1- Marcel's Simple Chess Program (MSCP) on a 128k Gigatron
I always tried to run MSCP on a Gigatron. The main issue is that MSCP needs a C compiler (done) and between 60 and 80 KB of memory depending on how one sets it up. I had succeeded in running it in a simulator, without a frame buffer (viewtopic.php?p=2379#p2379) and on the Gigatron 512k, by moving the frame buffer into page 15 (viewtopic.php?p=2828#p2828). But none of those is a real Gigatron.
The solution came from a discussion with Hans61. He considering a hardware patch that locks the framebuffer in banks 0 and 1, regardless of which bank is selected. The Gigatron 512k already works like this in fact. Anyway, I realized that we can also do this in software using a video loop that switches banks on the fly: use bank 1 when displaying the screen, use the bank selected by SYS_ExpanderControl when executing vCPU code. Making this change was challenging: I had to find at least two bytes in page zero to store data and a couple spare cycles in Marcel's notoriously tight video loops. In the end I had to steal a couple cycles from the vCPU, costing 2% in speed.
The ROM itself works only on 128k+ Gigatrons and offers very few programs:
- MSCP takes almost all the free space
- MSCP and Racer are the only programs that depend on ROM components. Racer loads the cityscape bitmap from the rom and needs two private SYS calls. MSCP loads its opening book from the rom. All other programs can be loaded easily from a SPI SD card without messing with the slowish Loader protocol.
You can also use command "both" to make MSCP play against itself. Because the Gigatron is not a very fast machine, the default search depth is now 2. To recover the full performance of MSCP, you need to type "sd 4" and be ready to wait. On the other hand, most of the opening book is there.
This program uses all memory banks. The code mostly resides in bank0 and its data in bank2; the screen buffer is in bank1; the transposition table and the opening book are in bank3.
2- Using the DEV7ROM and GLCC2
As usual everything is under the BSD license or the LCC license. No tricks, no revocable rights, no as-long-as-I-like-you clause.
The ROM binaries and their source code is available at https://github.com/lb3361/gigatron-rom in the master branch which used to contain the staged ROMv6. There are in fact three ROMs with different video loops.
- If you have one of the few Gigatron 512k, use "dev512k7.rom". This ROM only works on a Gigatron 512k.
- If you have a Gigatron 128k (any kind, including the Novatron), use "dev128k7.rom". This ROM only works on an expanded Gigatron.
- If you have an unexpanded Gigatron, you can use "dev7.rom". Since MSCP cannot run on your Gigatron, you'll get a normal video loop and the application selection of the defunct ROMv6. But you'll still get all the other speed improvements. This would also be the ROM to
use on a 128k Gigatron with the kind of hardware patch Hans61 has in mind.
The ROM source is in https://github.com/lb3361/gigatron-rom/ ... dev.asm.py. All three ROMs use the same source file and use conditional compilation constructs to change the video loop. You can use GLCC-2.0 (https://github.com/lb3361/gigatron-lcc/) to compile programs that use the new ROM goodies. Just use option "-rom=dev7" and observe a substantial speedup. There is also an option "-map=128k" which
copies bank1 into bank2, sets up the frame buffer in bank1, then switches to bank2 to run the program. This gives about 62KB of contiguous memory for code and data.
The adapted MSCP source is in https://github.com/lb3361/gigatron-rom/ ... s/MSCP/src. File "mscp.c" is 99% Marcel's code. The makefile calls the compiler with -map=128k and with an overlay that ensures that all code and data defined in file "core.c" lives in bank 0. I use it to swap banks and access the opening library or the transposition table. There is ample room to add new things such as a nice board display. I just did not have time. And also this is not what motivates me...
How final is the ROM? It could stay like this for a long time. I would like to reconsider two rare opcode and replace them with something different, but nothing guarantees that this is going to happen. Anyway, I will write about opcodes in a forthcoming addition to this thread. I did things quite differently from ROMvX0 and that paid off nicely (which was not obvious in the beginning.)