| |
tlr
Registered: Sep 2003
Posts: 1787 |
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.
|
|
| |
Jetboy
Registered: Jul 2006
Posts: 299 |
AFAIK you cannot test it _reliably_.
That's why many demos ask about it before they start. |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
Mathematica has a SID tester that works in VICE too. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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.
|
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
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.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
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 :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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. |
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
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? |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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?
|
| |
McMeatLoaf
Registered: Jan 2005
Posts: 108 |
$05 as in ringmod+gate, I think. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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? |
| |
Hein
Registered: Apr 2004
Posts: 945 |
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) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Hein, those sound quite interesting, especially the cycle delay method. |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
@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.. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@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
|
| |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
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?
|
| |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@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... |
| |
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/ |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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!
|
| |
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. :) |
| |
Raf
Registered: Nov 2003
Posts: 343 |
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... |
| |
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.... |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
So the rumour that 6582 is essentially an 8580 with digi-capabilities is wrong? |
| |
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. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@Hoogo: I remember that too.
It surely won't work in VICE though. |
| |
Hein
Registered: Apr 2004
Posts: 945 |
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. |
| |
Raf
Registered: Nov 2003
Posts: 343 |
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? |
| |
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. |
| |
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 |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
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? |
| |
Raf
Registered: Nov 2003
Posts: 343 |
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) |
| |
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". |
| |
yago
Registered: May 2002
Posts: 333 |
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.
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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.
|
| |
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?
|
| |
Raf
Registered: Nov 2003
Posts: 343 |
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...) |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
@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. |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
; 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
|
| |
Hein
Registered: Apr 2004
Posts: 945 |
What's the idea behind that? Reading a write-only register seems odd. (If it works, it works, though) |
| |
MC
Account closed
Registered: Jul 2009
Posts: 71 |
It does actually work so far (on VICE). Good stuff there from iAN CooG. Muchos gracias.
|
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
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. |
| |
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.
|
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
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 |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
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.. |
| |
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
|
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
@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? |
| |
MC
Account closed
Registered: Jul 2009
Posts: 71 |
Exactly. |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
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
|
| |
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. |
| |
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.
|
| |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
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 |
| |
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"... |
| |
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
|
| |
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. |
