From Newsgroup: comp.sys.apple2

Randy McLaughlin <randy@nospam.com> wrote in message news:Pp_Ka.616$Im5.226@fe03.atl2.webusenet.com...

There are lots of strange (and weird) computer programming languages, most all of these languages are history, RPG and others that had big enough support (IBM in the 60's and 70's is as strong as it got) continue to be
used in one way or another.

Look at LOGO, a non computational computer programming language
that was little more than a toy (the same basic language was written into some toys).

LOGO had a very stable and efficient implementation for recursion that
allowed it to run on very limited microcomputers. IMHO it would be
difficult or impossible to find any "serious" language of the day that could handle recursive algorithms as efficiently with the limited memory space,
stack and CPU speed of the 1980s Apple II.

There were other implementations of LISP available for the Apple II (e.g.
Owl Lisp), but they were not nearly as stable.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <_QfRa.10639$kI5.5692@nwrddc02.gnilink.net>,
"M. Pender" <mpender@hotmail.com> wrote:

Randy McLaughlin <randy@nospam.com> wrote in message news:Pp_Ka.616$Im5.226@fe03.atl2.webusenet.com...

There are lots of strange (and weird) computer programming languages, most all of these languages are history, RPG and others that had big enough support (IBM in the 60's and 70's is as strong as it got) continue to be used in one way or another.

Look at LOGO, a non computational computer programming language
that was little more than a toy (the same basic language was written into some toys).

LOGO had a very stable and efficient implementation for recursion that allowed it to run on very limited microcomputers. IMHO it would be
difficult or impossible to find any "serious" language of the day that could handle recursive algorithms as efficiently with the limited memory space, stack and CPU speed of the 1980s Apple II.

There were other implementations of LISP available for the Apple II (e.g.
Owl Lisp), but they were not nearly as stable.

- Mike

Logo was a delightful environment, but not the only "serious" recursive
stack machine in wide use on Apple II.

Apple's UCSD Pascal implemented a very efficient stack machine. Each
stack frame had a static and dynamic link to allow recursion from an
arbitrary nesting level.

Every implementation of Forth I saw on the Apple II (including the FIG
Forth I adapted to ProDOS) used at least two stacks. Recursion was not
as syntactically transparent as Pascal, but it was quite efficient.

Both of these were used in serious development and deployed commercially
into the 90's.

[Newsgroups line altered.]

John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

John B. Matthews <nospam@nospam.com> wrote in message news:nospam-967967.21253716072003@clmboh1-nws3.columbus.rr.com...

Logo was a delightful environment, but not the only "serious" recursive
stack machine in wide use on Apple II.

Apple's UCSD Pascal implemented a very efficient stack machine. Each
stack frame had a static and dynamic link to allow recursion from an arbitrary nesting level.

Apple Pascal was a half-baked implementation of the language that offered
very limited system access. It was a compiled Fortran program that
inherited all of the limitations of the Fortran language, as well as those
of Pascal.

For example, a program could not have more than 3 files open at once, system-wide.

Every implementation of Forth I saw on the Apple II (including the FIG
Forth I adapted to ProDOS) used at least two stacks. Recursion was not
as syntactically transparent as Pascal, but it was quite efficient.

I never played much with Forth, so I'll withhold any opinion on that.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <nospam-701F83.06305517072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:

In article <ShnRa.14919$kI5.9342@nwrddc02.gnilink.net>,
"Michael Pender" <mpender@hotmail.com> wrote:

......................

Umm, the Fortran compiler was written in Pascal and assembler to
run under the p-system, not the other way around. It was
copy-protected, slow, buggy and never got updated. Although the
number of open files was never a serious limitation, the
primitive disk allocation scheme was prone to fragmentation.

The rest of the system was quite robust: Apple Pascal disk I/O
was very efficient; it was the forerunner of ProDOS. The
p-system was used to develop scores of widely used applications,
including PFS, Jack, VersaForm, QuickFile, Smartcom, Apple
Business Graphics, Wizardry and the AppleWorks tutorial. The
UCSD language extensions for strings and separate compilation
were implemented in scores of subsequent systems for Apple ///,
Lisa and Macintosh, not to mention Turbo Pascal and Delphi.

Turbo Pascal versions 1 to 3 didn't support separate compilation
though: the entire program had to logically reside in the same
source file. The only way to split it up was through INCLUDE
directives.

I never liked Apple Pascal, and my first serious experiences
with Pascal was on Turbo Pascal 1 running on Apple II CP/M:
it was ...s.o...m.u.c.h...f.a.s.t.e.r... - on the same hardware!

I also liked Turbo Pascal's floating-point format, which was 6 bytes,
a good compromise between the usual 4 bytes (too imprecise) and 8
bytes (too slow). OTOH Applesoft with its 5-byte floating-point
format was quite good too. Here Apple Pascal was a definite step
back, to 4-byte floating-point numbers. And Apple Fortran was no
better, since it implemented only the subset standard of Fortran-77
and thus lacked e.g. DOUBLE PRECISION floating-point numbers - quite
a serious omission in a language supposedly intended for number
crunching!

To me, the most compelling feature was being able to mix low-
and high-level code cleanly.

Here Turbo Pascal did shine. If you wanted to access absolute memory
locations in Apple Pascal, you had to play some tricks with pointers
and variant records. In Turbo Pascal it was much much simpler: it
had a non-standard extension -- the mem[] array (of type "byte",
another Turbo Pascal non-standard extension) was predefined in
Turbo Pascal and _was_ the physical memory! So if you wanted to
read the keyboard directly in Turbo Pascal (Address $C000 for the
6502; it was remapped to 0E000h for the Z80) you just used 0E000h
as an index into the mem[] array.

In Turbo pascal you could also add machine code directly through
the "emit" statement (still another non-standard Turbo Pascal
extension). However, TP lacked a full-fledged inline assembler,
you had to supply the hex opcodes yourself.


I wrote a Turbo Pascal utility once which did read Apple Pascal disks
and transferred the Pascal source files (or any other text file) over
to CP/M disks, to make them accessible to Turbo Pascal. After having transferred all my Apple Pascal source files over to CP/M, I almost
never touched Apple Pascal again.

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2



Paul Schlyter wrote:

In article <nospam-701F83.06305517072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:

In article <ShnRa.14919$kI5.9342@nwrddc02.gnilink.net>,
"Michael Pender" <mpender@hotmail.com> wrote:

......................

Umm, the Fortran compiler was written in Pascal and assembler to
run under the p-system, not the other way around. It was
copy-protected, slow, buggy and never got updated. Although the
number of open files was never a serious limitation, the
primitive disk allocation scheme was prone to fragmentation.

The rest of the system was quite robust: Apple Pascal disk I/O
was very efficient; it was the forerunner of ProDOS. The
p-system was used to develop scores of widely used applications,
including PFS, Jack, VersaForm, QuickFile, Smartcom, Apple
Business Graphics, Wizardry and the AppleWorks tutorial. The
UCSD language extensions for strings and separate compilation
were implemented in scores of subsequent systems for Apple ///,
Lisa and Macintosh, not to mention Turbo Pascal and Delphi.

Turbo Pascal versions 1 to 3 didn't support separate compilation
though: the entire program had to logically reside in the same
source file. The only way to split it up was through INCLUDE
directives.

I never liked Apple Pascal, and my first serious experiences
with Pascal was on Turbo Pascal 1 running on Apple II CP/M:
it was ...s.o...m.u.c.h...f.a.s.t.e.r... - on the same hardware!

Well, to be *really* picky, Paul, as you know, it wasn't the same
hardware. It ran on a Z-80 card of some kind. I would be curious to know
if it ran, as you describe, on a Microsoft Soft80 card, or it if took
the PCPI card's much faster processor and independant 64K of RAM to run faster.

Roy

I also liked Turbo Pascal's floating-point format, which was 6 bytes,
a good compromise between the usual 4 bytes (too imprecise) and 8
bytes (too slow). OTOH Applesoft with its 5-byte floating-point
format was quite good too. Here Apple Pascal was a definite step
back, to 4-byte floating-point numbers. And Apple Fortran was no
better, since it implemented only the subset standard of Fortran-77
and thus lacked e.g. DOUBLE PRECISION floating-point numbers - quite
a serious omission in a language supposedly intended for number
crunching!

To me, the most compelling feature was being able to mix low-
and high-level code cleanly.

Here Turbo Pascal did shine. If you wanted to access absolute memory locations in Apple Pascal, you had to play some tricks with pointers
and variant records. In Turbo Pascal it was much much simpler: it
had a non-standard extension -- the mem[] array (of type "byte",
another Turbo Pascal non-standard extension) was predefined in
Turbo Pascal and _was_ the physical memory! So if you wanted to
read the keyboard directly in Turbo Pascal (Address $C000 for the
6502; it was remapped to 0E000h for the Z80) you just used 0E000h
as an index into the mem[] array.

In Turbo pascal you could also add machine code directly through
the "emit" statement (still another non-standard Turbo Pascal
extension). However, TP lacked a full-fledged inline assembler,
you had to supply the hex opcodes yourself.


I wrote a Turbo Pascal utility once which did read Apple Pascal disks
and transferred the Pascal source files (or any other text file) over
to CP/M disks, to make them accessible to Turbo Pascal. After having transferred all my Apple Pascal source files over to CP/M, I almost
never touched Apple Pascal again.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <nospam-EFADE7.15285117072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:

In article <bf6nmm$1vpr$1@merope.saaf.se>,
pausch@saaf.se (Paul Schlyter) wrote:

In article <nospam-701F83.06305517072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:
......................

The UCSD language extensions for strings and separate compilation
were implemented in scores of subsequent systems for Apple ///,
Lisa and Macintosh, not to mention Turbo Pascal and Delphi.

Turbo Pascal versions 1 to 3 didn't support separate compilation
though: the entire program had to logically reside in the same
source file. The only way to split it up was through INCLUDE
directives.

Interesting. I used Turbo Pascal for only a short time on Mac.
When did Turbo Pascal come support the UCSD "use" clause? Or am
I misremembering?

You're not misremembering: separate compilation and units were
introduced in Turbo Pascal ver 4. However, versions 4 and later
were never released for CP/M, only for MS-DOS and/or Windows.

I never liked Apple Pascal,

I loved it! It was sooo much better than Fortran:-)

Well, I was no fan of Apple Fortran either -- it was really a pig!

Instead I ran Microsoft Fortran-80 for CP/M for my Fortran needs.
Microsoft sold an Apple version of Fortran-80 for perhaps 1/3 the
price of the standard version of Fortran-80. But it would run only
on the Microsoft Softcard - when I tried to run it on the Appli-Card
it refused to work; the compiler just terminated, producing no
output. I suspected it checked the presence of a 6502 as it appeared
from the Softcard. So I scanned the executable file for the byte
sequence which let the Z80 call a 6502 subroutine -- and found it at
exactly one place. Next I started the executable in a debugger, put
a breakpoint there and single-stepped through the Z80 parts of the
code to figure out how it worked: the 6502 simply set a bit in a byte somewhere. So I replaced that 6502 call with Z80 code which set the
same bit -- and lo and behold, now the Apple version of Fortran-80
ran fine also on the Appli-Card !!!!

Next, I wrote a letter to Microsoft (this was back in 1981, when
Microsoft still was a small company, in Seattle) explaining my
problem and asking if there was a workaround. A few weeks later I
got a reply, basically saying "Sorry but the Apple version of
Fortran-80 doesn't work on the Appli-Card. But the standard version
of Fortran-80 works on that card.". Baiscally, they wanted me to buy
their compiler again, and this time for three times the price....

Still, I've abandoned it in favor of Kyan Pascal under ProDOS.

and my first serious experiences
with Pascal was on Turbo Pascal 1 running on Apple II CP/M:
it was ...s.o...m.u.c.h...f.a.s.t.e.r... - on the same hardware!

Can you speculate on how this came to be?

The reason is obvious and simple: pseudo-code versus native code.

Apple/UCSD Pascal compiled to P-code, which was interpreted by a
P-code interpreter at runtime. And since the UCSD Pascal compiler
was written in UCSD Pascal, it suffered the same performance penalty
as any other UCSD Pascal program.

Turbo Pascal was written in assembly language (Z80 assembly for CP/M,
8086/88 assembly for MS/PC-DOS, 68K assembly for the Macintosh) and
generated native code as output.

This is precisely the same reason why Java is slower than C or C++.
In a way, Java is the "UCSD Pascal" of our times. Of course today's
hardware is so much more powerful that this doesn't matter very much
(unless the program is heavily CPU intensive). But it's the same
phenomenon -- and back around 1980, when a 1-2 MHz 8-bitter was the
norm, the speed penalty of pseudo-code mattered a lot!

Apple's compiler and assembler were both disk based:

This of course added to the slowness of Apple Pascal, particularly
when floppy disks were used. Turbo Pascal read the entire system
(editor, compiler, runtime library) into RAM and versions 1-3 managed
to squeeze that into an amazingly small part of RAM (28K on the CP/M
version, 32K on MS/PC-DOS). The remainder was to be used for your
Pascal source and the object code. However, the object code could be
directed to disk, and the source could be split up and read into disk
in segments using the INCLUDE directive -- if used like this, Turbo
Pascal got much slower, of course, but it was still faster than
Apple Pascal.

I remember one other Pascal compiler which was even slower than Apple
Pascal: JRT Pascal for CP/M. It was sold by a company which had a
quite unorthodox view on software piracy -- in their ads, they
explicitly said "If you want, give copies of the disk and the
documentation to your friends; it's OK with us". That compiler was
also heavily disk based. Separate units got compiled into separate
object files on disk, which was read in, during runtime, only as
needed! But the compilation was very slow, and during runtime it
was even slower. The only advantage of JRT Pascal compared to Apple
Pascal was the floating-point accuracy: 14 digits vs 7 digits for
Apple Pascal....

They were slow, but they scaled well. On a hard drive and with the
speedup of the IIgs, they were quite suitable for larger projects.

I can imagine that UCSD Pascal scaled well on more powerful hardware.
Which is to be expected, since UCSD developed it on systems more
powerful than 8-bitters like the Apple II.

But on small systems (8-bit, max 64K RAM, only floppy disks) it did
not scale well -- at least not if you also consider scaling down and
not just scaling up.

UCSD Pascal wasn't unique in this respect. On the CP/M side there
were several C compilers available -- but they were ports of larger
compilers to CP/M and didn't scale well at all on such a small
system. They were large, and very slow at compiling, and didn't
produce code which ran that fast either. But then Leor Zolman came
along and wrote BDS C, which immediately became a success in the CP/M
world: it was small, it was fast, and it produced quite fast code too
- because it was written in 8080 assembly. It was not a perfect C
compiler of course -- it was non-standard, it lacked floating point,
and it had several idiosynchracies. But it worked very fine in the
CP/M environment, and a lot of stuff was written using BDS C. A user
group was formed which published a newsletter "The BDS C User's
Group". Somewhat later the name was changed to "The BDS C User's
Journal". Still later the "BDS" was dropped from the name and "C++"
was added -- and that publication is still around, under the name
"C/C++ User's Journal" -- you can visit their web site at
http://www.cuj.com if you want.

Small systems have different requirements than large systems. And
if you port software from a larger system to a small system, it might
suffer from such a port just like Apple Pascal did.

When the IBM PC had been released in the early 1980's, there were
three different OS'es you could choose among: PC-DOS (which came with
the machine), CP/M-86 and UCSD Pascal (which had to be purchased as
extras). I knew some software developers who developed for Apple
Pascal, with the explicit intention to later port their application
(an administrative system for small businesses) to UCSD Pascal on the
IBM PC and thus capture the PC market as well. Alas, UCSD Pascal
turned out to be the least popular of the OS'es for the IBM PC. And
it soon faded away in the Apple II world too, as ProDOS took over.

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <3F1744E2.80009@noneofyourbusiness.com>,
Exegete <millers@noneofyourbusiness.com> wrote:

Paul Schlyter wrote:

...................

I never liked Apple Pascal, and my first serious experiences
with Pascal was on Turbo Pascal 1 running on Apple II CP/M:
it was ...s.o...m.u.c.h...f.a.s.t.e.r... - on the same hardware!

Well, to be *really* picky, Paul, as you know, it wasn't the same
hardware. It ran on a Z-80 card of some kind.

True. However the Z80 Softcard (2 MHz clock) had a performance
comparable to the 1 MHz 6502: if you compared Applesoft Basic with
MBasic (on the SoftCard), then MBasic was usually somewhat slower --
perhaps 30% or so slower.

I would be curious to know if it ran, as you describe, on a Microsoft
Soft80 card, or it if took the PCPI card's much faster processor and independant 64K of RAM to run faster.

Turbo Pascal was much faster than Apple Pascal already on the
SoftCard. Compilation of Pascal source could easily be 100 times
faster, or more, on Turbo Pascal if the source files resided in RAM.
If it was read from the disk (through the INCLUDE directive), then
Turbo Pascal was perhaps "only" 10 times faster than Apple Pascal.

During run time the situation was similar: if your programs did
integer operations only (integers were 16 bits both on Turbo Pascal
and on Apple Pascal), Turbo Pascal programs ran perhaps 30 times
faster than Apple Pascal programs. If your program did a lot of
floating-point computations, the run time of Turbo Pascal was similar
to the run time of Apple Pascal; OTOH Turbo Pascal provided 12 digits
of precision in its floating-point, while Apple Pascal provided only
7 digits of precision. Both used binary floating-point but Turbo
Pascal used 6-byte for its f.p. values while Apple Pascal used only 4
bytes. Here Anders Hejlsberg (author of Turbo Pascal) did some
clever tricks with the Z80, using both the regular and the alternate
register set to keep both f.p. numbers in CPU registers at the same
time, while doing an add, subtract, multiply or divide (like the
6502, the Z80 had no hardware operations for multiply and divide).

This was the situation for the Z80 Softcard. If you switched to the
PCPI Appli-Card, everything CPU bound ran 3 times faster. Disk
access was no faster of course; actually it was marginally slower
since an extra copy of the data between the Z80 and the 6502 RAM was
needed; these were separate memory spaces. So for CP/M programs
doing much disk access, the Z80 Softcard could provide some speed
advantage over the Appli-Card.

OTOH there were accelerator boards for the 6502 too -- if you used
one of those, everything CPU-bound would be speeded up by a factor of
approx. 3 in Apple Pascal.

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Michael Pender wrote:

John B. Matthews <nospam@nospam.com> wrote in message >news:nospam-967967.21253716072003@clmboh1-nws3.columbus.rr.com...

Logo was a delightful environment, but not the only "serious" recursive
stack machine in wide use on Apple II.

Apple's UCSD Pascal implemented a very efficient stack machine. Each
stack frame had a static and dynamic link to allow recursion from an
arbitrary nesting level.

Apple Pascal was a half-baked implementation of the language that offered >very limited system access. It was a compiled Fortran program that
inherited all of the limitations of the Fortran language, as well as those
of Pascal.

No.

UCSD Pascal was a microcomputer adaptation of Wirth's ETH Zurich
portable Pascal implementation (based on P-code). In the process
of adapting it to microcomputers, the biggest problem was memory
space, so it is painfully optimized toward saving space at the clear
expense of a regular P-code.

Later, a FORTRAN implementation was done (in Pascal) which
used the same P-code interpreter as Pascal.

For example, a program could not have more than 3 files open at once, >system-wide.

Pascal certainly has many limitations as a system programming
language (many of which were conscious tradeoffs made to enhance
its educational value, in the eyes of its creator). Limitations like the number of simultaneously open files are not language limitations,
but implementation limitations--another consequence of optimizing
for very small memory (64KB) systems.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page: http://members.aol.com/MJMahon/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Michael J. Mahon <mjmahon@aol.com> wrote in message news:20030724183549.28226.00000581@mb-m24.aol.com...

Michael Pender wrote:

Apple Pascal was a half-baked implementation of the language that offered >very limited system access. It was a compiled Fortran program that >inherited all of the limitations of the Fortran language, as well as

those

of Pascal.

No.

UCSD Pascal was a microcomputer adaptation of Wirth's ETH Zurich
portable Pascal implementation (based on P-code). In the process
of adapting it to microcomputers, the biggest problem was memory
space, so it is painfully optimized toward saving space at the clear
expense of a regular P-code.

Later, a FORTRAN implementation was done (in Pascal) which
used the same P-code interpreter as Pascal.

For example, a program could not have more than 3 files open at once, >system-wide.

Pascal certainly has many limitations as a system programming
language (many of which were conscious tradeoffs made to enhance
its educational value, in the eyes of its creator). Limitations like the number of simultaneously open files are not language limitations,
but implementation limitations--another consequence of optimizing
for very small memory (64KB) systems.

As I said, Apple Pascal was a half-baked implementation that only allowed
three files open at the same time. In general, Pascal was a relatively powerful programming language 10 years ago. However, Apple's limited implementation left a *lot* to be desired, even for its day.

For example, I mentioned that AP only allowed three "files" to be open at
the same time.
- one "file" was needed to gather keyboard input (stdin)
- a second "file" was needed to write to the monitor or printer (stdout)
- the third "file" was really the only I/O channel available to a program without sacrificing the ability to accept user input from the keyboard or to send output to the display (or printer)

Thus, a program that actually interacts with the user could not have more
than one file open for reading/writing at a time without dynamically sacrificing one of the I/O streams. And if a program crashed without reconnecting either of the stdin/stdout streasm you had to reboot to regain control of the machine.

That is the standard I/O implementation of ForTran 77 -- which leads me to believe (but does not prove) that Apple Pascal was written in Fortran,
whether or not Apple had a commercial ForTran product in the box at that
point in time.

I stand by my previous statement that Apple Pascal was a half-baked implementation.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <Mt3Ua.17039$Qe5.5814@nwrddc03.gnilink.net>,
M. Pender <mpender@hotmail.com> wrote:

Michael J. Mahon <mjmahon@aol.com> wrote in message news:20030724183549.28226.00000581@mb-m24.aol.com...

Michael Pender wrote:

Apple Pascal was a half-baked implementation of the language that offered >>>very limited system access. It was a compiled Fortran program that >>>inherited all of the limitations of the Fortran language, as well as
those of Pascal.

No.

UCSD Pascal was a microcomputer adaptation of Wirth's ETH Zurich
portable Pascal implementation (based on P-code). In the process
of adapting it to microcomputers, the biggest problem was memory
space, so it is painfully optimized toward saving space at the clear
expense of a regular P-code.

Later, a FORTRAN implementation was done (in Pascal) which
used the same P-code interpreter as Pascal.

For example, a program could not have more than 3 files open at once, >>>system-wide.

Pascal certainly has many limitations as a system programming
language (many of which were conscious tradeoffs made to enhance
its educational value, in the eyes of its creator). Limitations like the
number of simultaneously open files are not language limitations,
but implementation limitations--another consequence of optimizing
for very small memory (64KB) systems.

As I said, Apple Pascal was a half-baked implementation that only allowed three files open at the same time. In general, Pascal was a relatively powerful programming language 10 years ago. However, Apple's limited implementation left a *lot* to be desired, even for its day.

For example, I mentioned that AP only allowed three "files" to be open at
the same time.
- one "file" was needed to gather keyboard input (stdin)
- a second "file" was needed to write to the monitor or printer (stdout)
- the third "file" was really the only I/O channel available to a program without sacrificing the ability to accept user input from the keyboard or to send output to the display (or printer)

Thus, a program that actually interacts with the user could not have more than one file open for reading/writing at a time without dynamically sacrificing one of the I/O streams. And if a program crashed without reconnecting either of the stdin/stdout streasm you had to reboot to regain control of the machine.

It wasn't quite THAT bad! I remember having written some program in
UCSD Pascal which opened one file for input, another for output, then
reading from the input file and writing to the output file, without
losing the keyboard or the console.

That is the standard I/O implementation of ForTran 77

...and in Pascal, C, Ada, PL/I and numerous other languages. Yes, it
is practical to have some predefined input and predefined output.

-- which leads me to believe (but does not prove) that Apple Pascal
was written in Fortran,

Why Fortran? Why not e.g. C, Ada, PL/I or Pascal instead? They all
used a similar I/O model....

whether or not Apple had a commercial ForTran product in the box at that point in time.

I stand by my previous statement that Apple Pascal was a half-baked implementation.

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


Michael J. Mahon <mjmahon@aol.com> wrote in message news:20030725020918.24310.00000421@mb-m16.aol.com...

M. Pender replied:

I believe you are referring to the three "predeclared files": OUTPUT,
INPUT, and KEYBOARD. Pascal also permits user-declared files
up to the limits that the system will support. This implies that the limitation you describe does not exist.

Yes, Apple Pascal permitted *one* additional filestream in addition to stdin and stdout. IIRC input and keyboard were just different references for the same stream, which a person could confirm by comparing the system-assigned file-ids for the streams.

Perhaps some stalwart Apple Pascal user can comment?

I think a few already have. ;-)

That is the standard I/O implementation of ForTran 77 -- which leads me

to

believe (but does not prove) that Apple Pascal was written in Fortran, >whether or not Apple had a commercial ForTran product in the box at that >point in time.

I can assure you that it is not written in FORTRAN--in fact quite the opposite: Apple FORTRAN is written in Pascal.

Apple Pascal was bootstrapped through the ETH Zurich Pascal
implementation, originally running on the CDC 6400. When UCSD
Pascal was completed, FORTRAN was implemented on top of the
same P-code interpreter, and the FORTRAN compiler also runs in
the Pascal P-code enviroment.

FORTRAN implementations which I used permitted many additional
files to be defined, though few FORTRAN programs ever used them.

Could the 3-stream limitation be an aspect of the UCSD p-code interpreter? Those are the only two languages I know of that are based on the UCSD p-code system that were implemented for the Apple II.

I stand by my previous statement that Apple Pascal was a half-baked >implementation.

You are, of course, entitled to your opinion. ;-)

But another possibility is that it was fully-baked, but to a different specification than you would prefer.

-michael

Fair enough; as long as I still get to call those undocumented features
"bugs." :-)

Seriously though, if the UCSD p-code interpreter defined a minimum number of filestreams that could be open at once, then the similarity I attributed to Fortran could just be a limitation of the p-code machine.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhn0f2i82v.fsf@ruckus.brouhaha.com...

"M. Pender" <mpender@hotmail.com> writes:

Yes, Apple Pascal permitted *one* additional filestream in addition to

stdin

and stdout.

False. I've written programs in Apple Pascal that had three disk files

open

simultaneously, as well as an extra serial port.

Well then, show us the code. I would like to see how you worked around the problem.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

"Mike Pender" <mpender@spamsucks.com> writes:

Well then, show us the code. I would like to see how you worked around the problem.

Give me a break, it was twenty years ago. I don't have the source code
any more, and even if I did, I couldn't post it because I didn't own it.
As a work for hire, it belonged to my employer.

But I didn't have to do anything special to "work around the problem",
because there was no problem.

If you really want to see a program that does this, I'd be happy to write
you a new one at my standard consulting rates. It would probably take
about two hours, including installing Apple Pascal on a simulator.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

"Michael Pender" <mpender@hotmail.com> writes:

Apple Pascal was a half-baked implementation of the language that offered very limited system access.

I'm not sure what you mean by "half-baked" and "very limited system access". Apple Pascal was a port of UCSD Pascal, and generally offered *more* capabilities and system access than standard Pascal as defined in
_Pascal User Manual and Report_ by Jensen and Wirth.

It was a compiled Fortran program that
inherited all of the limitations of the Fortran language, as well as those
of Pascal.

The compiler was itself written in Pascal, and was derived from the
Zurich P2 Portable Compiler. I don't have the source code for Apple
Pascal, but below I've attached the first few lines of the compiler
source code (file COMPA.TXT) from UCSD Pascal release I.3.



(*$U-*)
PROGRAM PASCALSYSTEM;

(************************************************)
(* *)
(* UCSD PASCAL COMPILER *)
(* *)
(* BASED ON ZURICH P2 PORTABLE *)
(* COMPILER, EXTENSIVLY *)
(* MODIFIED BY ROGER T. SUMNER *)
(* 1976..1977 *)
(* *)
(* INSTITUTE FOR INFORMATION SYSTEMS *)
(* UC SAN DIEGO, LA JOLLA, CA *)
(* *)
(* KENNETH L. BOWLES, DIRECTOR *)
(* *)
(* THIS SOFTWARE IS THE PROPERTY OF THE *)
(* REGENTS OF THE UNIVERSITY OF CALIFORNIA. *)
(* *) (************************************************)

TYPE PHYLE = FILE;
INFOREC = RECORD
WORKSYM,WORKCODE: ^PHYLE;
ERRSYM,ERRBLK,ERRNUM: INTEGER;
STUPID: BOOLEAN
END;

PROGRAM PROCEDURE USERPROGRAM;
BEGIN END (*USERPROGRAM*) ;

PROGRAM PROCEDURE COMPILER(VAR USERINFO: INFOREC);

CONST DISPLIMIT = 12; MAXLEVEL = 8; MAXADDR = 28000;
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <qh8yqmhyzk.fsf@ruckus.brouhaha.com>,
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:

"Mike Pender" <mpender@spamsucks.com> writes:

Well then, show us the code. I would like to see how you worked around the problem.

Give me a break, it was twenty years ago. I don't have the source code
any more, and even if I did, I couldn't post it because I didn't own it.
As a work for hire, it belonged to my employer.

But I didn't have to do anything special to "work around the problem", because there was no problem.

If you really want to see a program that does this, I'd be happy to write
you a new one at my standard consulting rates. It would probably take
about two hours, including installing Apple Pascal on a simulator.

The calssic merge sort typically has three files open; it was a
demo on disk 4. Here's a trivial example with two files:

program reformat1;
const lf = 10; cr = 13;
var f,g: text;
begin
reset(f); rewrite(g);
while not eof(f) do
begin
if eoln(f) then
begin
g^ := chr(cr); put(g);
g^ := chr(lf); put(g)
end
else
begin
g^ := f^; put(g)
end;
get(f)
end;
close(f); close(g)
end.

John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:qh8yqmhyzk.fsf@ruckus.brouhaha.com...

If you really want to see a program that does this, I'd be happy to write
you a new one at my standard consulting rates. It would probably take
about two hours, including installing Apple Pascal on a simulator.

Thanks for the offer, but if I cared that much I would just download the
Apple Pascal files from Asimov and do it myself.

Its been at least 15 years since I worked with Apple Pascal too. I expect
that a lot of problems that seemed 'unsolvable' back in those days would be
"no problem" at all now--whether due to updates (a.k.a. fixing bugs) in the software or improvements in skill level.

- Mike



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <FUvUa.2235$FP5.964@nwrddc02.gnilink.net>,
Mike Pender <mpender@spamsucks.com> wrote:

Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message >news:qh8yqmhyzk.fsf@ruckus.brouhaha.com...

If you really want to see a program that does this, I'd be happy to write
you a new one at my standard consulting rates. It would probably take
about two hours, including installing Apple Pascal on a simulator.

Thanks for the offer, but if I cared that much I would just download the >Apple Pascal files from Asimov and do it myself.

Its been at least 15 years since I worked with Apple Pascal too. I expect >that a lot of problems that seemed 'unsolvable' back in those days would be >"no problem" at all now--whether due to updates (a.k.a. fixing bugs) in the >software or improvements in skill level.

However, you could try it out on some old Apple Pascal implementation,
to see if there really was an "only one file open at a time" problem
or not back then.....




--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

"Mike Pender" <mpender@spamsucks.com> writes:

By "very limited system access" I meant that a person had to "cheat" to be able to call machine code subroutines from Apple Pascal.

False. You could easily write assembly code using the provided assembler,
and link it to your Pascal code.

There were ways to
'peek' and 'poke' using pointers, but at the time I couldn't find a way to call machine code subroutines by address.

If you really needed to do that, you could write a small piece of assembly
glue to provide a function like call(address).

Before you respond that access to machine resources wasn't a fault of Apple Pascal, remember that the other standard Apple languages of the day (integer basic, applesoft basic, etc.) all provided such access.

As did all variants of UCSD Pascal, including Apple Pascal.

One can hardly blame Apple Pascal if you didn't read the documentation.

One of the reasons I thought Apple Pascal may have been coded in ForTran is because they named the two disks "FORT1" and "FORT2."

I suppose it *might* just be a coincidence.

The FORT1 and FORT2 disks were part of Apple Fortan, not Apple Pascal.
Apple Fortran was a distribution of UCSD p-System Fortran, so it was Pascal-based.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

M. Pender replied:

Michael J. Mahon <mjmahon@aol.com> wrote in message >news:20030727041554.24610.00000499@mb-m28.aol.com...

Mike Pender wrote:

One of the reasons I thought Apple Pascal may have been coded in ForTran >is
because they named the two disks "FORT1" and "FORT2."

No, those disks are the FORTRAN compiler. The Pascal compiler and
system are on "APPLE0", "APPLE1", and "APPLE2".

These are the disks I pulled to get the flash screen at Asimov:
disk1: images/utility/programming/applepascal1.dsk.gz
disk 2: images/utility/programming/applepascal2.dsk.gz

If that's actually the Fortran compiler then it must be improperly labeled
on the Asimov site.

I haven't checked these images thoroughly against the original
disks, but the first one contains the FORTRAN library, and what
appears to be the Pascal compiler. The second appears to be
the APPLE1 Pascal system and library.

These are not the distribution disks for Apple Pascal, and
the volume names are, as you might guess, for the FORTRAN
distribution disks.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page: http://members.aol.com/MJMahon/
--- Synchronet 3.18b-Win32 NewsLink 1.113