Pc1 unpacking rout

GFA, ASM, STOS, ...

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

User avatar
GT Turbo
Captain Atari
Captain Atari
Posts: 335
Joined: Tue Feb 17, 2004 9:41 am
Location: Alsace, France
Contact:

Pc1 unpacking rout

Postby GT Turbo » Mon Jul 12, 2004 10:27 am

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) 8)
You do not have the required permissions to view the files attached to this post.
Never forget : Power is in your minds !!!

http://Cerebral-Vortex.net

http://Jagware.org

User avatar
Zorro 2
Administrator
Administrator
Posts: 2198
Joined: Tue May 21, 2002 12:44 pm
Location: Saint Cloud (France)
Contact:

Postby Zorro 2 » Mon Jul 12, 2004 12:14 pm

Cool !

ThanX mister GT Turbo.
Member of NoExtra Team

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Mon Mar 19, 2018 1:28 am

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
You do not have the required permissions to view the files attached to this post.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5015
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pc1 unpacking rout

Postby simonsunnyboy » Mon Mar 19, 2018 4:50 pm

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.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Mon Mar 19, 2018 8:53 pm

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

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5015
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pc1 unpacking rout

Postby simonsunnyboy » Tue Apr 03, 2018 4:40 pm

rockyone wrote: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!
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Tue Apr 03, 2018 11:48 pm

simonsunnyboy wrote:....
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 :wink:

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5015
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pc1 unpacking rout

Postby simonsunnyboy » Wed Apr 04, 2018 3:24 pm

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.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

FedePede04
Atari God
Atari God
Posts: 1035
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: Pc1 unpacking rout

Postby FedePede04 » Wed Apr 04, 2018 5:30 pm

if the first byte is $80 in a Degas Elite Picture then its compressed
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Wed Apr 04, 2018 7:22 pm

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

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 ... :mrgreen:

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:21 pm

simonsunnyboy wrote: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
You do not have the required permissions to view the files attached to this post.

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:39 pm

rockyone wrote:
simonsunnyboy wrote: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
You do not have the required permissions to view the files attached to this post.

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:40 pm

sorry, double sending

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:44 pm

simonsunnyboy wrote: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
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:48 pm

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

rockyone
Captain Atari
Captain Atari
Posts: 442
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Pc1 unpacking rout

Postby rockyone » Thu Apr 05, 2018 2:48 pm

sorry,..

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5015
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pc1 unpacking rout

Postby simonsunnyboy » Thu Apr 05, 2018 3:37 pm

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 ;)
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests