| |
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... |
|
... 22 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1762 |
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: 1762 |
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: 1762 |
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: 1762 |
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: 1762 |
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: 1762 |
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) |
| Previous - 1 | 2 | 3 | 4 - Next |
