|
Post by Wagner on Nov 13, 2017 17:04:12 GMT
If zero-page could be moved to any arbitrary boundary, then one could readily work around the register problem at $00 and $01. Since zero-page can only be moved to a page boundary, it would seem to be impossible to get at RAM at $ff00 and $ff01 by relocating zero-page. As far as I can tell, this problem persists with every page, not just page $ff. Apparently, RAM at $ff00 and $ff01 can only be accessed using the PHA and PLA instructions along with relocating the stack.
There might be other practical uses, but I simply happened to be bug-fixing an editor when I read this thread and a light bulb went on in my head. I'm happy to have found a practical use at all for relocating the stack. Even though I'm not using this technique to get access to RAM at $ff00 and $ff01, but under ROM and I/O instead, it still seems relevant to this thread.
|
|
|
Post by hydrophilic on Nov 17, 2017 12:28:49 GMT
I agree @wagner. If somebody wants to directly read $xx00 or $xx01 using page redirection, then the only choice is page-1 (stack-page) redirection. But if somebody wants to write $xx00 or $xx01, then another option is page-0 redirection. HOWEVER -- this can/will muck up the 40-column screen (no problem if an 80-column application) and/or the cassette drive (rare for C128 software).
Well that is my understanding. I haven't actually tried writing $00/$01 with zero-page redirection! Flame me if I'm wrong, but please elaborate on the details while toasting me.
|
|
|
Post by Wagner on Nov 17, 2017 14:13:10 GMT
I haven't tried this either, but my intuition tells me that writes to $00 and $01 in any relocated zero-page will go to the I/O registers and not to RAM, the same as writing to $00 and $01 in the normal page 0 zero-page does.
Page 420 of COMPUTE!'s Mapping the Commodore 128 book, in reference to relocating zero-page using $d507, states the same thing--"Notice that addresses 0-1 from zero page are not affected. These are the processor's on-chip I/O port registers--not RAM. Storing values in these locations always affects the registers rather than RAM."
I suppose one should verify that this is really so and not just take Ottis R. Cowper's word for it. Like Michael Faraday said, "I was never able to make a fact my own without seeing it."
It's interesting that relocating the stack can see through the mirage of $ff00 and $ff01 and read/write the RAM there. And zero-page could have too, if it didn't already have I/O registers of it's own to deal with. I'm supposing that relocating the stack into zero-page would also be able to access the RAM at $00 and $01. Seems to me I even read that somewhere.
As many people know, the VDC registers can be accessed on the 64 side of things. On the other hand, I've tried relocating the stack in 64 mode using register $d509, but it seems glued to page 1 and cannot be moved.
|
|
|
Post by hydrophilic on Nov 22, 2017 11:24:56 GMT
There is an interesting document (I don't know where) about how 6510/8502 writes to $00 and $01. More importantly, there is an Java-Script emulation of the chip at www.Visual6502.org. Anyway, the main point (if I understand correctly), is that if you write $00/$01 (directly or through MMU redirection), then BOTH the internal CPU registers *and* the underlying RAM will be updated. As I understand the hardware, ALL writes 'bleed' out of the CPU. So the I/O registers will be affected by writes to $00/$01, but the underlying RAM will also be updated! I have never attempted to test this, so it could be wrong... I'm only telling you what I've read. I don't know about the VDC, but for 64-mode, I can tell you that changing the BANK works. For example, you can set the MMU to use Bank1 for both zero page and page one, and then switch to C64 mode and run any software. If you do a physical reset (boot into C128 MONITOR) then you can recover all the page 0 and page 1 data from the C64 program hidden in Bank1. I know because I used my C128 to hack many C64 games. I've read that the MMU can not re-direct I/O memory. So attempting to access the VDC (or VIC/SID/CIA/etc.) via page-redirection will probably fail... but again this is only what I've read... never tried it myself!
|
|
|
Post by remark on Nov 22, 2017 12:05:53 GMT
There is an interesting document (I don't know where) about how 6510/8502 writes to $00 and $01. More importantly, there is an Java-Script emulation of the chip at www.Visual6502.org. Anyway, the main point (if I understand correctly), is that if you write $00/$01 (directly or through MMU redirection), then BOTH the internal CPU registers *and* the underlying RAM will be updated. As I understand the hardware, ALL writes 'bleed' out of the CPU. So the I/O registers will be affected by writes to $00/$01, but the underlying RAM will also be updated! I have never attempted to test this, so it could be wrong... I'm only telling you what I've read. I don't know about the VDC, but for 64-mode, I can tell you that changing the BANK works. For example, you can set the MMU to use Bank1 for both zero page and page one, and then switch to C64 mode and run any software. If you do a physical reset (boot into C128 MONITOR) then you can recover all the page 0 and page 1 data from the C64 program hidden in Bank1. I know because I used my C128 to hack many C64 games. I've read that the MMU can not re-direct I/O memory. So attempting to access the VDC (or VIC/SID/CIA/etc.) via page-redirection will probably fail... but again this is only what I've read... never tried it myself! Maybe you are referring to this page on codebase64? (at the end is a section on the C128) codebase64.org/doku.php?id=base:memmanage
|
|
|
Post by hydrophilic on Nov 22, 2017 12:39:47 GMT
No I wasn't referring to that document or anything other document in particular. It was mostly my limited personal experience (although I did add a web link for readers to pursue). Anyway, thanks remark... that is a great article! It reminds me that the data written to RAM can be random. I haven't tested this, but it sounds reasonable. Assuming that is the case, then once again we are only left with Page-1 redirection method (assuming a coder is not confident with "random" Page-0 redirection).
|
|
|
Post by jusalak on Oct 1, 2023 18:37:37 GMT
I wrote a small program to read the RAM below MMU registers $ff00-$ff04. There is no need to mess with PLA instructions, a simple stack page relocation and reading with LDA $0100-$0104 is sufficient.
main .org $1c01 .byte $0c,$08,$0a,$00,$9e,$37,$31,$38,$31,$00,$00,$00
sei lda #$3e sta $ff00 ldy $d506 lda #$00 sta $d506 sta $d50a lda #$ff sta $d509 lda $0100 sta ramxx lda $0101 sta ramxx+1 lda $0102 sta ramxx+2 lda $0103 sta ramxx+3 lda $0104 sta ramxx+4 lda #$01 sta $d50a lda #$ff sta $d509 lda $0100 sta ramxx+5 lda $0101 sta ramxx+6 lda $0102 sta ramxx+7 lda $0103 sta ramxx+8 lda $0104 sta ramxx+9 ldx #$00 stx $d50a inx stx $d509 sty $d506 cli lda #$00 sta $ff00
jsr $ff7d .byte $0d,'BANK 0 RAM:',$0d,$00
ldx #$ff lda #$00 jsr $b89f lda ramxx jsr $b8a5
ldx #$ff lda #$01 jsr $b89f lda ramxx+1 jsr $b8a5
ldx #$ff lda #$02 jsr $b89f lda ramxx+2 jsr $b8a5
ldx #$ff lda #$03 jsr $b89f lda ramxx+3 jsr $b8a5
ldx #$ff lda #$04 jsr $b89f lda ramxx+4 jsr $b8a5
jsr $ff7d .byte $0d,'BANK 1 RAM:',$0d,$00
ldx #$ff lda #$00 jsr $b89f lda ramxx+5 jsr $b8a5
ldx #$ff lda #$01 jsr $b89f lda ramxx+6 jsr $b8a5
ldx #$ff lda #$02 jsr $b89f lda ramxx+7 jsr $b8a5
ldx #$ff lda #$03 jsr $b89f lda ramxx+8 jsr $b8a5
ldx #$ff lda #$04 jsr $b89f lda ramxx+9 jsr $b8a5
lda #$0d jmp $ffd2
ramxx
endcode
A .prg file can be created by pasting the following dump into MONITOR in VICE or Z64K:
>01c00 00 0c 08 0a 00 9e 37 31 >01c08 38 31 00 00 00 78 a9 3e >01c10 8d 00 ff ac 06 d5 a9 00 >01c18 8d 06 d5 8d 0a d5 a9 ff >01c20 8d 09 d5 ad 00 01 8d 24 >01c28 1d ad 01 01 8d 25 1d ad >01c30 02 01 8d 26 1d ad 03 01 >01c38 8d 27 1d ad 04 01 8d 28 >01c40 1d a9 01 8d 0a d5 a9 ff >01c48 8d 09 d5 ad 00 01 8d 29 >01c50 1d ad 01 01 8d 2a 1d ad >01c58 02 01 8d 2b 1d ad 03 01 >01c60 8d 2c 1d ad 04 01 8d 2d >01c68 1d a2 00 8e 0a d5 e8 8e >01c70 09 d5 8c 06 d5 58 a9 00 >01c78 8d 00 ff 20 7d ff 0d 42 >01c80 41 4e 4b 20 30 20 52 41 >01c88 4d 3a 0d 00 a2 ff a9 00 >01c90 20 9f b8 ad 24 1d 20 a5 >01c98 b8 a2 ff a9 01 20 9f b8 >01ca0 ad 25 1d 20 a5 b8 a2 ff >01ca8 a9 02 20 9f b8 ad 26 1d >01cb0 20 a5 b8 a2 ff a9 03 20 >01cb8 9f b8 ad 27 1d 20 a5 b8 >01cc0 a2 ff a9 04 20 9f b8 ad >01cc8 28 1d 20 a5 b8 20 7d ff >01cd0 0d 42 41 4e 4b 20 31 20 >01cd8 52 41 4d 3a 0d 00 a2 ff >01ce0 a9 00 20 9f b8 ad 29 1d >01ce8 20 a5 b8 a2 ff a9 01 20 >01cf0 9f b8 ad 2a 1d 20 a5 b8 >01cf8 a2 ff a9 02 20 9f b8 ad >01d00 2b 1d 20 a5 b8 a2 ff a9 >01d08 03 20 9f b8 ad 2c 1d 20 >01d10 a5 b8 a2 ff a9 04 20 9f >01d18 b8 ad 2d 1d 20 a5 b8 a9 >01d20 0d 4c d2 ff
The program can then be saved with the MONITOR command:
S "FF0XRAM",8,1C01,1D24
These memory addresses are conveniently written to in C64 mode (bank 0 and/or bank 1).
|
|
|
Post by wsoft on Apr 13, 2024 15:05:28 GMT
All of this trouble about writing to what is beneath $ff00. I might understand the importance of using every single byte on a Vic-20 but hey, not even generic C64 users who have an REU are concerned about such trivialties. Nice to see that you guys have got it all figured out though. Stuff like this qualifies more in the "trivia" department, and away from the "tips and tools". There is such a thing as "useful information" to a Commodore programmer and then well... there's this. Knowing the MMU is helpful though- yes it is.
|
|
|
Post by bjonte on Apr 13, 2024 20:09:05 GMT
This is actually quite useful and somewhat important. When making games you often want to use the uppermost VIC bank and this hole makes it hard to place a bitmap as high up in memory as possible. It also makes it possible to make more C64 programs bootable in C128 mode.
|
|