HDTenEightyP/NetNews huggingface dataset:
From: jim@n5ial.chi.il.us
Newsgroups: alt.msdos.programmer
Subject: Re: Trapping 386 IO port accesses
Date: 1 Sep 92 13:12:18 GMT
Reply-To: jim@n5ial.chi.il.us
Distribution: na
Organization: me?  have you seen my desk?  : -)
Originator: jim@eddie

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)
------------------------------------------------------------------------------
Newsgroups: alt.msdos.programmer
From: miller@ee.tamu.edu (Kelly M Miller)
Subject: MS C 5.0 vs. MS C 7.0  .obj compatibility
Organization: Texas A&M University
Date: Thu, 27 Aug 1992 15:44:39 GMT


Can I use an .obj library created with MS C 5.0 with
MS C 7.0? 

thanx,
kelly


Newsgroups: alt.msdos.programmer
From: peter@Schultz.ON.CA (Peter Roeser)
Subject: Re: Trapping 386 IO port accesses
Organization: Sutherland-Schultz Limited, Kitchener, ON
Distribution: na
Date: Mon, 31 Aug 1992 19:23:41 GMT

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
Xref: sparky alt.msdos.programmer:2258 comp.os.msdos.programmer:8802 comp.lang.pascal:5057
From: beaurega@ireq.hydro.qc.ca (Denis Beauregard)
Newsgroups: alt.msdos.programmer,comp.os.msdos.programmer,comp.windows.ms.programmer,comp.lang.pascal
Subject: Re: Windows and printscreen
Date: 26 Aug 92 03:25:05 GMT
Organization: Institut de recherche d'Hydro-Quebec, Varennes, Canada

In article <17alp5INN4f0@matt.ksu.ksu.edu> holland@matt.ksu.ksu.edu (Rich Holland) writes:
>
>Okay, I understand that I can't run a TSR that redirects Int 09h, then run
>Windows, and when I "shell" to DOS from windows, expect my TSR to still
>be active.  That's *NOT* what I was attempting to do.  Instead of running

But, you should!  If you consider DOS (i.e. prompt available) and Windows
(i.e. MS Windows controlling mouse, keyboard and screen) as 2 modes,
whenever you are in DOS mode (from prompt after booting or from a
DOS shell like command.com running inside a Windows window or in
full screen mode), the TSR is available and you could hang up int 09.

>something like this: 'tn3270 matt' from within windows, I'd change the
>PIFF file to read: 'prthru tn3270 matt' -- my prthru program would Exec()
>whatever command I pass it, after re-directing the Interrupt so I can
>catch the prtscr (i had originally thought I needed to grab 05h, but I
>found out later I need the keyboard, 09h).  When the telnet session ends
>(in this case), control returns to my prthru program, which restores the
>vectors and exits to windows -- as far as Windows knows, there hasn't been
>any re-direction...
>
>Now, someone tell me why THIS won't work?
>
In your example, prthru is a Windows program calling tn3270, a Windows
program too, so int 05 and 09 are catched.  If, however, prthru and
tn3270 are both DOS programs (i.e. Windows will install DOS prompt before
running prthru), then you should be able to intercept printscreen, but only
if the DOS window is active.  It is like a program writting directly to
the screen (like a text editor I wrote years ago).  In the DOS window,
the editor writes to the video memory directly so that in DOS full
screen, the video memory is not intercepted.  However, in DOS window
with Windows active, when the editor writes to the screen, Windows intercept
the character, and re-write it on the copy of memory video in the DOS window.

In other words, Windows catch many interrupts (if not all) and when
WIndows has the control, you can't do anything.  Maybe you could do something
if you intercept WIndows commands, but this is not using the interrupts
and should be discussed in the ms-windows newsgroups anyway.

>
>-- 
>Rich Holland              | INTERNET: holland@matt.ksu.ksu.edu
>100 Jardine Terr, Apt A7  | BITNET  : holland@ksuvm
>Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
>"Jesus saves...but Gretzky gets the rebound!  He shoots!  He scores!!"


-- 
  \_\    Denis Beauregard  *  internet:beaurega@ireq.hydro.qc.ca
 /   \   Genealogiste officiel : Beauregard/Jarret/Jarest/Vincent
J   __>  Vient de paraitre : Andre Jarret et ses Ancetres
\_.-===  En vente par l'auteur                      Opinions ? Et pis non !
Xref: sparky alt.msdos.programmer:2296 comp.os.msdos.apps:4594
From: jimmy@namao.ucs.ualberta.ca
Newsgroups: alt.msdos.programmer,comp.os.msdos.apps
Subject: Simple print routines for DOS
Date: 1 Sep 92 03:17:28 GMT
Article-I.D.: kakwa.1992Sep1.031728.12364
Organization: University of Alberta

Does anyone have routines that can draw lines/text on dot matrix printers ?
I have the lines as a series of points. Basically, I need to draw on paper
just the way I draw on screen (using graphics.lib).
Please email,
Jimmy

--
jimmy@namao.ucs.ualberta.ca
From: aedil@suarez.tes.cl ("Aedil Suarez")
Newsgroups: alt.msdos.programmer
Subject: help
Reply-To: aedil@suarez.tes.cl ("Aedil Suarez")
Distribution: international
Organization: D.C.C. Sistemas (USENET V.gamma)
Keywords: 
Date: Wed, 26 Aug 1992 10:44:19 CST

 Hello :

 I'm working on a Clipper 5.0 program and i need to call from this
 program a Turbo Pascal 4.0 routine and so i wonder if it is posible.

 Is there someone who knows how can i do it ?  
 I'll be very gratefull.

 Please e-mail me your answer to :

 aedil@suarez.tes.cl

 Thanks.
 .
 
 :
 .
 .
 :
 :
 
 :.................
 .................
 ................
................
..............
.............
Newsgroups: alt.msdos.programmer
From: swalter@nyx.cs.du.edu (DreamWeaver)
Subject: Re: alt 255
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Wed, 26 Aug 92 05:36:41 GMT

CHAMINADE, MARC MICHEL LOUIS <MCHAMINA@ESTEC.BITNET> writes:

>If you want to prevent people to delete your files on your hd with the f
nction
>del xxx.x rather than Attrib you'd better rename the files from
>xxx.x to
> xxx.x The space in front of the name is obtained with the alt-255 combi
ation.
>You can not call the file or do anything to it by using the space key.

>Some may find it usefull. I do !

Nifty idea ... I've got an extension to that:

Since DOS see the ALT-255 combo as a valid character for filename, you
aren't limited to just one of them.  You can create a filename that is
nothing but ALT-255's.  -OR-, you can put an ALT-255 at the _end_ of the
name:

     xxx_.x

where the '_' is the ALT-255 combo.  That way, the file doesn't seem any
different when you do a directory of it ... yet trying to access just
xxx.x doesn't work (file not found).

Also, ALT-255 works for creating sub-directories.  It will effectively
make the directory invisible unless something is entered into the
directory table after it.

(for those curious, ALT-255 means hold down the alt key and type 2 5 5 on
the _numeric_keypad_.  You won't get this to work if you use the keys
across the top of the keyboard, it _must_ be the keypad.  For that matter,
that's how you can create filenames or directories with IBM graphics
characters:  simply substitute the ALT-??? combo of the character for what
you want ... the combo being the ASCII value of the graphic char you want
to use).

-Scotty

Newsgroups: alt.msdos.programmer
From: jcmorris@mwunix.mitre.org (Joe Morris)
Subject: Re: alt 255
Organization: The MITRE Corporation
Date: Wed, 26 Aug 1992 20:39:46 GMT

odonovan@ohstpy.mps.ohio-state.edu writes:

>Here's another nifty use for ALT-255:

>In batch files,

>    echo_

>where _ is ALT-255, will print a blank line on the screen.
>This is useful if you want to separate your output messages.
>And it works from DOS 2.11 and up!

Why not just code:

echo.

which writes a single blank line to the screen?  (Note the period after
the "o".)  This worked at least in 3.3; I'm not sure if it is valid for
any earlier releases.

Using ECHO. is documented for MS-DOS 5 on page 458 of the DOS manual.

Joe Morris / MITRE
Newsgroups: alt.msdos.programmer
From: drice@ponder.csci.unt.edu (Keith Rice)
Subject: Re: To all who want to program TSR
Organization: University of North Texas
Date: Fri, 28 Aug 1992 00:52:31 GMT

In <1992Aug27.153035.15061@tom.rz.uni-passau.de> mieze@forwiss.uni-passau.de (Thorsten Mieze) writes:

>Hi all!

>During last time, there were often questions about programming TSR
>in higher languages like C, PASCAL, MODULA etc. in this newsgroup.
>Notice, that all TSR-programs need an include of assembler, which 
>sets div. parameters (e.g. div. pointers of interrupts) to enable
>programming the real TSR-program in higher language. The mostly 

Not so.  In the book _Turbo Pascal 5.5_ from Borland/Osborne there
is an example of a screen blanker (I think) TSR written entirely in
TP 5.5.

--
D. Keith Rice -- University of North Texas -- drice@ponder.csci.unt.edu
-----------------------------------------------------------------------
Beta Test: To voluntarily entrust one's data, livelihood and sanity to
           hardware or software intended to destroy all three.  In
           earlier days, virgins were selected to beta test volcanoes.
Newsgroups: alt.msdos.programmer
From: schoof@dec5.informatik.uni-wuerzburg.dbp.de (Jochen "Joscho" Schoof)
Subject: Re: How to format 10 sectors per track?
Organization: University of Wuerzburg, Germany
Date: Thu, 3 Sep 1992 10:09:36 GMT

From article <92240.150513APPMS@CUNYVM.BITNET>, by Alexandre Pechtchanski <APPMS@CUNYVM.BITNET>:
> You can also use shareware program 800.com (or ask it's author how he've
> done it).  The program should be in many ftp sites; it puts a patch to the
> BIOS, which then enables flexible formatting (like 10s*43t on 360 kb
> floppies).  Unfortunately, it only works with MS-DOS 3.3+ and internal
> drives.
> 
> Happy hacking!
> -------
Another program with even better facilities is FDFormat v1.8, which is
available from SIMTEL and its mirrors via anonymous ftp. It comes with
sources in Turbo Pascal and offers lots of great formats (for example
1.72MB on 3.5" HD-disks). ATFMT100 offers a 1066KB-format for 3.5" DDs,
but unfortunately includes no source code. Hope this did help you.

Jochen

-- 
---------------------------------------------------------------------------
Jochen Schoof                    schoof@sundae.informatik.uni-wuerzburg.de
Lehrstuhl f. Informatik II +-----------------------------------------------
Universitaet Wuerzburg     | It's worse than that: he's dead, Jim!  -Bones
Newsgroups: alt.msdos.programmer
From: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Subject: Re: Trapping 386 IO port accesses
Originator: dspascha@c00063-100lez.eos.ncsu.edu
Reply-To: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Organization: North Carolina State University, Project Eos
Distribution: na
Date: Thu, 3 Sep 1992 21:30:55 GMT


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
Xref: sparky alt.msdos.programmer:2253 comp.lang.c:12771 comp.os.msdos.programmer:8792
From: kds@phy.duke.edu (Stokes Kevin)
Newsgroups: alt.msdos.programmer,comp.lang.c,comp.os.msdos.programmer
Subject: Re: file positioning with buffered/unbuffered I/O
Date: 25 Aug 92 18:29:31 GMT
Followup-To: alt.msdos.programmer
Organization: Duke University Physics Dept.; Durham, N.C.


   (Christopher H Gregg) writes:

>The program is memory resident and it traps......
>The problem is that when I try to use either DOS function 13h (delete file)
>or DOS function 41h (which I would prefer), the program crashes.

  You can't make DOS calls from within a TSR casually.  DOS is not re-entrant,
meaning that if your TSR interrupts the computer while it happens to be in
a DOS routine, and then turn around and call a DOS routine yourself the system
will quickly crash.
  The reason is that DOS uses static variables to save info when you make
a DOS call.  Thus when you make your DOS call it messes up the variables that
were setup by the DOS call your TSR interrupted.  Then when you try to
return control back, the machine immediately flies into lollyland.
  To find out whether it is OK for your TSR to pop up requires checking the
DOS internal In-service flag.  This is an undocumented location that you
find by making an undocumented system call.
  Yuck.  DOS is a piss-poor excuse for an operation system.  My old Data
General minicomputer (circa 1972) had a really nice true multi-tasking OS 
which fit in less than 16k.  They should have just ported that.  Of course, 
there is a famous Bill Gates quote "Our goal is for user to not even know 
there is an operating system there at all."   (not exact)
  In my opinion he has already achieved this with DOS.  He has convinced the
whole world to use computers with no operation system, just a nice binary
loader!
                                                   -Kevin




-- 
------------------------------------------------------------------------------
|  Kevin Stokes                        |     Please direct all pointless     |
|  Pie in the Sky Software             |   flames to my mailbox, it's much   |
|                                      |          more irritating.           |
From: odonovan@ohstpy.mps.ohio-state.edu
Newsgroups: alt.msdos.programmer
Subject: Re: alt 255
Date: 26 Aug 92 10:24:50 EDT

Here's another nifty use for ALT-255:

In batch files,

    echo_

where _ is ALT-255, will print a blank line on the screen.
This is useful if you want to separate your output messages.
And it works from DOS 2.11 and up!

The tricky thing, though, is to find an editor which will
let you enter it--not all do!  Of course, copy con batch.bat
*will* work.  :^)

Later,
Kevin
Newsgroups: alt.msdos.programmer
From: mieze@forwiss.uni-passau.de (Thorsten Mieze)
Subject: To all who want to program TSR
Organization: University of Passau, Germany
Date: Thu, 27 Aug 1992 15:30:35 GMT

Hi all!

During last time, there were often questions about programming TSR
in higher languages like C, PASCAL, MODULA etc. in this newsgroup.
Notice, that all TSR-programs need an include of assembler, which 
sets div. parameters (e.g. div. pointers of interrupts) to enable
programming the real TSR-program in higher language. The mostly 
unknown problem is the non-reentrance of DOS. It is complex and not 
as easy as it seems to be ! Look out for examples already written !
One exists in : WSMR-SIMTEL20.ARMY.MIL (or 192.88.110.20) in
directory PD1:<msdos.asmutl>. The file name is AMISL083.ZIP .

Examples for typical TSR-programs are :
    -screensaver
    -hot-key activated programs (e.g. calcualtors,calendars,etc.) 
    -intern-command overlaying programs (such as CLS, TIME, DIR) 
    -etc.

(hope everyone understood, because of my bad english %) ) 

Thorsten.

(on the eigth day god created Harley Davidson -
 ...ten minutes later he designed the screw-driver) %)
Newsgroups: alt.msdos.programmer
From: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Subject: Re: Trapping 386 IO port accesses
Originator: dspascha@c00075-100lez.eos.ncsu.edu
Reply-To: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Organization: North Carolina State University, Project Eos
Distribution: na
Date: Tue, 1 Sep 1992 14:33:50 GMT


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
Newsgroups: alt.msdos.programmer,comp.sys.intel,comp.lang.c++
From: Bob Zigon <bobz@truevision.com>
Subject: Problems with MSC7.0 and Intel 302 box
Organization: Truevision, Inc., Indianapolis, IN
X-Useragent: Nuntius v1.1
Date: Fri, 28 Aug 1992 14:46:29 GMT

I am having a great deal of difficulty getting MSC7.0 to run on an Intel
302 box.
This is a 25mhz 386 machine. My tests are showing that there is something
strange
about the hardware that is preventing the C compiler from running under
DOS 5.0.
The C compiler (CL) reports the message "R6906 : DOSX32 - not enough
conventional memory 
for exec". I have worked with Qualitas (makers of 386MAX) to see if they
can help. No luck.
Microsoft is also looking into the problem. There must be something funny
about the
machine. I say this because the DOS directory where DOS 5.0 is installed
has a README
that "singles out" the Intel 302 box whenever you install HIMEM.SYS. You
must include
a /MACHINE:8 parameter to HIMEM.SYS.

Anyone got any ideas?
Xref: sparky alt.msdos.programmer:2234 comp.os.msdos.programmer:8732 comp.lang.pascal:4996
From: beaurega@ireq.hydro.qc.ca (Denis Beauregard)
Newsgroups: alt.msdos.programmer,comp.os.msdos.programmer,comp.windows.ms.programmer,comp.lang.pascal
Subject: Re: Windows and printscreen
Date: 24 Aug 92 00:22:59 GMT
Organization: Institut de recherche d'Hydro-Quebec, Varennes, Canada

In article <17387rINNnm9@matt.ksu.ksu.edu> holland@matt.ksu.ksu.edu (Rich Holland) writes:
>ralf+@cs.cmu.edu (Ralf Brown) writes:
>
>>Windows takes over the INT 09h keyboard interrupt, so it is presumably
>>checking for PrtSc itself and calling its own routines instead of INT 05h
>>as the ROM BIOS does.
>
>Yeah, I thought of that about 10 minutes after I posted.  :-)
>
>Guess I'll re-direct Int 09h instead of Int 05h, huh?  
>
>-- 
>Rich Holland              | INTERNET: holland@matt.ksu.ksu.edu
>100 Jardine Terr, Apt A7  | BITNET  : holland@ksuvm
>Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
>"Jesus saves...but Gretzky gets the rebound!  He shoots!  He scores!!"

But, you can't redirect int 09h !  It is something every user working in
almost any other language than English learn very soon : keyboard interface
that change the keyboard to support French or other "foreign" characters
just won't work with Windows :-( and you have to use the foreign language
drivers included with Windows.  I don't know what actually Windows does,
but it is like it was detecting original BIOS entry points and removing them
while in Windows, but it gives them back while in a DOS windows (i.e.
inside WIndows, WIndows keyboard driver is active; outside Windows and inside
DOS window, DOS keyboard driver is active).

-- 
  \_\    Denis Beauregard  *  internet:beaurega@ireq.hydro.qc.ca
 /   \   Genealogiste officiel : Beauregard/Jarret/Jarest/Vincent
J   __>  Vient de paraitre : Andre Jarret et ses Ancetres
\_.-===  En vente par l'auteur                      Opinions ? Et pis non !
Newsgroups: alt.msdos.programmer
Subject: re: Maze Alorgithms for Borland C++ or just the algorithms
From: gsmi2@cs.aukuni.ac.nz (Gregory David       Smith          )
Date: Mon, 24 Aug 1992 04:01:37 GMT
Organization: Computer Science Dept. University of Auckland
Keywords: Maze Algorithms
Summary: Maze Algorithms for C++ or just the algorithms will do!

Can Someone please send me some good Maze generating algorithms for Borland c++
or even just the algorithms, as I can probably handle the programming myself.

I am trying to generate 800X600 mazes, with one solution, but have long
diversions, just to make them more difficult.

Thanks.

Newsgroups: alt.msdos.programmer