[Aquarius] information about correct YPbPr colours from the palette

[nitrofurano]

do anyone know which are the correct colours (YPbPr colourspace) from the Aquarius palette, for completing http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes ?

[jaybird3rd]

The best information I was able to find comes from the technical specifications for the color encoder chip used in the Aquarius, the TEA1002. Here is the relevant page:



This specifies the color outputs as luminance, chroma phase, and chroma amplitude values, but I'm afraid I don't know how to derive the equivalent YPbPr values.

 

Another option would be to use the YPbPr values for another system which uses the same color encoder, if someone else has already found them. It would almost certainly be better than the default palette used by Aquarius emulators; the MESS palette in particular is terribly inaccurate.

 

Here's the entire document (in PDF format), in case you need it:

 

tea1002.pdf

[nitrofurano]

thanks!

[nitrofurano]

i’m commenting here: https://en.wikipedia.org/wiki/Talk:List_of_8-bit_computer_hardware_palettes

[nitrofurano]

btw, jaybird3rd, are you still able to make 720x480 (or 720x576) frame grabs, so we could, in the meanwhile, pick their rgb colours, and this information could be a very valuable complementary and helping information for seeking the exact colours? i don’t know if some snippet (like those i were making on Boriel’s ZX-Basic Compiler, or something running on Aquarius Basic interpreter) is needed for this process

[jaybird3rd]

I'm currently setting up a new Windows workstation which will be equipped with a TV tuner card, so as soon as that's done, I'll see what I can do about taking a clean screen capture for you. I'm sure there's a color bar generator somewhere in the Virtual Aquarius archives that I can use to get all the colors at once.

[nitrofurano]

thanks!

[nitrofurano]

btw, @jaybird3d, it seems MESS emulator is now officially at GitHub, and the aquarius.c video driver is at https://github.com/mamedev/mame/blob/master/src/mess/video/aquarius.c - perhaps you might want to help somehow there? would be really amazing! i'm also discussing it at http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=95021Post95021 - man, thanks a lot in advance!!!!

Edited December 9, 2014 by nitrofurano

[jaybird3rd]

Thanks for pursuing this! I now have the workstation with the TV tuner that I mentioned earlier, so it's just a matter of getting the Aquarius hooked up to it and taking some good screen captures. That's probably the easiest way to get a more accurate Aquarius color palette.

[Bruce Abbott]

I am also interested in this because I am trying to make an analog RGB output circuit for the Aquarius. The circuit will have to translate the 4 bit digital RGB-INV signals into the correct analog RGB values. Unfortunately this is not quite as easy as I thought it would be, as unlike RGBI the colors have subtle variations that a simple digital circuit cannot produce. Therefore I will probably need a color lookup table, programmed with different RGB values for each color - and I need to know what those values are!

Current Aquarius emulators do not have accurate color palettes. Virtual Aquarius is much closer to reality than Mess, but still not perfect (eg. color #15 is dark gray instead of black). I don't have a PC video capture device, so the only way I could get the real colors into my computer was to photograph the TV screen (which introduces another source of color distortion). The image below compares the colors produced by Mess and Virtual Aquarius to a photo of my TV displaying composite video from an NTSC Aquarius.



In an attempt to calculate RGB equivalents of the TEA1002's composite output, I input the numbers from the datasheet into a spreadsheet (attached), applied YUV to RGB conversion, and used the results to set fill colors in Corel Photo-paint. The result was surprisingly close to my real Aquarius!



It will be interesting to see what video captured into a PC looks like, and how it compares to my numbers...

TEA1002_color_calc.zip

Edited August 17, 2017 by Bruce Abbott

[jaybird3rd]

Excellent! Thanks very much for figuring out the color palette, and I'm excited to know that you're working on a new video output circuit, too! If it would still be helpful, I'll try to have some PC captures posted this weekend.

[Bruce Abbott]

I calculated the numbers required to create 8 level analog RGB and created a logic circuit with WinCPUL, intending to program it into a GAL22V10. Unfortunately that plan came to a screaming halt yesterday, when I found out that my TL866CS programmer can't program that part!

So I have decided to try a building the converter with standard logic gates. To get the ball rolling I whipped up a circuit that just inverts the order of colors 8~15 to produce standard RGBI, then converts it to analog RGB using a normal resistor-diode matrix. This should produce colors that are similar to a Sinclair Spectrum, IBM CGA etc.

Here is a photo of the results displayed on an old NEC Multisync monitor. Even though some colors are a bit off, it clearly shows the improved sharpness and lack of color bleeding compared to composite. Next step is to figure out how to fine-tune the colors without adding too many extra parts...

Edited August 17, 2017 by Bruce Abbott

[jaybird3rd]

Congratulations! I would have been happy with just composite output, but RGB is even better! We're fortunate that the Aquarius already generates binary color data internally for the TEA1002; this makes it much easier to create new video outputs. I wonder if the RGB output from your circuit can be converted to VGA through an arcade converter board like this one; if it can, it would be relatively inexpensive and easy to use a modern computer monitor with the Aquarius. Exciting stuff!

 

Just out of curiosity, was the RGB output in the leftmost screenshot generated directly from your Aquarius? If so, it looks as if you made some changes to the character set: the lowercase "L" in the word "color" is a different shape than on the stock Aquarius.

[Bruce Abbott]

the lowercase "L" in the word "color" is a different shape than on the stock Aquarius.

You have a sharp eye!

 

It's supposed to be the stock character set, but a pixel might have temporarily gone missing somewhere in here,

Edited August 17, 2017 by Bruce Abbott

[jaybird3rd]

Wow, you've installed a RAM in place of the character generator ROM! I'm very curious to know more about the support circuitry you've added. How are you controlling access to the RAM? It looks as if you're mapping it into the Aquarius's address space, but I can't quite make out the location.

 

I've been thinking for a long time about the possibilities of replacing the CG ROM with a RAM that can be reprogrammed by the user for new character graphics; my early experiments with this idea (which I called the "SuperFont" upgrade) are documented here. Those experiments are what finally produced an accurate copy of the Aquarius character set, which is something we didn't have before. I've been too busy to pursue it further, but as it happens, I've been thinking recently of picking that idea up again. I'd like to have at least a working prototype installed in my own system so I can add support for it to my Aquarius games; I'll be working on the first of these next year.

[Bruce Abbott]

Wow, you've installed a RAM in place of the character generator ROM! I'm very curious to know more about the support circuitry you've added. How are you controlling access to the RAM? It looks as if you're mapping it into the Aquarius's address space, but I can't quite make out the location.

The character generator RAM is mapped over the BASIC ROM, but only for writing. I replaced the BASIC ROM with an EPROM and wired its /OE pin to CPU /RD, so that writing won't activate it. The CG RAM being write-only means I can't read character patterns out of the original ROM, but there wasn't enough room to fit both the RAM and ROM in a socket under the keyboard anyway. Of course the problem then was how to get the patterns into RAM when there is no ROM to read them from!

 

So I extended the BASIC ROM to 12k and put the character patterns into the last 2k, leaving 2k free for adding extra code. I then modified the system so that it copies the patterns into CG RAM at startup. I also removed the restriction against poking below $3000, so to modify any character pattern from BASIC I can just POKE into the ROM area. The original patterns can be restored by peeking ROM locations at $2800~$2FFF and then poking the values back to RAM at the same location. Alternatively I can restore the whole 2k in one go by calling the initialization routine at $2000, or if the characters are messed up so bad that I can't see what I am typing I just reboot and hit Ctrl-C.

 

Though I designed the circuit for a 2K static RAM I am actually using a 32k chip, and the BASIC ROM is a 64k chip. Seems a pity to waste the extra memory, so I am thinking about bank switching using an I/O port, perhaps also making the CG RAM readable and/or being able to switch between it and the original ROM. I even thought of paging the CG RAM in sync with the display to get 1024 programmable characters - for a true bitmap screen! However I think one of the charms of the Aquarius is seeing what it can do with fixed character graphics, and I don't really want to turn it into a Spectrum.

 

For your interest I have attached the latest iteration of my circuit. Note that a modified A13 signal is sent to ULA1 to fool it into thinking that $2000~$2FFF is at a lower address. This was necessary because that memory area is normally on the expansion bus and so would cause a bus contention. I have not drawn all the BASIC ROM connections, but they should be pretty obvious (/ROM goes to ROM /CE, etc.). Also please note that this circuit does not precisely match the picture above - it is an idealized version using the chips I would like to use, not what I actually have!

PCG RAM 13.zip

[jaybird3rd]

Very interesting! Thanks very much for posting your schematic. Your solution of enabling the character RAM only on writes is a clever way of hiding it "underneath" the BASIC/OS ROM.

 

The "SuperFont" implementation that I have in mind is similar, in that I'll also be making use of the extra space from $2000-#2FFF for character data. This region is occupied in the Aquarius II by a 4K Extended BASIC ROM, and the original Aquarius BASIC is able to use Extended BASIC in this space as well, if it finds it on startup. Since this is such a convenient way of extending the Aquarius OS, the new Mini Expander that I'm working on will bank a 512K "Super Extended BASIC" ROM into this space (one 2K fixed bank at $2000, and 255 switchable 2K banks at $2800). One of the many things I'll be adding to that ROM is additional character sets: the original Aquarius set, the IBM PC OEM set, and any other sets that might be useful. I'll also be adding some character graphics routines to BASIC.

 

Like you, I think that using an I/O port for enabling/disabling the BASIC ROM, and for switching banks within the character RAM, would be ideal. A dedicated 32K character RAM is perfect: it would require only four bytes to select any 2K bank in the RAM using the I/O port. I'm interested in exploring what can be done with full-screen bitmapped graphics, but I agree that it would be a mistake to take the idea too far and to try to turn the Aquarius into something other than a character based system.

 

EDIT: Just to clarify something in your schematic: the signals "ROW0", "ROW1", and "ROW2" correspond to pins 8, 7, and 6 of PLA1 (the big chip at U7), correct?

[Bruce Abbott]

Just to clarify something in your schematic: the signals "ROW0", "ROW1", and "ROW2" correspond to pins 8, 7, and 6 of PLA1 (the big chip at U7), correct?

Yes. By routing them to A0~2 the CG RAM is addressed in the same sequence as the ROM is when plugged into an EPROM programmer etc. (8 consecutive bytes per character). Originally I had them connected to A8~10 and used VA0-7 as the data lines. This enabled me to eliminate the 8 bit address buffer (since the video RAM data bus is already connected to A0~A7) but figuring out the decimal addresses for poking into it from BASIC was a pain.

 

This is going a bit off topic. Perhaps I should open a new thread to discuss it...

 

 

 

 

 

 

 

[jaybird3rd]

Thanks! That's what I thought. And no problem about going off-topic; it happens a lot around here.

 

So, what are your plans for the RGB upgrade once you've completed it to your satisfaction? Are you planning to offer it as an upgrade kit?

[Bruce Abbott]

So, what are your plans for the RGB upgrade once you've completed it to your satisfaction? Are you planning to offer it as an upgrade kit?

I will probably just open source the design and let other people make kits if they want.

 

Here's what I have so far - 4 standard logic IC's, 9 resistors and 5 diodes. The colored-in components provide correction for colors 3 and 12 ('light' and 'dark' yellow). Right now I have it assembled on a breadboard which is a bit flaky. I need to transfer the parts onto a pcb for final testing.

 

Edited August 17, 2017 by Bruce Abbott

[Bruce Abbott]

Today I put it on a matrix board, and of course there was an error in the circuit diagram (R4 was going to the wrong side of R9). I tweaked a couple of resistor values, and used the two spare NAND gates to buffer the CSYNC line.

 

Yellow has corrected nicely but dark blue and dark magenta are still a bit light, and cyan could be greener. More parts could be added to correct these anomalies, but is it worth the effort?

 

 

RGB V2 Eagle CAD.zip

Edited December 17, 2014 by Bruce Abbott

[Bruce Abbott]

And now... a screen full of random characters and colors in glorious RGB! Many of these combinations would be unreadable in composite mode.

 

Edited August 17, 2017 by Bruce Abbott

[jaybird3rd]

Wow, that looks great! Even the random characters! It is remarkably legible compared to the stock RF; in your second screenshot, for instance, I can distinguish several subtle differences between your character set and the original set. It looks as if you've modified the characters in the original set (mainly the game characters) to 7-pixel width instead of the original 8-pixel width. They look good!

 

Since you don't have plans to produce your own RGB upgrade kit, I might be interested in producing one based on your completed design (with your permission, of course). I'm sure that many Aquarius owners would love to have such clear output from their machines, too, especially if there's a possibility of converting it to VGA. I'd love to see the corrections for the other colors that you mentioned, but don't feel obligated to put any more effort into it than you want to.

 

Just out of curiosity, what are you using to produce your composite output? I experimented briefly with pulling the composite signal directly off the RF modulator, but it was too dark for me to use. I also tried one of the open-sourced composite video upgrades for the Intellivision, since it shares the Aquarius's RF modulator, but I got some nasty vertical banding that your composite screenshots don't seem to have.

[Bruce Abbott]

Since you don't have plans to produce your own RGB upgrade kit, I might be interested in producing one based on your completed design (with your permission, of course). I'm sure that many Aquarius owners would love to have such clear output from their machines, too, especially if there's a possibility of converting it to VGA. I'd love to see the corrections for the other colors that you mentioned, but don't feel obligated to put any more effort into it than you want to.

You are welcome to make a kit based on my circuit. I have one more idea for improved color correction using the existing gates, which I should be able to test out in the next few days. To go further I would prefer to completely redesign it using a GAL or RAMDAC. That's not likely to happen soon (if at all), so I suggest you start working on a pcb layout from the Eagle CAD file I have already posted.

 

Just out of curiosity, what are you using to produce your composite output? I experimented briefly with pulling the composite signal directly off the RF modulator, but it was too dark for me to use. I also tried one of the open-sourced composite video upgrades for the Intellivision, since it shares the Aquarius's RF modulator, but I got some nasty vertical banding that your composite screenshots don't seem to have.

 

The modulator works at a lower signal level than normal composite, so the Aquarius uses a resistive divider to reduce it. I just tapped into the circuit before the divider and added a transistor to buffer the output. If you have an NTSC Aquarius like mine then the circuit looks like this:-

 

The components to add are shown in RED. The transistor can be any general purpose NPN type such as 2N3904, BC549 etc. I used a 2SC1815. The 100uF on the left (wired across R7) is not strictly necessary, but helps to reduce horizontal streaking between large bright and dark areas on the screen (this is a fault in the original design, not caused by my composite video mod). The transistor can be mounted 'dead bug' style over the 4066, with its Collector connected to pin 14 (+5V), Base to R16 (510 Ohms), and Emitter to the 150 Ohm resistor which then goes to Ground.

 

 

Edited August 17, 2017 by Bruce Abbott

[jaybird3rd]

Thank you very much! Thanks also for the information and pictures for the composite circuit! I think I'll include the composite components on the PCB, to make the installation as easy as possible.

 

It would be nice to combine this upgrade and my "SuperFont" reprogrammable characters upgrade into a single board that is small enough to install inside the RF modulator footprint. Shrinking it down that much may require the use of programmable logic, but once I have a working "SuperFont" prototype (I'm waiting on some parts at the moment), I'll see if I can make them fit.