On Fri, 2 Jul 1999, Nicolas Welte wrote:
> > Hmm. now that I have worked out the bizarre implementation of the FM sound
> > chip on the 65xx bus, I doubt very much that a Soundblaster card could be
> > grafted onto the Commodore bus without at least some modifications on the
> > Soundblaster pcb.
>
> Why? The ISA bus should also have the separated READ and WRITE lines,
> and all the address lines are there. The interface to the SB card could
> be similar to the C64-OPL2 interface, with an added address encoder for
> the SB card. Instead of just decoding the C64 addresses to the OPL2 chip
> select you would have to create an ISA bus I/O address for it. Somewhat
> dependent of the R/W signals of course, because of that strange mapping
> on the Sound Expander. Doing it with discrete TTL components might
> actually be hard, but it should be possible to use some programmable
> logic like GALs. Not that I had any experience with them :-(
Well I must admit I didn't know ISA had seperate read and write lines. In
that case, the decoding of the YM3812 on a Soundblaster is probably simple
enough not to get in the way of the 65xx bus. I'll buy a few ISA
connectors today ;) Basically, I/O2# has to be 'un-decoded' to appear as
22xh on the ISA address bus. Assuming READ# and WRITE# are connected
straight through to the FM chip, they can be decoded in the usual SFX way
on the SB->C64 bridge card.
> > Here's the proposed software interface ('supported' register addresses):
> >
> > $DF40 Primary index register write only (220 on PC)
> > $DF48 Secondary index register write only (222 on PC)
> > $DF50 Primary data register write only (221 on PC)
> > $DF58 Secondary data register write only (223 on PC)
> > $DF60 Status register read only (220 on PC)
>
> Looks good. I don't know about the compatibility with the original
> software, of course. There are 2 significant address bits on the SFX
> side, plus the status register bit and the state of the R/W line. The PC
> side also only has 2 significant register bits. The extra case of
> reading the status register can be handled. As it seems, the address
> lines can be directly connected: C64 A4 with SB A0 and C64 A3 with SB
> A1. C64 A5 and R/W is checked for read accesses to the SB status
> register. The address lines A4 and A3 already match.
I have read that $DF40, $DF50 and $DF60 are the locations used by the
official software, therefore they will be preserved in any implementation
of OPL3. $DF40 and $DF50 are used in a write-only manner, whereas $DF60 is
read only. Any 'rogue' software out there might behave differently, and
may well be broken under the new scheme, but this is a problem in any
upgrade scheme. Bit 0 of register 5 in the OPL3 acts as an 'OPL3 feature
enable' when written to from the secondary port (see
http://www.fee.vutbr.cz/~arnost/opl/opl3.html#reg105 ), and this could
also be used to enable logic which passes A3 to OPL3 A1 (otherwise it
would be held at 0), but this would need more logic and I'm not convinced
it's necessary.
> BTW, where are the SB DAC and ADC registers on the PC? These could also
> be mapped into the C64 I/O space to give possibility of 8bit sampling.
> Only in PIO mode, I guess, because a DMA interface would be to
> complicated.
No idea. It would be nice to have DMA, and maybe even _just_ possible (!)
with a 1MHz clock, though it would have to halt the 6510 and I don't know
how it would react to the VIC-II's frequent 40 cycle-long interruptions
(badlines). Obviously the video chip has to have priority, so perhaps DMA
sound would be distorted whenever the screen is enabled.
> > The two registers labelled 'Secondary' are new. Of course, in actual fact
> > there are mirrors all over the DFxx address range, just as there are in
> > the original Sound Expander.
>
> Where are the mirrors? Which lines are decoded at all?
OK, here are the results of the reverse-engineering from a software
interface point-of-view:
All writes to $DFxx access the FM chip. (YM3526 OPL or YM3812 OPL2)
Since A4 is connected to A0 on the FM chip, a write to an address with bit
4 reset (eg. $DF40) will access the index register. Writes to addresses
with bit 4 set (eg. $DF50) access the data register. Writing to the
so-called read-only status register ($DF60) will in fact change the index
register. On the PC, these two are in fact the same register, 220h.
A7 A6 A5 A4 A3 A2 A1 A0
- - - 0 - - - - Write to index register
0 1 0 0 0 0 0 0 ($DF40)
A7 A6 A5 A4 A3 A2 A1 A0
- - - 1 - - - - Write to data register
0 1 0 1 0 0 0 0 ($DF50)
Reads are handled differently. Bit 5 accesses the FM chip (active high)
and bit 3 accesses the keyboard interface (active high), so addresses with
both high will cause bus contention.
A7 A6 A5 A4 A3 A2 A1 A0
- - 1 0 0 - - - Read from status register
0 1 1 0 0 0 0 0 ($DF60)
A7 A6 A5 A4 A3 A2 A1 A0
- - 1 1 0 - - - Data on bus not guaranteed (according to Yamaha)
A7 A6 A5 A4 A3 A2 A1 A0
- - 0 - 1 - - - Read from keyboard matrix
0 0 0 0 1 C B A ($DF08 - $DF0F)
A7 A6 A5 A4 A3 A2 A1 A0
- - 1 - 1 - - - Bus contention! (do not use)
Within this interface, it was fairly easy to decide where to add the OPL3
A1 address line - although A3 is used to enable the keyboard interface on
reads, the secondary registers in OPL3 (the ones with A1 set) are all
write-only, so it can also be used as A1 on the FM chip for writes. There
is no such thing as a Secondary status register, so the address $DF68 is
not used. This is fortunate (nay, deliberate by design!) as that happens
to be one of the addresses that cause bus contention between the keyboard
interface and FM chips.
The schematics are part-drawn as I write, and will come in two halves -
the Digital interface (address decoding, clock generation and keyboard
interface) and the Analogue interface (FM chip, D/A convertor and quad
op-amp filter circuits). Obviously the names aren't a clear-cut
distinction between the two pages, but I thought they were in the 'spirit'
of the schematics :)
Richard
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.