Ok. I do recommend, for older games, to set the FSB to 66 MHz, multiplier to 2x and disable all caches! CPU cache and internal cache.

Ideally though, a real 386 or 486DX would be better suited. There are games that will only sound correctly under these circumstances. Monkey Island is an example.

Just to avoid that you think it's the board when the issue lies elsewhere 😀

philscomputerlab wrote:

Ok. I do recommend, for older games, to set the FSB to 66 MHz, multiplier to 2x and disable all caches! CPU cache and internal cache.

Ideally though, a real 386 or 486DX would be better suited. There are games that will only sound correctly under these circumstances. Monkey Island is an example.

Just to avoid that you think it's the board when the issue lies elsewhere 😀

I might have to try that. Though, Monkey Island sounds fine on this machine when using a YMF719 card and SetMul to disable the cache. I did notice last night, Monkey Island didn't sound quite right with this board. Obviously there are still some issues to be worked out.

Monkey island does not have speed issues in music when you use a midi interface. It's the adlib and sb drivers that crap put. With my 200mmx build I can play MI without any slowdown needed when I use my mpu401at

philscomputerlab wrote:

I'd prefer this card to stay minimalistic / clean and do one purpose well. There are so many sound cards with wavetable headers. You can also get wavetable devices like this one: http://www.serdashop.com/MIDIBOARDCHILL

Also there are no LA synthesis wavetable modules, which this intelligent mode interface is really geared towards.

But that's just me.

Tend to agree. The main goal of this exercise is to produce an intelligent mode MPU-401 MIDI interface.
Once there is a final product, then one can always look at adding on other features in later revisions (or produce a "plus" version that has additonal features).

jesolo wrote:

philscomputerlab wrote:

I'd prefer this card to stay minimalistic / clean and do one purpose well. There are so many sound cards with wavetable headers. You can also get wavetable devices like this one: http://www.serdashop.com/MIDIBOARDCHILL

Also there are no LA synthesis wavetable modules, which this intelligent mode interface is really geared towards.

But that's just me.

Tend to agree. The main goal of this exercise is to produce an intelligent mode MPU-401 MIDI interface.
Once there is a final product, then one can always look at adding on other features in later revisions (or produce a "plus" version that has additonal features).

Understandable, and I agree. I was just asking what it would take to add it to this project, since the MPU401-AT is such a highly prized possession and is very scarce. But having another option for an MPU401 (no AT) is no small matter either. Having something inexpensive one can add an MT32, SC55, etc to for vintage setups is more than welcome.

Bring on the card. 😎

keropi wrote:

Monkey island does not have speed issues in music when you use a midi interface. It's the adlib and sb drivers that crap put. With my 200mmx build I can play MI without any slowdown needed when I use my mpu401at

Interesting. I had this issue a few times with instruments sounding off and putting the machine in "386 mode" usually fixes it. But because I work with so many different systems, please don't ask me what system I was using 😊

On my main SS7 machine I use a Pentium 200, but clocked at 100 MHz. I haven't found a MT-32 game that doesn't run on that machine. I'm using a Roland MIID interface though.

Fixed the issue by adding a buffer for outgoing MIDI data instead of blocking the entire program while a whole MIDI message is sent. Git has been updated. Silpheed, KQ4, KQ5, and Monkey Island all tested successfully. More testing later.

I'm taking a quick look at the code and you might want to change recv_isa_byte(). Unless the version in GitHub is outdated, you put sei() AFTER the return statement, so it will never be called.

alexanrs wrote:

I'm taking a quick look at the code and you might want to change recv_isa_byte(). Unless the version in GitHub is outdated, you put sei() AFTER the return statement, so it will never be called.

Wow. You're right. I had actually fixed that once, but reverted the changes trying to track down why KQ5 was broken. I bet that is why it got stuck in the reset state. Thanks for pointing that out.

Glad I could be helpful. I finished my quick read now and I didn't really find anything else wrong. I'm glad this project is evolving so fast and coming along so nicely =)

alexanrs wrote:

Glad I could be helpful. I finished my quick read now and I didn't really find anything else wrong. I'm glad this project is evolving so fast and coming along so nicely =)

Fixed and tested. Reset works correctly now.

Now I can start on the ability to enable and disable special features, as well as some code cleanup.

That's great news. There's plenty of space left for code in the 1284's memory, the current code compiles to just below 5kB, or 4% of the available flash memory.

I'm still waiting for parts to replicate it.

Update: There is now a DOS utility to enable and disable the special features like SysEx delay. Downloads are at https://github.com/ab0tj/HardMPU

SysEx delay, however, seems to be broken at the moment. When enabled it causes tons of errors on the MT32. More debugging to follow.

I have changed how SysEx delay is implemented, and it seems to work much better now. Games that make very large SysEx transfers don't work well with this, but they also don't seem to need the delay anyway. As always, more testing and debugging to come, but at this point it seems to be working fairly well.

For testing purposes, the most demanding games seem to be those that use interrupt-driven playback, e.g. Laser Squad, Gateway, Innocent Until Caught. If those work, everything should.

bjt wrote:

For testing purposes, the most demanding games seem to be those that use interrupt-driven playback, e.g. Laser Squad, Gateway, Innocent Until Caught. If those work, everything should.

I can attest to that.
When I tested my Voyetra V-22m MIDI interface on my 486DX4-100, all my intelligent mode games worked fine, except for Innocent Until Caught. I later realised it was a speed/hardware related issue, since the same card worked fine with this game in my 486DLC-40.

bjt wrote:

For testing purposes, the most demanding games seem to be those that use interrupt-driven playback, e.g. Laser Squad, Gateway, Innocent Until Caught. If those work, everything should.

It seems Gateway works - after re-enabling the ACK sent after switching to UART mode. But it sounds really bad. Back to debugging!

I should also mention that SoftMPU has an open issue with Gateway: https://github.com/bjt42/softmpu/issues/13
Hopefully it won't affect you, but something to be aware of.

bjt wrote:

I should also mention that SoftMPU has an open issue with Gateway: https://github.com/bjt42/softmpu/issues/13
Hopefully it won't affect you, but something to be aware of.

Thanks. This is where the position of the Version and ACK bytes get swapped, correct? I did actually implement this in my version as well, and it can be enabled and disabled with the config utility. I'm curious as to how you implemented enabling or disabling this, as I must have missed that part in the code somewhere.

At any rate, in my testing, the music has occasional stuck notes and sounds a little different every time I try it. I'll try and post a video later.

ab0tj wrote:

I'm curious as to how you implemented enabling or disabling this, as I must have missed that part in the code somewhere.

Nevermind on that part, found it. Looks like identifying the running app that way won't be a possibility with a hardware approach, so I'll just have to leave it to the user to enable/disable.