Full Color Tile Driver Thread

[Dr_Acula]

I know VGA better so here is a documentation of how to create icons:
1) Find some images
2) Do a screen capture with paint shop
3) Do copy/paste and size to 64x64 pixels
4) Paintfill the outside with black if it is white or another color.
5) Colors/Load Palatte and load the VGA 64 color palatte. Changes to these colors
6) Colors and increase the depth to 24 bit (makes the maths easier below)
7) Save as a RAW file (raw binary data, 3 bytes per pixel, no headers)
8) Run a tiny vb.net program

    Private Sub Button92_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button92.Click
        Dim b As Byte
        Dim i As Long
        Dim j As Byte
        Dim k As Long
        Dim Bitmap(12287) As Byte ' 64*64*3
        Dim Output(4095) As Byte
        Dim BinaryInput As New BinaryReader(File.Open("c:\" + TextBox46.Text, FileMode.Open))
        Dim BinaryOutput As New BinaryWriter(File.Create("c:\" + TextBox47.Text, FileMode.Open))
        For i = 0 To 12287
            Bitmap(i) = BinaryInput.ReadByte
        Next
        j = 0
        ' propeller format is RRGGBBxx
        For i = 0 To 4095
            b = Bitmap(i * 3)
            j = 0
            If b = 0 Then j = j + 0 ' 00 red
            If b = 85 Then j = j + 64 ' 01
            If b = 170 Then j = j + 128 ' 10
            If b = 255 Then j = j + 192 ' 11
            b = Bitmap(i * 3 + 1)
            If b = 0 Then j = j + 0 ' 00 green
            If b = 85 Then j = j + 16 ' 01
            If b = 170 Then j = j + 32 ' 10
            If b = 255 Then j = j + 48 ' 11
            b = Bitmap(i * 3 + 2)
            If b Then j = j + 0 ' 00 blue
            If b = 85 Then j = j + 4 ' 01
            If b = 170 Then j = j + 8 ' 10
            If b = 255 Then j = j + 12 ' 11
            Output(i) = j ' store value
        Next
        For i = 0 To 4095
            BinaryOutput.Write(Output(i))
        Next
        BinaryInput.Close()
        BinaryOutput.Close()
        MsgBox("Done")
    End Sub

9) save as a name ending in .ico (they are actually binary files so rename as .bin to view)
10) Copy file to sd card
11) Run the attached spin code (a hybrid of Ariba's screen driver and Kye's sd card, with behind the scenes debugging using the VT100 VGA driver)

I think the Prop is ready for graphics!

So, next little thing -

a) getting Ariba's code to work so the pixels are smaller (same hub ram, most of screen is black)
b) translating these .ico files into TV

Is there a simple table that converts the 64 vga colors into the nearest TV color?

Failing that, a table for RGB to TV colors. (In some ways it would be better to start with the 24bit original file rather than the one that has been reduced to 64 bits).

This operating system is called PotatoDOS.

[Tubular]

Just starting to read through this thread and its relatives. Lots of good stuff going on here.

Quick question; How many grey scales are possible using the techniques outlined so far, for TV out (either NTSC or PAL) ? Are we still limited to 6 levels, or can they be blended to make 11 levels, or more?

thanks
Tubular

[potatohead]

Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

@Dr_A: Easiest path is probably just to capture the RGB values, and go that route. When I get to my prop computer, I'll post up something that relates to the color table, adjusted for safe display values. I think the one in use on this thread is a little bit liberal. (A few of the lower intensity values may not display.) The latest Potatotext has a solid table. Need to double check.

Next steps for me is to go from a byte to word on tile addresses. Easy mod for the TV driver running right now. Then, start on VGA. Either one gets converted to scan-line capability, or Baggers scan-line type driver will work, which ever comes first!

His results indicate we are gonna get 320 pixels on a dual cog driver, so the truth is, the drivers will just about match up. Vertical resolution on the TV is 200, VGA a bit more, with horizontal resolutions matching up nicely at 320, or 160, maybe 256/224.

**Almost seems to me, with some creative work, SPIN could process images like VB can. Just a thought. We can open big files now, and it just occurred to me that kind of thing is now possible.

[Dr_Acula]

All very encouraging!

320 pixels divide by 64 with gaps will give 4 icons, times however many rows. The program space to display these and process them will take a bit of space. The one posted above is about 4k of program space, though this could be less if you use BST and eliminate unused spin methods. There will need to be a mouse driver as well, but actually, the code needed to put a few icons on the screen and a mouse and work out which one has been clicked is not going to be very big. Mabye 6 or 8k?? So lots of room for display buffers.

If you make the icons always 64x64, and use a color depth of 24 bits, and save as a RAW image, it is always 64x64x3 bytes long.

Processing that on the propeller could be quite possible. Might even be better given some people don't have vb.net. Only need to do it once to convert a 12k raw image to a 4k .ico (binary) file. Could do that as a spin file compiled to a binary with vt100 drivers and the local keyboard. You could run that from kyedos, and when this is working, run it from PotatoDOS. That starts to get into the spirit of having an operating system that you run files from. The smaller the files, the quicker they load too.

I'm thinking about the formula if you do a conversion from 24 bit to TV colors. eg, say you had 4 shades of gray like the VGA is, with transitions at 85, 170 and 255. Then the break points divide 255 into 4 parts. So 0-63 maps to 0, 64 to 127 maps to 85, 128 to 191 maps to 170 and 192 to 255 maps to 255. Actually, even that is not quite correct as there is not equal weighting for the colors.

At the moment I'm letting paintshop work out the closest colors but for TV, the program is going to have to work this out.

If you wanted to run "Icon Builder for TV and VGA", click the attached icon? For a spin program, it could produce both files, maybe instead of calling them .ico you call them .tv and .vga, and depending on the display you pick the one to display. Then you only have to build icons once.

I'm amazed at the colors you can get even with only 64 colors. TV is going to look even better at 96. And like you say, the blurring you get with TV will probably improve the look.

[ericball]

Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

Note: Six grey levels is what the Propeller composite video generator can do. Three bits = three pins = three resistors = eight output levels = 2 sync levels + 6 grey. With my "better TV color" driver the aural sub pin is used to push the sync levels up to give a 7th grey (and a second black), but that's about it. To get more greys you'd need to either drive the pins in VGA mode as one big DAC for greyscale only output. Or you'd need to sync two cogs so one produces the normal 6 greys and a second would add additional LSBs. The disadvantage with both schemes is 1. requires a non-standard board and 2. uses more pins.

[Oldbitcollector (Jeff)]

Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

Does this translate into more colors if we would be willing to use a non-standard video circuit? Sounds like win here.

OBC

[potatohead]

I'm curious to hear Eric's reply.

Yes. I see it breaking down two ways. If we run the Prop in TV mode, we get the same hues, but more shades, if there are more resistors.

If we run in VGA mode, TV drivers get more complex, but there would be more of both. Eric wrote one of these, and it's complex, and timing dependent. Pixel sizes won't vary like they can now, but the picture would be great. Dual COG driver solutions would be needed, because of the need to drive color in software.

RAM still is at issue though, which is why I never did much personally. Fleshing out byte per pixel to something closer to 256 colors would be good, because we do that now. Going higher seems impractical because resolution would have to be low because of RAM.

[ericball]

Does this translate into more colors if we would be willing to use a non-standard video circuit? Sounds like win here.

Let's back up here and see what we have to work with.

On the Propeller side the main limitation is around the WAITVID instruction, which allows 4-16 pixels (at 4 colors) to be output with a single instruction. Driving OUTA directly is too slow. The video generator has two color formats: composite (4 bit PSK/hue, 1 bit color enable, 3 bit luma driving 3 pins) and VGA (8 bits which are sent directly to the pins).

On the TV side, the composite input expects a luma signal with color difference signals quadrature modulated at the colorburst frequency. Luma is easy, that's just a time-varying signal. The color signal is the hard bit.

My 240H sprite driver has a larger color gamut because it drives the 4 pins (3 pin TV DAC + aural sub) at 4 times the colorburst frequency, which gives full control over the color difference signals. But that means performing 1 WAITVID per pixel - so the pixels are stored in cog RAM and multiple cogs are required.

One way to generate more colors would be to have two synchronized cogs with two 3 or 4 pin DACs. One cog would generate the "MSB" the other the "LSB".

On the other hand, if you want "VGA color" output, I know there are RGB to TV chips. It may be easier to simply use those.

I guess my question is what's the target? Most Prop users usually get excited about solutions which use fewer pins, fewer cogs and less RAM - not more.

[Dr_Acula]

I guess my question is what's the target? Most Prop users usually get excited about solutions which use fewer pins, fewer cogs and less RAM - not more.

Re pins - everything is a compromise, but for the boards I'm using, the top 8 do serial ports/mouse/keyboard/I2C, then next 8 down do VGA, the next 4 down do SD card and there are 12 pins free.

So if you are using 8 pins for VGA, you could use those 8 pins for TV too. That makes the color depth more, right?

Re cogs, this particular demonstration is for an operating system that is capable of loading new compiled binary files off the sd card. So the OS uses one cog for the spin interpreter, one for the SD card driver, and there will be one which will probably be a combo mouse/keyboard. So that leaves 5 cogs free for display drivers.

Re ram, I think there is about 24k free. Again, this would be used in an operating system that then loads new programs. The OS itself will be doing very simple things - detecting mouse clicks, key presses and loading pictures off the sd card. Then loading binary files and running them (Kyedos does all this in 'text mode' so this is just the graphical equivalent.)

So - lots of ram, pins are a compromise but there are 12 free, and up to 5 cogs.

This is for a tile driver in an OS. Of course, once you have such a thing, it can be used in other ways. I'd be thinking of Catalina running in external memory, which can be 512k in size for sram, or 32mb in size on jazzed's board. That also frees up virtually all the hub ram (all but the top 2k). And the ability to load cogs from within catalina, so you could do clever things like temporarily blank the screen while you load those cogs with other cog code.

I think this means you have a lot of hub ram to use.

I've been playing around with what we can fit on the screen. If you have one byte per pixel, by my maths 160x120=19200 bytes. If icons are 64x64, then you get four on a screen. If two are arrows, then clicking each arrow moves a list of icons along. That could be useful.

You could do more cunning things, eg if each icon is 64x64, that is 4096 bytes, so you could fit six into hub memory as long as the display driver put in some blank lines in between each icon.

I'd be inclined to stick with simple standard drivers for the moment.

Ariba's driver is 128x96 - which can only fit two icons side by side.

You could shrink the icons but they lose some resolution.

So a question to ask would be whether this driver can be recoded for 160x120, and if so, can it also be recoded so the pixels are smaller and the display ends up in the middle of the screen?

The attached file is 160x120 with propeller VGA colors.

[Kye]

Hey, I found that I have time to make a driver for this on friday. Should be able to roll out something nice for use by the morning.

Thanks,

(I'm just gonna take my bitmap driver and modify it.)

[Dr_Acula]

Kye, that sounds great!

More experiments. Start with what we have and then it can grow. So - this is using the full 12k of Ariba's driver, with Kye's sd card interface.

Attached is a photo of the screen. This could be the beginnings of an operating system - click the arrows and the icons scroll along. Click the icon and it runs that binary. Or use the keyboard arrow keys and Enter. Maybe the 'active' icon is the top left one? Or maybe draw a border round it in software?

Ariba's screen is 128x96, so for four icons that would make each icon 64x48.

[ericball]

So if you are using 8 pins for VGA, you could use those 8 pins for TV too. That makes the color depth more, right?

Sorry, no. VGA has 5 outputs: 2 pins each R G & B, 1 pin each H & V. So to reuse those pins for TV you'd need some kind of external 8:16 demux to select a different set of resistors to make a single composite output. So if you have the pins to burn, better to simply dedicate 3 pins to a normal TV DAC.

Hmm.. I wonder whether there's enough time & space in the driver to do a lookup. Encode the icons with a color value then do a lookup for the equivalent VGA or TV bytecode.

[Dr_Acula]

I was going to produce two files - one with the vga bytes and one with the tv bytes.

Re changing between TV and VGA using the same pins - could you do that with some headers? Even if it was up to 16 headers?

[ericball]

I was going to produce two files - one with the vga bytes and one with the tv bytes.

Probably the easiest way. Pre-process so the cog only has to fetch a long from HUB RAM.

Re changing between TV and VGA using the same pins - could you do that with some headers? Even if it was up to 16 headers?

Sure. You just need some way select which resistor network and output connector to use. You could use a 3x8 header and 8 jumpers. Or use one of the existing daughterboard connectors.

[Dr_Acula]

Attached is a little experiment with a smaller icon. This is the propeller icon resized to 32x24 and reduced to the 64 vga colors. Then placed in a 128x96 black display to give an idea of the scale. With smaller icons like this, one could fit 4x4=16 icons on a screen using code we have now.

If you had icons 32x32 then you would fit 4x3=12 icons in a screen.

I think the windows default in XP is 32x32.

[potatohead]

One big problem with the tiles as currently implemented is their addressing. It sucks, because the images need to be broken into little pieces, then re-assembled on screen. I was building the TV test pattern tiles I said I was going to capture, and it's laborious with 4 pixel, sequentially addressed tiles.

Two changes coming:

1. Word tile addressing. That's easy, because 8K of tile data doesn't allow the Prop to be fully exploited, and the extra bits in the words might open the door for text tricks. Not sure on that, but it's a option.

2. Address change.

Right now, the tiles are 4x8, and they live as sequential longs in the RAM. That's the trouble.

I'm going to change it so that the addresses are non-sequential, so that larger images can be loaded into RAM directly, not in pieces. I'm thinking about 32 or 64 pixel x say 32 pixel chunks. That way, one larger icon can be developed to be used as a whole, or in pieces, avoiding most of the tile building work.

What this means is somebody could use a graphics program, and define a 32x32 bitmap, or maybe a bigger one horizontally, and just paste things into it. If that is saved as GIF, with a one byte palette associated with TV or VGA, then the resulting file can be used directly, included into the project as a "file: tile1.gif", then placed on screen by simply calling out the tile addresses in the screen array. This will make producing graphics viable, with only the matter of either avoiding, or stripping the header off the graphics file being needed to get the images to a useful state. For "pieces", it's pretty great too, because the source bitmap can just be considered a grid, containing lots of tiles. Paste in, or draw the desired goodies, and load, and display on screen by tile number. A simple chart can make this workable.

That's where I'm headed next, as that can be used on any tile driver that ends up getting written, VGA and TV.

Not sure where Baggers is with VGA scan-line drivers, but I'll give that a go this weekend. No time until then. The existing drivers look favorable for 256 pixels at least, and we know Baggers got 320, so I think that's just a code and timing exercise to connect a graphics cog to a modified VGA driver signal cog. He is using the lower VGA timing, which makes the drivers more or less match up. 320 pixels is the target horizontal resolution. Enough for graphics detail that will more than satisfy this "let's do cool icons" project Their placement and size on screen will be able to vary considerably with the new tile addressing, with a lot less grunt work or code being required to format the data in a way that makes sense to the Propeller graphics COG.

(or render COG to a graphics COG, if that lingo makes any more sense)

There is not enough compute time in a single COG to do tiles in this way at higher resolutions. Bitmap only. A highly specialized bitmap COG could possibly accomplish the "put a tiny bit in the middle of the screen" task, but honestly, if that's to be written, we might as well get the tiles right, and easier to use on VGA and TV, so that lots of different graphics are possible. The prep work will be modest with the addressing changes.

Aside from that, bitmaps are really easy!! However, it's not really possible to exploit the Propeller fully using them alone. There isn't enough HUB memory, meaning we need to populate the blank areas with as little as possible, focusing the data on the non-blank areas, and ideally allow for positioning. That means either sprites or tiles, and for this work, tiles are nearly done, so I'll do tiles. Maybe we can add sprites, with a third COG. Could do a pointer, or something with a few of those, and a few per line will be possible with a third COG. That will mean one signal COG, one tile or bitmap render COG, and one potential render sprites COG. Truth is, only a sprite COG could be running as well, if one didn't care about the tiles. I'll build my stuff that way, so that door is open.

More from me soon, when I get the work grind behind me

[Kye]

Just finished rolling a 160x120 6-bits per pixel driver. I need to finish a demo and finish polishing the code and I'll post it to the OBEX.

Its very colorful!!! I should have it up by tonight!

[potatohead]

Awesome!! is it scan-line, or bitmap?

[Dr_Acula]

This all sounds fascinating. I'm still digesting potatohead's post - there are some complicated concepts in there.

Re file formats, I have not looked at .gif recently. .bmp is simply rgb bytes and there is a header at the beginning which has the file size and a few other things. I've been using .raw which is .bmp without the header.

Ariba's code has an array pixel[] in the main, and at the beginning you tell the vga cog where pixel[] starts, so from then on you just read things into the pixel array at the right place. For a 32x32 array at an arbitrary position x,y, there is a little bit of maths involved - r*128+c and then put in 32 bytes, then add 128-32 for the next position. I'll see if I can turn that into a pub where you pass the filename and the x,y position and the filesize.

If one considers special cog code that uses tiles, one could have a tile that is all black, and then have something like icon,blacktile,blacktile,blacktile,icon and one could potentially have something that has n icons at the proper small size in arbitrary positions on the screen. 32x32 icons are 1024 bytes, so maybe 20 of those. 64x64 icons are 4k. And then the data for one black tile.

Creating icons does take a bit of artistic work in paintshop - capturing, resizing, decreasing the color depth etc. It probably is not possible to automate this completely. Things work better in a certain order too - eg resize before decreasing the color depth.

Looking forward to seeing your code, Kye!

[Kye]

Its a bitmap, and uses more than half your memory. But, it gives you the colors.

As for a scanline driver... not possible for VGA. I say this because if I can't fit the code in the video loop to figure out how to translate a tile map... making another cog do so won't give me anymore time.

And believe me. My tile map driver PUSHED the propeller chip to the limit. I have expierence with this stuff in VGA. If you try doing this scanline by scan line you won't have enough time.

Since TV goes at a lower frequency a scanline buffer is possible.