Shop OBEX P1 Docs P2 Docs Learn Events
Full Color Tile Driver Thread - Page 3 — Parallax Forums

Full Color Tile Driver Thread

135678

Comments

  • TubularTubular Posts: 4,620
    edited 2010-11-16 22:13
    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
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-16 22:47
    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_AculaDr_Acula Posts: 5,484
    edited 2010-11-17 01:27
    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.
    128 x 128 - 3K
  • ericballericball Posts: 774
    edited 2010-11-17 05:40
    potatohead wrote: »
    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)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-11-17 07:02
    potatohead wrote: »
    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
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-17 07:29
    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.
  • ericballericball Posts: 774
    edited 2010-11-17 08:34
    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_AculaDr_Acula Posts: 5,484
    edited 2010-11-17 14:37
    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.
    160 x 120 - 6K
  • KyeKye Posts: 2,200
    edited 2010-11-17 16:05
    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_AculaDr_Acula Posts: 5,484
    edited 2010-11-17 16:42
    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.
    640 x 480 - 41K
  • ericballericball Posts: 774
    edited 2010-11-17 18:09
    Dr_Acula wrote: »
    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_AculaDr_Acula Posts: 5,484
    edited 2010-11-17 18:17
    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?
  • ericballericball Posts: 774
    edited 2010-11-17 18:23
    Dr_Acula wrote: »
    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.
    Dr_Acula wrote: »
    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_AculaDr_Acula Posts: 5,484
    edited 2010-11-18 05:06
    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.
    128 x 96 - 3K
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-18 11:35
    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 :)
  • KyeKye Posts: 2,200
    edited 2010-11-18 13:38
    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!
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-18 14:00
    Awesome!! is it scan-line, or bitmap?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-18 15:14
    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!
  • KyeKye Posts: 2,200
    edited 2010-11-18 15:39
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-18 15:44
    Its a bitmap, and uses more than half your memory. But, it gives you the colors.

    Sounds fantastic. No problem using half the memory. Indeed, I think one could probably use more - at least up to 20k.

    Just a thought. Say you had a 640x480 vga screen. And say you had tiles 32x32. Say you can 20 of these in memory making 20480 bytes.

    For arguments sake, tile 1 is black (but it could be any color really) and all the other tiles are icons.

    Then you have a tile list. 640x32 is 20, and 480/32 is 15. So you have 300 bytes storing numbers 1 to 20.

    Then you print them out eg tile 1,tile 1, tile 10, tile 1, tile 1, tile 1, tile 15 etc

    Every 32 bytes on a scan line you need to load in the next tile number and change a pointer to a new location in hub ram. So you do that 20 times on a scan line of 640.

    Do you think a vga driver would be fast enough to add this extra code (eg a 2 cog driver)?
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-18 16:55
    Dr_A, that's very close to the change I mentioned above.
  • KyeKye Posts: 2,200
    edited 2010-11-18 17:09
    Here's what I've made. I don't plan on working any harder. While two cog VGA solutions give better results I do not wish to make one.

    I'll put this driver up in the OBEX.

    (Edit - Its now in the OBEX http://obex.parallax.com/objects/686/)
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-18 17:20
    That looks good Kye. 160x120 will give enough 64x64 icons and more than enough 32x32. Can't wait to get home and try this.

    Re potatohead - so you are working on a big full color tile driver? My father in law likes to run his PC with a black background, so with tile driver code and 20 icons, it could look rather similar to a PC home screen, or an ipad. That would be a propeller OS that would be 'familiar'.

    Thinking of icons, there are times you want small ones and times you want bigger ones. I'm thinking of taking a 64x64 bitmap with the original 24 bit color and using this to produce a 64x64, 32x32 and a 16x16 in prop colors, both TV and VGA.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-18 17:29
    Yes. It will still be a lot of little tiles, but...

    If the addressing of the pixels is done correctly, 16x16 bitmaps can be loaded directly into the Propeller, maybe 32x32, whatever size works out in code.

    Then, when placing them on the screen, one can choose any origin tile location, within 4 pixels, allowing for placement anywhere within reason.

    Because it's tiles, the 320 pixels can be used, as not all the HUB memory will be consumed.

    Baggers has 320 on VGA, so I'm hoping those can be matched up for a nice "all-color" solution. However, I'll probably take what Kye did, and see what may be built from there.

    On the next pass at this code, I'll post up some detail info on tiles that should clear up how things can work. People have the same general trouble with the Parallax driver, and so that info probably will be of good general use.

    It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-18 17:38
    It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.

    That sounds brilliant.

    16,32 and 64 seem to divide well into the screen sizes. I'm thinking in terms of icons at the moment, but one could always take a number of icons and put them next to each other for a bigger picture. So you could click on an icon of a photo, and then bring up a 128x128 picture or maybe even bigger.

    Some of that could be built on the fly. Eg click on an icon of a clock, and it shuts down the operating system and runs a new binary that reads the time and displays it on a nice 128x128 clock, that you build up in software. You could even have the clock face as a bitmap and then draw the hands on in software. Then when you shut that down it reloads the operating system binary.

    Intriguing possibilities...
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-18 20:39
    Exactly! That was where my mind went when you first started musing about this idea.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-19 16:46
    Testing out Kye's driver. Lots of manual steps with paintshop to get here. Once we have an OS working, one little App that might be useful is to be able to convert a .bmp into a .tv and .vga picture.

    Abstract art and cartoons compress to propeller colors a lot better than photos.

    I started a new thread for the eye candy.

    Meanwhile, Icons.zip goes on the sd card, PotatoDOS gets compiled to the eeprom, and Photo.spin gets turned into a .bin file and goes on the sd card.

    There are some bugs - if just one picture or icon file is missing the whole thing crashes. And it is slow to load pictures but I can think of several ways to overcome that.

    Kye might have some advice, as this is the Kye SD code talking to the Kye 160x120 video driver code.
    640 x 480 - 49K
    640 x 480 - 36K
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-19 23:37
    A incremental update.

    This archive does WORD addressing for the tile indexes. It's capable of using all the HUB memory for tile displays.

    All tiles are 4x8 sequentially addressed, that change to the bitmap friendly tile addresses is next.

    Right now the tile addressing is still sequential. If you run the archive, I've defined a few black and white tiles for resolution tests. Nothing special, but useful for looking at how a tile works, and seeing the graphics product on screen.

    The next address change will be to arrange tiles in a grid of 16x32, or 32x32, or something that makes sense code wise, so that images may be made that size, and put directly to use by this driver, using "tile sets" of sequentially numbered 4x4 tiles to draw the image anywhere on the screen.

    At that point, several images can exist in the HUB, and placed on the screen with very little effort. That's possible now, but requires work to "stack" the 4x8 pieces into the right places on screen.

    VGA scan line type, driver coming up next, along with some actual image tile data and a document explaining how things end up in the HUB RAM.

    @Dr_A: Very cool to see those on the Prop! Nice conversions.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 08:53
    So I made a fat, beveled, grey scale "OK button" for a boring old GUI.
    With the fat pixels I have to use 6 tiles. Are thin pixels impossible ?
    {
    '--------------------------------------------
    ' draw a fat letter OK button
    
          TEXT.SetTile(0,1,8)   ' upper left
          TEXT.SetTile(1,1,10)  ' upper middle
          TEXT.SetTile(2,1,12)  ' upper right
          TEXT.SetTile(0,2,9)   ' lower left
          TEXT.SetTile(1,2,11)  ' lower middle
          TEXT.SetTile(2,2,13)  ' lower right
    '
    '--------------------------------------------
    }
    
    long  $06060606           '00_08    upper left
    long  $06060606
    long  $06050505
    long  $06050202
    long  $06050205
    long  $06050205
    long  $06050205
    long  $06050205
    
    long  $06050205           '00_09    lower left
    long  $06050205
    long  $06050205
    long  $06050205
    long  $06050202
    long  $06050505
    long  $05040404
    long  $04040404
    
    long  $06060606           '00_10    upper middle
    long  $06060606
    long  $05050505
    long  $02020502
    long  $05020502
    long  $05020502
    long  $05020502
    long  $05020502
    
    long  $05020502           '00_11    lower middle
    long  $05020502
    long  $05020502
    long  $05020502
    long  $02020502
    long  $05050505
    long  $04040404
    long  $04040404
    
    long  $06060606           '00_12    upper right
    long  $06060604
    long  $05050504
    long  $05020504
    long  $05020504
    long  $05020504
    long  $02040504
    long  $02050504
    
    long  $02050504           '00_13    lower right
    long  $04020504
    long  $05020504
    long  $05020504
    long  $05020504
    long  $05050504
    long  $04040404
    long  $04040404
    
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 10:21
    Jazzed, thin pixels are going to be possible on my VGA driver.
    ( Potatohead, it's 256 pixels wide, as couldn't get 320 at 5Mhz especially with sync correction oring $03030303 )

    64 * 30 * 4x8 chars

    will be posting demo of it in a mo.
Sign In or Register to comment.