Closed Alessandro1970 closed 5 years ago
Alessandro, when I run the CRT in V3.1.1, it looks as follows on my machine:
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 š:
No, Iām using alpha 3
Thanks. I'm getting the same picture with alpha 3 as above. Strong indication for a memory issue ...
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.
Sorry, it doesn't work yet
the same for me on VirtualC64 alpha 4
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?
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
š downloading xcode just now...
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
There are no dump files. The info messages are (supposed to be) written to the console window in which VirtualC64.app was launched.
Excuse me ...console window = Terminal Window ? This one ?
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...
Launch it like this (im my case, the app is in the Downloads folder):
Ok, I'll try this evening This is very interesting, thank you
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 )
Game line (phi1 / phi2): 1 / 1 Exrom line (phi1 / phi2): 1 / 1
Cartridge type: 32
Game line in CRT file: 1 Exrom line in CRT file: 0 Number of Rom packets: 0
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
state: 0
baseState: 0 numSectors: 8 sectorSize: 65536 rom: 0x10936c000
state: 0
baseState: 0 numSectors: 8 sectorSize: 65536 rom: 0x1093ec000
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 ...
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:
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? š¤
I would like to close this issue. What's the Vic problem ? For me with alpha 6 works...
...the graphic defects on the main screen ?
I noticed that in the ViceSC is also shown the flashing writing "PRESS FIRE"
Yes, the graphics defects on the main screen. The game itself seems to work fine.
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 ?
It's not a cartridge problem. It's caused by a falsely triggered sprite-background collision interrupt. Fix is yet to come.
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);
}
Hi, Easy Flash DonkeyKong Junior hangs on VirtualC64 at the main screen.
ViceSC:
VirtualC64:
GAME: DonkeyKongJR.crt.zip