Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPU-401 UART mode support #67

Open
jiyunomegami opened this issue Jan 8, 2024 · 15 comments
Open

MPU-401 UART mode support #67

jiyunomegami opened this issue Jan 8, 2024 · 15 comments

Comments

@jiyunomegami
Copy link
Contributor

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:
jiyunomegami@10f84fd
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.

@volkertb
Copy link
Collaborator

volkertb commented Jan 8, 2024

Amazing addition! I've been hoping that this would be added to SBEMU in the short term. Thanks for helping out with this. ❤️

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?)

@crazii
Copy link
Owner

crazii commented Jan 8, 2024

Cool, I'll check it out in no time

@crazii
Copy link
Owner

crazii commented Jan 8, 2024

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.

@jiyunomegami
Copy link
Contributor Author

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?

@crazii
Copy link
Owner

crazii commented Jan 11, 2024

Yes.
Since the address is obtained from BDA, I believe it OK now.

@jiyunomegami
Copy link
Contributor Author

jiyunomegami commented Jan 13, 2024

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.

@hjnijlunsing
Copy link

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.

@jiyunomegami
Copy link
Contributor Author

jiyunomegami commented Jan 13, 2024

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.

@crazii
Copy link
Owner

crazii commented Jan 13, 2024

There's CDC driver in USBDDOS which support serial protocol, but it needs extra work to install on dos .

@hjnijlunsing
Copy link

hjnijlunsing commented Jan 14, 2024

  • 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?

@jiyunomegami
Copy link
Contributor Author

jiyunomegami commented Jan 14, 2024

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.

@crazii
Copy link
Owner

crazii commented Jan 14, 2024

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.

@hjnijlunsing
Copy link

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

@jiyunomegami
Copy link
Contributor Author

jiyunomegami commented Jan 15, 2024

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.

@hjnijlunsing
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants