Virtualc64: PageFox cartridges not supported
These test cartridges are recognized as Pagefox and are not supported; on VICESC they work.
Alessandro1970
All 26 comments
Does someone know where the Pagefox cartridge (.crt file) can be found?
dirkwhoffmann
on 12 Sep 2020
For the records, here is the memory test source code. The Pagefox cart is documented https://www.forum64.de/index.php?thread/43216-pagefox-reversed/
; +-------------------------------------------------------------------------+
; | This file was generated by The Interactive Disassembler (IDA) |
; | Copyright (c) 2020 Hex-Rays, <[email protected]> |
; | License info: 48-3051-7314-20 |
; | Markus Fritze, personal use |
; +-------------------------------------------------------------------------+
;
; Input SHA256 : 88F5DC85C4D3FA578332A86C079778E5D091A5729A58E968D7417E5D48076D3F
; Input MD5 : 7CA44EFAFFEDED25F80358DC70787EAB
; Input CRC32 : 8B74C7B6
; ; Processor: M6502
; ; Target assembler: Table Driven Assembler (TASM) by Speech Technology Inc.
; ===========================================================================
; Segment type: Regular
;.segment RAM
.org 0A0h
pagefox_bank: .block 1
.block 0Dh
ram_addr: .block 2 ; DATA XREF: ram_test+A↓w
; ram_test+2D↓w ...
save_x: .block 1
save_y: .block 1
.block 34Eh
screen_adr_0400:.block 400h ; DATA XREF: ram_test+62↓w
; _start+47↓w
; end of 'RAM'
; ===========================================================================
; Segment type: Regular
;.segment seg001
.org 1000h
; =============== S U B R O U T I N E =======================================
ram_test: ; DATA XREF: _start+28↓w
; _start+2E↓t
LDA #08h
STA pagefox_bank
LDA #>RAMBASE_8000
STA ram_addr+1
LDA #<RAMBASE_8000
STA ram_addr
LDA #0FFh ; Pagefox: disable cartridge
STA 0DE80h
LDX #34h ; RAM, RAM, RAM
STX 1
LDX #0
_loop1: ; CODE XREF: ram_test+21↓j
TXA
STA RAMBASE_8000,X ; Set values for 8000h-9FFFh in C64 RAM
EOR #0FFh
STA RAMBASE_A000,X ; Set values for A000h-BFFFh in C64 RAM
INX
BNE _loop1
LDA #08h ; Pagefox: RAM lower bank
STA pagefox_bank
LDA #>RAMBASE_8000 ; Start at 8000h
STA ram_addr+1
LDA #<RAMBASE_8000
STA ram_addr
LDX #0
_loop2: ; CODE XREF: ram_test+38↓j
TXA
EOR #55h
JSR write_memory_address ; Test memory block
INX
BNE _loop2
LDA #0Ah ; Pagefox: RAM upper bank
STA pagefox_bank
LDA #>RAMBASE_A000 ; Start at A000h
STA ram_addr+1
LDA #<RAMBASE_A000
STA ram_addr
LDX #0
_loop3: ; CODE XREF: ram_test+4F↓j
TXA
EOR #0AAh
JSR write_memory_address ; Test memory block
INX
BNE _loop3
LDY #10 ; light red
LDA #0FFh ; Pagefox: disable cartridge
STA 0DE80h
LDX #34h ; RAM, RAM, RAM
STX 1
LDX #0
_cmploop1: ; CODE XREF: ram_test+78↓j
TXA
CMP RAMBASE_8000,X ; ? Patched out LDA $8000,X ?
STA screen_adr_0400,X ; Store expected values in page #1 of the video RAM
CMP RAMBASE_A000,X ; ? Patched out LDA $A000,X ?
STA (screen_adr_0400+100h),X ; Store expected values in page #2 of the video RAM (actually it should be EOR #$FF)
CMP RAMBASE_8000,X ; C64 RAM ok?
BNE _error_return ; error =>
EOR #0FFh
CMP RAMBASE_A000,X ; C64 RAM ok?
BNE _error_return ; error =>
INX
BNE _cmploop1
LDX #37h ; BASIC, I/O, KERNAL
STX 1
LDA #08h ; Pagefox: cartridge disabled, CS:RAM, Bank lower
STA 0DE80h
LDX #0
_cmploop2: ; CODE XREF: ram_test+94↓j
LDA RAMBASE_8000,X ; Copy Pagefox lower RAM into page #3 of the video RAM
STA (screen_adr_0400+200h),X
TXA
EOR #55h
CMP RAMBASE_8000,X ; Pagefox: lower RAM ok?
BNE _error_return ; error =>
INX
BNE _cmploop2 ; Copy Pagefox lower RAM into page #3 of the video RAM
LDA #0Ah ; Pagefox: cartridge disabled, CS:RAM, Bank upper
STA 0DE80h
LDX #0
_cmploop3: ; CODE XREF: ram_test+AC↓j
LDA RAMBASE_A000,X ; Copy Pagefox upper RAM into page #4 of the video RAM
STA (screen_adr_0400+300h),X
TXA
EOR #0AAh
CMP RAMBASE_A000,X ; Pagefox: upper RAM ok?
BNE _error_return ; error =>
INX
BNE _cmploop3 ; Copy Pagefox upper RAM into page #4 of the video RAM
LDY #5 ; green
_error_return: ; CODE XREF: ram_test+6E↑j
; ram_test+75↑j ...
LDA #35h ; RAM, I/O, RAM
STA 1
STY 0D020h ; frame color = light red or green
LDA #00h
CPY #5 ; color == green?
BEQ _jmp ; => ok
LDA #0FFh
_jmp: ; CODE XREF: ram_test+BB↑j
STA 0D7FFh ; Exit VICE emulator with exit code in A
_endless: ; CODE XREF: ram_test:_endless↓j
JMP _endless
; End of function ram_test
; =============== S U B R O U T I N E =======================================
; Test memory block
write_memory_address: ; CODE XREF: ram_test+34↑p
; ram_test+4B↑p
STX save_x
STY save_y ; save X and Y (color) to restore later
LDX #34h ; RAM, RAM, RAM
STX 1
LDY #0
TAX ; A = value to test memory
LDA (ram_addr),Y ; Save memory from C64 RAM
PHA
INC 1 ; Enable I/O
LDA pagefox_bank ; Pagefox: select bank
STA 0DE80h
TXA
STA (ram_addr),Y ; Write memory into Pagefox memory (and C64 RAM!)
LDA #0FFh ; Pagefox: disable cartridge
STA 0DE80h
DEC 1 ; Disable I/O
PLA
STA (ram_addr),Y ; Restore memory from C64 RAM
INC ram_addr ; Increment memory address
BNE _raminc
INC ram_addr+1
_raminc: ; CODE XREF: write_memory_address+24↑j
LDA ram_addr+1
CMP #>BE80h ; < BE80h?
BCC _samebank ; => yes
LDA ram_addr
CMP #<BE80h
BCC _samebank ; => yes
LDA pagefox_bank ; Already testing upper RAM bank?
CMP #0Ah
BEQ _samebank ; => yes
LDA #0Ah ; Pagefox RAM bank upper
STA pagefox_bank
LDA #>RAMBASE_A000 ; AE/AF = 8000h
STA ram_addr+1
ASL A ; A = 00h
STA ram_addr
_samebank: ; CODE XREF: write_memory_address+2C↑j
; write_memory_address+32↑j ...
LDA #36h ; RAM, I/O, KERNAL
STA 1
LDX save_x ; restore X
LDY save_y ; restore Y (color)
RTS
; End of function write_memory_address
; end of 'seg001'
; Format : Binary file
; Base Address: 0000h Range: 8000h - 9000h Loaded length: 1000h
; ===========================================================================
; Segment type: Pure code
;.segment ROM
.org 8000h
RAMBASE_8000: .dw _start ; DATA XREF: ram_test+4↑t
; ram_test+8↑t ...
.dw _start
.db 0C3h, 0C2h, 0CDh, 38h, 30h
; =============== S U B R O U T I N E =======================================
_start: ; DATA XREF: ROM:RAMBASE_8000↑o
; ROM:8002↑o
SEI
LDA #1Bh ; Screen on, 25 lines, YSCROLL=3
STA 0D011h
LDA #17h ; VRAM: 0400h, Font: D800h
STA 0D018h
LDA #0C8h ; 40 columns
STA 0D016h
LDA #0 ; black
STA 0D020h ; frame color
STA 0D021h ; background color
LDA #0E7h ; Font ROM, HIRAM, LORAM
STA 1
LDA #2Fh
STA 0
LDX #0FFh ; Initialize stack pointer
TXS
LDX #0
_copy_loop: ; CODE XREF: _start+54↓j
LDA ram_test_r,X ; copy code into RAM to 1000h
STA ram_test,X
LDA (ram_test_r+100h),X
STA ram_test+100h,X
LDA #1 ; white
STA 0D800h,X
LDA #2 ; red
STA 0D900h,X
LDA #3 ; turquois
STA 0DA00h,X
LDA #4 ; violet
STA 0DB00h,X
LDA #' ' ; Fill videoram with spaces
STA screen_adr_0400,X
STA (screen_adr_0400+100h),X
STA (screen_adr_0400+200h),X
STA (screen_adr_0400+300h),X
INX
BNE _copy_loop ; copy code into RAM to 1000h
JMP ram_test
; End of function _start
; ---------------------------------------------------------------------------
ram_test_r: .db 0A9h, 8, 85h,0A0h,0A9h, 80h, 85h,0AFh
; DATA XREF: _start:_copy_loop↑r
.db 0A9h, 0, 85h,0AEh,0A9h,0FFh, 8Dh, 80h
.db 0DEh,0A2h, 34h, 86h, 1,0A2h, 0, 8Ah
.db 9Dh, 0, 80h, 49h,0FFh, 9Dh, 0,0A0h
.db 0E8h,0D0h,0F4h,0A9h, 8, 85h,0A0h,0A9h
.db 80h, 85h,0AFh,0A9h, 0, 85h,0AEh,0A2h
.db 0, 8Ah, 49h, 55h, 20h,0C5h, 10h,0E8h
.db 0D0h,0F7h,0A9h, 0Ah, 85h,0A0h,0A9h,0A0h
.db 85h,0AFh,0A9h, 0, 85h,0AEh,0A2h, 0
.db 8Ah, 49h,0AAh, 20h,0C5h, 10h,0E8h,0D0h
.db 0F7h,0A0h, 0Ah,0A9h,0FFh, 8Dh, 80h,0DEh
.db 0A2h, 34h, 86h, 1,0A2h, 0, 8Ah,0DDh
.db 0, 80h, 9Dh, 0, 4,0DDh, 0,0A0h
.db 9Dh, 0, 5,0DDh, 0, 80h,0D0h, 40h
.db 49h,0FFh,0DDh, 0,0A0h,0D0h, 39h,0E8h
.db 0D0h,0E4h,0A2h, 37h, 86h, 1,0A9h, 8
.db 8Dh, 80h,0DEh,0A2h, 0,0BDh, 0, 80h
.db 9Dh, 0, 6, 8Ah, 49h, 55h,0DDh, 0
.db 80h,0D0h, 1Dh,0E8h,0D0h,0EFh,0A9h, 0Ah
.db 8Dh, 80h,0DEh,0A2h, 0,0BDh, 0,0A0h
.db 9Dh, 0, 7, 8Ah, 49h,0AAh,0DDh, 0
.db 0A0h,0D0h, 5,0E8h,0D0h,0EFh,0A0h, 5
.db 0A9h, 35h, 85h, 1, 8Ch, 20h,0D0h,0A9h
.db 0,0C0h, 5,0F0h, 2,0A9h,0FFh, 8Dh
.db 0FFh,0D7h, 4Ch,0C2h, 10h, 86h,0B0h, 84h
.db 0B1h,0A2h, 34h, 86h, 1,0A0h, 0,0AAh
.db 0B1h,0AEh, 48h,0E6h, 1,0A5h,0A0h, 8Dh
.db 80h,0DEh, 8Ah, 91h,0AEh,0A9h,0FFh, 8Dh
.db 80h,0DEh,0C6h, 1, 68h, 91h,0AEh,0E6h
.db 0AEh,0D0h, 2,0E6h,0AFh,0A5h,0AFh,0C9h
.db 0BEh, 90h, 17h,0A5h,0AEh,0C9h, 80h, 90h
.db 11h,0A5h,0A0h,0C9h, 0Ah,0F0h, 0Bh,0A9h
.db 0Ah, 85h,0A0h,0A9h, 80h, 85h,0AFh, 0Ah
.db 85h,0AEh,0A9h, 36h, 85h, 1,0A6h,0B0h
.db 0A4h,0B1h, 60h
.block 1E8Bh
; end of 'ROM'
; ===========================================================================
; Segment type: Regular
;.segment BASIC
.org 0A000h
RAMBASE_A000: .block 2000h ; DATA XREF: ram_test+1D↑w
; ram_test+3E↑t ...
; end of 'BASIC'
.end
sarnau
on 12 Sep 2020
Thanks for the source code!
Now, VirtualC64 accepts PageFox crt files, but it doesn't look quite right yet: 🙈
The easiest way to debug this is the „Ultima“ approach (aka compare debug traces between VICE and VirtualC64). However, I can only compile Scene Browser for my iPhone at the moment which restricts me to use .crt files from the web database. For some reason, the proposed workaround by @mithrendal doesn’t work out for me:
the other way is ... deploy on iPhone ... download the cartigde in Safari or airdrop from your mac as you like ... and go to the files app click on the ultima_crt.zip file and choose share then the share sheets opens and you can choose c64SceneBrowser which opens it then ... then you can look at the Xcode console for the debug statements
Scene Browser always terminates with a command line argument parsing error:
CART: could not attach '/var/mobile/Containers/Data/Application/0A34EA40-39E3-453A-8A48-0D0BBBC9D509/Documents/D5329F10-D222-4269-87D8-30DCF7C4F99D/__MACOSX/._godot.crt'.
Argument '/var/mobile/Containers/Data/Application/0A34EA40-39E3-453A-8A48-0D0BBBC9D509/Documents/D5329F10-D222-4269-87D8-30DCF7C4F99D/__MACOSX/._godot.crt' not valid for option `-cartcrt'.
Error parsing command-line options, bailing out. For help use '-help'So we are back at the original problem: Getting VICE to compile on macOS Cathalina. 🙈🙈
dirkwhoffmann
on 13 Sep 2020
Scene Browser always terminates with a command line argument parsing error
please try to embed the .crt in a zip file and give that to the Scene Browser via Sharesheet instead of the pure crt file. I tried here it definitely works ...
mithrendal
on 13 Sep 2020
please try to embed the .crt in a zip file and give that to the Scene Browser via Sharesheet
I did this (I think). Here is what I did in detail:
- Open SceneBrowser in Xcode
- Select real iPhone as target
- Compile and run (Scene Browser starts on iPhone)
- Open Files app on iPhone
- Select godot.crt.zip (checkmark appears)
- Select the Share icon (box with the up arrow)
- Select Scene Browser
After than, Scene Browser produces the following output in the Xcode console and aborts:
2020-09-13 09:53:57.411513+0200 C64 Scene[1033:620407] URL: handle file:///private/var/mobile/Containers/Data/Application/FC1C50A6-4AD3-4767-8928-5E8F456C0F59/tmp/dirkwhoffmann.SceneBrowser-Inbox/godot.crt.zip
2020-09-13 09:53:57.500491+0200 C64 Scene[1033:620407] CoreText note: Client requested name ".SFUI-Regular", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[UIFont systemFontOfSize:].
2020-09-13 09:53:57.500703+0200 C64 Scene[1033:620407] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
2020-09-13 09:53:57.501401+0200 C64 Scene[1033:620407] [OHAttributedLabel] Warning: "adjustsFontSizeToFitWidth" property not supported by CoreText and OHAttributedLabel! This property will be ignored.
2020-09-13 09:53:57.501766+0200 C64 Scene[1033:620407] CoreText note: Client requested name ".SFUI-Regular", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[UIFont systemFontOfSize:].
2020-09-13 09:53:57.501992+0200 C64 Scene[1033:620407] [OHAttributedLabel] Warning: "adjustsFontSizeToFitWidth" property not supported by CoreText and OHAttributedLabel! This property will be ignored.
2020-09-13 09:53:57.502278+0200 C64 Scene[1033:620407] CoreText note: Client requested name ".SFUI-Regular", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[UIFont systemFontOfSize:].
2020-09-13 09:53:57.502492+0200 C64 Scene[1033:620407] [OHAttributedLabel] Warning: "adjustsFontSizeToFitWidth" property not supported by CoreText and OHAttributedLabel! This property will be ignored.
2020-09-13 09:53:57.502649+0200 C64 Scene[1033:620407] CoreText note: Client requested name ".SFUI-Regular", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[UIFont systemFontOfSize:].
2020-09-13 09:53:57.502826+0200 C64 Scene[1033:620407] [OHAttributedLabel] Warning: "adjustsFontSizeToFitWidth" property not supported by CoreText and OHAttributedLabel! This property will be ignored.
2020-09-13 09:53:57.523644+0200 C64 Scene[1033:620407] Metal GPU Frame Capture Enabled
2020-09-13 09:53:57.524144+0200 C64 Scene[1033:620407] Metal API Validation Enabled
SID engine set to 1
SID model set to 0
SID engine set to 1
SID model set to 0
CART: could not attach '/var/mobile/Containers/Data/Application/FC1C50A6-4AD3-4767-8928-5E8F456C0F59/Documents/0E8A0D4D-62CC-409B-A333-89C29A8689ED/__MACOSX/._godot.crt'.
Argument '/var/mobile/Containers/Data/Application/FC1C50A6-4AD3-4767-8928-5E8F456C0F59/Documents/0E8A0D4D-62CC-409B-A333-89C29A8689ED/__MACOSX/._godot.crt' not valid for option `-cartcrt'.
Error parsing command-line options, bailing out. For help use '-help'
Strange thing:
why the file it is comlaining about has a dot prefix "_MACOSX/._godot.crt"
and
even more strange why it is in a flder with the Name MacOSX
are you feeding it with the right file ? Try to start the same file in vc64web, does it accept it ?
mithrendal
on 13 Sep 2020
Try to start the same file in vc64web, does it accept it ?
Getting closer. The zip file is screwed up:
dirkwhoffmann
on 13 Sep 2020
please open that file vc64web look what is in it ... when there are two crt files in it one with "._godot.crt" and the other with godot.crt then scenebrowser is taking clearly the wrong file ...
if that is the case ... make a new zip file without the shadow file ... which contains only the godot.crt file
mithrendal
on 13 Sep 2020
Oh you were faster ...
BTW: you have 81% battery ... you may disconnect from power now ...😉
mithrendal
on 13 Sep 2020
if that is the case ... make a new zip file without the shadow file
I used Right Button -> "Komprimieren" to produce the zip file. gz files are not accepted by Scene Browser. Did you use zip inside the shell?
you have 81% battery ... you may disconnect from power now ...😉
This is my old iPhone. With its aged battery it only runs for about half an hour so without a power cord. 😬
dirkwhoffmann
on 13 Sep 2020
in the iOS files app click firmly "use force" on the crt file ... and a menu pops up ... scroll down the last entry is "komprimieren"
mithrendal
on 13 Sep 2020
Oh no ... I see that way it creates the stupid shadow file ... on my side too ... you have to do it on the mac then
mithrendal
on 13 Sep 2020
in the iOS files app click firmly "use force" on the crt file ... and a menu pops up ... scroll down the last entry is "komprinieren"
Oh I see, you zipped it on the iPhone.
Zipping the old way (using zip from the command line) also works. I can now run the crt in Scene Browser.
Unfortunately, Scene Browser performs as bad as VirtualC64. The test doesn't pass 🙈
So we are back at the original problem: Getting VICE to compile on macOS Cathalina. 🙈🙈
dirkwhoffmann
on 13 Sep 2020
its vice is too old ... 😥
to be honest ... we should get the current vice for mac working .... SceneBrowser did its job but the setup felt always a bit like overkill no?
it is too complicated ... I can't even see Dirks iPhone in the wild debugging setup picture above ...
BTW: it has 85% battery now
mithrendal
on 13 Sep 2020
why the file it is comlaining about has a dot prefix "_MACOSX/._godot.crt"
When compressing files on macOS, that is a way to store additional file attributes. The leading "." for any UNIX based operating system marks it as an "invisible" file. The ZIP file is correct, it's just that this file should be ignored.
sarnau
on 13 Sep 2020
to be honest ... we should get the current vice for mac working ....
Yes, I think you're right. To get a better understanding of their Makefile architecture, I've started to built a 3D model of it...
So where do we start? 😬
dirkwhoffmann
on 13 Sep 2020
I started over with a fresh download of VICE 3.4, and this time it worked. I don't know what I did differently, but the following chain of commands seem to work:
make clean
make x64sc bindist
Maybe I was just missing the make clean 🤔.
IMPORTANT: VICE seems to redirect all standard unix channels (stdout, stderr) to "somewhere" which means that printf output is not visible. I helped myself by opening a file and to use fprintf instead. And here we go: My first debug trace created with VICE 3.4: 😎
> tail /tmp/VICE.log
pagefox_config_init()
BTW, I just found out that I was not the first one to build 3D models of the VICE software architecture. Others did before...
Could be SID or VICII, hard to tell... 🤔
dirkwhoffmann
on 13 Sep 2020
Fascinating. At this point,
the processor port register equals $35 which corresponds to the following memory layout:
Normally, cartridges are fully disabled in this memory configuration. However, according to the documentation in the test program (as well as to what I can see in the VICE trace log), the cartridge is still active. I guess the cartridge sniffes the address bus and writes into its on-board RAM whenever the on-board RAM is enabled (this is done by setting a certain bit combination in the control register).
dirkwhoffmann
on 13 Sep 2020
Another one solved 😎:
As expected, on-board Ram is always written when the control register bits enable it. Processor port values that disable the cartridge don’t affect this behavior.
To emulate this, the cartridge needs to fake the internal pokeTarget tables 🙄. Otherwise, the cartridge code would never be called for certain processor port values. How shall I explain to you how the table modification works technically? 🤔 Well, I think it's best described by this picture:
Now, since VirtualC64 passes the PageFox tests, it would be cool to see if the real PageFox cartridge works. But for doing this, we would need to have that cartridge…
dirkwhoffmann
on 13 Sep 2020
one german c64 magazin calls it "the absolut hammer" ...
https://archive.org/details/64er_1988_03/page/n109/mode/2up
it seems to be a "desktop publishing program" ... sort of professional layouting software ...
https://www.c64-wiki.de/wiki/Pagefox
question of the day : why is those sort of software called "desktop" publishing 🤔... does that mean a laptop e.g. a "mac book" is to weak for it and that you need a real c64 desktop system ?
mithrendal
on 13 Sep 2020
Yes, I have that cartridge – don't remember how I got it. It has four 16kb ROM banks and two 16kb RAM banks. The RAM banks were also used by other software.
sarnau
on 13 Sep 2020
and two 16kb RAM banks.
in total 96 Kb ... 🤤 ... game changer 👍🏻
mithrendal
on 13 Sep 2020
Yes, I have that cartridge – don't remember how I got it.
Would you mind sharing it (without posting it here)?
one german c64 magazin calls it "the absolut hammer" ...
Just read that article. Software from another galaxy if we believe the author 😂. Now, I wonder why I typeset all my books with LaTeX... 🤔
dirkwhoffmann
on 14 Sep 2020
The C64 Wiki https://www.c64-wiki.de/wiki/Pagefox has a link at the bottom of the Pagefox article to Forum64.de, which has the CRT. I hope it is the same.
sarnau
on 14 Sep 2020
The C64 Wiki https://www.c64-wiki.de/wiki/Pagefox
Thanks!
VICE: 👍
VirtualC64 v4.0: 🙈
A Blue Screen on the C64. Awesome 🤤. Another example showing that Commodore was way ahead of their competitors back in the day. Microsoft needed many more years to (re)invent that screen.
dirkwhoffmann
on 14 Sep 2020
Fixed
dirkwhoffmann
on 15 Sep 2020
Related issues
bluecursor
·
7Comments
dirkwhoffmann
·
7Comments
cfwdman
·
6Comments
Alessandro1970
·
6Comments
tsupplis
·
3Comments
Most helpful comment
Another one solved 😎:
As expected, on-board Ram is always written when the control register bits enable it. Processor port values that disable the cartridge don’t affect this behavior.
To emulate this, the cartridge needs to fake the internal pokeTarget tables 🙄. Otherwise, the cartridge code would never be called for certain processor port values. How shall I explain to you how the table modification works technically? 🤔 Well, I think it's best described by this picture:
Now, since VirtualC64 passes the PageFox tests, it would be cool to see if the real PageFox cartridge works. But for doing this, we would need to have that cartridge…