[Coco] CocoFLASH Production

[Barry Nelson]

I have not seen any features like what this Lode Runner cartridge requires used anywhere else in any existing cartridge. RoboCop and Predator both have and use more than 32k without doing this. If you can spare only a very few bytes of lower memory, you can implement routine to call functions in other banks. I have a routine that loads .BIN files and copies them to RAM. I copy the ML routine that does this to the cassette buffer and then run it from there.

 

Sudo code example:

 

Copy a code fragment like this to somewhere in lower RAM.

 

Set rom page to any desired offset.

Set memory map to be 32k ram, 32k rom, if it wasn’t already. 

Jump subroutine to address of routine in rom.

Set rom page back to “standard” value .

Set memory map back to however it was originally set.

Return from subroutine.

 

 

 

>         On 11/7/2016 8:12 PM, Mark McDougall wrote:

>         On 8/11/2016 1:41 AM, RETRO Innovations wrote:

>         > 

>         >> So, is there something else needed to support LodeRunner?

>         > 

>         Thanks for the explanation!

>         > 

>         I have to revisit my memory layout; to be honest I haven't yet 

>         designed how the cartridge mapping was going to work... 4KB banks is 

>         good, but I was planning on being able to swap in/out smaller windows 

>         within the upper 32KB address space. Lode Runner uses the entire lower 

>         32KB for video memory, graphics data @$8000, code & game data 

>         @$C000... so I was thinking a 4KB window somewhere to be able to load 

>         level data - the original Apple II loaded this directly from disk 

>         sectors.

>         Well, I'd probably recommend a "bank in, copy ROM to RAM, and bank out" 

>         approach.  Splitting the 32kB ROM space into individually addressed 4kB 

>         virtual ROM slots would probably move me beyond my CPLD space.  I might 

>         be able to create 4 8kB virtual ROM slots, and use 4 16 bit pointers to 

>         set the bank for each of those slots:

 

>         $8000

>         $a000

>         $c000

>         $e000

 

>         But, that adds to the IO requirements (10 bytes instead of 4), and 

>         requires quite a bit more setup for the simpler case of mapping in a 

>         16kB or 32kB chunk of ROM into the CART space.

 

>         I guess let me know.  I can try it, if you feel the extra capability is 

>         needed.

>         > 

>         And EEPROM for save game data is awesome! I was going to propose a 

>         'standard' structure so that games from various authors could 

>         co-exist, like a tag/header+length for example, or maybe even a 

>         FAT-type scheme...

>         I think that's valuable.  I'd even suggest an API that hides the EEPROM 

>         medium, so the same api can be used for Darren's solution, and others.

 

>         I was extremely surprised that my 15 macrocell homegrown SPI master works...

>         > 

>         Regards,

>         Mark