High-color TV.bitmap driver demo.
potatohead
Posts: 10,261
Version 1.0 bitmap variable resolution raster driver attached.
Horizontal resolutions are 20, 40, 80, 160, 256, 320
Vertical resolutions are set by pixel height now. 1 = 192, 2 = 96, 3 = 64, 4 = 48, etc...
Resolutions above 160 produce artifacting, and the thread below then applies.
There are two files in the attachment here. One is the TV driver, the other is a simple demo to show it off. Nothing fancy, but effective to see pixel sizes, colors, etc... The demo code is cleaned up, with some basic error correction in the dot plotter, and variable screen memory allocation, depending on resolution specified.
See my .PLAN for where this might be going in the future.
old thread text below
I've been working through color, NTSC timing, etc.. Decided to share this little example of nearly 400 colors on the display at once, using just the reference video output circuit.
I've got one problem, and that is pixel to color clock timing. This demo works correctly a high percentage of the time, but it not yet reliable...
It's a 320 x 96 image, showing an improved color palette. That's the best resolution that will fit in the prop 32K RAM. Lots will be possible with the SRAM expansion, IMHO.
The TV driver is a more easily adjusted version of Cardboardguru's NTSC. There is a resolution setting for one or two vertical lines per pixel and adjustable pixel sizes of 160, 256, 80 and 320 pixels horizontally at either 192 or 96 pixels vertically. All pixels consume one byte.
Sorry, I don't have a video capture device handy where I am right now.
Edit: Removed this attachment, see post at end of thread. Timing issue fixed, demo now reliable! Thanks to Jasper_M.
If you have a moment, please test this. See post at bottom of thread. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 7/22/2007 6:44:22 PM GMT
Horizontal resolutions are 20, 40, 80, 160, 256, 320
Vertical resolutions are set by pixel height now. 1 = 192, 2 = 96, 3 = 64, 4 = 48, etc...
Resolutions above 160 produce artifacting, and the thread below then applies.
There are two files in the attachment here. One is the TV driver, the other is a simple demo to show it off. Nothing fancy, but effective to see pixel sizes, colors, etc... The demo code is cleaned up, with some basic error correction in the dot plotter, and variable screen memory allocation, depending on resolution specified.
See my .PLAN for where this might be going in the future.
old thread text below
I've been working through color, NTSC timing, etc.. Decided to share this little example of nearly 400 colors on the display at once, using just the reference video output circuit.
I've got one problem, and that is pixel to color clock timing. This demo works correctly a high percentage of the time, but it not yet reliable...
It's a 320 x 96 image, showing an improved color palette. That's the best resolution that will fit in the prop 32K RAM. Lots will be possible with the SRAM expansion, IMHO.
The TV driver is a more easily adjusted version of Cardboardguru's NTSC. There is a resolution setting for one or two vertical lines per pixel and adjustable pixel sizes of 160, 256, 80 and 320 pixels horizontally at either 192 or 96 pixels vertically. All pixels consume one byte.
Sorry, I don't have a video capture device handy where I am right now.
Edit: Removed this attachment, see post at end of thread. Timing issue fixed, demo now reliable! Thanks to Jasper_M.
If you have a moment, please test this. See post at bottom of thread. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 7/22/2007 6:44:22 PM GMT
Comments
Nice to see lots of colours
It works well, but I don't really understand the theory. You say that the output of the pixel has to be timed precicely to a color clock. But as far as I understand it, it's not where the pixel is relative to the color bust that matters, but the phase of the chrominance signal relative to the color burst. In fact in the code you have, each of the 320 pixels takes 8 color clocks to display.
My concept of how it works is that you are displaying two differently coloured pixels next to each other in less space than the TV circult is able to resolve, so what appears is a mix of the two colors.
Is that the same thing, or am I missing something?
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 6/8/2007 2:56:34 PM GMT
More colors are possible, BTW. Right now, I'm only using the low saturation colors. There are two sets of 16 high saturation hues that are somewhat bizzare in their behavior. IMHO, those combined with the 6 intensities, particularly the lower ones, would add up to another palette, many of those colors not shared with this one.
I started out trying to emulate the look of older computers graphics systems. Wanted some control over how things looked and was thinking about artifacting. On NTSC, of course, pixels that are smaller in terms of their timing or width, than a full period of the colorburst, will appear colored, with said color depending on where they actually occur, with respect to the phase of the colorburst.
On the prop, I've found the artifiacting inconsistant. Sometimes it's one color, sometimes it's another one.
At beginning of scanline, prop outputs it's colorburst so the TV can match that color reference for that scanline. During the video generation period, then this signal controls the color. color burst Beginning of pixel A "Clock" as defined in . . easy_NTSC . . . Beginning of scan WMWMWMW............|- - O - - - - |- - - - - - - | . Sub-Pixels Upper is 1 clock wide, lower .5 wide . . WMWMWMW............|--o-----------|--------------| . . . . .....One NTSC color Clock...... Problem: WMWMWMW.....|--o-----------|--------------|What I think is happening is that the absolute timing of the pixels within the frame ends up being somewhat different than that same timing with respect to the colorburst PLL. When a sub pixel is output by the prop it's timing is determined by the CNTa. When we overclock the video to output our own pixels, the phase relationship between that PLL and the NTSC frame ends up being off.
That results in the condition shown above and was what I was trying to correct and didn't have much luck.
This behavior would also explain the seams sometimes present in propeller video images. That slight misalignment would cause monochrome pixel edges to not align with the color reference.
Many older computers somehow addressed this in their video generation, resulting in well aligned pixels with their color reference, thus artifacted colors were consistant. A demo like this, running on those machines would always output the same color for any given combination.
That diagram also does not show it, but this program does output two sub-pixels per color clock. Your average TV will mix them together to form a new hue. So, you can get 32 hues by just picking prop hues from 0 to 16 and place your color sub-pixel anywhere along the color clock, or you can get other hues by setting both pixels to some color, thus placing two sub-pixels in there. Lots of combinations are possible and some display better than others.
In any case, we can get a whole lot of colors on the prop, given we can insure the case shown above does not happen.
I'm thinking the scanline drivers can have a very large palette this way. Where overall resolution is concerned, once the timing issue is nailed down, it's then possible to offset this whole affair 1/2 a color clock to interlace the color resolution, thus yielding 320 pixels of horizontal resolution with a very high number of addressable colors per pixel. The Parallax driver does this and that's why text on it looks really sharp. If it were modified to use the waitvid #%%3210 trick, for the ~90 or so directly addressable prop colors, it would not have significant artifacts at resolutions above 160 pixels horizontally within the safe area. This would likely improve the Fantasia driver in that the better aspect ratio allows for smoother edges of text. (Could display Andre's text challenge too.)
Edit: Bob, sure. But it's only a bitmap buffer and it takes nearly all the room! Right now, this code really is only good for working with color and timing. Once that's done, bigger and better engines can be crafted.
Post Edited (potatohead) : 6/8/2007 3:15:19 PM GMT
If so I'll update the Project master index to reflect this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
potatohead has used SimpleNTSC in creating this, but it's not a replacement. SimpleNTSC's objective is to provide an easy to understand hi-color TV driver. This doesn't go further towards the easy to understand objective, but is more complicated in it's mechanism for providing more then 86 colors.
I think they deserve separate entries.
It's gonna get somewhat more complex as well.· This first pass really was just all about scoping out what could be done color wise on the Propeller.· I'm anticipating more color depth, and resolution on the SRAM expansion.·
Andre'
I'll start studying this tommarrow and see the changes you made the simpleNTSC.
·
The nice thing, Andre', about the prop is that it can easily be pixel clocked fast enough to avoid the oddball pixel sizes. This one runs at 160 x 192, and on most televisions, each pixel will appear as a more or less solid color. If the timing issue, noted above, gets worked out, scanline drivers with a high color and intensity depth will be totally doable. From what I've seen, we can get 320 x 192, with interlaced horizontal color, with 4 full bits of intensity and plenty of color, based on 32 hues. That's a 512 color display that will look solid. More is possible beyond that, but it will get tricky. Learning enough to deal with that is where I'm at now. Nothing else makes sense until that's nailed down.
It might consume too much time for scanline drivers, maybe not with a clever color lookup table. Will totally work for full on bitmapped displays, and character / tile based ones.
Anyone run this on a PAL display? I'm curious to see what it looks like. I know the artifacting does not come into play in the same fashion, but what does? I'm wondering what kinds of color choices there are for PAL.
IMHO, 12 bit color is gonna be a stretch. The core problem is only having 6 intensities to work with. If one is careful, the one just below black can be dithered with some of them to get a few more intensities, past the 20 or so possible with this technique, without hosing the display for mediocre displays, but that's really cheating. Having more hues rapidly ends up with diminishing returns. The intensities really make an image, IMHO. Getting the 512 to look good is doable. Past that, I'm not sure it's worth the bother for anything but still pictures.
The changes to Cardobard Gurus driver are incomplete. My intent is to hardcode the sync and overscan bits, leaving the user graphics display area variable. Right now, this is actually largely done, but the pixel timing issues are not worked out just yet. That means you get multiples of pixels that fit into the number of display clocks allocated. That's essentially the resolutions I noted above. Past that, it's largely the same driver, I only added bitmap code to scan a linear address space, and it's single buffered due to RAM constraints. On a stock prop, on the fly video, or tiles is the way to go. Really this was just enough to see if it was worth going farther. (it is)
I will end up doing one that does a very wide range of pixels and that has color lookup capability to make managing pixels easier. All of the real work shown above is in the demo program that just plots out pixels to prove out the scheme. Given the lack of a color lookup system, it's kind of tough to use without writing some additional code. There isn't RAM space for this on a stock prop.
When I get an SRAM card, I plan to work this into a full on bitmap driver with software sprites. The prop is plenty fast enough to sync this to the display, giving crisp visuals. I also would not mind coding in an option to interlace the color for the resolutions above 160 too. That would make for an excellent quality text / line art display. Also, even though a full 512 colors is doable, it's likely easier to just do 256 so the math is easy. Having a CLUT and bit mashing to decode the 512, without wasting a lot of bits, probably would be tough to fit into a COG.
Good work potatohead!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Regarding the potential of a high color E512K SRAM implementation, I haven't been able to reconcile the ramifications of the performance hit incurred by contention between the graphics generating process (i.e. the "game" app) and the driver. If you take a buffer swapping approach then the game app is actively drawing in a random access fashion in one "page" while the driver is sequentially trying to clock data out of another. That means that for one thing the two processes would need to manage their contention for the SRAM, but for another thing the graphics driver would frequently (or always, depending on the arbitration scheme) have to re-send the SRAM address since the main game process will have (/might have) changed it while drawing.
Have any of you envisioned a scheme for getting around the performance hit of the contention?
I don't yet have an SRAM... Have a few metrics, or maybe test for some?
What we really need to know is how long things take, in terms of scanlines. That timing is gonna drive everything, IMHO.
Let's say transfer is fast enough to happen, at 160 pixel resolution, while the screen is drawing. This might be reality from the brief look I took at the docs. So, that happens, then after the last 4 pixels have been drawn for that scanline, the alternate address is loaded, then some bitmap changes are sent during hblank, with the graphics address being sent, just in time for the next scanline. Depending on the drawing scheme used, these could be sprite tables, display lists, or just raw changes to the buffer, all depends on the graphics engine.
This goes on, until the active graphics area has been drawn, which gets us to vblank. Now, we've got a very nice chunk of time to get some stuff done. So, as many bitmap changes as is possible are sent to the drawing page. When a specific time has elapsed, the display draw and buffer pointers are changed, and things start again.
If the system counter is used to watch for memory access windows, an engine that gets complete changes done, would degrade if too many are requested. Either skip some movement, fail to display, or delay display until next frame.
I don't see things happening without some kind of interleave scheme timed to the display.
Another alternative would be a fairly large buffer approach. Maybe during vblank, load a third of the graphics screen into local propeller RAM. Then, while that is drawing, spend time streaming changes to the buffer page, and then using the system counter, determine when the next third of the screen is to be streamed into local prop RAM. Timed just right, the last scan line will have just finished display, when the RAM is full, pointers get changed, display continues for the next third, along with the streaming, etc...
This cuts down on the number of task switches required.
Because of the addressing, tiled display engines are very likely going to have to have their tiles in the propeller RAM. One could store sprites in the SRAM, then stream them out, scanline by scanline, for a mixed mode display where background graphics are tiles, and sprites are in the SRAM. A sprite table, that gets sorted could contain the addresses & such, that all gets worked out during VBLANK.
There is one other alternative I can see.
Wonder if it's possible to stream SPIN code, or more likely large memory model code into propeller RAM? Maybe just take two COG's and have one execute code, while the other preps the next bit of code, they swap roles and keep running small bits of code. If so, a larger local display buffer could handle a combination of tiles and scanline / sprite data, providing more speed.
(sorry for long post)
I did spend some time this weekend working with color some more. IMHO, the 512 color display is likely to be a PITA. I went ahead and mapped in some of the high saturation colors and they produced some additional colors, thus getting the 512 is no biggie. However, a CLUT is gonna be necessary to make it all sane. This CLUT is too big to fit into a COG and having it reside in HUB memory slows things considerably.
The display, present in this demo is easily done, but for the timing issue. That issue is annoying! (more below) My comments above about having a really great 256 color display are looking pretty accurate actually. Given the memory constraints, and the time it takes to bit shuffle things around, one byte per pixel is looking pretty attractive. This makes sense for a Color Lookup Table as well. So, a 256 color display, using most of the prop standard colors, and with some of the artifacted ones mixed in, will be the best overall balance between color depth, speed and memory requirements.
One other thing. I ran some timing tests to see how much time was available during a scanline for processing. At the 320 pixels per scanline speed, the code in the demo TV driver has no extra room. It's running about as fast as it can. That code will do 480, but that's it. This means multi-scanline engines where more than one cog video generator is processing it's scanline, while the others are drawing. I'm working with a friend on such an engine for sprites, but it's still being debugged. I found I cannot do a 640 byte scanline with one COG. (was exploring higher color depth and intensity depth options)
At 160 pixels, there is considerable room for additional instructions during the waitvid loop. 6 more instructions are possible with no problem, leaving some room for processing from SRAM, or just better pixel processing logic. (tile mode, reading of display list for resolution control, sprite overlay, etc.. We are gonna have to work for anything over the 96 colors possible from the video generator.
I ran some test cases on a very large CRT NTSC television and looked at the pixels. (don't have scope so...) It all comes down to differences between the system clock and the PLL used to generate color. I found a prop, gets that demo right after a cold reset 90 percent of the time. From there it degrades. Nothing I tried was successful at syncing the pixels to the color reference signal. This is a show stopper for the higher color scheme, until it is found.
It is possible to display two colors on the screen, request user resets until they are the same, then go ahead and run from there. It's a kludge though. I need to know more about how exactly the video generator does it's thing, before I can resolve this.
There is a nice alternative though. One could trade color depth for resolution and still get 96 colors. If we interleave the color, shifted by 1/2 color clock, every other scan line, we can get 320 x 200 x 96 colors. IMHO, this is gonna look really good, and will have no artifacts. Will handle motion nicely too as most modern gaming systems use just such a scheme to break the 160 pixel barrier. One side effect of this would be higher readable text resolutions, over 40 per line, would be doable. Think C64 quality output, with 96 colors and no attribute limitations.
For one thing, the speed of the next propellor would help you alot and the fact it has more RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Edit: I would appreciate a coupla people testing this. Reset the prop a few times, power down, up, run program multiple times, etc... Should only take a coupla minutes and all you look for is the hues being the same in the hi-color group, and correct in relation to the standard propeller palette drawn below. Thanks!
The changed version is attached to this post. One side effect of this is a richer palette. The image posted above is about 180 degrees out of phase from where it should be. Now, starting from the upper left, the second color group in should match the hue of the first color group in, from the left, of the reference palette below. They cycle to the right and down from there, with the upper left corner of each square color group being a good match for the hues, shown in sequence, in the palette below.
Some of the colors were not completely unique in the example above. (At least to my eye) These look far better. Effective resolution for this one is 160x96x400 colors, plus 6 intensities. (maybe a coupla more, given some very light tint is acceptable)
Given some RAM, it's totally possible to interlace the color and get 320x192xhi-color display drivers. This might make sense, if the 256 of these were mapped, we get a total RAM bitmap buffer size of 64K. Clearly this is probably best implemented as an on the fly scanline, draw sprites, display scheme. However, it does work and the colors are consistent. It also makes some sense to build a palette based mode where a subset of these possible colors are mapped into a reduced color display, such as 32 or 16 colors. Given a HUB based color lookup table, color cycling effects, and changes can be made on the fly.
All things considered, I'm not going to persue interlaced color at this time. RAM requirements are too great. When I get hold of an SRAM, maybe then... Assuming we get the same video hardware for prop V2, this will prove useful where the system RAM is high enough to make better use of this technique.
One other advantage here is artifacting becomes useful in the more limited color modes. So, a 16 color display, with artifacts can still yield a whole lot of useful colors on an NTSC television. Doing this might make more sense as the RAM requirements are low enough and the user can still choose from a wide palette to craft their display. I may explore this just to see how it all shakes out. Only 15K for a single scanline height bitmapped display.
Post Edited (potatohead) : 6/12/2007 6:16:14 AM GMT
tested it on my protoboard, works a treat every time, colours are the same.
Nice work [noparse]:)[/noparse]
This does make NTSC overlay graphics possible now as well... They are or'ed together, limiting their utility as sprites, but do open up more grey scales and or color combinations...
Thanks, and I hope the other tests come out ok.
Scanline isn't really 3024 color clocks wide - it's 3008 clocks.
Line 57 is
when it should be
and line 88 is
·when it should be
It'd help me see how sprites convert to your pallete.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
I'll bet matching a core set of hues by eye, then their intensity levels would yield rough parameters that could be used to more quickly get the other ones close.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
1. Large pool of rapidly addressable RAM does not exist. Even the SRAM isn't gonna make a display like that be useful.
2. Propeller video only does 6 intensities. 12 intensities are possible, but only with artifacting and those really cannot be combined with color. If one were to use more than one cog together, more greys are possible, but I don't know how many, and that's two cogs just to get the colors onto the screen.
3. Overall system speed. At that many bits of resolution, per pixel, manupulating the data is highly likely to be beyond the speed capabilities of this generation propeller.
8 bit color is doable and will work well. 9 bit color is a PITA, for addressing reasons, above that is just a mess for anything other than a trick demo. There is a strong case for the quick work I did to be excessive, for all colors being directly addressable at one time, because of the above limitations. Making a different video circuit might help, but IMHO is not worth the hassle. The reference one is quite good, given the overall capability of the propeller today. If one considers expansion then that's really changing the scope of things and that more or less defeats the purpose of running a propeller anyway. For me personally, I enjoy the learning that comes from exploring the chip, plus I think the next gen one will really shine and make leveraging stuff I know now easier.
Maybe, just maybe one could really put the cogs to work, crank the pixel clock and get 10 bits of color, but that's it, and it would only be a demo for learning anyway. Bragging rights to the first that does this, and that's about it. Displaying an image with it, would consume a large chunk of the SRAM. I doubt this could be done, for anything other than a carefully contrived demo display on the unexpanded propeller.
Frankly, for where you have expressed where you want to go, I'm not sure the Prop is your platform, unless you reset expectations. You would be better off with a stripped down computer, Linux, OpenGL and a modest graphics sub-system. That's where home-brew 3D gaming and animation is really at. (don't want to pop the bubble, but I gotta tell it like it is. If I'm dead wrong, somebody here will correct that and all will be good.)
There are 3D modeling tools, 2D texture and sprite tools, game engines and a ton of other open bits and pieces there for the taking. Lots of open games too, to learn and develop on.
Don't get me wrong, the Propeller is damn cool. For me, it's right in the sweet spot as I like retro gaming and have been out of programming and electronics for a long time. This is a killer chip, and it punches well above it's weight, but it's current scope of capability lies somewhat beneath where you are wanting to go.
If that seems daunting, do what I'm gonna do. Explore the capabilities, and build something fun. Look at what's been developed so far. The HYDRA cd is full of excellent retro games and demos. That's all really great stuff! The two games posted here are also excellent works. I enjoyed playing them and am enjoying learning from them I'm sure as much as Baggers and Cardboard enjoyed crafting them.
That's really what the propeller is about, where gaming and graphics overall is concerned, IMHO.
-timing errors, caught by Jasper_M incorporated
-comments cleaned up, some minor driver bugs fixed so that core display driver is actually useful.
Said driver resolutions possible are:
Horizontal: 20, 40, 80, 160, 256, 320 pixels @ 1 byte per pixel = 126 colors. (all possible standard propeller colors)
Vertical: 96, 192 (basically one or two scan lines high)
Edit driver to define desired pixel size, then start it, passing the screen buffer address to begin display. If you intend to tinker with this, or just want the linear mapped higher color display driver, this is the version you want.
I know that attachment says final, but the version you want is attached to the first post of this thread, and linked at http://propeller.wikispaces.com. It's better commented, cleaned up and now has variable vertical resolutions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 7/22/2007 6:50:44 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Here is what I do know:
There are 6 intensities and there are 16 core hues. That's 128 standard propeller color. Of those, I believe there are two basic saturation values. Most of the colors (80 or so) are muted and fairly low saturation. They are a lot like the Atari colors, if that helps to have a reference. Two of the standard colors are very high saturation, and are nearly identical, but not quite identical, where hue is concerned. (At least my TV's and eyes think so --I could be wrong!)
As they mix on screen, one should get the 8 combinations possible from zero saturation, high saturation, and moderate saturation, so that's the max possible with this technique. The demo program does not use the high saturation colors because there was not a 1 to 1 mapping between intensities and colors and I wanted a nice and clean mix to occur, be repeatable and mathmatically derived, if needed. So, it only uses the moderate saturation colors, for a total of 4 saturations. If you don't mind a monochrome display --no color at all, getting 12 shades of grey also works well too.
My guess about the black lines comes down to how the color is clocked. The reference Parallax video driver does it exactly right. Color is interlaced, every other scanline, interlaced vertical display or not. An adapter that does de-interlacing will sort this out and deliver a full on 320 pixel NTSC display with no issues and no horizontal flicker. This demo, does not do this. Color is the same every scanline, interlaced or not. A high resolution capture device probably can detect the pixel transitions, and that's your black lines.
IMHO, interlacing the hi-color is possible and will look really good with a full 320xwhateverx8bit color display, but we are flat out of RAM, unless contrived addressing schemes, tiles and such are used. That's really the core reason I didn't yet work through doing that. Suppose a text / tile / character mode display would work fine though!
Thought about the math today. IMHO, the colors all shift by a constant. I think the right thing to do is sort out the high color palette by hue. There should be 30 of these. (15 per half-pixel) Some hues are better represented than others, so trim down the palette for an 8 bit display. 5 bits for hue, maybe double up on one of the better represented ones, and 3 bits of intensity. Since we only get six, use a couple of the near white shades to balance that out to a full 8. From there, many of the colors will be simple adds across the different hues, resulting in a fairly small CLUT and a calculation, or just a full on 8 bit CLUT.
Depending on how much the display cog does, having the CLUT in the cog to translate might make sense. If this is too much, then a multi-cog design will be needed to build scan lines. The standard color palette can be generated with a 16 color table. 8 for the intensities, and 8 more for a baseline hue. They are all constant offsets from there. This one will be similar, but not quite as clean, IMHO.
Post Edited (potatohead) : 6/16/2007 5:22:53 AM GMT