feldman@umcp-cs.UUCP (11/08/83)
I have had my Apple ][+ for about four years, and for the last
three I have used Apple Pascal (AP). AP is by far the nicest
OS available on the Apple, however that is not to say that it
doesn't have its problems. AP is Apple's version of the UCSD
p-machine, A software simulated computer that runs p-code.
Supplied with AP is the Pascal language and a development
environment which includes a screen editor, a file handler, an
assembler (6502 for the Apple), a linker, and a variety of
library routines and utility programs. Considering that the
only alternative until recently to AP was Apple's DOS 3.3
(DOS), a pitiful excuse for anything (let alone an OS), AP
was by far the choice for software development. Here are the
pros and cons of AP as I see them.
The Pascal language (compiler) as supplied with AP is very
powerful. Except for the lack of a dispose function, the
Pascal has all of the features found on mainframe
implementations. I have on occasion written programs in AP and
phoned them in to Maryland's Univac 1100/80 (dinosaur) having
them run with little or no changes. AP has real file handling
as opposed to DOS's ctrl-D garbage. Units, which are very much
like Ada packages, are supported. Linking of externally
compiled/assembled routines is supported. What else could you
want in a language ?-). The problems voiced in the net about
compiler error #253 (Procedure too long) is overstated. If a
procedure is generating more than 600 words of code, it should
be more than one procedure. AP is not the only Pascal that
gives a procedure too long error. Pascal/VS running on
Maryland's IBM 4341's also does this (not at 600 words though).
Many students taking introductory computer courses here have
run into this error when they tryed to place all of there code
(about 50 writelns) into the main program.
The editor supplied with AP is a full screen editor. While it
doesn't have a lot of the nice features found in other editors,
such as macros and programmable tabs, it sure beats Applesoft's
esc-sequences. The only other problem I have with the editor
is its size limitation. The maximum amount of text it can edit
is about 20k. The editor and the compiler work nicely
together. If the compiler catches an error in your program you
can have it put you in the editor write where it caught the
mistake. This works most of the time, except when you start
using a lot of include files.
The file handler is called the filer. It is used for copying,
deleting, and renaming files as well as setting the date,
setting default volume names, etc., and it has wild cards. The
file structure used in AP uses contiguous blocks on the
diskette. This means that the disk must be K(runched whenever
free space is in lots o' little patches. People have
complained about this. They have asked why must AP do this
when DOS doesn't. The answer is speed. Haven't you ever
wondered why AP I/O is Soooo much faster than DOS I/O? The
"BASICS" disk provided with DOS and AP for loading the language
card with the basic not in ROM uses AP format. That's why it
can load the language card so quickly.
The assembler provided with AP is very nice. It supports
macros and everything (golly gee). My only problem with it is
that it assembles 6502 code. More on this later.
For the $295 it costs (I believe that's the cost for just the
software), it ain't bad. It does require 64k of RAM, and if
you don't want to go crazy, you should have two disk drives.
My problems with the system follow. It's slow. Sloooooooow.
6502 (8 bit brain damaged micro processor) running at a measley
1Mhertz + a software simulated machine on it =
slooooooooooooooow. The other big problem I always run into is
EXEC ERROR #4 (stack overflow). The only answer to this is to
segment and swap procedures. This leads to (you're not going
to believe this) slower execution time. I really hate waiting
20 minutes to get a stack overflow right before getting the
output. These problems really aren't with AP. They're with
the semi-evolved brain damaged device we jokingly call a
computer: The Apple ][ :-(.
Other things which bother people in AP include its menu driven
"shell", its lack of I/O redirection, and the Apple's lack of
interrupts. Part of AP's slowness comes from its type ahead
buffer. Since the Apple's keyboard is not interrupt driven, AP
must poll the keyboard between executing p-code instructions.
This lack of keyboard interrupt also means that the soft break
(default ctrl-@) won't alway's stop a program. There are many
other little annoyances, such as the fact that swapon; in
chainstuff doesn't work until another program is chained to,
but they are too numerous and technical to write a general
article on.
As far as micros go, I'd like to have a computer with a 68000,
a meg or so of memory, a few megs of disk space, and a
Un*x/Un*x like OS. But until then I'll keep my brain damaged
Apple, and keep running Apple Pascal :-).
-- mark feldman
UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
CSNet: feldman@umcp-cs
Arpa : feldman.umcp-cs@CSNet-relaysdh@rabbit.UUCP (11/11/83)
In response to Mr. Feldman's article, I have the following remarks:
DOS is not supposed to be a screen oriented editing system. Take a good
look at the meaning of the acronym: Disk Operating System.
The reason it is slow, is a problem with timing in the loop that loads files.
Since files can be spread out all over a disk instead of in predefined blocks,
The disk is much more space efficient.
Using the RWTS subroutine, a VERY simple assembly language proigram can be
written to load files in a time that makes most people cringe. I still don't
know why thos pholks at Apple never bothered with shaving off the cycles in
their loaders, because a few cycles can make a world of difference in access
time.
I think the AP assembler is a dinosaur. And that's being kind. Anyone who
has used the SC 4.0 assembler or the SC macro assembler will understand why.
Speed: The SC can assemble very large programs while printing out the
listing, in a fraction of the time the AP assembler with no screen output.
Convenience:The SC has some very nice built in features including, a good
line editor, assembly to either disk or memory. target address functions,
and an include file feature just to name a few.
As a bonus, the macro assembler can exist either as a program in RAM or as
a language if a language card is available.
I'm biased. I know it. Once I entered the realms ofassembly language,
I decided that all other languages were for nerds.
and for those of you who enjoy noise, I leave you with the following program:
300: DEC $00
302: BNE $309
304: BIT $C030
307: DEC $00
309: DEC $01
30B: BNE $314
30D: BIT $C030
310: LDA #$FE
312: STA $01
314: LDA #$02
316: JSR $FCA8
319: JMP $300
P.S. don't try this from PASCAL since you will not have access to the wonderfull
subroutines that already exist in ROM.
It only a program stuck way up in RAM to move the disk head around, load, save,feldman@umcp-cs.UUCP (11/14/83)
[these are non blank characters]
In response to rabbit!sdh's (What is his name?) response to my
article on Apple Pascal, I have the following to say:
My main use for a micro right now is developing software which is
portable. I have written business software (yuk) to deal with
very large files on a hard disk in AP. For DOS to come anywhere
close to AP's speed in random file access I would have to of
hacked DOS up quite a bit. Maintaining the program would be
lot's o' fun. AP walks the line between speed and porability. I
agree that assembly running under turbo-charged DOS is faster
than AP, but it really isn't very portable. I also believe that
there are other OSs that are more portable than AP such as UCSD
Pascal IV.1. Unfortunately IV.1 (or IV.anything for that matter)
currently runs much slower than AP. As I stated in my original
article, I would much rather have a 16 bit or 32 bit micro
capable of running one of the larger OSs such as Un*x.
The reason that the AP assembler runs so slowly is that it was
not written specially for the apple, or the 6502 for that matter.
Both AP and DOS should be getting faster/better in the future as
I heard/read that Apple was coming out with new versions of both.
The new DOS has a new name, but it escapes me at the moment. If
you look at the new DOS 3.3 Master that comes with the Apple
][/e, you will see that they now have a routine that does load
the language card quickly (in about 1/4 the normal DOS time).
Hacking is what makes the Apple running under DOS so much fun. I
liked your little assembly routine
300: DEC $00
302: BNE $309
304: BIT $C030
307: DEC $00
309: DEC $01
30B: BNE $314
30D: BIT $C030
310: LDA #$FE
312: STA $01
314: LDA #$02
316: JSR $FCA8
319: JMP $300
though I prefer
314: LDA #$01
- a matter of taste. As for assembly language being the only
language (that isn't for nerds), I do hope you weren't just
talking about 6502 assembly. It is, after all, just barely
passable as a computer's cpu :-). The only routine that you are
using from ROM is the wait routine ($FCA8) which can be easily
written. For most applications, the NOTE routine supplied by AP
is good enough for making sounds on the Apple's speaker.
AP can also be hacked up a bit. SYSTEM.APPLE (the p-code
interpreter) just sits there, waiting to be patched.
You see, I'm not saying DOS is bad or AP is great. I am just
justifying AP's existence. There are some things it does well,
some things it doesn't. Using it or not depends on your
application. Unfortunately I don't see an operating system that
runs on the Apple that does everything well, so the choice must
be made: DOS, AP, other, a combination. Arguing over which OS
is better is ridiculous. You gotta list the pros, list the cons,
and make your decision.
-- mark feldman -- UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
CSNet : feldman@umcp-cs
Arpa : feldman.umcp-cs@CSNet-relay