Recognition by Ultimate64 and C64 Ultimate

[Kaninbjerget]

Hi

An improvement suggestion which I hope you'll look into. I currently have an Ultimate64 Elite-II but it's same thing on the new C64 Ultimate as it's 99,9% identical.
As many agree the build in UltiSIDs are not that accurate so many opt for other options. Here the SideKick Pico comes into play as it's one of the currently best. Unfortunately it's not recognized by the Ultimate64 - it just says "None" in the socket.
Both ARMSID/ARM2SID and FPGASID are recognized, "ARMSID" in the socket etc., and able to be configured by the Ultimate64. That is crucial because while you can get it to play using manuel configuration then you have to configure adresses etc. manually when you want to utilize stereo content.

To my knowledge there should be a sort of API which both ARMSID and FPGASID utilizes and it should be open so I guess it should be able to implement for SidKick Pico too.

If at least it could be cognized as a chip in the socket. For start even if it just is set to whatever mode set in user interface (6581 respectively 8580) then it can be utilized by the auto configuration in the Ultimate64 as if it was a real SID which also is just what it is. But of course if able to be configured automatically by the Ultimate64 that would be icing on the cake (it seems to me ARMSID just saves it in ram as not to constantly wear flash whenever user changes tunes)
As it is now if you try to use autoconfiguration then depending on your settings you'll either get UltiSID to play which remains until power cycle if I remember correctly or you again fiddle with settings or no sound at all.

As it is now users which also listens to a lot of tunes and are not satishfied with the UltiSID at the moment really only have two options. Vintage SIDs or ARM(2)SID (it's unsure if FPGASID will be made again, last stock has been sold)

Hope it is something that you'll consider looking into. I'm sure they'll sell like hot cakes if this got implemented!

Thanks!

[frntc]

Hey,

unfortunately there's no API/procedure which a SID-clone could follow to be recognized. That's something that the U64/C64U firmware needs to implement. But maybe Gideon is willing to do that if he gets requests? ;-)

[Kaninbjerget]

Thank you for fast reply.
I must admit I probably took what I read in the Ultimate64 forum on FB for granted (by an admin though) a little too fast.
But it does seem there's solution for ARMSID, FPGASID and SwinSid Ultimate which are recognized.

Take a look at the files sid_device_XYZ:
https://github.com/GideonZ/1541ultimate/tree/a488e218cff354c92b5abc55d9b2b4167028353c/software/u64

I think the most ideal would be if everyone agreed on a simple "standard" interface. Or perhaps it could just "impersonate" SwinSid Ultimate. It seems the most simple contract.

[frntc]

Well, all three replacements are closed source and stable state (the FPGASID and ARMSID configuration is documented though), but even if there would be attemps to agree on a standard interface, then the configuration options are still vastly different, e.g. regarding the filters. Also the functionality differs (built-in config tool, file launcher, FM), so it would not make much sense if a SKpico would pretend being a FPGASID!? (or a SwinSID Ultimate with almost no configuration options)

[marty41]

All the currently supported SID replacements have been implemented individually by Gideon. So if anyone is able to add the SIDkick (and the ability to start the internal configuration tool), it's Gideon. Please feel free to request this feature directly by Gideon.

[Kaninbjerget]

Perhaps the time is to consider a common simple interface. Sure you then can't configure FM etc. but I believe 99.9% of users will be happy with it working with the auto configure to be abnle to switch it between 6581 respectively 8580 and if anything more complex is needed then use whatever config tool that SID replacement requires.

[marty41]

As @frntc already mentioned, most of the replacements are closed source, so you would need to get all different developers (and also Gideon) on one table to embed an common api to edit the replacements configuration. Personally, I don't believe that will happen.
Also, the mentioned replacements are just a few of their kind, there are many others (only to mention: KungFuSID, PDSID, ThePicoSID ... ) and they are getting more and more. Everyone would have to adhere to the interface to be defined and adapt their firmware accordingly, which I think is quite unlikely. Just to switch a SID between 6581 and 8580.

[Marc91360]

Hello,
There is something I do not understand : in this comment : "Commodore 64 Ultimate Config Questions **#148" the user "Marty41" said "You of course can have both SIDkicks installed in your C64U ..."

So is Sidkick compatible, or not, with the C64 Ultimate / Ultimate 64 ?

Marc

[frntc]

of course it is compatible, everything works except for the autodetection which needs to be implemented in the C64U/U64-firmware. I'll prepare a SKpico-firmware soon which will also include a special addressing mode for the C64U/U64.

[Kaninbjerget]

As long as you don't use the autoconfigure it's fine. However using the autoconfigure everything messes up and you need to either power cycle or mess with config to get it back on track. Not ideal.

[marty41]

"Autoconfig" is a completely different piece of cake, it is only used for the internal U64 SID player.
It has nothing to do with the autodetection of the installed SIDs in the sockets.

[Kaninbjerget]

Well yes but also no. When it doesn't detect any SID or replacement in a socket then everything goes haywire and either you end up with it switching to UltiSID (which is not that great) or no sound at all. If it detects either one of the supported SID replacements or a real SID then it works without issues and utilizing that.

[marty41]

Indeed, if the replacement is not recognised, how should it be switched to. There is nothing going haywire, it is just not being used.
As already multiple times written, the U64(-II) firmware is responsible for recognising any replacement! Each has to be implemented individually by Gideon! The same will happen with any other newer replacement!
My suggestion would be to simply remove the “Autoconfig” option and always let the user manually set what needs to be used. This would also encourage users to think a little more about what they are doing and why it works, or why it doesn't.