Closed modeler closed 7 months ago
Hm, I didn't find any cartridge images of these games, only D64?
The description of your problems all sound like "fire button of joystick #1" (= space bar), correct? This is something the SID is not connected to. Do these games support a 2nd fire button? This is typically realized via paddles (what the SwinSID cannot do).
Yes it does seem to be related the Port 1 fire button / Space Bar, but I only have one stick connected to Port 2. I'm not sure if these games support a second button, that's a really good point. I'm really not sure if it's likely to be hardware or software that causes this!
There are a few sources for the .CRT files, I won't link directly for obvious reasons but they can be found in the OneLoad64 collection, a link to which is in the description of this video: https://www.youtube.com/watch?v=lz0CJbkplj0
OneLoad64-Games-Collection-v5/Extras/OfficialCRTs/Navy Seals.crt OneLoad64-Games-Collection-v5/Extras/OfficialCRTs/Myth - History in the Making.crt OneLoad64-Games-Collection-v5/Extras/OfficialCRTs/Last Ninja Remix.crt
Zeta Wing 2 is a commercial game, but I will happily gift a copy to you via itch.io if needed. The developer Sarah Jane Avory is very approachable and I would have thought she would help to debug if she can.
These programs read $d419, so the 2nd fire button theory might hold. Which SKpico-firmware version are you using? (I don't remember if the first version had a bug return non-$FF when no mouse is connected). You can also try "PRINT PEEK(54297)" which should print 255 with no mouse. If it doesn't, you chased down the problem.
Firmware is v0.14:
The register does return 255:
I can reach out to Sarah re. the Zeta Wing 2 issue (bomb is actually detonated via the escape key by default, not the Space Bar) as that might help to narrow it down a little. If there's anything else I can do to help debug this, please let me know.
Thanks for your help with this, the device is still really great despite these glitches. Assume you have a suitable device to run EasyFlash binaries and such? I can help with that if not.
Sarah's comment:
"It's not a bug in the game. You see, ZW2 can use a 2nd button to trigger the smart bomb. The problem with SID replacements is that they don't emulate the analogue lines used to read extra buttons. Game thinks 2nd button is down, so fires off the smart bomb."
So it looks like your theory re. the second fire was on the money. I understand why SwinSID has this problem, as it doesn't emulate the analogue pots at all. I'll try the other POTX/Y options to see if it has any effect.
I'll try the other POTX/Y options to see if it has any effect.
Sadly, switching to one of the other options doesn't appear to have any effect.
I've been doing some digging (never looked into how the second fire button was implemented before) and found this:
http://wiki.icomp.de/wiki/DB9-Joystick
The classic C64GS two button joystick ("Cheetah Annihilator") uses the POTX line, which when the button is pressed is connected to VCC. For a third button, the same can be done with the POTY line. These two buttons can then be read from the paddle inputs: When the button is not pressed the POT line is floating, which equals a large resistance to VCC, and will read as $FF. When the button is pressed the POT line is connected to VCC, which equals no resistance to VCC, and will read as $00.
From the PEEK test we ran earlier, it returns $FF so the pot is not registering the second button being down. However, $DC00 has bit 7 on and bit 6 off by default, so BASIC is reading POTX from Port 1. All the games in with the issue get their inputs from Port 2. Could this be significant?
Maybe you can run https://csdb.dk/release/?id=179703 and see what values you get?
I tried the games (not ZW2) and I was not able to reproduce the problems you had.
Maybe you can run https://csdb.dk/release/?id=179703 and see what values you get?
Good shout, I wasn't aware this tool existed. Nice...
https://www.youtube.com/watch?v=Eq1s1blScPk
Note how the POTY inputs are 'noisy' here, no mouse or paddles attached. I understand that POTY can be used as a third button, perhaps the affected games are looking for a < $FF value on both inputs? I tried an original SID in this board as a control test, and it was completely stable at $FF.
I tried the games (not ZW2) and I was not able to reproduce the problems you had.
Thank you, this was a key piece of information. I went and got my other C64 (short board) and installed the SIDKick there, absolutely rock solid. Everything works. So the issue is specific to this particular board, not the SIDKick in general. I am genuinely massively sorry for taking up your time with this, when I should have just tried another C64 right away.
In any case, there is an obscure compatibility issue somewhere, or a fault with my board that only affects the SIDKick, but now it's up to me to pin it down. Which I shall, and I'll be sure to report back. Thanks again for all your help!
Maybe you want to have a look at the 4066 switch, and the capacitors for the potentiometers.
Edit: I'll close the issue for now, but plz report back
Would you believe it, as per #37 this bug is not present in v0.12. Pots are rock solid on the original breadbin I was testing on.
I had a feeling these two issues were connected. :smile:
Hi,
As many others have already said, thank you for this amazing project. The sound is really good (and unlike the Nano SwinSID the transfer game in Paradroid works just fine), but I'm afraid I have observed a few compatibility issues with some games:
Interestingly, all of these bugs are present with the Nano SwinSID, but not the ARMSID. This is how I found these issues, I went looking for them. I have no clue as to what actually causes any of these, sorry.
My set up is as follows:
Breadbin / long board 250425 XCPLA replacement (similar to PLAnkton) Kung Fu Flash cartridge Stock KERNAL ROM No disk drive connected