Discussion:
6502 version of version 3.01A of Turbo Pascal
(too old to reply)
AppleCPM
2010-03-14 00:01:36 UTC
Permalink
Hi, y'all!

I'm in the process of testing a 'port of Turbo Pascal, version
3.01A for MS/DOS,
AppleCPM
2010-03-14 00:05:31 UTC
Permalink
Hi, y'all!

  I'm in the process of testing a 'port of Turbo Pascal, version
3.01A for MS/DOS, to the Apple II. Making progress but have a long
way to go...

Willi
Ruud
2010-03-18 15:08:02 UTC
Permalink
Hallo Willi,
    I'm in the process of testing a 'port of Turbo Pascal, version
3.01A for MS/DOS, to the Apple II.
Please keep us informed! Is there a chance I can port it to the
Commodore 64?


Groetjes, Ruud

Ruud.C64.org
Dr J R Stockton
2010-03-19 17:37:22 UTC
Permalink
In comp.lang.pascal.borland message <e1e74573-c1df-40c9-8252-57d113a4dd4
Post by Ruud
Hallo Willi,
    I'm in the process of testing a 'port of Turbo Pascal, version
3.01A for MS/DOS, to the Apple II.
Please keep us informed! Is there a chance I can port it to the
Commodore 64?
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.

I used to program an important application on a twin-floppy LSI-11, and
tolerated a five-minute compile time. And I wrote, in TP4m a LSI-11
emulator which ran a useful program at acceptable speed on a 12 MHz PC.
Old TP compiles so fast on its intended machines; an emulator ought to
be OK on a modern machine, a thousand times faster.

The code generator part should be adaptable to give output files
acceptable to different systems, without necessarily optimising the code
for the system.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Marco van de Voort
2010-03-20 10:58:03 UTC
Permalink
Post by Dr J R Stockton
Post by Ruud
Commodore 64?
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.
Why? All the dosisms won't function, and the clean syntax works with
FreePascal, VP Delphi etc. The Java bit would probably be less compatible
than these.
Dr J R Stockton
2010-03-21 17:00:34 UTC
Permalink
In comp.lang.pascal.borland message <***@turtle.stack.
nl>, Sat, 20 Mar 2010 10:58:03, Marco van de Voort
Post by Marco van de Voort
Post by Dr J R Stockton
Post by Ruud
Commodore 64?
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.
Why? All the dosisms won't function, and the clean syntax works with
FreePascal, VP Delphi etc. The Java bit would probably be less compatible
than these.
Many useful, if small, programs do not need "dosisms". For example. I
use my CHEKLINX (via sig line 3) several times a day : all it normally
does is to read its argument list, read files as lines of strings, think
about them, and write to standard output (one option also writes to a
text file).

There would be no requirement for the TP port to be able to run ANY
valid TP program ('port' is probably a bad term here).

I suspect that FreePascal, VP Delphi, etc., do not run on as many
machines as Web browsers, Java, JavaScript do.

I've implemented the prime functionality of CHEKLINK with JavaScript in
<URL:http://www.merlyn.demon.co.uk/linxchek.htm>, though it is by no
means the same. Each of the two can do things that the other cannot do
and could not readily be made to do.

Even short programs can be vital. Part of the national measurement
system at one time relied on a machine with $C80 bytes of RAM, $300
bytes of ROM, and a 1 MHz (IIRC) 8-bit CPU with a 12-bit address bus.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Marco van de Voort
2010-03-22 11:07:28 UTC
Permalink
Post by Dr J R Stockton
Post by Marco van de Voort
Post by Dr J R Stockton
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.
Why? All the dosisms won't function, and the clean syntax works with
FreePascal, VP Delphi etc. The Java bit would probably be less compatible
than these.
Many useful, if small, programs do not need "dosisms".
For example. I use my CHEKLINX (via sig line 3) several times a day : all
it normally does is to read its argument list, read files as lines of
strings, think about them, and write to standard output (one option also
writes to a text file).
Write to harddisk from a browser? Do the sandboxes allow that?

Java is hardly installed into browsers nowadays. And beware, that while many
phones have so called java support, to actually access it often requires a
developer license.
Post by Dr J R Stockton
There would be no requirement for the TP port to be able to run ANY
valid TP program ('port' is probably a bad term here).
It will work, as long as you use the lowest common denomitor between all
imperative languages, and are too not too picky about the border conditions
of the language (e.g. require that the arithmetic will work exactly as in
TP, let alone dosims and pointer manipulation)

And that touches the different between TP and generic something pascalishly
with a few TP constucts.

The result will be hardly TP at all, but a watered down version of Pascal.
(since even e.g. UCSD pascals afaik supported range and overflow checks,
for which you would need a full Pascal VM in Javascript, not a shallow
conversion).

I can be wrong though, its just gut instinct, and having seen many bold
claims on all kinds of 2javascript and 2java tools. If that is the case,
please enlighten me.
Post by Dr J R Stockton
I suspect that FreePascal, VP Delphi, etc., do not run on as many
machines as Web browsers, Java, JavaScript do.
FPC runs on many systems that are too slow for more as the most simplistic
javascript. Java is different, since these ARM systems do often have
Jazelle. But often access to any of them require developer licenses.

Probably using GPC will yield more prolific (due to gcc) and close to the
pascal regime (arithmetic, checks) results than Java.

But OTOH to be anything close to even a _correct_ subset, would require to
write a Pascal VM.
Post by Dr J R Stockton
I've implemented the prime functionality of CHEKLINK with JavaScript in
<URL:http://www.merlyn.demon.co.uk/linxchek.htm>, though it is by no
means the same. Each of the two can do things that the other cannot do
and could not readily be made to do.
Even short programs can be vital. Part of the national measurement
system at one time relied on a machine with $C80 bytes of RAM, $300
bytes of ROM, and a 1 MHz (IIRC) 8-bit CPU with a 12-bit address bus.
True. But what is the point of a Pascal to javascript converter if the
javascript program behaves differently. That would be very, very limited.

And I don't think that an TP Pascal program converted to javascript will
even be in that position.
winston19842005
2010-03-22 11:50:40 UTC
Permalink
Post by Marco van de Voort
The result will be hardly TP at all, but a watered down version of Pascal.
(since even e.g. UCSD pascals afaik supported range and overflow checks,
for which you would need a full Pascal VM in Javascript, not a shallow
conversion).
I was actually surprised by many of UCSD's shortcomings in this respect.
For example, if you define a datatype to be 12 bits, UCSD Pascal does not
range-check it except to the next byte boundary, as the 12-bit value will be
put in a 16-bit cell.

And I seem to remember wrap-around from MAXINT to -MAXINT without any
complaints.

A lot of other ugly stuff under the hood, all in one of the books about UCSD
Pascal by Ken Bowles...
Dr J R Stockton
2010-03-23 20:45:44 UTC
Permalink
In comp.lang.pascal.borland message <***@turtle.stack.
nl>, Mon, 22 Mar 2010 11:07:28, Marco van de Voort
Post by Marco van de Voort
Post by Dr J R Stockton
Post by Marco van de Voort
Post by Dr J R Stockton
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.
Why? All the dosisms won't function, and the clean syntax works with
FreePascal, VP Delphi etc. The Java bit would probably be less compatible
than these.
Many useful, if small, programs do not need "dosisms".
For example. I use my CHEKLINX (via sig line 3) several times a day : all
it normally does is to read its argument list, read files as lines of
strings, think about them, and write to standard output (one option also
writes to a text file).
Write to harddisk from a browser? Do the sandboxes allow that?
I did not say that CHEKLINX runs in a browser. It is Borland Pascal 7
and/or Delphi 3. Also, standard output is not really to the hard disc,
although it can be routed there. That is the one feature of CHEKLINX
that a browser cannot do directly.

However, CHEKLINX could be translated, literally, to the JScript version
of JavaScript and run in Windows Script Host. Or it could be run, in a
web-page-like environment, as an HTA.
Post by Marco van de Voort
Java is hardly installed into browsers nowadays.
I think otherwise : perhaps not installed **IN**, but usable from. But,
for the purpose, all that matters is that a Java program can be compiled
into byte code and run on many sorts of computers.
Post by Marco van de Voort
And beware, that while many
phones have so called java support, to actually access it often requires a
developer license.
Does mot matter, except to those who want to access it in phones.
Post by Marco van de Voort
Post by Dr J R Stockton
There would be no requirement for the TP port to be able to run ANY
valid TP program ('port' is probably a bad term here).
It will work, as long as you use the lowest common denomitor between all
imperative languages, and are too not too picky about the border conditions
of the language (e.g. require that the arithmetic will work exactly as in
TP, let alone dosims and pointer manipulation)
And that touches the different between TP and generic something pascalishly
with a few TP constucts.
The result will be hardly TP at all, but a watered down version of Pascal.
(since even e.g. UCSD pascals afaik supported range and overflow checks,
for which you would need a full Pascal VM in Javascript, not a shallow
conversion).
I can be wrong though, its just gut instinct, and having seen many bold
claims on all kinds of 2javascript and 2java tools. If that is the case,
please enlighten me.
Post by Dr J R Stockton
I suspect that FreePascal, VP Delphi, etc., do not run on as many
machines as Web browsers, Java, JavaScript do.
FPC runs on many systems that are too slow for more as the most simplistic
javascript. Java is different, since these ARM systems do often have
Jazelle. But often access to any of them require developer licenses.
Probably using GPC will yield more prolific (due to gcc) and close to the
pascal regime (arithmetic, checks) results than Java.
But OTOH to be anything close to even a _correct_ subset, would require to
write a Pascal VM.
Post by Dr J R Stockton
I've implemented the prime functionality of CHEKLINK with JavaScript in
<URL:http://www.merlyn.demon.co.uk/linxchek.htm>, though it is by no
means the same. Each of the two can do things that the other cannot do
and could not readily be made to do.
LINXCHEK.HTM cannot write directly to disc, although what it displays
can be manually copied. I did not think of giving it an equivalent to
LINXCHEK.EXE's standard output stream (very rarely used); but part of
what it can show in that window has essentially the same information and
could be reformatted to match.
Post by Marco van de Voort
Post by Dr J R Stockton
Even short programs can be vital. Part of the national measurement
system at one time relied on a machine with $C80 bytes of RAM, $300
bytes of ROM, and a 1 MHz (IIRC) 8-bit CPU with a 12-bit address bus.
True. But what is the point of a Pascal to javascript converter if the
javascript program behaves differently. That would be very, very limited.
And I don't think that an TP Pascal program converted to javascript will
even be in that position.
You misunderstand me. I wrote "a port coded in". That does not mean
that it inputs TP source code and outputs a corresponding script; it
means that it inputs TP source code and outputs either an EXE equivalent
to what the Borland compiler would output or a form of code that can be
interpreted either by a commonly-available system or it's own run-time
system.

That's certainly *possible*, since any reasonable language can implement
a Turing Engine, and a Turing Engine can implement anything, including
640K of RAM holding DOS 3 & TP3. To be practical, one needs something
faster.

I have written, in TP4 or TP5, an emulator for a significant proportion
of the DEC LSI-11 instruction set, and used it to run on a 12 MHz PC a
program useful on both machines. On the PC, it was perceptibly, but not
importantly, slower; in a modern PC, it could be faster than the
original. One could likewise write in JScript an emulator for an IBM PC
and use that to run genuine TP3.


On sandboxes, which you started by mentioning : my Web page
<URL:http://www.merlyn.demon.co.uk/js-grphx.htm> executes JavaScript
(actually read from disc files) to write to an HTML5 "canvas" which is
read by the page as a string in PNG format which is read into a PNG IMG
replacing the "canvas". That IMG can be saved to disc with a few
clicks. So material can easily enough be extracted from JavaScript to
disc.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
Robert AH Prins
2010-03-26 11:36:51 UTC
Permalink
In comp.lang.pascal.borland message<e1e74573-c1df-40c9-8252-57d113a4dd4
Post by Ruud
Hallo Willi,
Post by AppleCPM
I'm in the process of testing a 'port of Turbo Pascal, version
3.01A for MS/DOS, to the Apple II.
Please keep us informed! Is there a chance I can port it to the
Commodore 64?
What would be really useful, long term, would be a port of TP coded in
something like Java or JScript/JavaScript - to something which, because
of the Web, will be available on any general-purpose computer system for
years to come.
I used to program an important application on a twin-floppy LSI-11, and
tolerated a five-minute compile time. And I wrote, in TP4m a LSI-11
emulator which ran a useful program at acceptable speed on a 12 MHz PC.
Old TP compiles so fast on its intended machines; an emulator ought to
be OK on a modern machine, a thousand times faster.
The code generator part should be adaptable to give output files
acceptable to different systems, without necessarily optimising the code
for the system.
You can run (Free)Dos in a JVM:
http://javapc.sourceforge.net/home_home.html and that might mean it will
also run TP 3...

FWIW, an in-depth look at TP3, with a program to generate a disassembled
source can be found at http://www.pcengines.ch/tp3.htm

I might have a version disassembled with IDA Pro that actually assembles
with TASM, will have to spend some time finding it...

Robert
--
Robert AH Prins
spamtrap(a)prino(d)org
Loading...