x128 RAM bank selection faulty in 64 mode
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
1 Attachments
#1835 x128 RAM bank selection faulty in 64 mode
There is a trick mentioned in the book
William M. Wiese, Jr.: Commodore 128 Programming Secrets, page 4 https://dokumen.pub/commodore-128-programming-secrets-9780078812507-007881250x.html
namely, that the RAM bank (0 or 1) is selectable in C64 mode, even if normally the bank 0 is used in C64 mode.
So I wrote a piece of code to test this. Attached as a snapshot.
Type SYS 14336 to enter C64 mode with bank 1, and GO64 with bank 0.
bank 0 $3800 jump to bank 1 $3800
bank 1 $3800 set RAM bank 1 and go64
bank 1 $c000 test code to cycle border colour
bank 0 $c000 test code to cycle background colour
After SYS 14336, when I type PRINT PEEK(49153) it gives correctly 32 (lower byte of $d020 in bank 1). But SYS 49152 cycles background colour ($d021, reading the code from bank 0). So there is something messed up in the emulation of MMU in C64 mode.
Using GO64 correctly uses only bank 0.
Please attach the actual .prg file, preferably with source. Snapshots are not suitable for this, they can only work right in the exact same emulator version they were created with.
I typed it in using the C128 monitor.
d03800
. 03800 a9 01 lda #$01 ;begin in bank 0, prepare to jump to bank 1 $3800
. 03802 85 02 sta $02
. 03804 a9 38 lda #$38
. 03806 85 03 sta $03
. 03808 a9 00 lda #$00
. 0380a 85 04 sta $04
. 0380c 20 71 ff jsr $ff71
d13800
. 13800 78 sei
. 13801 a9 4e lda #$4e
. 13803 8d 00 ff sta $ff00
. 13806 a9 e3 lda #$e3
. 13808 85 01 sta $01
. 1380a a9 2f lda #$2f
. 1380c 85 00 sta $00
. 1380e a9 44 lda #$44 ;set RAM bank for VIC
. 13810 8d 06 d5 sta $d506
. 13813 a9 f7 lda #$f7; switch to C64
. 13815 8d 05 d5 sta $d505
. 13818 6c fc ff jmp ($fffc)
d 0c000
. 0c000 ae 21 d0 ldx $d021 ; test code, cycle background colour
. 0c003 e8 inx
. 0c004 8e 21 d0 stx $d021
. 0c007 60 rts
d 1c000
. 1c000 ae 20 d0 ldx $d020 ; test code, cycle border colour
. 1c003 e8 inx
. 1c004 8e 20 d0 stx $d020
. 1c007 60 rts
The code is expected to use the code at 1c000, but x128 reads both banks, as described above. Anyway, the attached snapshot, created with the official v3.7, runs with the latest r43170 with same results.
Please make it into a program that can be loaded and run from the basic prompt, and if possible make it turn the border green if the correct thing happens and red if the wrong thing happens.
Doing that will make testing so much easier for both x128, a real c128 and other emus.
And if you go this for, also write 0 to $d7ff on success, and $ff to $d7ff on failure - then we can drop it into the testbench :)
(but a plain program with source is fine, i'll do the rest then)
Attached. After entering 64 mode type SYS 49152.
Demanding programs (games, demos) begin to crash in Bank1 64 mode.
Last edit: Jussi Ala-Könni 2023-02-15
Should be fixed in rev 43175, please svn up, build and try again.
After quick testing Bank 1 seems to function now in 64 mode. Now Bank 0 remains intact, no matter whatever the user does in 64 mode. Even the C128 screen flashes back for a moment when doing a soft reset.
Presumably even Banks 2 and 3 could used, even if it cannot easily tested in real HW?
Another interesting question is whether the common RAM remains in effect in 64 mode. I did another test program (attached). Doing SYS 8000 in 64 mode gives red border with negative result (no common ram), green border with positive result (common RAM in effect).
good question, I'll try the test program later, and if the answer is yes, then most likely something like page 0 and page 1 relocation also remains intact, I'll check it out and see what I can do to fix this if it turns out that those kinds of mappings remain.
from initial tests it looks like common memory and page 0/page 1 remappings are ignored in c64 mode, not just in vice but also in z64k, to be certain for this the program will need to be tested on real hardware.
Last edit: Marco van den Heuvel 2023-02-15
There was an error in the test program, the value written to RCR is corrected to $46. (8k common bottom RAM). Corrected one attached.
Results of test programs from real hardware. PAL 128D
64banktest.prg - light green border
64commonramtest.prg - red border
Thank you William.
So from the test result only the bank is carried through to c64 mode, not the common area, and I suspect p0/p1 relocation is also ignored in c64 mode.
Did you use the corrected version (has LDA #$46 at $1380E, poking at RCR)?
updated 64commonramtest.prg on real hardware, light green border, garbage on screen
Screen filled with garbage when entering C64 mode, but I was still able to blindly enter sys8000 to get result.
Last edit: William McCabe 2023-02-15
oh, interesting, on z64k red border, x128 also red border
Interesting. Green border would mean that the common RAM remains in effect in 64 mode.
I think the garbage is because VIC points to bank 1 in the common area, which is bank 0. Try poking #$06 to the RCR.
Attached - VIC changed to bank 0.
Last edit: Jussi Ala-Könni 2023-02-15
Yes, you are correct! 64commonramtest2.prg shows light green border with screen displaying correctly. I've applied a fix to Z64K which now matches real hardware behavior for all versions of test programs which I'll release after regression testing.
In summary it appears the last mmu configuration is enforced in c64 mode. I'd be interested to see tests on other mmu features such as mapping in z80 and c128 kernal being mapped in when entering c64 mode!
It has occurred to me as well, has anyone actually tested what will happen if z80 and c64 are enabled at the same time. The combination itself could be entirely valid.
I never earlier gave much thought to the matter whether the common ram applies only to the processor, or to VIC as well. Good that the latest test program worked. What about extra ram banks 2 & 3 - supposedly they should work as bank 1?
bank 2 should work as bank 0, bank 3 as bank 1, in a hacked mmu situation bank 2 and 3 work as their own banks, in a standard mmu system the top bank bit is ignored and so bank 2 is bank 0 and bank 3 is bank 1.
what I also wonder now is if p0/p1 relocation makes it through to c64 mode, in the next few days I'll adapt the test progs in this post to be more automatic and will add some p0 and p1 test progs.
Jussi Ala-Könni, thank you for bringing all this up, it's very interesting, and our (me and William) goal is to have our c128 emu's emulate the real c128 as much and close as possible.