This week I've been extending the PiTubeDirect framebuffer to work better with 16bpp and 32bpp modes.
I have a question for the RISC OS folk....
I think I understand the background to TINT (VDU 23,17,0..3), i.e. why it was necessary for Acorn to introduce this ugly hack when transitioning from 64 to 256 colour technology, and that this is not now the preferred way of setting colours.
Beyond 256 colours, Acorn abandoned setting colours through the VDU interface, instead relying on the OS_SetColour and ColourTrans_SetGCOL APIs. Up until then, pretty much any graphical operation could be done with VDU codes, so I think the implications of this change are significant. For example, it would limit the effectiveness of second processors on the Archimedes/RISC PC architecture, if such a thing was ever imagined.
Anway, I'm trying to understand whether TINT actually works in >256 colour modes, giving some kind of compatibility to existing applications on higher bit-depth displays.
I've written the following test program:
Code: Select all
10 MODE 640,512,32 20 W=1280:H=128 30 GCOL 0,16 40 FOR T=3 TO 0 STEP -1 50 Y=T*H 60 TINT 2,64*T 70 RECTANGLE FILL 0,Y,W,H 80 PRINT ~POINT(0,Y),~TINT(0,Y),~VDU 153, ~VDU 157 90 NEXT
Martix Brandy in a 8-bpp mode: Martix Brandy in a 32-bpp mode: The results are slightly curious...
If anyone could try this program on an actual RISC OS system (real or emulated is fine), I would be very grateful.
I'm trying to understand:
- whether TINT works at all in 32-bpp modes
- whether the resulting colours are the same between 8-bpp and 32-bpp modes
- what values POINT and TINT return (i.e. OS_ReadPoint)
- what values the VDU current forground colour/tint variables hold during the test