crazii
MPU-401 UART mode support
I added MPU-401 UART mode support that works in protected mode for Doom etc. You can use your Roland/Yamaha/... modules using a serial port.
The main patch/commit is here: https://github.com/jiyunomegami/SBEMU/commit/10f84fdba40470a996a712fd72dda73ca23ed7b5 Note that there is a minor error in the /MCOM usage message fixed in a later commit.
I posted a binary to vogons here: https://www.vogons.org/viewtopic.php?f=62&t=98071
Could this be merged into SBEMU as is or are there some changes that should be made? There is another option, /MDBG2 that changes the speed of the /DBG serial port from 9600 baud to 115200 baud. This is necessary to provide a hex dump of the MIDI data, since MIDI data is transmitted at 38400 baud.
A related question about serial ports: For /DBG and /MCOM, you can specify 1-4 for COM1-COM4, or 8-9 for D040-D050. D040 and D050 just happen to be where the two ports on my PCI serial IF card are mapped to.
Furthermore, you can specify an address, for example /MCOM3f8 will use COM1 and /COMd050 will use the port mapped to d050.
I didn't bother to check the provided address, so if you use /MCOM5 it will try to read and write from address 5 and address 6. Should the provided address be checked, or does it really matter?
It seems that modern platforms don't work with PCI devices mapped to "legacy addresses" under 1024, so some support for specifying an arbitrary address is needed.
When the specified value is not 1-4 or 8-9, would it be OK to check if the value is >= 1024 and an even number? I think 8: D040 and 9: D050 can be left in for convenience, since some drivers should allow mapping to arbitrary addresses.
Amazing addition! I've been hoping that this would be added to SBEMU in the short term. Thanks for helping out with this. :heart:
It seems that modern platforms don't work with PCI devices mapped to "legacy addresses" under 1024, so some support for specifying an arbitrary address is needed.
Correct. This is due to modern motherboards with PCI Express buses not supporting a certain feature called "subtractive decode" in their PCI-to-PCI bridges. This document on the Internet Archive provides some more information on that limitation.
One thing that would improve this is if you looked up the base addresses in the BIOS Data Area (BDA), instead of hard-coding them. That would also make it compatible with modern systems that have serial ports on PCIe expansion cards that don't have access to the <1024 legacy I/O addresses. (I don't think you can look up the IRQs through the BDA, but I believe you don't need the IRQs when you are only outputting data over the serial ports. Is that correct?)
I didn't bother to check the provided address, so if you use /MCOM5 it will try to read and write from address 5 and address 6. Should the provided address be checked, or does it really matter?
It doesn't matter, although performing checks will be better. I think if a user specify the address, he's aware what he's doing. except for some typos maybe.
One thing that would improve this is if you looked up the base addresses in the BIOS Data Area (BDA), instead of hard-coding them. That would also make it compatible with modern systems that have serial ports on PCIe expansion cards that don't have access to the <1024 legacy I/O addresses. (I don't think you can look up the IRQs through the BDA, but I believe you don't need the IRQs when you are only outputting data over the serial ports. Is that correct?)
Cool beans! This works in DOSBox and the two motherboards that I tested on. I added a /COML option to list the 4 COM ports in the BDA. It even works with my serial IF PCI card without needing to load the driver, on one motherboard at least. The IRQs are not needed. In my fork I disable serial interrupts.
@crazii is it OK to make a pull request?
Pull request #71 submitted.
It even works with my serial IF PCI card without needing to load the driver, on one motherboard at least.
Actually the driver was needed. It was being loaded from autoexec.bat. The driver sets the COM port address values in the BDA.
Impressive stuff! Is it possible to add USB serial support for netbooks without COM ports? I would love to hook my Acer Netboot a0751h to my mt32pi.
Regarding USB serial support, it is theoretically possible. If you have a Prolific USB serial controller, you can use the DOSUSB.COM driver from http://www.georgpotthast.de/usb/ Too bad that "DOSUSB is no longer free for personal use."
If DOSUSB.COM works, then use LISTDEVS.EXE to find the device address of the "USB-Serial Controller." Now I can use the provided example program examples/sample20/powerbas/SERIAL.EXE
I confirmed that the SERIAL.EXE program actually works. So it should be possible to use a Prolific USB serial controller, directly from SBEMU, or from another TSR serial driver that someone would have to create. The other day I made a "driver" inside SBEMU for some random PCIe serial card without DOS a driver, so I know it can be done.
EDIT: The downloadable demo of DOSUSB works, but it is time limited, it stops working after a few minutes.
There's CDC driver in USBDDOS which support serial protocol, but it needs extra work to install on dos .
- USBDOS works; but after output (00001820 03 F USB2.0-Ser!) it crashes as I am booting from USB Disk and usbdos does not seem to like that.
- Listdevs gives me a lot of numbers from 1 until 198 with no explanation How can I find out what the device address is?
USBDOS is something else. Now there are at least 3 projects: USBDOS, DOSUSB, and USBDDOS. I don't know much about DOSUSB, listdevs did the same thing here after I loaded the serdrv.sys driver. The serial.exe program doesn't need serdrv.sys. Anyways, I doubt DOSUSB will work for that system.
Your USB adapter is called "USB2.0-Ser!" ? I think the Linux driver is ch341. Do you know the USB vendor id and product id? Maybe it is 1a86:7523 ?
Can you try crazii's USBDDOS? In the USBDDOS README it says that USB boot disks are supported with the /disk parameter. Try this command: usbddosp /disk /hid
It should just skip your serial adapter.
USB devices are on usb bus and not directly managed by PCI bios, I don't think they have common IO adress. Only the USB host controller is directly on PCI bus and visible to the system. An serial USB driver may need trap the serial port like SBEMU does.
I think I'll wait for the USB midi driver ;-) @jiyunomegami Would it be relative simple to add UDP support? https://www.vogons.org/viewtopic.php?f=57&t=95102
This would enable to just hook up an ethernet cable between the dos computer and an mt32pi If I understand it correctly; it could work by calling an interrupt with the right buffer; no receive callbacks are needed if hardcoded these values:
- Source MAC to
- Source IP to
- Dest mac to ff:ff:ff:ff:ff:ff
- Dest ip to 255.255.255.255
Do you have a working packet driver for your netbook? Sometimes the drivers appear to work, but you can only send data (normally ARP packets) but not receive anything. In this case, those drivers might work since you are only sending data.
Your mt32pi has both an ethernet port and a serial port? I did get my Prolific pl2303 to output some data at 38400 baud using USBDDOS, so eventually I will try and make a driver for that.
Yes I have a working ODI driver for my NIC, using ODIPKT I can get Michael's mTCP stack working. But typically when booting over PXE would enable standard support for the universal PXE packet driver as well.
The interesting part is that for Midi we do not need to receive anything ;-) It's all fire and forget on ethernet frame level, provided if you spoof the source mac/ip and use broadcast to reach the mt32pi. Thus you could even re-use this with other mTCP applications.
mt32pi has an ethernet port and supports Midi over UTP: https://github.com/dwhinham/mt32-pi/wiki/Networking%3A-UDP-MIDI. I also have a serial cable connected to the mt32pi; as well as an USB midi cable. All work with my other motherboard on regular Midi or SoftMPU over serial. But my netbook has neither.
First I was trying to hack support into SoftMPU; but because it did not work together with VSHDA/SBEMU, and did not working with protected mode I added feature requests for both.
But with your excellent work it would be better to go this route ;-)
I'll await your progress on the pl2303.