Re: io port 0x80 - usage for debugging during OS development
Posted: Thu Mar 26, 2026 6:37 am
Hello, standard COM1 port works but has its own 9-pin header. You can connect null modem cable to another machine with serial port.
You need TTL-USB adapter to obtain data from Debug UART (2 pins from 5-pin connector on motherboard). You can write to the port by "out al,0x80" or "mov dx,0x80 \ out dx,al" and you obtain the data at another machine using TTL. If you write too fast only first byte is transmitted and the rest is lost. There is no way of synchronizing / waiting whether you can transmit more bytes. On standard COM port you can check whether it is ready to transmit or receive another byte.
These 2 ports are separated from each other.
I need the ioport 0x80 because OS takes ownership of standard COM1 port and then I'm unable to use it anymore. OS seems to reprogram it in some way that then access at 0x3F8 which worked at UEFI and boot stage stops to work when OS is running. But the ioport 0x80 still works when OS running and OS does not touch it. Under running OS you can use COM1 by calling OS system procedures, not by reading/writing 0x3F8 anymore.
You need TTL-USB adapter to obtain data from Debug UART (2 pins from 5-pin connector on motherboard). You can write to the port by "out al,0x80" or "mov dx,0x80 \ out dx,al" and you obtain the data at another machine using TTL. If you write too fast only first byte is transmitted and the rest is lost. There is no way of synchronizing / waiting whether you can transmit more bytes. On standard COM port you can check whether it is ready to transmit or receive another byte.
These 2 ports are separated from each other.
I need the ioport 0x80 because OS takes ownership of standard COM1 port and then I'm unable to use it anymore. OS seems to reprogram it in some way that then access at 0x3F8 which worked at UEFI and boot stage stops to work when OS is running. But the ioport 0x80 still works when OS running and OS does not touch it. Under running OS you can use COM1 by calling OS system procedures, not by reading/writing 0x3F8 anymore.