| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Self extracting decrunchers and low memory
If you're using a cruncher to create a self extracting .prg, do you care whether or not it disables the system IRQ and/or scribbles over low memory?
I'm about to add an executable output option for nucrunch, and so I was wondering what would make it most useful to others; if I copy the ~400 bytes the decruncher occupies down to $0200 I could then support decoding to $0801+
(Not sure which forum this lives in; happy for the mods to move it if appropriate obviously). |
|
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Disabling the system IRQ while decrunching the executable is de facto standard behaviour.
Then try to use as much as possible of the stack, and make sure to preserve at least the vectors around $0300-$0330.
This just off the top of my head, there may be other important values in $0200-$0400. Refer to http://unusedino.de/ec64/technical/aay/c64/zpmain.htm .
Speaking of $0400, running the decruncher at $0400-$0800 is not an option? |
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Ah, preserving this:
$0286/646 Current Character Color code
sounds like a good idea.
And IIRC, one of the other variables must have a specific value in order for KERNAL load to work. Maybe it was
$0285/645 Serial IEEE Bus timeout defeat Flag
or one of the RS232 variables. |
| |
Didi
Registered: Nov 2011
Posts: 486 |
Most crunchers use tape buffer $0334-$0400 and stack. Messing the zeropage should be done carefully. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Ah, excellent. Tape buffer plus stack is heaps of space. I was starting to consider seeing if there was 400 bytes of zeros anywhere in or after the file to be compressed, but this is much easier.
I'd rather not blat 0400-0800; it looks untidy to me, and precludes people doing their own transitions. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Next question, only slightly off topic...
Zeroing unused memory in between &/or after the provided sections to compress - yes/no?
I already take a list of .prgs to include so people can leave out memory they don't care about, but even given that I was thinking I should autodetect included runs to avoid the wrath of Ian Coog.
Perhaps I should just default to zeroing everything north of 0800 that's not otherwise specified? There'd the an added bonus of reducing the chance of demos accidentally relying on uninitialised RAM, too. |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
=)
Exomizer zeroes the mem between different sections because it callocs a 64k array before loading into it the sections, some other old native linker/packer left garbage in the space between linked sections if the crunched data was already in those areas (example: you link 2 sections 0801-0fff and $c000-cfff, the packed file occupies $0801-$2000, when depacking you'll end up with $1000-$2000 still filled with the leftover packed data).
So all depends what one needs to do. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Ah, so it's mostly an implementation side effect, and not something you can disable? Interesting. Doesn't sound like it's done exo's popularity any harm.
I hadn't really thought about the garbage issue, that's a good point. Something I should watch out for, really.
Thanks all. |
| |
Didi
Registered: Nov 2011
Posts: 486 |
For the filling of space I'd opt for default filling it with zeros but an option to leave memory as is in these places might be useful in some cases. |
