Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > How do I reliably detect 6581/8580 sid?
2006-08-22 14:18
tlr

Registered: Sep 2003
Posts: 1224
How do I reliably detect 6581/8580 sid?

There was an article in C=Hacking, but that does not work very well in VICE for example.
Maybe VICE's emulation is borked though.

I remember seeing a detailed analysis of the waveforms somewhere, but I can't seem to find it now.
2006-08-22 14:28
Jetboy
Account closed

Registered: Jul 2006
Posts: 179
AFAIK you cannot test it _reliably_.
That's why many demos ask about it before they start.
2006-08-22 14:32
Zyron

Registered: Jan 2002
Posts: 2077
Mathematica has a SID tester that works in VICE too.
2006-08-22 14:54
tlr

Registered: Sep 2003
Posts: 1224
The principle that seems most workable is sampling the waveform of voice 3 (using $d41b) and interpreting it in some way. The test in C=Hacking checks the differences of the combined triangle + sawtooth waveforms. (http://www.ffd2.com/fridge/chacking/c=hacking20.txt)
It uses a very simplistic max-value approach which does not work in VICE.

Assuming there are differences in waveform, it should be possible to detect reliably because this is done in an all digital domain. The timing of triggering the voices/reading $d41b might be very tricky though.
2006-08-22 15:00
Frantic

Registered: Mar 2003
Posts: 1373
It's possible.

The solution in mathematica is the standard one I think (waveform 5 on onscillator 3.. and check osc3 output for values above $80. However.. I've done some testing and noticed that values over $80 can show up on 6581 machines too, but they do so very seldom, so if you just read some more values than ppl normally do and use a threshold value instead of expecting zero occurances you are totally safe. (You are 99.9% safe anyway, since I actually think you need to initialize SID with random values before setting this wav$05-stuff to get any values above $80 at all on a 6581 machine.)

One interesting side issue that I have discovered (by some help of Twoflower who did the actual slavework of running a testprogram on some of his machines ;) is that waveform $05 is not exactly identical on all 8580 machines when read from oscillator 3, which is a bit weird. It seems to depend on factors external to the SID itself, or something like that. In our tests it was actually 1:1 correlated to the serial numbers of the motherboards, eh... ...but that's probably a coincidence... or not..

Anyway.. I did this testing stuff without using a REU for reading osc3, which is of course how it should be done, so proper testing remains to be done to clarify the behaviour of waveform 5 on the different chips..
2006-08-22 15:01
Groepaz
Account closed

Registered: Dec 2001
Posts: 9100
you just play one of the combined waveforms that the 6581 can not produce and sample the output from osc3....that should be pretty reliable.

the timing test can be used for something else - detection of emulator :)
2006-08-22 15:20
tlr

Registered: Sep 2003
Posts: 1224
C=Hacking 20:
start    sei
         lda #11
         sta $d011
         lda #$20
         sta $d40e
         sta $d40f
         lda #%00110001
         sta $d412
         ldx #0
         stx high
loop     lda $d41b
         cmp high
         bcc ahead
         sta high
ahead    dex
         bne loop
         lda #%00110000
         sta $d412
         cli
         lda #27
         sta $d011
         lda high
         bmi SID8580
         bpl SID6581

Mathematica (interrupts disabled, but no blanked screen):
B11F   A2 18      LDX #$18
B121   A9 00      LDA #$00
B123   9D 18 D4   STA $D418,X
B126   CA         DEX
B127   10 FA      BPL $B123
B129   A9 02      LDA #$02
B12B   8D 0F D4   STA $D40F
B12E   A9 30      LDA #$30
B130   8D 12 D4   STA $D412
B133   A0 00      LDY #$00
B135   A2 00      LDX #$00
B137   AD 1B D4   LDA $D41B
B13A   30 08      BMI $B144
B13C   CA         DEX
B13D   D0 F8      BNE $B137
B13F   88         DEY
B140   D0 F5      BNE $B137
B142   F0 02      BEQ $B146
B144   A2 01      LDX #$01
B146   86 0B      STX $0B
B148   A9 00      LDA #$00
B14A   8D 0F D4   STA $D40F
B14D   8D 12 D4   STA $D412


The same basic principle.
The mathematica code never sets the Gate. The gate is unnecessary as $d41b reads the oscillator directly.
It also uses a lower frequency and a longer detection time.

Thanks for the suggestions! I'll try it out.
2006-08-22 15:39
Twoflower

Registered: Jan 2002
Posts: 424
Concerning my slave-testing of 8580's - it's clear that the waveform $05 differs from 8580 to 8580. It's also pretty clear that different SID's made at different production-runs at different factories produce slightly different results. The interesting part is that you probably can spot the factory and the time of making just by checking the combined waveform. One or two similar values, ok, that might be a coincidence. But here we have pretty much an 1:1 correlation?
2006-08-22 16:22
tlr

Registered: Sep 2003
Posts: 1224
Quote: Concerning my slave-testing of 8580's - it's clear that the waveform $05 differs from 8580 to 8580. It's also pretty clear that different SID's made at different production-runs at different factories produce slightly different results. The interesting part is that you probably can spot the factory and the time of making just by checking the combined waveform. One or two similar values, ok, that might be a coincidence. But here we have pretty much an 1:1 correlation?

@Twoflower: Do you mean $05 as in sync+ringmod+gate?
2006-08-22 19:14
McMeatLoaf

Registered: Jan 2005
Posts: 87
$05 as in ringmod+gate, I think.
2006-08-22 20:38
tlr

Registered: Sep 2003
Posts: 1224
Quote: $05 as in ringmod+gate, I think.

Doh! I knew that...

But what happens when you just set ringmod + gate with no selected waveform?
If you are unlucky you'll feed the ringmod xor-gate with High-Z which could result in process/temperature dependent behaviour (which is what seems to happen).
Also ringmod on voice 3 will surely depend on what voice 2 is setup to.

@Twoflower: could you please give some more details on your tests?
2006-08-22 21:10
Hein

Registered: Apr 2004
Posts: 840
I think combining 2 methods, real SID, and reSID check should work fine. Haven't tried the real sid method though (courtesy of Soundemon and Dag Lem), could be that Soundemon found the wrong code from the top of his head:

real sid (1 cycle delay):

lda #$ff
sta $d412
sta $d40e
sta $d40f
lda #$20
sta $d412
lda $d41b <- different value for 6581 & 8580 because of 1 cycle delay in one of the two sids. I dunno the different values, though.

This method doesnt work in VICE, since Dag Lem didnt implement the cycle delay in reSID.

in case of VICE you can use the mixed waveform $71 (not reliable for real sid)

lda #$ff ;frequency ch3 up
sta $d40e
sta $d40f
lda #$00 ;pulsewidth ch3 down
sta $d410
sta $d411
lda #$71
sta $d412

read $d41b 128 times, INX whenever $d41b doesnt hit a zero. Both sids should output a different value. (in my test, X<$7c, sid=8580)
2006-08-22 21:43
tlr

Registered: Sep 2003
Posts: 1224
Hein, those sound quite interesting, especially the cycle delay method.
2006-08-23 07:54
Frantic

Registered: Mar 2003
Posts: 1373
@tlr: About the tests me and twoflower did.. We're not talking about $05, but of $50.... that is.. simply the combined waveforms.. Pulse+Tri. Nothing new, apart from the fact mentioned that 8580 machines seem to differ (and that 6581s aren't 100% reliable under all possible prior register settings, but that doesn't really matter, as I already said).

I don't really understand the 8580 chip difference though. I mean.. I thought the oscillator reading stuff was done on values strictly internal to the SID, but either the 8580 chips are different or the surroundings of the chip really have an influence on what is read from osc3 output... Too bad I'm not very good at electronics to have an educated standpoint in that matter..
2006-08-23 08:26
tlr

Registered: Sep 2003
Posts: 1224
@frantic: I think the unreliable values have to do with that the combined waveforms are unintended features, much like the undocumented opcodes of the 6510, many of which are unstable.

In the original NMOS 6581 they are wire and:s (or:s) of the selected waveforms. I assume they are just open-drain outputs driving the DAC.

In the 8580 which I believe is CMOS (correct me if I'm wrong) I would have expected it to be stable. But it could have been done in the same (open-drain) way with CMOS transistors.

If the above is the source of the behaviour, the unstability comes from inputs to the DAC/$d41b having voltages not clearly defined as '1' or '0'. Note here that there is no guarantee that the DAC sees the same bit-state as $d41b if this is the case.
(i.e $d41b could be unreliable even though the DAC output is stable and vice versa.)

The threshold voltages for the NMOS and CMOS processes are definately different, and will vary with temperature and batch. Different processes will vary to different degrees.


SID patent:
http://stud1.tuwien.ac.at/~e9426444/patent.html

Interview with Yannes about the SID (concerns only the 6581):
http://stud1.tuwien.ac.at/~e9426444/yannes.html


2006-08-23 08:28
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
From what I have heard so far, the combined waveforms are a result of "short circuiting" the digital waveform outputs, and thus can produce different results among different SID chips. This is also an explanation why they sound different on an 8580, since the 8580 was done in a new process (HMOS-II), creating a different pattern than the NMOS process.
2006-08-23 08:43
Frantic

Registered: Mar 2003
Posts: 1373
If someone feels like it, then please go ahead and code a simple tool similar to the one used for waveform investigations on the 6581 SID homepage, that cylces through different waveform settings one at a time, captures it with REU, and saves the results on disk. Then I could bring this program and my 512kb REU to some party sometime and run it on a lot of machines to collect some data for closer analysis, together with some notes on what kind of SID were in the machine.

Have been thinking of coding it myself, since it's obviously very simple, but I realized that I don't care enough about this issue to do it. (Since it doesn't really matter a whole lot for (ordinary) music making anyway..)

If temperature has something to do with it, perhaps a testing program should also run for a while on a certain machine and thus comparing the output of the waveform with itself from 10 minutes earlier or so?
2006-08-23 09:05
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
It would be, in general, interesting to make a new attempt in characterizing the combined waveforms. Is the waveform created by them truly periodic? And if so, what formula can be applied to get the same results as the real chips? If not, what other factors can influence the variation of the result?

Unfortunately, I think this can only really be explored by sampling VERY huge chunks of the waveforms.

My bet is that every time you will sample it, you get different results, which sound kind of same to the human ear, but vary a lot in the digital domain. The changes in the waveform could be as small as one SID cycle, thus hardly noticeable by the human ear.
2006-08-23 09:24
tlr

Registered: Sep 2003
Posts: 1224
@Necronomfive: Do you have any detailed info about the HMOS-II process? Is it a CMOS variant?
The statement about greatly reduced power consumption suggests it...
2006-08-23 09:54
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: @Necronomfive: Do you have any detailed info about the HMOS-II process? Is it a CMOS variant?
The statement about greatly reduced power consumption suggests it...


It´s actually funny, because HMOS stands for high-speed NMOS, which trades higher speed for higher power consumption. I think the statement about greatly reduced power consumptions refers to the reworked amplifier/filter circuits, which need 9V in the 8580/6582 contrary to the 12V in the 6581.

Most probably know it, but you can have an interesting look on the SID dies here at this site: http://sid.kubarth.com/
2006-08-23 10:04
tlr

Registered: Sep 2003
Posts: 1224
Quote: It´s actually funny, because HMOS stands for high-speed NMOS, which trades higher speed for higher power consumption. I think the statement about greatly reduced power consumptions refers to the reworked amplifier/filter circuits, which need 9V in the 8580/6582 contrary to the 12V in the 6581.

Most probably know it, but you can have an interesting look on the SID dies here at this site: http://sid.kubarth.com/


High-speed according to Wikipedia, yes. It can also stand for High-density CMOS. Also HMOS-II is obviously an improvement over HMOS.
I agree about the 9V/12V though.

Great link! I hadn't seen that sid-page actually.
Thanks!

2006-08-23 10:15
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: High-speed according to Wikipedia, yes. It can also stand for High-density CMOS. Also HMOS-II is obviously an improvement over HMOS.
I agree about the 9V/12V though.

Great link! I hadn't seen that sid-page actually.
Thanks!



However, MOS/CSG NEVER produced any CMOS VLSI´s, since Commodore did not care to invest any money to modernize the chip plants. The C64 was selling like hot cakes, so why bother?

They renamed HMOS to HMOS-II, because the only chips produced at their plants in HMOS (73xx series) ran unreliable and died easily. The first batches of C16/C116/Plus/4 Chips were done in that process. They improved that process and called it HMOS-II (83xx, 85xx series)

This is the reason, why the 8361 Agnus in the Amiga 1000 had only 48 pins and needed LOTS of TTL/GAL supply logic on the mainboard, because they WERE NOT ABLE(!) to bond PLCC84 packages at this time, because they were still using the old equipment from the seventies for chip fabrication. After 1987, they never produced anything above PLCC84. The only CMOS Chips in the AGA Chipset were done by other companies (VLSI, HP), since CSG could not handle it.

Glad you like the page. :)
2006-08-23 13:25
Raf

Registered: Nov 2003
Posts: 333
by the way how about 6582? can it also be recognized this way? and what's actual difference among 6581 and 8580? I've heard 6582 is NMOS 8580 made after 1991 to replace old 6581 , but this seems to be fake as I've found a photo of 6582 from 1986... never seen or heard 6582 live though...
2006-08-23 13:32
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: by the way how about 6582? can it also be recognized this way? and what's actual difference among 6581 and 8580? I've heard 6582 is NMOS 8580 made after 1991 to replace old 6581 , but this seems to be fake as I've found a photo of 6582 from 1986... never seen or heard 6582 live though...

There is no audible difference between 6582 and 8580. Both Chips share the same design, have the same filter characteristics, the same sample "fix", and seem to have come out around the same time (1986). Why they actually labelled the same design under 2 different names is really beyond me, since labelling it 6582 bears the danger to confuse it with the 6581 and put it into the same socket....
2006-08-23 13:48
Steppe

Registered: Jan 2002
Posts: 1489
So the rumour that 6582 is essentially an 8580 with digi-capabilities is wrong?
2006-08-23 16:21
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: So the rumour that 6582 is essentially an 8580 with digi-capabilities is wrong?

Yes. When Jens (Schönfeld) got a batch of 6582 chips, the tests turned out really disappointing. The 6582 is just an ultrare package variant of the 8580.
2006-08-23 18:00
Hoogo

Registered: Jun 2002
Posts: 87
I remember a very different way how to distinguish betwenn old and new sid. The sid does not support reading from his normal registers, but still you can read a written value for a while. That time is different for old and new sid.
2006-08-23 19:16
tlr

Registered: Sep 2003
Posts: 1224
@Hoogo: I remember that too.
It surely won't work in VICE though.
2006-08-23 19:39
Hein

Registered: Apr 2004
Posts: 840
Quote: @tlr: About the tests me and twoflower did.. We're not talking about $05, but of $50.... that is.. simply the combined waveforms.. Pulse+Tri. Nothing new, apart from the fact mentioned that 8580 machines seem to differ (and that 6581s aren't 100% reliable under all possible prior register settings, but that doesn't really matter, as I already said).

I don't really understand the 8580 chip difference though. I mean.. I thought the oscillator reading stuff was done on values strictly internal to the SID, but either the 8580 chips are different or the surroundings of the chip really have an influence on what is read from osc3 output... Too bad I'm not very good at electronics to have an educated standpoint in that matter..


Writing a cycle later can make a difference... Don't know if that's the case, but I can imagine that testing on a real c-64 requires cycle precise testing.
2006-08-23 20:43
Raf

Registered: Nov 2003
Posts: 333
Quote:

There is no audible difference between 6582 and 8580. Both Chips share the same design, have the same filter characteristics, the same sample "fix", and seem to have come out around the same time (1986). Why they actually labelled the same design under 2 different names is really beyond me, since labelling it 6582 bears the danger to confuse it with the 6581 and put it into the same socket....


but then I have 6582 datasheet and monolytic capacitors on pins 1-2 and 3-4 are other than for 6581 and 8580 , thus it should make differnece on filter... any ideas?
2006-08-23 21:23
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: Quote:

There is no audible difference between 6582 and 8580. Both Chips share the same design, have the same filter characteristics, the same sample "fix", and seem to have come out around the same time (1986). Why they actually labelled the same design under 2 different names is really beyond me, since labelling it 6582 bears the danger to confuse it with the 6581 and put it into the same socket....


but then I have 6582 datasheet and monolytic capacitors on pins 1-2 and 3-4 are other than for 6581 and 8580 , thus it should make differnece on filter... any ideas?


It has always been a BIG difference what Commodore wrote in their Datasheets, and what was actually done in the real machines. ;) Like claiming that combining waveforms will result in a logical ANDing, which is absolutely not true.

Of course, it makes a difference if you apply different filter capacitors to the 6582 as it would make a difference if you would apply them to the 8580. What counts is how it sounds under the same conditions, and both 6582 and 8580 sound identical.
2006-08-23 21:24
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: Quote:

There is no audible difference between 6582 and 8580. Both Chips share the same design, have the same filter characteristics, the same sample "fix", and seem to have come out around the same time (1986). Why they actually labelled the same design under 2 different names is really beyond me, since labelling it 6582 bears the danger to confuse it with the 6581 and put it into the same socket....


but then I have 6582 datasheet and monolytic capacitors on pins 1-2 and 3-4 are other than for 6581 and 8580 , thus it should make differnece on filter... any ideas?


doublepost
2006-08-24 06:21
JackAsser

Registered: Jun 2002
Posts: 1522
Quote: It has always been a BIG difference what Commodore wrote in their Datasheets, and what was actually done in the real machines. ;) Like claiming that combining waveforms will result in a logical ANDing, which is absolutely not true.

Of course, it makes a difference if you apply different filter capacitors to the 6582 as it would make a difference if you would apply them to the 8580. What counts is how it sounds under the same conditions, and both 6582 and 8580 sound identical.


How are the waveforms combined then?
2006-08-24 07:00
Raf

Registered: Nov 2003
Posts: 333
besides this all (sorry for OT) I exchanged 6581 with 8580 and they actually worked w/o any troubles (filter was messes ofcourse) , analogue part's voltage isn't that critical anyway , I guess it would work properly in range 8-15v for both chips (at expense of diffferent heating conditions probably) just like in many amplifiers (yeah.. filter is also amplifier... but selective only - for those who haven't heard about them in electronical contex)
2006-08-24 10:48
Necronomfive
Account closed

Registered: Dec 2004
Posts: 20
Quote: How are the waveforms combined then?

We don´t know yet. It´s quite confusing, especially if you quote Bob Yannes:

"Since all of the waveforms were just digital bits, the Waveform Selector consisted of multiplexers that selected which waveform bits would be sent to the Waveform D/A. The multiplexers were single transistors and did not provide a "lock-out", allowing combinations of the waveforms to be selected. The combination was actually a logical ANDing of the bits of each waveform, which produced unpredictable results, so I didn't encourage this, especially since it could lock up the pseudo-random sequence generator by filling it with zeroes."

If it would only be a logical ANDing, the results would actually be predictable. But Bob seemed to knew that something different was still going on, so he added this confusing "which produced unpredictable results".
2006-08-24 10:57
yago

Registered: May 2002
Posts: 331
I am using another Method, I check how long Values in the read-only register stay intact.
That way i can detect 6581/8580/fastSID/reSID.
Have to do more tests on real things, however.
2006-08-24 11:58
tlr

Registered: Sep 2003
Posts: 1224
Quote: We don´t know yet. It´s quite confusing, especially if you quote Bob Yannes:

"Since all of the waveforms were just digital bits, the Waveform Selector consisted of multiplexers that selected which waveform bits would be sent to the Waveform D/A. The multiplexers were single transistors and did not provide a "lock-out", allowing combinations of the waveforms to be selected. The combination was actually a logical ANDing of the bits of each waveform, which produced unpredictable results, so I didn't encourage this, especially since it could lock up the pseudo-random sequence generator by filling it with zeroes."

If it would only be a logical ANDing, the results would actually be predictable. But Bob seemed to knew that something different was still going on, so he added this confusing "which produced unpredictable results".


It's mostly unbuffered NMOS, so when more than one multiplexer is enabled, one wave-shaper could affect the logic inside another. Isn't this the way the noise LFSR gets zeroed? The multiplexer directly loads the shift register bits?

I suspect that the mux he describes is a transistor connected as a single-ended transmission gate.

Note that these are speculations based on what is in the patents of different Commodore NMOS devices.


2010-10-01 13:06
MC
Account closed

Registered: Jul 2009
Posts: 71
Both mentioned methods, C=Hacking 20 and Mathematica of detecting which SID is being used/emulated fail on Winvice in FASTSID mode and an 8580 is detected all of the time... (with RESID both methods work 100% perfect).

Is there any way to tell which SID is being emulated when people use FASTSID emulation on their slow-assed pc?
2010-10-01 13:46
Raf

Registered: Nov 2003
Posts: 333
FastSId isn't too precise, so does it really matter if it is detected 8580 or 6581 under fastsid? btw nowadays even lower end atoms can run reSID at maxed oversampling + resampled interpolation, so why bother? FASTSID is useful for < 500Mhz machines. ("max quality" newest resid takes up to 10% of one core at my phenom x2 550 @3.4Ghz...)
2010-10-01 14:37
Frantic

Registered: Mar 2003
Posts: 1373
@MC: Dunno about that, but perhaps there is some way of detecting VICE at least, which may perhaps help at least a little... And in the end, you could always also allow people to select the SID model they have manually.

Overall, I don't think one should conform too much to shortcomings of emulators. That is just likely to mess things up in the end (especially the day when emulation changes). Also, I think it is fair to expect that people who want to use your music editor in VICE will actually have resid-fp enabled, since it is more accurate.

Personally I prefer this detection method:
http://codebase64.org/doku.php?id=base:detecting_sid_type_-_saf..

The Mathematica/Reflex detection routine has been reported not to be 100% reliable, although I have not experienced problem with it myself.
2010-10-01 15:56
iAN CooG

Registered: May 2002
Posts: 2297
; Detect fastSID/reSID/reSID-fp/Hoxs/CCS. Real C64 untested.
; Just measure how much $d418 takes to decay from $1f to $00
; Experiment by iAN CooG, noticed first time in Excalibur intro exc-01
    *=$0801
    word eop
    word 7102
    byte $9e,"2059"
eop byte 0

    lda #0
    sta $0400
    sta $0401
    sta $0402
    ;SEI probably not needed
    lda #$1f
    sta $d418
loop
    inc $0400
    bne nohi
    inc $0401
    bne nohi
    inc $0402
nohi
    lda $d418
    bne loop

    ;values   | Engine
    ;---------+--------
    ;xx xx 01 | hoxs
    ;xx 07 00 | residfp
    ;xx 03 00 | resid
    ;xx 01 00 | ccs
    ;xx 00 00 | fastsid

    lda $0402
    beq vice
    cmp #$01
    beq hoxs
    bne realc64
vice
    lda $0401
    beq fastsid
    cmp #$04
    bcs residfp
    cmp #$03
    bcs resid
ccs
    lda #"S"
    byte $2c
resid
    lda #"R"
    byte $2c
residfp
    lda #"P"
    byte $2c
fastsid
    lda #"F"
    byte $2c
hoxs
    lda #"H"
    byte $2c
realc64
    lda #"C"
    jmp $ffd2

2010-10-01 16:51
Hein

Registered: Apr 2004
Posts: 840
What's the idea behind that? Reading a write-only register seems odd. (If it works, it works, though)
2010-10-01 17:43
MC
Account closed

Registered: Jul 2009
Posts: 71
It does actually work so far (on VICE). Good stuff there from iAN CooG. Muchos gracias.
2010-10-01 18:11
iAN CooG

Registered: May 2002
Posts: 2297
of course must be tested against a real c64 before saying it's correct, it could be even that hoxs has already the correct behaviour =)
All I know is that years ago I noticed that Excalibur intro exc-01 was polling $d418 to know when the intro was about to close, because after pressing space the volume fadeout routine set volume to 0. Strangely the intro immediately exited by itself both in CCS 2.0 and Vice with fastsid, and only worked in vice+resid.
2010-10-01 19:07
MC
Account closed

Registered: Jul 2009
Posts: 71
In CCS V3.8 the code finds resid (03) instead of CCS. Does CCS 3.8 actually utilize resid? I can't find the info on the ccs site.

2010-10-01 19:30
iAN CooG

Registered: May 2002
Posts: 2297
it doesn't use resid, ccs3 must be just "more accurate" than ccs2.0, which is the one i tested, and produces a similar result to vice resid. maybe by comparing results of location $0400/$0401 there is a chance to separate resid from ccs3, feel free to enhance the detection code :P
2010-10-02 08:11
Frantic

Registered: Mar 2003
Posts: 1373
Hmm.. funny. I will have a look on this some day.

As far as I remeber you can actually read sid registers in the sense that the value that was last written to the sid can be read back least within a certain time span. So.. While the sid registers aren't generally "readable", they can be sometimes, so to speak..
2010-10-02 10:42
MC
Account closed

Registered: Jul 2009
Posts: 71
; Emulation SID recognition table (responses from iAN CooG's test routine)
;
;    C4:03:00	VICE + RESID 6581
; BC/CF:03:00	VICE + RESID 8580
;    05:00:00	VICE + FASTSID (gets unreliable SID type from ANY testing)
;    D7:07:00	VICE + RESIDFP 6581
; DF/CA:07:00	VICE + RESIDFP 8580
;
;    XX:CC:01	HOXS (Emulates an 8580 always)
;
;    98:03:00	CCS3.X 6581
; A0/8A:03:00	CCS3.x 8580
;    1F:01:00	CCS2.x 6581
; 0F/14:01:00	CCS2.x 8580
;
; 7D-8F:00:00	Real C64 6581
; ???		Real C64 8580


TESTED WITH INTERRUPTS DISABLED (so enable that sei)

Can someone with a real 8580 get me a result please?
iAN (or anyone who feels like it) could you confirm these tests please, I ran it several times on every emulator with every setting and the results SEEM to be conclusive.

Cheers, Marco

2010-10-02 10:54
Frantic

Registered: Mar 2003
Posts: 1373
@MC: While it is nice to know how to check for various things, I get curious about what you will use this for? Will you make custom filter tables to make the tunes sound as similar as possible on different SID models and SID-emulation engines, or what?
2010-10-02 12:20
MC
Account closed

Registered: Jul 2009
Posts: 71
Exactly.
2010-10-02 12:27
iAN CooG

Registered: May 2002
Posts: 2297
ok, here's a new version =)
; Detect fastSID/reSID/reSID-fp/Hoxs/CCS/Frodo
; Just measure how much $d418 takes to decay from $1f to $00
; Experiment by iAN CooG, noticed first time in Excalibur intro exc-01
; Thanks to MC/Dutch USA-Team for checking CCS3 and real C64 timings
; Note: can't detect emulated sidmodel 6581/8580, values overlap.
; values   | Engine
; ---------+--------
; xx xx 01 | hoxs     (1cc00-)
; xx 07 00 | residfp  (7ca-7df)
; bx 03 00 | resid    (3bc-3cf)
; 8x 03 00 | ccs3     (38a-3a0)
; xx 01 00 | ccs2     (10f-11f)
; 7x 00 00 | real c64 (07d-08f)
; 0x 00 00 | fastsid  (003-005)
; 01 00 00 | vice nosound (001)
; ff ff ff | frodo    (never decays)

_id_hoxs     = 0
_id_residfp  = 1
_id_resid    = 2
_id_ccs3     = 3
_id_ccs2     = 4
_id_realc64  = 5
_id_fastsid  = 6
_id_nosound  = 7
_id_frodo    = 8

    *=$0801
    word eop
    word 7102
    byte $9e,"2059"
eop byte 0

    lda #0
    sta $0400
    sta $0401
    sta $0402

    sei
    lda #$1f
    sta $d418
loop
    inc $0400
    bne nohi
    inc $0401
    bne nohi
    inc $0402
    lda $0402
    cmp #$02
    beq check ; or directly: beq frodo
nohi
    lda $d418
    bne loop
check
    lda $0402
    beq vice
    cmp #$02
    beq frodo
    bne hoxs
vice
    lda $0401
    bne chkrs
    lda $0400
    cmp #$70
    bcs realc64
    cmp #$03
    bcs fastsid
    bcc nosound
chkrs
    cmp #$04
    bcs residfp
    cmp #$03
    bcc ccs2
rscc3
    lda $0400
    cmp #$b0
    bcs resid
ccs3
    ldx #_id_ccs3
    byte $2c
ccs2
    ldx #_id_ccs2
    byte $2c
resid
    ldx #_id_resid
    byte $2c
residfp
    ldx #_id_residfp
    byte $2c
fastsid
    ldx #_id_fastsid
    byte $2c
nosound
    ldx #_id_nosound
    byte $2c
hoxs
    ldx #_id_hoxs
    byte $2c
frodo
    ldx #_id_frodo
    byte $2c
realc64
    ldx #_id_realc64
    lda offtablel,x
    ldy #>stringtable
    ;cli ($ffd2 already clears int flag)
    jmp $ab1e

stringtable
shoxs     byte "HOXS64"  ,0
sresidfp  byte "RESID-FP",0
sresid    byte "RESID"   ,0
sccs3     byte "CCS 3"   ,0
sccs2     byte "CCS 2"   ,0
srealc64  byte "REAL C64",0
sfastsid  byte "FASTSID" ,0
snosound  byte "NO SOUND",0
sfrodo    byte "FRODO"   ,0

offtablel
          byte <shoxs
          byte <sresidfp
          byte <sresid
          byte <sccs3
          byte <sccs2
          byte <srealc64
          byte <sfastsid
          byte <snosound
          byte <sfrodo
2010-10-02 13:33
assiduous
Account closed

Registered: Jun 2007
Posts: 343
using d418 fade out time to detect the sid model is abit risky. this thing has a very analogue nature so it depends on temperature and varies in a wide range. you will likely get different results on different chips and even on 1 chip when you test it cold and warmed up. some sids take so much time to drop bits from the write only registers that they fail the emufuxxor test.

i`ve run the program on an 8580,the first test shortly after the bootup printed C but 20 minutes later it changed its mind for good: screen shot

Sounddemon`s method can be trusted the most.
2010-10-02 14:50
MC
Account closed

Registered: Jul 2009
Posts: 71
Things come down to ranges of values of the low byte. In the current emulators I'm getting proper results, in CCS2 its hard to distinguish 8580 from 6581 emulation (but that's old crap anyway).

I'll up a testproggie and edit this post shortly.

Edit: http://tanx0r.org/mc/iantestprog.prg

Plz run that and tell me if the results are correct. TIA.

2010-10-02 15:39
MC
Account closed

Registered: Jul 2009
Posts: 71
Now that I come to think about it, I already have conclusive results when combining the results from D418 and D41B tests.

I know which SID emulation is running and I detected the SID model being emulated in all situations but vice/fastsid.

Knowing the situation in which a song was created will allow people to compensate. Also, an editor can have seperate settings for different SID models and even emulations. Knowledge == power.
2010-10-02 20:19
Frantic

Registered: Mar 2003
Posts: 1373
But... :)

Even within the category of "6581" sids there is a considerable variance in the filter characteristics, and I guess the same also the case when using resid-fp for example, depending on which 6581 variant (or 8580 variant) you choose and so forth? :)

Personally I eventually gave up on the filter issue around one or two years ago, hehe.. :) (Well, I do some minor adjustment depending on whether it is 8580 or 6581, but more than that... nah..)

Anyway, it is interesting to see what you come up with, so I am not trying to discourage anyone or so. Just providing my own take on the matter.

//FTC
2010-10-02 21:16
MC
Account closed

Registered: Jul 2009
Posts: 71
Well if we're gonna detect a SID let's just do the best possible job while at it... Afterall the question isn't a simple "why" but rather "why not"...
2010-10-03 20:11
MC
Account closed

Registered: Jul 2009
Posts: 71
Okay. More testing has been done and I added JAC64 to the list of recognized emulators. iAN is correct in stating you can't judge whether you're dealing with 6581 or 8580 emulation from the D418 timing test.

I have created wider margins on the recognized ranges as well so it should really always correctly detect SID + emulation now through combined D418 timing and D41B testing for high bit.

Note: EMU64 doesn't give any reliable results and is recognized as VICE/NOSOUND.

Here's the table:
;			     min max med  hi sidcode
recogtab:		dc.b $00,$00,$CC,$01,0		; HOXS, 8580
			dc.b $A0,$F0,$07,$00,1		; VICE, RESIDFP
			dc.b $B0,$E0,$03,$00,2		; VICE, RESID
			dc.b $70,$B0,$03,$00,3		; CCS3.X
			dc.b $01,$28,$01,$00,4		; CCS2.X
			dc.b $20,$FF,$00,$00,5		; Real C64
			dc.b $02,$0F,$00,$00,6		; VICE, FASTSID
			dc.b $00,$01,$00,$00,7		; VICE, NOSOUND
			dc.b $00,$00,$00,$02,8		; FRODO
			dc.b $C8,$E8,$01,$00,9		; JAC64


Testproggie: http://tanx0r.org/mc/iantestprog2.prg

2012-05-27 17:15
Jak T Rip

Registered: Feb 2002
Posts: 39
Hi guys,

I tested the latest test program with my real C64 and
- the SID and VIC type are reliably detected (8580 PAL 50Hz)
- emu type is detected as
1) Unknown when I have no additional HW on (or with SCPU in 1Mhz mode)
2) Frodo in case I have a SuperCPU running in 20Mhz

The displayed values for normal unenhanced C64II are
xx:98:00

The first value is completely unreliable. I get values between 1x and fx.
The second value is very stable. I get values around 98, sometimes 99 or 9a, but never far off.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
JCH/Vibrants
iAN CooG/HVSC
ciccior2003/HF
Krill/Plush
pcollins/Excess
Moloch/TRIAD
jeroen1328
Guests online: 39
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 X Marks the Spot  (9.5)
9 Wonderland XII  (9.5)
10 OMG Got Balls!  (9.5)
Top onefile Demos
1 Smile to the Sky  (9.5)
2 Instinct  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Dawnfall V1.1  (9.4)
5 Pandemoniac Part 2 o..  (9.4)
6 Crystal Gazer  (9.4)
7 Rewind  (9.4)
8 Bad Boy  (9.4)
9 Official X2018 Report  (9.4)
10 Party Horse  (9.4)
Top Groups
1 Fossil  (9.7)
2 PriorArt  (9.6)
3 Oxyron  (9.4)
4 Booze Design  (9.4)
5 Censor Design  (9.3)
Top Graphicians
1 Mirage  (9.7)
2 Archmage  (9.7)
3 Duce  (9.7)
4 Veto  (9.7)
5 Electric  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.107 sec.