Another week of humiliation
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...