Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!sri-unix!hplabs!decwrl!decvax!tektronix!uw-beaver!ssc-vax!cxsea!blm
From: blm@cxsea.UUCP (Brian Matthews)
Newsgroups: comp.sys.apple
Subject: Re: SOS-ProDOS compatability
Message-ID: <1003@cxsea.UUCP>
Date: Fri, 14-Nov-86 11:33:40 EST
Article-I.D.: cxsea.1003
Posted: Fri Nov 14 11:33:40 1986
Date-Received: Mon, 17-Nov-86 04:58:43 EST
References: <8611102040.AA04271@ucbvax.Berkeley.EDU>
Reply-To: blm@cxsea.UUCP (Brian Matthews)
Organization: Computer X Inc.
Lines: 20

In article <8611102040.AA04271@ucbvax.Berkeley.EDU> F1.EGS@ISUMVS.BITNET ("E. G. Schnoebelen") writes:
|Re: Apple /// SOS and Apple // ProDOS
|
|The OS opcodes are the same between SOS and ProDOS, so the only changes
|needed to switch OS's is to change the JSR MLI to a BRK or visa-versa.

Well, it ain't that simple. This will work for most of the system calls, but
some of the more important ones, like the memory allocation stuff, is
missing in ProDOS, and a few of the disk calls have slightly different
semantics. The memory one's are the killers. Apple had a nice memory layout
on the /// that would theoretically allow up to 8Meg to be accessed
linearly, but they had to go and put that brain-damaged memory layout in the
//e, //c. Gak.

-- 

Brian L. Matthews
Computer X Inc. - a division of Motorola New Enterprises
..{utcsri!utzoo!mnetor, uw-beaver!ssc-vax}!cxsea!blm
+1 206 251 6811