256x224 video driver

Dr_Acula · 2011-08-31 18:55

These are some photos of experiments with a 256x224 color driver.

This is using a propeller and an external sram chip on pins 0-23 with a HC374 latch.

The code is using three cogs and most of the hub memory is used for a video buffer.

It ought to be possible to move all the 'object' code such as the serial driver into the 'main' program and then put the cog code into the hub buffer. If this technique works then there would be enough room for code in all 8 cogs, including code to do things like "draw a line", "draw a box", "draw a button".

Code is in the second post - there is the propeller code and also the vb.net code to do the Floyd-Steinberg dithering and download the pictures via the serial port.

Dr_Acula · 2011-08-31 18:55

Code attachments and more screenshots

Cluso99 · 2011-08-31 22:28

Nice work Drac.

Rayman · 2011-09-01 06:11

Nice work. Looks like we are working on similar things...
I just got dithering working for my PTP2 image processing utility...
I'll try to add TV and VGA palettes to it today...

I'll tell you one trick I just learned... I call it "self-indexed" bitmaps. Basically, I create 8bpp Windows Bitmaps
where each byte of index data equals the actual 8 (or 6) bits we want to output on Prop pins.
This way, you can use actual Windows Bitmaps directly as image data files without any conversion required.

These self-indexed bitmaps can then be viewed both on a PC and a Prop board...

Dr_Acula · 2011-09-28 06:16

Experimenting with several displays here. The 4:3 display is in the background running kyedos. In the foreground is a 16:9 widescreen display. If we take a widescreen picture, compress it so it is narrow, and then display it on this monitor then it ends up the correct width again.

The ratios are slightly different than 16:9 (and 4:3) and have been determined by drawing circles and measuring them on the real screen.

Next step is moving sprites around on the screen.

Dr_Acula · 2011-10-03 06:03

Writing code now for a GUI driver. Sprites are working and they are very fast and there is around 490kilobytes of ram free for sprites. I have a theory that you can drive a GUI with just three types of instructions:
1) Send a line of pixels
2) Capture a block of pixels and store to ram
3) Restore a block of pixels from ram to the screen

For instance, you can send all the letters of the alphabet in whatever font and capture these with little sprite blocks, then redraw those in any order to write text.

Or, capture a "checked" checkbox and an unchecked one, and print which ever one is relevant.

The control instructions become something that can be written in any language you like - C, Spin, Basic. Eg, this is the control instruction to click on a button. Store two images of the button - the normal one, and the 'pushed' one (which happens to be the normal one rotated 180 degrees). Each instruction is 8 bytes and then you can add a comment byte. CSV file. Bytes are 1=write/2=read then origin_x, origin_y, sizex, sizey, block (7 to 127), ram high byte and ram low byte.
Blocks of memory are 4096 long. The first 7 blocks are used by the ram buffer but the rest are free.

1,80,30,30,30,9,0,0,gray square for erasing
1,10,30,60,30,7,0,0,copy button down to latch 7
1,10,60,60,30,8,0,0,copy button up to latch 8
2,10,60,30,30,9,0,0,erase down button
2,40,60,30,30,9,0,0,erase down button
2,10,30,60,30,8,0,0,display button down
2,10,30,60,30,7,0,0,display button up

Attached is the spin program. Hardware is a propeller, 512k memory chip and a HC374 latch.

Dr_Acula · 2011-10-09 05:25

Next little challenge is fonts. Take a variable with font and work out the width of each letter. That is about 100 lines of vb.net code all up. Then put a little colored box around each letter and save that as a screen image. This can be downloaded to the board, and it is something that a sprite program can understand. Capture each little letter as a variable size sprite and store it in ram.

Then the GUI text box can retrieve these in any order and make up the text. I'm hoping to get around 64 sprites moved during the blanking period at the end of each screen. 30 frames a second = 1800 characters a second. Hopefully fast enough for a text editor. Scrolling should be faster because the sprite can be a line rather than a character.

Cluso99 · 2011-10-09 05:46

Interesting concept drac. On the old pcs and prior there was no available processing power so these things were not possible.

Dr_Acula · 2011-10-25 00:18

This probably won't work.... but.

Can we pull data out of a ram fast enough to bypass the hub?

I've been looking at the 74F series (F for Fast), eg the 74F161 counters. Put two in series and preload some latches for A8 to A18 on the ram and drive A0-A7 with the counter. Then clock 256 bytes in from the ram.

This is the current video loop:

:xloop2                 rdlong  pixels,ptr
                        add     ptr,#4
                        xor     pixels,phaseflip
                        waitvid pixels,#%%3210
                        djnz    x,#:xloop2
                        jmp     #:done

Replace the rdlong with an ina
Relace the add with a pin going high to clock the counter
Replace the phaseflip with that pin going low

The ram /rd is held low through the entire 256 bytes so no toggling of the /rd or /wr or /cs pins on the ram.
And the ram outputs have time to settle while the waitvid happens.

Time to rejig the breadboard. And even if this doesn't work, it might find a use as a fast cache driver.

256x224 video driver

Comments