Decisions, Decisions
I honestly cannot make up my find about whether to use this salvaged UM70C171 VGA palette chip as part of my video system design. I’ve changed my mind four times already in the past couple of days. I think I’m going crazy!
Previously I thought there would be a tradeoff for using the palette chip, and I’d need to give up some flexibility in supported bit depths and palette switching to use the chip, as compared with my original design that didn’t use it. But I’ve since worked out a few improvements to the design that avoid needing to give up anything.
From a technical standpoint, then, using the palette chip has nothing but advantages. It combines an 18-bit dual-port palette RAM and all the required D-to-A conversion hardware into a single chip.
- The required board space for the video system would be reduced by the equivalent of about 3 chips. That’s not a huge amount, but it would make a big difference in how much audio circuitry I could fit on the board, plus any other 11th hour things I’ve forgotten.
- The palette entries would be 18 bits, 6 bits per channel, compared with the 8 bit, 3/3/2 bits per channel of my custom-built output stage. That would produce much nicer looking colors when displaying digitized images or smooth color gradients, and it would completely sidestep the whole question of how to best map 8 bits to 256 colors that I wrote about last week.
- I’m less likely to encounter any problems related to high-frequency operation if I use the palette chip. It’s rated to run at up to 66MHz. With the custom output circuit, I’d have to be very careful to use high speed parts and account for the timing requirements everywhere.
- The D-to-A conversion would probably produce cleaner results than my custom circuit. There was a fair bit of noise in the video test circuit I built a few weeks ago, and the final circuit would probably suffer from some of the same problems. Also, the palette chip should produce nearly equal changes in brightness for equal changes in RGB values, which may not be the case for my custom DAC. I’m not even certain that my custom DAC will produce a brighter color for binary 100 than 011.
If I do use the UM70C171 palette chip, it will only replace about 25% of my original video system design. I’ll still need to build the circuits to generate the row and column addresses, video sync signals, VRAM, character ROM, and data latching. The only part that would be different is how a byte of video data, once it’s retrieved from VRAM or ROM, gets converted into analog RGB voltages for the monitor.
So why *wouldn’t* I use this palette chip? It sounds like a no brainer. The only reason is really a lingering feeling that it’s somehow “cheating”, or isn’t as interesting an accomplishment to build a video system if part of it is a purpose-built component scavenged from a VGA card. It’s the same argument that I went through with myself six months ago about whether to use GALs in BMOW’s design. Ultimately I did use GALs, and it’s worked well, and there’s no way I could have fit everything on the existing board without them. So from a practical standpoint the palette chip would be a big win. I guess I just need to swallow my pride a little, or let go of the “not invented here” attitude, and use what works.
Read 9 comments and join the conversation9 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Not cheating! Think of it as a pre-programmed ROM! If you were to do without the chip, you’d end up with basically the same thing. Anyway, if you are goinmg to torture yourself with character generation, might as well not waste your time with a DAC!
(the avr goes well, puts out very nice sync now. I ripped apart some code I found on the internet and now I can generate horiz and vert lines. links later)
Ideas for BMOW2: Ethernet connection, Serial + PS/2 keyboard connection, removable media. Oh yeah!
For what it’s worth, I struggled with the same question for portions of Magic-1. I ended up drawing the line at I/O devices. The UARTs, 8250-based IDE interface and real-time clock were all done using whatever off-the-shelf part was easiest.
When considering my own video system, I decided not to have a separate text mode as it complicates things considerably. Additionally, what if you want to mix text and graphics?
The only real problem with rendering text in graphics is, as you have mentioned before, scrolling. This can be solved by having a variable start address for the display (within a limited range, anyway). The display can then be moved vertically by any amount “instantly” just by changing the start address register!
Just a thought.
Merlin
Good going with your AVR microcontroller video HDL-SDK. Let’s see some photos.
BMOW does have a PS/2 keyboard, and a USB port, so an ethernet connection via a host PC should be theoretically possible. Removable media (compact flash) would be my last goal after audio, if there’s any space left for it.
Merlin, I haven’t found that text mode complicates things too badly. It requires adding a character ROM and a mux. Part of my plan is that all of the graphics settings can be changed line-by-line, so mixed text and graphics should be possible.
I did look pretty seriously at vertical hardware scrolling, but decided against it. Right now the row address counter doubles as the vertical sync/blank signal timing generator, so that would need to change. I was also worried that just drawing a screen of text in the first place (ignore scrolling) would be annoyingly slow without a character mode. I should redo the math and see how bad it would really be though. Maybe I’m making things harder than necessary.
I’ve pretty much decided to use the palette chip now, for the board space savings more than anything else. Then the last big question is whether to target a horizontal resolution of 640 or 512. 640 is the standard for VGA, it would give me 80 columns of text and 2:1 rectangular pixels at 640×240, the highest resolution I can fit in 32K of VRAM. But 512 packs much more easily into video memory, since it’s a power of two. As a result, it would give me twice the color depth: 2 bits per pixel at 512×240 vs 1bpp at 640×240, 4bpp at 256×240 vs 2bpp at 320×240, etc.
i would go with 640 if i were you. In my programming experiance, 640 is plenty of space without giving exess. most of the time, it would be worth the extra room to sacrifice a little resolution. it also is the most easily expandable way to go. however, if you don’t care about screen space, go with the 512 with some more resolution
just my 2 cents.
I say “Go for it!”. That part is an amazing device, even better then the M6845 I was once considering for a project, a very long time ago.
Besides I see Bill has commented further, so I’ll refrain from commenting on that part.
David, I’m not sure I understand what you mean by 640 being the most easily expandable way to go. You’re saying you find 640 pixels of horizontal resolution at 1 bit per pixel to be more useful than 512 at 2 bpp?
I’d say 640 is probably better for text, where you’re going to be running 1 bpp anyway, but 2 bpp with 512 horizontal resolution is probably more useful for drawing a game scene or a digitized image. So I guess it’s a question of whether the hardware should be optimized for text or graphics.
I would say go with optimizing for graphics. Game programming would probably keep you messing around with this thing for a lot longer, while writing say… a wordpad would really tire you out fast 😀
oops, sorry i didn’t make that very clear, did i. i meant the reslution of 1bpp being more expandable, because then eventually you could add to the pallatte thingumabob (that’s the technical term for the pallatte chip and supporting hardware) without much (relative) trouble, but adding to the screen size would mean adjusting the x and y counters as well.
however, i asked my dad after i left my comment and he sided with the 2bpp, because , as he said, loss of color would look worse than more colors with a somewhat smaller screen size. that coming from a very good photographer.