VOGONS


IBM Music Feature Card/Yamaha FB-01

Topic actions

Reply 60 of 263, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

The new version is much easier to use because it sends the patch dumps correctly the first time. Also, loadfix fixes the Packed File Corrupt issue when running the Sierra install program.

Let me distinguish between two issues. First, the FB01.DRV is not sending percussion notes to the FB-01. It does sound different from the IMFC, and both Cloudschatze and I tested this on a real FB-01 connected to a real MPU-401 running on vintage systems. This isn't an issue with your work.

Second, even with dump/received, the notes the IMFC driver is playing are sometimes missing or incorrect. I wondered if this could be an issue with the USB to MIDI device rejecting what it may think are bad notes. The IMFC is very odd compared to General MIDI. I have attached the Raw MIDI output.

Attachments

  • Filename
    sciv_000.zip
    File size
    7.38 KiB
    Downloads
    118 downloads
    File license
    Fair use/fair dealing exception

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 61 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

The new version is much easier to use because it sends the patch dumps correctly the first time.

Ah good, so that was the SysEx buffer that was too small then, now fixed.

Great Hierophant wrote:

Let me distinguish between two issues. First, the FB01.DRV is not sending percussion notes to the FB-01. It does sound different from the IMFC, and both Cloudschatze and I tested this on a real FB-01 connected to a real MPU-401 running on vintage systems. This isn't an issue with your work.

So I take it that you now do get the percussion via the IMFC driver directly?

Great Hierophant wrote:

I wondered if this could be an issue with the USB to MIDI device rejecting what it may think are bad notes. The IMFC is very odd compared to General MIDI. I have attached the Raw MIDI output.

Hum... that might be...
If I listen to your earlier capture, a lot of the brass sounds in the beginning are missing.
However, if I play the MIDI dump you just made, the notes are clearly there.
This dump is made by a portion of DOSBox that sits 'after' my IMFC code, and is the same as used by the MPU-401 interface. So in other words: the data passed through my IMFC interface, and I handed it off to the internal DOSBox MIDI interface correctly, but it gets lost somewhere between there and the FB-01.
It could be the USB device.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 62 of 263, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
Scali wrote:
Great Hierophant wrote:

The new version is much easier to use because it sends the patch dumps correctly the first time.

Ah good, so that was the SysEx buffer that was too small then, now fixed.

With the IMF.DRV, you just get dump/received. With FB01.DRV, you get dump/error followed by dump/received. You have to run the game twice to get only dump/received. This is resolved by ripsaw8080's FB01.DRV.

Scali wrote:
Great Hierophant wrote:

Let me distinguish between two issues. First, the FB01.DRV is not sending percussion notes to the FB-01. It does sound different from the IMFC, and both Cloudschatze and I tested this on a real FB-01 connected to a real MPU-401 running on vintage systems. This isn't an issue with your work.

So I take it that you now do get the percussion via the IMFC driver directly?

On real hardware, yes.

Great Hierophant wrote:

I wondered if this could be an issue with the USB to MIDI device rejecting what it may think are bad notes. The IMFC is very odd compared to General MIDI. I have attached the Raw MIDI output.

Scali wrote:
Hum... that might be... If I listen to your earlier capture, a lot of the brass sounds in the beginning are missing. However, if […]
Show full quote

Hum... that might be...
If I listen to your earlier capture, a lot of the brass sounds in the beginning are missing.
However, if I play the MIDI dump you just made, the notes are clearly there.
This dump is made by a portion of DOSBox that sits 'after' my IMFC code, and is the same as used by the MPU-401 interface. So in other words: the data passed through my IMFC interface, and I handed it off to the internal DOSBox MIDI interface correctly, but it gets lost somewhere between there and the FB-01.
It could be the USB device.

I find it very odd that the FB01.DRV transmits data that my USB device has no problem with but the IMF.DRV causes my FB-01 to have issues beyond the failure to play the percussion data. When I take the raw dump and play it through a real MPU-401 through DOSMid, I get the same incorrect sound. I don't think its my USB device, (a Roland UM-1X).

I have attached a raw OPL dump of the FB01.DRV's output. Maybe that can help. Players don't like it at all, however.

Attachments

  • Filename
    sciv_001.zip
    File size
    9.98 KiB
    Downloads
    126 downloads
    File license
    Fair use/fair dealing exception

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 63 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

I find it very odd that the FB01.DRV transmits data that my USB device has no problem with but the IMF.DRV causes my FB-01 to have issues beyond the failure to play the percussion data.

Yes, I'm sending all data to the DOSBox MIDI handler as-is.
I can see two possible problems here:
1) I do not emulate the IMFC interface correctly, so sometimes I may send certain bytes that shouldn't be sent, or vice versa.
2) I shouldn't just send all data as-is, but perhaps I need to do some analysis/pre-processing on the data before sending it to the DOSBox MIDI handler, before things work correctly.

I would need some proper tooling to try and compare the two midi streams here...
Because if I understand correctly, the 'sciv_000.mid' capture above is with my IMFC emulation in DOSBox, and causes some wrong notes on the FB-01.
Listening to it again, I hear certain off-pitch notes. Initially I thought they may have been percussion notes, so the actual pitch is irrelevant... but it may actually be mangled notes trying to play a melody, as you describe.
And 'sciv_001.mid' capture is done with the MPU-401 emulation in DOSBox, using the FB-01 driver. Which sounds correct, except the percussion is missing for whatever reason.

Great Hierophant wrote:

When I take the raw dump and play it through a real MPU-401 through DOSMid, I get the same incorrect sound.

Yes, that seems to indicate that whatever mangling occurs, is already done before the data is captured.

Great Hierophant wrote:

I don't think its my USB device, (a Roland UM-1X).

Indeed, original Roland equipment is unlikely to be this faulty. Cheap Asian clone USB midi interfaces could be, but not Roland 😀

Great Hierophant wrote:

Players don't like it at all, however.

Yes, there seems to be a really long event at the start. That may indicate some corrupt data. Certain players can play it (like Falcosoft's player), but they think it's a really long song, so you have to skip to the end to hear the actual Larry theme.
Once you get there, it seems correct, however, at first glance.
So I need to find a way to somehow 'align' the two files, and see which notes they play. Some of the notes should be the same in both files, perhaps leading to some clues of what happens with the rest.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 64 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Scali wrote:

1) I do not emulate the IMFC interface correctly, so sometimes I may send certain bytes that shouldn't be sent, or vice versa.

I think this may be the problem...
As I extended the IMFC emulation, I accidentally broke the filter that should only output the MIDI data when you are sending in 'data mode', as opposed to 'command mode'.
I could actually hear the off-pitch notes via the Windows GM synth as well. And I could understand the FB-01 getting confused while receiving non-MIDI data.
Now that I fixed it, the off-pitch notes are gone. Hopefully it also works better on the FB-01 now.
Here's the updated version: https://www.dropbox.com/s/dlk84chf35jzr2m/DOS … oxIMFC.zip?dl=0

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 65 of 263, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

The latest version may have improved the music, but it is still not perfect. I don't hear the percussion sounds and the horns at the beginning are off.

Also, on the latest versions, I cannot hear any music unless I "initalize" the module by running the FB01.DRV before the IMF.DRV.

Perhaps it may be helpful to tackle the issue by adding the IMFC emulation code to the SoftMPU, then compiling it and it can be tested to run on a real MPU-401.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 66 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

Also, on the latest versions, I cannot hear any music unless I "initalize" the module by running the FB01.DRV before the IMF.DRV.

My guess is that this is related to the memory protection. The FB-01 driver may force it to off (that may be the code that ripsaw8080 patched? The code that is not present in the IMFC driver?), but the IMFC driver may not, because it can assume it's off by default.

Great Hierophant wrote:

Perhaps it may be helpful to tackle the issue by adding the IMFC emulation code to the SoftMPU, then compiling it and it can be tested to run on a real MPU-401.

Well, I can't build SoftMPU myself, because it relies on a toolchain I don't have.
I can give bjt or someone else who can build it the code for the IMFC emulation though.
I've attached the current super-simple quick-and-dirty code for DOSBox.

Attachments

  • Filename
    IMFC.cpp
    File size
    6.32 KiB
    Downloads
    111 downloads
    File license
    Fair use/fair dealing exception

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 67 of 263, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
Scali wrote:
Great Hierophant wrote:

Also, on the latest versions, I cannot hear any music unless I "initalize" the module by running the FB01.DRV before the IMF.DRV.

My guess is that this is related to the memory protection. The FB-01 driver may force it to off (that may be the code that ripsaw8080 patched? The code that is not present in the IMFC driver?), but the IMFC driver may not, because it can assume it's off by default.

The FB-01 defaults to Memory Protection On, but I make sure to manually turn it off before sending data to it. When data is sent, the FB-01's display shows dump/received!! for a good dump, dump/error for a bad dump and memory/protect if the memory protection is on. I see dump/received with the IMFC driver and your build.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 68 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

The FB-01 defaults to Memory Protection On, but I make sure to manually turn it off before sending data to it. When data is sent, the FB-01's display shows dump/received!! for a good dump, dump/error for a bad dump and memory/protect if the memory protection is on. I see dump/received with the IMFC driver and your build.

Okay, so there must be some other difference between the 'FB-01' on an IMFC and an external one in the way they initialize when they boot up.
The FB-01 driver probably sends some additional commands at initialization, which the IMFC driver does not, because they're not required.

I should be able to do MIDI dumps from both the MPU-401+FB-01 driver and the IMFC driver via DOSBox, and hopefully a comparison gives us some hints.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 69 of 263, by Scali

User metadata
Rank l33t
Rank
l33t

I've captured the MIDI data in three ways:
1) MPU-401 with the original FB01.DRV from Sierra
2) The 'ripsaw8080' FB01.DRV fix from here: *START HERE* SoftMPU 1.91 - Software Intelligent MPU-401 Emulator
3) IMFC.DRV

See attachment.
I've inspected them using Falco's MIDIEdit tool, which he kindly posted here: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
And I've found that the FB-01 driver indeed sends a few extra SysEx commands.
There are the 'fixed' commands that Cloudschatze explained earlier: *START HERE* SoftMPU 1.91 - Software Intelligent MPU-401 Emulator

F0 43 75 00 10 21 00 F7 - Turns memory-protect off
F0 43 75 00 10 20 00 F7 - Sets the system channel to 1

These are missing from IMFC, presumably because they are the defaults, but not on an FB-01.
Then both drivers send two SysEx messages of 6221 bytes, which would be custom voice data. I haven't inspected the actual messages yet, but for now, let's assume they're the same.
Then FB-01 does something else again.
It sends 4 SysEx messages of 7 bytes each, namely:
437500180101F7
437500190102F7
4375001A0103F7
4375001B0106F7
Followed by a 112 byte message, that I have yet to inspect.
The IMFC driver instead sends a single 168-byte SysEx message.

After these initial differences, both drivers send the exact same data for the remainder of the session, at first glance.
Oddly enough certain commands are sent twice back-to-back.
So, they play all the exact same notes on the exact same channels, with the same timing.
Since the percussion is missing when using the FB01.DRV from Sierra, apparently that driver is still broken, because the note data is there. The channel used for playing the percussion is just not set up correctly by the driver.

So I think the problem should be solvable by bringing the FB-01 into the exact same state as an IMFC on powerup. That could probably be done by sending the right SysEx commands before starting a game with IMFC. It looks like Sierra attempted this, but failed. Ripsaw8080's fix may have fixed something, but apparently not everything. The non-fixed driver seems to send a lot of garbage (mainly showing up as a lot of random note off-messages).
Perhaps there's a clue in the difference between the 112-byte vs the 168-byte SysEx message.

Attachments

  • Filename
    Larry3MID.zip
    File size
    23.37 KiB
    Downloads
    115 downloads
    File license
    Fair use/fair dealing exception

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 70 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
Scali wrote:
It sends 4 SysEx messages of 7 bytes each, namely: 437500180101F7 437500190102F7 4375001A0103F7 4375001B0106F7 […]
Show full quote

It sends 4 SysEx messages of 7 bytes each, namely:
437500180101F7
437500190102F7
4375001A0103F7
4375001B0106F7

These commands appear to be:
43h: Manufacturer ID
75h: Sub-status
00h: Node ID
18h: <00011iii> Instrument number
01h: <00pppppp> Parameter number
01h: <0ddddddd> Data
F7h: End-of-command

Parameter 01 is MIDI channel number
So apparently this is the mapping of instruments (0, 1, 2, 3) to MIDI channels (1, 2, 3, 6).
It seems incomplete (they are only mapping channels 1, 2, 3 and 6, while there are other channels also used in the MIDI data), which might explain why the percussion isn't working.
The IMFC technical reference documents a number of preset configuration data sets (Single, Mono 8, Dual and Split), where they all map instruments to various channels by default.
This might be a fundamental difference between FB-01 and IMFC at startup.
Either that, or one of the larger messages is a configuration update, and doesn't work correctly in FB01.DRV. So the mapping may be correct, but the configuration is not.
It seems that the configuration data itself contains the mapping of the instruments to channels as well, so it could be that these additional mapping commands actually mess up the mapping, which would otherwise have worked.

So that's my theory for now:
The IMFC driver might work correctly on the FB-01, but the FB-01 is not in the same state as the IMFC by default.
The IMFC doesn't modify the state, so things don't work on the FB-01.
The FB01.DRV will modify the state, but doesn't do so correctly (my current theory is that the 112-byte message is corrupt, it should be the 168-byte message, might be a similar bug to the one ripsaw8080 fixed. I will dump the raw messages and compare to the FB-01 docs to see. At first glance I saw a message with 160-byte payload, which would be 168 in total I guess, but nothing I could match to 112 bytes). So when running the game with FB01.DRV, some sounds are missing.
When running via IMFC.DRV afterward, some of the faulty FB01.DRV configuration 'stuck', so you now hear stuff from the FB-01, but it is still not initialized correctly.

Assuming this is what is happening, then the correct procedure would be to avoid the FB01.DRV like the plague, and instead shoot some SysEx commands into the FB-01 in advance, to bring it into the same configuration as an IMFC on powerup.
After that, run the game with IMFC.DRV, and it should work 100%.

My guess for the commands to send would be the initial two commands the FB01.DRV sends, possibly followed by the selection of a specific configuration:
F0 43 75 00 10 20 00 F7 - Sets the node number to #0 (default on IMFC, all commands are sent to node #0) <-- I'm not sure if this works actually, since the command itself is sent to a node#..., so perhaps you need to send it to all possible node # to make sure you force the device to node 0, from whatever node it is currently listening to:
F0 43 75 nn 10 20 00 F7 for all nn in the range 00-0F. Might be easier to just set node #0 via the frontpanel?

F0 43 75 00 10 21 00 F7 - Turns memory-protect off (default on IMFC)
F0 43 75 00 10 22 nn F7 - Select configuration #nn (IMFC powers up to 'Single' configuration, value 16, so that would be nn == 10h. I believe it actually comes up as 17 on the FB-01 display, since it seems to count the configurations as 1-based rather than 0-based)

I suppose if you were to just dial this in via the frontpanel, it would also work.

Last edited by Scali on 2017-03-21, 14:35. Edited 3 times in total.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 71 of 263, by Scali

User metadata
Rank l33t
Rank
l33t

The plot thickens...
I found that when the Larry 3 theme 'switches' from the intro to the main theme, IMFC.DRV sends another SysEx of 170 bytes, and one of 7 bytes.
At the same place, FB01.DRV (the 'fixed' version by ripsaw8080) instead sends a whole bunch of SysEx commands...
First 7 SysEx commands of 7 bytes each, then one of 142 bytes, and finally one of 7 bytes again.
Prior to these SysEx commands, there's a bunch of weird channel/key aftertouch events, which are not present in the IMFC data.
Something tells me the FB-01 driver messes up SysEx commands royally.
After these differences, both drivers again output the exact same note data on the exact same channels.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 72 of 263, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Scali wrote:

Ripsaw8080's fix may have fixed something, but apparently not everything.

Fixed were two instances of sysex data read with DI+offset in a loop and neglecting to initialize DI to zero, which caused a large amount of junk to be written as MIDI data before DI finally wrapped around. I checked that other instances of DI+offset, SI+offset, and BX+offset don't make the same mistake. In any case, I assure you that no attempt was made to fix anything that was not reported as a problem, such as a missing percussion track. 😉

Reply 73 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

Fixed were two instances of sysex data read with DI+offset in a loop and neglecting to initialize DI to zero, which caused a large amount of junk to be written as MIDI data before DI finally wrapped around. I checked that other instances of DI+offset, SI+offset, and BX+offset don't make the same mistake. In any case, I assure you that no attempt was made to fix anything that was not reported as a problem, such as a missing percussion track. 😉

I wasn't criticizing your work... more surprised at the state of the driver that Sierra released.
Looks like I'll actually have to reverse-engineer the SysEx commands to see what it's trying to do.
It would sure help if I had some real hardware myself 😀

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 74 of 263, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

The genuine Sierra FB01.DRV does not send a Sysex command to turn the memory protection off. The install program tells you to do this manually. I believe this was intentional to avoid irritating musicians by automatically overriding the patch bank memory when they started a game.

The FB-01's defaults to the single configuration and sets the system channel to #1. I believe the latter is Yamaha's way of referring to what IBM calls setting the node to #0.

Last edited by Great Hierophant on 2017-05-07, 20:04. Edited 1 time in total.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 75 of 263, by lchiocca

User metadata
Rank Newbie
Rank
Newbie
Scali wrote:
I wasn't criticizing your work... more surprised at the state of the driver that Sierra released. Looks like I'll actually have […]
Show full quote
ripsaw8080 wrote:

Fixed were two instances of sysex data read with DI+offset in a loop and neglecting to initialize DI to zero, which caused a large amount of junk to be written as MIDI data before DI finally wrapped around. I checked that other instances of DI+offset, SI+offset, and BX+offset don't make the same mistake. In any case, I assure you that no attempt was made to fix anything that was not reported as a problem, such as a missing percussion track. 😉

I wasn't criticizing your work... more surprised at the state of the driver that Sierra released.
Looks like I'll actually have to reverse-engineer the SysEx commands to see what it's trying to do.
It would sure help if I had some real hardware myself 😀

I still have my old IMF card. But I don't have an ISA slot anymore. I could send you the card if you wish

And the technical reference manual that I scanned like years ago can be found here: http://www.symphoniae.com/soundcard/Yamaha/IM … alReference.pdf

Reply 76 of 263, by Scali

User metadata
Rank l33t
Rank
l33t
lchiocca wrote:

I still have my old IMF card. But I don't have an ISA slot anymore. I could send you the card if you wish

Ooh yes, that would be awesome!
These cards are impossible to find on Ebay or such, it seems.
Send me a PM plz, so we can discuss the details 😀

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 77 of 263, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
lchiocca wrote:

And the technical reference manual that I scanned like years ago can be found here: http://www.symphoniae.com/soundcard/Yamaha/IM … alReference.pdf

Ah, I figured it was Cloudschatze. Thanks for that.

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 79 of 263, by Scali

User metadata
Rank l33t
Rank
l33t

Some update:
Hierophant, Cloudschatze and myself have been experimenting with MIDI captures from Sierra games, dissecting dumps from both units, and working through the documentation, and we have figured out a significant difference between the IMFC and the FB-01:
The IMFC supports a "Parameter list" SysEx command, F0 43 75 71, which is not supported by the FB-01.
The FB-01 has a similar "Event list" command, and Sierra tried to convert to this command type in their FB-01 driver.
This is where they went wrong: the Event list can change parameters of instruments by addressing them via the MIDI channel. Parameter list works directly on the instruments themselves.
The problem here is that the mapping between MIDI channels and instruments is not necessarily 1:1.
This also explains why the drums aren't working on an FB-01: The MIDI channel is also used by another instrument.

Based on this info, I added a translation function in my IMFC code, so it now translates to FB-01 compatible SysEx commands (without the bugs that are in the Sierra games).
This seems to work on a real FB-01.
Current in-progress version of DOSBox-X with the IMFC emulation can be downloaded here: https://www.dropbox.com/s/dlk84chf35jzr2m/DOS … oxIMFC.zip?dl=0

Next step will be to try and get an FB-01 emulator working, so that eventually, a physical FB-01 is no longer required for IMFC emulation.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/