| |
oziphantom
Registered: Oct 2014
Posts: 490 |
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? |
|
... 5 posts hidden. Click here to view all posts....
|
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
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: 463 |
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: 3193 |
-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: 490 |
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: 3193 |
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: 11386 |
mein luftkissenboot ist voller Aale |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
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: 2014 |
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: 490 |
Do you know where Krill define what you can/should write to DD00? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
dont touch dd02, write 0-3 to dd00 |
| Previous - 1 | 2 - Next |
