letzter Beitrag von Drachen am
Hi all 
Well, the title says it all... Currently I'm writing a little side project in BASIC10 using some small companion routines in assembler. Now the problem is, I need 4 bytes of zeropage for time critical stuff, but I don't know which locations are safe to use. So, has someone already charted the murky waters of C65 zeropage usage? Is there any kind of zeropage usage map for C65 mode somewhere? It wouldn't have to be complete, I only need 4 bytes ;-))
Thanks and kind regards
Stephan
I only need 4 bytes
If I'd recognized it correctly, these four bytes of the zeropage can be used save for applications:
$FB, $FC, $FD, $FE (251, 252, 253, 254)
If I'd recognized it correctly, these four bytes of the zeropage can be used save for applications:
$FB, $FC, $FD, $FE (251, 252, 253, 254)
Thanks a lot! That did the trick
Actually, a short while later I needed four more bytes... and then I realized that by using the 4502's 'B' register, I can actually have all the zeropage space I need... which is a very nice feature of this processor
Actually, a short while later I needed four more bytes... and then I realized that by using the 4502's 'B' register, I can actually have all the zeropage space I need... which is a very nice feature of this processor
I assume, you are talking about the Z register of the 4510? 
Zitat von 65ce02.txtThe Z Register
~~~~~~~~~~~~~~
The 65CE02 has a third index register: the Z register. The zero page indirect addressing mode has been completely replaced by the zero page indirect, Z indexed addressing mode. As long as the Z register is not used and therefore 0, these commands are fully backwards-compatible.
assume, you are talking about the Z register of the 4510?
No, in fact I did mean the B register
One paragraph further down:
ZitatAlles anzeigen2.2.2 Direct Page
~~~~~~~~~~~
Just like on the 65816, the zero page can be relocated to any page (block)
within the 64 KB of memory that are currently "in sight" of the CPU.
The B (block) register can be loaded with the contents of the accumulator,
and its contents can be written back into the accumulator, too.
So with something like
I can relocate the zero page to say $AB00, gaining $FF free available zero page bytes (one has to disable interrupts during this, because the C65s Kernal relies on the zero page being where it belongs, though)
No, in fact I did mean the B register
Oh, my fault! I mixed B and Z. 
But it's good that we discussed this all from B to Z. 
That's one of the things I find so nice with the C65/MEGA65: Having enough use of the "old" C64 knowledge, but also having enough "new" stuff to discover and learn. I think that's a very nice "mixture"! 
This is exactly what attracts me to the MEGA65 as well. You already have the feeling of "knowing" the machine, but there is so much more to discover under the hood. i really would like to say, the MEGA65 is the C64s bigger brother.
I can relocate the zero page ...
I just tried this little routine
I set the B register to 1, then write $55 to $02 and load B with 0 again.
This routine runs in bank 8 of the xc65 emulator with 911210 ROM.
The $55 is stored in $0102. So that's okay.
But it's not stored in $0102 of bank 8 where the routine runs, but in $0102 of bank 0.
Does B register don't care about in which bank the program runs? Have the base pages always be in bank 0?
Hm, truth being told, up until now I only tried it in BANK 0
I just wanted to do some research on my DevKit but then found that the monitor in the current ROM (920134) seems to be broken... so... I'll get back to you later when I have some kind of functioning ml monitor again...
I can confirm your findings... apparently, base page is restricted to bank 0 regardless of any mapping being in effect.
Now the million $ question... is that a bug or a feature?
... is that a bug or a feature?
It's Commodore!
ubik : Many thanks for your checking and help!
It's not only when using the B register.
Even this supersimple routine doesn't work as one would assume:
Running in bank 8, the $55 is written in $02 of bank 0.
I don't get it. Even using $0002 instead of $02 for storing the $55 it will only be stored in bank 0 although running in bank 8.
I'm sure it's possible to store data in bank 8. It works perfect in BASIC 10 with BANK 8:POKE 2,85
Is it possible that you have to use the sta_far kernel routine for storing the data into the same bank as the program is running if it's not in bank 0? 
up until now for some reason I thought BANK/SYS and the monitor somehow use the MAP command to configure memory before jumping to the machine language routine, but this seems not to be the case... so I guess you‘ll have to MAP something together all by yourself to make other banks accessible, especially in regards to the base register.
Unfortunately MAP is kinda nightmarish to use... the easiest approach would be working in bank 0 and using Paul‘s new 32bit opcodes or DMA to access data in other banks...
So it seems that the banks > 0 can just be used for storing/loading some datas in/from it but not for running a program in it?
E.g. if I have a program in bank 8 I of course want that a STA $02 saves the content of the A register into $02 of bank 8 and not into $02 of bank 0.
So it seems that the banks > 0 can just be used for storing/loading some datas in/from it but not for running a program in it?
E.g. if I have a program in bank 8 I of course want that a STA $02 saves the content of the A register into $02 of bank 8 and not into $02 of bank 0.
You would have to use the MAP instruction to map the corresponding 8kb block of the desired bank to bank 0 (but I've never tried this in conjunction with the base register... in theory it should work; I'd like to write a little demo but I'm just too tired for the MAP instruction at the moment...
OR, you could use zero-page indirect addressing [ NOP + LDA(ZP),Z ] to access any 32 bit address directly, without the hassle of having to deal with the MAP opcode.
OR, you could use zero-page indirect addressing [ NOP + LDA(ZP),Z ] to access any 32 bit address directly, without the hassle of having to deal with the MAP opcode.
Okay, I had just managed to get a code works with this option. Sadly I doesn't work on the C65 (xc65), but it works on the MEGA65 (xmega65).
This short routine starts in bank 4 of xmega65 at address $43000. I want to read the content of address $43020 and store it into $43030 while the program runs in bank 4.
For the zero vector I use $FB,$FC,$FD and $FE of the zero page in bank 0. I have to store $20,$30,$04,$00 (for $00043020) because I want to read address $43020.
Then I load $00 into Z, make a NOP and then load it with LDA ($FB),Z ($FB is where the address bytes are stored).
After read the content of $43020, I change the byte in $FB from $20 to $30, because I want to store A in $43030. And then store A after a NOP with STA ($FB),Z in $43030.
That's the memory $43000 to $4303F before and after running the routine (with J 43000).
So at least I managed to read a $55 from $43020 and store it into $43030 with a program running in bank 4.
Okay, it only tooks me a day to store a $55 in bank 4! Hooray!
Hi Snoopy,
Frage, gibt eine Zerropageadresse für den Tastaturpuffer. Habe diesbezüglich noch nichts richtiges gefunden.
Ich habe mal eine Seite gefunden wo alle Zerropageadressen aufgeliste waren, nur finde ich die nicht mehr. 
Frage, gibt eine Zerropageadresse für den Tastaturpuffer. Habe diesbezüglich noch nichts richtiges gefunden.
Ich habe mal eine Seite gefunden wo alle Zerropageadressen aufgeliste waren, nur finde ich die nicht mehr.
Der Tastaturpuffer ist bei $200 bis $2A1 bzw. $2B0 bis $2BA.
Die Übersicht von der Seite finde ich ganz nett.
