🚀 go-pugleaf

Greetings netters,

I have a need to write a program for MSDOS that will act
as a TSR to redirect IO manipulation by another program
to my own custom hardware. That is to say:

	1. Trap any IO reads/writes to a specific port
	2. Simulate Interrupts from hardware

This is somewhat like writing a debugger that allows traps
whenever low level IO is accessed.
Needless to say this must all be done in software.
The software can be specified to only run on 386 class PC's.

Does anyone have experience in writing this kind of software?
Are there any books which might discuss this kind of hardware
simulation?

I will post a summary of any email if there is interest.

-- 
Peter Roeser                 | peter@Schultz.ON.CA
S-S Technologies Inc.        | uunet.uu.net!watserv1.uwaterloo.ca!schultz!peter
88 Ardelt Avenue             | voice: (519) 571-1434 x227
Kitchener, ON Canada N2C 2C9 | FAX:   (519) 743-3610

gee....I was just about to post a similar request --- good timing, eh?

In article <1992Aug31.192341.795@Schultz.ON.CA> peter@Schultz.ON.CA
(Peter Roeser) writes:

>I have a need to write a program for MSDOS that will act
>as a TSR to redirect IO manipulation by another program
>to my own custom hardware. That is to say:
>
>        1. Trap any IO reads/writes to a specific port
>        2. Simulate Interrupts from hardware

I'm looking for something similar --- only in my case, all I want to do is
setup something where, with one standard (we'll assume a 16550 UART) serial
port, multiple programs under a multitasking environment (Desqview, windoze,
whatever) can use the same serial port to access multiple devices.

something like the following:

                                          ____
modem terminal program    \              |    |--- modem         (38.4 kb)
packet radio program       > serial port | ?? |--- packet TNC #1  (9.6 kb)
2nd packet radio program  /   (115 kb/s) |    |--- packet TNC #2  (9.6 kb)
                                          ---- 

the black box after the serial port is something I haven't designed yet,
since I'm not sure if the rest of this is even within the limits of sanity
to attempt (or if it's even possible to begin with).  basically, though,
it's a data switch/mux.

now, to add to the problem --- I'd want this to work with any old generic
comm program....meaning it can't be expected to handle the addressing on
its own (device driver?).

>I will post a summary of any email if there is interest.

there is interest.  :-)

ideas?  thoughts?  suggestions?  comments as to the sanity level of asking
this?  :-)
   --jim

\input std_disclaimer                     % 73 DE N5IAL (/9)
------------------------------------------------------------------------------
"[...] the plural of `mongoose' ought to be `polygoose'." [Jargon file 2.9.10]

INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
ICBM:  41.70N 87.63W            UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO:  n5ial@n9hsi (Chicago.IL.US.Earth)
------------------------------------------------------------------------------

Hi.  The 386 and better can be set up to generate a general protection fault
when a process does an IN or OUT to a specific I/O port based on an I/O
permission bitmap in the Task State Segment, but this only works in protected
mode where there are TSS's, not in real mode in which MS-DOS operates.  I
guess you could write a little (not!) DOS extender that runs DOS in V86 mode
(which is really a real mode process running within protected mode which is how
Windows multitasks DOS applications in 386-Enhanced mode), but this would be
extremely difficult to design properly to handle BIOS interrupts and DMA.

Simulating interrupts would be pretty easy to do in real mode -- in your
"custom" interrupt handler, just call any interrupt handler you want.

Since this is your "own custom hardware", why don't you just simulate these I/O
ports in your adapter?

Tschuess,
David Paschal

In <1992Sep1.143350.10587@ncsu.edu> dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL) writes:
>Hi.  The 386 and better can be set up to generate a general protection fault
>when a process does an IN or OUT to a specific I/O port based on an I/O
>permission bitmap in the Task State Segment, but this only works in protected
>mode where there are TSS's, not in real mode in which MS-DOS operates.  I
>guess you could write a little (not!) DOS extender that runs DOS in V86 mode
>(which is really a real mode process running within protected mode which is how
>Windows multitasks DOS applications in 386-Enhanced mode), but this would be
>extremely difficult to design properly to handle BIOS interrupts and DMA.

>Simulating interrupts would be pretty easy to do in real mode -- in your
>"custom" interrupt handler, just call any interrupt handler you want.

>Since this is your "own custom hardware", why don't you just simulate these I/O
>ports in your adapter?

what about doing this under windows?  I know nothing of windows
programming,  but wouldn't it be possible to write a windows
driver (for 386 enh mode of course) to do something like this?

I'd be interested in seeing what others think, and how one 
would go about doing it, as I have a similar need.

In article <tgreen.715391992@vincent2.iastate.edu> tgreen@iastate.edu (Todd Greenfield) writes:
>
>what about doing this under windows?  I know nothing of windows
>programming,  but wouldn't it be possible to write a windows
>driver (for 386 enh mode of course) to do something like this?

  I have been told that although Windows uses protected mode to do
  memory management( ie. traps when you talk to non-available mem.)
  it does not trap IO references.

>
>I'd be interested in seeing what others think, and how one 
>would go about doing it, as I have a similar need.

  Let's keep the discussion going


-- 
Peter Roeser                 | peter@Schultz.ON.CA
S-S Technologies Inc.        | uunet.uu.net!watserv1.uwaterloo.ca!schultz!peter
88 Ardelt Avenue             | voice: (519) 571-1434 x227
Kitchener, ON Canada N2C 2C9 | FAX:   (519) 743-3610

In article <1992Sep1.143350.10587@ncsu.edu> dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL) writes:
>
>Hi.  The 386 and better can be set up to generate a general protection fault
>when a process does an IN or OUT to a specific I/O port based on an I/O
>permission bitmap in the Task State Segment, but this only works in protected
>mode where there are TSS's, not in real mode in which MS-DOS operates.  I
>guess you could write a little (not!) DOS extender that runs DOS in V86 mode
>(which is really a real mode process running within protected mode which is how
>Windows multitasks DOS applications in 386-Enhanced mode), but this would be
>extremely difficult to design properly to handle BIOS interrupts and DMA.
>
>Simulating interrupts would be pretty easy to do in real mode -- in your
>"custom" interrupt handler, just call any interrupt handler you want.
>
>Since this is your "own custom hardware", why don't you just simulate these I/O
>ports in your adapter?

   I would like to find a software only solution if possible.
   The software that needs to do the IO trapping will be put into
   existing 386 machines and we would like to avoid modifying
   them by adding cards etc. 
>
>Tschuess,
>David Paschal


-- 
Peter Roeser                 | peter@Schultz.ON.CA
S-S Technologies Inc.        | uunet.uu.net!watserv1.uwaterloo.ca!schultz!peter
88 Ardelt Avenue             | voice: (519) 571-1434 x227
Kitchener, ON Canada N2C 2C9 | FAX:   (519) 743-3610

In <1992Sep03.153802.688@Schultz.ON.CA> peter@Schultz.ON.CA (Peter Roeser) writes:

>In article <tgreen.715391992@vincent2.iastate.edu> tgreen@iastate.edu
(Todd Greenfield) writes:
[ original discussion of need to trap access to IO port deleted ]
>>
>>what about doing this under windows?  I know nothing of windows
>>programming,  but wouldn't it be possible to write a windows
>>driver (for 386 enh mode of course) to do something like this?

>  I have been told that although Windows uses protected mode to do
>  memory management( ie. traps when you talk to non-available mem.)
>  it does not trap IO references.

any of you windows programmers care to comment?  I thought
that windows can trap any IO access, such as comm ports or
the timer.  How do you programmer a driver to handle something
like this?  I've never programmed for windows, so references
and any advice would be appreciated.

>>
>>I'd be interested in seeing what others think, and how one 
>>would go about doing it, as I have a similar need.

>  Let's keep the discussion going

In article <1992Sep03.153802.688@Schultz.ON.CA>, peter@Schultz.ON.CA (Peter Roeser) writes:
|> Newsgroups: alt.msdos.programmer
|> Path: taco!rock!stanford.edu!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!Schultz.ON.CA!peter
|> From: peter@Schultz.ON.CA (Peter Roeser)
|> Subject: Re: Trapping 386 IO port accesses
|> Message-ID: <1992Sep03.153802.688@Schultz.ON.CA>
|> Organization: S-S Technologies, Kitchener, ON
|> References: <1992Aug31.191659.672@Schultz.ON.CA> <1992Sep1.143350.10587@ncsu.edu> <tgreen.715391992@vincent2.iastate.edu>
|> Distribution: na
|> Date: Thu, 3 Sep 92 11:38:02 GMT+5:00
|> Lines: 22
|> 
|> In article <tgreen.715391992@vincent2.iastate.edu> tgreen@iastate.edu (Todd Greenfield) writes:
|> >
|> >what about doing this under windows?  I know nothing of windows
|> >programming,  but wouldn't it be possible to write a windows
|> >driver (for 386 enh mode of course) to do something like this?
|> 
|>   I have been told that although Windows uses protected mode to do
|>   memory management( ie. traps when you talk to non-available mem.)
|>   it does not trap IO references.
|> 
|> >
|> >I'd be interested in seeing what others think, and how one 
|> >would go about doing it, as I have a similar need.
|> 
|>   Let's keep the discussion going
|> 
|> 
|> -- 
|> Peter Roeser                 | peter@Schultz.ON.CA
|> S-S Technologies Inc.        | uunet.uu.net!watserv1.uwaterloo.ca!schultz!peter
|> 88 Ardelt Avenue             | voice: (519) 571-1434 x227
|> Kitchener, ON Canada N2C 2C9 | FAX:   (519) 743-3610
|> 

Hi.  Windows DOES trap I/O port accesses -- that's what *.386 virtual device
drivers are for.

Tschuess,
David Paschal