High resolution mode?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk »

I like to confirm the stability at 10 MHz as 60 ns is a huge chunk to chop off the timing budget. My concern is if the high-nibble adder can always keep up in combination with all addressing mode changes. Almost nothing will immediately fail if it doesn't. A sound sample may be off, or Mandelbrot show wrong pixels. Take this snippet from vCPU in the ADDW instruction:

Code: Select all

              03a6 0500  ld   [x]
              03a7 8119  adda [$19]
The RAM addressing mode changes and signal EL swings from low to high during the second instruction by the 2.2k pull-up resistor in R4. This swing is slow. From there the propagation goes through RAM, logic unit, low adder and high adder and finally to AC. This is quite a long path. For many instruction combinations the RAM already happens to see the correct address and we don't observe a problem. The instructions immediately following are easier, because now the EL swing is from high to low by diode D11, which is much faster.

Code: Select all

              03a8 111d  ld   [$1d],x
              03a9 8500  adda [x]
We should really have a simple stress test for this instead of making eye diagrams. Yet, I think we beat the data sheets because we don't operate at a large temperature range.

But now my little a-ha moment: for palette 'c' (and 'b') we can reuse the resistors that are already on the board:

palette-c.gif
palette-c.gif (37.7 KiB) Viewed 8185 times

Well, I have probably mixed up something subtle and created 'b' instead, but I hope the idea is clear (and not flawed by itself).
gesari
Posts: 32
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari »

Well, I can redo the board with this palette:
videodoubler3.gif
videodoubler3.gif (19.76 KiB) Viewed 8177 times
videodoubler3_lay.gif
videodoubler3_lay.gif (12.87 KiB) Viewed 8177 times
BTW, I was also not very happy with the many 157s needed for the selectable mode...
Maybe It would be a good idea to test the circuit on a breadboard before making a PCB...
gesari
Posts: 32
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari »

And about the delays, these also depend on the data being added. The worst case is when the carry propagates from low adder to high, for instance for a $ff + $01 or $00 - 0.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk »

It's a neat hack. I'm almost tempted to try out this mod in dead bug style, without any PCB. The pin layout between the 2 chips match well for this. Or you can have 10 or so made for ~5 dollars excl. shipping at JLCPCB. For a smaller board, you can win some space by overlapping the "socket" with one of the IC's. As the socket can be made out of 2 rows of headers. It will still have a volume conflict with the prototype SPI expander. [Edit: Perhaps make it a wider board that extends above the video resistors?] I would also rotate U2 by 180 degrees so it faces left like all other ICs.

The bit assignment needs some extra thought. Low resolution is like this:

Code: Select all

bit 76543210
    VH------ sync
    --BBGGRR big pixel
[Indeed: the Gigatron has the RGB order reversed compared to common conventions. It was way too late to change it once we noticed this, with kits already out there...]

High resolution could be like this:

Code: Select all

bit 76543210
    VH------ sync
    --b-g-r- left pixel
    ---b-g-r right pixel
But then with 'r' being #aa0055, 'g' #55aa00 and 'b' #0055aa (web notation).

The idea of interleaving the pixels is two-fold:
  • Color components from low resolution images map to related hues when displayed in high resolution
  • In software it's easier to shift-left by 1 bit than to shift-left by 3 bits
I expect the colors will come out in this order, from low to high:
palette-8c.png
palette-8c.png (350 Bytes) Viewed 8154 times

I did left/right pixel in big-endian bit order, but it can just as easy be reversed. I see no strong compelling reason for either order yet.

modded.gif
modded.gif (53.25 KiB) Viewed 8163 times


Or directly wired, perhaps like this. It's a lot of wires for a small space...

deadbug.png
deadbug.png (105.61 KiB) Viewed 8163 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk »

One important detail is that the bit mapping for OUT is optimised for the PCB layout. So D0 isn't receiving ALU0, etc. All our diagrams above are therefore wrong on this aspect. The lower pins are in reverse:

Screenshot 2019-04-22 at 19.06.32.png
Screenshot 2019-04-22 at 19.06.32.png (108.89 KiB) Viewed 8140 times

Of course I found out with the multimeter only after building a dead bug version. I didn't want to spend the extra time to get it right, and consequently the colours are completely off from intended. The clock wave isn't square yet either. With those two caveats in mind, the concept kind of works already:

IMG_5188.jpeg
IMG_5188.jpeg (391.22 KiB) Viewed 8138 times

It's a bit difficult to see due to the uneven size of the pixels. Also, there appear razor thin dark vertical lines between the pixel pairs. These must be some kind of timing glitches or transient behaviour of the '157, and I don't like them. These lines even show when everything is of the same opaque color. For example, in the photo the background is all in color value 63 (white). BTW, I used a 74LS377 and a 74LS157 here for the experiment. I need to let this rest for a couple of weeks. I have busy times approaching, and after that I will hopefully be able to shift back my attention to the SD card project.
gesari
Posts: 32
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari »

I think the vertical lines are due to the propagation delay of the register. When clock changes to high the multiplexer switches first, showing a wrong value before new valid data comes out a few nanoseconds later. Also the multiplexer is built around AND/OR gates, and there are transients when the selection line changes even with the same value at both inputs (glitches).
In an old VGA monitor these glitches would be probably unnoticed, but in a modern 1080 line monitor each horizontal pixel takes about 13ns, more or less the same value as the propagation delays, and it is capable of sampling the glitches. This will explain the "razor thin" (1 monitor pixel) vertical lines.

This is bad news for the video doubler design, as it would require a 3-bit register with a 12.5MHz clock at the multiplexer output in order to avoid these lines...

Thanks a lot for checking it.
gesari
Posts: 32
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari »

Hi,
This time I tried a different version with registers at the output:
vd2.gif
vd2.gif (62.12 KiB) Viewed 8053 times
The XOR gates double the clock rate for U2 flipflops. The OR gate may be replaced by 2 diodes and a resistor, but only if chips are 74HCs, not true TTLs like those in the prototype. The Gigatron clock is a square wave.
Another snapshot with the video doubler attached to the Gigatron.
vd2.jpg
vd2.jpg (400.89 KiB) Viewed 8053 times
and a closer look to the screen:
vd3.jpg
vd3.jpg (319.63 KiB) Viewed 8053 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk »

Lovely and congratulations!
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk »

gesari wrote: 23 Apr 2019, 13:45 I think the vertical lines are due to the propagation delay of the register. When clock changes to high the multiplexer switches first, showing a wrong value before new valid data comes out a few nanoseconds later. Also the multiplexer is built around AND/OR gates, and there are transients when the selection line changes even with the same value at both inputs (glitches).
In an old VGA monitor these glitches would be probably unnoticed, but in a modern 1080 line monitor each horizontal pixel takes about 13ns, more or less the same value as the propagation delays, and it is capable of sampling the glitches. This will explain the "razor thin" (1 monitor pixel) vertical lines.

This is bad news for the video doubler design, as it would require a 3-bit register with a 12.5MHz clock at the multiplexer output in order to avoid these lines...
In retrospect, it's rather obvious the vertical stripes must be present in the original proposal by considering the logic diagram alone. Even though you can't use these diagrams to derive timing effects, here it does predict that there will be black stripes on the L to H clock transitions:

When toggling the select input S, there will be a different set of AND gates feeding data into the OR layer. Internally the '157 creates an inverted S signal. That introduces a gate delay and asymmetric switching between the inputs I0x and I1x.

74157.png
74157.png (148.01 KiB) Viewed 7937 times

When we toggle S from L to H at the start of the clock cycle, the new AND gates switch ON briefly after the previous ones switch OFF. This gap means that the OR layer momentarily receives no high inputs, and will briefly emit a low voltage which renders as black. When later in the clock cycle we switch S from H to L, the order of switching between AND gates is reversed and there is some overlap in their activity. We then see no transient effect at all if the pixel colors are the same. We will still see fake (brighter) colors if the two adjacent pixel values are different. So it all defeats the purpose: this can't work very well. [Come to think of it: the VGA monitor works as a pretty nice oscilloscope as it visualises the IC's internals so nicely.]

Indeed, a flip-flop at the output stage is the solid solution. Too bad it requires so many extra chips. We can cheat and try to mitigate these effects with fast logic instead (74F). Perhaps for the OUT register as well because it switches at the same time.

BTW: There is a similar glitch lurking under the surface in the Gigatron's conditional branching design. In this case it goes through the '153 multiplexers of the logic unit: https://github.com/kervinck/gigatron-rom/issues/78 We might have been a bit lucky with those.
tocksin
Posts: 25
Joined: 22 Jun 2018, 14:12

Re: High resolution mode?

Post by tocksin »

This is all amazing work guys. I love when it comes together. Seems like the inverter in the '157 is causing the problem; however, we already have the inverse of this signal - the opposite clock signal. So we really only need the AND/OR logic to do the multiplexing. With 6 AND and 3 OR gates, you'd only need a '32 for the ORs, but unfortunately you'd need either two '21s for the AND gates, or you could use a '808 hex AND gate. So two chips is a possibility.

I'm sure there are other alternatives like you could use two buffers with tri-state outputs and tie the outputs together for each output. Each chip would get a different clock phase to its enable. I think that would still be a two chip solution. I feel like there should be a 1-chip solution if you use both clock phases.
Post Reply