[Coco] CocoFLASH Production

[RETRO Innovations]

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
>


-- 
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com