| |
Hermit
Registered: May 2008
Posts: 208 |
Proposal for 2SID hardware-compatibility
I'm fiddling with 2SID hardware solution right now, and got an idea for a most suitable address for the 2nd SID, which could be compatible with almost all hardware solutions (except $de00, $df00, but they're not good selection anyway due to conflicting with AR,TFR, etc. cartridges.)
In VICE it's easy to set 2nd SID base-address, but it's not the case with real C64.
There's a multiplexer circuitry, which uses one of the address lines between A5..A9 ($20..$200) beside the original $d400..$d7ff chip-select signal. The address-line is hardwired in most of the cases, and not easily selectable/switchable in the real machines.
(Btw. I could solve it by hardware to see 2nd SID both in $d420 and $d500 locations, by "OR"-ing A5 and A8 lines...)
I think using/preferring only base-address $D7E0 for 2nd SID in 2SID programs & music releases would ensure that any of the A5..A9 address lines could select the 2nd SID in the machines, similarly to an "OR" function...
(the address came from this simple calculation: $d400+$20+$40+$80+$100+$200 = $D7E0)
It's easier by software than by hardware.
And VICE's 2nd SID address can be set to $D7E0. If VICE emulates the hardware multiplexor, the $d420, $d500, etc. settings could be fine too in VICE, just as on real C64, all would call 2nd SID at $d7E0
I guess it's not hard to configure in SID-players too...
Just, because 2SIDs seem to get more popular and real machine is always better to compose & listen with :)
Maybe the issue, it's not forward-compatible with 3SID, 4SID, etc solutions.
A further improvement to this 'specification' could be to distinguish mono (6 channels) vs stereo (2x3 channels) SID tunes by the A6 or A7 ($40 or $80) address lines, which seem rarely used for 2nd SID selection...
So in that case SID addresses could follow like this:
$d400..$d41f: 1st SID
$d7a0..$d7bf: 2nd SID, A6 ($40) low - line says "mono"
$d7e0..$d7ff: 2nd SID, A6 ($40) high - line says "stereo"
It was just a idea, i couldn't find this in the forum after some search, maybe it was mentioned before, maybe not... |
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Wouldn't it be better just to scan for the SIDs?
It shouldn't be too hard to determine how many unique SIDs there are in the $d400-$d800 range.
1. clear $d400-$d800.
2. set up v3 of sid at $d400 for detection.
3. detect (using $d41b) the aliases that exist for that sid.
4. disable v3 of sid at $d400.
5. go back to 2 but with $d420 as base instead.
Continue until enough sids are found (or $d800 is reached. |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Watch out for the VDC which naturally resides at $D600 in C128, even in C64 mode. Something like that should detect the VDC reliably:
LDX #$12
LDY #$DE
LDA #$0E STA $D626 STX $D627
LDA #$0F STA $D626 STY $D627
LDA #$0E STA $D626 CPX $D627 BNE novdp
LDA #$0F STA $D626 CPY $D627 BNE novdp
This writes 2 values into VDP registers that won't cause havoc (cursor position) and then checks whether these values can be read back.
If a SID is connected instead it'll read from voice 3 osc which will never give such values since its maximum envelope speed is limited. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Hermit,
you should ask my brother Devia about this, because he and Lotus have made what i think is the ultimate 2sid.
The 2sid that Devia has done, and there is a whitepaper on it, you just plug it on, and go! no soldering, no wires.
Devia and Lotus showed it on LCP 2009 party, but people arent interested to invest money in it, so it was never produced.
naybe youre doing it a bit different, and want a programmable sid address for sid #2 ?
write to devia, ulf@harries.dk |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
using d420, d440, d480, d4c0 etc for 2nd sid seems best to me, because all the software that use 2 sids, use one of these adresses.
going d7xx seem weird, then all this software is obsolete! :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
actually there is a lot of software that uses $de00 =P |
| |
Hermit
Registered: May 2008
Posts: 208 |
@SIDwave: The $d7e0 address would trigger all of the mentioned $d420, $d480, etc. addresses with the simple multiplexer solution (like my transistor-based solution). So the old programs mustn't be modified...it's just about new programs to be more compatible with existing hardware...
If there are multiplexers which strictly use certain ranges (e.g. $d420..$d41f and no repeated address), this wouldn't work...
@Groepaz: I like to use fastloader cartridge even if I have 2 SIDs in my machine. I remember my first home-made cartridge, it didn't need the $de00 address and worked with $DE00 SID, but for example, an Action Replay cartridge and the MMC Replay clashed with $de00 IIRC... If it's the case, that's not good if $de00 is used a lot...
I checked: In the shematic of Action Replay cartridge the IO1 ($de00) and IO2 ($df00) (pin 7 and 10 of the expansion port) are connected and used/occupied :(
http://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/c6.. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Watch out for the VDC which naturally resides at $D600 in C128, even in C64 mode. Something like that should detect the VDC reliably:
LDX #$12
LDY #$DE
LDA #$0E STA $D626 STX $D627
LDA #$0F STA $D626 STY $D627
LDA #$0E STA $D626 CPX $D627 BNE novdp
LDA #$0F STA $D626 CPY $D627 BNE novdp
This writes 2 values into VDP registers that won't cause havoc (cursor position) and then checks whether these values can be read back.
If a SID is connected instead it'll read from voice 3 osc which will never give such values since its maximum envelope speed is limited.
Thanks for pointing that out. $d626/$d627 would be offset 6/7 in a sid (=V0SR + V1FL). Those are write only and unpredictable on read.
Do I understand correctly that the VDC registers are mirrored every 2 bytes in $d600-$d7ff?
Detecting $de00-$dfff sids is a bit more tricky because of unknown types of carts potentially residing there.
A selection of Scan, Partial Scan (e.g $d400-$d5ff) and manual would be appropriate IMO. |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
I read incorrect values from a SID register table written in decimal (instead of hex), sorry :(
And yes, the VDC's 2 external registers repeat again and again from $D600 to $D6FF.
Also, check for further SIDs at $D700 in C128.
Here's a corrected version:
; Disable voice 3 by setting the test bit if there's a SID reachable at $D600. This should ensure that reading the oscillator always yields the same value.
LDA #$FF
STA $D612
; Write test values into VDC's cursor address and read them back.
; If there's a SID it'll read voice 3 osc instead and thus get different values.
LDX #$12
LDY #$DE
LDA #$0E STA $D61A STX $D61B
LDA #$0F STA $D61A STY $D61B
LDA #$0E STA $D61A CPX $D61B BNE novdp
LDA #$0F STA $D61A CPY $D61B BNE novdp |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Another approach would be to detect the fact that the machine is a C128 and skip the $d600-$d6ff area based on that. (or always skip $d600-$d6ff because it's presumably rare as sid placement)
C128 can be detected in a couple of ways. I'm tempted to try the 1/2 MHz variant. i.e switch on 2 MHz in the vb area and verify cpu timing against a cia timer.
Does 2 MHz mode affect the VIC output at all if kept in the upper/lower border? |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
sure, if you open the borders, then instead of $3fff always the (every 2nd) byte is displayed that the cpu read last. risen from oblivion exploited this to display fullscreen & top / bottom border gfx. (hint: many lda #$xx). |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting Oswaldsure, if you open the borders, then instead of $3fff always the (every 2nd) byte is displayed that the cpu read last. risen from oblivion exploited this to display fullscreen & top / bottom border gfx. (hint: many lda #$xx).
Ah, neat effect! For this job I only need to be sure it doesn't f-ck up the video output when flipped in the upper/lower border. I seem to remember that the display goes grey/bw when keeping the 2MHz mode permanently on but it was a _really_ long time since I had a C128 to fiddle with. |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Quote:Does 2 MHz mode affect the VIC output at all if kept in the upper/lower border?
No.
You're totally right - it should be enough to test whether you've got a C128 and then exclude $D500..$D6FF.
But you don't need to do timing tests - write $00 to $D030 and then read it back, AFAIK you'll then always get $FF on C64 and $FC on C128.
However, there might be unconnected address ranges (e.g. if a 2-SID addon was installed but just 1 SID inserted into it) - you'll get nonsense (more or less) when reading from those values (to be precise: remnants of the data byte read by the VIC during its cycle phase, with 0 or more bit flips). |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quote:Does 2 MHz mode affect the VIC output at all if kept in the upper/lower border?
No.
You're totally right - it should be enough to test whether you've got a C128 and then exclude $D500..$D6FF.
But you don't need to do timing tests - write $00 to $D030 and then read it back, AFAIK you'll then always get $FF on C64 and $FC on C128.
However, there might be unconnected address ranges (e.g. if a 2-SID addon was installed but just 1 SID inserted into it) - you'll get nonsense (more or less) when reading from those values (to be precise: remnants of the data byte read by the VIC during its cycle phase, with 0 or more bit flips).
I've used the $d030 method previously. I don't think the $00->$d030 is necessary unless the machine has TEST + 2MHz set at the routine start. Thought perhaps I'd give a different method a shot but maybe not. :)
So $d500-$d5ff can't be used for sid on a c128? I know it's the MMU but is it still there in c64 mode?
Unconnected stuff is simple to handle. I'm more concerned about stuff that has side effects when written to, like a cart. ;) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
I made a simple scanner you can try out: sid-detect2.prg
It always scans $d400-$d7ff + $de00-$dfff so it may cause problems with carts.
Only emulator tested, which revealed a secret bug... ;)
EDIT: fixed some stupid errors. (like printing 6581 for both 8580 and 6581)
EDIT: and yet another one, masked by the secret bug. |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Quote: I made a simple scanner you can try out: sid-detect2.prg
It always scans $d400-$d7ff + $de00-$dfff so it may cause problems with carts.
Only emulator tested, which revealed a secret bug... ;)
EDIT: fixed some stupid errors. (like printing 6581 for both 8580 and 6581)
EDIT: and yet another one, masked by the secret bug.
I tried this on my DualSID. It detects 6581 on D400 and 2nd SID (8580) on DE00 and DF00 correctly.
However, when the 2nd SID is on D500 it tells me it's in D520. Also, when both SIDs are in D400 it says there's only 8580 in D420 :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: I tried this on my DualSID. It detects 6581 on D400 and 2nd SID (8580) on DE00 and DF00 correctly.
However, when the 2nd SID is on D500 it tells me it's in D520. Also, when both SIDs are in D400 it says there's only 8580 in D420 :)
Interesting. The scan relies on that the sid can be read from. It's expected that you'll get corrupt results when both sids are in $d400 as the reads will collide on the bus and the sids are different.
$d500 seems strange on the other hand. Are you sure that the sid at $d500 can be read back from $d500 in that configuration? |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Quoting tlrAre you sure that the sid at $d500 can be read back from $d500 in that configuration?
At least poking+peeking shows values correctly. It seems to mirror d500 to d520, d540, d560 and so on. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
What does the "sid map" look like for the mysterious configuration? |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Quoting tlrWhat does the "sid map" look like for the mysterious configuration?
D400 11 -- 11 -- 11 -- 11 --
D500 -- 20 -- 20 -- 20 -- 20
D600 11 -- 11 -- 11 -- 11 --
D700 -- 20 -- 20 -- 20 -- 20
D800 ** ** ** ** ** ** ** **
D900 ** ** ** ** ** ** ** **
DA00 ** ** ** ** ** ** ** **
DB00 ** ** ** ** ** ** ** **
DC00 ** ** ** ** ** ** ** **
DD00 ** ** ** ** ** ** ** **
DE00 -- -- -- -- -- -- -- --
DF00 -- -- -- -- -- -- -- -- |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Thanks. That explains the result but not what causes it. It could be a bug or it could be something I fail to realize with the decoding.
The digits are XY, X=sid number, Y=type (1=6581, 0=8580)
I did a few changes to the binary as the edits indicate, when did you download it? (the changes were within a few minutes) |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Quoting tlrI did a few changes to the binary as the edits indicate, when did you download it? (the changes were within a few minutes)
I downloaded it after both of the edits. If there's something funny with the hardware, maybe Tomi Malinen knows what's going on. |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Oh, what was missing from my first post was that 2nd SID in D420 is detected correctly. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quoting tlrI did a few changes to the binary as the edits indicate, when did you download it? (the changes were within a few minutes)
I downloaded it after both of the edits. If there's something funny with the hardware, maybe Tomi Malinen knows what's going on.
Nah, I'd rather analyze my program in detail first. It's more likely I made a bug than anything. We shouldn't trust emulators on things like this.
Having a schematic of the sid board would help though.
What I do (twice) for each test is set up a sawtooth like this:
$7f -> $xx12
$20 -> $xx0e
$20 -> $xx0f
$20 -> $xx12
then sample 3 values from $xx1b and verify that they are in the correct sequence.
After the two tests I do:
$00 -> $xx12.
In the test map you posted it detects every other sid which may indicate that running a new test after a working one always fails.
Any sid hacking guru that sees anything fatal here? |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
Tested on my 6581 ($d400)/8580 (selectable) setup.
Chips at $d400, $d420, $d440, $d480, $d500 & $d600 were indentified correctly.
If I set both chips to $d400 it only detects the 6581, but that's because I've added logic to forbid reads from the 8580 if they're both at the same address. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Cool! Could you post the sid map for some typical configuration so I can compare to the one Trurl posted? |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
Not very surprising...
D400 11 11 11 11 11 11 11 11
D500 11 11 11 11 11 11 11 11
D600 11 11 11 11 11 11 11 11
D700 11 11 11 11 11 11 11 11
D400 11 20 11 20 11 20 11 20
D500 11 20 11 20 11 20 11 20
D600 11 20 11 20 11 20 11 20
D700 11 20 11 20 11 20 11 20
D400 11 11 20 20 11 11 20 20
D500 11 11 20 20 11 11 20 20
D600 11 11 20 20 11 11 20 20
D700 11 11 20 20 11 11 20 20
D400 11 11 11 11 20 20 20 20
D500 11 11 11 11 20 20 20 20
D600 11 11 11 11 20 20 20 20
D700 11 11 11 11 20 20 20 20
D400 11 11 11 11 11 11 11 11
D500 20 20 20 20 20 20 20 20
D600 11 11 11 11 11 11 11 11
D700 20 20 20 20 20 20 20 20
D400 11 11 11 11 11 11 11 11
D500 11 11 11 11 11 11 11 11
D600 20 20 20 20 20 20 20 20
D700 20 20 20 20 20 20 20 20 |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Thanks. Indeed expected. Looks like my little program is working after all.
I wonder what's up with Trurls config? Maybe it's just that read back is only allowed for A0=0 (SID1) and A0=1 (SID2)? |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
I ordered couple of those DualSID boards that Trurl has. Will see what's up with them. |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
2x8580 DualSID-card:
@$D400
D400 10 10 10 10 10 10 10 10
D500 10 10 10 10 10 10 10 10
D600 10 10 10 10 10 10 10 10
D700 10 10 10 10 10 10 10 10
DE00 -- -- -- -- -- -- -- --
DF00 -- -- -- -- -- -- -- --
@$D420
D400 10 20 10 20 10 20 10 20
D500 10 20 10 20 10 20 10 20
D600 10 20 10 20 10 20 10 20
D700 10 20 10 20 10 20 10 20
DE00 -- -- -- -- -- -- -- --
DF00 -- -- -- -- -- -- -- --
@$D500
D400 10 -- 10 -- 10 -- 10 --
D500 20 20 20 20 20 20 20 20
D600 10 -- 10 -- 10 -- 10 --
D700 20 20 20 20 20 20 20 20
DE00 -- -- -- -- -- -- -- --
DF00 -- -- -- -- -- -- -- --
@$DE00
D400 10 -- 10 -- 10 -- 10 --
D500 10 -- 10 -- 10 -- 10 --
D600 10 -- 10 -- 10 -- 10 --
D700 10 -- 10 -- 10 -- 10 --
DE00 20 20 20 20 20 20 20 20
DF00 -- -- -- -- -- -- -- --
@$DF00
D400 10 -- 10 -- 10 -- 10 --
D500 10 -- 10 -- 10 -- 10 --
D600 10 -- 10 -- 10 -- 10 --
D700 10 -- 10 -- 10 -- 10 --
DE00 -- -- -- -- -- -- -- --
DF00 20 20 20 20 20 20 20 20
While I had some trouble with the card initially (not hooking up the extra address-lines expecting both SIDs to still work at $D400) and looked how the address decoding was wired I noticed that under several settings the logic keeps SID1 disconnected when accessing it via certain addresses. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
A bit odd (and different than trurls) but detection seems to be working I guess. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
and it shows that if your software uses the mirrors - its your fault =) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Anything can happen when you add third party hardware modifications but sure if you want maximum compatibility, don't use mirrors. |
