Bitmap VGA driver that can do Palette or HAM modes?

tonyp12

There is not really a limit how good the gfx could look on the propeller,
if you simple had more onboard ram.

But let's limit ourself to a 24kb bitmap and what possible video mode can be done?

280x180 4bit with a color pallate lookup table?

Thousands of colors·done with·Hold and Modify mode?
http://en.wikipedia.org/wiki/Hold_And_Modify





·

Ahle2

Hold an Modify is a really good idea, and shouldn't be any problem to code in ASM.
I'm willing to give it a shot.

HAM was what made the Amiga the most "colorful" computer around when it was released in 1985.

tonyp12

HAM_4096 would need 6bit.

a 24kb bitmap could have max resolution of 210x160

(210x160/8*6)

I wounder if it would be better NOT to store the bimap the same way Amiga did it in Bit Planes?
but 6bit data put in 32bit longwords does not add up either.

And where can you find a Windows Program that can save to·raw ham6 mode?
A good HAM picture would need some smart analyzing for the base 16color palette.

Here is a simulated 24kb ham picture.


Post Edited (tonyp12) : 4/14/2009 4:56:41 PM GMT

ericball

Once you have drivers (and hardware) which can generate more than 64 colors then you can think about storage formats.

In order to get more VGA colors out of the Prop, you're going to need to have wider DACs, i.e. more than the current 2R2G2B. Also, the video generator is only capable of 8 bits per pixel, so if you are doing more than 8bpp you will need to run two cogs in parallel. You might be able to get some additional "bits" via high frequency dithering; although I don't know whether that is truely feasible.

One easy change would be to use the two pins normally tasked to H & V sync to R & G instead and generate H & V sync outside of the video generator. That would bump up the number of colors to 256 shades 3R3G2B.

virtuPIC

Didn't know about HAM so far. I owned an Atari ST. Looks very interesting!

But as already mentioned we need a DAC. Digital outputs with resistors are not suited for 6 bits per channel and VGA pixel frequency. I just had a look at ti.com. DACs that are fast enough are only available in single channel. The TLC7524 is available for less than four dollars at DigiKey.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

tonyp12

Without using 14pins for 4r4g4b+H+V I guess 4096 colors is out the question.


What other realtime de-compression for 6bit graphics would be suitable?

4bit HAM would only save 33%.

Some type of delta compression?
12 pixels in a 32bit longword would save 65%

OwenS

If your using 4bpp, you may as well go for S3TC and get 16bit colour out of it. Of course, you then have the problem of how do you use that 16 bit colour, but...

tonyp12

here is a Commodore64 streaming video in realtime.
http://www.youtube.com/watch?v=knZyPXcelYM

I'm pretty sure·they use some type of compression, that is not to heavy on the cpu.
·

Baggers

owens, 4bpp would still give 16 colours not 16bit, and as stated, for >256 colours you'd need the extra dacs, or two vga cogs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

OwenS

I was saying that S3TC in DXT1 mode takes 4 bits per pixel for 16* bits of output

* Actually, you can get slightly more out of it - but 16bpp is the easiest way of putting it :P

Baggers

Yeah, I did a DXT1 on the original PropGFX, when it was using 15bits RGB and one bit for Sync, using SCART but US don't have scart cables in their TV's so we went back to composite.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

tonyp12

Can DX1 be used for 64color (2r2g2b)·images with decent result?

Could a VGA driver be created that draws VGA images in realtime from DX1 data?

http://cache-www.intel.com/cd/00/00/32/43/324337_324337.pdf

I'm trying to avoid having one cog decompressing to a buffer
and when the vga cog to work displaying it.


I understand that DX compression takes 4x4 pixels (16 pixels in a block) and gives it a color space number and direction.

As we only have 64 colors, wonder if something similar could be created by using a lookup table?

Create a·table of 256 different color pattern, and then use the one with closest match.




Post Edited (tonyp12) : 4/14/2009 10:03:26 PM GMT

OwenS

I felt compelled to implement it, so...

Code removed

Smile! I forgot to divide each of the colour components individually...

-- Addition:

DXT1 takes a 4x4 grid of pixels. From those, it selects two colours, c0 and c1. c2 is 2/3*c0 + 1/3*c1 and c3 is 1/3*c0 + 2/3*c1. Since it uses 16-bit colour, thats the first 32 bits consumed. (I'm ignoring alpha masking for now)

The second 32 bits is a lookup table. Each 16 pixels divided by 32 bits means colour gets 2 bits. This, as you may guess, looks up from c0 through c3.

Hmm... You could implement DXT1 for 8bpp by just packing all 4 colour components into the first 32 bits.

Which I've just modified my code to do, removing the need to fix it to unpack and repack the RGB components [noparse]:)[/noparse]

' Inputs:
'   mapAddr   The address of the S3TC data for the 4x4 pixel group
'   row       The row of pixels to get from the group
' Outputs:
'   p0..p3    The calculated pixels
'
' Time: 130 clocks for 4 pixels / 32.5 clocks per pixel
' (Assuming hub synchronization)
' Health warning: Code is completely untested
' (Legal disclaimer: S3TC is also patented)

                RDLONG c0, mapAddr      ' Read the colour information       '
                MOV c1, c0              ' Copy into C1                      '
                ADD mapAddr, #4         ' Advance to LUT                    '
                RDLONG lut, mapAddr     ' Read the LUT                      '
                SHR c1, #8              ' Shift C1                          '
                AND c1, #$FF            ' Mask it                           '
                MOV c2, c0              ' Copy into C2                      '
                SHR c2, #16             ' Shift C2                          '
                AND c2, #$FF            ' Mask it                           '
                MOV c3, c0              ' Copy into C3                      '
                SHR c3, #24             ' Shift C3 (No mask)                '
                AND c0, #$FF            ' Mask C0                           ' [noparse][[/noparse]48cy]

                SHL row, #3             ' Calculate number of leading bits to skip to get row
                SHR lut, row            ' Skip said bits                    ' [noparse][[/noparse]56cy]

                MOV w, lut          '                                       '
                AND w, #3           ' Mask in only the bits we want         '
                ADD w, #c0          ' Add address of c0                     '
                MOV p0, w           ' Load that into the pixel value        '
                SHR lut, #2         ' Move to next pixel                    ' [noparse][[/noparse]76cy]

                MOV w, lut                                                  '
                AND w, #3                                                   '
                ADD w, #c0                                                  '
                MOV p1, w                                                   '
                SHR lut, #2                                                 ' [noparse][[/noparse]96cy]

                MOV w, lut                                                  '
                AND w, #3                                                   '
                ADD w, #c0                                                  '
                MOV p2, w                                                   '
                SHR lut, #2                                                 ' [noparse][[/noparse]116cy]

                AND lut, #3                                                 '
                ADD lut, #c0                                                '
                MOV p3, lut                                                 ' [noparse][[/noparse]130cy]

lut             .resl 1
c0              .resl 1
c1              .resl 1
c2              .resl 1
c3              .resl 1
p0              .resl 1
p1              .resl 1
p2              .resl 1
p3              .resl 1
w               .resl 1

Post Edited (OwenS) : 4/14/2009 8:54:14 PM GMT

Sapieha

Hi

Why not drive 2 COGs pararell on 2x8 pins that give You 4R4G4B pixel.
That must be doable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

virtuPIC

I've got at least a solution regarding the DAC. I looked for video-DAC instead of regular DAC and got a few results:

• TI has THS8133/4/5 triple DAC at 80 MSPS. Should be good enough for VGA.
• Analog Devices offers ADV7172/3 NTSC/PAL video DAC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys