Is there any information on writing hardware port emulators? I would like to be able to create a driver that acts as a virtual serial port, which can be accessed just like a regular serial port, but would allow another program to read what would normally be comming through the port. WindowsXP would be the targeted system, but Win2k support would be nice too. Any information would be greatly appreciated! [edit] Just to give a little info about exactly what I'm trying to do.. I have been studying electronic engeering (the maths and such involved) and, while learning, have been creating my own 'real time' (Though its timescaled WAY down) analog circuit simulator. So far when I build the projects in real life (heh) the circuits act the same (for the most part as I haven't coded in randomization for things like resistor tolerance, which is 5% on my real life resistors). But anywho, in the near future I am going to start designing some serial port circuits. But instead of risking frying my actuial ports, I want to create a virtual serial port that my emulator program can interface too. Then I want to be able to use C++ and do standard serial port I/O code, which the emulator (which would have to be running at realtime speed) would then catch and act upon. This thing is turning into a way cool project(concidering i was doing it just to learn the maths), so I hope its possible ^_^ [Edited by - Dreq on September 27, 2006 6:47:00 AM]

Most programs would see a serial port as a simple file stream.

Back in the old days, cin/cout (or stdin/stdout) WERE connections to serial ports. Computers didn't have a "console" in the sense of what Microsoft Windows provides. They may have had a hardcopy terminal attached to serial port 0 (or there may have been a designated console port which was in fact a serial port).

So, all you'd need to emulate that is another program. In Unix and its ilk, that what a pipe(2) was: it enabled another program to act as a source/sink for serial port emulation. There must be something similar under Windows?

If what you're looking for is lower-level UART emulation so you can practice IRQ-level programming and feeding/reading control and data registers at memory-mapped addresses, you might look in to obtaining a copy of <a href="http://bochs.sourceforge.net>bochs, which emulates yer garden-variety PC hardware, including COM1: and COM2:.

Quote:Most programs would see a serial port as a simple file stream.

Indeed linux is like that, but I did not know windows was the same way.. then again, I have 0 knowledge of using hardware directly in windows.

Quote:Back in the old days, cin/cout (or stdin/stdout) WERE connections to serial ports. Computers didn't have a "console" in the sense of what Microsoft Windows provides. They may have had a hardcopy terminal attached to serial port 0 (or there may have been a designated console port which was in fact a serial port).

I know what ya mean. Most of them were dumb terminals that accepted something like telnet.. basically echoed text on a text monitor, and sent keystrokes.. no processing involved.

Quote:So, all you'd need to emulate that is another program. In Unix and its ilk, that what a pipe(2) was: it enabled another program to act as a source/sink for serial port emulation. There must be something similar under Windows?

Well from my experiences with hardware I/O, I used inportb and outportb (or inp outp respectivly in vs). I guess this is the 'old' way to do it?

Quote:If what you're looking for is lower-level UART emulation so you can practice IRQ-level programming and feeding/reading control and data registers at memory-mapped addresses, you might look in to obtaining a copy of

Malformed html, but I looked at the source, and i'm aware of bochs. I actuially use VMware though as it can run windows and linux with no problems.

I guess my main confusion is step 1:
Step 1: ??
Step 2: Service or driver reads the data and converts it into a digital version of what the serial port would send
Step 3: Emulation software reads this service/driver and sets the values of the pins that are connected to the port accordingly.

At the lowest level, a serial port is a UART, which could be implemented as a bunch of NAND gates across the memory address bus and a bunch of flip flops (implemented by NAND gates) across the data bus. These gates combine their output into a line driver on ping 3 of your connector, and a similar line buffer feeds into a bitshift register that dumps through another series of NAND gates and connects to an interrupt controller pin.

I guess at a lower level, NAND gates can be imlemented using transistors and resistors, and the logic could be implemented using NOR gates instead, saving a few transistors.

At the next level up, the serial port is seen as a couple of memory addresses, generally one for the control register and one for the data register. These addresses might be mapped in to the main memory address space or might be in a different address space (the Intel architecture uses a separate IOPort address space for legacy hadrware like COM1:). You would simple write data to the data address to send, and read data from the data address to receive. You would only read data when the interrupt was sent, and you would clear the interrup by writing to the control address (which was also used for things like setting the speed, duplex mode, control protocol, toggling control lines, etc). Usually it's the job of the OS to perform these tasks, and would simply transfer the bytes to/from a buffer area.

At the next level up, the normal programmatic level, you would just open the serial device and supply a buffer for te OS to read/write to/from. In DOS (and probably in Windows) you could simply fopen("COM1") and use fread() and fwrite() for I/O. Similarly in Unix you could fopen("/dev/tty0") or whatever.

So, the question is, at what level are you looking for emulation?