groepaz wrote:[...] could you please confirm what i did:
- the VIC can "see" all RAM in $0000-$1fff range
- the colorram was extended from 1k to 16k
- colorram address bits 10-13 come from VIA1 PB bits 0-3 (userport pins C-F)
Check. Check. Check - when the DDR is set to input, those four bits should default to high, and thus select bank 15.
- every instance of the VIC or CPU accessing colorram uses the new address scheme
(and of course you need to enable ram in block 0 and block 1)
Check. And Check - however IMO -vflimod should force RAM for block 0 anyway. No point in having the VFLI mod without RAM in $0400..$0FFF. I didn't include an enable switch - if a program requires the original RAM setup on the real h/w, I run a small program to set the limits of BASIC for 3583 bytes free.
Block 1 isn't strictly necessary. It's just required for anything that needs RAM there, like of course those slide shows.
if you spot obvious mistakes please shout
No obvious mistakes, but possibly one other thing to be wary about: the VFLI mod needs to explicitly disable *external* +3K expansions of any kind - see reasons
here. If those +3K come with extra functions, like banking or write-protect (on FE3), that doesn't work anymore on real h/w. Gives quite some cross-dependencies with all those cartridge simulations ...
In practice, it's for the moment only the write protect of the FE3 wedge which isn't anymore present. Also, on Mega-Cart, "unexpanded" doesn't mean anymore 3583 bytes free, but rather now 6655 bytes free, and I need to run the aforementioned utility to reduce it to 3583 with BASIC starting at $1001.
Just so one doesn't fall into a trap when he writes a program that requires both VFLI mod && (Mega-Cart || FE3 || UltiMem), and doesn't take into account, that the +3K don't anymore come from the cartridge, and thus don't anymore have the cartridge's extra functions.
...
Thanks!