.PIC images

[BSJR]

N x 3 in the byte table, and N x 3/2 in the nybble table

The main question is - are you sure that the tables contain the correct values? How were these values obtained?

George Gwilt once wrote In QLToday on colour conversion and used real calculations.
In an article about PNG this was formulated as: output = ROUND(input * MaxOutSample / MaxInpSample) .
But the same text also mentions Bit Replication which was giving almost identical results (not tested by me!).
e.g. Then the 3 m16 bits are written in the 3 high bits of an 6 (or 8) bit sample and repeated in the next 3 bits etc.

My "calculation" was for high to low mode and is actually mostly testing the bits and setting the bits.
For up scaling of the QL-2-QL modes in BMP/SQRview also pre-defined tables are used.
In QCP, where a single colour is converted I use the Replication method.

The tables used were probably supplied by M.Kilgus (and who dares to challenge those) but in early tests of SQRview I also tried BMPCVT by W.Lenerz and the "original" tables from the "Graphics Device Interface 2" document by Tony Tebby and found significant differences in tables when converting BMP16 to QL mode 16.

BSJR

[pjw]

N x 3 in the byte table, and N x 3/2 in the nybble table

The main question is - are you sure that the tables contain the correct values?

No. I dont know that these are the correct values. They are my best guess.

How were these values obtained?

At first I extracted the information from the tables given in GD2user_doc by Tony Tebby. However, there are certain anomalies, including apparently missing and duplicate entries. I tried a lot of different things including calculation (its a long time ago now, so I dont remember it all). However, in the end I just decided to physically test every possible RGB value and record how SMSQ/E translated them. That is the basis of my tables.

The thing is, I only tested on QPC2, as the testing program takes a long time to run its course, so it may be possible that SMSQmulator and Q68 come up with different results. Have a go yourself, if you like!

I slightly changed the program (attached) to remove any reference to strange and unusual toolkits. To run it: Boot your system into 8-bit (mode 16) display mode and then EXecute the program (dont RUN it). Then go and have lunch. Or if you want to try it on Q68, you should probably start it before you go to work in the morning and see how its got on when you get back. (You may want to check your smoke alarm before you go..)

The program produces two outputs in ram1_. 1) the assembler table youve already seen above and 2) a quick list so you can easily compare results with any other method you might wish to try.

[Dec]

This would allow variable size QL graphics files without the need to fit, stretch or centre the source file if it is not 512x256 pixels. In other words, graphics files can be any size, not just 512x256 pixels.

Added. Need to be tested.

But the same text also mentions Bit Replication which was giving almost identical results

I use Bit Replication in my tool.

I found AuDetail.pdf (Hardware details of the Aurora board) in the Internet and there is a good description of mode 256:

Bit: 7 6 5 4 3 2 1 0
Pixel info: G2 R2 B2 G1 R1 B1 G0 RB0
G2,1,0 = green, G2=MSB, G0=LSB
R2,1 = red, R2=MSB
B2,1 = blue, B2=MSB
RB0 = Red/Blue compound bit 0.
G2..1 translate directly into a 3-bit value for the green component
R2..1 and B2..1 translate directly into the top 2 bits of the 3-bit red and blue components.
RB0 generates, in conjunction with R2..1 the LSB of red, R0, and in conjunction with B2..1 the LSB or blue, B0, as follows:
R0 = R[2] * RB[0] + R[1] * RB[0] + /R[2] * /R[1] * /B[2] * /B[1] * RB[0]
B0 = B[2] * RB[0] + B[1] * RB[0]

Therefore:
R2 R1 B2 B1 RB0 R B
0 0 0 0 0 0 0
0 0 0 0 1 1 0
0 0 0 1 0 0 2
0 0 0 1 1 0 3
0 0 1 0 0 0 4
0 0 1 0 1 0 5
0 0 1 1 0 0 6
0 0 1 1 1 0 7
0 1 0 0 0 2 0
0 1 0 0 1 3 0
0 1 0 1 0 2 2
0 1 0 1 1 3 3
0 1 1 0 0 2 4
0 1 1 0 1 3 5
0 1 1 1 0 2 6
0 1 1 1 1 3 7
1 0 0 0 0 4 0
1 0 0 0 1 5 0
1 0 0 1 0 4 2
1 0 0 1 1 5 3
1 0 1 0 0 4 4
1 0 1 0 1 5 5
1 0 1 1 0 4 6
1 0 1 1 1 5 7
1 1 0 0 0 6 0
1 1 0 0 1 7 0
1 1 0 1 0 6 2
1 1 0 1 1 7 3
1 1 1 0 0 6 4
1 1 1 0 1 7 5
1 1 1 1 0 6 6
1 1 1 1 1 7 7

I closed the question regarding mode 16 for myself.

Now I only have a question about converting 5-bit values to 6-bit values in mode 32.

Have a go yourself, if you like!

I am not a QL platform user. I'm just a developer who writes a program that allows user to convert images for various retro platforms.

[BSJR]

I closed the question regarding mode 16 for myself.
Now I only have a question about converting 5-bit values to 6-bit values in mode 32.

I am not a QL platform user. I'm just a developer who writes a program that allows user to convert images for various retro platforms.

The mode 32 colour word is actually rrrrrggg.gggbbbbb, so the 5-bit to 6-bit only applies to the green part.
A simple value doubling or left shift will make the 6-bit. Replication the high bit into the low bit finishes it off.
However, any mode 32 image file will have the bytes swapped because in practice mode 32 only exists on emulated platforms which are mostly Intel based.

BSJR

[Dec]

The mode 32 colour word is actually rrrrrggg.gggbbbbb, so the 5-bit to 6-bit only applies to the green part.

Since the green part already has 6 bits, perhaps you mean that the transformation from 5 to 6 bits only applies to the red and blue parts?

A simple value doubling or left shift will make the 6-bit. Replication the high bit into the low bit finishes it off.

Is this documented somewhere or just a guess?

However, any mode 32 image file will have the bytes swapped because in practice mode 32 only exists on emulated platforms which are mostly Intel based.

So mode 32 is a mode that has never been implemented in real hardware?

Is there a list of real boards that support extended color schemes? Aurora, Q40/Q60... something else?

[dilwyn]

Here's the makings of one. I'll need help to fill in the columns marked '?', or to correct any mistakes, or add any platforms not included, as I don't have all platforms and emulators.

Since mode 32 / mode 33 follow little endian/big endian, it tends to follow that mode 32 are on emulators on Intel-processor machines, while mode 33 tends to be on Motorola-style processor platforms (i.e. hardware). The less obvious one is the QXL, which was an ISA card with a Motorola processor which plugged into and ran on a DOS or Windows PC.

I'd hazard a guess that emulations of QL in software are more common than hardware systems with the exception of a BBQL itself.

Code: Select all

---------------------------------------------------------------
               MODE 4   MODE 8   MODE 16   MODE 32   MODE 33
                                           (Intel)   (Motorola)
---------------------------------------------------------------
QL             yes      yes      no        no        no
AURORA         yes      yes      yes       no        no
Q40            yes      ?        ?         no        yes
Q60            yes      ?        ?         no        yes
Q68            yes      yes      yes       no        yes
QLem           yes      yes      no        no        no
QPC1           yes      yes      no        no        no
QPC2           yes      yes      yes       yes       no
SMSQMULATOR    yes      yes      yes       yes       no
QL2K           yes      yes      no        no        no
QLAY           yes      yes      no        no        no
QEMULATOR PC   yes      yes      yes *     no        yes *
QEMULATOR Mac  yes      yes      ?         ?         ?
uQLx           yes      yes      no        no        no
sQLux          yes      yes      no        no        no
QDOS4Amiga     yes      yes      no        no        no
QDOS Classic   yes      yes      no        no        no
ATARI ST-QL    yes      yes      no        ?         ?
QXL            yes      yes      no        yes       no
MESS emulator  yes      yes      no        no        no
MIST-QL        yes      yes      ?         ?         ?
MISTer         yes      yes      ?         ?         ?
ZEsarUX        yes      yes      no        no        no
---------------------------------------------------------------

*=with relevant version of SMSQ/E on QemuLator

[tofro]

So mode 32 is a mode that has never been implemented in real hardware?

Is there a list of real boards that support extended color schemes? Aurora, Q40/Q60... something else?

Depends on how you define "real hardware". The QXL boards use mode 32 and definitely are "real hardware". Screen output, however, is done on a PC that is hijacked by the "parasite" QXL.

[XorA]

Here's the makings of one. I'll need help to fill in the columns marked '?', or to correct any mistakes, or add any platforms not included, as I don't have all platforms and emulators.

Since mode 32 / mode 33 follow little endian/big endian, it tends to follow that mode 32 are on emulators on Intel-processor machines, while mode 33 tends to be on Motorola-style processor platforms (i.e. hardware). The less obvious one is the QXL, which was an ISA card with a Motorola processor which plugged into and ran on a DOS or Windows PC.

I'd hazard a guess that emulations of QL in software are more common than hardware systems with the exception of a BBQL itself.

Code: Select all

---------------------------------------------------------------
               MODE 4   MODE 8   MODE 16   MODE 32   MODE 33
                                           (Intel)   (Motorola)
---------------------------------------------------------------
QL             yes      yes      no        no        no
AURORA         yes      yes      yes       no        no
Q40            yes      ?        ?         no        yes
Q60            yes      ?        ?         no        yes
Q68            yes      yes      ?         no        yes
QLem           yes      yes      no        no        no
QPC1           yes      yes      no        no        no
QPC2           yes      yes      yes       yes       no
SMSQMULATOR    yes      ?        ?         yes       no
QL2K           yes      yes      no        no        no
QLAY           yes      yes      no        no        no
QEMULATOR PC   yes      yes      yes *     no        yes *
QEMULATOR Mac  yes      yes      ?         ?         ?
uQLx           yes      yes      no        no        no
sQLux          yes      yes      ?         ?         ?
QDOS4Amiga     yes      yes      no        no        no
QDOS Classic   yes      yes      no        no        no
ATARI ST-QL    yes      yes      no        ?         ?
QXL            yes      yes      ?         yes       no
MESS emulator  yes      yes      no        no        no
MIST-QL        yes      yes      ?         ?         ?
MISTer         yes      yes      ?         ?         ?
ZEsarUX        yes      yes      no        no        no
---------------------------------------------------------------

*=with relevant version of SMSQ/E on QemuLator

sQLux is "yes yes no no no" the same as uqlx

[BSJR]

A simple value doubling or left shift will make the 6-bit. Replication the high bit into the low bit finishes it off.

Is this documented somewhere or just a guess?

Each extra bit doubles the range so a 1-bit left shift for each sample does the trick.
The formula I quoted earlier should also work.
The modes have been published in various QL publications in the past but strangely, it's not explained in any of the QPC2 pdf's like Manual, Concepts or Keywords. It was featured in the GD2 document by Tony Tebby.
https://dilwyn.qlforum.co.uk/docs/smsqe ... D2user.pdf

However, any mode 32 image file will have the bytes swapped because in practice mode 32 only exists on emulated platforms which are mostly Intel based.

So mode 32 is a mode that has never been implemented in real hardware?
Is there a list of real boards that support extended color schemes? Aurora, Q40/Q60... something else?

A PAPER/INK command will need the original Word, the Intel flipped Word is identical to the colour Word used by BMP's 16-bit mode and thus I expect, will be compatible with the 64K colour mode graphic cards may expect.

To further complete Dilwyn's list:
Q68 will do mode 8 and mode 16 as well.
SMSQmulator will also do mode 8 & 16.
QXL will NOT do mode 16.

SMSQ/E has conversion routines built in for all modes but these are only automatically used for PE Sprites.
Although High Colour sprites will not be converted down to mode 4 or 8, a default 'X' cross will be seen instead.
QL PIC Viewers will need to have their own conversion code.

BSJR

[dilwyn]

To further complete Dilwyn's list:
Q68 will do mode 8 and mode 16 as well.
SMSQmulator will also do mode 8 & 16.
QXL will NOT do mode 16.
BSJR

Thanks Bob (and XorA earlier).
I'll amend my original list with the extra info, then put it on my website once complete.