home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!wupost!gumby!destroyer!caen!mtu.edu!abcd.Houghton.MI.US!Jim_Johnson
- From: Jim_Johnson@abcd.Houghton.MI.US (Jim Johnson)
- Newsgroups: comp.sys.atari.8bit
- Subject: Re: REPLY
- Distribution: world
- Message-ID: <Jim_Johnson.05wt@abcd.Houghton.MI.US>
- Date: 27 Jul 92 15:04:00 EST
- Organization: Amiga BitSwap Central Dispatch
- Lines: 33
-
-
- HH> Another unpleasant "feature"
- HH> (IMHO) is a leftover from the ATARI 40-column printer days. If you
- HH> send
- HH> ANY character after a RETURN, the P: handler will pad it out to 40
- HH> spaces! Very annoying for a program I was writing... I couldn't get
- HH> around it at the OS level.
-
- HH> --Michael
-
- HH> ----------------------------------------------------------------------
- HH> ---------
- HH> Michael Hill <>< Isaiah 9:6 | "Outside your door He is waiting,
- HH> waiting for
- HH> hill@spot.Colorado.EDU | you/ Sooner or later you know He's
-
- Its been awhile, but it is my understanding that ANY of the device drivers
- built into the Atari OS can be replaced by the user (well, the program used
- by the user anyhow). The device table is read from the bottom up for the
- first occurence of the device name and the vector to the handler. To get
- around the buffer padding for the printer will require you to write your
- own P: handler and install its vector in the device (handler) table. Since
- the OS will take the first matching vector it comes to, the replacement P:
- handler would be used rather than the one built into the OS ROM. A fair
- example of building your own printer handler is the G: driver published
- some years ago in ANALOG. (You are right though that the 155<->13
- translation happens in the printer adapter hardware and cannot be
- controlled by the P: handler).
-
- -- Via DLG Pro v0.995
-
- Jim Johnson-
- *** Remember, they're only tools - Not a way of life! ***
-