lb3361 wrote: ↑21 Feb 2021, 22:10
To me this looks like the most reasonable option because, as you explain, all bytes in the first 32KB are accounted for, and because a Gigatron that boots from a SD card must have one of these expansion boards so far. But even that is not enough. Although we can hide the code in bank 3, we cannot hide the zero page variables it relies on. This is why I believe that one should also bank a part of the zero page in order to provide a safe space for those variables.
Would it be possible to do this completely in software, (obviously apart from the bank switching)? My idea is that native code doesn't give two cahoots about where it's vCPU context lives, i.e. you could switch RAM banks while native code was running and as long as you weren't trying to output the video stream and as long as the vCPU context was still valid, everything should work fine:
Process that occurs for a SDCard access whilst running from RAM bank 0, this assumes that there are three banks 0 to 3 in a 128K RAM expansion?
1) SDCard access is initiated, so wait for VBlank, call a native Sys function that copies page zero from bank 0 to page zero in bank 3.
2) Load vCPU SDCard reader/utils from ROM into bank 3 RAM, facilities for this are already built into the ROM's.
3) Execute the SDCard reader vCPU code that is now residing in RAM bank 3, (the issue here is that once the video stream needs to commence, you need to switch back to ram bank 0, (or have a full copy of video RAM in bank 3, or not care what is contained in the bank 3 mirror of video RAM).
4) If you don't have a copy of video RAM in bank 3, you would need to switch back to bank 0 at the end of VBlank, this would slow down your SDCard reader drastically as it could only get work done during VBlanks, (a much more complicated system could be setup that bank switches during non video/audio/io bit banging, i.e. horizontal blanks, but I fear that would require major ROM modifications to the ROM bit-banging code.
5) If you don't care that during SDCard reading/accesses that your video stream is not the same as bank 0's video stream, then you could fill the bank 3 mirror of bank 0 video ram with whatever values you like, (lets say an empty blue background that matches the default Gigatron blue background), as the monitor only requires valid sync signals, the video stream itself is purely for user feedback and is inconsequential to the actual functioning of the SDCard, (it might not be a great user experience, but it should work). You could make it look like upon starting the SDCard menu option in bank 0, the screen instantly clears, (as it bank-switches to bank 3 initialised video ram), and then run the SDCard code outputting results to bank 3 video RAM.
6) Whenever the SDCard code needs to copy code from the SDCard buffer in bank 3 to bank 0, it can do a simple bank switch for that copy, even if that copy is as granular as a byte, as long as the copying is done by native code, (i.e. a Sys function in ROM), then you don't have to worry about what RAM is currently enabled, or what the vCPU interpreter context currently is or when/what the video bit-banging is about to do; the native sys function is guaranteed to be processed outside of vCPU processing and outside of video bit-banging, (that's the way that native Sys calls work, i.e. Sys calls can never cause race conditions with vCPU code or the bit-banging code).
TLDR: or a simpler summary of what I am trying to say:
0) Initialise bank 3 mirror of video ram, (only on reboot).
1) vCPU SDCard code lives in ROM.
2) native bank switching code lives in ROM.
3) Bank switch from bank 0 to bank 3 when SDCard code is started and VBlank has commenced, (trivial to do in a ROMv5a/DEVROM VBlank interrupt).
4) Copy page zero in it's entirety from bank 0 to bank 3, this requires a trivial ROM Sys function addition and no modifications to internal ROM architecture.
5) Launch, (using the current vCPU from ROM launcher), ROM SDCard code into bank 3, (now with it's own valid page zero).
6) Each time bank 3 SDCard code wants to write a byte from SDCard to page 0, then bank switch to page zero and copy that byte through vAC or vTMP, this is another native Sys function that is trivial to add to the ROM, (but maybe not so trivial to write).
7) Once done copying, switch back to page 0 and execute the code through the normal execution process built into the current ROM.
P.S. This would necessitate a 160x120 mirror of video ram in bank 3 that would need to be fenced off from user applications, as it's sole purpose is to provide a glitch free user experience, (it could also be used for some other pretty nifty built in features, like double buffering or a copy/swap buffer for better native software sprites etc), so cordoning it off from the rest of the system and user may allow it to be used for advanced future possibilities.