uncrunch same address of source

[Giants]

Hi !

On a code, I don't have any free memory to :
- TrackLoad to memory Adress #A
- Uncrunch Data From #A to memory Adress #B
- Copy Uncrunched data from #B to #A

In my example, I don't have #B

I Think depending of what it use to crunch, I think it's possible to use the same adress of the source (or Source+little buffer) to uncrunch.

Question is, it's possible ? with which cruncher ?
I try with ByteKiller with #B is #A+1 Long word but I think It's not a good idea (I don't know the format specification of ByteKiller).
With This method, sometimes my unchrunded data is corrupt (only in the begining).

[roondar]

If I recall correctly, RNC Propack allows for decrunching with source and destination being the same (http://aminet.net/package/util/pack/RNC_ProPack).

There is also the Solid Gold source code (http://aminet.net/package/game/jump/SolidGold_Source), which has a trackloader that decrunches Bytekiller files as it loads them, without needing extra memory buffers to do so. To me that sounds like a version of Bytekiller that does in-place decrunching should be possible. Perhaps you can extract this from the Solid Gold source.

[dodke]

I guess the destination should be start of buffer? Packed data at the end of the buffer + a bit of padding? If you use enough padding almost any compression should be fine. A longword sounds a bit small though. Use a few times that maybe if unsure.

[Giants]

Hi !

Rnc seems don't working with Destination=Source
Ak Source :
* a0.l = start address of packed file
* a1.l = start address to unpack file
* (note: a1 cannot be equal to a0)

Compil Solid Gold trackloader is a bad idea with ASM because source has some function (with { ), and ASM pro don't like.
And the code seems very big.
If not, this was a better idea ro process.

Actually, I 'working' with the official byte_killer source :
But don't work with UnPacked Data=Packed Date

I try also with :
Source=$(Memory_Adress_selected)+$10
Destination=$(Memory_Adress_selected)

but don't work good.
I Try to add more than $10 in my equation, like :
Source=$(Memory_Adress_selected)+$400
Destination=$(Memory_Adress_selected)

But... it's worse.

Source=$40000		;Packed Data
Dest=$50000		;UnPacked Data

DeCruncher:	movem.l	d0-d7/a0-a6,-(a7)
		lea.l	$dff180,a6
		lea.l	Source,a0
		lea.l	Dest,a1
		move.l	(a0)+,d0
		move.l	(a0)+,d1
		move.l	(a0)+,d5
		move.l	a1,a2
		add.l	d0,a0
		add.l	d1,a2
		move.l	-(a0),d0
		eor.l	d0,d5
lbC0007F8:	lsr.l	#1,d0
		bne.s	lbC000800
		bsr.S	lbC0008A0
lbC000800:	bcs.s	lbC00083E
		moveq	#8,d1
		moveq	#1,d3
		lsr.l	#1,d0
		bne.s	lbC00080E
		bsr.S	lbC0008A0
lbC00080E:	bcs.s	lbC00086A
		moveq	#3,d1
		clr.w	d4
lbC000814:	bsr.S	lbC0008AC
		move.w	d2,d3
		add.w	d4,d3
lbC00081C:	moveq	#7,d1
lbC00081E:	lsr.l	#1,d0
		bne.s	lbC000826
		bsr.S	lbC0008A0
lbC000826:	roxl.l	#1,d2
		dbra	d1,lbC00081E
		move.b	d2,-(a2)
		dbra	d3,lbC00081C
		bra.S	lbC000878
 
lbC000836:	moveq	#8,d1
		moveq	#8,d4
		bra.S	lbC000814
 
lbC00083E:	moveq	#2,d1
		bsr.S	lbC0008AC
		cmp.b	#2,d2
		blt.s	lbC000860
		cmp.b	#3,d2
		beq.s	lbC000836
		moveq	#8,d1
		bsr.S	lbC0008AC
		move.w	d2,d3
		move.w	#$C,d1
		bra.S	lbC00086A
 
lbC000860:	move.w	#9,d1
		add.w	d2,d1
		addq.w	#2,d2
		move.w	d2,d3
lbC00086A:	bsr.S	lbC0008AC
lbC00086E:	subq.w	#1,a2
		move.b	0(a2,d2.w),(a2)
		dbra	d3,lbC00086E
lbC000878:	move.w	a0,(a6)
		cmp.l	a2,a1
		blt.S	lbC0007F8
		movem.l	(a7)+,d0-d7/a0-a6
		rts
  
lbC0008A0:	move.l	-(a0),d0
		eor.l	d0,d5
		move.w	#$10,CCR
		roxr.l	#1,d0
		rts
 
lbC0008AC:	subq.w	#1,d1
		clr.w	d2
lbC0008B0:	lsr.l	#1,d0
		bne.s	lbC0008BE
		move.l	-(a0),d0
		eor.l	d0,d5
		move.w	#$10,CCR
		roxr.l	#1,d0
lbC0008BE:	roxl.l	#1,d2
		dbra	d1,lbC0008B0
		rts

[StingRay]

ProPack does support decrunching over the source data. CrunchMania decruncher allows that too. ByteKiller (at leat the orginal version) was never made to support that.

[roondar]

Originally Posted by Giants

Hi !

Rnc seems don't working with Destination=Source
Ak Source :
* a0.l = start address of packed file
* a1.l = start address to unpack file
* (note: a1 cannot be equal to a0)

The RNC propack code from the LHA I linked to comes in two versions: 'compact' (RNC_1C.asm & RNC_2C.asm) and 'standard' (RNC_1.asm & RNC_2.asm). That note is only present in the MC68000 'compact' source code, which indeed does not support it.

The MC68000 'standard' source code that is provided doesn't have this line and should work, AFAIK.

Compil Solid Gold trackloader is a bad idea with ASM because source has some function (with { ), and ASM pro don't like.
And the code seems very big.
If not, this was a better idea ro process.

It was worth a try, I've used it myself and had no real problems - though I do use VASM, perhaps that has more features than ASM pro.

[dodke]

Not sure if I'm understanding correctly but...
If your source is destination + 10 then they would overlap pretty quickly. Destination pointer will move faster than source for compressed data.
You should have:
destination at start of memory block the size of [unpacked size] + [padding].
source at [destination] + [unpacked size] - [packed size] + [padding] no?
So that the packed data will end a little bit past the end of the unpacked size.

[NorthWay]

Any LZ style compressor should support in-buffer decompression. If it consumes data from the start of the compressed chunk then you move your chunk to the end of the final buffer, and vice versa if it consumes from the end of the chunk then you move it to the start.

Worst case you should have the last literal byte being read and then overwrite itself.
EDIT: That is probably wrong. I can't wrap my head around how much bigger it needs to be right now...

[Giants]

>The MC68000 'standard' source code that is provided doesn't have this line and should work, AFAIK.
Yes, I see that too but not already tested.

The syntaxte to make Function in ASM-pro is not the same as other compiler.

StingRay : Ok, Thks for this informations.

dodke : What do you mean by 'padding' ? I don't know this term.


Humm, First I going to test with 'RNC propack source' like roondar said.
yess, the source of some 'Crunch-Mania' version is in this webPage : http://www.amiga-stuff.com/crunchers-download.html

I will try too.


Thks

[Giants]

I post here what I do

Just compil Crunch-Mania1.7.s and test with A0=A1=Memory adress 'Source and Destination'

It's work but obscure reason, it's crash after uncrunch the data.
Strange...

Starting always with My MKIII
LM TEST_Crunched, 20000
LM Crunch-Mania.bin, 1000

a FE0
FE0 MOVEQ.L #20000,A0
FE6 MOVEQ.L #20000,A1
FEC BSR 1000
FEE MOVE.W #F0,DFF180
FF6 BRA FEE

M 20000
20000 43 72 4D 21 00 00 00 02 D6 90 00 01 87 FA 07 83 CrM!...ö........

G FE0
Just waiting...and Crah Power Led Blinking and going (if I don't do anything) to GuruMeditation, so... Enter to the AR and see What I have in 20000

m 20000
20000 30 90 84 0A 08 91 02 24 C4 81 89 02 44 92 1C 11 0......$Ä...D...

Data in $20000 is good but code crash and I never return ti my code and see green screen.

Maybe I use wrong option when I crunched the file.

I will dig the subject.

[phx]

When you are really that low on additional buffer space then you should decrunch while loading, as roondar already pointed out.

As you wrote you use your own trackloader, this should be no major problem and you only need a buffer of 512 bytes for the next disk-block. Let your decompression routine work through this block. Then load the next.

This works fine with all compression algorithms that create a single continuous stream to decompress (which is true for simple algorithms like Bytekiller, for example, although you must read it backwards).

[Galahad/FLT]

Originally Posted by Giants

I post here what I do

Just compil Crunch-Mania1.7.s and test with A0=A1=Memory adress 'Source and Destination'

It's work but obscure reason, it's crash after uncrunch the data.
Strange...

Starting always with My MKIII
LM TEST_Crunched, 20000
LM Crunch-Mania.bin, 1000

a FE0
FE0 MOVEQ.L #20000,A0
FE6 MOVEQ.L #20000,A1
FEC BSR 1000
FEE MOVE.W #F0,DFF180
FF6 BRA FEE

M 20000
20000 43 72 4D 21 00 00 00 02 D6 90 00 01 87 FA 07 83 CrM!...ö........

G FE0
Just waiting...and Crah Power Led Blinking and going (if I don't do anything) to GuruMeditation, so... Enter to the AR and see What I have in 20000

m 20000
20000 30 90 84 0A 08 91 02 24 C4 81 89 02 44 92 1C 11 0......$Ä...D...

Data in $20000 is good but code crash and I never return ti my code and see green screen.

Maybe I use wrong option when I crunched the file.

I will dig the subject.

Would help if you used the right instructions.

1). You can't use MOVEQ on Ax registers

2). $20000 is too big a value in any case for MOVEQ

Your code should be

lea $20000,a0
move.l a0,a1
bsr depack

RNC Propack v1 for absolute sure depacks in place as it uses the stack space, and uses $180+ bytes on the stack, so check that isn't your problem where the depacking overwrites the stack area.

[Giants]

Hi !

phx : Yes


Galahad/FLT : Exactly but, I use move.l and not MOVEQ.
Moveq is displayed by AR when I use the D command. (the interpreter on AR is not perfect).

You right, LEA is better, but no mater.
move.l or lea or just Put the good Value in A0 and A1 with R command like
r A0 20000

do the job.
Data always uncrunch but crash at the end (no return).

Not sure is a stack issue.
I just add 'R A7 60000' command on AR before 'G FE0' and do the same. (crash after decrunch)
60000 is free for me, for my test, my crunched data is not big.

I've just woken up, I'm going to watch this more ready this afternoon.
Maybe a stack problem.

We will see

Thks

[Giants]

I create a .uss file (76 Ko) whith WinUae :

Workflow :

- Simple A500 configuration + Kickstart 1.3 (no ext. memory)
- AR3 in Rom
- Cycle-exact on
- In a floppy, load CrunchMania binarie (compil from Crunch-Mania1.7.s with asm pro) at $1000
- Load my test_file (it's just a crunched text with crunchmania 1.4. Compilation : Apocalyspe Tools Disk 1992, Crunchmania 1.4, release 17.10.91), at $20000
- do a little code in FE0 like Galahad/FLT said.
- Change A7 to $60000 with AR command (maybe it's not a good idea)
- Start this litle code in $FE0

and....decrunch..... and.... Going to guru meditation.
Enter on the AR and see what I have in $20000, it's a test file decrunched.

and.... I will take my breakfast :=)


PS : for unknown reasons you need to have Freezer: 'Action Replay Mk III v3.17 (256k)' file in EXACTLY path contained in the .uss file

I don't know why but when we load a StateFile in WinUae and when this StateFile Use MKIII, we need to have this local file (so AR rom) used in this state with exactly the same path, if not, they bug and crash (gargabe screen)

I used relative path, my roms path is : .\roms\

[Giants]

Ok... I just find the problem.

For unknown reasons wrong compilation. (of Crunch-Mania1.7.s)
AsmOne 1.44 compil this BLE to a <wrong adress> (in memory $106E on my test configuration)

and this BLE is executed at the end of decrunching which explains the crash.
I corrected this directly under AR and now, it's working.

So... problem, solve

[StingRay]

There are a few bxx.L instructions in the CrunchMania source which should've been bxx.w. Bxx.l is illegal on 68000 hence the crash. Adapt the decruncher code and fix the few offending branches, then it will work fine on 68000.

[Giants]

yes, exactly, that's what I found too.

In this case, it's :
ble.l .DecrEnd ;a1=a5: fertig (a1<a5: eigentlich Fehler)

AsmOne seems don't like this command and create a wrong opcode
But, If I change in the source : ble.l .DecrEnd to a ble .DecrEnd
(like you said)

Compilation always work and the generated binarie, and so, opcode for this part, it's good.

what I find strange is that cas that AsmOne don't print : warning or Error when I compile the source code, it's strange isn't ? No matter cpu configuraton used (68000 or 68020), always no warning or error.

Well, it's good to say that
Don't use Bxx.l

Thks

[StingRay]

AsmOne seems don't like this command and create a wrong opcode

Nope, Asm-One generates the correct opcode. Which is the reason why the code fails on 68000. Older SEKA and very early ASM-One versions silently convert the bxx.l to bxx.w which is actually incorrect behaviour.

[Giants]

Ok, so Opcode generated is good but this opcode don't work on 68000.
I'v just add colored bar when it decrunch, it's cOOoooooollll