Bellcom disk 481, part 2, or flipping bits for fun

Entry posted by Atari_Ace August 3, 2018

438 views

In the last post we partially restored the first sector of Girl6.pic by splicing in some data into the RLE stream to represent 160 zero bytes. But we have a slightly different version of the picture, so in principle we can completely restore the picture from that and some ingenuity.

First, let's expand out the first column of GIRLJ.PIC (our more complete picture) and see what it looks like.

     0  00 00 00 00 aa aa aa aa-aa 9a 7a ae a9 a9 a6 a9   ..........z.....
    10  a5 a9 aa aa ab 9f af 6b-67 56 69 55 95 55 55 55   .......kgViU.UUU
    20  55 55 95 55 65 a9 a5 55-59 55 fd f9 ff fe ff ff   UU.Ue..UYU......
    30  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    40  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    50  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    60  00 00 00 00 aa a9 aa a9-a9 aa a9 aa aa 65 aa a6   .............e..
    70  a9 aa aa 9a ab 9f af 6b-96 59 aa 95 55 55 55 55   .......k.Y..UUUU
    80  59 55 99 69 a9 65 59 65-55 dd fd fe fb ff ff ff   YU.i.eYeU.......
    90  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    a0  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    b0  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................

I'm guessing each byte represents 4 horizontal pixels, and that the sequence of bytes is the entire column, but apparently not in linear order. We don't really need to know the layout exactly, we simply need to assume we can infer the layout from another part of the file. Since the rightmost part of the picture is empty except for the border, we can expand out GIRL6.PIC, and look at the last 160 bytes to work out the layout. In those bytes, we only see the values 0x03, 0xff, and 0x00. Assuming the 0x00s are locations that are blank in all the 160 byte blocks, we can zero the same locations here, yielding the following.

     0  00 00 00 00 aa aa aa aa-aa 9a 7a ae a9 a9 a6 a9   ..........z.....
    10  a5 a9 aa aa ab 9f af 6b-67 56 69 55 95 55 55 55   .......kgViU.UUU
    20  55 55 95 55 65 a9 a5 55-59 55 fd f9 ff fe ff ff   UU.Ue..UYU......
    30  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    40  ff ff ff 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    50  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    60  00 00 00 00 aa a9 aa a9-a9 aa a9 aa aa 65 aa a6   .............e..
    70  a9 aa aa 9a ab 9f af 6b-96 59 aa 95 55 55 55 55   .......k.Y..UUUU
    80  59 55 99 69 a9 65 59 65-55 dd fd fe fb ff ff ff   YU.i.eYeU.......
    90  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    a0  ff ff 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    b0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................

The next thing we notice about the picture is that the entire outside of the picture has been set to lightest color, which turns out to be color #3. So we need to bitwise or every non-zero byte here with 0xc0 (since we want the left pixels to be changed to color 3). We also want to set the bytes at offset 0x64 and 0xa3 to 0xff, since in the last column those are 0xff and that should represent the first and last lines of the border in the picture. This yields:

     0  00 00 00 00 ea ea ea ea-ea da fa ee e9 e9 e6 e9   ..........z.....
    10  e5 e9 ea ea eb df ef eb-e7 d6 e9 d5 d5 d5 d5 d5   .......kgViU.UUU
    20  d5 d5 d5 d5 e5 e9 e5 d5-d9 d5 fd f9 ff fe ff ff   UU.Ue..UYU......
    30  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    40  ff ff ff 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    50  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    60  00 00 00 ff ea e9 ea e9-e9 ea e9 ea ea e5 ea e6   .............e..
    70  e9 ea ea da eb df ef eb-d6 d9 ea d5 d5 d5 d5 d5   .......k.Y..UUUU
    80  d9 d5 d9 e9 e9 e5 d9 e5-d5 dd fd fe fb ff ff ff   YU.i.eYeU.......
    90  ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
    a0  ff ff ff 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    b0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................

Now we need to RLE encode these bytes into the file. It turns out the RLE for this is exactly the right size to fit into the 91 bytes we have available in the sector to contain these 160 bytes, strongly suggesting this is the right data restoration. So we end up with the following for sector 556.

011590: SECTOR: 556: FILE:
     0  ff 80 c9 c7 1a 00 01 01-0e 00 28 00 c0 22 25 27   ..........(.."%'
    10  0c 00 69 0a 00 00 9b 9b-9b 9b a2 04 00 05 ea 83   ..i.............
    20  da fa ee 02 e9 84 e6 e9-e5 e9 02 ea 87 eb df ef   ................
    30  eb e7 d6 e9 09 d5 8a e5-e9 e5 d5 d9 d5 fd f9 ff   ................
    40  fe 15 ff 20 00 84 ff ea-e9 ea 02 e9 82 ea e9 02   ... ............
    50  ea 84 e5 ea e6 e9 02 ea-88 da eb df ef eb d6 d9   ................
    60  ea 05 d5 83 d9 d5 d9 02-e9 88 e5 d9 e5 d5 dd fd   ................
    70  fe db 16 ff 21 00 95 95-96 69 96 65 95 52 2d 7d   ....!....i.e.R-}

And the picture even looks correct.

That was more work than I originally intended to expend on this disk, but it allowed me to learn at least a little bit about the MicroIllustrator compression format, so I think it was time well spent.

481.atr