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: 28
Joined: 30 Sep 2020, 22:19

Possible ways of speeding up the Gigatron

Post by Sugarplum »

1. Use a faster clock rate, lower latency chips, more compact board.

2. Separating the video. This change could allow the core unit to be clocked faster than the video. I may use some type of DMA and make the controller indirection table aware in my own variation. That should keep compatibility. There could be artifacts, though there are likely hardware and software methods to prevent this. One workaround is to add HW interrupts so the sound and keyboard will work. It may be better to do all the I/O in hardware the way the Gigatron does it, but using concurrent DMA. So you keep the time relationships between the video, sound, and keyboard by doing all of that using hardware DMA.

3. Reducing colors. An 8, 4, or 2 color mode with supporting hardware would allow more processing time.

4. ISA changes. Adding a secondary control unit and ALU would sometimes allow two instructions to be done simultaneously. There could be a ROM block copy command where up to 512 bytes of ROM could be copied to RAM starting at Y:X. That would only affect initialization speed, but it would improve density. Additional instructions could make code denser and faster too. Proper shifts could make code faster, as would a proper carry flag. The above idea about the secondary CU/ALU could allow 16-bit additions in 2 cycles. Each half could add each half in a single cycle, and a fixup instruction could be added to deal with any carry (or borrow). Even a couple of 16-bit registers could be added. Redoing the opcode map to prevent chained decoding might allow for less control unit latency.

5. A couple of 16-bit memory instructions could help. There are several ways to do this. Without a more sophisticated memory controller or wait states, one could code to avoid race conditions. So if the RAM is tied up in a 16-bit operation needing 2 cycles, you can use a non-RAM instruction or a NOP immediately after the word memory instruction. You could effectively do 16-bits in a single cycle by hiding the second transfer with a concurrent instruction. Or, if designing in FPGA, you could have 2 interleaved 32K channels that could work simultaneously but are designed to work within an 8-bit wide memory map. This would also take unaligned accesses into account, though possibly with a slight skew (due to needing a pre-increment on one of the channels). Looking at some of the variable locations, I notice that the Gigatron uses a lot of unaligned memory accesses (though it is not a concern when using a true 8-bit architecture). This latter way to get 16-bit accesses would make the ROM block copy above work better. Mixed-mode instructions could work in this context, too, such as read an address and write to the next in sequence, or vice-versa. Another way to achieve this would be to use a free DMA channel to do half of the transfer.

6. A faster ALU could help when increasing clock rates. One low-hanging change is to replace the upper adder with two adders and a multiplexer. So all three adders work simultaneously, and the carry puts to appropriate high nybble on the bus. That is faster than a carry triggering an additional addition. So there would be less latency when settling after a carry. A switch is faster than an adder with the carry line enabled. A distributed ALU might also reduce latency. Logic gates could be used for logic functions.

7. Not clobbering the accumulator on every operation could also help in that you wouldn't have to reload Ac if you need it a bit later.

8. Adding a coprocessor is another possible strategy. I considered creating a VN core to run out of RAM while the Gigatron core uses the ROM. However, I am not sure how to avoid possible software races that could cause stuttering sound, visual artifacts, etc. Perhaps some memory writes could trigger a halt until Vsync. You could use other means to prevent sound and video from getting out of sync.
Last edited by Sugarplum on 18 May 2021, 01:22, edited 3 times in total.
axelb
Posts: 14
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

I designed a small add-on board which can be plugged into U37 output register if the Gigatron has a socket. It writes every fourth line into a fifo memory chip and transmits it back 4 times to the output. By this the Gigatron can be run in mode 1 to 3 still producing an image without blank lines.
Attachments
Video Repeater PCB
Video Repeater PCB
Repeater.jpg (513.07 KiB) Viewed 1243 times
at67
Posts: 384
Joined: 14 May 2018, 08:29

Re: Possible ways of speeding up the Gigatron

Post by at67 »

axelb wrote: 23 Apr 2021, 19:24 I designed a small add-on board which can be plugged into U37 output register if the Gigatron has a socket. It writes every fourth line into a fifo memory chip and transmits it back 4 times to the output. By this the Gigatron can be run in mode 1 to 3 still producing an image without blank lines.
Looks good so far, do you have a schematic to share and have you built and tested it?

Does the jumper switch between pass through, (i.e. disabling scan conversion), and 1-4 or does it switch between 1-2 and 1-4, i.e. reading first scan line and output either 2 or 4?
lb3361
Posts: 77
Joined: 17 Feb 2021, 23:07

Re: Possible ways of speeding up the Gigatron

Post by lb3361 »

To what extent can you use this fifo approach to decouple the VGA timing from the Gigatron clock? Maybe you need two fifos for this. The gigatron fills one at its leisure, while the VGA monitor gets pixels from the other one using its own clock. Then one could speed up the gigatron clock without messing up the vga. One could also increase the horizontal resolution because the gigatron can take more than one scanning to fill the fifo...

This is a 74act7200?
at67
Posts: 384
Joined: 14 May 2018, 08:29

Re: Possible ways of speeding up the Gigatron

Post by at67 »

lb3361 wrote: 24 Apr 2021, 19:51 To what extent can you use this fifo approach to decouple the VGA timing from the Gigatron clock? Maybe you need two fifos for this. The gigatron fills one at its leisure, while the VGA monitor gets pixels from the other one using its own clock. Then one could speed up the gigatron clock without messing up the vga. One could also increase the horizontal resolution because the gigatron can take more than one scanning to fill the fifo...
A dual ported FIFO that is capable of simultaneous input writes and output reads with half full and full flags already fully decouples the input and output up to the difference in input and output data rates, so you shouldn't need two FIFO's.

e.g. When outputting 1/4 the lines you effectively have 3 scanlines worth of time to do whatever it is you want to do in terms of pixel depth, colour palettes, hi-res modes, interlacing, etc.

When I designed my version of this circuit around 3 years ago, I used a separate VGA output port with it's own DAC and sync signals, (I did this because I wanted to allow for new pixel depth modes as well as different resolutions, that would fit into the bandwidth provided by a standard Gigatron and an overclocked Gigatron, using colour palette LUT's etc). I never built or tested the circuit, I just ran out of time.

Because this circuit replaces U37 and generates new sync and video signals that still route through the Gigatron's display and input circuitry, (which is very cool BTW), I fear it will not be able to work with overclocked Gigatron's without a re-write of BabelFish and probably using much faster Arduino devices to handle the higher frequency Vsync/Hsync signals.

I would guess it would be much easier and more compatible to breakout the new sync and video signals on a 2nd vga connector, (as I originally planned), and leave the the original sync signals running at their old rate using a new ROM/firmware like Marcel produced for ROMv3y.rom, so that BabelFish and other input devices don't freak out.
axelb
Posts: 14
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

This is the schematics for my repeater. Currently the "scanlines-off" jumper simply blanks the first out of 4 lines in order to create a "retro look".
I tested the board on my Gigatron and it works as expected. However, sometimes i see faint vertical lines between the pixels. I need to check if the 74HCT574 is more sensitive than the 377 or the pickup of the clock is due to an insufficient decoupling of my layout.
Attachments
gtfifo.png
gtfifo.png (66.85 KiB) Viewed 1178 times
axelb
Posts: 14
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

lb3361 wrote: 24 Apr 2021, 19:51 To what extent can you use this fifo approach to decouple the VGA timing from the Gigatron clock? Maybe you need two fifos for this. The gigatron fills one at its leisure, while the VGA monitor gets pixels from the other one using its own clock. Then one could speed up the gigatron clock without messing up the vga. One could also increase the horizontal resolution because the gigatron can take more than one scanning to fill the fifo...

This is a 74act7200?
So far i tested the IDT7201-15, IDT7202-25, and QS7204-15. The 7201 produces artifacts probably since all four lines are actually written to the FIFO although i´m using only the first one for the retransmit. My 02 and 04 versions worked fine.
Hans61
Posts: 29
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Possible ways of speeding up the Gigatron

Post by Hans61 »

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.
axelb
Posts: 14
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

[/quote

Because this circuit replaces U37 and generates new sync and video signals that still route through the Gigatron's display and input circuitry, (which is very cool BTW), I fear it will not be able to work with overclocked Gigatron's without a re-write of BabelFish and probably using much faster Arduino devices to handle the higher frequency Vsync/Hsync signals.

I would guess it would be much easier and more compatible to breakout the new sync and video signals on a 2nd vga connector, (as I originally planned), and leave the the original sync signals running at their old rate using a new ROM/firmware like Marcel produced for ROMv3y.rom, so that BabelFish and other input devices don't freak out.
[/quote]

It would be great if we could use such a device together with a 12.5 MHz Gigatron...

My current state is here. In the meantime I found out that by writing only the first line into the FIFO ( i.e. connecting my U38, pin 9 to U34 pin2 ) my 7201 also worked fine.
Attachments
25AD3ECC-C4C8-4FA9-8CE3-A84587630714.jpeg
25AD3ECC-C4C8-4FA9-8CE3-A84587630714.jpeg (1.44 MiB) Viewed 1152 times
axelb
Posts: 14
Joined: 07 Jan 2021, 06:27

Re: Possible ways of speeding up the Gigatron

Post by axelb »

errata: connection from U3B pin 9 to U4A pin 1 or 2, sorry
Post Reply