The Pro Audio Spectrum 16 NuBus's YMF262 FM synthesizer...

[Mr. Ksoft]

So this has been bothering me for a few years... I have the Pro Audio Spectrum 16 NuBus card and there is a Yamaha YMF262 (OPL3) FM synth chip on the board staring back at me. It's mentioned in the manual's spec sheet, pretty sure it's on some of the marketing materials too, but there doesn't seem to be any actual way to USE it. It's never mentioned in the drivers or anything... but it's there on the card. Obviously on the PC version this is part of the Sound Blaster compatibility, but I can't imagine that they would include it on the Mac version if it was completely inaccessible. As a Yamaha synth fan, this is unacceptable!

Does anyone know of any software that can use it? I recall reading a mention of some kind of devkit or reference documentation that Media Vision provided for adding PAS16 support to Mac software, which might have some info, but now I can't find that mention again and I don't think the disks or docs are out there online. I do know a bit of programming (enough to be dangerous, I guess you could say) and wouldn't be opposed to trying to figure out how to poke at the OPL3's registers if they are exposed somehow, but obviously I've never tried to talk to a NuBus card so I have no idea what that entails...

 

[cheesestraws]

obviously I've never tried to talk to a NuBus card so I have no idea what that entails...

I can't help much with the specifics of the card, but I can tell you that all your I/O is going to be memory mapped. Each NuBus slot has an address range, and the OPL3 registers will presumably be mapped somewhere in that range. You will then be able to poke them just with normal memory reads and writes.

In your position I'd probably start with taking the ROM to bits and see if I could see anything that looked OPL3-y. The other option would be to look at the address decoding logic on the card, but that is ... harder.

 

[Phipli]

At some point I plan to do some Mac OPL3 programming, although I'm miles away ATM. I have the parts, but need the knowledge. Anything you would do will be helpful to me!

The YMF262 manual is attached. I was trying to see if there was a register that you could recognise. Perhaps scan the memory range for the NuBus card and look for a register with a default OPL value in it... See if there is only one, then study the surrounding area and see if it behaves like an OPL3.

 

[demik]

Did you find anything useful ?

I tried to do some mapping on that board to recreate the external breakout box and from the MacOS sides, it looks like there is only one input and one output. Everything else is mixed inside the card.

Maybe the OPL is accessible only from the MIDI side ?

 

[Phipli]

Did you find anything useful ?

I tried to do some mapping on that board to recreate the external breakout box and from the MacOS sides, it looks like there is only one input and one output. Everything else is mixed inside the card.

Maybe the OPL is accessible only from the MIDI side ?

Surely it is memory mapped. Can you trace out the pins on the OPL3?

 

[halkyardo]

I'd second the "explore the ROM" option. Even without having to disassemble the code, there's a mechanism for declaration ROMs to indicate the base addresses of devices to software (the MinorBaseOS and MajorBaseOS sResource entries). Not all cards use them, but if it contains those, that could yield some clues as to where to look. Do you know if the ROM for that card is dumped somewhere? I've been doing a bunch of stuff with declaration ROMs lately and I'd be happy to take a peek and see if anything jumps out at me.

For a primer on programming for NuBus cards, I'd suggest looking at Designing Cards and Devices for the Macintosh Family, and the Slot Manager chapter of Inside Macintosh: Devices. It's a bit overwhelming to grasp at first, but once the concepts all fall into place, it's a very elegant system.

 

[Phipli]

I'd second the "explore the ROM" option. Even without having to disassemble the code, there's a mechanism for declaration ROMs to indicate the base addresses of devices to software (the MinorBaseOS and MajorBaseOS sResource entries). Not all cards use them, but if it contains those, that could yield some clues as to where to look. Do you know if the ROM for that card is dumped somewhere? I've been doing a bunch of stuff with declaration ROMs lately and I'd be happy to take a peek and see if anything jumps out at me.

For a primer on programming for NuBus cards, I'd suggest looking at Designing Cards and Devices for the Macintosh Family, and the Slot Manager chapter of Inside Macintosh: Devices. It's a bit overwhelming to grasp at first, but once the concepts all fall into place, it's a very elegant system.

With one issue - I'm suspect that Mac software doesn't use the OPL, so it probably isn't declared in the Decl ROM.

 

[NJRoadfan]

You could take the brute force approach and just poke the card's I/O area with the standard OPL detection routine. https://www.fit.vutbr.cz/~arnost/opl/opl3.html#appendixB

 

[Phipli]

You could take the brute force approach and just poke the card's I/O area with the standard OPL detection routine. https://www.fit.vutbr.cz/~arnost/opl/opl3.html#appendixB

Yup, that or actually physically map out how the chip is wired into the address lines.

 

[demik]

Any idea of what tools to brute force that ? Besides MacsBugs and 3 days of work that is
The DeclROM looks empty and doesn't have much in it

@Phipli yeah I think it's going to be needed.

 

[Phipli]

Any idea of what tools to brute force that ? Besides MacsBugs and 3 days of work that is
The DeclROM looks empty and doesn't have much in it

@Phipli yeah I think it's going to be needed.

You could... Interface the chip enable pin on the OPL very carefully to the interrupt on an unused Nubus slot and then write a program to progressively read the PAS16's address space. Break on the interrupt? I don't know how you'd do it software-wise sorry.

@cheesestraws @Crutch @Melkhior? Any thoughts on how you'd implement this? Hot wiring the chip enable so it triggers an interrupt?

 

[Phipli]

The select lines on the YMF262 are pins 4 and 5.




(Picture from here : http://www.oldschooldaw.com/forums/index.php?topic=2493.0 )

 

[Mr. Ksoft]

Hey, this thread is alive again! Nice!

So I actually went off into a corner for a while and started really getting used to working with the OPL in its native environment (DOS), so I have some fairly functional C code now for detecting, testing, and playing back commands on the chip. Seeing this thread again, armed with more knowledge, I think I might have a snowball's chance in hell of finding where the chip lives.

I want to try the "brute force" method since I have some code that can poke the chip. Was going to just write a simple hard coded program to run through the PAS16's memory space as suggested above. Of course, then I started poking around in memory in MacsBug before starting, to get a feel for where I should start (partially so that I'm sure I'm actually talking to the PAS, and partially so that I don't end up trashing my actual MacOS memory every time I run the thing). I have the PAS16 in my Quadra 800 in "Slot E" which based on the Inside Macintosh documentation should map to a "standard slot" memory location of $FE000000-FEFFFFFF, or a "super slot" memory location of $E0000000-EFFFFFFF. Thing is, looking at the $FE000000 range... it's just zeros forever. I am not seeing any signs of a card there (also E0000000 range tells me it can't show that memory) - sure, a lot of the registers might be "write only" (even the OPL itself is like that) but I'd expect to see at least a few non-zero values somewhere, considering that the card seems to save mixer values on the card - it brought up my old mixer settings from the last time I had the card in a few years ago! Shouldn't I expect to see the DeclROM or something? Is it supposed to be mapped in there somewhere?

Most likely is that I still don't actually have an understanding of how this works on the Mac and I'm thinking too simple, having gotten used to slapping IO ports around like in DOS. Do I absolutely have to deal with Slot Manager to talk to the card, perhaps? (Obviously a robust program would, but this is the discovery stage! I don't care if it only works on my machine! )

 

[demik]

Nah that should work. You can't use $E0000000-EFFFFFFF if you are in 24 bit mode, but as this is a Q800 it should be in 32 bit mode.

But if you poke $FE000000-FEFFFFFF, at least you should be able to read the DeclROM. Is the card even detected ? (Check with TattleTech or Gauche or something else)

 

[Melkhior]

I have the PAS16 in my Quadra 800 in "Slot E" which based on the Inside Macintosh documentation should map to a "standard slot" memory location of $FE000000-FEFFFFFF, or a "super slot" memory location of $E0000000-EFFFFFFF. Thing is, looking at the $FE000000 range... it's just zeros forever.

To simplify your life, rather than MacsBug, you can build a Mac console application that will do e.g.

printf("0x%08x\n", *(int*)0xFE000000);

. You can do that natively with CodeWarrior, or from a modern box with Retro68. Unlike modern operating system, this area is not protected from user access and is mapped with a physical == virtual mapping, so it's easy. You can then probe in a more sophisticated way in C/C++.

The first address to probe would be $FEFFFFFC, the last 32-bits value in the slot area. This should be mapped to the last doubleword of the ROM, which includes the width of the ROM and (if wide enough) the end of the test pattern. If you can't read this (such as a bus error), then as mentioned by other you first check with e.g. TattleTech whether the board is seen after a clean reboot. If you can read it, at least *something* is working. It should not be all-zero, if it is there's something going on with the hardware.

If you start at another address is the slot space, it's possible the hardware reacts badly and lock up...

 

[Phipli]

if you are in 24 bit mode, but as this is a Q800 it should be in 32 bit mode.

A Q800 will run in 24bit mode if you run older than 7.6.

 

[demik]

A Q800 will run in 24bit mode if you run older than 7.6.

My bad, you are right. @Mr. Ksoft be sure to be in 32 bit mode when accessing $E0000000-EFFFFFFF then

 

[olePigeon]

I wanna say that I read somewhere that a handful of Sierra games like King's Quest supported it.

 

[Mr. Ksoft]

I'm definitely in 32-bit mode, I run 7.6.1. Regardless, I still find that $E0000000 isn't readable. If I do it in a C program, I actually get dumped into MacsBug with a Bus Error. Weird. I am also 100% confident that the card works, it is detected in TattleTech and the drivers work. I can get sound out of it normally. It wouldn't have anything to do with the fact that TattleTech says that slot $0E is mapped to "pseudo slot 3", right? Does that change anything?

Anyway I'm just running with $FE000000 now. I've got a program running right now that is running through the address space trying the OPL detection routine. I don't really have confidence that it will work, as I noticed also that if I try writing any of the card memory, if I read the value back, I still end up with 0's. It's probable that a lot of this memory space is not used and they hid the actual PAS registers somewhere in there, hence scanning the entire memory space.

Another thing I thought about is that they could expose the OPL3 in a different way than on the PC. On PC it's through an I/O port where you send the target register to 0x388 and then the data to 0x389. Since this is NuBus and there is a ton of memory-mapped I/O space, I figure there's a chance they may have just exposed the registers directly. I think I may write a second version that works on that assumption. There's also the chance that I completely messed it up translating the code to MacOS (mostly getting it working without "inp" and "outp" like on DOS+Watcom C) and that's why it isn't finding anything

The closest thing to a result I've run into so far is that if I write any value to $FE000B88 I get a little click out of the speaker. The only reason I mention this is that it happens to be exactly 0x800 bytes added to 0x388... you know, 0x388 as in where it would be on a PC. However, playing around with it, I couldn't get anything to happen apart from that short click. If that's where the OPL sits, it isn't responding as I expect it to, even if I send it data to play a note instead of doing a detection routine. I may have just hit a port used for normal wave output. EDIT: Wouldn't you know it... I looked at some old PAS code in the Linux kernel and they read the PAS status register from... 0xB89. Oddly close, wouldn't you say? (Though I doubt that's supposed to make it click)

I wanna say that I read somewhere that a handful of Sierra games like King's Quest supported it.

I have read this too, but I was under the impression it was specific "bundled" versions of the games - which don't seem to have surfaced anywhere. If they're really out there, they likely would provide invaluable information upon disassembly.

EDIT2: Some other research regarding this sorry card. For instance, here's someone about 30 years ago asking the same question we are asking! Also interestingly he mentions his driver disk being labeled 2.0! As far as I know, the latest drivers we have are 1.0.4. Here's a mention of Version 1.3 as well. Of course both of these point to the same site, and it's one that predates the Wayback Machine so it's long gone.

 

[olePigeon]

@Mr. Ksoft Now that I think about it, it might be games that supported the Roland MT-32.