Virtualc64: Ultima V EF hangs

[Alessandro1970]

Hi,
This EF Crt hangs on VirtualC64 after pressing any choice at start (Journey... etc):

u5remastered.crt.zip

It works on ViceSC:

[rossimariolee]

This cartridge does not work for me too... !
:crying_cat_face:

[sarnau]

It's an EasyFlash adoption of Ultima V. It seems the bank is not mapped into $8000 correctly and eventually jumps into garbage.

Enabling the CRT logging shows a lot of stuff, this is the end of it:

[656] (264, 51) DFE8 EasyFlash: peekIO2(dfea)
[656] (264, 53) DFEB EasyFlash: peekIO2(dfeb)
[656] (264, 54) DFEB EasyFlash: peekIO2(dfec)
[656] (264, 62) 7A83 EasyFlash: pokeIO2(dfb7,1)
[656] (265, 3) 7A86 EasyFlash: pokeIO2(dff0,9)
[656] (265, 7) 7A89 EasyFlash: pokeIO2(dff1,0)
[656] (265, 13) 7A8E EasyFlash: pokeIO2(dfba,0)
[656] (265, 20) 7ACE EasyFlash: peekIO2(dfe9)
[656] (265, 21) 7ACE EasyFlash: pokeIO2(dfe9,d5)
[656] (265, 22) 7ACE EasyFlash: pokeIO2(dfe9,d6)
[656] (265, 31) 7AED EasyFlash: peekIO2(dfba)
[656] (265, 38) 7A93 EasyFlash: peekIO2(dff4)
[656] (265, 45) 7AA8 EasyFlash: peekIO2(dff4)
[656] (265, 46) 7AA8 EasyFlash: pokeIO2(dff4,1)
[656] (265, 47) 7AA8 EasyFlash: pokeIO2(dff4,0)
[656] (265, 54) 7AF2 EasyFlash: peekIO2(dff1)
[656] (265, 58) 7AF5 EasyFlash: peekIO2(dff0)
[656] (265, 62) 7AF8 EasyFlash: peekIO2(dfb7)
[656] (266, 14) 3C1D EasyFlash: pokeIO1(de02,4)
[656] (268, 27) 398E EasyFlash: peekIO2(df23)
[656] (283, 41) DF86 EasyFlash: peekIO2(df86)
[656] (283, 42) DF86 EasyFlash: peekIO2(df87)
[656] (283, 43) DF86 EasyFlash: peekIO2(df88)
[656] (283, 47) 7A5B EasyFlash: pokeIO2(dff2,12)
[656] (283, 51) 7A5E EasyFlash: pokeIO1(de00,12)
[656] (283, 63) 7C6B EasyFlash: pokeIO1(de02,7)
[656] (289, 57) 2022 C64: RL_CPU_JAMMED

[dirkwhoffmann]

I guess there is something wrong with the chip packet loader. I remember that it wasn't easy to find out which ROM banks are included in the EasyFlash file and which are not (Lemmings is strange in this respect, the numbering has gaps). The current loader reads in consecutive banks up to 40H (H = ROMH range). After that, it skips L banks (ROML range) which might be OK (there might be more banks in the upper memory area). But at the end, it starts loading L banks again. I don't think the cartridge is made that way.

At this point, we need some decent information about the EasyFlash file format...

[284] ( 71, 58) E5CD EasyFlash: Loading Rom bank 36H ...
[284] ( 72,  6) E5CD EasyFlash: Loading Rom bank 37L ...
[284] ( 72, 19) E5CD EasyFlash: Loading Rom bank 37H ...
[284] ( 72, 28) E5D1 EasyFlash: Loading Rom bank 38L ...
[284] ( 72, 34) E5CD EasyFlash: Loading Rom bank 38H ...
[284] ( 72, 45) E5CD EasyFlash: Loading Rom bank 39L ...
[284] ( 72, 55) E5D4 EasyFlash: Loading Rom bank 39H ...
[284] ( 73, 14) E5D1 EasyFlash: Loading Rom bank 40H ...
[284] ( 73, 24) E5CF EasyFlash: Skipping Rom bank 41L ...
[284] ( 73, 31) E5D4 EasyFlash: Loading Rom bank 41H ...
[284] ( 73, 44) E5D4 EasyFlash: Skipping Rom bank 42L ...
[284] ( 73, 50) E5CF EasyFlash: Loading Rom bank 42H ...
[284] ( 73, 60) E5CD EasyFlash: Skipping Rom bank 43L ...
[284] ( 81, 58) E5CF EasyFlash: Loading Rom bank 43H ...
[284] ( 82, 18) E5CD EasyFlash: Skipping Rom bank 44L ...
[284] ( 82, 26) E5D1 EasyFlash: Loading Rom bank 44H ...
[284] ( 82, 38) E5D1 EasyFlash: Skipping Rom bank 45L ...
[284] ( 82, 45) E5CD EasyFlash: Loading Rom bank 45H ...
[284] ( 82, 55) E5D4 EasyFlash: Loading Rom bank 46L ...
[284] ( 83,  4) E5D4 EasyFlash: Skipping Rom bank 46H ...
[284] ( 83, 14) E5D1 EasyFlash: Loading Rom bank 47L ...

[sarnau]

It seems this is the programmers side: http://skoe.de/easyflash/files/devdocs/EasyFlash-ProgRef.pdf
and this is e.g. Easy File System (EasyFS), Supported cartridge types and EasyFlash xbank Cartridges: http://skoe.de/easyflash/files/devdocs/EasyFlash-AppSupport.pdf

A lot of stuff, not sure if this helps or if this is "old news"

[dirkwhoffmann]

I've compared the debug traces of Scene Browser 1.3.2 with Virtual64. At the beginning a whole lot is going right. The trouble begins when the cartridge switches to bank 18:

Scene Browser 1.3.2: 👍

...
pokeIO1(2,4)
MXG = 4
peekIO2(23): 0
peekIO2(86): 4c
peekIO2(87): 5b
peekIO2(88): 7a
pokeIO2(f2,12)
pokeIO1(0,12)
Switching to bank 18
pokeIO1(2,7)
MXG = 7
peekL(8000) = a9
peekL(8001) = 0
peekL(8002) = 8d
peekL(8003) = cd
peekL(8004) = 3
peekL(8005) = 8d
...

VirtualC64: 🙈

...
MXG = 4
peekIO2(23): 0
peekIO2(86): 4c
peekIO2(87): 5b
peekIO2(88): 7a
pokeIO2(f2,12)
pokeIO1(0,12)
Switching to bank 18
pokeIO1(2,7)
MXG = 7
[312] (101, 26) 8000 EasyFlash: peekL(8000) = 5
[312] (101, 27) 8000 EasyFlash: peekL(8001) = 5
[312] (101, 29) 8002 EasyFlash: peekL(8002) = 5
[312] (101, 30) 8002 EasyFlash: peekL(8003) = 5
[312] (101, 32) 8004 EasyFlash: peekL(8004) = 5
[312] (101, 33) 8004 EasyFlash: peekL(8005) = 5
[312] (101, 35) 8006 EasyFlash: peekL(8006) = 5
[312] (101, 36) 8006 EasyFlash: peekL(8007) = 5
[312] (101, 38) 8008 EasyFlash: peekL(8008) = 5
[312] (101, 39) 8008 EasyFlash: peekL(8009) = 4c
[312] (101, 41) 800A EasyFlash: peekL(800a) = 5

[dirkwhoffmann]

As I expected, the EasyFlash reader is the culprit. What is supposed to be put into bank 18 is put into bank 17 by the EasyFlash reader in VirtualC64.

 [485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 15H ...
e6 f3 d9 ce 68 4f f2 e1 4d ad c1 69 db de e9 ec f5 df c6 65 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 16L ...
23 aa 00 6f a3 15 63 b4 f1 f3 f2 ef c8 75 0c fd 85 02 69 18 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 16H ...
0e a8 1c 4f de 00 02 24 20 2a ff ac 90 43 e8 92 ca fd 7b 90 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 17L ...
a9 00 8d cd 03 8d cc 03 a9 03 8d d9 7c a2 00 bd bb 7d 0a 9d 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 17H ...
02 0f 28 54 4c 50 4a 42 07 44 36 02 4c 32 02 0f 44 2c 30 34 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 18L ...
05 05 05 05 05 05 05 05 05 4c 05 05 05 05 05 05 05 05 05 05 
[485] (  0,  1) E5D1 EasyFlash: Loading Rom bank 18H ...
05 05 05 05 05 05 05 05 05 4c 05 05 05 05 05 05 05 05 05 05 

Maybe there is no page 17 and the CRT files contains something like a bank map at the beginning of the .crt file. Unfortunately, I didn't find any decent information about the EasyFlash .crt format (EasyFlash itself is well documented, but not the format of .crt files containing EasyFlage images).

[dirkwhoffmann]

Maybe there is no page 17 and the CRT files contains something like a bank map at the beginning of the .crt file

True. The bank number is coded inside the header. There is no bank 17 in this cartridge:

Log from Scene Browser:

...
Chip header size: 2000 skip: 0 type: 2 bank: f start: 8000
Chip header size: 2000 skip: 0 type: 2 bank: f start: a000
Chip header size: 2000 skip: 0 type: 2 bank: 10 start: 8000
Chip header size: 2000 skip: 0 type: 2 bank: 10 start: a000
Chip header size: 2000 skip: 0 type: 2 bank: 12 start: 8000
Chip header size: 2000 skip: 0 type: 2 bank: 12 start: a000
...

Fun fact: Just found this in the old code:

   // Returns the bank information (what is this exactly?)
    u16 chipBank(unsigned nr) { return LO_HI(chips[nr][0xB], chips[nr][0xA]); }

Now, we know what "bank information" is. It's the bank number.

[mithrendal]

Cool 🤤

[dirkwhoffmann]

😎

Fixing this was great team work! Thanks!

[sarnau]

…and the code is now even simpler. Congrats!

[dirkwhoffmann]

…and the code is now even simpler.

You are right. The old code utilized a static variable which is the opposite of brilliant coding style. 🙄