High resolution mode?

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

Re: High resolution mode?

Post by marcelk » 21 Apr 2019, 16:33

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 212 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: 29
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari » 21 Apr 2019, 20:52

Well, I can redo the board with this palette:
videodoubler3.gif
videodoubler3.gif (19.76 KiB) Viewed 204 times
videodoubler3_lay.gif
videodoubler3_lay.gif (12.87 KiB) Viewed 204 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: 29
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari » 21 Apr 2019, 21:13

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: 252
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk » 22 Apr 2019, 10:33

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 181 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 190 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 190 times

User avatar
marcelk
Posts: 252
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk » 22 Apr 2019, 17:10

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 167 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 165 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: 29
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari » 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...

Thanks a lot for checking it.

gesari
Posts: 29
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari » 11 May 2019, 10:35

Hi,
This time I tried a different version with registers at the output:
vd2.gif
vd2.gif (62.12 KiB) Viewed 79 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 79 times
and a closer look to the screen:
vd3.jpg
vd3.jpg (319.63 KiB) Viewed 79 times

User avatar
marcelk
Posts: 252
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk » 11 May 2019, 20:42

Lovely and congratulations!

Post Reply