The Gigatron project
Posted: Tue Dec 05, 2017 7:32 pm
Marcel van Kervinck has developed this wonderful retro computer, the Gigatron: it doesn't even use a micro-processor, and is built entirely from discrete TTL logic components available in the eighties. The challenge now of course is to make it play Chess.
The Gigatron has a rather harsh machine language, and although it has the capability to generate video signals for driving a VGA monitor, it has to do this in software (like the Sinclair ZX81). It can only use one quarter of the resolution horizontally, though (160 pixels per line), and its 32KB memory would not allow it to store an image that uses all 480 lines of a VGA image independently. So the usual display mode is to also reduce the vertical resolution by a factor 4, by displaying every line 4 times, so that a 160x120 image results. As displaying a line puts a 100% load on the CPU, usually only 3 (identical) lines are displayed, leaving the 4th line of every group black, allowing the CPU to do some calculations. Even storing the 160x120 image occupies 160 bytes in 120 of the 128 available (256-byte) memory pages.
I have already written a small program to display a Chess board on such a screen; in my emulator it looks like this:
The squares are 9x9 pixels, making the board 72x72, using only part of the screen. This leaves 304 of the 520 scan lines (including the vertical retrace) unused, increasing the time available for calculation. In fact it would be possible to increase that further, by displaying each line only once, for 448 lines of calculation vs 72 lines displayed. That still gives a clearly recognizable image. It would also give a hard-to-miss signal that the computer is done thinking, when the image would intensify threefold.
Even during black lines the program still has to generate the video sync pulses, however. And it has to generate them exactly in time. So the program should at all times be aware how many clock cycles it has been using, and generate a syc pulse when this is due. The alternative of course is to just drop the image while the program is thinking. This will upset the VGA monitor (which might start displaying some 'No Signal' warning), but it will recover soon enough when generation of the video signal resumes after the computer is done thinking. Yet another method is to do away with the monitor altogether, and use the output port to drive two 7-segment LED digits ('matchbox style').
Anyway, I will report in this thread about the development of the Chess program. First step will be to write something that works without paying attention to the video requirements; the generation of a video signal during thinking can be added later. The wish to eventually generate video during thinking will affect the design, though. Tight loops become quite inefficient when you have to keep track of how many iterations they do, in order to keep track of the elapsed time. So I will try to use algorithms that use a more predictable control flow, with as few conditional branches as possible. So preferably no scans along board rays to find the first piece in a certain direction, or whether a path between two squares is blocked.
The Gigatron has a rather harsh machine language, and although it has the capability to generate video signals for driving a VGA monitor, it has to do this in software (like the Sinclair ZX81). It can only use one quarter of the resolution horizontally, though (160 pixels per line), and its 32KB memory would not allow it to store an image that uses all 480 lines of a VGA image independently. So the usual display mode is to also reduce the vertical resolution by a factor 4, by displaying every line 4 times, so that a 160x120 image results. As displaying a line puts a 100% load on the CPU, usually only 3 (identical) lines are displayed, leaving the 4th line of every group black, allowing the CPU to do some calculations. Even storing the 160x120 image occupies 160 bytes in 120 of the 128 available (256-byte) memory pages.
I have already written a small program to display a Chess board on such a screen; in my emulator it looks like this:
The squares are 9x9 pixels, making the board 72x72, using only part of the screen. This leaves 304 of the 520 scan lines (including the vertical retrace) unused, increasing the time available for calculation. In fact it would be possible to increase that further, by displaying each line only once, for 448 lines of calculation vs 72 lines displayed. That still gives a clearly recognizable image. It would also give a hard-to-miss signal that the computer is done thinking, when the image would intensify threefold.
Even during black lines the program still has to generate the video sync pulses, however. And it has to generate them exactly in time. So the program should at all times be aware how many clock cycles it has been using, and generate a syc pulse when this is due. The alternative of course is to just drop the image while the program is thinking. This will upset the VGA monitor (which might start displaying some 'No Signal' warning), but it will recover soon enough when generation of the video signal resumes after the computer is done thinking. Yet another method is to do away with the monitor altogether, and use the output port to drive two 7-segment LED digits ('matchbox style').
Anyway, I will report in this thread about the development of the Chess program. First step will be to write something that works without paying attention to the video requirements; the generation of a video signal during thinking can be added later. The wish to eventually generate video during thinking will affect the design, though. Tight loops become quite inefficient when you have to keep track of how many iterations they do, in order to keep track of the elapsed time. So I will try to use algorithms that use a more predictable control flow, with as few conditional branches as possible. So preferably no scans along board rays to find the first piece in a certain direction, or whether a path between two squares is blocked.