Gigatron Clone Ideas

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
alastair
Posts: 47
Joined: 10 Oct 2019, 14:28

Re: Gigatron Clone Ideas

Post by alastair »

Sugarplum wrote: 07 Jun 2022, 03:21 take 2 Gigatrons, use a 2-phase clock, and connect them at the memory.
The memory would then become a bottleneck. One Gigatron would have to halt while the other execute, slowing each to half the speed. You would be duplicating the registers and ALU with no real benefit here. There would also be shared state in the zero page that would need a significant firmware update to deal with.

Talking of memory. I finally made some progress on debugging the new design. After fixing the boneheaded schematic errors the machine was getting stuck in the entropy loop. I couldn't figure it out and had to write my own custom firmware to investigate. It took another week to finally figure it out! I have a negative write recovery time on the SRAM. It's only around -4ns, but that is enough to perform a second write to the faster RAM I'm using.

The Gigatron avoids this issue by having a single OR-gate between the write enable and clock (U16A). The ~WE signal is one of the first to change from low to high and makes sure the write recovery (address change) happens after the write enable has ended. The ~WE I'm using goes through the GAL and is happening slightly after the address changes. This causes two writes to happen within a few nano seconds.

There's a few other things that look tight, so I need to rethink things. I will probably need a third clock phase to make it all work. That may take some time... but at least I can start making progress again.
bmwtcu
Posts: 122
Joined: 01 Nov 2018, 12:02

Re: Gigatron Clone Ideas

Post by bmwtcu »

alastair wrote: 08 Jun 2022, 19:40 The Gigatron avoids this issue by having a single OR-gate between the write enable and clock (U16A). The ~WE signal is one of the first to change from low to high and makes sure the write recovery (address change) happens after the write enable has ended. The ~WE I'm using goes through the GAL and is happening slightly after the address changes. This causes two writes to happen within a few nano seconds.
Without the benefit of your schematic/board file, I'll ask some potentially dumb questions out of sheer curiosity. Do you have an unused input pin on the same GAL to replicate the same mechanism? I'm guessing you will have to bodge wire the 6.25MHz CLK1 line, which could be less than ideal depending on how far you have to go. Basically the OR gate delays active low write assertion until the falling edge of CLK1, and forces deassertion of the write on the rising edge of CLK1 even if WE_B is still low . The active low write only effectively happens when both WE_B AND (De Morgan's Law) the clock are low.
alastair
Posts: 47
Joined: 10 Oct 2019, 14:28

Re: Gigatron Clone Ideas

Post by alastair »

bmwtcu wrote: 10 Jun 2022, 22:12 Do you have an unused input pin on the same GAL to replicate the same mechanism?
That's basically what I have now, but any path through the GAL is more than just a single gate. It does look like I've solved that issue though. I'm dividing down a 25.175 MHz to 6.25ish using a two-stage ring counter so I have 4 clock phases. Rather than OR-ing CLK1, I'm OR-ing the phase 90-degrees behind. This puts the ~WE pulse in the center of the cycle and avoids the ends where things can change. I don't think this would prevent overclocking either, since the store operation isn't waiting for the ALU to calculate anything and there's plenty of time to perform the write (you miss the last 1/4 of the cycle).

I'm not out of the woods yet though :cry: I've got to page 4 and running the vCPU. It's kind of stuck and jumping all over the RAM. The vCPU is basically crashing and not able to execute. I suspect another timing glitch somewhere, but I can't see it. I might need to spin another custom ROM to figure it out... it's going to be another fun weekend :lol:
Sugarplum
Posts: 66
Joined: 30 Sep 2020, 22:19

Re: Gigatron Clone Ideas

Post by Sugarplum »

My idea on that would be to put the 2 Gigatrons on opposing clocks and make the RAM only available to the active one. So concurrent DMA where 1 works half the time and the other works half the time. So they each get to use the memory during their turn. So round-robin arbitration. I can think of different problems
alastair
Posts: 47
Joined: 10 Oct 2019, 14:28

Re: Gigatron Clone Ideas

Post by alastair »

Another week of humiliation :lol:

One apparent optimization of the Gigatron design is replacing U32 and U33 (zero page multiplexer) with a pull-down resistor. The Y register is changed to a tristate latch and the EH signal is inverted and used as the ~OE. The pull-down will select the zero page without the extra two chips. The ~YL signal is OR-ed with the clock in the GAL to act as the Y register clock.

In fact I wasn't the only person to spot this optimization. A proposed Microtron design had the same feature...
steve wrote: 22 Jul 2020, 19:16 **Removal 2:1 multiplexers for Y**

Since high byte of RAM address can be 0 or Y, the same effect of the double 2:1 multiplexers can be obtained using a 374 chip for Y register in combination with pull-down resistors, simply routing the multiplexer selection to Y output enable

This change should be fully usable also with the "standard" gigatron, saving 2 chips on the total count.
However, I did observe some glitches with the Y clock pulse. The 16V8 decoder GAL doesn't quite have enough outputs, so I also use one half of the 139 decoder to generate the ~XL, ~YL, and IX signals. The GAL enables the decoder and then the decoder selects one of four outputs based on IR2 and IR3. The trouble here is two layers of logic with the same starting point (IR). When IR updates it propagates through the decoder before the GAL updates the enable line to disable it. This results in a potential 4-6 ns glitch that can latch data in the Y register when it shouldn't.

Code: Select all

     __  _______________  ______
IR     \/               \/
2..3 __/\_______________/\______

     ____  ________________  ___
139      \/                \/
~E   ____/\________________/\___

     ____________________  _  __
Y-reg                    \/ \/
CP   ____________________/\_/\__
One (horrible) solution to this is using a slower chip for the decoder and/or a faster GAL. The slower decoder solves the glitch problem, but becomes too slow to reliably latch the Y register before the input changes. This did seem to progress things a little more and I was getting video output, but with very unstable timing. I tried some better solutions to the glitch issue, but still no luck.

The vCPU is running... but it is "stuck". I spent the rest of the week checking every timing scenario and it all looks good. The conclusion was some type of logic issue. I went through all the logic (yet again) and did spot one thing that I didn't think would be an issue. The Branch conditions can select a zero page value as the jump location. My logic hadn't accounted for this, so I made sure to select "D" rather than "X" and the zero page by disabling the Y output during jumps. Obviously, this wouldn't apply to the long jump that needs to use the Y register.

But wait...

Code: Select all

              030f e11e  jmp  y,[$1e]     ;Return to caller
There is a long jump that uses the zero page. I can't disable the Y register since I need to load the upper byte of PC. I have to disable the Y register in order to select the zero page. Contradiction!

I really didn't expect this would be a thing and it represents a fatal design flaw due to what I thought was an easy "win" in optimizing the design.

To be continued...
Lerc
Posts: 15
Joined: 21 May 2020, 19:38

Re: Gigatron Clone Ideas

Post by Lerc »

I did a quick scan of The V5a ROM to see what Instructions were used

https://gist.github.com/Lerc/2af74fde9f ... 0f22950622

It found 6 instances of

Code: Select all

jmp [Imm]           e1xx    6
It wouldn't be the end of the world to break backwards compatibility and to break the jmps into multiple (2) instructions. The ROMs could easily be updated.
at67
Posts: 486
Joined: 14 May 2018, 08:29

Re: Gigatron Clone Ideas

Post by at67 »

All six cases are used to return from vCPU code into the current video scanline handler, unfortunately you can't just replace:

Code: Select all

ld(hi('vBlankStart'),Y)
jmp(Y,[vReturn])
ld(0)
with:

Code: Select all

ld(hi('vBlankStart'),Y)
ld([vReturn])
jmp(Y,AC)
ld(0)
As this will break timing of the display by 1 cycle; I'm not saying it's impossible to re-write the video display bit banger, but it's far from trivial or easy.
alastair
Posts: 47
Joined: 10 Oct 2019, 14:28

Re: Gigatron Clone Ideas

Post by alastair »

Lerc wrote: 21 Jun 2022, 22:13 I did a quick scan of The V5a ROM to see what Instructions were used
That's really helpful. I also noticed 6 instances of "bra [Imm]". Those I could handle, but not the "jmp [Imm]". I agree with @at67 though. Breaking compatibility is a rabbit hole I don't want to go down.

I just needed to add one additional buffer chip. I'm still using the pull-down trick, but on a buffer just for the RAM address bus. I don't need to tristate any of the registers now, so I've switched to registers with clock enable (74HC377 as used by the Gigatron). This solves a lot of the timing glitch issues with generating my own register-specific clock pulses. Modding the Rev.1 board with these changes was going to be a lot of work, so I just ordered a new Rev.2 board. JLC turned it around super fast and it shipped out yesterday.
alastair
Posts: 47
Joined: 10 Oct 2019, 14:28

Re: Gigatron Clone Ideas

Post by alastair »

The board came in Friday but I was still waiting on a couple of components. They just arrived and it worked first time 8-)
novatron-lives.jpg
novatron-lives.jpg (520.42 KiB) Viewed 70 times
CRT via RF modulator for added effect. I don't have a Pluggy installed yet or a Famicom controller to interact with it. Started with the V1 ROM and will progress with testing from there.

Update: I'm using F-series logic and it runs fine at 12.5MHz. You usually get much better mileage out of the ROMs and the 120ns ERPOM seems to be happy running on an 80ns cycle (the RAM is 20ns). The VGA to RF adapter is happy converting the 2x VGA signal, so the display comes up normally except for a super fast cursor.
bmwtcu
Posts: 122
Joined: 01 Nov 2018, 12:02

Re: Gigatron Clone Ideas

Post by bmwtcu »

Congrats! I'm curious... what make/model RF modulator?
Post Reply