![]() |
Forum Index : Microcontroller and PC projects : PicomiteVGA colors
Author | Message | ||||
William Leue Guru ![]() Joined: 03/07/2020 Location: United StatesPosts: 405 |
This is a question for Peter, I think. After playing with the PicomiteVGA for a while and writing a couple of programs, the one big limitation I available of colors available in Mode 2. It's a pity we don't have something like the CMM2's MAP commands that let you build a color table and use indexed colors to get a good set of colors in a mode with fewer color 'slots'. For the PicomiteVGA, I think 16 colors are plenty but the available color selection within those 16 is not great. It seems we may be stuck with just those 16 "direct" colors, but maybe Peter can work his magic as he did recently with colors in the Editor in Mode 1? I understand that hardware limitations may make this impossible. -Bill |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
AFAIK, with 4 colour signals (R, G-hi, G-lo, B) you can have 16 colours (being 2^4). To get different shades all you could do would be to mix those differently (change resistors?). The way around it is more signals i.e. different hardware (& software to match it). There are boards which do this but they have few GPIOs and of course no MMBasic. John Edited 2023-03-03 06:18 by JohnS |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
The limitation on the PicoMite is the size of the frame buffer RAM. There simply isn't enough of it to allow more than 16 colours. You can do what you like with the resistor network, but you still have 16 colours that are actually numbered from &h00 to &h0F on the four video pins. Something like the CMM2 MAP isn't possible as you can only have a choice of 16 out of 16. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Grogster![]() Admin Group ![]() Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Mick is 100% spot-on with that reply. ![]() PERHAPS if Raspberry Pi release a new version of the chip AT SOME STAGE IN THE FUTURE - and that is probably a big "If" - they will put more RAM in the next version, which would allow for some improvements in this area. But for now, WYSIWYG. ![]() Smoke makes things work. When the smoke gets out, it stops! |
||||
Pilot352 Newbie ![]() Joined: 12/08/2020 Location: United StatesPosts: 34 |
I've pondered this for a while but was afraid to suggest a solution for fear of the wrath of the PicoVGA gods... A solution would be to use a palette register scheme. It's still 16 colors but each color value would point to a palette register (maybe 8, 12 or 16 bit) that contains the real color information ( i.e. color #7 points to a 8/12/16 bit register #7 for the real color ). The palette registers could be programmable so the user can set their own colors. This would expand the available colors knowing that only 16 of the colors can be displayed at any given time. The Radio Shack Color Computer 3 does this and it works quite well. You would loose I/O bits though. Just a suggestion for future growth. :) |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Suppose you keep the existing frame buffer. In Mode 2 you have 4 bits per pixel for colour. As you say, they can represent any colours however you then need time to look up every pixel in a colour lookup table before you can drive the (larger number of) outputs. It has to be done in real time as the video lines are sent. That's *very unlikely* to be within the capabilities of the PicoMite. Obviously, you need more outputs to get larger range of colours. The CMM2 works its graphics magic because the chip is designed to drive a LCD display in hardware. That ability has been cleverly tweaked to make it drive VGA instead, but it's still done in hardware. Even the display RAM is external. The RP2040 stands no chance at keeping up. You can have more colours, but not on VGA. You'll have to stick to LCD. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Bleep Guru ![]() Joined: 09/01/2022 Location: United KingdomPosts: 633 |
Hi, The 16 colours are hard coded in the resistor values. The there are only 4 GPIO outputs for colour and they are either ON, so one colour or OFF, so black, the Red & Blue are literally either hi or low, the Green has 2 GPIO, and a simple resistor network, so you can get 4 shades of green. You can change the resistor values, which potentially will give you colour variation, but it's still only 16,"fixed" colours. I'm assuming Pilot352 is using external hardware, so more complications. Mixtel beat me to it :-( Regards Kevin. Edited 2023-03-06 23:57 by Bleep |
||||
IanRogers![]() Senior Member ![]() Joined: 09/12/2022 Location: United KingdomPosts: 151 |
I suppose the point is:- That there is no point. 16 colours is okay and dithering will get you a tad closer, but the point of more colours is to add to the pallet. Changing the shades won't really achieve much apart from a slight change to the visual colouring you already have. Just my 2 cents... Back in the day we have 4 crap colours on CGA, so no complaints here. I'd give my left arm to be ambidextrous |
||||
Pilot352 Newbie ![]() Joined: 12/08/2020 Location: United StatesPosts: 34 |
In my suggested scheme, you would have to increase the number of I/O points used to get the increased colors. I stated this in my description. It does work as I have done this on a FPGA many times. Yes, currently the DAC uses only 4 bits. But if that is expanded and linked to the palette registers and not directly to the 4 bits of RAM, it works quite well. This is the exact scheme the Color Computer 3 by Radio Shack uses. You get 16 colors out of a programmed 64 colors. Edited 2023-03-07 00:28 by Pilot352 |
||||
Martin H.![]() Guru ![]() Joined: 04/06/2022 Location: GermanyPosts: 1233 |
Right but for 64 Colors, you need 2 more IO pins. And, because there is no video hardware, one has to re-write the VGA Output routine for the 2nd CPU to use a Color Palette and translate every Pixel to the outputs instead of simply assigning them via DMA transfer. Whether this is possible, and the result is worth the effort, I don't know. Edited 2023-03-07 01:06 by Martin H. 'no comment |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
The number of colors is an optimisation of - memory usage All that followed the birth of the VGA code know how Peter struggled to put all this functionality in the available RAM of the picomite. This has been a struggle for bits from the start. And it is amazing what has been achieved. - available pins With only 4 color pins that PIO can output maximum of 3^4 = 81 colors (3 states per pin) pin = low (0V) pin = high (3.3V) pin = 3-state (with a suitable pullup resistor, could be 1.65V) But this is the hardware side only. You still need the RAM to put all these colors. Either in a pallette, or in tiles. So it would cost you a (one) framebuffer (I guess)... Volhout PicomiteVGA PETSCII ROBOTS |
||||
Pilot352 Newbie ![]() Joined: 12/08/2020 Location: United StatesPosts: 34 |
Yes, as stated, you will need to add a few more I/O pins and increase the resolution of the DAC (more resistors), but the frame buffer would remain the same size. 4 bits per pixel and twp pixels per byte (8 bit). Again, this is just an idea. I doubt the PicoVGA gods would consider it. It's purely academic. -Enjoy |
||||
stanleyella![]() Guru ![]() Joined: 25/06/2022 Location: United KingdomPosts: 2566 |
Palette switching would be nice ie make any colour on screen another colour |
||||
Pilot352 Newbie ![]() Joined: 12/08/2020 Location: United StatesPosts: 34 |
You could also do some "fake" animation by cycling the colors. Very low CPU burden. |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
It isn't going to happen in firmware as it would require more pins and different H/W and the VGA pinout and H/W is fixed. It could be easily done in H/W using an external device with the output of the 4 data lines defining an address and the contents at that address being as many colour bits as you want. Then you would just need to find a way of programming the device contents from Basic. A very simple FPGA would do it or even a static RAM chip |
||||
Pilot352 Newbie ![]() Joined: 12/08/2020 Location: United StatesPosts: 34 |
I kind of figured.... But it's always fun to dream. ![]() |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
That's an idea... (just mind games. :) ) A static RAM chip: A0-A3 are the video signals from the PicoMite D0-Dn are the video outputs to the monitor (0-7 is easy) /WR lets you load the palette settings into the RAM A4-A7 (for example) let you set the row Start by outputting colours onto A0-A3 and a row on A4-A7, pulse /WR low to write it. Repeat until you've entered the rows that you want. While /WR is high the data lines will be outputting whatever colours are selected on A0-A3. I suppose a /EN line could be used to force the display to black. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
Hi Mick, You need either dual port RAM, or connect databus to both PICO and VGA resistors. Then write palette in the 16 locations MMBasic controlling the 4 color lines and writing data to 8 but databus. Then PIO taking control of the 4 address lines, and the VGA driven from databus. A dual port RAM would be great. Separate adress, 8/9 bit data.. You could change palette on the fly.... Volhout Edited 2023-03-07 06:55 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
If you use the console to set things up you can use a autorun flash slot to set up the standard palette on boot or reset (or pull one from a file). Then dual port ram isn't needed as the video outputs never need to write to the monitor, only to the ram address lines. Of course, you would use more row address lines to make the table bigger. 4 lines would only do the basic setup, giving 16 rows each with one colour on it. * lines makes more sense, then with the 4 lines used for the video you have a total of 12 address lines and up to 8 data lines. A 4kx8 RAM. I doubt if you can't get one so small now. lol. To save on I/O use a counter to drive the row address lines, then you only need reset and clock. The video address lines remain, of course. This clobbers changing palettes instantly though. Edit: RAM size corrected. Edited 2023-03-07 07:44 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |