High resolution mode?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
gesari
Posts: 29
Joined: 11 Apr 2019, 07:15
Location: Valladolid, Spain
Contact:

Re: High resolution mode?

Post by gesari » 19 Apr 2019, 13:40

Could you check if the resistor does the trick? I got no equipment here to test it, and simulation is not always like reality...

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

Re: High resolution mode?

Post by marcelk » 19 Apr 2019, 15:02

I don't understand the problem...

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

Re: High resolution mode?

Post by gesari » 20 Apr 2019, 09:22

Isn't a problem. I tough we can make the clock waveform more square if we put a resistor in parallel with C2 instead of replacing U1 by an HC04. But this is still untested. I simulated the oscillator using Spice and it seems to work, but the circuit I simulated is quite different from the real one, so I'm not much confident about it.
I'm coming back from vacation next week and then I can build a replica of the oscillator and test it, so don't worry about it, it isn't urgent at all.

Best Regards

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

Re: High resolution mode?

Post by gesari » 20 Apr 2019, 15:26

Meanwhile I worked a little on the original tocksin idea, and I think a convenient way to change the video mode to 320 pixels per line is to solder a socket for U37 (the output register) and then instead of plugging on it an HCT377 we plug this little board:
videodoubler_sch.gif
videodoubler_sch.gif (33.88 KiB) Viewed 132 times
videodoubler_lay.gif
videodoubler_lay.gif (40.95 KiB) Viewed 132 times
If this works then the idea can be developed further. And, of course, we also need to double the RAM in order to get 240 lines...

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

Re: High resolution mode?

Post by marcelk » 20 Apr 2019, 22:18

One thing to address is the 8 color palette. I believe it looks bad, like Teletext. Compare these two:

rrggbb-Baboon-160x120.png
160x120 in 64 colors RRGGBB (native Gigatron)
rrggbb-Baboon-160x120.png (10.98 KiB) Viewed 125 times
rgb-Baboon-320x120.png
320x120 in 8 color RGB (simplest high-resolution)
rgb-Baboon-320x120.png (13.66 KiB) Viewed 125 times

Ugh, the image looks much worse! Maybe it is possible to avoid fully saturated colors by some clever recombination of the available bits. The 16-color RGBI palette is already a huge step up. RGBI can be mixed with resistors and diodes. With one additional bit per pixel, it provides much softer colors:

rgbi-Baboon-320x120.png
320x120 in 16 color RGBI
rgbi-Baboon-320x120.png (12.08 KiB) Viewed 125 times

But we don't have enough bits for two independent 4-bit RGBI pixels. So we need a trick. Many monitors appear to accept a combined (XOR'red) vSync/hSync signal on the hSync line (for support of composite sync). If this is true, we can modify the software and have 7 bits for the color info. This is the first step.

This then opens up the possibility to assign, for example, 3 bits of RGB to each of the two pixels, and 1 shared bit for intensity. That gives many gradients. But it's not a too great choice, because contrast is important and in this arrangement we can't have black and white in the same pixel pair.

Sharing the blue component in pixel pairs might work better instead. The eye is least sensitive to blue after all. We still can't have black and white together, but blue and white come closer than grey and white.

The classic Baboon/Mandrill image is a good test for this concept. I have no idea how to instruct ImageMagick to convert under such pairwise constraints. The best I can think of is generate RGBI first, and then perform a pairwise collapse of the blue bits by logical-AND (or logical-OR). There are probably better methods based on error diffusion, but this is simple. Here's what it then becomes in 7-bits per 2 pixels:

rgbx-Baboon-320x120.png
320x120 in 16 color RGBI with shared blue
rgbx-Baboon-320x120.png (11.44 KiB) Viewed 125 times

Pretty close to the original. Perhaps slightly more yellowish (the logical-OR version looks worse). It even looks acceptable compared to the 64 color version in high resolution:

rrggbb-Baboon-320x120.png
320x120 in 64 colors
rrggbb-Baboon-320x120.png (17.35 KiB) Viewed 125 times

Of course this completely ignores that the two sync signals are shared by the game controller. So this isn't a full story. And regardless of the color palette, programming individual pixels becomes a complex matter in high-resolution. It's likely easiest to always treat pixel pairs as fundamental units. High-resolution character rendering becomes a bit of a puzzle, as the font is stored as small bitmaps in ROM.

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

Re: High resolution mode?

Post by gesari » 21 Apr 2019, 08:08

I think the main application for a 3-bit, 320 pixels per line, mode would be text because it will allow 52 characters per line.

The above circuit is very simple and doesn't allow for mode switching, but this can also be done with more multiplexing and a control bit. Then the video mode could be changed on a video line basis. (I think the Apple II did some like this with its graphics modes)

And there is still the question about where to store the control bit. I think the RGB levels do not mater during HSYNC or VSYNC pulses, so, for instance the OUT0 bit can be latched when HSYNC goes low and this bit, along with the clock, will control the multiplexers.

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

Re: High resolution mode?

Post by marcelk » 21 Apr 2019, 09:23

You can use one of the 4 high XOUT bits as a control bit. They were intended as general purpose output (the LEDs are just an indicator).

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

Re: High resolution mode?

Post by gesari » 21 Apr 2019, 09:55

Yes, an XOUT bit could be used, but this means to connect a line to another socket.
The circuit with the HSYNC mode latching could be:
videodoubler2_sch.gif
videodoubler2_sch.gif (65.65 KiB) Viewed 97 times
Here the bit storage is dynamic (C4: a 1-bit DRAM :)

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

Re: High resolution mode?

Post by marcelk » 21 Apr 2019, 13:03

Personally I would stick to one mode and avoid the component increase.

Another tack is simply to move the clock speed up to 8 MHz with help of some 74F logic and/or different pull-ups as Ken has done. We can then burst 213x120 pixels: a 9X reduction of the standard 1920x1080 resolution for 16:9 LCD screens. That gives 35 characters without compromised colors. It's not even completely cheating as 55 ns SRAM was on the market in the late 1970s (I didn't know that before). I forgot I had already played with this mode two years ago:

IMG_2342.jpeg
213x120
IMG_2342.jpeg (223.89 KiB) Viewed 95 times

Approaching 10 MHz we can burst 256 full color pixels, or 42 characters, still without complicating the circuit and software.

From there we can add the pixel doubling trick by accepting the multiplexer. Maybe drop the clock a bit for a 50% duty cycle. But the aesthetics of the primary 8-color palette is holding me back. And admittedly, the 7-bit scheme is also convoluted.

But even with just 3-bit colors, a diode/resistor matrix can create color combinations that are easier on the eye. We can experiment with linear combinations. The obvious candidates are:

Code: Select all

       RR GG BB (default)
       -- -- --
bit 0: ff 00 00
bit 1: 00 ff 00
bit 2: 00 00 ff
palette-8.png
palette-8.png (350 Bytes) Viewed 95 times

Code: Select all

       RR GG BB (palette a)
       -- -- --
bit 0: 7f 7f 00
bit 1: 00 7f 7f
bit 2: 7f 00 7f
palette-8a.png
palette-8a.png (350 Bytes) Viewed 95 times

Code: Select all

       RR GG BB (palette b)
       -- -- --
bit 0: aa 55 00
bit 1: 00 aa 55
bit 2: 55 00 aa
palette-8b.png
palette-8b.png (350 Bytes) Viewed 95 times

Code: Select all

       RR GG BB (palette c)
       -- -- --
bit 0: aa 00 55
bit 1: 55 aa 00
bit 2: 00 55 aa
palette-8c.png
palette-8c.png (350 Bytes) Viewed 95 times
overview.png
overview.png (101.05 KiB) Viewed 95 times

Based on this test image, my ranking would be: c > a > b >> default

monsonite
Posts: 36
Joined: 17 May 2018, 07:17

Re: High resolution mode?

Post by monsonite » 21 Apr 2019, 15:15

Marcel,

I managed to reach 10MHz with the standard 74HCT without the use of any 74F series. Hi-res mode might only involve a crystal change.

Post Reply