If I store a PIC file of an area of the screen in MODE 8, which measures 202 pixels across, that is not exactly divisible by 2. You need 100 bytes to store the first 200 pixels and an extra 2 bytes to store the last 2 pixels (due to the fact that 1 word stores 4 pixels).
As a result, the PIC header would need to read:
$4AFC
202
50 (presuming height of area is 50 lines)
102
8
Is this correct??
Yes. for a width of n pixels the "increment" (ie the number of bytes per line of n pixels stored in the PIC file) would be
2*((n + 3) DIV 4)
For mode 4 the "increment" would be
2*((n + 7) DIV 8)
This assumes that the pixels in the screen image are packed to the left in each line. If, for example, you wanted to save the 2nd to the 9th pixel of a Mode 4 screen you would have to pack the information for these 8 pixels into two bytes to be saved after the header. The information would come from bits 0 to 6 of the first screen byte, bits 0 to 6 of the second bytes, bit 7 of the third byte and bit 7 of the fourth byte.
At least this is what I would do. In fact I have written programs to save and print parts of a Mode 4, Mode 8, Mode 32 and Mode 33 screen, but I have restricted Modes 4 and 8 to widths divisible by 8 and 4 and starting on word boundaries.
It just takes a wee bit more programming to extract or print areas which are not on word boundaries and not multiples of 4 or 8.
Question.
In my PSA files (as I call them in case PIC files are in a different format from the partial save areas defined in Jochen's QPTR manual) I use 4 or 0 in byte 12 to indicate mode 4. How does a PIC file do this? I use 32 and 33 to indicate these GD2 modes. There seems to be the possibility of confusion here in the coding of GD2 modes 0, 4 and 8. Does anyone know how PIC files cope here?
George
