dirkwhoffmann / virtualc64

VirtualC64 is a cycle-accurate C64 emulator for macOS
https://dirkwhoffmann.github.io/virtualc64
Other
356 stars 33 forks source link

Easy Flash DonkeyKong Junior hangs #465

Closed Alessandro1970 closed 5 years ago

Alessandro1970 commented 5 years ago

Hi, Easy Flash DonkeyKong Junior hangs on VirtualC64 at the main screen.

ViceSC:

schermata 2018-11-14 alle 23 10 41

VirtualC64:

schermata 2018-11-14 alle 23 10 03

GAME: DonkeyKongJR.crt.zip

dirkwhoffmann commented 5 years ago

Alessandro, when I run the CRT in V3.1.1, it looks as follows on my machine:

bildschirmfoto 2018-11-18 um 17 00 55

There is definitely something wrong (the text is broken). Did you also use V3.1.1? If yes, this would be an indication for uninitialized memory or something like that.

It doesn't work with the latest build either, but one can at least make the monkey glow šŸ™„:

bildschirmfoto 2018-11-18 um 17 07 35
Alessandro1970 commented 5 years ago

No, Iā€™m using alpha 3

dirkwhoffmann commented 5 years ago

Thanks. I'm getting the same picture with alpha 3 as above. Strong indication for a memory issue ...

dirkwhoffmann commented 5 years ago

Could you check, if the screen is still scrambled in 3.2 alpha 4?

http://www.dirkwhoffmann.de/virtualc64/VirtualC64_3.2alpha4.zip

Right no, I'm trying to figure out if it's a sprite related issue or a cartridge related issue.

Alessandro1970 commented 5 years ago

Sorry, it doesn't work yet

schermata 2018-11-19 alle 21 31 25
mortinus commented 5 years ago

the same for me on VirtualC64 alpha 4

dirkwhoffmann commented 5 years ago

It's actually good news that the emulator behaves differently on your machine, because this really backs my hypothesis that it's due to some uninitialized memory. Unfortunately, hunting down such issues is like searching a needle in haystac. To get a hint, I have compiled 3.2 alpha 5 as a debug executable. Could you please do the following for me?

  1. Run 3.2 alpha 5, either from the command line or in Xcode.
  2. Run Donkey Kong Jr. until the scrambled screen appears.
  3. Hit Edit->Debug->Dump State->C64->Expansion Port.
  4. Hit Edit->Debug->Dump State->C64->VIC.

Post the debug output here (it appears in the console if you run the app from the command line or in the Xcode window if you run it from there). It should look similar to this (some values might be different):

VIC
---

       Chip model : 4
              PAL : yes
             NTSC : no
       Glue logic : 1
     Gray dot bug : yes
   is656x, is856x : 0 1
     Bank address : C000
    Screen memory : 0C00
 Character memory : 2000
X/Y raster scroll : 0 / 3
    Control reg 1 : 33
    Control reg 2 : D8
     Display mode : Multicolor bitmap mode
            (X,Y) : (472,104)  
               VC : F0
           VCBASE : F0
               RC : 05
             VMLI : 08
          BA line : high
      MainFrameFF : 0
  VerticalFrameFF : 0
     DisplayState : on
    SpriteDisplay : 00 (00)
        SpriteDma : 00 ( 0 0 0 0 0 0 0 0 )
      Y expansion : FF ( 1 1 1 1 1 1 1 1 )
Expansion port
--------------
 Game line (phi1 / phi2):  1 / 1
Exrom line (phi1 / phi2):  1 / 1

Cartridge
---------
        Cartridge type: 32
 Game line in CRT file: 0
Exrom line in CRT file: 1
 Number of Rom packets: 0

EasyFlash
---------

bank = 3
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ...

FlashRom
--------

     state: 0
 baseState: 0
numSectors: 8
sectorSize: 65536

FlashRom
--------

     state: 0
 baseState: 0
numSectors: 8
sectorSize: 65536
Alessandro1970 commented 5 years ago

šŸ–– downloading xcode just now...

Alessandro1970 commented 5 years ago

Only one help: I run VirtualC64 form Terminal (Open ViertualC64.app) than "Hit Edit->Debug->Dump State->C64->Expansion Port" ...but I do not know where the dump files are saved. Where can I find the dump files ? They are not in the desktop

dirkwhoffmann commented 5 years ago

There are no dump files. The info messages are (supposed to be) written to the console window in which VirtualC64.app was launched.

Alessandro1970 commented 5 years ago

Excuse me ...console window = Terminal Window ? This one ?

appleterminal2

I have copied VirtualC64.app on the Desktop, than I have opened the terminal. I have reached the Desktop path (pwd --> Desktop) than I have given this command: Open VirtualC64.app Once launched the emulator I have loaded the Donkey.crt and when appeared the scrambled screen I have done this: Hit Edit->Debug->Dump State->C64->Expansion Port None different was shown in the terminal window

Maybe there is another way for open an app in the Terminal or the console window in not the terminal...

dirkwhoffmann commented 5 years ago

Launch it like this (im my case, the app is in the Downloads folder):

bildschirmfoto 2018-11-21 um 07 42 40
Alessandro1970 commented 5 years ago

Ok, I'll try this evening This is very interesting, thank you

Alessandro1970 commented 5 years ago

VIC

   Chip model : 2
          PAL : yes
         NTSC : no
   Glue logic : 1
 Gray dot bug : yes

is656x, is856x : 1 0 Bank address : C000 Screen memory : 0C00 Character memory : 2000 X/Y raster scroll : 0 / 3 Control reg 1 : 33 Control reg 2 : D8 Display mode : Multicolor bitmap mode (X,Y) : (392,311)
VC : 3E8 VCBASE : 3E8 RC : 07 VMLI : 00 BA line : high MainFrameFF : 1 VerticalFrameFF : 1 DisplayState : off SpriteDisplay : 00 (00) SpriteDma : 00 ( 0 0 0 0 0 0 0 0 ) Y expansion : FF ( 1 1 1 1 1 1 1 1 )

Alessandro1970 commented 5 years ago

Expansion port

Game line (phi1 / phi2): 1 / 1 Exrom line (phi1 / phi2): 1 / 1

Cartridge

    Cartridge type: 32

Game line in CRT file: 1 Exrom line in CRT file: 0 Number of Rom packets: 0

EasyFlash

bank = 3 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FlashRom

 state: 0

baseState: 0 numSectors: 8 sectorSize: 65536 rom: 0x10936c000

FlashRom

 state: 0

baseState: 0 numSectors: 8 sectorSize: 65536 rom: 0x1093ec000

dirkwhoffmann commented 5 years ago

Thanks! To my shame, I contradicted rule 1 of software engineering: Use the same test case as the OP. (OK, I invented the rule number just now, but anyways ...). By comparing the output, I noted that I was simply using a different CRT. Mine only has 12 chip packets while yours has 16. Furthermore, they use a different exrom/game start configuration (this is how I noticed it). When I use your original test case which I should have done upfront, I get the same result. I'll keep you informed ...

dirkwhoffmann commented 5 years ago

OK, here's the thing. This is what the EasyFlash Programmer's guide tells us:

 4.1 Cartridge Boot Process

 [...] EasyFlash cartridges always start in Ultimax mode.

However, your EasyFlash version of Donkey Kong Jr. looks as follows:

bildschirmfoto 2018-11-22 um 10 27 17

Ultimax mode is a synonym for EXROM = 1 and GAME = 0, so this means that some EasyFlash CRT files simply contain wrong initial values for these lines. The custom cartridge implementation uses the values from the CRT file on startup which causes the problem. In alpha6, the default values in EasyFlash cartridges are ignored and the EXROM and GAME lines are always set to 1 and 0, respectively.

http://www.dirkwhoffmann.de/virtualc64/VirtualC64_3.2alpha6.zip

Unfortunately this only solves one part of our problem. There is still the text drawing issue. I verified that the text is drawn with sprites, so this might not be an EasyFlash, but a VICII problem. On the other hand, the D64 version of Donkey Kong Jr. draws the text correctly which hints to an EasyFlash problem. Why is software sometimes so mean to us? šŸ¤”

Alessandro1970 commented 5 years ago

I would like to close this issue. What's the Vic problem ? For me with alpha 6 works...

schermata 2018-11-22 alle 22 55 58
Alessandro1970 commented 5 years ago

...the graphic defects on the main screen ?

schermata 2018-11-22 alle 23 06 46
Alessandro1970 commented 5 years ago

I noticed that in the ViceSC is also shown the flashing writing "PRESS FIRE"

untitled 2

dirkwhoffmann commented 5 years ago

Yes, the graphics defects on the main screen. The game itself seems to work fine.

Alessandro1970 commented 5 years ago

There is another version of this CRT (always EasyFlash type): DonkeyKongJR.zip

...try it, but the game is the same, is it a packet (compress) problem ?

dirkwhoffmann commented 5 years ago

It's not a cartridge problem. It's caused by a falsely triggered sprite-background collision interrupt. Fix is yet to come.

dirkwhoffmann commented 5 years ago

Fixed in 3.2 alpha 7 (šŸ˜Ž):

http://www.dirkwhoffmann.de/virtualc64/VirtualC64_3.2alpha7.zip

Old code:

        // Is it a sprite/sprite collision?
        if ((pixelSource[i] & 0xFF) & ((pixelSource[i] & 0xFF) - 1)) {

            spriteSpriteCollision |= (pixelSource[i] & 0xFF);
            triggerIrq(4);
        }

        // Is it a sprite/background collision?
        if ((pixelSource[i] & 0x100) && spriteBackgroundCollisionEnabled) {

            spriteBackgroundColllision |= (pixelSource[i] & 0xFF);
            triggerIrq(2);
        }

New code:

        // Is it a sprite/sprite collision?
        if ((pixelSource[i] & 0xFF) & ((pixelSource[i] & 0xFF) - 1)) {

            // Trigger an IRQ if this is the first detected collision
            if (!spriteSpriteCollision) {
                triggerIrq(4);
            }
            spriteSpriteCollision |= (pixelSource[i] & 0xFF);
        }

        // Is it a sprite/background collision?
        if ((pixelSource[i] & 0x100) && spriteBackgroundCollisionEnabled) {

            // Trigger an IRQ if this is the first detected collision
            if (!spriteBackgroundColllision) {
                triggerIrq(2);
            }
            spriteBackgroundColllision |= (pixelSource[i] & 0xFF);
        }