| |
Kickback
Registered: Apr 2004
Posts: 97 |
$01 register
I know this was asked most-likely 1000 times already but my mind isn't as it use to be because of age and all LOL!!!
If I swap out all of the rom (store $34 into $01) do I need to have some sort of interrupt enabled? I seem to remember if you have the ROM off to long the system will crash? Is this the case or is it just plain ol bad programming LOL!!!
So basically I have my exomizer decrunch and I do the following....
lda #$34
sta $01
jsr decrunch
lda #$37
sta $01
Which I know the decrunch can take some time and not sure is this is why the system is getting hosed out!
|
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Just do a "sei" before you swap the Romz out and you'll be fine. Then enable the interrupts again afterwards with "cli", if desired...
(But just for your information... The "default" interrupt enabled when the C64 is turned on is a CIA1 Timer A irq, which jumps through the vector in $0314/$0315.) |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: Just do a "sei" before you swap the Romz out and you'll be fine. Then enable the interrupts again afterwards with "cli", if desired...
(But just for your information... The "default" interrupt enabled when the C64 is turned on is a CIA1 Timer A irq, which jumps through the vector in $0314/$0315.)
I figured this also, but stopping irq's a good amount of time will crash the system also? No?
And if I have irq's running for say music then the music will stop playing also?
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Stopping interrupts does not by necessity crash anything.
...but yes, if you do in fact use interrupts for something already, then stopping them is not a good idea of course. :) If your non-interrupt code somehow depends on interrupt code being executed, then you will have a crash of course.
What you need to do to have IRQs working even if you swap out the roms is to use the IRQ vectors at $fffe/$ffff instead of $0314/$0315:
http://unusedino.de/ec64/technical/aay/c64/romfffe.htm
Perhaps that is your problem?
By the way, I don't remember by heart exactly which state that is caused by $34, but if this also switches out the IO area including the SID, you cannot play music unless you swap this area in again temporarily in your music playing interrupt, and then out again before the interrupt quits, so the decrunching stuff can continue where it left before the interrupt got executed.
|
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: Stopping interrupts does not by necessity crash anything.
...but yes, if you do in fact use interrupts for something already, then stopping them is not a good idea of course. :) If your non-interrupt code somehow depends on interrupt code being executed, then you will have a crash of course.
What you need to do to have IRQs working even if you swap out the roms is to use the IRQ vectors at $fffe/$ffff instead of $0314/$0315:
http://unusedino.de/ec64/technical/aay/c64/romfffe.htm
Perhaps that is your problem?
By the way, I don't remember by heart exactly which state that is caused by $34, but if this also switches out the IO area including the SID, you cannot play music unless you swap this area in again temporarily in your music playing interrupt, and then out again before the interrupt quits, so the decrunching stuff can continue where it left before the interrupt got executed.
Ahhhhhh see I knew my mind was slipping!! Yes this jogs the memory!!! Thanks dude for the help MUCH appreciated!!!
James
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
You're welcome. Just don't forget to save the registers if you use $fffe instead of $0314. When roms are enabled, the IRQ jumps through the following code ($ff48 is where the IRQ vector in the ROM is pointing):
FF48: 48 PHA
FF49: 8A TXA
FF4A: 48 PHA
FF4B: 98 TYA
FF4C: 48 PHA
FF4D: BA TSX
FF4E: BD 04 01 LDA $0104,X ; 6510 Hardware Stack Area
FF51: 29 10 AND #$10
FF53: F0 03 BEQ $FF58
FF55: 6C 16 03 JMP ($0316) ; Vector: BRK Instruction Interrupt Address
FF58: 6C 14 03 JMP ($0314) ; Vector: Hardware IRQ Interrupt Address
...so you would have to do the register-stack pushing yourself if you use $fffe directly.
|
| |
TWW
Registered: Jul 2009
Posts: 541 |
A small tip:
You can set $01 to 34 and simply inc / dec $01 when you want to enable/disable the IO area.
Then you consecvently use $fffe/$ffff to handle your IRQs.
This gives you access to all memory and opens IO when you need it.
This assuming youre not using kernal for anything.
Maybee this was already answered :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
A better way may be to do:
lda $01
pha
lda #$35 (or whatever suits the music player irq)
sta $01
[call music player]
pla
sta $01
..since this will work no matter what value that is currently in $01 (I got the impression that this would change over the course of Kickback's program). Then again DEI/INC $01 of course consumes fewer cycles, if that is the priority...
|
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: A better way may be to do:
lda $01
pha
lda #$35 (or whatever suits the music player irq)
sta $01
[call music player]
pla
sta $01
..since this will work no matter what value that is currently in $01 (I got the impression that this would change over the course of Kickback's program). Then again DEI/INC $01 of course consumes fewer cycles, if that is the priority...
Actually this is the way I am doing it, that way my outside program can change $01 to anything and it will be preserved during the irq process. This works well with music under ROM areas.
|
| |
TWW
Registered: Jul 2009
Posts: 541 |
For wedge code i agree.
however if YOU run the show (I have extreeeeemly high performance requirements!) why not only access RAM and pull in ROM when(if) you need it instead of using time to preserve states which probably doesen't exist anyway?
and why not:
lda $01
sta mem+1
and #%11111100 /removes ROM (of the top of my head)
sta $01
[call music player]
mem: lda #$00
sta $01
saves a cycle :)
ps. don't forget that dec/inc don't mess with your regs either^^ |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@TWW: My answer was based on my impression of what Kickback wanted to do. I never actually used that kind of solution myself. :) (Well, once or twice maybe..) |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
Quoting FranticBy the way, I don't remember by heart exactly which state that is caused by $34,[...]
http://unusedino.de/ec64/technical/aay/c64/zp01.htm
leads to
http://unusedino.de/ec64/technical/aay/c64/memcfg.htm
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
which reminds me that I made this a while back: http://www.harries.dk/files/C64MemoryMaps.pdf
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting TWW
and why not:
lda $01
sta mem+1
and #%11111100 /removes ROM (of the top of my head)
sta $01
[call music player]
mem: lda #$00
sta $01
AND #$FC will also disable the I/O area -> no SID registers -> no music.
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: which reminds me that I made this a while back: http://www.harries.dk/files/C64MemoryMaps.pdf
You need to gather all the things you have done, and put them in 1 place.
Random links in random threads, dont do much for preservation.. :) |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
One thing you have to remember is that SEI only blocks IRQ interrupts. BRK and NMI will not be affected so if you switch out kernel while not providing correct interrupt handler routines for those interrupts your code will crash. This could explain why you remember that at some point after SEI you can expect problems. |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: One thing you have to remember is that SEI only blocks IRQ interrupts. BRK and NMI will not be affected so if you switch out kernel while not providing correct interrupt handler routines for those interrupts your code will crash. This could explain why you remember that at some point after SEI you can expect problems.
Ahhhhhh!!! So I wasn't crazy after all? So if I do not set anything up (interrupt wise) and so something like this:
lda #$02
sta $02a8
jsr $e544
sei
lda #$34
sta $01
ldx
ldy
jsr decrunch
lda #$37
sta $01
cli
if my decruncher takes too long the system will hault? If that's the case how do I get around it?
|
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
if thats your problem and you are decrunching to IO memory then you could perhaps just decrunch a portion of the data every frame.
if it's not IO area you shouldnt have to worry about this since you wouldn't need to bank out any crucical parts (unless you are doing a basic demo or something ofcoz). |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: if thats your problem and you are decrunching to IO memory then you could perhaps just decrunch a portion of the data every frame.
if it's not IO area you shouldnt have to worry about this since you wouldn't need to bank out any crucical parts (unless you are doing a basic demo or something ofcoz).
Oh yes it most definitely IO area under $d000 area?
I want to use that area for decrunching if possible. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: Oh yes it most definitely IO area under $d000 area?
I want to use that area for decrunching if possible.
Unless you really understand how memory management and hardware registers work on c64 it's not a good idea to use d000-dfff memory for decrunch. Take a look at one of C=Hacking issues where you will find necessary code for swapping in/out d000-dfff area for code.
Also when using IO area for memory you can forget about sound and screen affects and communication with floppy drive.
Coming back to your question: you can mask NMI despite it's name. There is a code example on codebase. Anyway you can also install one handler for all interupts using rti. This will make all your interrupt problems go away. Keep in mind that when you have no external peripherals connected you might almost never see NMI. BRK can be hit if there is a bug in your code and you address some unused memory or data before/after decrunch for example. |
| |
enthusi
Registered: May 2004
Posts: 674 |
also some folks start viewing demos by hitting RESTORE to hunt for 'bugs'... :) |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: Quoting TWW
and why not:
lda $01
sta mem+1
and #%11111100 /removes ROM (of the top of my head)
sta $01
[call music player]
mem: lda #$00
sta $01
AND #$FC will also disable the I/O area -> no SID registers -> no music.
Swap out
and #%11111100
with a
lda #$35 or
and #%11111101 if your sure IO is enabled form before...
still same amount of bytes/cycles... |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
If you knew what $01 is before calling the music, you would not need to save it on stack.
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: If you knew what $01 is before calling the music, you would not need to save it on stack.
Those kinds of assumptions just makes linking harder imho... |
| |
TWW
Registered: Jul 2009
Posts: 541 |
I wasn't saving anything on the stack, Frantic/Kickback did. I used SMC instead. Check the code you quoted.
IMO: Using inc/dec $01 when you need access to IO registers (like before/after 'jsr playsid')if $01 is pre-set to #$34 (Which banks inn all RAM) is the way to go. No need to stack or smc anything. Less cycles/RAM no regs messed up.
This method ofcourse mean you allways know the contents of $01 (why shouldn't you?). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting TWWThis method ofcourse mean you allways know the contents of $01 (why shouldn't you?).
If you depack stuff below $D000 and then use the stuff with IO mapped in, $01 changes outside IRQs.
|
| |
Skate
Registered: Jul 2003
Posts: 490 |
if you need to switch $01 in your main effect loop, then a few cycles are of course important. but otherwise, if you need to change it once (probably twice) per frame, store it to 1541 and read it back if you want, it doesn't matter that much. :) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
You dont need any switch :D just poke 1,$35 and all is ready :D put $100 bytes fastloader in there, and we are rolling!!! (thank you Krill) |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Ok ok ok.... Here is what I want to do, cause we are getting off track here... I understand swapping out memory banks and as far as I know swapping out $d000 area is the same as the other areas you swap out? UNLESS your using those registers in that area? Correct?
Which I'm not, I am just decrunching into that area after I set $01. Now my IRQ on the other hand is, but it saves $01 and then swaps back in that area so this SHOULD work fine? Correct?
The reason I want to use this area is then I will have ALL of the area below it to use for whatever. IMHO it makes a lot of sense because this area is being "wasted" so to say? Why not use it for decrunching?
So with all that said, am I missing anything? Which I believe I am because if I do the following:
sei
lda #$34
sta $01
ldx
ldy
jsr decrunch
lda #$37
sta $01
cli
Doesn't work, I have no IRQ's enabled or anything just an outside small program for test. What am I missing here? Or maybe it was already explained above and my feeble mind can't grasp it? If that's the case could you please say it a bit sloooower LOL!!!
|
| |
Skate
Registered: Jul 2003
Posts: 490 |
@Kickback: give $30 a try instead of $34 for the first $01 value.
sei
lda #$30
sta $01
ldx
ldy
jsr decrunch
lda #$37
sta $01
cli
if it works, i'll explain the reason :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting enthusialso some folks start viewing demos by hitting RESTORE to hunt for 'bugs'... :)
In the immortal words of Steve Jobs: "Just avoid holding it in this way."
|
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
Can you tell us more about the decrunch routine? Perhaps that is cuasing all the issues. |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Quote: @Kickback: give $30 a try instead of $34 for the first $01 value.
sei
lda #$30
sta $01
ldx
ldy
jsr decrunch
lda #$37
sta $01
cli
if it works, i'll explain the reason :)
I tried the #$30 and it worked and then tried #$34 and it worked. I also found so stupid shit in my decruncher which was changing $01 also LOL! UGH!!
@Stryyker:
It's a typical Exomizer decruncher nothing special?
Now hopefully this works with the IRQ's turned on and I will be all set!
(keeping fingers crossed!) |
| |
Skate
Registered: Jul 2003
Posts: 490 |
@Kickback: yes, crunchers usually ask for $01 value and sets it at the initialization level. you seem to have missed that part. |
| |
MC
Account closed
Registered: Jul 2009
Posts: 71 |
To clarify the #$30 / #$34 thing read the CHAREN bit in this:
6510 input/output port ($0001)
NAME BIT DIRECTION DESCRIPTION
LORAM 0 OUTPUT Control for RAM/ROM at
$A000-$BFFF (BASIC)
HIRAM 1 OUTPUT Control for RAM/ROM at
$E000-$FFFF(KERNAl)
CHAREN 2 OUTPUT Control for I/O/ROM at
$D000-$DFFF
3 OUTPUT Cassette write line
4 INPUT Cassette switch sense
5 OUTPUT Cassette motor control
LORAM (bit 0) can generally be thought of as a control line which banks the 8K byte BASIC ROM in and out of-the microprocessor address space. Normally, this line is HIGH for BASIC operation. If this line is programmed LOW, the BASIC ROM will disappear from the memory map and be replaced by 8K bytes of RAM from $A000-$BFFF.
HIRAM (bit 1) can generally be thought of as a control line which banks the 8K byte KERNALROM in and out of the microprocessor address space. Normally, this line is HIGH for BASIC operation. If this line
is programmed LOW, the KERNALROM will disappear from the memory map and be replaced by 8K bytes of RAM from $E000-$FFFF.
CHAREN (bit 2) is used only to bank the 4K byte character generator ROM in or out of the microprocessor address space. From the processor point of view, the character ROM occupies the same address space as the I/O devices ($D000-$DFFF).When the CHAREN line is set to 1 (as is normal), the I/O devices appear in the microprocessor address space, and the character ROM is not accessable. When the CHAREN bit is cleared to 0, the character ROM appears in the processor address space, and the I/O devices are not accessable. (The microprocessor only needs to access the character ROM when downloading the character set from ROM to RAM. Special care is needed for this... CHAREN can be overridden by other control lines in certain memory configurations. CHAREN will have no effect on any memory configuration without I/O devices. RAM will appear from $D000-$DFFF instead.
Puzzled by the CHAREN stuff which was copied directly from the C64's programmers manual? Short version: Setting the bit enables I/O devices, clearing the bit disables them thus allows the 4K of RAM space from $D000-$DFFF to be used instead.
Ofcourse, you don't want any possible interrupts left running in the ROM areas when switching those ROMS off.
#$30 is therefor probably your best bet when running a decruncher/decompressor type of thing, just switch all the ROM and I/O off to have as much as possible memory.
Just my 2 bits.
|
