Jump to content

Photo

ARM Scheme for UnoCart-2600


14 replies to this topic

#1 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 688 posts
  • Location:Orlando, FL US

Posted Sun Jun 3, 2018 9:46 PM

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.

 



#2 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,905 posts

Posted Mon Jun 4, 2018 8:44 AM

Two wishes:

 

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

http://atariage.com/...rd-coming-soon/

http://atariage.com/...nel-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.



#3 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 688 posts
  • Location:Orlando, FL US

Posted Mon Jun 4, 2018 9:45 AM

Having the Uno cart compatible with the bankswitching scheme batariBASIC can use:
http://atariage.com/...rd-coming-soon/
http://atariage.com/...nel-frameworks/


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.



#4 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 399 posts
  • Location:Germany

Posted Mon Jun 4, 2018 2:34 PM

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/...rd-coming-soon/

http://atariage.com/...nel-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.



#5 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 688 posts
  • Location:Orlando, FL US

Posted Mon Jun 4, 2018 9:36 PM

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.

#6 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • 199 posts
  • Location:Hannover, Germany

Posted Tue Jun 5, 2018 3:45 AM

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



#7 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 688 posts
  • Location:Orlando, FL US

Posted Tue Jun 5, 2018 9:38 PM

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.

#8 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 399 posts
  • Location:Germany

Posted Wed Jun 6, 2018 3:08 PM

 

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.).



#9 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 688 posts
  • Location:Orlando, FL US

Posted Wed Jun 6, 2018 8:11 PM

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.



#10 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • 199 posts
  • Location:Hannover, Germany

Posted Fri Jun 8, 2018 12:59 AM

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.



#11 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 399 posts
  • Location:Germany

Posted Fri Jun 8, 2018 3:06 PM

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.



#12 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,277 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 8, 2018 3:14 PM

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, Fri Jun 8, 2018 3:17 PM.


#13 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,793 posts
  • Bitnik
  • Location:Canada

Posted Fri Jun 8, 2018 7:23 PM

Official game URL field?

DRM enforcement flag?  :evil:



#14 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 688 posts
  • Location:Orlando, FL US

Posted Fri Jun 8, 2018 8:53 PM

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.



#15 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • 199 posts
  • Location:Hannover, Germany

Posted Sat Jun 9, 2018 1:24 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users