PCS format

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

bjw66
Atari User
Atari User
Posts: 37
Joined: Fri Jan 18, 2008 2:02 am
Contact:

PCS format

Post by bjw66 »

I did some searching and it seems like nobody knows what happened to Douglas LIttle.

I am trying to figure out the PCS (PhotoChrome) format. From what I've been able to find, there are no public specs for that format. Are there specs for PCS? I don't want to spend a lot of time trying to figure it out, only to find that it has already been done. Does anyone who is "active" have the specs? If not, no problem. I'll spend the time and share the specs.
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

bjw66 wrote:I am trying to figure out the PCS (PhotoChrome) format. From what I've been able to find, there are no public specs for that format. Are there specs for PCS? I don't want to spend a lot of time trying to figure it out, only to find that it has already been done. Does anyone who is "active" have the specs? If not, no problem. I'll spend the time and share the specs.
I just disassembled a PCS viewer. I think it won't be too hard to figure out the specs. It is just like spectrum only the color swapping is done a bit different. I think it is possible to write a much more compact display routine as used in the PCS viewer.

Did you already start reverse engineering? Or should I spent some time on this project (hadn't heard from OCS before; that's why it is not in my Atari ST picformats viewer).

Hans Wessels
bjw66
Atari User
Atari User
Posts: 37
Joined: Fri Jan 18, 2008 2:02 am
Contact:

Re: PCS format

Post by bjw66 »

Yes, I started reverse engineering. Here is what I have found so far:

The header is 8 bytes long. The first word gives the width, the second the height. Then 4 more bytes follow, which have something to do with the type of image. PCS comes in 4 types:
(1) PCS-ST: 48 colours per line out of 512. (3 components of 3 bits for the colours.)
(2) PCS-STE: 48 colours per line out of 4096. (3 components of 4 bits for the colours.)
(3) Super HAM: 4096 colours out of 4096 colours. (3 components of 4 bits for the colours.)
(4) STE PhotoChrome: 19200 colours out of 32768. (3 components of 5 bits for the colours.) This seems to mean that 96 colours per line are possible. (96*200 = 19200.)

Of those 4 bytes starting at offset 4, here are some values that I have observed that clearly seem to indicate which of the 4 types is used.

Type (1)
0x00 0x00

Type (2)
0x00 0xfe

Type (3)
0xfc 0x00
0xfd 0x00
0xfe 0x00
0xff 0x00

Type (4)
0xfc 0xfe
0xff 0xfe

Following the 8 byte header is the screen data for 200 scan lines, this is divided such that first there is all the data for plane 0 (8000 bytes after decompression), then plane 1, then plane 2, then plane 3.

A variant of RLE is used for the compression:

Take a byte b from the input.

If 0 < b < 128, then repeat the next byte b times. The screen data pretty much always starts with 0x28 0x00 in PCS files, meaning "store 40 zero bytes" (remember this is only 1 plane) because the first scanline cannot be displayed.

If b >= 128, then copy the next 256-b bytes from the input.

However, there is one thing I have not yet figured out in this, and that is what to do when b = 0. I can successfully decompress the screen data for files that do not have count bytes with value 0, but I don't know what to do when I see a count byte with value 0.

Following the screen data is the palette data. So far I have only looked at types (1) and (2) for this. They use the same variant of RLE, except that the count byte refers to numbers of words, not bytes. So 0xff 0x04 0x03 0x05 0x0f 0xff means "store 0x04 followed by 0x03, then store (0x0f followed by 0xff) a total of 5 times. The palette data contains 200 lines * 3 palettes per line.

I have only looked at a few PCS files so far, and the docs actually say that it tries two different compression schemes and chooses the best. So it seems like there is a different compression scheme that I have not encountered yet.
bjw66
Atari User
Atari User
Posts: 37
Joined: Fri Jan 18, 2008 2:02 am
Contact:

Re: PCS format

Post by bjw66 »

bjw66 wrote:However, there is one thing I have not yet figured out in this, and that is what to do when b = 0. I can successfully decompress the screen data for files that do not have count bytes with value 0, but I don't know what to do when I see a count byte with value 0.
OK, I have figured it out now. It's identical to the scheme used by the TNY format. So let me correct what I said earlier:

Take a byte b from the input.

If 1 < b < 128, then repeat the next byte b times.

If b >= 128, then copy the next 256-b bytes from the input.

If b = 0, then read the next word. The value of that word gives the number of times to repeat the byte that follows that.

If b = 1, then read the next word. The value of that word gives the number of bytes to copy from the input.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1962
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: PCS format

Post by Cyprian »

bjw66 wrote:(4) STE PhotoChrome: 19200 colours out of 32768. (3 components of 5 bits for the colours.) This seems to mean that 96 colours per line are possible. (96*200 = 19200.)
As far as I know this is an "interlaced mode"
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
MiggyMog
Atari Super Hero
Atari Super Hero
Posts: 909
Joined: Sun Oct 30, 2005 4:43 pm
Location: Scotland

Re: PCS format

Post by MiggyMog »

There is an overscan variation of the PCS format too used in the Tobias Richter slideshow.


Does this mean we may get a new program with faster conversion to these formats :-)
('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.
bjw66
Atari User
Atari User
Posts: 37
Joined: Fri Jan 18, 2008 2:02 am
Contact:

Re: PCS format

Post by bjw66 »

MiggyMog wrote:There is an overscan variation of the PCS format too used in the Tobias Richter slideshow.
Yes, I found those "PCI" images too and I briefly looked at the format. It seemed to me that, instead of using 320x200, they use 352x278, but when it really seemed to be PCS format (apart from the dimensions) to me, I left that format alone for the time being to concentrate on PCS first. And then I got sidetracked by the variation of the IFF format that ONLY Deluxe Paint seems to use and THEN ONLY the ST version of Deluxe Paint... (ILBM compression type 2). Which I THINK I have figured out now by looking at those IFFs in a hex editor. I still have to write code though to see if I'm right...
MiggyMog wrote:Does this mean we may get a new program with faster conversion to these formats :-)
To or from those formats? As for me, I'm really just interested in writing code so that I can view them on a PC. I don't have an Atari, but I wanted to be able to view the Atari's pictures. So I personally am really only interested in converting FROM those formats. I finally wrote my own viewer. And, yes, it now supports PCS, although most (if not all) of the credit for figuring out the specs goes to Hans Wessels (Nyh). I figured out part of the header and pretty much all of the compression simply by looking at the PCS files with a hex editor. I could actually produce something already that was very viewable that way. But Hans then actually disassembled a viewer and found out the exact specs that way.
simonsunnyboy
Moderator
Moderator
Posts: 5239
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: PCS format

Post by simonsunnyboy »

@Nyh: do you have working display code of this? I'm interested in such for use from GFABASIC....
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

simonsunnyboy wrote:@Nyh: do you have working display code of this? I'm interested in such for use from GFABASIC....
I have got code for displaying PCS. But not yet a simple plug and play module.

I think we need two routines:
1 depacker for decoding the picture to a memory block
2 display routine for displaying the picture itself

A bit of a problem is who controls all the interrupts. The display routine uses VBL and HBL and disables all other routines. I don't know yet how much control I can give back to Gfa. Do you have an example with spectrum displaying code for Gfa?

Hans Wessels
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

bjw66 wrote:Yes, I found those "PCI" images too and I briefly looked at the format. It seemed to me that, instead of using 320x200, they use 352x278, but when it really seemed to be PCS format (apart from the dimensions) to me, I left that format alone for the time being to concentrate on PCS first. And then I got sidetracked by the variation of the IFF format that ONLY Deluxe Paint seems to use and THEN ONLY the ST version of Deluxe Paint... (ILBM compression type 2). Which I THINK I have figured out now by looking at those IFFs in a hex editor. I still have to write code though to see if I'm right...
PCI is not as good as PCS. With PCI images you have only 16 colors per scanline. To make life easy for us all the color switching is done outside the visible screen.
Format:
352x278
first 12232 bytes for bit plane zero
then 12232 bytes for bit plane 1
12232 bytes for bit plane 2
12232 bytes for bit plane 3

then the second screen:
first 12232 bytes for bit plane zero
then 12232 bytes for bit plane 1
12232 bytes for bit plane 2
12232 bytes for bit plane 3

then the pallet entries for the first screen, 16 colors per line (total 278*16*2=8896 bytes)
then the pallet entries for the second screen, 16 colors per line (total 278*16*2=8896 bytes)

Data is packed with ICE, first depack before setting up the display.

Hans Wessels
You do not have the required permissions to view the files attached to this post.
simonsunnyboy
Moderator
Moderator
Posts: 5239
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: PCS format

Post by simonsunnyboy »

Nyh wrote:
simonsunnyboy wrote: A bit of a problem is who controls all the interrupts. The display routine uses VBL and HBL and disables all other routines. I don't know yet how much control I can give back to Gfa. Do you have an example with spectrum displaying code for Gfa?

Hans Wessels
Not at hand, I'm afraid :(
But all I know of overtake the interrupts while displaying. That should be ok in this case too. Switching all those palettes already takes CPU. I wouldn'T mind if it is just displaying and waiting for a key...
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
Cooper
Captain Atari
Captain Atari
Posts: 165
Joined: Fri Mar 14, 2003 6:21 pm
Location: Nancy / France
Contact:

Re: PCS format

Post by Cooper »

Hi, here is an example of Spectrum 512 pic displaying (SPU). GFA sourcecode attached, including the inline. If you want an other sourcecode, i have one from the SpriteWorks library, but if i recall correctly it's quite similar to this one.

Thanks for any progress on this PCS viewing stuff :)

Code: Select all

SPOKE &HFF820A,252
'                               GFA512.GFA
'
'            Original GFABASIC 2.0 version by Charles Medley
'                          STatus Disk Magazine
'                    Volume 1, Issue 1, October 1989
'
' This GFABASIC 3.0 version by Jim Burton,
' not affiliated with STatus Magazine.
'
' Be sure to read STatus!
'
' Except where noted, all following comments by Medley
'
' Now I wanna allocate the memory for BOTH the compressed pic and the final
' displayable pic...
@malloc(52000,*adr)
' Now, I'm gonna boot in the SPECTRUM 512 compressed pic, into the top most
' area of that reserved memory... what fun that will be...hehehehehe
' OK, so, anyways, we wanna have space for the TRIO code, for decompression
' and displaying of an .SPC pic...
INLINE show%,675
' This INLINE contains TRIO's SHOW512.O code (Burton)
DO
  FILESELECT "\*.SPU","",name$
  EXIT IF name$=""
  spc%=adr+52000
  dest=spc%
  ' x is used to test for the existence of the file...
  x=EXIST(name$)
  IF x<>-1 THEN
    CLS
    PRINT "The program needs to have ";name$;" present on the same path!"
    PRINT " The program's execution has now been terminated..."
    END
  ENDIF
  ' Now, I run the decompression routine, supplied by TRIO Engineering...
  ' First we define the destinations for the bitmap and color data...
  bitm%=adr
  colm%=bitm%+32000
  BLOAD name$,bitm%
  '
  ' Now we put the SPECTRUM pic onscreen until the user presses a key...
  ~C:show%(1,L:bitm%,L:colm%)
  REPEAT
  UNTIL INKEY$<>""
  ' We have to get the machine out of SPECTRUM mode...
  ~C:show%(0)
  ' We give memory back that was used for the .SPC and decompressed SPECTRUM
  ' pics...
LOOP
@mfree(adr)
END
'
PROCEDURE malloc(amt,ptr)
  ' Amt is how much memory we are setting aside, ptr is the pointer to the start
  ' of this memory...
  LOCAL pg
  ' Pg is used to calculate an address divisible for 256 that is appropriate...
  pg=INT(amt/256)
  ' Checks to see if what we will reserve will be enough for what we wanted...
  ' If not, we increase it...
  IF amt MOD 256<>0
    INC pg
  ENDIF
  ' We set up how much we will actually reserve with Malloc...
  malloc_amt=pg*256
  ' Reserves the memory, away from GFA Basic...
  RESERVE FRE(0)-malloc_amt
  ' Now we pass ptr to the GEMDOS Malloc() call that will reserve memory from
  ' the ST's OS...
  *ptr=MALLOC(malloc_amt)
RETURN
'
PROCEDURE mfree(adr)
  ' Adr is just the starting address of the area reserved...
  LOCAL er1
  ' Er1 is used to determine if an error occurred with the use of Mfree...
  ' We also give back the RAM to the OS and GFA Basic...
  er1=MFREE(adr)
  RESERVE FRE(0)+malloc_amt-255
  IF er1<>0
    CLS
    PRINT "Mfree() error ->";er1
  ENDIF
RETURN
'
You do not have the required permissions to view the files attached to this post.
*****************
Cooper/Paradize
STe / STf / Lynx
*****************
User avatar
SoLo2
Captain Atari
Captain Atari
Posts: 207
Joined: Wed Feb 04, 2004 4:09 am
Location: Spain
Contact:

Re: PCS format

Post by SoLo2 »

Hello!


Seems like this PCS format
is also displayable in med res?
Looks very good.


Bye,
SoLo2
~~~~~~~~~~~~~~~~~~~~~~~~~~*~~~
The BITS Club http://bits.atari.org
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

SoLo2 wrote:Seems like this PCS format is also displayable in med res?
Why do you think so?

Hans Wessels
User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: PCS format

Post by bullis1 »

SoLo2 wrote: Seems like this PCS format
is also displayable in med res?
Looks very good.
No, but it does break borders.

I would like to see a slideshow on Atari that utilized Photochrome images. It's a cool format and I hope you guys get it figured out!
simonsunnyboy
Moderator
Moderator
Posts: 5239
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: PCS format

Post by simonsunnyboy »

bullis1 wrote: I would like to see a slideshow on Atari that utilized Photochrome images. It's a cool format and I hope you guys get it figured out!
Check out the "Thematic Slideshows" made by Cooper :) http://paradize.atari.org/
However they use the supplied PCS viewer software and no builtin code.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: PCS format

Post by bullis1 »

Unfortunately those ones are STE only (except the Tawnee Stone one 8O )
User avatar
SoLo2
Captain Atari
Captain Atari
Posts: 207
Joined: Wed Feb 04, 2004 4:09 am
Location: Spain
Contact:

Re: PCS format

Post by SoLo2 »

Hello!


I saw a presentation screen by
Sinister Development, raytraced,
in red is the logotype, and was
very incredible because it showed
more than 16 colors, but in
medium resolution! 8)


Greetings,
SoLo2
~~~~~~~~~~~~~~~~~~~~~~~~~~*~~~
The BITS Club http://bits.atari.org
User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: PCS format

Post by bullis1 »

SoLo2 wrote: I saw a presentation screen by
Sinister Development, raytraced,
in red is the logotype, and was
very incredible because it showed
more than 16 colors, but in
medium resolution!
I've always wanted to see >4 colours in medium resolution. Do you have any info on this production? Can it be found on pouet.net?
User avatar
MiggyMog
Atari Super Hero
Atari Super Hero
Posts: 909
Joined: Sun Oct 30, 2005 4:43 pm
Location: Scotland

Re: PCS format

Post by MiggyMog »

('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.
simonsunnyboy
Moderator
Moderator
Posts: 5239
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: PCS format

Post by simonsunnyboy »

STE only is only valid for thw whole prod. You can still try the pictures standalone with the PCS viewer, You will only miss the small intro and the digi music ;)
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
SoLo2
Captain Atari
Captain Atari
Posts: 207
Joined: Wed Feb 04, 2004 4:09 am
Location: Spain
Contact:

Re: PCS format

Post by SoLo2 »

Hello!


More than 4 colors in a medium
resolution screen for Atari ST are
found in the presentation logotype of
Asteroids by Sinister Developments,
for example.

I could count more than 8 colors!
And these were densely packed.

Would this be possible changing the
resolution to low at some concrete
point? The Atari XL had such tricks.

:wink:


Greetings,
SoLo2
~~~~~~~~~~~~~~~~~~~~~~~~~~*~~~
The BITS Club http://bits.atari.org
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

SoLo2 wrote:Would this be possible changing the
resolution to low at some concrete
point? The Atari XL had such tricks.
Yes, Gfa raytracer did this. It had lowres high color view screen and a medium res menu at the side if I remember correctly. Magnetic Scrolls adventures like, "the Pawn"had low res graphics and medium res text.

Hans Wessels
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: PCS format

Post by Nyh »

Cooper wrote:Hi, here is an example of Spectrum 512 pic displaying (SPU). GFA sourcecode attached, including the inline. If you want an other sourcecode, i have one from the SpriteWorks library, but if i recall correctly it's quite similar to this one.
I am afraid you included the .SPC depack code and not the display code. Can someone send code that does display a Spectrum picture in Gfa?

Hans Wessels
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1962
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: PCS format

Post by Cyprian »

SoLo2 wrote:Hello!


More than 4 colors in a medium
resolution screen for Atari ST are
found in the presentation logotype of
Asteroids by Sinister Developments,
for example.

I could count more than 8 colors!
[...]
and you can find much more colours in this production:

http://www.pouet.net/prod.php?which=12237
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
Post Reply

Return to “Coding”