Page 2 of 2

Re: New Gigatron with 128K expansion. Boots from SD!

Posted: 22 Feb 2021, 05:21
by at67
lb3361 wrote: 22 Feb 2021, 01:00 Just to be clear: Marcel designs always gives you bank 0 in the low memory 0x0000-0x7ffff. The video buffer leaves there. The bank bits B[1..0] select what you see in the high memory 0x8000-0xffff. If B[1..0]=0, then you have a copy of the low memory in high memory, like a 32KB Gigatron. If B[1..0]=1, which is what the rom does by default, then it looks like a 64KB Gigatron. Switching to bank 2 or bank 3 does not fundamentally change how the video is generated. Everything works, except that what appears in 0x8000-0xffff is changed.
Ok, that makes sense, a little disappointing, but I get why Marcel did it this way.
lb3361 wrote: 22 Feb 2021, 01:00 The entry code essentially, (1) saves the current bank, (2) switches to bank 3, (3) maybe saves VSPH, (4) calls the proper routine, (5) maybe restores VSPH, (6) restores the original bank, and (7) returns. Now the remaining problem is that the os code needs zero page variables. Let's say 64 bytes. Swapping 64 zp bytes takes at least 128 clock cycles, that is almost a full scanline. This has to be done on entry and exit. This cost prevents us to have small grain services such as reading one byte from the current file. This is doable, but clumsy and slow.
There are three App's that do nasty static initialisation within zero page, if those three App's were re-written to avoid static initialisation of zero page function call pointers and instead do them in an initialisation phase during their code execution, would this free up 0x44 to 0xBF for SDCard vars? Is this a simpler solution, (I could modify those three App's in an hour or two), than trying to page swap a portion of zero page in hardware?
lb3361 wrote: 22 Feb 2021, 01:00 Suppose now that switching to bank 3 switches a part of the zero page, say 0x80-0xff that is not touched by the main gigatron loop. That solves the problem. Suppose also that the 0x8080-0x80ff area always shows bank 0. That gives a place where to put the jump code that is accessible from every bank. Meanwhile programs that don't use these services can remain happily ignorant of all this. They can even overwrite the entry point since they are not using it. They just see a 64KB Gigatron. If they start to use banking, then that is another story....
This last section sounds quite good in terms of compatibility issues if I am understanding it correctly, a fixed area of memory, (0x8080-0x80ff), that contains SDCard vectors that can be used or ignored/written over depending on the application?