I have no idea.
It is difficult for me to write assembler code and even more difficult to understand code written by someone else.
For information, I tested with the Panasonic FS-A1GT virtual machine.
I made a routine in C that work on any configuration I tested but it is far bigger and slower. ^^
I tested the NYYRIKKI's routine that there is on the Wiki at the time when i created SCRT.COM.
I had made this command to test the routine:
https://up2.1fichier.com/end.pl?xid=I2wE3L2Nl8
I don't remember exactly but i think it worked correctly on my real MSXs and BlueMSX but not on OpenMSX.
I deduced that OpenMSX was buggy because I had already noticed oddities during tests with SCC games from the Konami Game Collections converted into ROMs. (some versions were badly converted so SCC sound doesn't work on real hardware but works on OpenMSX)
I've noticed some quirks too with the slot expander when it's in slot 2. I thought it was because of Nekolauncher but maybe not.
I talked about these two problems somewhere in the forum. In addition, it is difficult to handle slots correctly with OpenMSX. So it's hard to pinpoint the problem. I find it strange that everyone gets along with it. OpenMSX is nevertheless claimed as an emulator close to real hardware. This is not the case for slots. It's worse with Cataplult. With that, we don't even know where the cartridges are inserted.
Not sure about wiki but this is tested
https://github.com/artrag/Uridium-msx1/blob/master/sccdetec.asm
It probably works but i think it's a bad idea to return 255 when the SCC is not found because the SCC can be put in a slot 3-3 on some MSXs.
I guess returning 0 if no SCC is found makes more sense (it’s not impossible to have it in slot 0-0 but even less likely than 3-3). To make it 100% trustworthy it probably needs to return a separate 0/1 value to indicate an SCC was found.
I wonder if the routine should handle multiple SCC? Maybe it could return an array or it could take an input to ask for the nth (e.g. 2nd or even 3rd) SCC.
I guess returning 0 if no SCC is found makes more sense (it’s not impossible to have it in slot 0-0 but even less likely than 3-3). To make it 100% trustworthy it probably needs to return a separate 0/1 value to indicate an SCC was found.
The format is FxxxSSPP so 255 is theoretically more probable than 0 because the Main-ROM is always in slot 0 or 0-0 so this slot cannot be a cartridge slot. (Even if the MSX2 standard was said that the Main-ROM could be in another slot, in fact it never was the case because they realized it served no purpose except to complicate programmers' lives. They finally retracted but this remained ambiguous.)
xxx bits are indefini. So they can be set and so the ID can become theoretically 255. This doesn't really bother with this routine because it is indicated but as sdsnatcher73 says 0 makes more sense.
The search routines only use bit 7 from the values in EXPTBL, so if SCC is in slot 3-3 the return value is 10001111.
I use NYYRIKKI's SCC detection routine, it works fine for me. It can be called mulitple times to detect more than one SCC.
I made a little program to test the different SCC detection algorithms (the one from the MRC wiki, the one from ARTAG and mine in C) in various machine configurations on OpenMSX... and in fact they all work very well.
The only thing a bit "strange" for me is that the one in the MRC wiki seems to detect an SCC in slot 2 before those in the sub-slots of slot 1.
In any case, everything works fine (the problems I had must have come from my program).
The only thing a bit "strange" for me is that the one in the MRC wiki seems to detect an SCC in slot 2 before those in the sub-slots of slot 1.
It is amazing because it's the opposite for me.
Have you tried with the command I gave above?
The NYYRIKKI's one? Not yet.
I already have many algorithms to play with. ^^
By the way, I found my problem with MRC wiki's one... it does not restore the page 2's slot after its research.
The detection algorithm on the wiki still have a issue.
When SCC is in slot 1-0 and program cartridge in slot 1-2, SCC is detected but the page #2's slot is not restored properly.
Unless someone who is familiar with assembler looks into the problem, I'll use my interslot read/write based C function, which works fine (although it's big and slow).
EDIT: To test the problem on OpenMSX, use this command-line -exta slotexpander -ext scc -ext fmpac -cart myprogram.rom
The intended behaviour of those routines is to keep the SCC selected in page #2 (or a 'random' slot if no SCC found).
