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