Possible ways of speeding up the Gigatron

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: Possible ways of speeding up the Gigatron

Post by Sugarplum »

My own idea is to have concurrent DMA of some sort and clock the video side at 6.25 and/or 12.5, and generate the correct syncs. To prevent I/O races, it would probably be easier to put sound and keyboard support in hardware too. Otherwise, one would need to do parallel syncs in software, add halting/spinlocks, and/or add full interrupt support. But if they are all hardwired as one I/O subsystem, software intervention would not be needed to route the traffic.

For compatibility and preventing software races (tearing screen, stuttering sound, or missing video/sound info), one could add a halt feature that is tied to the syncs. That would cripple performance, though there would be some increase with hardware syncs, hardwire line-quadding, hardware sound, and hardware keyboard I/O, plus the clocks could be independent if the RAM was fast enough and some sort of abstraction was used there. Like maybe add a handful of registers with the memory having a fast clock up to 100 Mhz or so, and creating different memory channels. If one wanted a new vCPU and new file format, one could add syncing opcodes and selectively halt or spinlock things as needed.

An easier way to do it in TTL hardware is to have a 2-phase 6.25 Mhz clock (ie., 12.5 Mhz with 2 overlapping 25/75 duty cycles) so each hardware subsystem or core has access at opposite times. That is much how the C64 did things, with the 6502 and the VIC-II alternating. You don't get the full benefit of the 12.5 Mhz base clock, but everything gets 6.25 Mhz in 2 interleaved cycles. I am not sure how one would do that in TTL since I'd be likely using FPGA clock management tiles. It probably could be done by ANDing the divided clock with the undivided clock for 1 channel and ANDing the undivided clock with the inverted divided clock. So a pulse from the original when the divided clock is high, and a pulse from it when it is low, with one driving the CPU and the other driving the DMA controller.
Last edited by Sugarplum on 29 Apr 2021, 12:03, edited 1 time in total.
axelb
Posts: 41
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

Hans61 wrote: 25 Apr 2021, 15:17 Very nice work, thank you. I think I would like to replicate it. I think the PCB clashes with the RAM expander. Maybe I will make one myself.
If you intend to add a VGA adapter to your PCB ( following at67´s idea ) there is an example from Ted Yapo on Hackaday.
It shows which resistors he used to connect a 74ACT574 to the RGB and SYNC lines.
https://hackaday.io/project/18682-pic-graphics-demo
Attachments
74ACT574.jpeg
74ACT574.jpeg (58.62 KiB) Viewed 2975 times
Hans61
Posts: 102
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Possible ways of speeding up the Gigatron

Post by Hans61 »

I don't have a FIFO yet. I just ordered some and hope they arrive within the next week.
@axelb thanks for the hint.
I wanted/will test the circuit first as it is. I think it's already good as it is, since it gives us the maximum processing power of the Gigatron without graphics loss.
To decouple the VGA clock you would have to regenerate HSYNC and VSYNC. But that would be the minor problem.
You would also have to synchronize the Gigatron software with the extension. The Gigatron would have to rewrite the FIFO at the beginning of each new pixel line.
For this the Gigatron would need a feedback from the extension if they don't run in the same clock and the software would have to take this into account.
Then there would be the problem that U38 and U39 depend on the Gigatron clock HSYNC.
I can't think of a solution for this with little effort and the technology of the 1980s. Or do I see that wrong?
axelb
Posts: 41
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

The link below shows at67’s Mandelbrot application with the Gigatron running at about 11 MHz together with my video repeater:
https://youtu.be/yvkT9QpGYkI
axelb
Posts: 41
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

Hans61 wrote: 02 May 2021, 17:56 To decouple the VGA clock you would have to regenerate HSYNC and VSYNC. But that would be the minor problem.
You would also have to synchronize the Gigatron software with the extension. The Gigatron would have to rewrite the FIFO at the beginning of each new pixel line.
For this the Gigatron would need a feedback from the extension if they don't run in the same clock and the software would have to take this into account.
Then there would be the problem that U38 and U39 depend on the Gigatron clock HSYNC.
I can't think of a solution for this with little effort and the technology of the 1980s. Or do I see that wrong?
Really it might be too complicated to use completely decoupled SYNC signals.

In the meantime i was able to overclock my Gigatron to 10-11 MHz while adapting Rom3y to achieve the correct HSYNC. When dividing CLK2 by 2 before feeding into /R of the FIFO memory it is possible to get rid of the black right part of the image. Of course the image is clipped at the right edge as long as 12.5 MHZ isn’t used.

Is anyone able to provide the Gerber files for a 4 Layer board so that I can try to build up an overclocked Gigatron according to Marcel’s suggestions?
Hans61
Posts: 102
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Possible ways of speeding up the Gigatron

Post by Hans61 »

klf
Posts: 17
Joined: 10 Jan 2019, 22:48

Re: Possible ways of speeding up the Gigatron

Post by klf »

The Gigatron was designed as a "TTL Microcomputer". Now there are some expansion ideas based on GALs. If you accept programmable logic in your highspeed Gigatron this could significantly shorten the critical path.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: Possible ways of speeding up the Gigatron

Post by Sugarplum »

The above is why in my FPGA design, I'd be using DMA with hardware-only syncs and moving all I/O to hardware. So everything that needs the syncs would have direct physical access to them. That would prevent hardware races. Software races would be more difficult to avoid. In this configuration, you'd have 2 threads, a CPU thread, and an I/O thread.

I have some ideas about software races. I could put some flow control in the hands of the vCPU coder in the new vCPU core. As for existing vCPU compatibility, I have some hardware workarounds in mind. One would be to emulate current code-blocking behavior. So the I/O controller can disable the CPU during screen draws. That could mean "bubbling" the Instruction register and disabling the PC.

To refine that I might take a cue from accelerator boards for older computers and snoop the I/O ranges. So my machine could process during line drawing until the code starts to update the framebuffer or sound locations so the memory in those places is not overwritten before it is used. Then it speeds the system back up by not halting the CPU. So let it operate as "mode 4" in terms of the amount of processing allowed but let it run full-speed when no sound or video updates are needed. So 3 lines are monitored and 1 line causes halting when determined that is wise.

I would have built-in line-quadding, but the strategy I'd use would be to read from memory the first line and both display and copy to a BRAM buffer, then display from the BRAM in the next 3 lines, then repeat. So that would save DMA time, leaving the DMA time during 3/4 lines for other things like more sound abilities, file I/O, etc. Eventual printing support would be nice, and there are open hardware inkjet projects.
Hans61
Posts: 102
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Possible ways of speeding up the Gigatron

Post by Hans61 »

I have all the parts there and axelb extension rebuilt. It works without problems. As you can see my PCB still has a mistake that I had to correct.
Also I did not consider that it covers the LED's. I made a new one and am waiting for delivery. If it works I will be happy to provide the PCB files.
FIFO.jpg
FIFO.jpg (276.62 KiB) Viewed 2741 times
The board gives us the maximum speed of the Gigatron with no loss of graphics. This is great. We now have the "graphics accelerator" expansions the RAM & IO Expander and the PluggyReloaded. I think that's all the hardware we need.
You can think about combining this all on one PCB, maybe with an expansion slot. Everything else, in my opinion, amounts to a solution for a few or a new computer. For which you would also need new software.
The Gigatron has very large distribution for a project of its kind I believe. Whether again such a success with a Gigatron 2 would be possible I would like to doubt. (I would participate) But I think one would annoy the many Gigatron (1) owners who are not hobbyists.
The focus should now be more on software to make the Gigatron even more attractive. I already have many ideas in my head. Unfortunately I understand the programming still too badly. I am trying to learn to walk. But I am working on it.
hnaves
Posts: 10
Joined: 25 Apr 2021, 00:57

Re: Possible ways of speeding up the Gigatron

Post by hnaves »

What a thing of beauty!
Post Reply