NEW 640 x 480 2-4 Color VGA Bitmap Driver

[potatohead]

Seriously! Don't blame you one bit. If you don't need the features, video is easier and a lot more fun as a single cog affair.

Really, part of the post was to leave the how-to out there, and let Dr_A, know there is a path --just not a easy one.

(nice driver, BTW!! your code is great to read)

[Dr_Acula]

You think there is a path?! *pricks up ears*

Yes I can't see how with the one cog driver, but with the two cog vga driver...

It is a matter of, on average, taking 6 instructions or less per pixel. At the very simplest level, you are writing the same value of a byte to an incrementing memory location in cog memory. My feeling is that might be even faster than reading a byte from hub ram. Might that not be possible with only 3 or 4 instructions?

[Electronegativity]

Thank you very much Kye for taking the time to do this and being generous enough to share it.

I'm sure you saved me at least a month of work.

[Kye]

Thank you very much,

Please note however that drawing on the screen using SPIN code is painfully slow. You may have to recode your drawing functions in assembly.

[potatohead]

@Dr_A Well... It seems to me, one cog is kind of out of the question, just because the extra indexing and decisions would probably render the video loop too long, meaning one would have to make several cases... That gets complex very quickly.

However, a graphics cog could very easily be filling a scan buffer, based on the screen list data... Two cogs are probably necessary, which means building out the basic connection outlined above.

The Spacewar game was written with a higher resolution display that operates at a greater resolution than RAM can handle. Perhaps that makes sense? Worth a look.

Then there are tiles. The Parallax drivers are tile based, and get the benefit of the graphics.spin COG. Some simple display management could yield a nice, high resolution display, using the tiles, and some code to manage them too. Depends on what the display is. That's probably easier than dealing with rebuilding the list, and graphics can be shared too.

[Dr_Acula]

Hi Potatohead,

Tiles sound interesting.

I've just spent some time deep inside the code for the two cog hi_res vga driver. Now, this is very cunning code, but I do not understand all of it. I am trying to understand where the data gets stored before it is displayed. There is a buffer "scanbuff[128]" which is 512 bytes, but elsewhere it says it stores four lines of data. 640x4 is more than 512 bytes, so I am thinking it only stores bits, not bytes, and maybe because it only has two colors for that particular line it only needs to store bits.

In which case, how is your spacewar code storing colors? (6 bits per pixel for max resolution).

So the first problem one might face is that for 6 bits per pixel, one has to store 640x6 = 480 bytes or nearly 1/4 of the cog memory for just one line. So clearly you can't store 4 lines.

You do save some considerable space with respect to the hi_res vga driver in that you don't need to store all the character bitmaps.

The other bit of code that I can't understand is

scanline                mov     vscl,vscl_chr           'set pixel rate for characters
                        jmp     #scancode               'jump to scanbuff display routine in scancode
scanret                 mov     vscl,#hs                'do horizontal sync pixels

where #scancode does not seem to exist anywhere as a label in the code.

I guess this comes back to a generic question - what is the highest vga resolution the propeller can drive? Limit maybe to 640x480 display, can one do 4x4 pixels as a block with individual colors? Can one go to 2x2 pixels? What is the best resolution one can do with tiles assuming that most tiles might be all white? Can tiles take you to a solution where most of the screen is white, but at an arbitrary location is a really detailed tile with all 6 bits of color per pixel?

I'm particularly interested in this as Catalina can be configured to work in external ram, so that pretty much frees up all the hub ram for video.

[potatohead]

I've not looked at that code much.

But... Let's talk pixels for a moment. Basically, we can get 1 bit per pixel, 2 bits per pixel, and 8 bits per pixel out of a waitvid. Waitvids work with the concept of a 'frame' which is a pixel group.

The first line of code you asked about is setting a waitvid frame timing. That's your pixels over time. Another line somewhere sets the size of a pixel, in terms of time, with the two of them together determining what a waitvid does with the pixels.

eg: Let's say a pixel is 3 clocks, and we set a frame size of 24 clocks. Really that should be PLLA, not clocks, because the waitvid works off of PLLA.

So, that's 8 pixels, three PLLA each. That waitvid would then draw 8 pixels, from the pixels long, assuming 1 or 2 bits per pixel. It would not use all the data given to it.

Perhaps that parameter you cannot locate is a constant, or is computed and written at run time?

For higher resolutions, you want the whole frame, and you want the pixel clock as large as it can be, so that the waitvid spends the max time drawing things, so your COG has the max time fetching things for it to draw. That means you really want the full 16 or 32 pixel frame, at 1 or 2 bits per pixel.

Higher resolutions then mean 1 or 2 bits per pixel, because the 8 bits per pixel is fixed at a rather fast 4 pixel frame. "waitvid colors, #%%3210"

Seems to me, a 160 byte scan line buffer would hold one scan line. Typically a scan line buffer exists in the HUB, so that all the working COGs can contribute to it, not the COG. COG indexing, fetching, and bit manupulation, if one wants bytes, is actually not too much faster than just fetching from the hub, because computation is generally needed anyway. One has to add indexes, subtract from counters, maybe perform a bit operator, etc... so that get done between hub fetch cycles.

If you don't mind TV, and feel you can map over to VGA, I've got a old version of potatotext that isn't text yet, and that is a two COG scan line buffer graphics engine. I'll get it, and post it, so you can see much simpler code. VGA requires more sophisticated timing, and runs at higher sweep frequencies, putting more demands on the prop. TV runs rather easily at 640 pixels, by comparison. I think exceeding 640, takes multiple COGs just to draw the signal, and that's the resolution I personally would target. 1280 can actually be done, though it took Chip 5 COGs to do it

How fast is external RAM fetch? I think it's got to be on the order of 3Mhz to make any sense for refreshing video, and TV is the slowest and easiest video to refresh.

If you got a tile display running, and just FYI, the Parallax driver does those tiles, and colors at 640 pixels on the VGA, one could simply maintain a lot of tiles in external RAM, moving them into and out of the HUB as needed for a lot of display variety. If you do the moving during VSYNC, it will be tear and flicker free too. Or, just don't do it faster than say, 15Hz, and it will look nice too.

[Dr_Acula]

Hi Potatohead,

I've just downloaded every vga driver I could find on the obex. I suspect there are more out there in the wild too, but the one that does look intriguing is the 1280x1024 tile driver. This uses 3 cogs.

I'm still not sure about tiles, but let us assume you have a display and 80% of the display is white, ie you have a white tile and you replicate this many times. So this saves a huge amount of hub ram. But, right in the middle of the screen, you have some tiles with lots of data - each pixel is the full color range (6 bits). I wonder if this is possible?

What I'm thinking of is buttons that use bitmaps for the button. So the prop is a bit like an ipad, really easy to use with picture buttons that you press.

I just did an experiment in paint shop taking a picture and decreasing the color depth to 64 bits. It does not look too bad. Not as gorgeous as an ipad, but certainly faces are recognisable.

With an sd card, it is easy to move bitmaps into hub ram.

What I'm not entirely sure is the color depth of tiles, and whether there is code out there that can do a tile in full 64 bit color (even if it is only a tiny tile in the middle of the screen and the rest of the screen is black).

[jazzed]

What I'm thinking of is buttons that use bitmaps for the button. So the prop is a bit like an ipad, really easy to use with picture buttons that you press.

Having a driver that does this would be a great thing. When you can't tell the difference between Propeller generated GUI and a modern phone GUI you can say something *really cool* has been done.

[potatohead]

Well, tiles are generally 2 color, or 4 color, because of how the waitvid works with pixel and color data.

If you want "full color", then it all comes down to running the waitvid backward, for a 4 pixel frame.

"waitvid colors, #%%3210" colors become pixels done that way, otherwise there are more pixels than colors, imposing the familiar 4 color / tile limits.

In a normal waitvid, there are four colors possible, and up to 32 pixels. It all gets loaded in there, for the waitvid to crunch on, while the cog gets the next data set.

So tiles at full color, really are multiples of 4 pixels. And full color displays operate at a lower resolution, because each waitvid is only four pixels.

I've done over 320 pixels at full color on TV graphics, with one COG. I think that actually can hit 512 at 80Mhz, but it's been a while since I did that. The code is actually on the Wiki, under "hi-color bitmap" in the old list of drivers there. Never did because of lack of RAM.

Anyway, your are on the right track with the tiles and saving space. Basically, all white, or all black tiles can be represented by a single tile definition in HUB RAM, which is basically where the video has to live, unless you are able to fetch data fast enough from external RAM.

It is entirely possible to do what you want to do. IMHO, what is required is to find a driver that runs the waitvid backward, like I put above, or recode one so that it does that. That means redoing the video loop to use 4 pixel frames, and adding a counter or two for your tile sizes.

Have you considered 16 color?? Baggars has done sprite drivers that do that, and that have palettes! Look at the VCS driver he did. It can do a hell of a lot of sprites.

Either way, say you setup 16 pixel tiles at full color. You divide the display into 16 pixel zones, horizontal and vertical. Each tile is 4 longs wide, by 64 longs deep.

Tiles can be done two basic ways. There is the Parallax way, shown in the Chip VGA drivers. I really like that way, because it's flexible. Basically your "screen" is just this array of words that contain tile addresses, one address per tile in the display. You fill the array with the addresses where the data lives, and the driver then draws out the pixels, fetching addresses, and computing offsets based on the scanline being drawn.

The other way is basically the "text mode" way, seen in older computers, and my text drivers. Tiles occupy a chunk of HUB ram, and have a start address. The "screen" is a series of bytes, each one referencing a tile number. Again, the driver computes addresses and offsets based on the byte read, and the scan line drawn.

Advantage of the text mode way is a more efficient means to store the screen. It's just bytes, and for larger screen sizes can be a nice savings. Disadvantage is there are only 256 tiles possible. At your tile sizes, that would be enough.

Advantage of the Parallax way, when using less than full color, is a very easily exploited waitvid, for lots of colors and tiles, and the use of the graphics.spin library. For your idea, graphics.spin won't work because you would be operating at 8 bits per tile.

One thing to consider is time spent bit mashing. Propellers are slow at this, because the COG addressing is longs only. It is best to just operate at 8 bits per pixel, knowing there is some waste, because expanding the 6 bits into 8, to feed the waitvid will cost you too much compute time.

Eric Ball wrote a sprite driver that's seriously worth a look. It's TV, and it's 224 pixels, but... it draws a lot of sprites. The sprite engine part of that could probably be used on a VGA driver.

Sprites can be freely placed, but there can only be so many of them.

I don't think anybody has done a text + sprite driver in full color yet. The few full color drivers there are, either are bitmap, or sprites, but not both, and most of them are for TV, or were coded for a specific game.

IMHO, having both would be sweet, but it's going to be pushing the edge of what has been done. (possible though, just not done for lack of RAM)

Did you find a driver that does full color for VGA? I don't recall seeing one. There are TV drivers for bitmaps, most recent being the one I posted to draw fractals at full color, that can easily be made to do tiles. I don't recall seeing one for VGA yet. Probably because the resolutions are high enough to require some work, and nobody yet has come along asking to do what you are thinking of doing.

Would you be able to live with 320 pixels horizontal?? TV maybe to prototype it? I'm asking, because there is a lot of close TV code. A 16 pixel wide tile driver for TV would not be too difficult at one byte per pixel.

[Dr_Acula]

This is an intriguing discussion.

So - would it ever be possible to build a tile that has all 64 colors in one tile? Even if the tile was tiny and the rest of the screen was black?

Just to see if this is worth pursuing, I hand coded a palatte in paint shop. There are three colors and each color has the value 0, 85, 170 or 255. 64 colors in all.

The first attachment is the full palatte. There are some interesting colors in there, including skin tone colors.

There is a picture of me (to demonstrate skin tones), a lorikeet, an outdoor shot, a shot in the snow, and I think the color depth is enough to recognise the pictures.

But it is the last one pic6 that I find the most intriguing. This is a screen capture of the prop tool (I saved it as a bitmap as jpg blurs the text) The graded color bar along the top window has been converted to discrete colors, but the rest of the screen looks almost identical to the real thing.

Consider the data in this screen. There are a lot of tiles the same color (white/yellow), and if you coded this screen by describing each line in terms of the change in color (50 white pixels, 25 gray pixels, 100 yellow pixels) I wonder if that data could be decoded on the fly?

[potatohead]

A 16 x 16 pixel tile consumes one page of RAM. 256 bytes at full color.

On a VGA, that's 64 colors. On a TV, that's more like 80-120 or so, depending on how brave you are, and your display tolerance. 90 colors for sure.

You can get 64 of those tiles into 8K of RAM, for example. At 320 pixels, that's a nice set of colorful tiles. 320 pixels can absolutely happen. Edit: 32 of these. Somewhere, my math broke down.

Is that useful? Would you guys actually build GUI type stuff with that kind of driver? Nobody asked before. I can do it for TV, easy. With some creative tile management in the VBLANK, a mouse can move over it too. Just need 4 tiles to buffer the mouse, and combine it with the other on-screen tiles.

That's a 20 x 12 tile display, BTW. Enough to do something?

[Dr_Acula]

Those tiles would be more than enough.

re "Would you guys actually build GUI type stuff with that kind of driver?"

Yes, and I think it would look really cool.

I think the secret to this might be to use Catalina with external memory, and hence free up pretty much all the hub ram (all but the top 2k, which is used for a stack and intercog comms).

So say you had some simple C code that grabbed a little bitmap, put it in a tile and put the tile on the screen. Have maybe ten tiles on the screen, and the rest of the screen is black. You could move through a menu of choices very quickly. Menus might run other programs, eg KyeDOS can load binaries so you could start off with the pretty GUI, but run boring old text wordstar from that. Or keep it purely GUI. Many choices.

Attached - lorikeet shrunk down to 64x64 pixels and 64 colors. On a black screen, this is 8k of data so you could fit a few of these into hub ram at any one time.

[potatohead]

Isn't that 4K of data??

[jazzed]

Is that useful? Would you guys actually build GUI type stuff with that kind of driver?

Well sure! Just having Ok and Cancel buttons with 3D look/feel would be great. Couldn't stop there though. What about a 3D border and corners for window frames? I imagine much more is possible.

I can do it for TV, easy. With some creative tile management in the VBLANK, a mouse can move over it too. Just need 4 tiles to buffer the mouse, and combine it with the other on-screen tiles.

That would be like a big cream filled doughnut. Hard to resist.

Even 4 of those 256 byte 64 color tiles rendered all at once would be great for buttons.

How would a user provide pointers and x/y offsets for "button buffers" ?

How many longs would be left in the TV and/or VGA COG?

[potatohead]

*just booted into XP. All my Prop dev stuff is there. Can't make my killer video capture work on Windows 7 yet, and it's annoying as all get out.

I'll see where I get to. Bottom line is some older potatotext code, that is still single COG would work great for this.

Memory map would have to be:

screen = 20x12 bytes, used as indexes to the tile map

tile map = 1 page / tile, for as many as the user chooses to fit, or end of HUB RAM is reached. ($FF / tile)

1 other page to deal with parameters and such.

The rest is up to the user. If the mouse is needed, 4 tiles would have to be reserved as the "redraw buffer", and some code space for the tile swap logic needed. In full color, it's possible to just copy the tiles, draw the mouse over them, then assign those screen coordinates to the buffer tiles. That would happen anytime the mouse moves. I've seen that done on older character display computers. Never done it myself, but that can't be hard.

I'm going to see about just getting the tile display working on TV, and see what you guys do with it. If it's worth it, then ports can be done. Can't promise any more than that right now.

About half the screen, max, could be filled with unique tiles, if the RAM isn't doing much else.

[jazzed]

Sounds exciting. Maybe another thread?

[Dr_Acula]

Ok, lets put it on another thread. 64 color tiles in vga or tv or both.

And yes potatohead you are right, 64x64 is 4096 bytes. I was looking at the filesize on paintshop. Use catalina with 30k of space, and we could put 8 of those on a screen. More if you use less colors or do clever things like a tile that is a corner and a tile that is a line.

This would make a cool demo, especially if it came with a skeleton code to step through menus and do things.

[potatohead]

Well, I'll start a thread as soon as the basic driver is done. Got a nice start on modding potatotext to do tiles this evening.

320 pixels @ 80Mhz, full color = no problem. Target is 16x8 pixel tiles, on a 20x24 grid, BTW. That appeared to be the best balance for all elements in this case. Good screen coverage, moderate density, resolution.

TV cog is done, tile cog in progress, other cogs possible, and I'll comment stuff so that can be done.

(got my arse kicked on PAL, and life got in the way too If this sees use, maybe I can get some hints, or help from somebody here to try that again, so it's NTSC for now, sorry)

[Dr_Acula]

Sounds good. Do you think VGA is possible?

The attached image will fit into hub ram because most of it is black. 64 colors. If each button brought up sub menus you could do some clever things. I'm thinking of something like kyedos behind the scenes that can load binary files when you click an icon.

With the palatte loaded into paint shop, it is easy to create icons. You could save them as binary files, or text files with numbers 0-63. And it ought to be possible to load them from an sd card as needed.

Second icon is a true 64x64 icon.

If your tiles are 16x8 then maybe make icons 64x64?