Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 22, 2021, at 5:43 PM, ben via cctech  wrote:
> 
> ...
> 1965 to 1985 generated most of the new computing languages,operating
> systems and ideas. Sadly most of it seems lost source code wise.
> Ben.

I might push the start of that back to 1955, but apart from that I agree you 
have a good point.

There's actually a surprising amount of preserved material.  The SIMH project 
has been a very impressive help with that, as is Bitsavers.  Then there is 
Hercules and DtCyber, to mention just two classic architectures preserved in 
emulators -- and each of these comes with a substantial body of operating 
systems and languages.

The famous THE system has been preserved.  The first ever ALGOL-60 compiler 
also (more precisely, the third, load and go, version of that compiler -- but 
that was a small incremental change not affecting the essential structure).  
Both in source form, and both run in emulation.  The same goes for Multics, and 
OS/360, and CDC COS and Scope and Kronos, and Burroughs mainframe MCP.  There 
is a collection of PDP-1 software, and IBM 1620 software, and so on.  You can 
still run APL\360 as it existed on the IBM 360 mainframes, and you can 
experience the PLATO system just as it was in the late 1970s (for that, see 
cyber1.org).

For most of this the source code still exists, though I'm not sure about the 
1620 bits.  So you aren't limited to playing with it, you can study the code, 
in as much depth as you care to.  Some have gone deep enough to get a Ph.D. for 
their work (Gauthier van den Hove's extremely detailed analysis of that first 
ALGOL compiler).

Of course there's also a lot that has vanished.  The machine on which I learned 
assembly language seems to have vanished from history except for one sales 
pamphlet (the Philips PR8000).  Software of the MC (CWI) research machines is 
pretty much gone, which is quite unfortunate since one of them is an ARMAC demo 
program written by Dijkstra containing his original implementation of the 
"shortest path" algorithm that later became the essence of several Internet 
routing protocols.

paul

Re: Early Programming Books

[ben via cctalk]

On 2021-06-22 3:10 p.m., r.stricklin via cctech wrote:




On Jun 22, 2021, at 12:40 PM, ben via cctech  wrote:



Lisp is evaluated, not compiled from what little I have read.
If I could read the papers (for free) I could know more.


So… have I got this right?

1. You admit directly you have only a little knowledge on the topic.
2. You choose to stand by your uninformed opinion (and dig your heels in 
deeper, even) instead of accepting information from somebody with more 
knowledge and/or direct experience, or taking the initiative to learn more 
about it yourself, before spouting off about it on a public mailing list.


Jesus take the wheel.


ok
bear.

Reading a book on Lisp, 40 years ago is not being up to date on the 
topic.It mostly covered the eval loop, and how Lisp can be written

in Lisp. When Lisp gets better keywords like HEAD and TAIL I might
want to use it, if I had need for it.
Right now I am looking at META-COMPILERS, not some thing new
because I need a bootstrap language for a single accumulator
machine with modest memory usage.
1965 to 1985 generated most of the new computing languages,operating
systems and ideas. Sadly most of it seems lost source code wise.
Ben.

Re: Early Programming Books

[r.stricklin via cctalk]

> On Jun 22, 2021, at 12:40 PM, ben via cctech  wrote:

> Lisp is evaluated, not compiled from what little I have read.
> If I could read the papers (for free) I could know more.

So… have I got this right?

1. You admit directly you have only a little knowledge on the topic.
2. You choose to stand by your uninformed opinion (and dig your heels in 
deeper, even) instead of accepting information from somebody with more 
knowledge and/or direct experience, or taking the initiative to learn more 
about it yourself, before spouting off about it on a public mailing list.


Jesus take the wheel.


ok
bear.

Re: VT340 Emulation

[Douglas Taylor via cctalk]

Someone already did this with a TEK4010 emulation:  See

https://github.com/rricharz/Tek4010

Hmmm... You could use a Raspberry Pi to emulate a number of terminals.

Doug

On 6/22/2021 3:49 AM, emanuel stiebler via cctalk wrote:

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:


I'm now wondering about building something like a Raspberry Pi with an
LCD display (native resolution?)

Be careful. The "native" resolution of the vt340 is 800x480 in 4:3
format ...

So I would use an 15" 4K display at the RBpi, and scale up...

Imagine a Tekronox Emulation on a 4K display ;-)


in a custom case that's stylaized after
the VT340 (?) case, all be it abbreviated so that it's much shallower.
I'd probably simply run a full screen XTerm without any window manager.
(I might have a different way to start with a window manager and
traditional GUI.)
I could support serial, but if I'm using an SBC, why not use Ethernet
(or even WiFI)???

I would love to see REAL RS232 on a RBPi, probably even the original MMJ
from DEC for keyboard & mouse

Re: Early Programming Books

[Jay Jaeger via cctalk]

I’d like a copy.  This is the card version?


Sent from my iPhone

> On Jun 22, 2021, at 3:28 PM, Van Snyder via cctalk  
> wrote:
> 
> On Tue, 2021-06-22 at 15:44 -0400, Paul Koning via cctalk wrote:
>> The Electrologica ALGOL compilers used somewhat similar mixtures of
>> pseudocode and machine code.
> 
> The IBM 1401 Fortran compiler 1401-FO-050 (subset of Fortran II)
> generated machine code for integer operations, and bytecode for
> floating point. The machine didn't have any floating-point hardware.
> The bytecode was smaller than subroutine calls would have been.
> Floating-point arithmetic was rather well done. Up to 20 decimal
> digits, with two guard digits. Only significant defect was that
> rounding wasn't symmetric. Gary Mokotoff did a very good job. I have
> the source code if anybody wants it.
> 

Re: Early Programming Books

[Van Snyder via cctalk]

On Tue, 2021-06-22 at 15:44 -0400, Paul Koning via cctalk wrote:
> The Electrologica ALGOL compilers used somewhat similar mixtures of
> pseudocode and machine code.

The IBM 1401 Fortran compiler 1401-FO-050 (subset of Fortran II)
generated machine code for integer operations, and bytecode for
floating point. The machine didn't have any floating-point hardware.
The bytecode was smaller than subroutine calls would have been.
Floating-point arithmetic was rather well done. Up to 20 decimal
digits, with two guard digits. Only significant defect was that
rounding wasn't symmetric. Gary Mokotoff did a very good job. I have
the source code if anybody wants it.

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 22, 2021, at 3:40 PM, ben via cctalk  wrote:
> 
> ...
> Lisp is evaluated, not compiled from what little I have read.
> If I could read the papers (for free) I could know more.
> Refal "Recursive functions algorithmic language" from Russia
> looks just what I was looking for. Around since 1966.
> Ben.

Any language can be interpreted or compiled.  For some languages, like LISP and 
TECO, interpreting is a rather natural implementation techniques, while for 
others (C, ALGOL) compilation is the obvious answer.  But either is possible.

For example, there is a compiled TECO -- it turns the editor commands into 
PDP-10 machine code and then executes it (Stevens TECO, if I remember right).

Of course there are implementations that are borderline between the two.  The 
common Python implementation is an example, with its bytecode that is 
interpreted.  Forth is partly bytecode and partly straight machine code.  The 
Electrologica ALGOL compilers used somewhat similar mixtures of pseudocode and 
machine code.  DEC's PDP-11 Fortran IV used bytecode, while Fortran IV-Plus 
uses machine code.  (Two compilers for the same machine, two different 
approaches.)

paul

Re: Early Programming Books

[ben via cctalk]

On 2021-06-21 3:47 p.m., Rich Alderson wrote:

Date: Sun, 20 Jun 2021 22:19:02 -0600
From: ben via cctalk 



LISP still can't be compiled.


May I respectfully suggest that you don't know WTF you're talking about?

LISP compilers have existed for decades.  One of the *early* MIT AI Lab papers
by Guy Steele is a comparison of the compiler for MACLISP (the Project MAC
dialect of Lisp, nothing to do with Apple computers) with the then current
FORTRAN compiler for the PDP-10 (called "F40"), in which the LISP compiler
generated better code than the FORTRAN compiler.

Things have not degenerated since then.

 Rich


Lisp is evaluated, not compiled from what little I have read.
If I could read the papers (for free) I could know more.
Refal "Recursive functions algorithmic language" from Russia
looks just what I was looking for. Around since 1966.
Ben.

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 22, 2021, at 12:57 PM, Zane Healy  wrote:
> 
> 
> 
>> On Jun 22, 2021, at 6:19 AM, Paul Koning via cctalk  
>> wrote:
>> 
 Imagine a Tekronox Emulation on a 4K display ;-)
>> 
>> Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.
> 
> That brings up an interesting question, how good is a 4K display for 
> emulating vector graphics?

Assuming you can feed such a display a video signal that actually represents 4k 
worth of pixels, without compression, it should be quite decent for vector 
graphics up to 11 bit x/y resolution or so.  I have a CDC console (DD60) 
emulation, that's a 512x512 display with vector characters, which looks good on 
the 1k resolution laptop screen.  Not so good before I started using the 
"Retina" mode and was only getting 512 pixel resolution; with that the pixel 
artefacts were quite visible and somewhat annoying.

Depending on the API of the vector system, the hard part may be to create an 
adequate emulation of display persistence and fade. If the vector machine has a 
well defined refresh cycle that's probably straightforward (just display what 
the current display list says).  If the graphics primitives simply amount to 
"send a stream of vectors to the tube" as is the case for the DD60, then you 
have to track elapsed time and fade the older pixels -- possibly with the help 
of an inferred display refresh cycle that isn't expressed in the data stream.  

paul

Re: VT340 Emulation

[Zane Healy via cctalk]

> On Jun 22, 2021, at 6:19 AM, Paul Koning via cctalk  
> wrote:
> 
>>> Imagine a Tekronox Emulation on a 4K display ;-)
> 
> Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.

That brings up an interesting question, how good is a 4K display for emulating 
vector graphics?

Zane

Re: VT340 Emulation

[Ethan Dicks via cctalk]

On Tue, Jun 22, 2021 at 6:32 AM Grant Taylor via cctalk
 wrote:
> > I would love to see REAL RS232 on a RBPi, probably even the original
> > MMJ from DEC for keyboard & mouse
>
> What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or
> bit banging GPIO lines?

The OP said he meant with "real" connectors, but in my case, I've
encountered strange buffering issues with USB serial dongles (since
they are really block-mode devices, not character-at-a-time) and I've
definitely had problems supporting lines with odd parameters
(especially speeds slower than 300 baud or with 5-bits-per-char, like
one would use for a Model 19 or Model 28 teletype).  The hardware
UARTs on AVR processors implement those juse fine (though for "50
baud", you often have to put a slower crystal on the processor because
the 16-bit divisor overflows at 16-20MHz).  The "soft serial"
libraries often just hard-code 8-bit implementations.  Fine for modern
stuff but I have uses for connecting to electromechanical serial
devices.

In terms of a CRT terminal, though, most modern serial implementations are fine.

-ethan

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 22, 2021, at 6:32 AM, Grant Taylor via cctalk  
> wrote:
> 
> On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:
>> Be careful. The "native" resolution of the vt340 is 800x480 in 4:3 format ...
> 
> 800x480 isn't 4:3 aspect, like VGA 640x480 / SVGA 800x600 / XGA (?) 1024x768. 
>  But I suppose the aspect ratio can be the area that the pixels cover, not 
> the actual pixel matrix.

Some DEC displays use non-square pixels.  An example (annoying because I've 
been wanting to connect to a modern display) is the Pro, which has a max 
resolution of 1024 by 480, on a 4:3 tube.

> ...
>> Imagine a Tekronox Emulation on a 4K display ;-)

Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.

paul

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 06:32, Grant Taylor via cctalk wrote:
> On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:

>> So I would use an 15" 4K display at the RBpi, and scale up...
> 
> I personally dislike all the 4k monitors that I've seen.  I'd be more
> likely to go old school.

Why? I love the new ones, as I travel a lot ;-)

>> Imagine a Tekronix Emulation on a 4K display ;-)
> 
> ~chuckle~

;-)

>> I would love to see REAL RS232 on a RBPi, probably even the original
>> MMJ from DEC for keyboard & mouse
> 
> What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or
> bit banging GPIO lines?

OK, sorry. "Real" is for me here, physically the same connectors like
DB25/DB9/MMJ/etc ...

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:
Be careful. The "native" resolution of the vt340 is 800x480 in 4:3 
format ...


800x480 isn't 4:3 aspect, like VGA 640x480 / SVGA 800x600 / XGA (?) 
1024x768.  But I suppose the aspect ratio can be the area that the 
pixels cover, not the actual pixel matrix.


Your point is noted.  Though I don't know if an improper resolution 
would make that much difference to me in my use case.  But I'm not 
chasing an authentic experience.  Rather I am after something neat / 
nifty / quaint, much like the PiCade is not a real arcade cabinet.



So I would use an 15" 4K display at the RBpi, and scale up...


I personally dislike all the 4k monitors that I've seen.  I'd be more 
likely to go old school.



Imagine a Tekronox Emulation on a 4K display ;-)


~chuckle~

I would love to see REAL RS232 on a RBPi, probably even the original 
MMJ from DEC for keyboard & mouse


What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or 
bit banging GPIO lines?




--
Grant. . . .
unix || die

Re: VT100 colors

[Antonio Carlini via cctalk]

On 22/06/2021 08:16, Matt Burke via cctalk wrote:

The VT640 had a green phosphor. This was a 3rd party upgrade for the
VT100 from Digital Engineering which gives the VT100 graphical
capabilities. Part of the upgrade involved changing the picture tube. I
suspect this was to reduce flicker as the phosphor has a high persistence.

Here is an original advert for the upgrade:

https://books.google.co.uk/books?id=rO0QAcSJpQUC=PA27

Matt


The ones I used had a VT640 (although the only used for the graphics 
side that I remember was a labyrinth game and some ALGOL code I wrote to 
plot some coursework). I would never have guessed that the tube got 
changed as part of the process, but it looks like you probably bought 
the modified VT100 from Digital Engineering rather than installing a kit 
yourself.



Antonio


--
Antonio Carlini
anto...@acarlini.com

Water Cooling and Hot Climates was RE: IBM 1620; was: Early Programming Books

[Dave Wade G4UGM via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Van Snyder via
> cctalk
> Sent: 22 June 2021 00:00
> To: cctalk@classiccmp.org
> Subject: Re: IBM 1620; was: Early Programming Books
> 
> On Mon, 2021-06-21 at 17:26 -0400, William Donzelli via cctalk wrote:
> > > Of course, nowadays, the old R22 systems are being refilled with
> > > purified propane, called R290.  Cheap, with better thermal
> > > properties than R22, but probably not legal when LCM picked up the
> 6500.
> >
> > When cleaning out a 3rd party CDC dealer quite a few years back, he
> > remarked that the CDC machines going way back all the way to the 800s
> > were fantastically unpicky about how they were cooled. He just used a
> > garden hose connected to the building potable water, and if the
> > machine under test needed more coolant because it was running warm, it
> > just pumped more supply. Heated waste water went down the drain.
> >
> > This unlike the IBM water machines.
> 
> I was once told that the most valuable guy in a Honeywell 6080 Multics shop
> was the plumber.
> 

I don't ever remember the 6080 being water cooled? I Thought Honeywell/GEC was 
all air cooled. All the L66s (which were from what the Multics machine was 
developed) were air cooled.

I was told the following tale by one of my Honeywell contacts

... Apparently the last Shah of Iran owned a Level 66 for the use of his secret 
police. Apart from the fact that the OS had been modified by Honeywell Italy, 
and the documentation for this was in Italian which no one on the job 
understood, and when the OS crashed it was usually in a section of the code 
with Italian comments,  there was also a problem with the power. As the 
temperature rose the power invariable failed. This was because it was run from 
a diesel generator that was out in the sun, it over heated and cut out.

... any way after many complaints the military man in charge came to the 
Honeywell staff and told them the problem was solved. They of course asked how 
and were taken to the generator and shown the latest modification. They had 
fitted a new cap to the radiator with a thermometer in it, as often found on 
vintage cars. They had painted a read line on the gauge and assigned a soldier 
to watch it. When the needle got to the line, he blew his whistle and several 
other soldiers appeared and threw buckets of water over the engine until it 
cooled down
 
I just wonder what they did while waiting for it to overheat..

> >
> > --
> > Will

Dave
G4UGM

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:

> I'm now wondering about building something like a Raspberry Pi with an
> LCD display (native resolution?) 

Be careful. The "native" resolution of the vt340 is 800x480 in 4:3
format ...

So I would use an 15" 4K display at the RBpi, and scale up...

Imagine a Tekronox Emulation on a 4K display ;-)

> in a custom case that's stylaized after
> the VT340 (?) case, all be it abbreviated so that it's much shallower.
> I'd probably simply run a full screen XTerm without any window manager.
> (I might have a different way to start with a window manager and
> traditional GUI.)

> I could support serial, but if I'm using an SBC, why not use Ethernet
> (or even WiFI)???

I would love to see REAL RS232 on a RBPi, probably even the original MMJ
from DEC for keyboard & mouse

Re: VT100 colors

[Matt Burke via cctalk]

On 21/06/2021 18:12, Antonio Carlini via cctalk wrote:
> I found the IPB on bitsavers and that lists the P4 phosphor and a
> later CRT with the P40 phosphor. I think both of those are white.
>
>
> I did find one seemingly untouched image of a VT100 with green text:
> https://vistapointe.net/cliparts/getsecond. That does appear to be a
> VT100 (not a VT102/VT103 etc) and is green.
>
> I did find many more white phosphor pictures than green (and no amber
> at all).
>

The VT640 had a green phosphor. This was a 3rd party upgrade for the
VT100 from Digital Engineering which gives the VT100 graphical
capabilities. Part of the upgrade involved changing the picture tube. I
suspect this was to reduce flicker as the phosphor has a high persistence.

Here is an original advert for the upgrade:

https://books.google.co.uk/books?id=rO0QAcSJpQUC=PA27

Matt

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:

> After seeing the prices of VT3xx / VT4xx / VT5xx when I looked a few
> years ago, I quickly decided that I didn't want to spend that sort of
> money.

And, if you get a cheap VT340, it probably is just an "A", not a "G+"
version :(

Re: Early Programming Books

[Daniel Moniz via cctalk]

On Mon, Jun 21, 2021, at 12:05 AM, Van Snyder via cctalk wrote:

[snip]

> denizen of the Fortran committees) is a LALR parser generator. I use
> the generator written by Al Shannon when he was Charlie Wetherell's
> student, now updated, which implements David Pager's algorithm that
> generates a parser that is LR where necessary and LALR or SLR or LR(0)
> where possible.

Out of curiosity, which parser generator is this?; i.e., the one you use 
written by Al Shannon, and since updated? I went digging in my files and 
online, though only cursorily, and found Hyacc  
by Xin Chen, which I hadn't previously known about, but was wondering if you 
were referring to it, or something else, maybe the original implementation of 
LR in Fortran 66, e.g. 
?


-- 
Daniel Moniz  [http://pobox.com/~dnm/]