High resolution mode?
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: High resolution mode?
Could you check if the resistor does the trick? I got no equipment here to test it, and simulation is not always like reality...
Re: High resolution mode?
I don't understand the problem...
Re: High resolution mode?
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
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
Re: High resolution mode?
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:
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...Re: High resolution mode?
One thing to address is the 8 color palette. I believe it looks bad, like Teletext. Compare these two:
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:
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:
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:
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.
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:
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:
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:
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.
Re: High resolution mode?
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.
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.
Re: High resolution mode?
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).
Re: High resolution mode?
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: Here the bit storage is dynamic (C4: a 1-bit DRAM
The circuit with the HSYNC mode latching could be: Here the bit storage is dynamic (C4: a 1-bit DRAM
Re: High resolution mode?
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:
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:
Based on this test image, my ranking would be: c > a > b >> default
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:
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
Code: Select all
RR GG BB (palette a)
-- -- --
bit 0: 7f 7f 00
bit 1: 00 7f 7f
bit 2: 7f 00 7f
Code: Select all
RR GG BB (palette b)
-- -- --
bit 0: aa 55 00
bit 1: 00 aa 55
bit 2: 55 00 aa
Code: Select all
RR GG BB (palette c)
-- -- --
bit 0: aa 00 55
bit 1: 55 aa 00
bit 2: 00 55 aa
Based on this test image, my ranking would be: c > a > b >> default
Re: High resolution mode?
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.
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.