Pc1 unpacking rout

[GT Turbo]

For Gfa coders, i have done a PC1 unpacking rout, i know that there is a lot a routine to unpack pc1 picture, this one must be a little bit smaller and faster, i think. The rout is an asm one, but with a GFA example for calling this one.

Just a little thing : it's only a low res rout.

If you want to modify something, everything is given with. (Gfa rout, assembled rout, sources from unpacker, etc...)


GT Turbo (Cerebral Vortex)

[Zorro 2]

Cool !

ThanX mister GT Turbo.

[rockyone]

Thanks GT Turbo
I made a rout for PC1 PC2 PC3.
In low resolution, it is very slightly faster than the original.

UNPACK PC1-3.zip

[simonsunnyboy]

Thanks for sharing, I am currently working on integrating a different PC1 unpacker into my kernel project. This versions looks a lot shorter codewise and I will give it a go.

[rockyone]

As it stands, this rout is 128 bytes.
In my image converters, (MI-3 at MI-9) I use a more complete version, because I do not display the image directly on the screen, I recreate a complete PI1-3 image

[simonsunnyboy]

As it stands, this rout is 128 bytes.
In my image converters, (MI-3 at MI-9) I use a more complete version, because I do not display the image directly on the screen, I recreate a complete PI1-3 image

Nice and fast...just one note for those whodo not read the implementation 1:1, this routine only depacks the picture data and does not move the picture header with palette information to the destination buffer.

I added a code snippet to move that information aswell....

Code: Select all

   move.b   1(a0),d1       | Image resolution

   | copy header data and palette to destination
   move.w (a0),(a1)
   move.w 2(a0),2(a1)
   move.w 4(a0),4(a1)
   move.w 6(a0),6(a1)
   move.w 8(a0),8(a1)
   move.w 10(a0),10(a1)
   move.w 12(a0),12(a1)
   move.w 14(a0),14(a1)
   move.w 16(a0),16(a1)
   move.w 18(a0),18(a1)
   move.w 20(a0),20(a1)
   move.w 22(a0),22(a1)
   move.w 24(a0),24(a1)
   move.w 26(a0),26(a1)
   move.w 28(a0),28(a1)
   move.w 30(a0),30(a1)
   move.w 32(a0),32(a1)

   | skip header at source and destination for unpacking
   lea.l   34(a0),a0
   lea.l   34(a1),a1
   ..


Also for caution, the code already assumes input pointers are on the stack, not in registers.

But otherwise: it is fast, small and working Thanks again for sharing!

[rockyone]

....
this routine only depacks the picture data and does not move the picture header with palette information to the destination buffer.
I added a code snippet to move that information aswell....

Yes, this rout just unpack the image, because I can not predict how you will use it.

But the compression byte is not appropriate in the destination

[simonsunnyboy]

Well I have never heard about any compression byte. At which offset is it? 0? If so, hardly any software parses this. It can be masked out in case of real problems. The palette data is the most important part here.

I personally prefer to keep complete PI1 pictures in memory with associated palette information.

[FedePede04]

if the first byte is $80 in a Degas Elite Picture then its compressed

[rockyone]

Degas Elite test this byte, but apparently does not compare it with file extension but with file size

It does not load a compressed image that does not have its active compression byte!

But crash with an uncompressed image having this active byte ...

[rockyone]

Well I have never heard about any compression byte. At which offset is it? 0? If so, hardly any software parses this. It can be masked out in case of real problems. The palette data is the most important part here.

I personally prefer to keep complete PI1 pictures in memory with associated palette information.

For security reasons, I advise you to test the first byte before decompressing the image, because I recently found "Image.PC?" packed with Ice and Atomik. This is more common with "Image.PI?"

A full version ( 184 bytes ), I added the compression byte test, the copy of the color palette, and the color cycles copy if there is on

UNPACK_2_PC1-3.zip

; Source : address buffer image source
; Destination : address buffer 32066 bytes minimum
; File_size : file size to decompress
;
; return in d0
; #-2 bad file
; #0 if not color cycle.
; #>0 if there is color cycle ( = number of byte in the image source before color cycles )
;
;
; In basic Omikron:
; call unpak_2( L source, L destination, file_size )
; if Lpeek(reserved(0))=-2 then
; ; bad_file
; else
; color_cyle% = (Lpeek(reserved(0)))>0
; endif

[rockyone]

Well I have never heard about any compression byte. At which offset is it? 0? If so, hardly any software parses this. It can be masked out in case of real problems. The palette data is the most important part here.

I personally prefer to keep complete PI1 pictures in memory with associated palette information.

For security reasons, I advise you to test the first byte before decompressing the image, because I recently found "Image.PC?" packed with Ice and Atomik. This is more common with "Image.PI?"

A full version ( 182 bytes ), I added the compression byte test, the copy of the color palette, and the color cycles copy if there is on

UNPACK_2_PC1-3.zip

; Source : address buffer image source
; Destination : address buffer 32066 bytes minimum
; File_size : file size to decompress
;
; return in d0
; #-2 bad file
; #0 if not color cycle.
; #>0 if there is color cycle ( = number of byte in the image source before color cycles )
;
;
; In basic Omikron:
; call unpak_2( L source, L destination, file_size )
; if Lpeek(reserved(0))=-2 then
; ; bad_file
; else
; color_cyle% = (Lpeek(reserved(0)))>0
; endif

[rockyone]

sorry, double sending

[rockyone]

Well I have never heard about any compression byte. At which offset is it? 0? If so, hardly any software parses this. It can be masked out in case of real problems. The palette data is the most important part here.

I personally prefer to keep complete PI1 pictures in memory with associated palette information.

For security reasons, I advise you to test the first byte before decompressing the image, because I recently found "Image.PC?" packed with Ice and Atomik. This is more common with "Image.PI?"

A full version ( 182 bytes ), I added the compression byte test, the copy of the color palette, and the color cycles copy if there is on

UNPACK_2_PC1-3.zip

; Source : address buffer image source
; Destination : address buffer 32066 bytes minimum
; File_size : file size to decompress
;
; return in d0
; #-2 bad file
; #0 if not color cycle.
; #>0 if there is color cycle ( = number of byte in the image source before color cycles )
;
;
; In basic Omikron:
; call unpak_2( L source, L destination, file_size )
; if Lpeek(reserved(0))=-2 then
; ; bad_file
; else
; color_cyle% = (Lpeek(reserved(0)))>0
; endif

[rockyone]

strange, when I want to change my shipment, it duplicates

[rockyone]

sorry,..

[simonsunnyboy]

No prob, I will add the test and deletion of the packed indication as it comes at no cost.

But seriously I never ran into problems yet as I am dealing with code to import the data into my own applications/games/demos, not exporting them for others to use.

In the latter case I would simply output an unpacked PI1 instead. I personally only need the 32K of screen content and the 32 byte palette data

[rockyone]

DEGAS Elite Packer by Nucleus/HMD for Synthetic Arts III! - PC1 ONLY -

Source and modifications for PC1 PC2 PC3

Packer Degas.zip