Voila LA routine de décompactage de la Jag :

Click to view attachment

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 !!

Yes !! :yes:



Bien joué GT ;)



[PS : il ne manque plus le .o :D]

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 ;)

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

Hi!




Ok, thanks!


Matthias

And here come the Gpu (Dsp) sources :

Click to view attachment




GT

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

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.

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

Bye!
Matthias

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

Don't forget you can use it in Gpu or Dsp ram at all adress you want without any problems If that can help you in a other way

GT

Hello!




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


Is this ok?
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

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

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 ;-)

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



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

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

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!

ice ?
it's 68k compatible (atari) and pretty fast with good ratio

I tried lzjag, seems to work quite well!

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

ok finally I switched back to lz77 !

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

I have written my own GPU implementation of the lz77 unpacker.
I will release it soon.

You going to make it part of your Removers Lib?

Probably, yes