HDTenEightyP/NetNews huggingface dataset:
From: bammi@acae127.cadence.com (Jwahar R. Bammi)
Subject: Re: Can a TSR Malloc()?
Organization: Cadence Design Systems
	<1992Aug12.095216.1@uwovax.uwo.ca>
	<1992Aug12.181935.11706@mnemosyne.cs.du.edu>
Date: Mon, 3 Aug 1992 03:02:42 GMT

In article <1992Aug12.181935.11706@mnemosyne.cs.du.edu> ilepore@nyx.cs.du.edu (Ian Lepore) writes:
>  I've always thought it should be possible to temporarily change TOS's _run
> variable temporarily so that it points to the TSR's basepage during the 
> Malloc() then gets set back to the proper value.  But, I've never tried it,
> it just seemed like a possibility to investigate (despite the fact that 
> Atari warns you to "look but don't touch" on that variable).

	the location of _run is not official and has already changed
in various versions of tos so far. besides the above scheme does not
work (believe me i tried everything possible to make gulam callable
via _shell_p, and never succeeded just because of this problem).
>  
>  Seriously, though...it would be nice to have an alternate form of Malloc()
> usable by TSRs and desk accessories...something where you could pass a  

	i hope you were not serious about this. Its time to become
MiNT aware, and forget atrocities like TSRs and ACCs.

cheers,
--
--
bang:   uunet!cadence!bammi			jwahar r. bammi
domain: bammi@cadence.com
GEnie:	J.Bammi
CIS:    71515,155
Newsgroups:  comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re:  Null arguments with ARGV 
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Thu, 13 Aug 92 05:35:21 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.

 > store *argv[] in the parent, pass a pointer to it
 
 It's been done; it's called xArg.  And quite a nice little standard it
is too, very clean compared to ARGV.
 
 The problem is, Atari declared it to be anathema to multitasking OSes 
they had planned (but not announced) at the time:  they didn't want child
programs poking about in the parent's memory region, and quite rightly so
under a multitasking OS that makes any attempt at isolating applications 
from each other for fault tolerance.

--
- Ian
(void *) where prohibited by law

Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re: Interrupt interference
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Tue, 18 Aug 92 00:12:27 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.

 > the IPL is lowered to 3 to allow other interupts...
 
 It may  take more than that.  The interupts are also prioritized within 
the 68901 MFP chip.  If MFP autovector interupt 12 is running, for example,
then any interupts coming in on vectors 0-11 will be left pending until the
ISR for vector 12 clears the inservice bit.  I don't have my MFP docs handy,
so I'm not sure this affects you -- I vaguely remember that the 200hz timer
is pretty low in the MFP priority list.

--
- Ian
(void *) where prohibited by law
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: format of object files in gcc
Date: 20 Aug 92 01:29:00 GMT
Reply-To: warwick@cs.uq.oz.au

In <bnell.714159659@ferrari> bnell@siemens.com. (Bill Nell) writes:

>Can anyone tell me where to find the format of the .o files used by gcc?
>I don't feel like wading through the source or anything like that.  I would
>prefer some simple docs.  I want to write a program to convert them to DRI
>or GST format so I can link them with object files from my assembler (and
>yes I know gcc can do inline asm but I hate the syntax).  Also, I guess I
>should ask if anyone has already made such a program already to save myself
>the trouble. 


If the MIT 68000 syntax is the problem, I believe GCC has a compiler-time
option (ie. when making gcc) to support Motorola syntax.  Personally, I
prefer MIT now anyway (probably because I never got into Motorola much).


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /      void (if removed)
      v      Brisbane, Australia.        /  
Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Trapping ^C
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Fri, 14 Aug 92 07:10:27 GMT

 What's a good method of trapping a ^C from within a program and ignoring
it?  I've tried using the terminate handler (vector 0x0102) but that gets
control on *any* type of program exit (ie, even if you called exit()).  I
can't find anything in the atari docs that says how to tell if the terminate
handler was invoked by a detection of ^C in DOS, but (oddly enough) they
call that vector the ^C handler in the docs.
 
 (Actually, leave out the "and ignoring it" part of that question.  I can
handle that part of it with a longjmp, I just need to be sure it's a ^C
termination and not a normal program exit.)
 
 (Also, suggestions like "uninstall your 0x0102 handler in the exit() 
routine" are Not An Option for me -- the program could have done a Pterm()
or a gemdos(0) or something else that I can't catch at all.)

--
- Ian
(void *) where prohibited by law

Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: Opening aux1
Organization: University of Western Ont, London
Date: Sun, 16 Aug 1992 18:27:52 GMT

In article <1992Aug15.021512.11496@csi.uottawa.ca>, cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
> How do I open a file to aux (a.k.a. modem1, a.k.a. com1: ...)?

Under TOS, it's called "AUX:" (that name also works under MiNT).
Unfortunately, TOS's Fwrite and Fread system calls are seriously warped,
so using AUX: to do anything useful can be tricky.
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario

Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: Falcon 030 ? nah wait the 040 !
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Sat, 22 Aug 92 18:45:36 GMT

In <BtC3yq.552@acsu.buffalo.edu> chu@acsu.buffalo.edu (John C. Chu) writes:

>In article <1992Aug21.083142.16355@prl.dec.com> amos@prl.dec.com (Samos) writes:
>>and to buy a falcon at 16Mhz 030 is to buy an 'under-TT device'..
>>so wait for the high technology, and buy the falcon 040 !
>                                              ^^^^^^^^^^

>Do we *know* there will even be one? (Rumors don't count.)

Well, at the Atari Messe in  Duesseldorf  a  guy  (his  name  was
Kreidl or Kreindl) gave a talk about the Falcon. He said that the
Falcon 030 was the first one of a whole family of  machines.  The
development of the Falcon 040, he added, is well under way.

>Frankly, I don't think a Falcon 040 will come it at the "right" price
>point for a while...

We can only speculate on the price of  the  Falcon  040,  but  it
seems  to me that Atari has successfully returned to their "power
without the price" slogan after the TT. Let's hope they  continue
to do so.

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
From: boris@sys6626.bison.mb.ca (boris)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes
Date: Sat, 15 Aug 92 03:40:22 CST
Organization: system 6626 BBS, Winnipeg MB

ricks@tcpbbs.pcn.org (Sports Sysop) writes:

> as423@cleveland.Freenet.Edu (Kenneth A. Wallace) writes:
> 
> > 
> >     Taking the MegaSTE back to the dealer is great if there is
> > one within 100 miles! There is almost no ST support in the area
> > I live in, we have a huge wholesaler here but that is not open
> > to the public. 
> >     I find myself in the same situation as J.J. Lehett, a 
> > worthless 1.44 Disk Drive. 
> >     To think Atari put this crap on the market makes me ill, I
> > guess Quality Control is non-existant or they only give a shit
> > about making money and figure 'Hell with the consumer, I bent
> > him over already'. At least I know not to but an Ajax chip, new
> > TOS or another Atari product. And I have and will make sure I
> > discourage anyone from buying Atari and go with IBM or Amiga!
> > 
> > Ken Wallace
> 
> Ken, B&G Electronics is in Lakewood (west side of Cleveland) and is only 
> about 10-15 miles away.  Give us a call at (216)521-2855.
> We are a full line Atari Dealer.  We also sell IBM clones.
> 

I haven't been following this thread, but I assume that someone out there 
has put a 1.44 drive into an mega ste? I had read somewhere that there is 
also a dipswitch (#9, I think) that has to be switched. I beleive it's 
under the hard drive. Hope this helps.

;--- (boris) a user of sys6626, running waffle 1.64
;E-mail: boris@sys6626.bison.mb.ca
;system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8
Newsgroups: comp.sys.atari.st.tech
From: hartlenk@newton.ccs.tuns.ca (Kenneth W Hartlen)
Subject: Detecting GDOS presence
Organization: Technical University of Nova Scotia, Halifax, N.S.
Date: Wed, 19 Aug 1992 00:56:21 GMT

Lattice  C v5.x provides a Lattice specific VDI  function  called 
vq_gdos()  which returns 0 if GDOS is not loaded and non-zero  if 
GDOS is loaded.

The  description  says "This function does not have  an  official 
name  but  uses  an Atari approved  method  for  determining  the 
presence  of GDOS." Anyone know what the "approved method" is  so 
GDOS presence can be checked from Heat & Serve/Sozobon C?

Thanks in advance.


Newsgroups: comp.sys.atari.st.tech
From: an375@cleveland.Freenet.Edu (Jason Baker)
Subject: Re: ACCs Die! Die!
Reply-To: an375@cleveland.Freenet.Edu (Jason Baker)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Mon, 17 Aug 92 13:18:13 GMT


In a previous article, bammi@acae127.cadence.com (Jwahar R. Bammi) says:
>
>	i hope you were not serious about this. Its time to become
>MiNT aware, and forget atrocities like TSRs and ACCs.
>
	Under multitos, won't the only difference between an acc and an
application be that one won't have the gawdawful menu bar?
 
-- 
This signature is copyright 12/6/1992 Simon Oke. All rights reserved. If you
like it and keep a copy for your own use, you owe me $20. Please pass it on
to your friends with all documentation.              Email okes@essex.ac.uk.
NOTE: I'm not okes, but you can reply to him if you want.
Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re: access to the screen using C?
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Fri, 21 Aug 92 02:03:31 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.

 > how do I get a pointer to the screen?
 
   void *screen = (void *)Logbase();
 
 That's all there is to it.  Oh, you've got to #include <osbind.h>.  The
pointer type doesn't have to be void*; char* or short* or whatever you 
want will work fine.  Details of accessing screen memory are semi-complex,
due to the interleaved bitplane pixel organization.

--
- Ian
(void *) where prohibited by law
From: cable@crs.cl.msu.edu (Dan Cable)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: NEC Multisync Monitor
Date: 23 Aug 92 03:49:59 GMT
Organization: Michigan State University

<NCOYNE@ESOC.BITNET> writes:


>I have a NEC Multisync monitor and the question you are waiting for is
>can I use this with my Atari 1040 STfm.
>This question has probably been asked in the past but I didn't have the
>monitor then.
>If the answer is yes then please could send me some technical directions
>such as pin outs and such like.

>Until now I have only been using a TV and I am very excited to have a colour
>monitor, so is my son.

The first question to answer your question is: What scan rate is the monitor 
capable of? ST low res requires 15.75 and most newer multisynch monitors might 
not go this low. If yours won't you can still get medium and hi-rez. In any 
event you'll like it ever so much better than the TV.

Pinouts: Looking at the connector from the rear of the computer pin 1 is the 
upper right hand; pin 4 is the upper left hand; pin 9 is the lower right hand; 
pin 12 is the lower left hand. If you have the book that came with your ST 
these should be shown in a diagram at the back of the book. Pin 1 is Audio 
Out. Pin 2 is Composite Video. Pin 3 is Clock Select. Pin 4 is Mononchrome 
Detect/Clock In. Pin 5 is Audio IN. Pin 6 is Green. Pin 7 is Red. Pin 8 is 
Reserved. Pin 9 is Horizontal Synch. Pin 10 is Blue. Pin 11 is Monochrome. Pin 
12 is Vertical Synch. Pin 13 which is all by itself at the bottom of the 
connector is Ground.

I don't know what your level of expertise with electronics is but if you make 
a wrong connection you could do serious damage to your monitor or computer or 
both. So please be careful and check your connections twice. This isn't the 
same as plugging in a drive or some such where it just doesn't work if you 
make a mistake, so be forewarned.

--
Dan Cable                            e-mail cable@crs.cl.msu.edu
Canton MI USA planet Earth           Compuserve 75266.353
Organisation: European Space Operation Centre (E.S.O.C)
Date: Saturday, 22 Aug 1992 18:36:22 CET
From: <NCOYNE@ESOC.BITNET>
Newsgroups: comp.sys.atari.st.tech
Subject: NEC Multisync Monitor


I have a NEC Multisync monitor and the question you are waiting for is
can I use this with my Atari 1040 STfm.
This question has probably been asked in the past but I didn't have the
monitor then.
If the answer is yes then please could send me some technical directions
such as pin outs and such like.

Until now I have only been using a TV and I am very excited to have a colour
monitor, so is my son.

Thanks in advance

Nick Coyne
NCOYNE @ ESOC.BITNET
DARMSTADT GERMANY
From: chu@acsu.buffalo.edu (John C. Chu)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon 030 ?  nah wait the 040 !
Date: 21 Aug 92 12:56:50 GMT
Organization: UB

In article <1992Aug21.083142.16355@prl.dec.com> amos@prl.dec.com (Samos) writes:
>and to buy a falcon at 16Mhz 030 is to buy an 'under-TT device'..
>so wait for the high technology, and buy the falcon 040 !
                                              ^^^^^^^^^^

Do we *know* there will even be one? (Rumors don't count.)

Frankly, I don't think a Falcon 040 will come it at the "right" price
point for a while...

					john
				chu@acsu.buffalo.edu
Newsgroups: comp.sys.atari.st.tech
From: as423@cleveland.Freenet.Edu (Kenneth A. Wallace)
Subject: Re: Continuing 1.44 Drive Woes
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Fri, 21 Aug 92 04:23:58 GMT


     The MegaSTE I have came with the 1.44 drive, made by Atari.
It was purchased from a Software and Hardware Wholesaler on
the central coast of California, where I happen to live. I can
live with the incompatibility problems, but the 1.44 drives I
feel there is no excuse..

                                       Ken Wallace
From: jeff.molofee@outlan.ersys.edmonton.ab.ca (Jeff Molofee) 
Newsgroups: comp.sys.atari.st.tech
Subject: RE: CONTINUING 1.44 DRIVE
Date: 12 Aug 92 08:00:00 GMT
Reply-To: jeff.molofee@outlan.ersys.edmonton.ab.ca (Jeff Molofee) 
Distribution: world
Organization: Outland BBS-UUCP

Oh, give it a rest... You sound like an IBM user already.  Just because
your drive does not work is no reason to blow up on the net.  Why don't
you just call Atari Canada and explain the situation to them... they
will more than likely help you.
From: jhenders@jonh.wimsey.bc.ca ( John Henders )
Newsgroups: comp.sys.atari.st.tech
Distribution: tp
Organization:  One of these days for sure
X-News: HERMES MMAIL 1.03 Rev. Apr 14 1992
Subject: Re: Opening aux1
Date: Sun, 23 Aug 1992 09:00:16 -0700

Julian_Reschke@ms.maus.de (Julian Reschke) writes:
>Christopher Browne (cbbrowne@csi.uottawa.ca) wrote:
>>How do I open a file to aux (a.k.a. modem1, a.k.a. com1: ...)?
>Try "AUX:".
	Don't you also have to use Fforce and Fdup to create handles to 
attach the files to the ports?


-- 
jhenders@jonh.wimsey.bc.ca
From: simonk@castle.ed.ac.uk (Simon Kinahan)
Newsgroups: comp.sys.atari.st.tech
Subject: Falcon Hard Drives
Keywords: Help
Date: 19 Aug 92 11:17:53 GMT
Distribution: comp
Organization: Edinburgh University


  From the specs of the Falcon which have just been published in
Brittish magazines I understand the thing will have a SCSI 2 port.
  As I understand it it should be possible to hack a current DMA
port Atari hard drive so it fits in this but does anyone know for sure ?
  Might there also be trouble with the current hard disk drivers ?


-- 
Simon Kinahan  simonk@castle.ed.ac.uk   "Only in our dreams are we truly free.
               scgk@dcs.ed.ac.uk         The rest of the time we need wages."
                                            --Terry Pratchett, Wyrd Sisters
From: pjc@cc.ic.ac.uk (Peter Churchyard)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: my floppy drive lies to me: a cry for help...
Date: 20 Aug 92 13:09:45 GMT
Organization: Imperial College

Check that you are not using the wrong type of Diskette!

Check to see if you have a disk cache caching the floppy stuff.

Try write protecting the drive and make sure you get the Drive is
Write protected..

Scan for Viri
From: m_adlard@csd.brispoly.ac.uk (M Adlard)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: cts/rts fix for tos1.0?
Date: 22 Aug 92 15:23:23 GMT
Organization: Bristol Polytechnic, England
X-Newsreader: Tin 1.1 PL5

Peter J Card (pjc@jet.uk) wrote:
: The title says it all. I have a v32bis modem and an old tos1.0 ST.
: Which cts/rts patch program is best used with this pairing. Am I
: correct in thinking that the ST cannot run its rs232 port above 9600
: baud under any circumstances?

I used to run a BBS using an HST modem running at 19200 baud, using tos 1.0
and it worked fine. The patch I used to fix the RTS/CTS was  TOSFIX 2.2.
The best way to fix this would be to update to at least tos 1.4. then use
the RAINBOW tosfix from atari. The tos upgrade here in the uk is not too 
bad (cost wise)


: 
: Is hardware flow control properly implemented on the Falcon, I wonder?
: 
I am not sure about the Falcon, its weird that its not been fixed in other
versions of TOS.. hohum...

MAT.A.
-- 
Matthew Adlard     | m_adlard@csd.brispoly.ac.uk

Any remarks made are my own views only.
From: ricks@tcpbbs.pcn.org (Sports Sysop)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes
Date: Thu, 13 Aug 92 12:31:05 EDT
Organization: TCP BBS, Cleveland, Ohio

as423@cleveland.Freenet.Edu (Kenneth A. Wallace) writes:

> 
>     Taking the MegaSTE back to the dealer is great if there is
> one within 100 miles! There is almost no ST support in the area
> I live in, we have a huge wholesaler here but that is not open
> to the public. 
>     I find myself in the same situation as J.J. Lehett, a 
> worthless 1.44 Disk Drive. 
>     To think Atari put this crap on the market makes me ill, I
> guess Quality Control is non-existant or they only give a shit
> about making money and figure 'Hell with the consumer, I bent
> him over already'. At least I know not to but an Ajax chip, new
> TOS or another Atari product. And I have and will make sure I
> discourage anyone from buying Atari and go with IBM or Amiga!
> 
> Ken Wallace

Ken, B&G Electronics is in Lakewood (west side of Cleveland) and is only 
about 10-15 miles away.  Give us a call at (216)521-2855.
We are a full line Atari Dealer.  We also sell IBM clones.
Organization: Penn State University
Date: Wed, 12 Aug 1992 14:32:39 EDT
From: J.J. Lehett <JJL101@psuvm.psu.edu>
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes

In article <4228@wet.UUCP>, ekrimen@wet.UUCP (Ed Krimen) says:
>
>In article <1992Aug11.005337.4789@usenet.ins.cwru.edu>
>as423@cleveland.Freenet.Edu (Kenneth A. Wallace) writes:
>>
>
>>    I find myself in the same situation as J.J. Lehett, a
>>worthless 1.44 Disk Drive.
>
>Exactly which situation is that?  Do you have an old Mega STE?  Below
>you say you know not to buy an Ajax chip (or am I missing or forgetting
>something)?  You need an Ajax chip for the 1.44meg drive to work.
>

     I would assume that the situation he is referring to (J.J.'s = me)
is that I have a TOS 2.05 MSTe that came with a 1.44 drive.  It didn't
work, and I posted about this a time or two.  I upgraded to TOS 2.06, and
even replaced the Ajax chip thinking it could be defective, so... with these
improvements I 'in essance' should have a reliable 1.44 drive.  This is not
the case.  I have pulled the power supply screw, I have unhooked the Hard Drive
from the power supply to avoid any interference from the power lines, and
I continue to always get a error upon formatting at track 45 when in HD mode.
Yes, I have tried numerous high quality HD disks.
     I have been able to on occasion format a disk on an IBM and bring it
home and read all 1.44 megs succesfully... but never get a successful format
from the desktop.
     I have been told that its really sound like an interference problem,
but with the error occuring at track 45 on formatting no matter what disk
I am using, this doesn't sound like it could be random interfernce, not to
mention that I have as I said pulled the power to the Hard Drive to reduce
the interfernce and still the same repeatable error.  Diamond Format reports
the error as a cannot seek track error (I think that was it).  Once it hits
track 45, you can hear the head going back and forth attempting to 'seek' the
track to no avail, and then it errors out.
     Always on the lookout for more things to try, I have tried just about
everything that has been suggested so far, and I do not have another MSTe
available to try to swap mechs unfortunately.
------------------
J.J. Lehett     : Atari's, puzzles, games, chaos, fractals, math....

  - jjl101@psuvm.psu.edu                 Penn State CAC
  - aa400@cleveland.freenet.edu          Atari 16/32 bit SIG Sysop
  GEnie: JLEHETT2                        Delphi: JLEHETT@delphi.com
Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re: Can a TSR Malloc()?
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Wed, 12 Aug 92 18:19:35 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.

 > can a TSR Malloc()
 > [basically no, because the wrong process would own the memory]
 
 I've always thought it should be possible to temporarily change TOS's _run
variable temporarily so that it points to the TSR's basepage during the 
Malloc() then gets set back to the proper value.  But, I've never tried it,
it just seemed like a possibility to investigate (despite the fact that 
Atari warns you to "look but don't touch" on that variable).
 
 > any current tricks will break under MultiTOS and MiNT
 
 Well then Shame On You for not fixing this problem, Eric. Don't you know
we've all been counting on you to undo absolutely every bad design decision
Atari initially made?  :-)
 
 Seriously, though...it would be nice to have an alternate form of Malloc()
usable by TSRs and desk accessories...something where you could pass a  
pointer to the basepage of the process that should own the memory.


--
- Ian
(void *) where prohibited by law

Newsgroups: comp.sys.atari.st.tech