[Solved] Win98 VBox failing to see COM port

[irishlazz]

Hi, newbie here. I've got a Win98 VB on a Win10 host. Trying to run and "antique" piece of equipment in my lab for which newer software is not available. So far I have the Win98 VB running smoothly, and the software is loaded and also running.

The next big hurdle is getting the Win98 box to see the COM port that the equipment is plugged in to. In Device Mgr there are no COM/Ports listed at all. (attachment) Any thoughts?

[mpack]

Use "Add new hardware" in the Win98 control panel, after you've added the serial ports in the VM settings.

p.s. I suggest that in future you use "Windows Snipping Tool" to capture screenshots in PNG format. Floyd-Steinberg dithering was brilliant in its day, but that day was over at least twenty years ago!

[irishlazz]

mpack - I did use snip, but by pasting 3 into one it made for a file too large for upload.

So I installed the com in win98. It gave the "this isn't the right/best driver, are you sure" warning but installed. It starts at com5 and my ancient software is looking for com1 or com2. I've tried to force it, but it won't accept either the com1 or 2 I/O range. More thoughts?

com 01.PNG (26.9 KiB) Viewed 3229 times

[mpack]

Why are you trying to configure a COM5 inside the guest? Win98SE has no idea how to handle a COM5. You can't possibly have found that using "Add new hardware".

It should be COM1, which has well known I/O and IRQ assignments.

[irishlazz]

**The win98 VM didn't find a COM, it found a "PCI Device" that I assume must be the COM. So I complete the install as a COM and IT (not me) assigns it COM5. I've removed and retried it a few times.**

The ABOVE was from the boot-up plug-n-play detection. I ignored that and did a manual ADD and it installed as COM1 (hooray!!)

Sadly I am not getting a successful communication with the instrument. If you have any additional hints I'll be happy to try them, but at this point I'm thinking my next issue is the old software.

err.PNG (3.77 KiB) Viewed 3222 times

Thanks for getting me this far!!

[mpack]

The win98 VM didn't find a COM, it found a "PCI Device" that I assume must be the COM.

The unknown PCI device is not the UART. Win98 always sees an unknown PCI device for some reason, but that can't be the serial port because the latter is not a PCI device - the virtual UART is on the virtual motherboard with direct connections to the virtual CPU and virtual interrupt controller. It isn't on a plug-in PCI card.

Time for a VM log file I think. With the VM fully shut down, right click and "Show Log" in the GUI, save "VBox.log" (no other file) to a zip, and attach the zip here.

Include the <vmname>".vbox" file in the zip (can't see a ".vbox" file? turn off the "hide extensions of known file types" feature in Windows Explorer).

[irishlazz]

The VBox log and the Win98se.vbox in attached zip as requested. As edited above, I ignored the detected PCI and got COM1 appearing now. Just no communication with the rheometer as yet.

[mpack]

In the VM settings, the host "Path/Address" should be "COM1:" (note the colon), and the "Port Mode" should be "Host Device", not "Host Pipe" (you are not configuring a software pipe).

Also make sure that nothing in the host is opening the port, as RS232 ports are legacy devices and cannot be shared.

[irishlazz]

We have some glitches to work out, but we are in business!!

thx.PNG (88.84 KiB) Viewed 3217 times

[mpack]

If "glitches" refers to comms glitches then it usually means that you need to reduce the baud rate. Serial UARTs have a really inefficient design by modern standards, so you can't assume that 115,200 bps is no problem for a modern PC, especially when the PC is a simulation. That data is passing through a simulated UART, so it can still involve a significant overhead (thousands of simulated interrupts per second, x2 if it's a full duplex connection).

One trick you can use with any baud rate is to configure the transmit side for 2 stop bits. A stop bit is not actually transmitted, it just means to delay for N bit times, so setting 2 stop bits in the transmit side just tells the transmitter to insert an extra one-bit delay between characters, which is often enough to give the receiver time to consume the data without taking the more drastic step of cutting the baud rate in half (PCs don't have a lot of granularity in available baud rates).

I'll mark the topic as solved.

[irishlazz]

Brilliant! I really appreciate how educational your responses are. Thanks again.