VOGONS

Common searches


Reply 220 of 419, by carlostex

User metadata
Rank l33t
Rank
l33t
bjt wrote:
Can anyone explain the meaning of the FB-01 messages? […]
Show full quote

Can anyone explain the meaning of the FB-01 messages?

DUMP - receiving instrument sysex
ERROR - sysex was malformed
RECIEVED - sysex was OK

Is DUMP always followed by ERROR or RECEIVED?

As far as i know yes, but my experience with the FB-01 is rather short and limited.

I don't know if this will help but try it:
http://soundprogramming.net/manuals/Yamaha_FB-01_Manual.pdf

Reply 221 of 419, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
bjt wrote:
Can anyone explain the meaning of the FB-01 messages? […]
Show full quote

Can anyone explain the meaning of the FB-01 messages?

DUMP - receiving instrument sysex
ERROR - sysex was malformed
RECIEVED - sysex was OK

Is DUMP always followed by ERROR or RECEIVED?

As far as I know, that is correct. I just tested my device on my 486 and all it shows is dump/received.

The FB-01 needs to receive two sets of 6,144 bytes, which correspond to its two RAM instrument banks. The other five banks are ROM banks, so any error may not be sound immediately apparent.

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

Reply 222 of 419, by bjt

User metadata
Rank Oldbie
Rank
Oldbie

OK. Difficult for me to test this without an FB-01 so I will have to ask for help from both of you.

I've captured the two large sysex messages sent to the MIDI interface from the game using Bochs. The data was the same on the first and second runs. The two large messages are sent consecutively.

Could you try sending each of these to your FB-01 and see if they work OK please.

The next step is to capture the data sent by SoftMPU, I plan to use the serial output feature for this. Cheers 😎

Reply 223 of 419, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

First of all, thank-you for the prior response to my question about SoftMPU's use of buffering, bjt. I'm still wondering if it might be worth implementing a switch to bypass the customized SysEx buffering/handling, and treat it the same as "normal" MIDI data.

An FB-01 really shouldn't be necessary for testing. If the SysEx output from either DOSBox or SoftMPU can be made to match the "QG1MPU.txt" output from an MPU-401 that I provided back in 2008, then the FB-01 will work correctly.

IBM Music Feature Card/Yamaha FB-01

I've been hard-pressed for time this week, but plan to do some testing/capturing of my own with the latest version of SoftMPU this weekend.

Reply 225 of 419, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
bjt wrote:
OK. Difficult for me to test this without an FB-01 so I will have to ask for help from both of you. […]
Show full quote

OK. Difficult for me to test this without an FB-01 so I will have to ask for help from both of you.

I've captured the two large sysex messages sent to the MIDI interface from the game using Bochs. The data was the same on the first and second runs. The two large messages are sent consecutively.

Could you try sending each of these to your FB-01 and see if they work OK please.

The next step is to capture the data sent by SoftMPU, I plan to use the serial output feature for this. Cheers 😎

Both show dump/error !!!. I anticipated that they would, as a good sysex dump should be 6,363 bytes (including the MIDI messages to put the data back) or 6,144 (raw patch bank data only).

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

Reply 226 of 419, by carlostex

User metadata
Rank l33t
Rank
l33t

And on another news i'd put my absolute trust that Cloudschatze is right, in fact his QG1MPU.syx message yields a dump/received message.

EDIT: Sorry for testing Eric i'd should have put my faith in you right away, indeed there was no need to test!!!! 😁

Reply 227 of 419, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

IIRC, the first time the FB01.DRV driver sends the patch banks there is an error, but subsequently (run the game again in the same session) there is no error. The two large sysex messages containing the patch banks are identical each time, and match Cloudschatze's dumps exactly, which implicates preceding messages.

There is indeed a difference in the preceding messages between the first and subsequent runs.

First run:
F0 43 75 00 00 01 00 F7
F0 F7

Subsequent run:
F0 20 F7
F0 00 F7
F0 F7

The 2-3 byte messages appear malformed and may simply be ignored. The first message of the first run is suspect because it does identify as a Yamaha FB-01 message, but I'm unable to determine its purpose from the data here.

To test the theory that this unknown message is causing the error, I've attached a .syx file that prepends the message to the known-good messages for the patch banks. If it turns out that the message is responsible for the error then perhaps there is a MPU-401 compatibility issue in the emulation that causes it. If it's not the message itself that's an issue then perhaps there is an element of timing, although I believe that delaysysex has been tried.

Attachments

  • Filename
    fb01test.zip
    File size
    2.47 KiB
    Downloads
    179 downloads
    File license
    Fair use/fair dealing exception

Reply 228 of 419, by bjt

User metadata
Rank Oldbie
Rank
Oldbie

Not sure what was up with my Bochs captures. Will take some using serial capture.

Ripsaw - thanks for looking at this. Will be interesting to see if the preceding messages have an effect.

Reply 230 of 419, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I suppose the dump/error is on the first patch bank, and the dump/received on the second. So it seems the error is caused by the preceding message, at least in part. Sending the preceding message by itself and then waiting awhile before sending the patch banks would test whether or not a delay is needed.

I still haven't been able to conclusively determine the purpose of the preceding message, but it may be some sort of reset or clearing of parameters. I found the preceding message's sequence of bytes stored in FB01.DRV along with other messages, so the driver is apparently desgined to send it, and the reason it is sent initially but not subsequently may be the root cause of the issue.

Reply 231 of 419, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

The "F0 43 75 00 00 01 00 F7" message corresponds to the FB-01's, "current configuration buffer." It looks like Sierra simply dumped the parameters/banks from whatever FB-01 they were working with, and the games simply re-send some of that data via the FB-01 driver and respective patch files.

As mentioned, these "preceding" messages that show-up in the DOSBox/SoftMPU output aren't sent to the FB-01 when using an actual MPU-401 or variant. The MPU might simply drop them for some reason, whereas DOSBox/SoftMPU at least try to send something. Removing the extraneous SysEx strings from FB01.DRV might be an option, in lieu of fixing the emulation, but will require something more than just deleting the relevant bytes.

Reply 232 of 419, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Cloudschatze wrote:

In addition, it hasn't been determined why, with DOSBox or SoftMPU, starting the game a second time results in both voice banks transferring successfully. It seems like that should be a clue.

I think it has been determined. Again, the difference is that the the driver sends the preceding message in question the first time, and subsequently it does not. What hasn't been determined is WHY the driver decides to send the preceding message.

Cloudschatze wrote:

The behavior of the FB-01 driver shouldn't change in successive attempts (nor would that makes sense)

It does make sense if the driver's behavior for sending the preceding message is based on something regarding the state of the system, most probably the MPU-401's state.

What does the "current configuration buffer" message actually do? Understanding that may help to figure out why the driver decides it needs to send this message.

Reply 233 of 419, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

What does the "current configuration buffer" message actually do? Understanding that may help to figure out why the driver decides it needs to send this message.

The FB-01 has a number of configuration memory presets, each comprised of settings for voice allocation, MIDI channel mappings, note limits, output level, tuning, etc. (comparable to what is defined as a "patch" for the MT-32).

That particular SysEx string would be used to modify the current (active) configuration. As defined in both the driver, and in the DOSBox/SoftMPU output, it seems to be missing the data bytes that would actually change anything though.

Reply 234 of 419, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There is an obvious bug in FB01.DRV where bad pointers are used to write sysex data, causing a fairly large amount of memory contents to be written to the MPU-401. The MIDI processing in DOSBox (and SoftMPU by extension, I guess) tries to weed through all of it for something meaningful, but I don't know how a real MPU-401 would react. However, the contents of memory change from one execution of the game to another, so the behavior is arbitrary in any case.

It appears the intention of the driver author was to send the following two sysex messages before the patch bank sysex messages:

F0 43 75 00 10 21 00 F7
F0 43 75 00 10 20 00 F7

I'm not sure what these messages do, but they're probably some kind of init or reset. I've attached a modified driver file that should correctly send the preceding messages on any system.

Attachments

  • Filename
    fb01fix.zip
    File size
    1.73 KiB
    Downloads
    363 downloads
    File license
    Fair use/fair dealing exception

Reply 235 of 419, by carlostex

User metadata
Rank l33t
Rank
l33t

Hmmm, i'm curious about the driver changes... How could you edit the driver? You mentioned bad pointers... Are we talking about C or C++ pointers? If so how did you access the source code?

Reply 236 of 419, by truth_deleted

User metadata

Presumably, it's by disassembling the binary: http://stackoverflow.com/questions/23084560/t … sassembled-code. That and ripsaw is obviously genius/fluent at reading it (and then proposing a workaround or fix by editing the machine code in the binary). If this is correct, then he may also have knowledge of "markers" in the assembly code which indicate various cpu tasks (could be somewhat confirmed by comparing different drivers and their code).

Reply 238 of 419, by keropi

User metadata
Rank l33t++
Rank
l33t++

my friends, it's ripsaw8080 we are talking about here... his skills are legendary , it comes to no surprise at all he made sense of the driver and made a patch 😀

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 239 of 419, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

I'm not sure what these messages do, but they're probably some kind of init or reset. I've attached a modified driver file that should correctly send the preceding messages on any system.

The modified driver works. Bravo!

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

Turning the memory protection off has always been a necessary, manual process heretofore, and while Sierra might have intended it to be automatic, it looks like it took your fixed driver to make that a reality. Bravissimo!