> The thing that still befuddles me is how to get the COM ports to work, for some reason they really don't emulate those well in either one of those.
What are you having trouble with for COM ports? Checking status (port + 5) and interrupt identification (port + 2) might help if you're missing interrupts?
It goes further than that: it doesn't work at all. I know quite well how to deal with hardware com ports (I've built firmware for port concentrators), it's just that the emulations do not expose working endpoints and that makes it really hard to get this going.
Qemu and Virtualbox both supply similar mechanisms that should expose the com port but I've yet to be able to input or output a single byte through an emulated com port on either. What I'll probably end up doing is first to get a hardware pass through to work and once that is reliable to move back to emulated hardware to see if there are any differences. It's funny, I expected this to be one of the easier devices but so far it has not yielded at all.
Hmmmm. I can attest to qemu com ports working for my hobby OS, which does work on hardware com ports as well. For qemu, I use the com port as the primary console. But, I just assume there's a comport at 0x3f8, I don't do detection.
I don't remember if I got virtualbox com ports to work, I had a lot of trouble with virtualbox and decided it wasn't on my support list.
This is output only, but if you don't have a better way to test if qemu comport works, you can run my kernel with
You should get a bunch of useless debug output, but it came through the com1. If that's helpful, the relevant code is more or less here https://github.com/russor/crazierl/blob/4e41bfa5c5bbae078a57... (init starts here, writing characters a smidge later on line 324)
What are you having trouble with for COM ports? Checking status (port + 5) and interrupt identification (port + 2) might help if you're missing interrupts?