| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
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: 1787 |
Exomizer, pucrunch and basically all native decrunchers do that by default.
What problem are you encountering more specifically? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
..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: 1787 |
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: 1408 |
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: 5086 |
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: 1787 |
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: 5086 |
I have never used $30, altho I remember seing shit like this when peeking at code. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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. |
... 15 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
