Has anyone already implemented - or thought about - display lists?
pullmoll
Posts: 817
I guess most of you have heard the term. Display lists were used already on the famous Xerox Alto computer to counter the tight memory. Yes, it was 197something and RAM was very expensive. Displaying a full 606x808 screen of black and white bits took 30704 of the 32768 (- I/O range) words available. Sounds familiar, huh? They implemented a rather simple to understand scheme, where the display would be described by a linked list of words and description of what the current block should look like. Perhaps it's not even a bad idea to think about using an approach like this today, because the developers of the Alto certainly spent a lot of time on the design.
Here's an overview of how DCBs (display control blocks) looked like on the Alto:
The control word consisted of a number of fields for various purposes:
The Alto used an interlaced display, but there's no reason why the principles of the DCB layout should not work non-interlaced.
By defining DCBs with NWRDS = 0 and SLC > 0 you could simply insert some empty scanlines in a layout. You could just as well insert 'horizontal rulers' (black) and even indented ones by setting the INV and/or HTAB fields of a DCB. Doubling, tripling etc. a vertical regions height, like for double or triple height text, could be done by just repeating the same bitmap addresses in several DCBs. By defining NWRDS smaller than the number of words for a full scanline you could save (white) space on the right edge. A DCB with a link field of value 0 would end the display, i.e. the video would continue with blank lines until the vertical blanking + sync.
The size of the bit fields could be different today, depending on what ranges are required for the values. There could perhaps be more fields, like for dealing with colors (background?). The Alto was B&W...
There wasn't much more to it but this, except perhaps for the compact way the Alto stored fonts (that's another story) and the microcoded opcode to expand such a glyph into some bitmap memory. If something similar to the Alto DCBs could be implemented on the Propeller, then certainly also the font rendering could be done as they did it back then.
I doubt I would yet be able to tackle any of this, since I did not even look too close in the 'simple' tile buffer video drivers. Perhaps this is an idea for those of you who are more acquainted with WAITVID than I am.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/10/2010 11:16:25 AM GMT
Here's an overview of how DCBs (display control blocks) looked like on the Alto:
DCB: word DCB1 ' link to the next display control block
word control ' control for this DCB, bits explained below
word bitmap ' pointer to the actual bitmap memory to display
word SLC ' scan line count
The control word consisted of a number of fields for various purposes:
bit # purpose ----------------------------------- 0 LOW: use low resolution if set (double wide pixels / half pixel clock) 1 INV: inverse bitmap if set 2-7 HTAB: indentation by a number of 16*HTAB bits (16 because that was word size of the Alto) 8-15 NWRDS: number of words in the bitmap (had to be even)
The Alto used an interlaced display, but there's no reason why the principles of the DCB layout should not work non-interlaced.
By defining DCBs with NWRDS = 0 and SLC > 0 you could simply insert some empty scanlines in a layout. You could just as well insert 'horizontal rulers' (black) and even indented ones by setting the INV and/or HTAB fields of a DCB. Doubling, tripling etc. a vertical regions height, like for double or triple height text, could be done by just repeating the same bitmap addresses in several DCBs. By defining NWRDS smaller than the number of words for a full scanline you could save (white) space on the right edge. A DCB with a link field of value 0 would end the display, i.e. the video would continue with blank lines until the vertical blanking + sync.
The size of the bit fields could be different today, depending on what ranges are required for the values. There could perhaps be more fields, like for dealing with colors (background?). The Alto was B&W...
There wasn't much more to it but this, except perhaps for the compact way the Alto stored fonts (that's another story) and the microcoded opcode to expand such a glyph into some bitmap memory. If something similar to the Alto DCBs could be implemented on the Propeller, then certainly also the font rendering could be done as they did it back then.
I doubt I would yet be able to tackle any of this, since I did not even look too close in the 'simple' tile buffer video drivers. Perhaps this is an idea for those of you who are more acquainted with WAITVID than I am.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/10/2010 11:16:25 AM GMT
Comments
And you usually can't determine beforehand if the worst case could happen.
I think back to the ZX81 display memory. It only had 1K of RAM. The display was 24 lines of 32 characters. But each line of text was ended with the special character. If a line had no characters the line consisted of only the special character. So the idea was to keep text to the left and/or only use a limited number of lines. But even this method uses 1 extra character per line worst case, but this could be eliminated if you just keep track of how many characters are on the line. If you reach 32 OR the special character then the rest of the line is blank.
And these methods make drawing on the screen much harder and slower.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
·
Each text or graphics color/resolution mode had a bytecode, 4 bytes for mode,
one bit caused an interrupt, perhaps for changing sprite positions after drawing them ,allowing more,
and also for changing pallettes to get more colors on the screen, etc.
I think there was also a bit to enable horizontal and vertical scrolling...
I know there is detailed info on ANTIC on the web.
Oh, also... There were bytecodes for vertical retrace blanking, which at least made black lines above and below
the visible part of the screen, because if you cound type under the bottom of the screen you wouldn't be able to read it.
The most common use of the display list was to mix various sized pixels and characters, but
each code represented usually one line of text or graphics, so the list was only a little bit longer
than the vertical resolution.
I was thinking about a mixed text and graphics driver recently for the propeller and figured that a display list
Atari800 style or simpler could define what was text and what was bitmap, because text takes up a lot less
screen buffer. It could be hard to automatically figure out where to display characters and where to
display text, and also manually if you had several different zones on the screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
Somewhere I have a big old scope tube that could do with driving in a similar way. I've often wondered if the Prop was up to it.
How you use display lists with raster I'm not sure.
Bean, yes in the worst case they require more memory, but at least there are a lot of cases where a few objects at high resolution would be great. For example the old Asteroids game. Lots of empty space with a few objects flying around in it. Or just drawing, for example, waveforms for a scope application. All you need is the X-Y axis, some tick marks and the waveform line or two. Most of the screen area is empty. Lot's of uses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
With raster scan you would need either dedicated hardware to produce video pixels in a manner similar to the way text terminals generated a full screen of 80x24 characters from 1920 bytes of ram, or a very fast cpu to go through the display list and generate the image in a display buffer.
I was thinking of a system with a full screen memory (possibly double buffered), additional ram to hold the "sprites" and a dedicated cpu to accept graphics commands and place "sprites" on the screen. For a 640x480 display 512Kx8 ram, 307,200 for the display buffer and the rest to store the sprites.
IMHO, another great alternative for higher detail/color/resolution displays would be serial memories. For an instrument panel, an awful lot of the display could come from the serial device. Static, or nearly static display elements could be combined with dynamic ones, on a scan line by scan line basis, preserving the HUB memory for those areas of detail that are dynamic.
The SRAM could up updated during blanking periods, if needed.
pullmoll, the propeller actually has several color "modes". If one sticks to the reference video circuit, it's possible to get ~100 colors, and do so at 1 bit per pixel, 2 bits, or 8 bits, some of which are wasted. Eric Ball wrote a higher color resolution display using all of the pins in VGA mode, to drive the reference circuit to better color, achieving 130 colors, but with much better characteristics. That is a 224 pixel display, timing coded specifically for a NTSC display.
Additionally, the waitvid frame size can be changed. For "full color" where each pixel color is independent, that frame size is 4 pixels, using one long per 4 pixel group to get color on the screen. The trick there is to use the waitvid backwards, essentially changing the colors long into a pixels long, and the pixels become an immediate value. eg: waitvid colors, #%3210 For the 2 and 4 color modes, frames can be up to 32 pixels, but don't have to be. I use a frame size of 8 pixels when doing text drivers, to emulate the one byte per character 8x8 text modes common on older computers, for example.
On a NTSC display, a resolution of 160 pixels exactly delivers ~400 in spec colors, and close to 1K colors, if one bends the standard a bit. This is done through artifacting, and will only work on a composite signal, NTSC display, and only work at 160 pixels.
If one does not stick to the reference display, the number of colors could be significantly improved, by adding more grey scales, and to drive the circuit with VGA model. That would consume one cog for just scan lines, requiring another COG, or multiple COGs to feed that display cog each scan lines worth of data.
Current display methods include tiles, where the "screen memory" is a combination of references to HUB memory color palettes, giving color indirection at a fairly low cost BTW, and HUB memory addresses. That's how the Parallax reference driver works, and it's very clever, and very flexible, but it is 4 colors per tile in the end.
"Character mode", where a table of characters exists in HUB memory, or on the COG, if a limited display is all that is needed, an optional table of colors, and a screen memory consisting of bytes, that reference the characters. That's how my 8x8 text drivers work, and others have built nice variations of that. Think 8 bit computer, "text mode", without a dedicated character ROM, like the Apple and CoCo used.
Bitmaps. These are really easy, but consume more HUB memory and that sharply limits their use on Propeller. The bitmap would be a great candidate for the sram + hub memory display scheme, IMHO.
Those can all be done with a single COG, and depending on the driver attributes, can go to 640 pixels of resolution on a TV display. S-video makes that useful for color, otherwise, it's probably best to do a full interlace (like potatotext) for the best quality with the least artifacts, or stick to a monochrome display.
Multi-cog displays almost all use a scan line buffer method. The primary video cog outputs sync signals for other display cogs, and draws each scan line as "full color" pixels, with the display cogs filling a scan line buffer while the display cog is drawing it. Either a single buffer or double buffer method can be used here, depending on the peak fill rate needed. I don't think I've seen a double scan line buffer driver, unless baggers higher end WOLF3D does that. It might, due to the very high fill rate required for that one.
Multi-cog displays are most often used for sprites, though I did end up doing one for text, because of the cost of color lookups and their impact on resolution. It took two cogs to get 80 column "character mode" text on the screen, with color attribute capability. Sprite drivers sort the table of objects during the blanking period, then render them to a scan line buffer as the screen is being drawn. Sprites per line depends on number of render COG's, and a few cogs will get you 16 sprites per line, with each sprite being 16 colors, from a palette of the full color set.
An alternative to the ANTIC way of doing things would be to use a simple display list, where the display reads from a string of bytes. Color palette info, character map offset, and or bitmap mode + start of display memory could be read, allowing people to use the screen in vertical strips. This method would not be too expensive, maybe even rendering with a single video cog. Characters could be "stacked" together to render graphics areas, and even duplicate those, if needed.
Full on bitmaps could plot curves and such too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
www.acm.org/press-room/news-releases/2010/turing-award-09
Mister Thacker certainly deserves the price. I have emulated the Alto and know the design to the chip. It's fascinating what you could do with a bucket full of TTL chips.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
My main reason for organizing thigs this way was for flexibility, though, rather than space savings.
-Phil
The VECTREX video game system consisted of an ordinary yoked small TV tube
and a 6809 and a couple of 8 bit DACs, which means you could make Asteroids
or Tempest with a Prop and a small analog TV, methinks. Cheaper than o-scope tubes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
A similar structure is found in modern 3D graphics displays, where triangles are linked into lists for texture mapping, and overall display culling of back faces, different Z depths, etc... A solid object is tessellated, then those triangles are sent to the graphics device, along with a whole bunch of other stuff, to be processed in specific order by the graphics system. Done right, the moving of things only requires a few transforms be written to be applied to the list on the next frame.
I am wanting to make a vector display for the Prop for viewing on my O-scope sometime. If a 6809 can do it, and it can --the VECTREX is excellent, a Propeller should have no trouble with doing vectors at all. And, having one or maybe two COGs blasting out vectors would make for a great setup. No interrupts and such to contend with...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I wrote a vector graphics driver for the Prop as part of the VGA version of Space Wars and BattleZone (800x600 4 color image attached - it also does resolutions up to 1152x864, but only with 2 colors).
See here: http://forums.parallax.com/forums/default.aspx?f=33&m=284807
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 3/13/2010 4:31:37 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
An oscilloscope suitable for vector graphics can be made out of a small TV,
and I have tried this and noticed also that the VECTREX system works that way also.
EDIT: Although people commonly repaired their own TVs in the 1970s, it was and is
a dangerous exposure to
are extremely careless, OR extremely terrified, and litigious about hazards.
In any case, the memory requirements of a true vector graphic list of X,Y endpoints
is very low, and the driver for the amplified DACs controlling a small TV yoke is so
simple that it can probably be written in SPIN following the code that generates
the list of endpoints for the image, such as a game, within the game loop.
Lines are made simply by changing the endpoints through the DACs that power the
tube yokes. Like an analog oscilloscope, these lines are not made of pixels, and
thus each line may only need two bytes (X,Y) in the display list or buffer.
I might as well ask, do those "vectorgraphic drivers" somehow convert vector graphic
Cathode Ray coordinate data DIRECTLY into NTSC without a display buffer,
or merely simulate vector graphics using a bitmapped display buffer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
Post Edited (VIRAND) : 3/13/2010 11:47:31 PM GMT
I got your intent perfectly, but have no intention of modding an old TV. At some point, I'm going to do a custom display on the scope though!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!