Something I should have mentioned on dosforum is that the Midiman MM-401 isn't 100% compatible. Legend games (Gateway for example) fail to detect the card. I admit these are the only games I am aware of though...

I also believe that demand will be very limited. Definitely far less compared to let's say an Amiga, Console or Arcade project.

Now another angle of attack: Ensoniq has a MPU401 interface, while not Intelligent mode, it does what is needed for Games from Origin or Sierra to load. This works on their PCI cards as well, so maybe t's something you could implement in the driver.

That's the kind of feedback I was looking for 😀 Thanks once again.

Mau1wurf1977 wrote:

I also believe that demand will be very limited. Definitely far less compared to let's say an Amiga, Console or Arcade project.

Very much so, yes - but then again my previous project was backed by 1 person getting involved and a few stripping naked yelling "take my money, now", you know finished products are always more attractive than something that might possibly fail 😉

Now another angle of attack: Ensoniq has a MPU401 interface, while not Intelligent mode, it does what is needed for Games from Origin or Sierra to load. This works on their PCI cards as well, so maybe t's something you could implement in the driver.

That's certainly something I lack knowledge of which is why I'm asking for people getting involved if there's demand. Personally I've got to admit I barely "care" about this whole intelligent mode/roland vs. yamaha vs. the world thing (I'm happy with using my GUS in my physical DosBox), just thought it might be a decent thing to do in case there's interest.

I've always wondered if there was a software solution to this problem. I know nothing about the hardware / software involved but from what I understand MIDI devices are not particularly complicated, and I've wondered if it would be possible to write a little TSR that could monitor and intercept communication b/w the software and the MPU interface, injecting the relevant replies that are missing from non-intelligent MPU cards.

If it was possible, then it would be much easier than created a clone card!

I think the TSR idea is impracticable. If could have been done so that it would work without general difficulty, someone would have written it by now. I think the better option is to make patches for the 50 or so DOS games that require Intelligent Mode. I think NewRisingSun already did so for the Sierra games to allow them to work with UART Mode. Many of the other games use engines, so one needn't start at the beginning each time.

If it uses off the shelf components I don't really get where the copyright is - some software [driver? rom?] or the pattern of metal on the pcb?

Also there are other diy projects out there for midi like this:

http://www.maxmidi.com/diy/serial/index.html

No idea if that's any use.

I've never come across the intelligent mode problem [doesn't affect my games]. Sticking notes with sb16s may be a more widespread issue. From that point of view I'm guessing more people might be interested.

Would it be an 8bit or 16bit card? Might be some demand for 8bit from vintage computer enthusiasts.

What about any specialist cabling - is that included in your costs? Presume it can't sport a couple of big 5-pin dins.

Great Hierophant wrote:

I think the better option is to make patches for the 50 or so DOS games that require Intelligent Mode. I think NewRisingSun already did so for the Sierra games to allow them to work with UART Mode. Many of the other games use engines, so one needn't start at the beginning each time.

Sounds like the better approach there, agreed.

ratfink wrote:

If it uses off the shelf components I don't really get where the copyright is - some software [driver? rom?] or the pattern of metal on the pcb?

Rom and PCB pattern indeed, later could be changed to get into a grey area, but would leave an unpleasant taste in my mouth.

ratfink wrote:

Also there are other diy projects out there for midi like this:
http://www.maxmidi.com/diy/serial/index.html
No idea if that's any use.

Nopes, totally different approach.

ratfink wrote:

Would it be an 8bit or 16bit card? Might be some demand for 8bit from vintage computer enthusiasts.

8bit of course due to practical reasons (keeping costs low, the design as minimal as possible, including 8bit isa only computers).

ratfink wrote:

What about any specialist cabling - is that included in your costs? Presume it can't sport a couple of big 5-pin dins.

No problem to reflect that on the card, so one could use ordinary midi cables. Not sure about the huge 5pin DIN sockets but mini-din as used on some Roland cards would be possible.

It's definitely an interesting idea and I've also been thinking about doing something similar. Rather than cloning an existing design, I'd look at a more modern approach using an Atmel AVR 8-bit microcontroller (same family of microprocessors as the ones on the Arduino boards) in conjunction with some standard 7400 series chips for address decoding and buffering. That would also solve any legal issues regarding PCB layout and ROM.

By the way, for the games that require intelligent mode, is it necessary to fully implement intelligent mode, or is it enough to just send ACK messages like the Soundscapes do?

If just sending ACK bytes is enough, I don't think it's very complex to program and it would also run on the ATmega328P, which is quite cheap. For a complete implementation of intelligent mode I'd use the ATmega1284P, which is somewhat more expensive, but has more RAM. Both chips are in a DIP package, so soldering them would be easy.

Lennart wrote:

It's definitely an interesting idea and I've also been thinking about doing something similar. Rather than cloning an existing design, I'd look at a more modern approach using an Atmel AVR 8-bit microcontroller (same family of microprocessors as the ones on the Arduino boards) in conjunction with some standard 7400 series chips for address decoding and buffering. That would also solve any legal issues regarding PCB layout and ROM.

By the way, for the games that require intelligent mode, is it necessary to fully implement intelligent mode, or is it enough to just send ACK messages like the Soundscapes do?

If just sending ACK bytes is enough, I don't think it's very complex to program and it would also run on the ATmega328P, which is quite cheap. For a complete implementation of intelligent mode I'd use the ATmega1284P, which is somewhat more expensive, but has more RAM. Both chips are in a DIP package, so soldering them would be easy.

ACK is not sufficient to make all Intelligent Mode MPU-401 games work. AudioPCI also supports / emulates "intelligent mode" MPU401

The MPU-401, at least the hardware needed to implement all the vital gaming features, is not the most complex device in the world. It consisists of a HD6081 MCU, 6116 2K SRAM and 2764 8K EPROM. Later variations embed the ROM code in an HD6801VOP. The only off the shelf part is the HD61J221F Surface Mounted Chip. This presumably is used mostly for mostly bus interfacing and some of the more esoteric MIDI features like Tape in and out. Its exact functions should not be too difficult to figure out.

badmofo wrote:

I've always wondered if there was a software solution to this problem. I know nothing about the hardware / software involved but from what I understand MIDI devices are not particularly complicated, and I've wondered if it would be possible to write a little TSR that could monitor and intercept communication b/w the software and the MPU interface, injecting the relevant replies that are missing from non-intelligent MPU cards.

If it was possible, then it would be much easier than created a clone card!

I believe a TSR can only hook to an interrupt, and programs sending messages to the sound card won't generate any interrupts. So I don't think it's possible to implement full intelligent mode in software.
If all that is required is sending ACK messages to the synth once in a while, then yes, that can be done with a TSR. But I'm not sure if all sound cards trigger an interrupt when receiving MIDI messages. Even then you might be able to hook to the timer interrupt and read incoming MIDI once in a while.

ratfink wrote:

What about any specialist cabling - is that included in your costs? Presume it can't sport a couple of big 5-pin dins.

I think using a standard game port connector would make sense. Last time I checked gameport to MIDI cables were readily available, and even if these are no longer in production, it's easy to make one yourself.

The gameport cable is a good idea, since brackets are easily available. The cables themselves seem to be getting rarer. A serial port can also work similarly. MIDI out only requires three pins. MIDI in requires two, but also an Optoisolator.

I believed that the game writes a MIDI command to the command port then the polls data port for the ACK. A dumb program will sit there forever if the ACK is not received and it has not have code to do something else after a certain number of tries or times.

I don't think a TSR in real mode can detect a port read and put the appropriate value on the port for a program to read. In virtual 8086 mode, this may be possible.

Great Hierophant wrote:

The gameport cable is a good idea, since brackets are easily available. The cables themselves seem to be getting rarer. A serial port can also work similarly. MIDI out only requires three pins. MIDI in requires two, but also an Optoisolator.

I believed that the game writes a MIDI command to the command port then the polls data port for the ACK. A dumb program will sit there forever if the ACK is not received and it has not have code to do something else after a certain number of tries or times.

I don't think a TSR in real mode can detect a port read and put the appropriate value on the port for a program to read. In virtual 8086 mode, this may be possible.

So what about the hardware equivalent of my TSR suggestion - a small unit that plugs into the MIDI / Game port of a sound card (with a MIDI / joystick port on the other side for the MIDI module to connect to) which allows the MIDI signal to pass through unchanged, but that can detect and respond to the ACK requests?

It seems like a waste of effort to re-create the entire card when most sound cards already do 95% of the work.

shock__ wrote:

Only problem: you guessed it, the copyright is still valid for at least 48 years and midiman still around. Considering the card is long out of print/"rare" and occasionally reaches horrendous prices on eBay, what are your opinions on a clone?

Is hardware copyrighted? I thought making hardware clone is legal as long as you're using clean room method. For example, Compaq made the first IBM compatible PC by using clean room method to clone IBM PC BIOS, IIRC.

badmofo wrote:

Great Hierophant wrote:

The gameport cable is a good idea, since brackets are easily available. The cables themselves seem to be getting rarer. A serial port can also work similarly. MIDI out only requires three pins. MIDI in requires two, but also an Optoisolator.

I believed that the game writes a MIDI command to the command port then the polls data port for the ACK. A dumb program will sit there forever if the ACK is not received and it has not have code to do something else after a certain number of tries or times.

I don't think a TSR in real mode can detect a port read and put the appropriate value on the port for a program to read. In virtual 8086 mode, this may be possible.

So what about the hardware equivalent of my TSR suggestion - a small unit that plugs into the MIDI / Game port of a sound card (with a MIDI / joystick port on the other side for the MIDI module to connect to) which allows the MIDI signal to pass through unchanged, but that can detect and respond to the ACK requests?

It seems like a waste of effort to re-create the entire card when most sound cards already do 95% of the work.

The "ACK" requests are on the IO resource, not the MIDI interface.

What would do is an ISA card that just has a microcontroller on it that listens for the ACK request, responds appropriately, but otherwise does nothing.

So how difficult would be patching the games be? Just like with the TSR I'm thinking if it's that easy someone would have patched the main ones (e.g. Origin games for example) a long time ago.

Few things that come to my mind about emulating intelligent mode.

Emulating the ISA card so that no patching of game binaries is needed could be done at several different levels.

One is to actually build an ISA card with the same IO interface and have some MCU or CPU talk to ISA bus through buffer chips (discrete or CPLD). The MCU would need firmware to actually communicate raw data through buffers and perform the intelligent mode emulation. MCU serial port can be used for MIDI data transmission, and the physical interface can be anything (joystick port with TTL data or actual MIDI connectors with current loop interface).

But as many sound cards already provide the hardware interface part, but just do not emulate the intelligent mode. If this kind of midi interface is always in dumb mode, and forwards everything from the data port to MIDI cable, it could be possible just to add a microcontroller between the MIDI cable to perform the emulation.

One more way would be to use some 386-specific CPU features to trap IO accesses. A TSR could put a CPU into this mode where IO accesses to MPU ports would generate a interrupt and the TSR would emulate the whole hardware at IO level. I recall some sound card emulators do this. But this requires the CPU to be in some kind of protected mode, so some games might not work. Plus the actual MIDI data needs to be put somewhere, so there has to be a real MIDI interface somewhere, just not at the default MPU port as that is emulated.

The hardest part is not the ISA interface, it is how some MCU performs the emulation. For it to work, the emulation needs to be complete enough (certain commands give back certain responses) and accurate enough (the time between receiving a command and transmitting the response should be within limits that work). Good thing is DosBox already emulates the mode so there is a reference implementation. The downside is that if some software ran OK with a 4.77MHz 8086, the same software might not work on a 100MHz 80486 even with real hardware as it expects different timing.

But patching game binaries, that would make them work with regular dumb MIDI interfaces, and even with regular RS232 serial port. As an example my Korg synthesizer module supports standard 38400 serial port as MIDI interface. But if a game really needs the intelligent mode for something, that must be emulated separately somewhere then.

I have patched some games for my own projects. All IO accesses to sound card (Adlib or Gameblaster) were converted to software interrupts. Then before running the game a TSR can be installed. I used the system to forward register writes over serial port for logging register writes. But patching games is not exactly easy, except with the previously mentioned Sierra games where sound card access is separated into drivers and anyone can create a driver that does anything.

Would be nice if there was a pcb printer that was small enough and cheap enough for the average Joe. Interesting ideas though.

Been following this discussion with interest as I've recently written a TSR to emulate a subset of MPU-401 features:

Topic 35492

My take on the various options:

- Hardware: probably ideal as it would be independent of any software compatibility issues and could work on anything from an XT upwards. Cost of parts/ability to assemble may be an issue.

- Patching games: can be very simple if the game doesn't use many intelligent mode features and isn't compressed/encrypted. I looked at doing this for Wing Commander which has very simple MPU usage. However, the code dealing with MPU is compressed and unpacked at runtime making patching non-trivial.

- TSR: Port accesses can be trapped in protected mode on 386 and above and in real mode on Pentium and above (Pentium debug registers may be too slow however). I'm not aware of any games which require intelligent MPU and won't tolerate V86 protected mode. EMM386 provides a port trapping API which I use in my TSR.

As previously mentioned Dosbox provides a reference MPU implementation and works with Gateway etc. Dosbox also provides SYSEX throttling for MT-32 Rev.0 which could also be handled by a TSR.

If I can figure out how to emulate MPU interrupts (and get some time for non-work coding) it should be possible to support the Legend games with a TSR. I'm sure it can work as the old Virtual Sound Blaster TSR emulates both interrupts and DMA.

I intend to test as many games as I can find good copies of with this patch. See here for games that use Intelligent MPU-401. This looks to be the most brilliant work!

http://nerdlypleasures.blogspot.com/2012/04/u … me-support.html

What is the "Virtual Sound Blaster TSR"?

Virtual Sound Blaster emulates a Sound Blaster 1.0 and supports output to either PC Speaker or parallel port DAC. I found it quite unstable and because it predates the EMM386 port trap API, it only supports running in a custom protected mode (no EMS available) or under QEMM. It's a good reference though (comes with source).

http://cs.ozerki.net/zap/pub/vsb/