Jump to content
ZackAttack

ARM Scheme for UnoCart-2600

Recommended Posts

I'm going to implement a new scheme for the UnoCart firmware to enable custom ARM code execution. This is what I have in mind, please let me know how I can improve it.

 

  1. Create a new file type with its own header and extension
  2. Put a driver uuid and version fields in header to make life easier for emulators
  3. Specify ROM size in header up to 512KB.
  4. Specify RAM size in header up to 192KB.
  5. Specify ROM checksum in header.
  6. Use ROM checksum to avoid reflashing ROM if the selected game is already there.
  7. Load 6507 routine into zeropage and pull D0-D7 high with built in Pull-up resistors so 6507 can run on its own while ROM is being loaded. Once program is ready it will pull D0-D7 low to signal a jump to $f000
  8. Store the full file path in RAM before handing control over to the game so it can load additional data from files larger than 512KB. Also, enables games to save to themselves or a similarly named save file.

 

  • Like 7

Share this post


Link to post
Share on other sites

Two wishes:

 

Having the Uno cart compatible with the bankswitching scheme batariBASIC can use:

http://atariage.com/forums/topic/219144-new-homebrew-board-coming-soon/

http://atariage.com/forums/topic/221100-bb-256k-128k-64k-32k-multikernel-frameworks/

 

Some way to have the program see plain old SuperChip RAM but have it be effectively static. Meaning whatever values were in RAM on shutdown get automagically loaded on power on.

 

I could see Atari Adventure type games with a vast, open worlds and sandbox style gameplay.

Share this post


Link to post
Share on other sites

I think the MegaFlex scheme that DirtyHairy is working on is probably what you're looking for here. We do want to have some form of bB support for that one.

 

Some way to have the program see plain old SuperChip RAM but have it be effectively static. Meaning whatever values were in RAM on shutdown get automagically loaded on power on.

 

I could see Atari Adventure type games with a vast, open worlds and sandbox style gameplay.

What I'm proposing would support saving to a save file on the SD card of saving to built in flash for non SD card variants. In theory you could enhance the cart hardware to battery back up some of the RAM, but that would add to the cost of each cart.

 

Really once you're executing custom ARM code you can do whatever you want with the hardware. I'm just trying to figure out what the best way to get to the point where the custom ARM code is running.

  • Like 1

Share this post


Link to post
Share on other sites

I'm going to implement a new scheme for the UnoCart firmware to enable custom ARM code execution. This is what I have in mind, please let me know how I can improve it.

 

  1. Create a new file type with its own header and extension
  2. Put a driver uuid and version fields in header to make life easier for emulators
  3. Specify ROM size in header up to 512KB.
  4. Specify RAM size in header up to 192KB.
  5. Specify ROM checksum in header.
  6. Use ROM checksum to avoid reflashing ROM if the selected game is already there.
  7. Load 6507 routine into zeropage and pull D0-D7 high with built in Pull-up resistors so 6507 can run on its own while ROM is being loaded. Once program is ready it will pull D0-D7 low to signal a jump to $f000
  8. Store the full file path in RAM before handing control over to the game so it can load additional data from files larger than 512KB. Also, enables games to save to themselves or a similarly named save file.

 

That sounds pretty good to me. A few remarks:

 

  • The smaller of the two STM32F4 SOCs that is usually found on the carts has only 512k flash, 64k of which are used by the firmware.
  • RAM is 128k "ordinary" RAM + 64k zero-waitstate CCM RAM, but the current memory layout of the firmware leaves only 96k + 64k CCM available
  • Starting a cartridge from the menu already does what you propose: the 6507 jumps to RIOT RAM and triggers the setup of the ROM there. It then waits for the cartridge to come back online (drive the bus again), at which point it jumps to the reset vector

 

Two wishes:

 

Having the Uno cart compatible with the bankswitching scheme batariBASIC can use:

http://atariage.com/forums/topic/219144-new-homebrew-board-coming-soon/

http://atariage.com/forums/topic/221100-bb-256k-128k-64k-32k-multikernel-frameworks/

 

Some way to have the program see plain old SuperChip RAM but have it be effectively static. Meaning whatever values were in RAM on shutdown get automagically loaded on power on

 

I could see Atari Adventure type games with a vast, open worlds and sandbox style gameplay.

 

 

Actually, saving and loading chunks of RAM (to SD in this case) is a pretty cool idea I think. It could work by describing the operation to be done in a data structure in RAM and then waiting in RIOT RAM until the cartridge has completed the operation. I have something similar planned for loading parts from an arbitrarily large "extended image" into RAM or ROM at runtime.

  • Like 2

Share this post


Link to post
Share on other sites

The smaller of the two STM32F4 SOCs that is usually found on the carts has only 512k flash, 64k of which are used by the firmware.

Noted. ROM size will be limited to 448KB. If the file is larger than that it will need to handle its own loading for everything over 448KB.

 

RAM is 128k "ordinary" RAM + 64k zero-waitstate CCM RAM, but the current memory layout of the firmware leaves only 96k + 64k CCM available

The custom ARM code can just stomp on the firmware's memory since it will not transfer control back to the firmware. How the memory is used will be entirely implementation defined. I was mostly thinking it would be nice to know how much RAM is used for emulation and future hardware design purposes. Thanks for pointing out the CCM. I'll have a field for RAM data size, and RAM code size to make this more useful.

 

 

Starting a cartridge from the menu already does what you propose: the 6507 jumps to RIOT RAM and triggers the setup of the ROM there. It then waits for the cartridge to come back online (drive the bus again), at which point it jumps to the reset vector

Great, I was hoping there would be some routine that could be reused for this.

 

 

I think it would also be good if the header includes a magic number and the file size and is embedded in the beginning of the file. Then the firmware could detect the presence of a game in flash and automatically run it if there is no SD card present.

  • Like 1

Share this post


Link to post
Share on other sites

How about a way so store data like highscores, game states, etc.?

Perhaps there could be a routine that you can call which specifies a region of RAM to be copied to ROM or SD card depending on how the game was loaded. You'd have to reduce the game size by however much you intend to save in order to fit it into flash.

Share this post


Link to post
Share on other sites

 

Thanks for pointing out the CCM. I'll have a field for RAM data size, and RAM code size to make this more useful.

 

You're welcome :) The only issue to be aware is that CCM and "ordinary" RAM do occupy two disjoint parts of the address space, so you can't use them as a contiguous block of RAM.

 

I think it would also be good if the header includes a magic number and the file size and is embedded in the beginning of the file. Then the firmware could detect the presence of a game in flash and automatically run it if there is no SD card present.

 

 

Definitely. I am planning a similar header for MegaFlex. Perhaps we could trailblaze a bit and include several fields for metadata (author, date, TV format, etc.).

  • Like 1

Share this post


Link to post
Share on other sites

Definitely. I am planning a similar header for MegaFlex. Perhaps we could trailblaze a bit and include several fields for metadata (author, date, TV format, etc.).

 

Ok, this is a great idea. I'm in.

 

What I'm proposing is an optional VCS Metadata header which when present can enhance the user experience by providing metadata and a small icon to use in menu programs. More complex schemes like the ones we're working on can have an additional structure in the file which may or may not be part of the embedded bin.

 

 

In theory we can retroactively apply this header to existing ROMs. The menu program can detect if all the files in a folder contain thumbnails and switch to thumbnail view automatically.

 

I just added a header file to my fork. Let me know what you think.

Share this post


Link to post
Share on other sites

If you're going for some kind of meta-format, wouldn't it be wiser to use a zip-container including all files necessary and optional? Like some meta-data (e.g. json-encoded), and the binary data for the ROM. Optional data would be manual and box-art.

  • Like 1

Share this post


Link to post
Share on other sites

In theory we can retroactively apply this header to existing ROMs. The menu program can detect if all the files in a folder contain thumbnails and switch to thumbnail view automatically.

 

I just added a header file to my fork. Let me know what you think.

 

 

Looks good to me. I would kick the "scheme_head_offset", though; if the scheme requires a header, it will be part of the actual scheme "image" after the header. There is no such thing as a "raw" bin image for anything other that 2k and 4k anyway, they all need interpretation anyway. I would also change "version" to an uInt32 that increments with every revision.

Share this post


Link to post
Share on other sites

I would add more, e.g. default difficulty switches and controllers. IMO almost basically everything you can find in Stella's "Game Properties" dialog would make sense.

 

Also a checksum of the ROM itself would be helpful. And maybe some bookkeeping info, like how often the ROM was loaded and how long it was played. I even wouldn't mind a full resolution (160 x ~240) screenshot.

Edited by Thomas Jentzsch

Share this post


Link to post
Share on other sites

If you're going for some kind of meta-format, wouldn't it be wiser to use a zip-container including all files necessary and optional? Like some meta-data (e.g. json-encoded), and the binary data for the ROM. Optional data would be manual and box-art.

I really like this idea, but I'm concerned that it would make the game unloadable on SD carts like harmony and uno. Perhaps if we allocate 128KB to firmware on the uno there would be enough room for a zip and json library.

 

 

 

Looks good to me. I would kick the "scheme_head_offset", though; if the scheme requires a header, it will be part of the actual scheme "image" after the header. There is no such thing as a "raw" bin image for anything other that 2k and 4k anyway, they all need interpretation anyway. I would also change "version" to an uInt32 that increments with every revision.

I was thinking it would be nice to provide additional scheme information in a more explicit way for some of the fancier roms. I. E. 3e with 48KB ROM and 24KB of RAM. But, yeah, there would be cases where the offset just points to the header that's embedded in the bin.

 

I would add more, e.g. default difficulty switches and controllers. IMO almost basically everything you can find in Stella's "Game Properties" dialog would make sense.

 

Also a checksum of the ROM itself would be helpful. And maybe some bookkeeping info, like how often the ROM was loaded and how long it was played. I even wouldn't mind a full resolution (160 x ~240) screenshot.

Would be really cool to capture the screenshot as a frame worth of 6502 execution so it could be replayed on hardware. You could have a slideshow mode to select which game to play.

 

Official game URL field?

 

DRM enforcement flag? :evil:

 

URL good, DRM bad. If you want DRM just make it fit in the MCU and enable memory protection.

 

There's a lot of potential here, but it's not part of the critical path for implementing MegaFlex or ARM Custom Executables. So let's shelve the metadata discussion for now and revisit it when someone is available to work on it.

Share this post


Link to post
Share on other sites

I really like this idea, but I'm concerned that it would make the game unloadable on SD carts like harmony and uno. Perhaps if we allocate 128KB to firmware on the uno there would be enough room for a zip and json library.

Most probablly Harmony won't be able to cope with it. But cJSON is just one C file of 50k in size (including sourcecode), minizip is a bit larger, though, but it should fit in the UnoCart. If I can spare some time and build a test-case, but as I look at my schedule this will probably not happen soonish.

Share this post


Link to post
Share on other sites

Did you ever arrive at a method for saving game data to the cart?  I'd like to avoid requiring a save key.

Share this post


Link to post
Share on other sites

I doubt the UnoCart can emulate a SaveKey. And proprietary solutions would fraction the system.

Share this post


Link to post
Share on other sites
7 minutes ago, Thomas Jentzsch said:

I doubt the UnoCart can emulate a SaveKey. And proprietary solutions would fraction the system.

Thank you for your feedback.

 

Nevertheless, I am curious in hearing from ZackAttack about possible high score storage on a stand alone cart, because the thread hints at the possibility.

 

Rather or not users with rom file and a standard UnoCart can save the game isn't a concern for me this time.

Share this post


Link to post
Share on other sites

Sorry, I thought you asked for something special for the UnoCart.

 

You can save on a standalone cart. Chetiry and Star Castle Arcade do so.

 

 

Share this post


Link to post
Share on other sites

If you look at the unocart firmware you'll find that it's already writing to the flash memory for the larger schemes like 3E when the bin is too big to fit in RAM. So just use that as a template to add flash memory writing support to your own arm project.

 

I think it would be good if we reserved sector 3 for saved game data and defined a simple structure to allow multiple games to share it. It would also be nice to add import/export functionality to the firmware so you could backup to SD or share your games saves.

 

Though if you only care about a stand alone cart, you could use whatever sector you want, any way you want.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...