Re: What exactly WAS Apple Pascal?

[pausch@saaf.se (Paul Schlyter)]

In article <HGLJc.2560$54.31954@typhoon.sonic.net>,
Don Bruder  <dakidd@sonic.net> wrote:
> In article <cd7lc2$q52$1@ottoman.cs.fiu.edu>,
>  Zorin the Lynx <yakko@zorin.org> wrote:
.................
>> A pointer to a FAQ or other document explaining Apple Pascal would be 
>> great too...
> 
> If you know what CodeWarrior is on the Mac, then you've got the basic 
> idea of what Apple Pascal was - An early IDE, or "Integrated Development 
> Environment" that allowed the user to program the Apple II in Pascal 
> rather than BASIC. (Although I never encountered it personally, I did 
> hear rumours of a Fortran system that was identical to the Pascal 
> system, except that it had compiler/linker/library/etc. modules intended 
> for developing in Fortran.

Yep, there was an Apple Fortran too, which was Apple Pascal whtih the
Pascal compiler and libraries exchanged with the equivalents for
Fortran instead.  Apple Fortran implemented the Fortran-77 subset
version, which made it quite useless since the subset excluded double
precision and complex numbers, features wihch are quite useful to
people into number crunching.  And since Fortran is good for number
crunching but hardly anything else, removing double precision and
complex numbers from Apple Fortran made Apple Fortran quite useless.

So I used Microsoft Fortran-80 on my Apple CP/M system instead: it
had double precision numbers but lacked complex numbers.  After digging
in the internals of Fortran-80 for some time, I ended up adding complex
numbers to that compiler, both runtime library support and syntax and
code generation support for the compiler itself.

The UCSD system was a single language system.  If you programmed in
Apple Pascal and wanted to switch to Apple Fortran, a reboot with a
different boot disk was necessary.  This I considered another
disadvantage compared to e.g. CP/M: there you just started whatever
compiler or IDE for whatever programming language you had available
with a suitable command line and perhaps also a suitable disk change.
No reboot was evern necessary to switch languages.

> Another rumored variant I heard of  but never saw myself was COBOL package) 

That I think is just a rumor -- I never heard of any Cobol for the UCSD
system.  You might confuse this with Microsoft Cobol-80: Microsoft sold
Apple versions of their Fortran-80, Cobol-80 MAC-80 (a macro assembler)
and Basic Compiler for CP/M, at substantially reduced prices.  The MAC-80
Apple version even had the capability of assembling 6502 opcodes, a
capability the standard version of MAC-80 lacked.
 
> Whatever the language, it was a compiler that spit out "P-code" bytes - 
> Pseudo-assembly code for an imaginary (until later, when someone 
> actually cooked up a hardware CPU to match the specs of the until-then 
> purely emulated) processor, specced out by UCSD. It also had an editor 
> for creating files to feed to the compiler, a file manager that was more 
> or less the OS, libraries, a linker, a debugger, and an emulation module 
> that would run the P-code emitted by the compiler.
> 
> It used its own disk format, catalog structure, and so on, which 
> generally made accessing disks outside of the pascal system a pain in 
> the rump at best, and next to impossible at worst. Add the "sin" of 
> programs written with it not being proper "ready-to-run" standalone 6502 
> code (When you ran the program, you actually fired up what amounted to 
> an emulator for the pseudo-CPU,

That emulator for the pseudo-CPU (the "P-machine") always resided in RAM
though, in the language card, both banks.

The Apple P-machine also had an improved RWTS which allowed one track of a
floppy to be read at one revolution of the floppy, by doing the
de-nibblizing of the data "on the fly" while reading the data.  Other
Apple OS'es (DOS 3.3, ProDOS) required 2 revolutions of a floppy to read
one track; Apple CP/M required 3 revolutions.  And the sectors were
interleaved accordingly.

> then it ran your program on the emulated 
> chip) and I thought it had some serious holes. At the same time, it 
> could be made quite useful, within its limitations.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/