DOS ain't dead

Hello,

I am looking for a nice way to exchange information between a dos program and "the real world".
Of course there are Parallel and Serial ports (on mother board on PCI board).
But I would like something more efficient, for example writing/reading directly a 32 bit value via PCI port.

I have been looking for a chip that performs the PCI interface and proposes GPIO, but I haven't really found... Idealy a cheap and simple PCI card could propose this ?
Does someone knows anything like this?

Thanks.

Some years ago I found some PCI/PCI-E bridges that behaved like GPIO controlled via few registers from IO space. Also some implemented MMIO. I really cannot remember the type or manufacturer but it exists. Also you can use IDE (PATA) port as fast 16b IO.

---
DOS gives me freedom to unlimited HW access.

You're going to need to go into a little more detail on what you mean by "real world". Something inside the computer, next to the computer, in the next room, down the street, halfway around the world, a plane or satellite flying through space, ...? Do things like bandwidth, speed, latency, security, reliability, electromagnetic/radio-frequency interference immunity, etc., matter? Is the communications simplex, half-duplex, or full-duplex? What kinds of protocols, voltage/current levels, etc. does the device with which you're trying to communicate understand?

There are hundreds of different protocols and standards, all designed for specific demands and requirements, and you can even come up with some proprietary ones of your own if you feel like it. Just as a simple example, look at the plethora of standards there are/have been used to get video signals to a monitor (to name but a few: MDA, CGA, EGA, VGA, SVGA, 8514/A, XVGA, digital (MDA/CGFA/EGA) cables, analog (VGA) cables, DVI, HDMI, interlaced, non-interlaced, etc. -- and we won't even talk about all of the television standards).

> Some years ago I found some PCI/PCI-E bridges that behaved like GPIO
> controlled via few registers from IO space. Also some implemented MMIO. I
> really cannot remember the type or manufacturer but it exists. Also you can
> use IDE (PATA) port as fast 16b IO.

PATA, I didn't think about it. At the present time there is only one in my computer, and it is used (compact flash as HDD). But is it possible to control one byte or word at a time? (I thought it was only some kind of "data transfer protocol", not really a gpio).

FDD port cannot be used in the same way?

> You're going to need to go into a little more detail on what you mean by
> "real world". Something inside the computer, next to the computer, in the
> next room, down the street, halfway around the world, a plane or satellite
> flying through space, ...? Do things like bandwidth, speed, latency,
> security, reliability, electromagnetic/radio-frequency interference
> immunity, etc., matter? Is the communications simplex, half-duplex, or
> full-duplex? What kinds of protocols, voltage/current levels, etc. does
> the device with which you're trying to communicate understand?
>
> There are hundreds of different protocols and standards, all designed for
> specific demands and requirements, and you can even come up with some
> proprietary ones of your own if you feel like it. Just as a simple
> example, look at the plethora of standards there are/have been used to get
> video signals to a monitor (to name but a few: MDA, CGA, EGA, VGA, SVGA,
> 8514/A, XVGA, digital (MDA/CGFA/EGA) cables, analog (VGA) cables, DVI,
> HDMI, interlaced, non-interlaced, etc. -- and we won't even talk about all
> of the television standards).

Hello,

As I said my need is really to interface with dos programs, in a simple and basic way. I am not looking for a protocol, just a GPIO.
For me the real world is something inside the computer or next to it.

In other words i am looking for a improved parallel port, with one instruction I could do something like "outportl(0E300, toto)" and this would directly set a 32 bit gpio port. (the same with "inport").
Max frequency is 1 Mhz, but generally it is much less.
I don't even need interrupts on PCI port.

Yes, PATA behaves similar to simplified ISA bus. There are 16b data lines but only 3 address lines + iord#, iowr# and some others. I belive you can find some older GPIO cards on ebay - used in industry PCs...

---
DOS gives me freedom to unlimited HW access.

Regular parallel ports can easily exceed 1 Mbps, so it doesn't sound like speed is your issue -- you don't need an "improved" parallel port in that sense. It sounds like your main concern is the interface, not the speed.

Does it need to be an I/O interface, or would the regular INT 17h BIOS interface for the parallel port work for you? Of course the INT 17h interface only allows for a byte at a time to be transferred instead of a dword, but you could easily create a function/procedure to handle that automatically (the "simple" interface you're looking for could be a function call, could it not?).

In my USBPRINT program, I've added some INT 17h extensions to allow for the transfer of entire blocks of data (not just a byte or even a dword at a time), and also to allow for data to be received from the device instead of just being sent. The data in the reverse direction (from the device to the computer) must be sent in nibble mode (IEEE 1284 specification), so isn't as fast as the forward direction, but it does work. The main purpose of USBPRINT is to be a driver for USB printers and USB-to-parallel converter cables, but also adds some enhancements to regular parallel ports. It may be able to help you with your quest.

> The data in the reverse direction (from the device to the
> computer) must be sent in nibble mode (IEEE 1284 specification), so isn't
> as fast as the forward direction, but it does work.

But every moder LPT is EPP/ECP standard, that id fully bi-dir. and can read full 8b bata + status lines. I used it 15 years ago for EPROM reader/programmer on LPT...

---
DOS gives me freedom to unlimited HW access.

The first parallel ports IBM came out with were bidirectional, and then they made them unidirectional (they were a little cheaper to make that way), and then with the PS2's they made them bidirectional again (and they weren't even EPP or ECP, they were just bidirectional). You don't actually need EPP or ECP to have a bidirectional port.

Making a port EPP, ECP, or regular/bidirectional is usually something you can change in the BIOS.

The problem with anything other than nibble mode is that both devices (the computer and the end device, usually a printer) have to be configured exactly the same way. If it's a one-off application, or has a very limited, controlled distribution, that's OK since you can manage everybody's configuration. If it's a general-purpose application intended for wide distribution, it's much more problematic.

Nibble mode doesn't have that problem -- it always works no matter how things are configured. But, it's slower -- at least in theory, it should only be about 1/2 as slow, though in actual practice I'm not sure how fast it really is. They claim parallel ports can reach speed of 12~16 Mbps, so I would think even in nibble mode you should be able to get at least 1 Mbps.

>
> But every moder LPT is EPP/ECP standard, that id fully bi-dir. and can read
> full 8b bata + status lines. I used it 15 years ago for EPROM
> reader/programmer on LPT...

Indeed you can configure the LPT data to be inputs or outputs.
From my experiments, I noticed that
in standard mode, you have 8 outputs (data) + 4 inputs + 5 I/O
in bidir mode with input data, you have 8+4 inputs, and 5 outputs
(but I never manage to get 16 inputs)

> Regular parallel ports can easily exceed 1 Mbps, so it doesn't sound like
> speed is your issue -- you don't need an "improved" parallel port in that
> sense. It sounds like your main concern is the interface, not the speed.
>
> Does it need to be an I/O interface, or would the regular INT 17h BIOS
> interface for the parallel port work for you? Of course the INT 17h
> interface only allows for a byte at a time to be transferred instead of a
> dword, but you could easily create a function/procedure to handle that
> automatically (the "simple" interface you're looking for could be a
> function call, could it not?).
>
> In my USBPRINT program, I've added some INT 17h extensions to allow for the
> transfer of entire blocks of data (not just a byte or even a dword at a
> time), and also to allow for data to be received from the device instead of
> just being sent. The data in the reverse direction (from the device to the
> computer) must be sent in nibble mode (IEEE 1284 specification), so isn't
> as fast as the forward direction, but it does work. The main purpose of
> USBPRINT is to be a driver for USB printers and USB-to-parallel converter
> cables, but also adds some enhancements to regular parallel ports. It may
> be able to help you with your quest.

By 1 Mhz I mean that each access to the port (read or write) is 1 µs. so it corresponds to 8Mbps in your speed system measurements.
I am not looking for big data transfer, but I need to access the "real world" quite often and with a short cpu time. At the present time I use paralle port with "inportb(0x378)" instruction, and it takes about 1us. I would prefer if it took less time, for example 0.1us. But I don't know much about efficient low-level access.

For example I don't know how to use int 17h, I guess I shall try to understand it.

> The first parallel ports IBM came out with were bidirectional, and then
> they made them unidirectional (they were a little cheaper to make that
> way), and then with the PS2's they made them bidirectional again (and they
> weren't even EPP or ECP, they were just bidirectional). You don't actually
> need EPP or ECP to have a bidirectional port.

OK, you're right, there were also simple bidirectional ports.

> They claim parallel ports can reach speed of 12~16 Mbps, so

Really theoretical. Just try to toggle some bit as fast you can and measure if it really toggles. I never seen something far beyond 1Mb/s (maybe some industrial version is exception).

---
DOS gives me freedom to unlimited HW access.

> I would prefer if it took less time, for example 0.1us. But I don't know much
> about efficient low-level access.

Even if you could reach average 0,1us acces you will run into other toubles with running SMI BIOS routines (cannot disable them all) that could delay your I/O cycle to several us - in a random manner. Simply PC is not designed to do such fast realtime controlling / unbuffered sampling. You should use some fast MCU (ARM, etc.) that is fully under your control that will be controlled by master PC.

---
DOS gives me freedom to unlimited HW access.

> Really theoretical. Just try to toggle some bit as fast you can and measure
> if it really toggles. I never seen something far beyond 1Mb/s (maybe some
> industrial version is exception).

It is my impression that ECP mode provides 2.5 Mbps. Come to think of it, I can't recall a single DOS program which supports LPT to LPT transfers while utilizing the extra speed and DMA transfer of the ECP parallel port mode. Anyone know of such a program?

> > I would prefer if it took less time, for example 0.1us. But I don't know
> much
> > about efficient low-level access.
>
> Even if you could reach average 0,1us acces you will run into other toubles
> with running SMI BIOS routines (cannot disable them all) that could delay
> your I/O cycle to several us - in a random manner. Simply PC is not
> designed to do such fast realtime controlling / unbuffered sampling. You
> should use some fast MCU (ARM, etc.) that is fully under your control that
> will be controlled by master PC.

Hum I don't know, I've made some tests and I didn't find serious problems such as several us delays (after inhibiting all usb and some hw interrupts), I get a precision of about 1-2us. Maybe (probably) it depends on motherboards.
So with this precision of 1 or 2us established, I want to limit the cpu time dedicated to I/O access. And If I could do I/O acces of 0,1us it would really reduce this cpu time.

At the present time I consider PC is interesting solution, because nice power computation and efficient way to debug/follow your program. In general PC is not used for time-critical application but I consider it can do such job.
I use microcontroler for limited tasks. But I probably don't know much about fast MCU capabilities.

> I get a precision of about 1-2us. Maybe (probably) it depends
> on motherboards.

Then you're lucky guy but I'm not sure about modern UEFI based PCs...
Yes running on PC has also its advantages...

---
DOS gives me freedom to unlimited HW access.

> By 1 Mhz I mean that each access to the port (read or write) is 1 µs. so it
> corresponds to 8Mbps in your speed system measurements.

Well, that is very different. As someone else noted above, I'm not sure I really believe a standard parallel port can actually reach the speeds I've heard some claim it can reach (12~16 Mbps). It is WAY faster than a serial port, though.

> I am not looking for big data transfer, but I need to access the "real
> world" quite often and with a short cpu time.

So, is your real issue the fact that you need to wait for it to happen and can't use the CPU for other things, or do you actually need "real-time" control of the device? IOW, will your system fall apart if you process the data transfers in the background that may get queued and delayed a several microseconds or even milliseconds?

> At the present time I use paralle port with "inportb(0x378)" instruction,
> and it takes about 1us.

INT 17h probably won't be any faster than accessing the I/O ports directly, it's just an easier interface to use.

How are you measuring the strobe timing?

> I would prefer if it took less time, for example 0.1us. But I don't know
> much about efficient low-level access.

According to RBIL, you're supposed to hold the strobe for at least 5 microseconds on a standard parallel port, so you're not going to get down into the sub-microsecond range with your timing, at least using standard parallel ports. Also, according to the IEEE 1284, the device has up to 35 milliseconds to respond to a request for data in the reverse direction, and it doesn't sound like you can wait anywhere near that long.

If you can handle the latency/queueing issues mentioned above, USB might be a good approach. USB is packet-based, though, so has a lot of inherent latency issues that can't be overcome, so can't really be used for true real-time processes.