7800basic beta, the release thread

[Revontuli]

12 hours ago, RevEng said:

I dropped a new v0.21 7800basic release at github. Changes include...

Awesome!  

I agree that the banksets are the big thing, but I appreciate the pokey sfx pitch shift, since that allowed me to make the music tracker for Harpy's Curse much, much more easily

 

The bankset stuff is a big deal (gfx bank space is typically the first thing I run out of or have to restructure for, *way* before ROM and RAM) - Harpy's Curse is effectively finished (or at least finished as far as fitting into its 128kROM16kRAM layout), but I'm certainly keeping a 2x128K ROM in mind for a possible platformer to follow.  Is there any documentation out yet on how to properly use banksets in 7800Basic (as opposed to asm), or it is that coming soon?

 

Amazing work as always - 7800Basic makes developing for the 7800 a ton of fun, thank you!

[+Random Terrain]

14 hours ago, RevEng said:

I dropped a new v0.21 7800basic release at github. Changes include...

• Bankset support added
• Hi-Score controller callback functions added, to allow score entry with non-joystick controllers.
• Keypad driver updated to allow for slower-than-spec keypads
• SNES control driver updated to recover from sync loss
• bugfix: allow pokey sfx to change pitch
• docfix: documented 0 to 0 decrementing loop edge case
• docfix: mutesfx added to docs

I wanted to level-set 7800basic and get banksets out into developer hands, but I'm planning to put out another release in the next month or so, to add RMT pokey tracker support.

 

The online version has been updated:

 

https://www.randomterrain.com/7800basic.html

 

Also checked the page with https://validator.w3.org/ and got rid of some errors that I had. Now the page is supposedly error-free (until more code becomes obsolete).

[Trebor]

4 hours ago, Revontuli said:

Is there any documentation out yet on how to properly use banksets in 7800Basic (as opposed to asm), or it is that coming soon?

This page may help and includes downloadable sample bankset ROMs:

 

http://7800.8bitdev.org/index.php/Bankset_Bankswitching

[RevEng]

First-off, thanks for all of the thank-you's and words of appreciation, guys! And a big on-going thanks to you, RT for continuing to update the online manual!

 

5 hours ago, Revontuli said:

Is there any documentation out yet on how to properly use banksets in 7800Basic (as opposed to asm), or it is that coming soon?

There's a new banksets section in the manual that goes over the main points, and there's a commented conversion of the "adventurer" sample, called "banksets". I think in time I'll need to expand on both of those, 

 

For the most part you can treat your banksets program code like it's non-bankset format counterpart. By which I mean you just go ahead and "incgraphic" wherever you normally would in the source code - the graphics will automatically go to the Maria bankset, and take up zero space in your Sally/7800basic-code rom. This was entirely by design - I wanted it to be fairly painless to switch bank and forth between banksets.

 

The one thing you do need to do is do differently is to stick "bset_" in front of any data that you need Maria to see (e.g. character/tile data), so 7800basic knows to send it to Maria's bankset.

 

I'm starting to re-iterate the manual info here, but bankswitching is the same too. A bankswitch for Sally is a bankswitch for Maria, so wherever you'd need to avoid switching away from displayed graphics with non-bankset formats, you still need to avoid switching away in the exact same way.

 

The one advanced tip I'd give is to use cart ram, and then you can store graphics in Sally's side of the rom too, and copy them to Maria's view of the RAM. This works fine for character/tile graphics, but less so right now for sprite graphics. Sprite graphics need dma holes to move smoothly vertically, and dma holes don't extend down into the cart ram area. There's also the sticky problem of 7800basic not having a way to plotspite graphics that you didn't import with incgraphic, which I'll try to figure a way around in the future.

 

Speaking of "in the future", I'm also going to add commands for the game to disable dmaholes and pack in graphics where dma holes would normally be. This is problematic for games with sprites that move vertically (which is most of them), but for tile based games it would allow for double the available graphics storage. To me, this really only makes sense in the context of banksets, since you can fill the entire address space (and more) with graphics and still have somewhere for your program code to run.

[Shannon]

So I guess this is one release that we can really bank on! 

 

[+mksmith]

Hi all!

Thanks Mike for the release and Happy New Year to you my friend 😄

 

I'll get this into ADS shortly!

[RevEng]

9 hours ago, mksmith said:

Thanks Mike for the release and Happy New Year to you my friend 😄

Right back at you!  🎆

[RevEng]

Heads up that Matt found what I'd call a show-stopper bug in the v0.21 release - non-bankset bankswitched roms with graphics all the way at the front of any ephemeral bank will encounter a compile error.

 

A bug-fix release is being tested.

[RevEng]

As promised, there's a new v0.22 7800basic release at github, with just a single change...

• bugfix: non-bankset bankswitched roms with graphics all the way at the front of any ephemeral bank will encounter a compile error.

No changes to the docs, RT.

[+Muddyfunster]

Great find @mksmith, thanks for the swift fix @RevEng.

[+mksmith]

On 12/31/2022 at 1:03 AM, RevEng said:

The one advanced tip I'd give is to use cart ram, and then you can store graphics in Sally's side of the rom too, and copy them to Maria's view of the RAM. This works fine for character/tile graphics, but less so right now for sprite graphics. Sprite graphics need dma holes to move smoothly vertically, and dma holes don't extend down into the cart ram area. There's also the sticky problem of 7800basic not having a way to plotspite graphics that you didn't import with incgraphic, which I'll try to figure a way around in the future.

 

Speaking of "in the future", I'm also going to add commands for the game to disable dmaholes and pack in graphics where dma holes would normally be. This is problematic for games with sprites that move vertically (which is most of them), but for tile based games it would allow for double the available graphics storage. To me, this really only makes sense in the context of banksets, since you can fill the entire address space (and more) with graphics and still have somewhere for your program code to run.

Wow - some of this sounds great! It would be awesome to pack gfx and unpack them either on the fly or for a specific screen. I have a project where this would be interesting as I copy characterset and tilemap gfx into ram (have been thinking about investigating compiled code to see if I can do something here).

 

1 hour ago, Muddyfunster said:

Great find @mksmith, thanks for the swift fix @RevEng.

Not much input from me as I was just compiling up Millie and Molly to test out 😊 Its a good project as one of the banks for choc full with source and gfx. 

[+saxmeister]

On 12/29/2022 at 2:40 PM, RevEng said:

add RMT pokey tracker support.

Thank you! I'm looking forward to this. I've been coming to grips with RMT just for this purpose.

 

Many thanks for this incredible tool which has made so many good things possible on the 7800!

[RevEng]

I appreciate that! I'm pretty keen on getting RMT incorporated too. It's in there on the backend already, since I added it during the petscii robots development, but I need to create some 7800basic commands to make things easier.

 

A few notes, since you're already looking into RMT authoring...

1. The 7800basic driver is based on Eckhard Stolberg's RMT assembly port to the 7800, which was RMT v1.20. It's best to stick to that version of the authoring software, as I'm not entirely sure what driver changes later versions require. This may change in the future, based on how A8 RMT developments with LZSS pokey data streaming shakes out.
2. Instrument speed should be 1x, since 7800basic only calls the driver once per frame. I pulled and converted all of the RMT music from the asma archive, and 1x seems to be pretty standard.
3. Compose with one pokey. This may change later.

 

[+Karl G]

I have a feeling that this has been asked before, but is there any way to copy a sprite to RAM and then plot it from there, or update something to point at the moved sprite to allow manipulation of the bits directly?

 

Failing that, does anyone have any suggestions on how to make a sprite appear to "dissolve" apart from flipping through many different frames? Palette manipulation might be one way to do something similar, but I'm wondering about other options as well.

[+SmittyB]

@Karl G check out this demo I put together to show the sort of thing you're looking for. It's doing it with tiles rather than sprites, but ultimately to the 7800 it's all the same thing so it doesn't matter.

 

https://forums.atariage.com/topic/295423-animated-chars-with-characterset-from-memory/?do=findComment&comment=4339782

[+Karl G]

5 minutes ago, SmittyB said:

@Karl G check out this demo I put together to show the sort of thing you're looking for. It's doing it with tiles rather than sprites, but ultimately to the 7800 it's all the same thing so it doesn't matter.

 

https://forums.atariage.com/topic/295423-animated-chars-with-characterset-from-memory/?do=findComment&comment=4339782

Thanks! I hadn't considered using characters since I'd be drawing over a background that uses sprites, and I had it in my head that characters aren't ever drawn over sprites, though I'm not sure where I got that impression. I suppose it just depends on the drawing order like anything else?

[RevEng]

Characters in 7800basic are limited to zone Y alignment, due to DMA concerns, so that may or may not be a problem here.

 

RAM based sprites are possible, but it's a fair bit of under the hood work. The plotsprite command expects a bunch of constants named after the sprite, which are created by the incgraphic command for that sprite. If you can provide an alternative set of those constants (you can dig them out of the *.symbol.txt file) for the RAM location, then plotsprite will work equally with the alternate ram-based name. Of course, you'll also need to copy the sprite into RAM in the weird format the 7800 expects, with a page of RAM separating each line of the sprite.

 

At some point I'm going to try and come up with a pseudo "incgraphic" type command that sets up the symbols for you, for ram based sprites, but I'm a ways off from implementing that.

[+karri]

8 hours ago, Karl G said:

I have a feeling that this has been asked before, but is there any way to copy a sprite to RAM and then plot it from there, or update something to point at the moved sprite to allow manipulation of the bits directly?

 

Failing that, does anyone have any suggestions on how to make a sprite appear to "dissolve" apart from flipping through many different frames? Palette manipulation might be one way to do something similar, but I'm wondering about other options as well.

In Wizzy I do a transparent sprite by setting every second pixel to transparent. So when the character moves it is solid and when it is idle it is transparent. You could see the scenery through the character. And it is still animated.

 

 

In Wizzy the idea is that you can collect shadowflies to create a shadow cloak that helps you sneak around.

 

I don't have screenshots as the current development is on real hw and the SN cart code does not run on emulators.

[RevEng]

Hey all,

 

Just a heads up that @darryl1970 found a conflict between the snes2atari driver and atarivox/savekey driver. Until I get a chance to address this, it's advised to avoid using both of these in the same game. Potentially it could corrupt other saves in the atarivox/savekey device.

[Revontuli]

I'm finally getting around to trying banksets, which it taking some getting used to.

 

I take it these errors are normal?  A7800 does seem to run the final ROM image.

 

[...compile messages...]

7800basic compilation complete.
User-defined 7800.asm found in current directory
too many endif's
too many endif's
too many endif's
too many endif's
   stack allowance: 30 nested subroutines.
   the canary is situated at: $1c1
   stack allowance: 30 nested subroutines.
   the canary is situated at: $1c1

Complete. (0)
starting bankset symbol transfer.
bankset symbol transfer complete.
   stack allowance: 30 nested subroutines.
   the canary is situated at: $1c1
   28169 bytes of ROM space left in the main area.
     $1880 to $1fff used as zone memory, allowing 31 display objects per zone.
     2401 bytes left in the 7800basic reserved area.

[...more compile messages...]

 

I'm realizing how much I'll have to switch around the programs I used to use for testing ROM builds.  I take it that we'll, at the very least, need to upgrade firmware for the Concerto/Dragonfly?  

I will miss BupSystem for testing - I respect the accuracy of A7800 emulation, but I need to remember the macros and environment variables to use to run the darn thing from the command line (or otherwise go through 8 menus to test a build XD)

 

Again, the added functionality is very much appreciated (I've always run out of graphic block space first, before ROM, RAM, and even CPU cycles) - but I want to make sure that, as I change how my pipeline works, I'm not forgetting anything or getting something wrong this early on!

 

[RevEng]

Yeah, the too many endif's thing is harmless. I tracked down the cause of it, and it's within some conditional code that's been permanently turned off anyway. Next release won't have those errors.

 

I'm trying to get other emulator authors on board for banksets. Presently there's a7800 (pc), a7800ds (nds), and the MiSTer 7800 core. (fpga) The petscii robots demo will drop soon, so with that hopefully more emulator authors will get on board.

 

Concerto doesn't yet have bankset support either, and early Concertos don't have a required connection to the halt line.

[Revontuli]

I'm gradually getting the bankset stuff to work - While I'm not porting Harpy's Curse itself to a bankset system, I'm trying to move a lot of its code over as a proof-of-concept as I start another project that will take advantage of a lot of its codebase. 

 

My current stumbling block is reconciling multibank layout with the bankset - This code compiles but A7800 has trouble running it (removing the "set banksets on" will get it working again):

 

  set banksets on
  set romsize 128kRAM

__StartROM 
  BACKGRND = $0A
  goto __StartROM
   
  bank 2
  bank 3
  bank 4
  bank 5
  bank 6
  bank 7
  bank 8

 

[EDIT: It seems to work ok with romsize 128K but not romsize 128kRAM]

 

I'm also trying to gauge how much graphical space I actually have when considering the DMA holes and extra RAM.  I will say I'm having flashbacks to the first time I shifted from one 48k bank to several 16k ones  

 

I'm at that point where I'm trying to implement an awesome feature (banksets) while stuck in the weeds of getting it to work!  I think I'll move my further questions to their own thread, to avoid crowding this one (who knows, maybe it will aid in a tutorial eventually) - I have a project I've working on that can hopefully take advantage of the extra graphical (and DMA hole-free code) space!

Edited January 29, 2023 by Revontuli

[RevEng]

4 hours ago, Revontuli said:

[EDIT: It seems to work ok with romsize 128K but not romsize 128kRAM]

It looks like 7800basic isn't setting the header to "hram@4000" instead of regular "ram@4000", like it should be. It's a pain, but either you can set that after a build with 7800header, or you can wait for the next release. Sorry about that.

[OldStyle]

 

Is set dlmemory compatible with banksets + RAM?  It seems to work if console memory is used but allocating from on-cart is corrupting the display.

[RevEng]

4 hours ago, OldStyle said:

Is set dlmemory compatible with banksets + RAM?  It seems to work if console memory is used but allocating from on-cart is corrupting the display.

Not yet, but mainly due to oversight. I'll try to tackle that for the next release.