| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Exmoizser and Mem trash RAM?
I'm using the mem option, and the depack routine provided in the src of exomizer.
The data is from BB28-DF40 I set the load address to 1000 like so
exomizer mem -l $1000 -o drop64BitmapMem.prg dropzonebitmap.prg
However it seems the Exomizer then wants to clear all RAM between 1000-BB28 when it depacks, which trashes the depacker. How do I stop it? |
|
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
If I set the load to $a000 it still does it.
Since my unpack code is at 4000, the memory clear stops there when it trashes its own code. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Try adding -c to the exomizer commandline and enable LITERAL_SEQUENCES_NOT_USED = 1 in exodecrunch.s, sometimes literal seq make it bugs. It's unrelated to your problem btw. I tried a quick test and works, only memory bb28-df40 gets unpacked and no other memory is overwritten. |
| |
lft
Registered: Jul 2007
Posts: 369 |
If you are decrunching into colour ram, here's a gotcha that I ran into a while ago:
For efficiency, many cruchers work from high addresses to low addresses. Suppose the original, uncompressed data contains e.g. "00 01 02" at address cff0 and "00 01 02" at address d800. It might happen that the decruncher writes "00 01 02" at d800 first, and then tries to copy that over to address cff0. But it will read back as "f0 f1 f2" (actually the high nybble would contain bus noise). So that's what gets written at cff0. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Ah, I assumed that he intended to unpack after setting all ram (lda #$38 sta $01) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Yes the unpack from $1000 upto BB28 is done with All RAM as it is under I/O & D800, although that is a nice quirk you found lft.
iAN did you do a mem depack or the sfx ? |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
mem of course, here is my quick test
https://www.dropbox.com/s/tf3vsrdtvsqv6iv/exotest.rar?dl=0
test.prg is the test data, randomly prepared from some tunes and ranging $bb28-df3f
t.bat crunches the prg and compiles the exotest.s to exotest.prg, all mem is filled with $ea to check after it finishes that nothing else gets written to.
the test.exo gets linked at $1000, code is at $4000, like you are trying to do. Everything works as expected.
What I suspect is that your original data isn't exactly ranging as you said. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
I guess if you set start address with -l at $1000, and your data starts at $bb28, exomizer fills $1000-$BB27 with $00.
Is normal exomizer behaviour... like if you pack more chunks of data, at different addresses: exomizer fills the ram in the middle with $00... |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
-l <address> adds load address to the outfile, using "none" as <address>
will skip the load address.
it's just the load address of the crunched data, it only affects the 1st 2 bytes of the generated file in other words.
you can even skip it by using -l none, and then include the file with incbin which doesn't use a load address but includes every file as raw.
*=$1000
incbin test.exo
same result. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
iAN test works the same on my setup..
I've switched to Byteboozer, but that won't work in the end. So tomorrow ( well today its 2:30am here ) I will switch back to exomizer and see what I see. Well if I can get the 2nd file loading, first one loads, 2nd one Krill's loader just sits waiting on $dd00 I must be trashing something it wants somehow..
Thanks for the help guys. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
what? my test works, how can it be possible that bugs for you? or do you mean "works correctly also for me"? =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
mein luftkissenboot ist voller Aale |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Solved the loader issue, seems a lda dd00
and #252
sta dd00 doesn't count as a non-arbitrary dd00 write in the Krill loader's eyes and I needed to add the idle bus lock feature.
So Exomizer
Running iAN's test prg worked ( I'm using ICU=64 Vice 2.3 so I can see what the depacker is doing more easily, but 2.3 anything can and will happen, so it was a needed test of my setup )
Putting iAN's know working exo file into my d64 and it still trashes RAM... Thus my code is to be at fault... ( I "ported" the decrunch to Tass64 ), nope it is fine....
Something was trashing a byte in the "decrunch_table" which is what caused it to at the end of the decrunch to just march through RAM...
Thanks for the test cast iAN, made it a lot easier to track down.
Oddly Groepaz it's the inverse case, in that you're the euros and I'm not XD |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
When working with fast loaders, never ever read, mask, write dd00/02 to set vic-bank. Always do direct writes following the recommended protocol of the loader. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Do you know where Krill define what you can/should write to DD00? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
dont touch dd02, write 0-3 to dd00 |
