I'm missing something here. If your storage devices are behind the serial I/O how are you planning to "read ahead to avoid serial I/O"? > On May 2, 2023, at 3:44 AM, Justin <shadow_at_darksideresearch.com> wrote: > > Our notional accelerator could have logic to read ahead to cache storage device contents and then not have to slow down for IEC I/O. > > Justin > >> On May 2, 2023, at 04:02, smf <smf_at_null.net> wrote: >> >> I don't know how SCPU does it, but the way I thought to do (but haven't implemented it ever) would be at bootup switch to >> >> "Bits #0-#2: Configuration for memory areas $A000-$BFFF, $D000-$DFFF and $E000-$FFFF. Values: >> >> %x00: RAM visible in all three areas." >> >> You would need to cache the roms on the accelerator as they are no longer going to be visible at $A000/$E000. For speed you would want to do this anyway. >> >> While it would be possible to transfer the onboard roms, you will need patched roms that disable the turbo when accessing the IEC bus anyway. So it's probably best to have them loaded into fast ram on the accelerator from an sdcard. >> >> That leaves I/O mapped into D000-DFFF, whenever the accelarator does those accesses you would pull /GAME low and leave /EXROM high and I think that will override the $00/$01 setting and switch to ultimax mode. The timing of switching in and out of ultimax mode while avoiding VIC2 cycles will be kinda interesting. I think the power cartridge displays sprites from rom using ultimax mode https://rr.pokefinder.org/wiki/Power_Cartridge, so it should be possible. >> >> I would recommend implementing the SuperCPU v2 ram mirroring registers, so that software can control which areas of the accelerators fast ram will be copied into the c64's memory. If you implement the turbo control registers then you can use the existing roms too. >> >> On 23/04/2023 10:32, Maciej Witkowiak wrote: >>> This got me thinking: how does a real SCPU handle access to $01 port? >Received on 2023-05-02 18:00:08
Archive generated by hypermail 2.3.0.