DOSBox does not emulate midi in.

Would be a nice addition, although I don't see it as being much of a priority (unfortunately) due to DOSBox's focus on games.

I know that there are people who would probably also like MIDI-IN support for use with MOD trackers.

Okay, that's great to know that nothing is wrong or broken, although a bit disapointing at the same time. I'll definitely try SBTIMBRE on a real PC next.

However, it would be interesting for me to see how the output is done, and maybe try to contribute to DosBox by coding the Midi IN to work. I'm quite good at DOS/C/x86asm/embedded stuff, but I regard my Win32/POSIX skills poor. This would be a great chance to learn.

Any suggestions how to proceed from here? Download the CVS repository and find some tools to compile DosBox? Are the required tools listed in a FAQ somewhere? Can I use OSS software (like GCC with Dev-C++ IDE) to compile it, or do I need some proprietary tools like a Borland Windows compiler to compile DosBox for the Win32 platform?

DOSBox can be compiled with mingw on win32 platform. See the wiki. MIDI IN would probably require an implementation for each platform dosbox supports, see the src/gui/midi_*.h how output is done. This is for the host part...from the dosbox side you'll probably need to modify src/hardware/mpu401.cpp and have some knowledge of the midi messages 😀

GCC will compile it fine
just use mingw (or get dev c++ to executate purely make)
and you can use any editor you want

a good starting place would be
dosbox/src/gui/midi.cpp (and other files in that directory)
and maybe dosbox/src/hardware/mpu401.cpp <- beware complex stuff)

Be sure to work against the latest cvs. as both files have changed since the latest release of dosbox.

Alright, some progress already. Downloaded the CVS snapshot, took a brief look at the mpu-401 code and the midi header for win32 platform. My first thought was "Oh my goodness, there's code in .h files!". But in this case I also understand why..

I remember trying to use midi ports in windows before, but a couple of months back I couldn't get Dev-C++ linking in the library that has midi functions, because I had no idea what it was. So now I know, it's libwinmm.a. And the mmsystem.h is NOT included in windows.h by default (like in some Microsoft compiler perhaps), it had to be included manually.

So at this point, I have a program which opens midi output and input ports, sends reset to output (I have not verified this, but the midi adapter transmit led blinks on my self-made adapter), and also prints out any received midi data to console when I press the keys on my midi keyboard. The data on screen looks exactly like it should be, I know my keyboard sends the 0xEF keepalive, and I recognize the note on, controller change and pitch bend wheel events too. I think windows might truncate the 14-bit bend event to 7-bit one, but then again, my keyboard is pretty old (has MC68HC11 MCU inside), so it might send only 7 MSB:s in the 14-bit message.

Man, I never knew emulators could be so much fun :) It's funny to make code to emulate a piece of real hardware which you have used with assembler around ten years ago.. I wish I had time to make a hardware OPL3 emulator with a FPGA :) Talk about nostalgy..

You might also want to consider registering in the forum...if you contribute your code so we know who to credit 😁

Alright, I finally signed in.

I suppose this is out of topic now, so do say if we should continue in another forum than DosBox General.

I've gotten this far:

0) For now, I'll settle with the UART mode of MPU-401, because I am not familiar with the Intelligent mode at all, and won't even think about SysEx commands until later.

1) The win32 specific midi stuff needs modifications to be able to receive midi data. Data is received one command (not byte) at a time with a (static) callback function, which is specified when opening the Midi input device. This data should propably be saved in a circular receive buffer or something for later retrieval.

2) Some periodically run function in mpu-401 module (MPU401_Event ?? ) should check if there is data in the receive buffer. If there is data, update the status read port value and raise the MPU-401 IRQ pending flag somehow so an IRQ is generated to the emulated software.

3) Data is then read by reading the MPU401 data port, and circular buffer is advanced to next byte. At this point I have no idea when or in what function to generate another data available interrupt if there is more data, maybe in MPU401_read_data?

Any comments on that?

Does anyone now if there's a html version of the Gravis Ultrasound HelpPC helpkit available? It had marvellous info about the GUS MPU-compatible port.. But I think I can get enough info from this link: http://www.borg.com/~jglatt/tech/mpu.htm

beware of point 2
harekiet and I dislike regular timers very much. (it depends offcourse on how often you want it called), but high resolution timers are bad in our opinion.

you might want to consider raising the irq on first data in and forget about a regular timer.

Hmm, you're right, that's how it should be done. I was under the impression it was mpu401_event() function's responsibility to check if it should raise the IRQ.

So the best would propably to keep the rx buffer in mpu401, and have a exported member function which adds data one byte at a time in the buffer and is then responsible for raising the IRQ and setting the mpu401 interrupt flag. Say, mpu401::insert_to_rx_buffer(byte data) or something.

Then in midi_win32 receive callback, just calls the mpu401::insert_to_rx_buffer() one to three times, depending on how many data bytes the received midi event has. I remember there already is a table defined in the midi sources how many bytes a midi command has, so this is no problem. Except when multiple midi messages with same command byte are shortened to include only the first command byte.

Problem is that then the midi class should be able to use MPU401 class and vice versa, for data storing or at least IRQ raising. I know it can be done, but is that OK? I hate when two classes depend on each other, chicken and egg problem..

And if done the other way, say, the midi_win32 module keeps the receive buffer, how on earth the MPU401 would be able to poll that buffer then..

MPU401_Event is used only for playback in intelligent mode which requires timer.
For UART mode input is as simple as calling MPU401_Queuebyte(your midi byte). it will put it in circular buffer, raise IRQ (irq only in case dosbox is set to intelligent=true) and set status bit . So you may want to have your win32 midi callback directly call queuebyte function (or perhaps another function that will check if UART mode is on, etc.).