| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Packer/decruncher for under IO?
So, what's the current rec for tools that let you load stuff that will crunch down to less than 51199 bytes, but decompresses to the entire area from from (ooh, for example) $0801 to $e1e0? I thought pucrunch took care of that, but either I'm mistaken or I don't know what flags to use.
(why yes, I do have an entry for Show Me Your (Vector) Balls that fits that criteria) |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Exomizer, pucrunch and basically all native decrunchers do that by default.
What problem are you encountering more specifically? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
..in which case there must be a bug in my display routine instead *blush*
If I set $01 to $35 at the start of every IRQ (before acknowledging the interrupt and setting up the next), and clear it to $30 at the end, my mainline should have access to all of RAM, should it not? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Seems reasonable, although I usually use $34 instead.
Is $00 setup correctly? Typically $2f. |
| |
algorithm
Registered: May 2002
Posts: 705 |
I would recommend something such as
sta $40
stx $41
sty $42
lda $01
sta $43
lda #$35
sta $01
irq routines..
....
ldx $41
ldy $42
asl $d019
lda $43
sta $01
lda $40
rti
And main routine outside IRQ can make any other adjustments to $01
rti |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ah! $34 was the answer. Thanks, @tlr. I've not used the RAM under IO for anything other than charsets or sprites for a very long time.
@algorithm, fair point about saving/restoring $01 in the general case, but in this instance I know the mainline code isn't touching IO. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Ah! $34 was the answer. Thanks, @tlr. I've not used the RAM under IO for anything other than charsets or sprites for a very long time.
@algorithm, fair point about saving/restoring $01 in the general case, but in this instance I know the mainline code isn't touching IO.
Save and set $01 in the irq handler anyway, always unless you really need the cycles. One day 4h before deadline you'll get the brilliant idea to load the next part while you irq is running => boom!
Been there - done that! :)
Oh and for real safety push the values on stack instead of zp if you get the other brilliant idea to allow an irq happen inside the handler. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
my 2 cents: dont use zp,
sta saveaccu+1
..
..
saveaccu lda #$00
is just as fast, but now you have avoided zp conflicts :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Ah! $34 was the answer. Thanks, @tlr. I've not used the RAM under IO for anything other than charsets or sprites for a very long time.
@algorithm, fair point about saving/restoring $01 in the general case, but in this instance I know the mainline code isn't touching IO.
Hmm, I think $30 should have worked though. The only difference is that CHAREN is 0 but the I/O area/charrom isn't visible with LORAM/HIRAM=0 anyway. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I have never used $30, altho I remember seing shit like this when peeking at code. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I have never used $30, altho I remember seing shit like this when peeking at code.
$30 isn't all that useful but $31 can be as you can flip in the char rom while still having ram at $a000-$bfff and $e000-$ffff. |
| |
algorithm
Registered: May 2002
Posts: 705 |
@Oswald. That is what i do as well. Although it does use 2 cycles more overall for each register save/restore which is trivial |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: @Oswald. That is what i do as well. Although it does use 2 cycles more overall for each register save/restore which is trivial
2 cycles more ?
lda $00
sta $00
= 6 cycles
sta $1000
lda #$00
= 6 cycles |
| |
algorithm
Registered: May 2002
Posts: 705 |
Darn. Sorry oswald. Ofcourse its 6 cycles. :-) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Hrm, and now if I change back to $30 it still works. I suspect I didn't check in a version close enough to hunt down what the real issue was now.
@JackAsser, very good point about future proofing. Linking issues were one of the biggest reasons I didn't manage to complete my entry for BFP in 2006 :-/ |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting ChristopherJamHrm, and now if I change back to $30 it still works. I suspect I didn't check in a version close enough to hunt down what the real issue was now.
There are two solutions to this:
1. make more fine granular commits with decent comments.
2. regress to being 13 years old when we could still remember all the steps and juggle them around with the occasional help of pen and paper.
:) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I've been using $30 for years before realizing $34 has exactly the same results. Still keep using $30. I think $30 and $34 have the same level of usefulness, since they're equivalent. Also, what JackAsser said. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i'll just quote it again because it cant be said often enough:
Quote:
Save and set $01 in the irq handler anyway, always unless you really need the cycles. One day 4h before deadline you'll get the brilliant idea to load the next part while you irq is running => boom!
Been there - done that! :)
Oh and for real safety push the values on stack instead of zp if you get the other brilliant idea to allow an irq happen inside the handler.
:) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
@krill: true, although if you are bank switching a lot $34 is helpful because it allows inc/dec to switch I/O on or off without mapping in ROM.
I rarely move out of the $33-$37 range myself. Well, except for tape bits. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
...so, now I've a one filer that doesn't crunch to less than 51199 bytes.
My disks used to be littered with frozen games this size long before I started cross developing, but my Action Replay was quite happy to load them for me. I can happily send them across to my real c64 even now using codenet.
But what's current best practice for loading them on a bare c64? VICE is understandably barfing. And is it considered bad form to release a single such .prg without placing it on a .d64 with a loader? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
..and yes, @JackAsser, I currently have the brilliant idea to allow an irq to happen inside the handler :D |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
if you're picky the solution I see is an autostart loader, otherwise just leave a note it only works with AR, or a provided software speeder... |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Quoting JackAsserSave and set $01 in the irq handler anyway, always unless you really need the cycles. One day 4h before deadline you'll get the brilliant idea to load the next part while you irq is running => boom!
Apparently there is another big mistake happening before that: A release is finished in time, and thus one never runs into that kind of trouble 8-)
@ChristopherJam:
Adding an autostarting loader would be best practice i'd say. When i was releasing Ächzzeit to be loaded with cart only, there was some decent whining going on :-) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
At least it was decent. Nothing bugs me more than mediocre whining. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Damn that mediocre whining ;)
OK, I'll patch in the Effluvium loader. It's not the fastest in the world, but it's easy to bash into shape, and it's one less tool to learn for now.
I really should play with Krill's at some point.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
FWIW I ended up writing my own decruncher with byte aligned records for speed, and a simple decoder that fits easily into zero page. Not quite as high a compression ratio as pucrunch, but a better fit for purpose.
(I wanted the destination to be from $0200 to end of ram, but the data from around the $5000 mark on is pretty incompressible, so that had to be verbatim. All in all, time to roll my own) |
