Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
Don't Panic. Please wash hands.
-
But, would lag on USB vs. PS/2 for keyboard and mouse usage causes gameplay lag which uses the joystickports anyway ? Maybe I misunderstood 
Not directly no. However once there is a USB connecter, users will not able to limit themselves to just keyboards. They want to connect trackballs, game-pads, usb joysticks or as discussed hybrid devices like keyboard and mouse combined. Not even considering USB-hubs, mass storage devices, CDroms, diskdrives and random webcams. Yes USB can get complex quite quickly. The FPGA can't do all those extra tasks, so an additional micro is necessary. To support a good subset of devices without getting lag, when it is in a separate micro is an interesting issue.
In comparison PS/2 is a lot simpler. Four wires into the FPGA and a few small hdl entities. Done. No lag, no drivers, no complex software stack. And also important: fully design compatible with first edition of Chameleon (which we will still want to support with updates in parallel with v2).
-
There is a very important reason why mk2 has full auto-detection (compared with the manual jumper style on the mk1). The 65xx and 85xx chips require a different supply voltage. Allowing quick access to an override in the menu could cause damage to the retro chips very easily by selecting the wrong option. Or user swaps a chip a few months later forgot that the override has been set and another non-replaceable retro chip bites the dust. So no override.
Although the green LED on the board will be flashing it is only a warning, the SID replacements you listed should still work. It will be treated as a 8580 (as this has the lowest voltage requirement of the two).
-
False warning by windows defender.
-
The video mode of the workbench shouldn't matter for ECSv2 detection.
My educated guess is the Vampire 500 blocks access to the required configuration registers.
Did a bit of searching and found this wiki page:
http://wiki.apollo-accelerator…u.php/compatible_hardware
| iComp |
Indivision ECS |
Yes |
Configuration tools not working; Graffiti mode not working |
I do not own a Vampire and know little about the inner workings. So I'm not sure if the Vampire can be switched to some more compatible or transparent mode. It should allow writes to $DFF1F2 and $DFF1F8 and reads from $DFF1F4. If the Vampire blocks or remaps one or more of these three (reserved) chip registers it causes the problem you describe.
-
Yes the docking station is compatible with both versions of the Turbo Chameleon.
-
What does the menu item "Chipset Info" (I) reports when the unrecognized SID is installed? That makes the "why" a little easier to guess. And it will work as 8580 SID is the fallback mode (as it requires the lowest supply voltage).
SwinSID is not recognized, because the detection depends on very specific electrical behavior of the various SID chips. I expect the SwinSID to still work though, as it should not care about the supply voltage it gets.
