[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple// CP/M question



In article <ztbQ5.7314$tU2.61660@news-server.bigpond.net.au>,
Peter Watson <paw77@NOhotmailSPAM.com> wrote:
 
> "Henry Broekhuyse" <broekh@unixg.ubc.ca> wrote in message news:rc1Q5.126325
>> Presumably, once that is done, you have some way of printing these files
>> from within ProDOS. Incidentally, what was used to create the original
>> "source code" you are trying to print out? If it was in Microsoft Basic,
>> the code may be "tokenized" and might not necessarily be stored as an ASCII
>> text file.
> 
> Suggestion for what to do if a program was originally a BASIC program.
> 
> Disclaimer: It is a *lot* of years since I last looked at this stuff!
> 
> If he can still actually *run* CP/M on the Apple II, then he could try
> running MBASIC, loading the program, then saving it as an ASCII text file.
> From memory, the syntax is something like this:
> 
> SAVE "program.txt",A
 
You can also do:
 
    SAVE "program",A
 
and the program will be saved, in ASCII format, in the file PROGRAM.BAS
 
> If you can't run CP/M anymore, then the file(s) can be copied to ProDOS
> using the Chameleon utility (as others have mentioned). I seem to remember
> that the layout of an MBASIC file was pretty similar to Applesoft BASIC (not
> too surprising, really!),
 
Unfortunately, that's wrong!  The tokenization of Applesoft programs is
really simple:
 
Line number     2-byte binary
Line length     2-byte binary
Tokens          1 byte per reserved word or ASCII character
End-Of-Line     00h
 
In Applesoft only the reserved words are stored as tokens; everything else
is stored in plain ASCII.
 
In MBASIC the tokenization is much more complex.  Reserved words are stored as
tokens, as in Applesoft, but other things are tokenized too:
 
Integers:           <token> + value as 2-byte binary
Short reals:        <token> + value as 4-byte binary, Microsoft FP format
Long  reals:        <token> + value as 8-byte binary, Microsoft FP format
GOTO/GOSUB target:  <token1> + target line as 2-byte binary
                    <token2> + offset to target line in tokenized program
 
+ some other things I don't remember now.
 
Note the two different tokenization of GOTO/GOSUB: the first form is
used before the GOTO/GOSUB has been executed, while the second form
is used when the GOTO/GOSUB has been executed at least once.  This
means MBASIC need not look up the target line more than once even if
the GOTO/GOSUB is executed thousands of times in a loop.  A similar
method is used for user-defined functions and for RESUME <lineno>.
 
> so it may be possible to hack one of the many Applesoft "lister" programs
> around to print the file(s).
 
Not quite -- it's much more complex to write a de-tokenizer for
MBASIC programs than for Applesoft programs.  But someday I might
write one, as part of my FID program (the source FID.C is available
freely at http://hotel04.ausys.se/pausch/apple2): today it handles
only DOS 3.3 disks but contains integral de-tokenizers for Applesoft
(really simple), Integer Basic (somewhat more complex) and S-C
Assembler (quite simple too) files.  I plan to extend it to handle
Apple CP/M disk images as well, and in that context an MBASIC
de-tokenizer would be natural.
 
Ultimately I would want it to work for Apple Pascal and Apple ProDOS
disk images too, but Apple CP/M is next on my priority list.

-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch