Detecting 1CHIP consoles in software (maybe)

http://revenant1.net/1chipdetect.sfc

As a result of developing tests for this thread, I found what might be a reliable way for software to tell whether it's running on a 1CHIP / SNES Jr. or not, by using the SMP test register. (This does not use the regular CPU/PPU revision number registers.)

If you can, please run this on a real SNES and tell me if the result is accurate (especially if you have access to more than one).

I have no idea if it's actually useful to be able to do this, but I'm still curious to whether or not it actually works.

I tested it on my SNES Jr. with my SD2SNES and for some reason it says "Lame emulator detected"
This is also shown with my 1CHIP PAL-SNES. The non-1CHIP versions seem to be detected correctly.

Hmm, interesting. Could you run this test also and see what's shown on the last four lines ($CA and above)?

Jr.:
CA 1063
DA 1169
EA 147c
FA 199e

Alright, thanks. That's a fair bit lower than what I was expecting (maybe a NTSC/PAL difference somehow?) but not too bad.

I updated the test ROM in the original post, hopefully it's more correct this time

Seems to work for the Jr.
But I have some PAL consoles where some non-1CHIP are classified as 1CHIP.

Here are the values for the 1CHIP
1049
114e
145e
1977

and for the non-1CHIP
1041
1146
1453
196A

Weird. I wonder if my idea only works for certain non-1CHIP models, then. I was only able to test it on a SHVC-CPU-01, a SNS-CPU-GPM-02 and a SNES Jr. (all NTSC).

It's totally erratic.

Here are my consoles:
https://www.dropbox.com/s/oy53z3w6ze25ehm/SNES.ods?dl=0

Classified as 1CHIP: ca, ... is >=B000 <= CFFF
UP11797400
UP17276665
UP17608834

Classified as non 1CHIP: ca, ... is >= 1000 <= 19FF
UP12640721

UP12640721 and UP11797400 are nearly the same but have totally different timing.

I'm mildly curious what wait state values are needed for TEST.d4-d7 in order to match the B000-CFFF results.

I doubt it'll reveal anything useful about the behavior, but would be good to know.

Does the result depend on the ratio between the CPU/PPU clock crystal and the (less accurate) audio subsystem oscillator? Because the latter can be off by up to half a percent.

That'd only explain small differences of up to +-0x10. 0x1000 -> 0xB000 cannot be explained by that.

Japanese SFC 1CHIP SM1201****
1CHIP console detected.
CA 106E
DA 1175
EA 148B
FA 19B0

US SNES 1CHIP UN3200*****
1CHIP console detected.
CA 1073
DA 117A
EA 1491
FA 19B8

US SNES MINI 1CHIP UC3011*****
1CHIP console detected.
CA 1067
DA 116E
EA 1483
FA 19A5

US SNES MINI 1CHIP UC3018*****
1CHIP console detected.
CA 1065
DA 116C
EA 1481
FA 19A2

US SNES GPM-02 Serial Unknown
1CHIP console detected. (WRONG)
CA 1069
DA 1171
EA 1485
FA 19A8

I have a few other loose boards - one more 1CHIP and several GPM-02s. I can pull them out of storage if this needs more testing.

You can if you want to, but I think my hunch about it being a 1CHIP issue (or a model-specific issue at all) has basically been debunked already, based on your result with the one GPM-02 and jbo_85's results including different results for two of the same model.

I'd still like to figure out what the actual difference is, but it probably won't be as easy to determine as the model.

Thanks to both of you for testing it out so far.

I just added some additional columns to my sheet:

(1) result of the Burn-In Test
(2) results for the SMP Test register 0A-FA. All of them seem to be crashing on 8A. One is even crashing on 0A, but that one seems to be broken as the Burn-In Test shows a failure on "DMA", "VRAM Low" and "VRAM count".
(3) Position of the long dots, as they seem to differ between consoles. I have seen 321, 325; 323, 327

I couldn't test my 2 US Super Nintendos as I can't seem to find my AC adapter for it.

Edit: I used a slightly hacked bmi test for it to include 8A-BA and for some reason that botched the timing a bit :\
I'll retest with the original test ROM.

> All of them seem to be crashing on 8A.
> I used a slightly hacked bmi test for it to include 8A-BA

Thank you for doing that, I was curious about this. It's really a shame that we can't confirm how many wait states are introduced for internal timing mode 2. Especially in light of the drastically different results between internal timing for mode 3 based on unknown differences.

Just because we confirmed internal and external mode 3 gain 20 wait states on some systems for both, doesn't mean that mode 2 guarantees 10 wait states for both modes. Let alone if the same thing that affects mode 3 on some systems (20->248 wait states) happens there as well (10->124 wait states?)

Would be lovely to get someone on that with a a logic analyzer. Maybe we can find out what's causing the crash, and maybe, how to avoid the crash so we can test it. But, it does seem pretty clear that from an emulation perspective, internal mode 2 == always a real hardware crash. Internal mode 3 == either 20 or 248 wait states.

> Position of the long dots, as they seem to differ between consoles. I have seen 321, 325; 323, 327

I have seen 322,326 as well. And what you get can vary even during execution.

I once had a test ROM where you could adjust how many cycles to run past V=0,Hcycle=0 before latching counters, and it printed the results of the counters onscreen. By simply hammering retest button, I could see the latched value fluctuating on the long dots.

I also had another that just looped, polling Hdot, writing to a 32-bit SRAM array entry for said dot. Ran the test for a very long time. It's clear that consoles have a very strong affinity to a specific long dot pattern, and the system I ran that on was clearly 323,327.