Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!bionet!agate!russet!archie From: archie@russet.berkeley.edu (Archie Cobbs) Newsgroups: comp.sys.apple2 Subject: Re: ProDos from machine language Summary: i want direct text sendage Message-ID: <1990Mar20.224015.25922@agate.berkeley.edu> Date: 20 Mar 90 22:40:15 GMT References: <1990Mar20.053133.16783@agate.berkeley.edu> Sender: archie@brahms.berkeley.edu Reply-To: archie@brahms.berkeley.edu Distribution: usa Organization: UC Berkeley (does that count?) Lines: 37 In article gt0t+@andrew.cmu.edu (Gregory Ross Thompson) writes: > What you want is "Beneath Apple Prodos" from Quality Software. It >fully documents the ProDOS MLI. I've found the book to be invaluable. >Basically, you call the MLI, tell it what you want it to do, and where >it can find the parameters. It does its thing, and then all you do is >read back the error from the accumulator, and go to the parameter list >and get the returned values. Kinda simple... > > -Greg T. I apologize for not making this clearer. I don't want to deal with MLI or anything. I want to be able to take a BASIC.SYSTEM command such as "CATALOG /RAM" or whatever and send that string directly to ProDos (running under BASIC.SYSTEM) and have it deal with interpreting it. The reason is that I have a program where the user can enter ANY disk command they please. It's ridiculous for me to parse the command and then send it to ProDos when there already exist more competent routines for doing that. I just need an address that bypasses the TRACE filtering junk that ProDos does or something. Maybe it would be help to state that this program is actually attached to an Applesoft program like this: 10 ON ERR GOTO 30 20 CALL XXX1 30 CALL XXX2 So the idea is that DOS thinks an Applesoft program is running, so if the user enters a bogus command, control goes back to my program where the error is printed out and life is restored to normal. This avoids MLI's and such, which is what I want to do if possible because it means more stuff to learn for a silly program that's probably not worth the trouble in the first place. If this book has locations for doing this kindof thing then I'll get it. Thanks. -Archie Archie Cobbs archie@brahms.berkeley.edu