Phipli
Well-known member
In
Someone in the comments here offered to upload version 2, but nobody responded to themI'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 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.
