Basic Apple II commands?
Jason Dyer
since I've used an Apple and have forgotten the commands. Also,
I can't seem to work out how to use any disk other than the system.dsk
file with the program locking up on me. Can anyone help?
--
Jason Dyer - jd...@indirect.com
Peter Steiger
: In article <43iv1b$r...@globe.indirect.com>, jd...@indirect.com (Jason Dyer) writes:
: > I got an emulator up an running (APL2-EM3) but it has been ages
: > since I've used an Apple and have forgotten the commands.
> Choose to edit the file and carry on going until you hit [slot 6] where
> the floppy drive setup is. The two disk images used are entered under
> A= and B=. Unfortunately there is no way short of multitasking to
> change the disk images after loading,
> so you can only run two-disk programs.
Well, here are a coupla tips that might help. I rummaged through my
closet until I found my trusty ol' _Apple ][ The DOS Manual_ ( (c) 1980
by Apple Computer, Inc.) complete with instructions for swapping out the
PROMS on your drive controller to upgrade it from 13-sector to
16-sector. Ahh, the days of open architecture! But I digress...
First of all, just because the default APPLE.INI file contains nothing
useful for the other slots doesn't mean you can't make use of 'em. You
can easily hang a disk drive off slot 5, and I can't see why you can't
add another pair from other slots. Then just CATALOG Sx,Dy to get the
right slot/drive catalog (yup, here it says you can have a fifth and
sixth drive, "... and so on.")
Now, by default Apple will boot from S6D1. Once there, however, you can
force it to boot from another drive with the command PR#x where x is the
slot; of course only disk 1 will boot from that slot. Still, it means
you can have controllers in slots 4-7 and use S6D1 for a standard DOS
master, and then boot different games from different slots.
I had to look up that PR#6 stunt: All I remembered was the machine
language monitor hack (type CALL -151 from the Applesoft prompt and
you'll find yourself at the machine language prompt) of typing 6 then
ctrl-P {ENTER} to boot from slot 6.
This manual is a wealth of history: "A single diskette can hold over
1,146,000 bits of information." (that's about 143K). Everybody here
remember using disks that small?
As someone mentioned earlier, programs saved as Applesoft (BASIC) can be
run with the RUN programname (or RUN programname,Sx,Dy, where x is the
optional slot # and d is the optional drive #) and programs saved as
binary can be run with the BRUN command. Do a CATALOG of the disk in
question and look for an "A" (or, rarely, "I" for Integer BASIC) or a "B"
at the leftmost part of the catalog listing. If the file name has an
asterisk between the language flag and the filename, that's the read-only
indicator. For whatever that's worth.
Also, the manual notes that there is no way to tell which is the startup
(autoexec, if you will) program; the INIT command stores DOS on a
diskette and saves whatever program is currently in memory as the startup
program. And while I'm on the subject of quirks, any and all ASCII codes
are valid as filenames, which means that sneaky programmers may very well
have saved files with hidden control-code characters embedded.
Hmmmm. On a whim, I tried storing extra language cards to other slots to
see if it would buy me more memory. No chance...
On the other hand, is there any reason we couldn't take the typical disk
image, multiply it by 10 or 20 meg, and get a PRODOS-formattable hard disk?
pbs, having serious Applesoft flashbacks
Jean-Marc Tanzi
|>
|> This manual is a wealth of history: "A single diskette can hold over
|> 1,146,000 bits of information." (that's about 143K). Everybody here
|> remember using disks that small?
That was 63K bigger than the 80K standard of that time for 5.25 (on CP/M boxes
mostly), due to the clever GCR coding. Yes, I remember using 80K disks.
--
==========================================
Jean-Marc Tanzi - <j...@cma.cma.fr >
Paul Schlyter
<mlna...@uctvms.uct.ac.za> wrote:
Article: 3332 of comp.emulators.apple2
> The only Apple commands I can remember (and use) is CATALOG to get the
> directory of a disk, and RUN and BRUN to run programs with an A or B in
> front of them in the catalog. If there are other commands (e.g. typing
> a text file to the screen) I also like to know them.
There was no "type" command in Apple DOS. The commands I remember are:
CATALOG [S<slot>|D<drive>|S<slot>,D<drive>]
LOAD <basicfilename>[,S<slot>][,D<drive>]
RUN <basicfilename>[,S<slot>][,D<drive>]
SAVE <basicfilename>[,S<slot>][,D<drive>]
BLOAD <binfilename>[,A<addr>][,S<slot>][,D<drive>]
BRUN <binfilename>[,A<addr>][,S<slot>][,D<drive>]
BSAVE <binfilename>[,A<addr>[,L<len>]][,S<slot>][,D<drive>]
OPEN <textfilename>[,S<slot>][,D<drive>]
CLOSE <textfilename>[,S<slot>][,D<drive>]
DELETE <filename>[,S<slot>][,D<drive>]
RENAME <oldfilename>,<newfilename>[,S<slot>][,D<drive>]
INIT [S<slot>|D<drive>|S<slot>,D<drive>]
<addr> and <len> could be given as decimal numbers, or if prefixed by
a '$' as hex numbers. <slot> refers to the slot of the disk
controller (1 to 6) and <drive> to the drive connected to the disk
controller (1 or 2). The "INIT" command formats the disk, erasing
everything on it (try THAT on your Apple II emulator... :-)
The "OPEN" and "CLOSE" commands couldn't be issued from the prompt but
had to be issued from within a running Basic program. Once a textfile
was opened, all I/O (INPUT/GET/PRINT statements) went to/from that file
instead of the screen. This was of doing file I/O was awkward to say
the least, but allowed Apple to add file I/O to two Basis interpreters
that knew nothing about files or disks in the first place.
There were also "READ" and "WRITE" commands, used to position the
file pointer properly for random access I/O to 'T' type files, but
I don't remember the syntax for these. THey required additional
parameters to the "OPEN" command specifying the random record length.
On Apple DOS 3.2, file lengths were limited to max 32 KBytes,
including text files !!! This limit was removed in Apple DOS 3.3
Apple DOS commands were issued from Basic through PRINT statements
starting with a Ctrl-D, e.g. 10 PRINT CHR$(4);"CATALOG"
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Nybrogatan 75 A, S-114 40 Stockholm, SWEDEN
e-mail: pau...@saaf.se paul.s...@ausys.se
Burkhard Lehner
I still can remember 3 more commands, that worked in DOS 3.2 and DOS 3.3.
They worked on Text-Files:
EXEC <filename>[,S<slot>][,D<drive>]
This one read the contents of a text file (remember: the letter for a text
file was 'T') and interpreted the contents of the file as if the text was
typed in on the keyboard. This worked in Integer-Basic as well as in
Applesoft-Basic.
This command can be used to do something like a batch-program. If you have
for example a text file named "DO IT" with the following contents:
NEW
10 HOME
20 PRINT "HELLO, WORLD"
30 END
RUN
SAVE HELLO WORLD
RENAME HELLO WORLD,HELLO APPLE
and then type "EXEC DO IT" (while being in Applesoft-Basic), every program
in memory will be deleted (NEW), a new program is typed in (just as if you
typed the lines on your keyboard), the program is run (which should produce
the line 'HELLO, WORLD' to be written to screen), it is saved to disk with
the name "HELLO WORLD" and after that the name is changed to "HELLO APPLE".
(It is an other problem to produce such a textfile!)
This will also work in Integer-Basic, but the program won't run. (The
command
HOME doesn't exist in Integer-Basic. I think you have to use a "CALL
...."!)
On the DOS 3.2 Master Disk there was a nice example of this command. I think
it was called "DO'ER" or so.doesn't run in integer
MON [C][I][O]
NOMON [C][I][O]
These commands turn on/off the monitoring of text file operations.
Monitoring
means, that the textual information of every read or write operation
to a text
file is also written to the screen.
There are three types of monitoring:
C command monitoring Dumps everything read by an EXEC-Command
to screen
I input monitoring Dumps everything read from a text file
to screen
(but not which is read by EXEC)
O output monitoring Dumps everything written to a text file
to screen
So use "MON C" to turn command monitoring on, "NOMON C" to turn it off,
"MON CIO" to turn all of them on etc.
"MON C" and "NOMON C" have a similar function as "echo on" and "echo
off" in
MS-DOS.
If you used "MON C" before typing "EXEC DO IT" in the example above, every
line of the textfile would have been dumped to the screen before interpreta-
tion. Using "NOMON C" instead, would show nothing on the screen but 'HELLO
WORLD', that is printed by the BASIC program.
The combination of these three commands can help you to have a quick
(and dirty)
dump of a text file: Simply type "MON CIO" and after that "EXEC
<filename>". If
the text file contains a normal text, this will produce a lot of beeps
and
"SYNTAX ERROR" messages, because the text is no valid
Applesoft-BASIC-Program,
but you will have a glance at the text file.
I think I read this tricky tip in "Apple ][ The DOS Manual". It was a
very funny
manual. I remember it said: "A floppy disk can store the information for
a long
time, unless you play frisbee with it or the dog bites it!" (I don't
know what
it sounds exactly).
Does anyone else remember any jokes in the manual?
Paul Schlyter
Peter Steiger <p...@metronet.com> wrote:
> Also, the manual notes that there is no way to tell which is the startup
> (autoexec, if you will) program; the INIT command stores DOS on a
> diskette and saves whatever program is currently in memory as the startup
> program.
the system tracks, and can of course be read by any program reading
the correct sector of the disk.
> And while I'm on the subject of quirks, any and all ASCII codes
> are valid as filenames, which means that sneaky programmers may very well
> have saved files with hidden control-code characters embedded.
inverse and blinking characters. This was a common way to create
"customized" directory listings in the early 80'ies: the files with
inverse and/or blinking chars in filenames could not be accessed,
they were just visible in a CATALOG listing. Of course end-of-line
characters could be inserted in filenames too, making a filename
span several lines on the display.
Paul Schlyter
Jean-Marc Tanzi <j...@legend.cma.fr> wrote:
>In article <43o4m0$q...@feenix.metronet.com>, p...@metronet.com (Peter Steiger) writes:
>|>
>|> This manual is a wealth of history: "A single diskette can hold over
>|> 1,146,000 bits of information." (that's about 143K). Everybody here
>|> remember using disks that small?
>
>That was 63K bigger than the 80K standard of that time for 5.25 (on CP/M boxes
>mostly), due to the clever GCR coding. Yes, I remember using 80K disks.
And the original Apple II disks weren't even that large -- they used 13
instead of 16 sectors per track, which means they were able to hold only
108K of data. The 143K disks were introduced with the Apple Pascal system
and later included in DOS 3.3.
But expressing the data size in bits may of course look more impressive
to some. Why not use milli-bits or micro-bits instead? Suppose we had
that 80K standard 5.25" disk, then we could say:
"This disk holds 80,000,000,000,000 nano-bits of information"
:-)