|
Post by oziphantom on Apr 30, 2019 12:04:04 GMT
So I'm trying to get fancy with stack relocation. in X128 it works, in hardware it doesn't and in Z64K it doesn't.
The "docs" well some of them, say that you if you have Share Memory Bottom enabled the Stack is forced into Bank 0. However I have tried it with d506 set to 3 (16K but no overlap specified) and with 0. And still my PHA pushes to $0:01ff not $1:feff as it should. I can't seem to read D500 registers in Z64K but on VICE they are set as expected.
lda #$3e sta $ff00 lda #1 sta $d030 lda #1 sta $d507 lda #%0000000 ;16K size, but no overlap, VIC Bank 0 sta $d506 lda #%00111110 ; RAM 0 + IO sta $d501 lda #%01111111 ; RAM 1 sta $d502 ..... lda #1 sta MMU_STACK_BANK ; upper bank#get_crunched_byte sta zp_dest_hi sta MMU_STACK_PAGE lda #1 sta MMU_STACK_BANK ; upper bank I've also tried setting the VIC bank to 1 incase that has effect under fast mode. Any ideas on what else needs to be done to get the Stack to move?
|
|
|
Post by oziphantom on Apr 30, 2019 14:40:57 GMT
There must be more to this. on hardware 1c0d sei lda #$3e sta $d501 sta $ff00 lda #$00 sta $d506 lda #$01 sta $d50a ldx #$ff stx $d509 txs lda #$8c pha lda #0 sta $ff00 brk This will then cause the monitor m 1fff0 to lock up, but if I do a reset then m 1fff0 1ffff is unchanged...
|
|
|
Post by oziphantom on Apr 30, 2019 15:00:47 GMT
*= $1c0e sei #JustIO tsx stx ahead+1 lda #0 sta MMU_STACK_BANK lda #$20 sta MMU_STACK_PAGE ldx #$01 txs lda #0 sta $d506 ; disable shared lda #5 pha lda #4 sta $d506 ; enable shared lda #4 pha ;restore stack lda #$00 sta MMU_STACK_BANK lda #$01 sta MMU_STACK_PAGE ahead ldx #1 txs lda #0 sta $ff00 ; bank 15 cli brk
in Z64K gets me >02000 04 05
|
|
|
Post by oziphantom on Apr 30, 2019 15:07:01 GMT
sei #JustIO tsx stx ahead+1 lda #1 sta MMU_STACK_BANK lda #$20 sta MMU_STACK_PAGE ldx #$01 txs lda #0 sta $d506 ; disable shared lda #5 pha lda #4 sta $d506 ; enable shared lda #4 pha ;restore stack lda #$00 sta MMU_STACK_BANK lda #$01 sta MMU_STACK_PAGE ahead ldx #1 txs lda #0 sta $ff00 ; bank 15 cli brk
>02000 04 05 >12000 ff ff
|
|
|
Post by oziphantom on Apr 30, 2019 15:13:36 GMT
sei #JustIO tsx stx ahead+1 lda #1 sta MMU_STACK_BANK lda #$20 sta MMU_STACK_PAGE ldx #$01 txs lda #0 sta $d506 ; disable shared lda #5 pha lda #4 sta $d506 ; enable shared lda #4 pha ;restore stack lda #$00 sta MMU_STACK_BANK lda #$01 sta MMU_STACK_PAGE ahead ldx #1 txs lda #0 sta $ff00 ; bank 15 lda #4 sta $d506 ; restore to default cli brk I added a restore of d506 at the end, now I get >02000 04 ff >12000 ff 05
|
|
|
Post by willymanilly on Apr 30, 2019 23:04:39 GMT
I don't have time now to go through your code but I've just added basic mmu dumping functionality in Z64K's machine monitor which I've uploaded to the website. You can use the command io d500Have you seen the mmu test programs available in the VICE test repository? I had the author of those programs contact me awhile back to improve MMU emulation in Z64K and I spent a bit of time on it comparing the zero page and stack page pointer functionality to real hardware so it should be reasonably accurate. I should have time tomorrow after work to have a good look at your code and fix any bugs in Z64K if required after testing on real hardware.
|
|
|
Post by oziphantom on May 1, 2019 7:56:07 GMT
I got it to work, eventually. I think the issue is VICE doesn't do address mirroring when doing the ZP swap.. hard to be sure sure
looking at the test lda #%00110011 ; disable basic sta $01 are they sure this is for a 128???
The main issue for me was all 3 seem different. It seems the 128 Monitor must have share mem enabled in order for it to show what is in RAM, otherwise it shows the wrong thing. Its banking doesn't handle Stack swaps properly.
What does you monitor do? If I do rb1 does it show me from the chips point of view, or from the cpus point of view?
My original way was set d506 to be 3 so 16K no shared
then I would do inc d506 <= shared 1K bottom sta ff01 <= switch to bank 1 RAM lda (pointer),y <= read from Ram1 sta ff00 <= switch to bank 0 RAM dec d506 <= 16K no shared
This worked on VICE, but gave me corrupted uncompressed data on hardware and Z64K. I'm guessing this was at fault for how the data was corrupted, but hard to be sure.
I now do dec d509 <= move stack down 1 page, so ram above has to be ram sta ff01 <= switch to bank 1 RAM lda (pointer),y <= read from Ram1 sta ff00 <= switch to bank 0 RAM inc d509 <= move stack back which seems to work.
|
|
|
Post by willymanilly on May 1, 2019 13:05:13 GMT
looking at the test lda #%00110011 ; disable basic sta $01 are they sure this is for a 128??? Yes, they definitely created it for the c128 purely to test MMU behaviour. Not sure why they tried to disable basic in C128 mode using the cpu io register though. That value to the CPU IO register would set the color RAM bank to 1 for both cpu and VIC, and maps in character ROM... What does you monitor do? If I do rb1 does it show me from the chips point of view, or from the cpus point of view? rb1 simply sets bit 6 of MMU register 0 to map in ram bank 1. Memory dumping and disassembly in Z64K is always from the CPU's point of view. The command noramshare is one way RAM can be disassembled and dumped from the chips point of view but is destructive in the sense that shared memory will remain disabled when exiting the monitor until register 6 is written to again. In case you didn't know already, using commands like rb0, rb1 and z80 do not automatically restore the machine state when exiting the monitor so any program running might crash if you don't manually restore them back to the original values.
|
|
|
Post by oziphantom on May 2, 2019 12:16:22 GMT
In case you didn't know already, using commands like rb0, rb1 and z80 do not automatically restore the machine state
Umm why is it modifying the state of the machine!!!! that does explain a lot now that I know I'm not looking at the emulators monitor output but through the eyes of the 128. An emulator monitor however should be a perfect eagle eye that lets me see everything without changing the machine being looked at. So when I do rb1 it should show me ram bank 1 and the actual pure RAM. Leaving actual MMU untouched. Although 9bit address support in the monitor would be better.
|
|
|
Post by willymanilly on May 2, 2019 14:11:33 GMT
In case you didn't know already, using commands like rb0, rb1 and z80 do not automatically restore the machine state Umm why is it modifying the state of the machine!!!! that does explain a lot now that I know I'm not looking at the emulators monitor output but through the eyes of the 128. An emulator monitor however should be a perfect eagle eye that lets me see everything without changing the machine being looked at. So when I do rb1 it should show me ram bank 1 and the actual pure RAM. Leaving actual MMU untouched. Although 9bit address support in the monitor would be better. I totally agree with you. I concede debugging features of Z64K are limited at the moment hence why I haven't widely documented them. The commands like rb0, rb1 etc, were really only created for my own debugging purposes during development of the emulator and weren't intended to be core debugging features. Version 2 of Z64K I'm currently building from the ground up will have greatly improved debugging tools and command line options similar to what emulators like VICE offer. The debugging output will be customisable among other features. It's still a couple of months away before I think it will be ready for a first release so happy to still update the existing version of Z64K's monitor features. Anyway I'll tame the discussed commands so the system restores to it's original state when exiting the monitor. I'll do that over the weekend. It's only rb0,rb1, noramshare, z80 and 6502 that affect machine state. I'll also include the 9 bit address support in the existing monitor.
|
|