Jump to content

Unpacking rout


GT Turbo

Recommended Posts

Voila LA routine de décompactage de la Jag :

 

LZW_JAG.ZIP

 

C'est une adaptation Gpu ou Dsp de la routine de décompactage de Ray (TSCC)

 

Tout est dedans, le compacteur Atari et PC (Amis PCistes, vous pouvez remercier SCPCD pour la recompilation du compacteur !) et la routine Jag et bien sur le mode d'emploi !!

 

P.S : un grand merci a SCPCD, car la première fois j'ai oublié la routine Gpu !! :wacko:

 

[english]

 

Here come THE Jag unpacking rout !! In the ZIP file you will find Atari and PC packers (SCPCD has recompiled it for the PC), the Jag routine and of course notice !!

 

It's an adaptation of a Ray (TSCC) rout.

 

 

GT Turbo :yes:

 

 

 

P.S : big thanks to SCPCD, first time i forgot the Gpu rout !!

Link to comment
Share on other sites

Quelques détails supplémentaires, j'ai encore oublié de préciser que l'adresse de chargement de la routine doit ètre aligné sur un mot long (Donc multiple de 4) et que la routine meme ne fait que 300 octets, faites pas gaffe a la taille du fichier .o, Madmac rajoute pleins de trucs sans intèrets !!! La routine d'installtion ne recopie que le code meme.

 

 

 

 

 

[english]

 

Starcat has asked me for some details, and he has right my english doc is not very good, so some additionnal explanations :

 

 

 

Unpack_adr is the adresse where the routine will be installed in ram (Gpu or Dsp ram) ($f03000, $f1b000 any adresse but must be long word aligned)

 

 

 

When calling, if d0=0, the data will be unpacked and the routine will be finished only when unpacking was done. If d0<>0, the routine will come back immediatly, not when the Gpu or Dsp has finished, that means you can do something else during the depacking time (Calculating and unpacking in same time, loading data on CF and unpacking, etc...)

 

 

 

Don't look on the .o file, the rout do only 300 bytes !!! (In .o file, you can find 'symboles' and a lot of other things, we don't need !!) The installation rout only copy the rout nothing else

 

 

 

Do you have any questions ? Ask !! :)

 

 

 

GT Turbo ;)

Link to comment
Share on other sites

  • 5 months later...
Hello!

I have one:

Why isn't the RISC-source released? I haven't found it in the archive. :-(

 

Best regards

Matthias

 

Yes because it is not included, I will put it tomorrow ;)

 

It's only the translation of the 68000 code by Ray, in Gpu :)

 

 

 

GT :poulpe:

Link to comment
Share on other sites

Hi!

Ok, thanks for this :-)

 

I'll let you know if/when i got it incorporated in my project.

 

Thanks again!

Matthias

 

If you use it, just credits Ray(TSCC) for this great work :)

 

The source is not fully documented, but if you want more explications, don't hesitate. This is the 'exact' translation of the 68000 unpacking rout of the LZ77 implementation for Atari micro, let's have a look on the Ray website here :)

 

 

GT :poulpe:

Link to comment
Share on other sites

Hello!

 

If you use it, just credits Ray(TSCC) for this great work :)

 

The source is not fully documented, but if you want more explications, don't hesitate. This is the 'exact' translation of the 68000 unpacking rout of the LZ77 implementation for Atari micro, let's have a look on the Ray website here :)

GT :poulpe:

 

Today i started incorporating it in my project, the decoding RISC-code isn't working yet :-( , but the C-function which i found on Ray's site.

 

I'll let you know how it procedes :-)

 

Bye!

Matthias

Link to comment
Share on other sites

Hi!

 

Hello!

Today i started incorporating it in my project, the decoding RISC-code isn't working yet :-( , but the C-function which i found on Ray's site.

 

 

 

 

Ok, finally found the problem:

Your RISC-code simply consumpts too many registers! ;-)

 

The reason why i asked for the RISC-source was that i have to integrate it into a huge project with an already established RISC-code-environment. Sadly this RISC-code-environment (--> the function dispatcher) leaves only few registers for the called subroutines.

 

 

Ok, now it's working, so i am happy :-)

 

Thansk again!

Matthias

Link to comment
Share on other sites

Hi!

Ok, finally found the problem:

Your RISC-code simply consumpts too many registers! ;-)

 

The reason why i asked for the RISC-source was that i have to integrate it into a huge project with an already established RISC-code-environment. Sadly this RISC-code-environment (--> the function dispatcher) leaves only few registers for the called subroutines.

Ok, now it's working, so i am happy :-)

 

Thansk again!

Matthias

 

Yes, i must do a version who save and restore all used registres that's better ;)

 

 

GT :poulpe:

Link to comment
Share on other sites

  • 3 weeks later...

Hello!

 

If you use it, just credits Ray(TSCC) for this great work :)

 

 

Ok, i am using this sentence in the credits-screen:

LZSS packer by Ray of tscc

 

Is this ok?

I am using "LZSS" because of the state of confusion i am currently in, see below:

 

 

The source is not fully documented, but if you want more explications, don't hesitate. This is the 'exact' translation of the 68000 unpacking rout of the LZ77 implementation for Atari micro, let's have a look on the Ray website here :)

GT :poulpe:

 

Hmm, recently i began wondering about this:

On Ray's website he talks about a new version of his LZ77 stuff which he calls LZ78,

the DOS-EXE i use to compress (pack) the files outputs LZ77, does this mean that

we all use an outdated version now on the Jaguar?

 

Regards

Matthias

Link to comment
Share on other sites

Hello!

Ok, i am using this sentence in the credits-screen:

LZSS packer by Ray of tscc

 

Is this ok?

 

Yes ;)

 

I am using "LZSS" because of the state of confusion i am currently in, see below:

Hmm, recently i began wondering about this:

On Ray's website he talks about a new version of his LZ77 stuff which he calls LZ78,

the DOS-EXE i use to compress (pack) the files outputs LZ77, does this mean that

we all use an outdated version now on the Jaguar?

 

Regards

Matthias

 

Ray has done the LZ78 version after i have translated his LZ77 code, if i got a little free time i will do it for the LZ78 version.

 

 

GT :poulpe:

Link to comment
Share on other sites

  • 4 weeks later...
Yes ;)

Ray has done the LZ78 version after i have translated his LZ77 code, if i got a little free time i will do it for the LZ78 version.

GT :poulpe:

 

Did you write the update for this aswell?

 

TXG/MNX

 

Ps. what about a decompress routine for UPX files, seems that this algorythm is very fast and there is already an atari version for the compressor ;-)

Link to comment
Share on other sites

Did you write the update for this aswell?

 

It's not 'really' an update to do, but if i got some free hours this week end, i will do it ;)

 

Ps. what about a decompress routine for UPX files, seems that this algorythm is very fast and there is already an atari version for the compressor ;-)

 

Yes but you must know that UPX is C written, that's bad for the Jag, because C langage will give too big programs, and with only 4 Kbytes in Gpu ram..... so if that's be done that will be a 68000 version, so too slow. (The LZ77 Gpu unpacking rout unpack a 20Kbytes->128 Kbytes in less than 10 Vbls (50 Hz)), so i don't think the Upx packer can do the same thing), the LZ77 got a very nice ratio too.

 

 

GT :poulpe:

Link to comment
Share on other sites

  • 2 years later...
Guest promethea

I can't get multi-quote to work, so I'll write all I want from mem ;)

 

  • Firstly, nice stuff! Will have to test lz77 again against the heavyweight arj mode7 :)
  • Secondly, the lz78 algorithm is different than lz77, so it's not exactly an update. From what I remember from Ray's site it provides better pack ratio, but it's slower to depack.
  • Thirdly, the UPX depacker for ST is written in pure asm! At least I hardly think that C could generate such a small stub! So it's definitely easily portable even to GPU! The only hurdle one has to overcome is that upx is only a prg packer and it won't accept datafiles. There has been a hack which takes a datafile, adds a valid prg header, then you call UPX to pack it, then you just remove the header and use the UPX depacker :)
Link to comment
Share on other sites

  • 4 months later...

I found a bug in Ray's package. I've got a file which is badly depacked (or badly packed, I don't know).

 

Moreover, the 68k version is a bit slow.

 

Anyone has a good packing/unpacking rout' to suggest?

I need an ultra-fast unpacking routine and I need reasonable compression ratio (lz77 was ok regarding the compression ratio).

 

Thanks!

 

 

Link to comment
Share on other sites

I tried lzjag, seems to work quite well!

 

Link to comment
Share on other sites

[23:24] <@SebRmv> (pour l'instant j'utilise lz77 mais manque de pot, j'ai un fichier qui fait planter lz77)

[23:25] <@SebRmv> (enfin, planter gentiment)

[23:25] <@SebRmv> Fredifredo_AW: tu peux répeter la question?

[23:25] <@Fredifredo_AW> et lzjag ? :D

 

[Fr]C'est bien d'écouter les conseils d'un vieux codeur comme moi ! :D [fr]

 

 

Link to comment
Share on other sites

  • 2 weeks later...

ok finally I switched back to lz77 !

 

I realized, thanks to SCPCD, I did not use the latest release of lz77...

 

 

Link to comment
Share on other sites

I have written my own GPU implementation of the lz77 unpacker.

I will release it soon.

Link to comment
Share on other sites

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...