Dear Matt, first and foremost, thumbs up for approaching the problem with an oscilloscope. This is the right tool for the job.
Mr. Bret Johnson (himself a programming wizard/veteran) has already provided a super-gentle debugging intro... If I remember correctly, the DOS and BIOS services that work with COM ports (serial UART's) are rather starved of sorely needed features, and so is possibly the stock "driver" towards the hardware. Not sure if flow control and other things can be configured in bare DOS. From my modest programming attempts towards serial UART's in DOS, I recall that the safest way has always been: talk to the UART directly, if you know what you're doing... Back in the day, I was a fond user of JCOM the terminal emulator: http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/serial/jcom174d .zip JCOM has its own routines for talking to the UART hardware and can do "hardware flow control" via RTS+CTS - and can be configured to work with no flow control, which is probably what you want for a basic "signs of life" check. The trick in DEBUG.EXE that Mr. Johnson has mentioned, relies on the BIOS presenting the venerable "equipment table" at a well-known address in the system RAM - not sure how reliable that is, nowadays. In modern PC's, e.g. Linux probably gets to know about COM ports from ACPI tables (or earlier via PnP BIOS calls). Not something you would easily reach via DEBUG.EXE :-) BTW if you can boot some Linux live distro and type "dmesg | less" at the command line, you should find some messages about UART's being detected. That said, modern BIOSes typically have a pretty good information in the human-facing SETUP menu, about where the COM ports are located. (Conveniently, the fact that you can boot DOS means to me that you're not facing pure UEFI :-) In DEBUG.EXE, I wouldn't be ashamed to try some o 3f8 00 i 3f8 ...but other registers might come in handy too. Note that the basic 16C550A UART (or compatible) does not directly respect the CTS signal in hardware - rather, the "hardware flow control" is actually handled by a software routine watching the CTS input flag in the Modem Status Register. I mean to say that a direct outb(0x3f8, anything) should result in some activity on the UART's TX pin - unless this is some higher UART model (I've met 16C950) that can follow the CTS input in actual UART hardware, and has been so configured (this functionality is turned off upon HW reset / power-up). As for the "i(nput)" direction, empty space on the ISA reads 0xFF. If my memory serves, the input data register on an empty FIFO reads the last character previously received... If you're not afraid, here is a human re-phrase of the 16C550 datasheet: https://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming #UART_Registers In hardware currently sold on the market, you are likely to get some UART's (COM ports) implemented in an onboard SuperIO chip, attached to the south bridge via LPC. LPC is a recent-ish narrowed-down flavour of the old ISA, and the LPC SuperIO UART's are typically available at the legacy IO ports and IRQ's. As far as you're concerned, they still *are* the good old ISA UART's - accompanied by due entries in the various BIOS interfaces that can be used to ask about the hardware available. The SuperIO chips unconditionally must be initialized by the BIOS on startup - hence it's fairly automatic, that the BIOS knows all the details about the setup of the UART's. It really tends to be pretty seamless in modern PC hardware, including detection by the OS (Windows or Linux). BTW there's a special tool for Linux called "superiotool" that can look for SuperIO chips directly, in the hardware - trying to talk to their configuration register banks at well-known base addresses such as 0x2E and 0x4E. If there are any add-on serial ports (UARTs) in the PC, it is *very* unlikely that they would collide with your onboard UART's. At least in any newly purchased HW setup, addon UART's would reside on the PCI, PCI-e or USB, thus having no chance of colliding with onboard UART's (including those appearing as legacy ISA devices). And, PCI/PCI-e and especially USB UART's would be harder for you to reach from DOS :-) In the last 5 years or so, pure ISA addon hardware tends to be vanishing from the industrial PC market - including the last obscure incarnations such as the original ISA-flavoured PC104 form factor. In theory, LPC-based addon UART's are possible, but in practice I've never seen such a board as a commercial product. I know a guy who has DIY'ed an LPC addon board with an extra SuperIO chip, but he had to route the board himself and write a piece of software to initialize the UART's :-) It's very unlikely that the peripherals in the addon SuperIO chip (not known to the BIOS) would collide with the onboard SuperIO stuff - the addon-on chip, pristine "after reset", should have all the peripheral devices disabled in its config registers... Anyway - if you have an older hardware setup with an extra set of ISA-based UART's, you know the old ISA story... (the responsibility is *yours* to avoid resource conflicts). We can talk further, but please provide some details about your hardware :-) Frank Rysanek P.S.: Many years ago, I've seen a defective series of UART's in one model family of SuperIO chips... And one or two instances where a BIOS bug would lead to a misconfigured SuperIO UART (RS485 auto-flow-control was crippled by the bug). But those specific ancient trouble cases are not likely relevant to your problem. On 28 Dec 2019 at 5:07, Matt Jacobs wrote: > > Nothing is connected to the serial ports at the moment, except for an > oscilloscope that I am using to measure what is being transmitted (Tx > pin). I'm not interested in anything on the receive side just yet. > > At first I tried a legacy program that worked in MS-DOS 6.22 that I > am trying to get working in FreeDOS - this program outputs data on > COM1. The hardware that it is connected to does not use hardware flow > control. No data appeared to be transmitted. > > When I couldn't get a reading on my scope I decided a more direct > approach by piping direct from the console: > ECHO TEST>COM1 > > When I do this I get: > Error reading from device COM1: write fault > (A)bort, (I)gnore, (R)etry, (F)ail? > > > > > > > From: dmccunney <dennis.mccun...@gmail.com> > Sent: Friday, 27 December 2019 11:55 PM > To: Discussion and general questions about FreeDOS. > <freedos-user@lists.sourceforge.net> > Subject: Re: [Freedos-user] MODE not changing RTS or DTR of serial > ports > > On Fri, Dec 27, 2019 at 6:13 PM Matt Jacobs <kexling...@hotmail.com> > wrote: > > > I suspect that DTR/RTS being on is the reason why I cannot write to > the serial port. > > How are you *trying* to write to the serial port? What is connected to > the port? How is it connected? DTR/RTS is hardware flow control, > used to determine whether the device you are attempting to write to is > ready to receive data. Hardware flow control requires that certain > pins be connected in the cable. Incorrect pinouts on the cable's > connectors may be your problem. > ______ > Dennis > > > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
