Re: RS232 ports and new PC's

Not entirely true. A serial port will be visible to a DOS app if an appropriate virtual device driver is supplied. I've seen support for both 9x and NT systems (which require quite different virtualization code), although I can't vouch for its quality.

Reply to
Robert Wessel
Loading thread data ...

  1. I am assuming that his DOS app accesses the hardware directly by writing or reading from the UARTs located at base address 0x3F8 or
0x2F8, depending on how many UARTs are on the motherboard.
  1. If he tries that in Windows, the OS will not not let that happen...and will be very mad at him. It might even tell him to piss up a rope. ;-) He would have to get a handle to COMx port and perform WriteFile or ReadFile to the Virtual COMM layer which eventually will pass the data to the serial driver via IOCNTRL commands.

A DOS app, written to touch hardware directly, has no chance of running in small or large Windows.

Elroy

Reply to
Elroy the Seedy Impaler

It's quite possible to make that work by trapping the I/O access and emulating a 16550 in the USB serial driver.

Could be. Virtualizing hardware like a 16550 UART has been a well-known technique for 20+ years -- so it's entirely possible that bit of high-tech hasn't seeped into the Windows world yet.

That's a deficiency in the Windows DOS emulators, not a fundamental problem. DOS programs that touch hardware directly work fine in Linux's "DOS box" because it emulates things like UARTs.

--
Grant Edwards                   grante             Yow!  ... I want a COLOR
                                  at               T.V. and a VIBRATING BED!!!
 Click to see the full signature
Reply to
Grant Edwards

If you are referring to "virtualizing hardware" as using VHDL or Verilog to instantiate a UART in an FPGA, then I agree, but I don't know how that applies here.

Perhaps a brief descriptor of how the USB/Serial adapter works under Windoze will elucidate the discussion. After installation (i.e. the Plug and Play sequence) and enumeration, a COM port appears in the device manager. It is accessed like a normal COMx port via an app. The data is passed to the Vitrual COMM layer (they are radically different in large and small Windows), where a driver other than the serial driver must intercept it because a real UART isn't there. The UART is hanging off the USB tree at an endpoint somewhere. So the data gets packetized, dropped on the USB stack destined for the appropriate endpoint, and depacketized at the remote end (an embedded processor with a USB stack and some firmware). Of course, this segmentation and reassembly protocol has to be able to handle flow control command and escape sequences, and has to bubble those types of commands back to the application so that the virtual COM port really responds to the app like a built-in port.

In this case, the only place to "virtualize" the UART is between the firmware and the physical hardware.

Agreed, but from a reality standpoint, a problem in the Windows DOS emulator IS a fundamental problem. You and I aren't going to be able to fix the problem, and neither is the original poster, who undoubtedly has lost all interest in this arcane thread by now. Thank Mr. Gates. =)

You could use Linux, but that isn't what the OP was asking...

Elroy

Reply to
Elroy the Seedy Impaler

Nope. I'm talking about trapping read/write operations to the UART registers and invoking software that makes it appear that a UART is, indeed, present at the I/O addresses being accessed.

We're instantiating the UART in software, which uses some unrelated (to a 16550) method to actually do the serial I/O.

We're aware of how a USB serial driver works.

What we're talking about is the ability of an OS to trap I/O operations that happen in a virtual-8086 process and then make it appear that hardware does in fact exist at those I/O addresses. The actual serial data could be going in/out via USB, Ethernet, some oddball UART, whatever. The process running on the virtual 8086 thinks it's got hold of a 16550.

He wanted to run a DOS program with a USB serial device. I told him one of doing it: use Linux. Apparently it can't be done under Windows.

--
Grant Edwards                   grante             Yow!  I LIKE Aisle 7a.
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

How is this so hard to believe ?

Computers have emulated instructions (opcodes) which were not available on a specific processor for quite a few decades.

A typical example are the floating point instructions in some computer families. The largest members of the computer family had the floating point instructions implemented in hardware. In order to be able to execute an identical program on the smallest members of the family that did not implement the floating point instructions, emulation was used.

When the small computer encountered the floating point instruction, it was trapped using the illegal op-code trap (reserved instruction or whatever it was called). The trap service routine would first decode the offending opcode and if it was one of the emulated instructions, it would determine were the operands are and then executed the floating point instruction using some library routines, that used integer instructions. When the floating result was ready, it would be stored in the same place as the floating point instruction would have stored it, before the reserved instruction trap would return and the program execution would continue from the next op-code following the floating point instruction.

To the application program, it would appear as if the processor had floating point instructions, but of course the program would be much slower.

--
Now it should be quite obvious, how emulation of UART access is
implemented.
 Click to see the full signature
Reply to
Paul Keinanen

I thought it was all along, but thanks for explaining it in detail.

Yup. The [3456]86 processor architecture has that.

Yup. Dosemu has been doing that for years.

However, the DOS program can be running in virtual-8086 mode.

In true real mode, there is no such concept as a "non-existant location" that is comparable to a non-mapped area in a machine with VM. All locations exist. Some locations just don't have hardware that responds when those locations are accessed.

The write cycle is actually performed, but nobody on the bus is paying attention because their chip-selects are all inactive. Read cycles are likewise performed, and whatever value happens to be on the data lines is returned.

Easy: You don't run it in real-mode. You run it in virtual-8086 mode on a 386 or latter.

formatting link

--
Grant Edwards                   grante             Yow!  Zippy's brain cells
                                  at               are straining to bridge
 Click to see the full signature
Reply to
Grant Edwards

How then do the drivers access the hardware? Or is it your point that all the software at that level has already been written?

Reply to
Richard Henry

Not true. All I/O access by applications is indeed trapped by windows. But the most common I/O ports like the UARTs, LPT ports and even the PIC are virtualized in windows, in order to let old DOS apps access these I/O ports 'directly'. And I know from experience, because my self written DOS terminal programs do this exactly, and have always run fine in DOS, Windows 3.x, 95, ME, NT4 and 2K.

Meindert

Reply to
Meindert Sprang

Even in plain vanilla DOS, this is feasible. All you need is a device driver started from config.sys, that switches the CPU into virtual mode and run DOS is a VM. Just like EMM386.SYS did. And in that situation, the DOS app sees real comm port registers.

Meindert

Reply to
Meindert Sprang

This is not actually true. Programs that use the comms port hardware directly have no trouble under Win9x (since it's really just glorified Win3.1, runs dos underneath and has very little hardware protection), and they have no trouble under NT or W2K (I can't answer for XP - I wouldn't touch it with a bargepole), which virtualises the ports. Programs that use the parallel port directly (very common for people in this group) work fine under Win9x (again, it's a toy system with no protection), and can be made to run under NT/W2K with a bit of help. If the author of the program is helpful, then they can include the "giveio" driver - a program can access this driver, and then have rights to access the hardware directly. Almost all parallel-port programs (for debuggers, programmers, etc.) that have NT/W2K support use this technique. If you can't modify the program, then you can use the "totalio" driver - start it, and *any* program can access the parallel port directly. I've used it to get old Win3.1 parallel-port programs to work under NT, although obviously you don't want to use it more than necessary.

Reply to
David Brown

Perhaps it's true for Windows, but you can run DOS and DOS apps under Linux using DOSemu, and it will provide "virtual" hardware.

You can make it look like you do.

--
Grant Edwards                   grante             Yow!  HUMAN REPLICAS are
                                  at               inserted into VATS of
 Click to see the full signature
Reply to
Grant Edwards

Not quite "all I/O access by applications" are trapped by Win

3.x/9x/ME (they are all by NT/2K/XP). Any port that hasn't been grabbed by a VxD in 3.x/9x/ME is generally allowed to be accessed by DOS apps without interference. The system does provide VxDs for all of the system hardware (eg. PIC, timer, keyboard, display, etc.), so those are all virtualized by default, but if you install some non-standard hardware without a VxD, you *can* hit it from a DOS app under 3.x/9x/ME. Other resources (I/O device memory especially) have a similar "default" access unless virtualized by a VxD under 3.x/9x/ME.
Reply to
Robert Wessel

With an Intel cpu and some others you have the 'in' and 'out' machine instructions to access device hardware. A low level device driver would typically use these instructions to write and read to and from the device registers. Devices are not mapped into main memory address space as with many micros, but live in a separate and private address space unique to the in and out instructions. It's not segmented and can be thought of as being in parallel with the 0x0000 to 0xffff main memory space.

So, on a pc, if real i/o device registers not physically mapped into the i/o space, they can't be seen by the in and out instructions or, by implication, system code that calls the driver.

This is all muddied by the fact that all sorts of code is called a driver now, but to me, a 'device driver' is always low level code that talks directly to hardware :-)...

Chris

Reply to
Chris Quayle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.