Re: And speaking of ALGOL

[Nigel Williams]

On 11 Aug 2015, at 3:05 pm, Nigel Williams  
wrote:
> 
> On Tue, Aug 11, 2015 at 12:07 PM, Mark Kahrs  wrote:
>> One could always implement a KDF9 emulator and then port Randall and
>> Russell code (from the book).
> 
> Both of those requirements are already done:
> 
> http://www.findlayw.plus.com/KDF9/emulation/emulator.html

BTW, there is a write-up of this ALGOL compiler by one of the authors here:

http://www.cs.man.ac.uk/CCS/res/res50.htm#e

a sort of who’s who of early ALGOL implementations.

Re: DEC RX02-PA?

[Jochen Kunz]

Am 10.08.15 um 00:06 schrieb Pete Turnbull:
> There's an official DEC mounting kit to mount 2 x RX33 where you'd
> normally find an RX50 in a BA23/BA123.  It's basically two side plates,
> to hold the upper and lower drives together.
I basically did this to mount two EDSI half height disks in my BA23 that
holds my 11/23. The lower drive attaches to the BA(1)23 drive sled by
the bottom screws. The upper drive attaches to the lower drive by a
plate on the left and right side each. The two plates are the front
bezels from dead MFM disks. I just drilled holes for the side screws
into them.
-- 

tschüß,
   Jochen

Re: OT: Slow booting, was re: Booting an IBM MP 3000 S/390 System

[Noel Chiappa]

> From: Chuck Guzis

> Could it be that the presence of ECC registered SDRAM requires that
> every memory location get written before boot-up can proceed? There's
> 2GB of the stuff, so that could be the difference.

I was going to suggest that, actually. Turning on ECC in the memory in a
somewhat older HP minitower machine caused a long delay in booting while it
cleared all the memory.

Noel

Re: And speaking of ALGOL

[Noel Chiappa]

> From: Chuck Guzis

> Why all this DEC stuff about Algol? 

I probably started it; I just mentioned the PDP-11 one because a lot of
people already have either 11's, or an emulator up and running.

Noel

R: Booting an IBM MP 3000 S/390 System

[Mazzini Alessandro]

Well, that was an interesting video. How long did it take to get it fully 
loaded ?
The "service" Celeron board, is it interfaced internally to the rest, or 
externally ?

-Messaggio originale-
Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Guy Sotomayor
Inviato: martedì 11 agosto 2015 07:08
A: General@main.local; Discussion@main.local:On-Topic and Off-Topic Posts
Oggetto: Re: Booting an IBM MP 3000 S/390 System

z/OS is a licensed product from IBM (read $$$'s involved). Generally you can't 
run anything newer than MVS 3.8j on Hercules.  See the Hercules website 
(http://www.hercules-390.eu). It has links to other sites where you can get 
various OS's and other programs that can be legally run.

Note that there is a "turnkey" system for MVS 3.8j that is set up for Hercules 
that has an ISPF-like clone.  I have that set up to run on my Mac.  I also have 
the VM/370 "sixpack" installed as well when I want to run VM/370.

The version of z/OS installed on my MP3000 does have ISPF (along with lots of 
other program
products) installed.

TTFN - Guy

On 8/10/15 2:33 PM, Sean Caron wrote:
> Does it include ISPF? Using MVS is a bear without it...
>
> Best,
>
> Sean
>
>
> On Mon, Aug 10, 2015 at 5:17 PM, Mazzini Alessandro  wrote:
>
>> Well, there's a z/os image for hercules, floating around
>>
>> -Messaggio originale-
>> Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Kevin 
>> Monceaux
>> Inviato: lunedì 10 agosto 2015 21:55
>> A: General Discussion: On-Topic and Off-Topic Posts
>> Oggetto: Re: Booting an IBM MP 3000 S/390 System
>>
>> Guy,
>>
>> On Tue, Aug 04, 2015 at 11:20:42PM -0700, Guy Sotomayor wrote:
>>
>>> I spent some time today and made a video of my MP 3000 system 
>>> booting up to z/OS.  The video is here: http://youtu.be/WnJmeQR0GQU.
>> Sadly I'll have to wait until I get home to watch it.  YouTube is 
>> blocked where I work.  I suspect I'll be experiencing extreme envy as I 
>> watch it.
>> The closest I have is Hercules running the OSes freely available to 
>> hobbyists.  Just one thing - one doesn't boot z/OS, one IPL's z/OS.  
>> :-)
>>
>>
>>
>> --
>>
>> Kevin
>> http://www.RawFedDogs.net
>> http://www.Lassie.xyz
>> http://www.WacoAgilityGroup.org
>> Bruceville, TX
>>
>> What's the definition of a legacy system? One that works!
>> Errare humanum est, ignoscere caninum.
>>
>>

Re: Booting an IBM MP 3000 S/390 System

[Sean Caron]

I don't think you're allowed to run z/OS on Hercules even if you pay IBM,
no? Or did they lift that restriction? The licensing on the image which
Alessandro is referring to is undoubtedly questionable in the whole; I was
just curious, since it sounds like he maybe had seen it before, if it was
"complete" and had big layered products like ISPF included and working as
well.

Best,

Sean


On Tue, Aug 11, 2015 at 1:08 AM, Guy Sotomayor  wrote:

> z/OS is a licensed product from IBM (read $$$'s involved). Generally you
> can't run anything newer
> than MVS 3.8j on Hercules.  See the Hercules website (
> http://www.hercules-390.eu). It has links
> to other sites where you can get various OS's and other programs that can
> be legally run.
>
> Note that there is a "turnkey" system for MVS 3.8j that is set up for
> Hercules that has an ISPF-like
> clone.  I have that set up to run on my Mac.  I also have the VM/370
> "sixpack" installed as well
> when I want to run VM/370.
>
> The version of z/OS installed on my MP3000 does have ISPF (along with lots
> of other program
> products) installed.
>
> TTFN - Guy
>
>
> On 8/10/15 2:33 PM, Sean Caron wrote:
>
>> Does it include ISPF? Using MVS is a bear without it...
>>
>> Best,
>>
>> Sean
>>
>>
>> On Mon, Aug 10, 2015 at 5:17 PM, Mazzini Alessandro 
>> wrote:
>>
>> Well, there's a z/os image for hercules, floating around
>>>
>>> -Messaggio originale-
>>> Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Kevin
>>> Monceaux
>>> Inviato: lunedì 10 agosto 2015 21:55
>>> A: General Discussion: On-Topic and Off-Topic Posts
>>> Oggetto: Re: Booting an IBM MP 3000 S/390 System
>>>
>>> Guy,
>>>
>>> On Tue, Aug 04, 2015 at 11:20:42PM -0700, Guy Sotomayor wrote:
>>>
>>> I spent some time today and made a video of my MP 3000 system booting
 up to z/OS.  The video is here: http://youtu.be/WnJmeQR0GQU.

>>> Sadly I'll have to wait until I get home to watch it.  YouTube is blocked
>>> where I work.  I suspect I'll be experiencing extreme envy as I watch it.
>>> The closest I have is Hercules running the OSes freely available to
>>> hobbyists.  Just one thing - one doesn't boot z/OS, one IPL's z/OS.  :-)
>>>
>>>
>>>
>>> --
>>>
>>> Kevin
>>> http://www.RawFedDogs.net
>>> http://www.Lassie.xyz
>>> http://www.WacoAgilityGroup.org
>>> Bruceville, TX
>>>
>>> What's the definition of a legacy system? One that works!
>>> Errare humanum est, ignoscere caninum.
>>>
>>>
>>>
>

Re: Still seeking 3B2 information

[Jerry Kemp]

Hello Seth,

We were having a 3B2 discussion on the Sun Rescue list, and that got me to 
thinking about your emulator project.


Can you share a status update?

Is there anything us non-developers can do to assist?

Thank you,

Jerry


On 01/19/15 01:45 PM, Seth Morabito wrote:

Hi everyone,

I've made tremendous progress on my 3B2 emulator. It's being
implemented under the SIMH simulator platform, which has been a huge
help.

My WE32100 core is getting closer to being complete. I'd consider it
alpha quality right now, but it has enough instruction coverage to
pass the 3B2's power-on self tests and to (barely) run some of the 3B2
firmware mode tools.

Implementing the WE32100 core has been thanks to the processor manual
and assembly language manuals that are available on BitSavers, but
outside of the CPU, virtually all of my understanding of the 3B2's
architecture has come from studying the ROMs and the SYSVR3 source
code. I've also been helped by having remote access to a running 3B2
so I can assemble and disassemble code using the real AT&T tools.
Beyond that, I have found precious little documentation.

I'm at the point now where I'm pretty well stuck until I can find more
information. I understand large chunks of the memory map now and
should be able to do things like simulate the floppy and hard disk
controller, but there are large gaps in my understanding. There are
many undocumented registers that are used by the firmware, but don't
appear in the SYSV source code anywhere. What they mean and what
they're for is anybody's guess. I've just stubbed them out for now.

If anybody has access to schematics, architecture docs, or other
memory map information, I'd be eternally grateful if you could share
it!

-Seth

Re: And speaking of ALGOL

[Paul Koning]

> On Aug 11, 2015, at 1:16 AM, Chuck Guzis  wrote:
> 
> On 08/10/2015 07:07 PM, Mark Kahrs wrote:
>> One could always implement a KDF9 emulator and then port Randall and
>> Russell code (from the book).
>> 
>> And r.e. ALGOL68, Peter Hibbard had some sort of ALGOL68 system
>> working on the PDP11s at CMU I believe.
> 
> Why all this DEC stuff about Algol?  Go to the source--the Burroughs B5500 
> (or if you want, the B5000).  A piece of engineering much advanced for its 
> time.

Yes, that was a pretty nice system.  Certainly not the first ALGOL system, but 
a decent one even though they did put a bunch of Fortran-like ugliness into the 
I/O.  

PDP11 DECUS ALGOL was clearly inspired by that, it’s a subset of Burroughs 
ALGOL and the generated code looks like a 16-bit variant of B5500 machine code.

Note though that some of the discussion was about Algol 68, which is a rather 
different language.  I don’t know that Burroughs ever did anything with it, but 
some other companies did (CDC for one).
> 
> Did DEC ever produce a machine that ate Algol as its native programming 
> language?

“native” in what sense?  There are plenty of machines, from many companies, 
that support block structured languages well.  The PDP11 and VAX are among 
those, as are the Burroughs mainframes, the Electrologica EL-X8, and many 
others.  If so, they will do well at Algol, Pascal, C, Modula, Ada, and so on.

Some other machines don’t make stack operations and recursive functions easy, 
and as such could be called “Fortran machines” — CDC 6000 series, IBM 360, and 
PDP-8 are examples.  Still, with a bit of extra work those too can handle Algol 
and other block-structured languages.  After all, the first Pascal was 
implemented on the CDC 6600 (by ETH Zürich).  And CDC shipped both Algol 60 and 
Algol 68 compilers.  IBM had an Algol 60 for OS/360, as I recall, though I’ve 
never used it.

If you mean “native” in the sense of an instruction set tailored for running 
Algol programs, no — in that sense, Burroughs was rather unusual, though you 
might point at the Electrologica EL-X8 as another example.

paul

Re: And speaking of ALGOL

[Chuck Guzis]

On 08/11/2015 07:52 AM, Paul Koning wrote:


Yes, that was a pretty nice system.  Certainly not the first ALGOL
system, but a decent one even though they did put a bunch of
Fortran-like ugliness into the I/O.


As I recall, the I/O in the Algol-60 report was not particularly 
well-defined.  Pascal followed this pattern also.


So Burroughs could hardly be blamed.


PDP11 DECUS ALGOL was clearly inspired by that, it’s a subset of
Burroughs ALGOL and the generated code looks like a 16-bit variant of
B5500 machine code.


I hadn't realized that descriptors had been implemented on the PDP-11.


Note though that some of the discussion was about Algol 68, which is
a rather different language.  I don’t know that Burroughs ever did
anything with it, but some other companies did (CDC for one).


I don't know where Algol 68 in the CDC world came from; I am aware of no 
one in CPD Sunnyvale who worked on it.  Was it a VIM contribution?



“native” in what sense?  There are plenty of machines, from many
companies, that support block structured languages well.  The PDP11
and VAX are among those, as are the Burroughs mainframes, the
Electrologica EL-X8, and many others.  If so, they will do well at
Algol, Pascal, C, Modula, Ada, and so on.


Well, CDC 6600 routinely beat out IBM's iron on COBOL, even without 
character addressability or the capability for decimal arithmetic.



If you mean “native” in the sense of an instruction set tailored for
running Algol programs, no — in that sense, Burroughs was rather
unusual, though you might point at the Electrologica EL-X8 as another
example.


That's exactly what I mean.

--Chuck

Re: And speaking of ALGOL

[Paul Koning]

> On Aug 11, 2015, at 11:24 AM, Chuck Guzis  wrote:
> 
> On 08/11/2015 07:52 AM, Paul Koning wrote:
> 
>> Yes, that was a pretty nice system.  Certainly not the first ALGOL
>> system, but a decent one even though they did put a bunch of
>> Fortran-like ugliness into the I/O.
> 
> As I recall, the I/O in the Algol-60 report was not particularly 
> well-defined.  Pascal followed this pattern also.

It was not defined at all.  

> 
> So Burroughs could hardly be blamed.

I wouldn’t conclude that.  The natural way to do I/O in Algol is exactly what 
it is in C: using a set of libraries.  In fact, C is arguably no different than 
Algol in that I/O is not part of the base language.  The difference is that in 
C there came to be a fairly consistent “standard library”.

The Dutch Algol implementations use that model, and there were several 
different compilers that used roughly the same set of functions.  With that 
approach, all that is needed by way of extension to Algol is the addition of a 
“string” type (for literal strings, not string variables, minimally).

Burroughs however took a very different route, which is much more invasive into 
the underlying language, and feels a lot like a grafting of Fortran FORMAT 
statements onto Algol.

> 
>> PDP11 DECUS ALGOL was clearly inspired by that, it’s a subset of
>> Burroughs ALGOL and the generated code looks like a 16-bit variant of
>> B5500 machine code.
> 
> I hadn't realized that descriptors had been implemented on the PDP-11.

Not in the PDP-11 machine architecture.  DECUS Algol is a P-code 
implementation: the generated binary is pretty much Burroughs machine code 
apart from the word length, and the runtime library interprets that code.  So 
you see descriptors there, and B5500 style stack operations, and all that, but 
it isn’t native PDP-11 machine code.

> 
>> Note though that some of the discussion was about Algol 68, which is
>> a rather different language.  I don’t know that Burroughs ever did
>> anything with it, but some other companies did (CDC for one).
> 
> I don't know where Algol 68 in the CDC world came from; I am aware of no one 
> in CPD Sunnyvale who worked on it.  Was it a VIM contribution?

No, it was a CDC product, but developed by CDC Holland (at their Rijswijk 
office).  Apparently it was created at the insistence of a number of CDC’s 
academic customers in Europe.

> 
>> “native” in what sense?  There are plenty of machines, from many
>> companies, that support block structured languages well.  The PDP11
>> and VAX are among those, as are the Burroughs mainframes, the
>> Electrologica EL-X8, and many others.  If so, they will do well at
>> Algol, Pascal, C, Modula, Ada, and so on.
> 
> Well, CDC 6600 routinely beat out IBM's iron on COBOL, even without character 
> addressability or the capability for decimal arithmetic.

Which makes sense; it demonstrates what nearly everyone now knows, which is 
that RISC architecture is a very good way to design a computer.
> 
>> If you mean “native” in the sense of an instruction set tailored for
>> running Algol programs, no — in that sense, Burroughs was rather
>> unusual, though you might point at the Electrologica EL-X8 as another
>> example.
> 
> That's exactly what I mean.

I suspect part of the reason is that Algol wasn’t all that popular in the USA 
even if its heyday.  Add to that the fact that most computer designers weren’t 
all that skilled in software.  And finally, as the RISC experience has shown, 
it isn’t really worth it — a well designed RISC architecture supports any 
language well, with a simpler, faster, and more economical hardware 
architecture.

paul

Re: R: Booting an IBM MP 3000 S/390 System

[Guy Sotomayor]

It takes 20-30 minutes from the time that I hit the power switch until 
there's a login
screen on the 3179s (not including the time it takes to IML the 3174 
controller).  So

you can see, I did a bit of editing to get a 9 minute video.  ;-)

The service board is located in the chassis.  It plugs into the PCI 
backplane.  However
other z/Series machines have an "external" laptop (though from what I 
can tell, there's
a drawer that the laptop sits in that you pull out when you need to do 
something with

the service element.

TTFN - Guy

On 8/11/15 5:44 AM, Mazzini Alessandro wrote:

Well, that was an interesting video. How long did it take to get it fully 
loaded ?
The "service" Celeron board, is it interfaced internally to the rest, or 
externally ?

-Messaggio originale-
Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Guy Sotomayor
Inviato: martedì 11 agosto 2015 07:08
A: General@main.local; Discussion@main.local:On-Topic and Off-Topic Posts
Oggetto: Re: Booting an IBM MP 3000 S/390 System

z/OS is a licensed product from IBM (read $$$'s involved). Generally you can't 
run anything newer than MVS 3.8j on Hercules.  See the Hercules website 
(http://www.hercules-390.eu). It has links to other sites where you can get 
various OS's and other programs that can be legally run.

Note that there is a "turnkey" system for MVS 3.8j that is set up for Hercules that has 
an ISPF-like clone.  I have that set up to run on my Mac.  I also have the VM/370 
"sixpack" installed as well when I want to run VM/370.

The version of z/OS installed on my MP3000 does have ISPF (along with lots of 
other program
products) installed.

TTFN - Guy

On 8/10/15 2:33 PM, Sean Caron wrote:

Does it include ISPF? Using MVS is a bear without it...

Best,

Sean


On Mon, Aug 10, 2015 at 5:17 PM, Mazzini Alessandro  wrote:


Well, there's a z/os image for hercules, floating around

-Messaggio originale-
Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Kevin
Monceaux
Inviato: lunedì 10 agosto 2015 21:55
A: General Discussion: On-Topic and Off-Topic Posts
Oggetto: Re: Booting an IBM MP 3000 S/390 System

Guy,

On Tue, Aug 04, 2015 at 11:20:42PM -0700, Guy Sotomayor wrote:


I spent some time today and made a video of my MP 3000 system
booting up to z/OS.  The video is here: http://youtu.be/WnJmeQR0GQU.

Sadly I'll have to wait until I get home to watch it.  YouTube is
blocked where I work.  I suspect I'll be experiencing extreme envy as I watch 
it.
The closest I have is Hercules running the OSes freely available to
hobbyists.  Just one thing - one doesn't boot z/OS, one IPL's z/OS.
:-)



--

Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

Re: And speaking of ALGOL

[Chuck Guzis]

On 08/11/2015 08:37 AM, Paul Koning wrote:


No, it was a CDC product, but developed by CDC Holland (at their

Rijswijk office). Apparently it was created at the insistence of a
number of CDC’s academic customers in Europe.

Which explains why I never saw it at CPD SVLOPS.  CDC in those days was 
fond of "bootleg" products.  MACE/KRONOS/NOS being the chiefest of them. 
 At least one program that I wrote (in a week) was turned into an 
official product, complete with reference manual.  It was never intended 
as anything more than a way fro me to get my own work done.  "Ports" of 
it were downright silly.



Which makes sense; it demonstrates what nearly everyone now knows,
which is that RISC architecture is a very good way to design a
computer.


What it told me was that byte.character addressability wasn't all that 
it was cracked up to be.  Even after the CYBER 70 introduced the CMU (on 
the 72/73 only; not on the 74), use of it didn't contribute massively to 
the speed of COBOL.



I suspect part of the reason is that Algol wasn’t all that popular in
the USA even if its heyday. Add to that the fact that most computer
designers weren’t all that skilled in software. And finally, as the
RISC experience has shown, it isn’t really worth it.


...which is why we're all working in x86 today. :)

What RISC does demand is a fast memory system.  The 6600 had 1 usec 
memory interleaved 10 ways, so it could issue a read or write every 
machine cycle (100 nsec).  Without that, the 6600 could well have been a 
real dog.


--Chuck

RE: Booting an IBM MP 3000 S/390 System

[Dave G4UGM]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Sean
> Caron
> Sent: 11 August 2015 14:38
> To: General Discussion: On-Topic and Off-Topic Posts
> ; Sean Caron 
> Subject: Re: Booting an IBM MP 3000 S/390 System
> 
> I don't think you're allowed to run z/OS on Hercules even if you pay IBM, no?

That depends on your zOS licence. Different countries have different laws. I 
believe that the current Z partner developer licences specifically restrict 
running zOS on anything other than the supplied emulator and IBM has taken 
steps to encrypt the disks  to prevent you from even trying. On the other hand 
some of the older MVS licences allowed you to run on anything in a disaster 
recovery situation, including Disaster recovery testing. I believe these 
clauses have been modified in the current licence but I don't have a copy to 
look at...

> Or did they lift that restriction? The licensing on the image which Alessandro
> is referring to is undoubtedly questionable in the whole; I was just curious,
> since it sounds like he maybe had seen it before, if it was "complete" and had
> big layered products like ISPF included and working as well.

It depends on how it was originally licenced. If it was on a Monthly Charge the 
licence on the MP3000 will have expired. If it was purchased then the original 
owners will have a licence and it may be possible to transfer it...

> 
> Best,
> 
> Sean
> 

Dave
G4UGM


> 
> On Tue, Aug 11, 2015 at 1:08 AM, Guy Sotomayor 
> wrote:
> 
> > z/OS is a licensed product from IBM (read $$$'s involved). Generally
> > you can't run anything newer than MVS 3.8j on Hercules.  See the
> > Hercules website ( http://www.hercules-390.eu). It has links to other
> > sites where you can get various OS's and other programs that can be
> > legally run.
> >
> > Note that there is a "turnkey" system for MVS 3.8j that is set up for
> > Hercules that has an ISPF-like clone.  I have that set up to run on my
> > Mac.  I also have the VM/370 "sixpack" installed as well when I want
> > to run VM/370.
> >
> > The version of z/OS installed on my MP3000 does have ISPF (along with
> > lots of other program
> > products) installed.
> >
> > TTFN - Guy
> >
> >
> > On 8/10/15 2:33 PM, Sean Caron wrote:
> >
> >> Does it include ISPF? Using MVS is a bear without it...
> >>
> >> Best,
> >>
> >> Sean
> >>
> >>
> >> On Mon, Aug 10, 2015 at 5:17 PM, Mazzini Alessandro 
> >> wrote:
> >>
> >> Well, there's a z/os image for hercules, floating around
> >>>
> >>> -Messaggio originale-
> >>> Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Kevin
> >>> Monceaux
> >>> Inviato: lunedì 10 agosto 2015 21:55
> >>> A: General Discussion: On-Topic and Off-Topic Posts
> >>> Oggetto: Re: Booting an IBM MP 3000 S/390 System
> >>>
> >>> Guy,
> >>>
> >>> On Tue, Aug 04, 2015 at 11:20:42PM -0700, Guy Sotomayor wrote:
> >>>
> >>> I spent some time today and made a video of my MP 3000 system
> >>> booting
>  up to z/OS.  The video is here: http://youtu.be/WnJmeQR0GQU.
> 
> >>> Sadly I'll have to wait until I get home to watch it.  YouTube is
> >>> blocked where I work.  I suspect I'll be experiencing extreme envy as I
> watch it.
> >>> The closest I have is Hercules running the OSes freely available to
> >>> hobbyists.  Just one thing - one doesn't boot z/OS, one IPL's z/OS.
> >>> :-)
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Kevin
> >>> http://www.RawFedDogs.net
> >>> http://www.Lassie.xyz
> >>> http://www.WacoAgilityGroup.org
> >>> Bruceville, TX
> >>>
> >>> What's the definition of a legacy system? One that works!
> >>> Errare humanum est, ignoscere caninum.
> >>>
> >>>
> >>>
> >

RE: R: Booting an IBM MP 3000 S/390 System

[Dave G4UGM]

The MP3000 red book explains how the system fits together. An interesting read 
even if you don't have one..

http://www.redbooks.ibm.com/abstracts/sg245633.html

Dave Wade
G4UGM

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Guy
> Sotomayor
> Sent: 11 August 2015 16:51
> To: General@main.local; Discussion@main.local:On-Topic and Off-Topic Posts
> 
> Subject: Re: R: Booting an IBM MP 3000 S/390 System
> 
> It takes 20-30 minutes from the time that I hit the power switch until there's
> a login screen on the 3179s (not including the time it takes to IML the 3174
> controller).  So you can see, I did a bit of editing to get a 9 minute video. 
>  ;-)
> 
> The service board is located in the chassis.  It plugs into the PCI backplane.
> However other z/Series machines have an "external" laptop (though from
> what I can tell, there's a drawer that the laptop sits in that you pull out 
> when
> you need to do something with the service element.
> 
> TTFN - Guy
> 
> On 8/11/15 5:44 AM, Mazzini Alessandro wrote:
> > Well, that was an interesting video. How long did it take to get it fully
> loaded ?
> > The "service" Celeron board, is it interfaced internally to the rest, or
> externally ?
> >
> > -Messaggio originale-
> > Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Guy
> > Sotomayor
> > Inviato: martedì 11 agosto 2015 07:08
> > A: General@main.local; Discussion@main.local:On-Topic and Off-Topic
> > Posts
> > Oggetto: Re: Booting an IBM MP 3000 S/390 System
> >
> > z/OS is a licensed product from IBM (read $$$'s involved). Generally you
> can't run anything newer than MVS 3.8j on Hercules.  See the Hercules
> website (http://www.hercules-390.eu). It has links to other sites where you
> can get various OS's and other programs that can be legally run.
> >
> > Note that there is a "turnkey" system for MVS 3.8j that is set up for
> Hercules that has an ISPF-like clone.  I have that set up to run on my Mac.  I
> also have the VM/370 "sixpack" installed as well when I want to run VM/370.
> >
> > The version of z/OS installed on my MP3000 does have ISPF (along with
> > lots of other program
> > products) installed.
> >
> > TTFN - Guy
> >
> > On 8/10/15 2:33 PM, Sean Caron wrote:
> >> Does it include ISPF? Using MVS is a bear without it...
> >>
> >> Best,
> >>
> >> Sean
> >>
> >>
> >> On Mon, Aug 10, 2015 at 5:17 PM, Mazzini Alessandro 
> wrote:
> >>
> >>> Well, there's a z/os image for hercules, floating around
> >>>
> >>> -Messaggio originale-
> >>> Da: cctalk [mailto:cctalk-boun...@classiccmp.org] Per conto di Kevin
> >>> Monceaux
> >>> Inviato: lunedì 10 agosto 2015 21:55
> >>> A: General Discussion: On-Topic and Off-Topic Posts
> >>> Oggetto: Re: Booting an IBM MP 3000 S/390 System
> >>>
> >>> Guy,
> >>>
> >>> On Tue, Aug 04, 2015 at 11:20:42PM -0700, Guy Sotomayor wrote:
> >>>
>  I spent some time today and made a video of my MP 3000 system
>  booting up to z/OS.  The video is here:
> http://youtu.be/WnJmeQR0GQU.
> >>> Sadly I'll have to wait until I get home to watch it.  YouTube is
> >>> blocked where I work.  I suspect I'll be experiencing extreme envy as I
> watch it.
> >>> The closest I have is Hercules running the OSes freely available to
> >>> hobbyists.  Just one thing - one doesn't boot z/OS, one IPL's z/OS.
> >>> :-)
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Kevin
> >>> http://www.RawFedDogs.net
> >>> http://www.Lassie.xyz
> >>> http://www.WacoAgilityGroup.org
> >>> Bruceville, TX
> >>>
> >>> What's the definition of a legacy system? One that works!
> >>> Errare humanum est, ignoscere caninum.
> >>>
> >>>

cctalk@classiccmp.org

[Brad Parker]

On 8/9/15 1:12 PM, Noel Chiappa wrote:

This all makes sense - if one can reach into the CPU, it's definitely
plausible to have an upgrade which expands the size of the PARs (unlike the
ENABLE board from Able).


I know I'm late to this discussion, but are you aware of this:

http://bitsavers.trailing-edge.com/pdf/konelar/RVM128-RVM512_UM_1982.pdf

It's basically bank switched unibus memory.  Not split I&D, I know but 
might be interesting.  And not QBUS, I know.  But I thought I'd mention 
it, since at one point in the discussion I could swear there was talk of 
the 11/34 two board set.


I somehow ended up with a bunch of these boards, and some blanks and 
enough spares to finish some of the blanks.  If you are interested I'd 
be more than happy to "share".  I have a working 11/34 and 11/44 so I 
could even test them.  I think I might need to blow some PALs, but I can 
do that if I can find the right parts (gals, most likely these days).


-brad

Re: And speaking of ALGOL

[Paul Koning]

> On Aug 11, 2015, at 12:20 PM, Chuck Guzis  wrote:
> 
> ...
>> I suspect part of the reason is that Algol wasn’t all that popular in
>> the USA even if its heyday. Add to that the fact that most computer
>> designers weren’t all that skilled in software. And finally, as the
>> RISC experience has shown, it isn’t really worth it.
> ...
> What RISC does demand is a fast memory system.  The 6600 had 1 usec memory 
> interleaved 10 ways, so it could issue a read or write every machine cycle 
> (100 nsec).  Without that, the 6600 could well have been a real dog.

Every machine needs a fast memory system.  CISC machines just as much, after 
all the number of memory references per operation of a given kind doesn’t 
depend on the sort of CPU architecture you use.  All that changes is whether 
the cycles are issued by regular machine code, or micro-engine actions.

A full-up 6600 is 32 way interleaved; half size you get 16 way interleaving.  
Once nice benefit is that context switching takes only a few microseconds, 
because the exchange jump would swap current and new context at memory speed: 
16 words issued at 100 ns intervals once the operation gets moving.

paul

Fwd: sparc20 available in boston

[Paul Koning]

Posting this for another NetBSD developer.  Please contact him directly if 
interested; I don’t have any additional information.

paul

> Begin forwarded message:
> 
> From: David Holland 
> Subject: sparc20 available in boston
> Date: August 11, 2015 at 2:05:41 PM EDT
> 
> I have a sparc20 sitting in my office that I need to get rid of for
> space reasons. Anyone in Boston want it? I do not have time to deal
> with shipping it, but you're welcome to try to persuade someone else
> around here to do that :-)
> 
> It has a keyboard and mouse, and I think a framebuffer, but no
> monitor. There are I think two or three cpu modules, though I vaguely
> recall there being an issue with one of them. Dunno how much RAM it
> has.
> 
> Deadline is Friday, although if someone speaks up by then I might be
> able to hold it until the end of the month. Otherwise it gets thrown
> out...
> 
> -- 
> David A. Holland
> dholl...@netbsd.org

Re: And speaking of ALGOL

[ben]

On 8/11/2015 9:37 AM, Paul Koning wrote:


Which makes sense; it demonstrates what nearly everyone now knows,
which is that RISC architecture is a very good way to design a
computer.


*NO*
(Not with a single memory bus, that is)

Have gun ... will travel. -:)
Ben.

msc 8009 docs

[joseph lang]

I'm trying to find docs for monolithic systems 8009 board.
multibus I, z80, RAM ROM 2 serial, FDC.
I see references to the board online but no actual docs.
I'm looking for information (schematic) for the on board interrupt logic
and bus interface.

I've figured out enough to get CP/M 2.2 running on it but things like
interrupts,bus time out and arbitration are implemented in PALs and defy
my attempts at reverse engineering.

Even docs from another model (800X) may prove useful since similar
logic may be used.

thanks
joe lang

Re: cctech Digest, Vol 14, Issue 10

[Clem Cole]

On Mon, Aug 10, 2015 at 1:00 PM,  wrote:

> From: Brent Hilpert 
>
> There was also AlgolW, supported on MTS.
>
> As MTS was being mentioned earlier I was going to ask if anyone knew
> whether the AlgolW compiler was included in the available distribution.
>

​The sources are available - they were googlable - send me a note off list
and I can put together a tar image of what I have.  FYI:  It was written
PL/360.  I did some hacking on it under TSS years ago.​ IIRC  Wirth did
AlgolW on the 360 at Stanford which was running one of the OS/360 flavors.
  CMU ported to TSS and Michigan to MTS.

also check out:
The Programming Languages Genealogy Project

http://everything2.com/title/the+Programming+Languages+Genealogy+Project

​Clem​

Re: And speaking of ALGOL

[Noel Chiappa]

> From: Paul Koning

> Every machine needs a fast memory system. CISC machines just as much,
> after all the number of memory references per operation of a given kind
> doesn't depend on the sort of CPU architecture you use.

You're forgetting the memory bandwidth for the instruction fetching. RISC
machines execute a stream of simple, low-level instructions, whereas CISC
machines tend to do fewer, (semantically) higher-level operations - and in
the process, use less memory bandwidth for instructions.

To be tedious (sorry), for example, instead of of the RISC instruction
sequence 'move register Ra to Rt1; add constant X to Rt1; move mem loc (Rt1)
to Rt2; add Rn to Rt2; move Rt2 to mem loc (Rt1)', a CISC would just do 'add
Rn to mem loc X[Ra]'. Same number of _data_ reads/writes, but a very different
count of instruction fetches.

The CISC tradeoff (fewer, slower, instructions) made sense 'back in the day',
and not just for memory bandwidth - it made for more compact code, back when
memory was in very short supply (by today's standards).

Now, of course, a number of technological changes - primarily multi-level
caches - have changed the 'sweet spot' for optimal instruction complexity,
while keeping the memory bandwidth needed for instruction fetches down.

Noel

Re: And speaking of ALGOL

[ben]

On 8/11/2015 3:13 PM, Noel Chiappa wrote:

 > From: Paul Koning

 > Every machine needs a fast memory system. CISC machines just as much,
 > after all the number of memory references per operation of a given kind
 > doesn't depend on the sort of CPU architecture you use.

You're forgetting the memory bandwidth for the instruction fetching. RISC
machines execute a stream of simple, low-level instructions, whereas CISC
machines tend to do fewer, (semantically) higher-level operations - and in
the process, use less memory bandwidth for instructions.

To be tedious (sorry), for example, instead of of the RISC instruction
sequence 'move register Ra to Rt1; add constant X to Rt1; move mem loc (Rt1)
to Rt2; add Rn to Rt2; move Rt2 to mem loc (Rt1)', a CISC would just do 'add
Rn to mem loc X[Ra]'. Same number of _data_ reads/writes, but a very different
count of instruction fetches.

The CISC tradeoff (fewer, slower, instructions) made sense 'back in the day',
and not just for memory bandwidth - it made for more compact code, back when
memory was in very short supply (by today's standards).

Now, of course, a number of technological changes - primarily multi-level
caches - have changed the 'sweet spot' for optimal instruction complexity,
while keeping the memory bandwidth needed for instruction fetches down.

Noel


But the real question is your programming model again.

It all seems to be the old FORTRAN model. Random access of
any variable from absolute address.  /common/ FOO(100),i,j,BAR(100)
... sum = FOO(j)+BAR(i-6)...

Ben.

Writing 8" floppies with SuperCard Pro

[Josh Dersch]

Here at the museum I'm evaluating the use of a SuperCard Pro 
(http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate 8" 
floppies from various machines.  It's not technically supported (the manual 
states that it *should* work but has not been tested, etc.)  The disks I'm 
reading are nothing exotic (They're standard double-density, double-sided disks 
with an IBM format -- I could use a PC and ImageDisk to do the job, but the 
SuperCard is very convenient, in theory...)

Thus far I've been successful in creating images of floppies, but less 
successful in writing them back out.  Thus far I've tried a pair of Shugart 
851s and a Qume QumeTrack 842.  I'm using a DBit FDADAP 
(http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals.  
(And the 851s are jumpered properly for the TG43 signal, as far as I can tell). 
 I've also tried a variety of media (Verbatim, Maxell) with the same results 
(though the position of the bad data varies from attempt to attempt).

The issue is that upon reading back a disk that has been written via the 
SuperCard, data is fine up until about cylinder 60, at which point bad sectors 
start appearing more and more frequently (though most of the data is still OK). 
 I tried disabling TG43 just to see if it made a difference, and it does - with 
TG43 disabled sectors written past cylinder 43 read back as garbage.

I'm running short of ideas.  Anyone else have any experience with this combo?  
Any suggestions on troubleshooting tips?

Thanks,
Josh

Sr. Vintage Software Engineer
Living Computer Museum
www.livingcomputermuseum.org

Re: Writing 8" floppies with SuperCard Pro

[Eric Smith]

On Tue, Aug 11, 2015 at 6:27 PM, Josh Dersch
 wrote:
> The issue is that upon reading back a disk that has been written via the 
> SuperCard, data is fine up until about cylinder 60, at which point bad 
> sectors start appearing more and more frequently (though most of the data is 
> still OK).  I tried disabling TG43 just to see if it made a difference, and 
> it does - with TG43 disabled sectors written past cylinder 43 read back as 
> garbage.

The SuperCard is apparently not using a suitable amount of write
precompensation for the drives you're using.

Re: Writing 8" floppies with SuperCard Pro

[Chuck Guzis]

On 08/11/2015 05:27 PM, Josh Dersch wrote:


The issue is that upon reading back a disk that has been written via
the SuperCard, data is fine up until about cylinder 60, at which
point bad sectors start appearing more and more frequently (though
most of the data is still OK).  I tried disabling TG43 just to see if
it made a difference, and it does - with TG43 disabled sectors
written past cylinder 43 read back as garbage.

I'm running short of ideas.  Anyone else have any experience with
this combo?  Any suggestions on troubleshooting tips?


So what does the software do to compensate for bit crowding/shifting 
when writing to the inner cylinders?That is, what sort of write 
precompensation does it perform?


--Chuck

RE: Writing 8" floppies with SuperCard Pro

[Josh Dersch]

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck Guzis
Sent: Tuesday, August 11, 2015 5:42 PM
To: gene...@classiccmp.org; Discussion@
Subject: Re: Writing 8" floppies with SuperCard Pro

> On 08/11/2015 05:27 PM, Josh Dersch wrote:

>> The issue is that upon reading back a disk that has been written via 
>> the SuperCard, data is fine up until about cylinder 60, at which point 
>> bad sectors start appearing more and more frequently (though most of 
>> the data is still OK).  I tried disabling TG43 just to see if it made 
>> a difference, and it does - with TG43 disabled sectors written past 
>> cylinder 43 read back as garbage.
>>
>> I'm running short of ideas.  Anyone else have any experience with this 
>> combo?  Any suggestions on troubleshooting tips?

> So what does the software do to compensate for bit crowding/shifting 
> when writing to the inner cylinders?That is, what sort of write 
> precompensation does it perform?

Absolutely no idea -- the  manual isn't particularly technical and the SDK 
mentions nothing.  I'll see if there's anything to be dug up in this regard.  
(Thanks also to Eric for suggesting this problem...)

- Josh

> --Chuck

Re: Writing 8" floppies with SuperCard Pro

[Al Kossow]

On 8/11/15 5:53 PM, Josh Dersch wrote:


Absolutely no idea -- the  manual isn't particularly technical and the SDK 
mentions nothing.  I'll see if there's anything to be dug up in this regard.  
(Thanks also to Eric for suggesting this problem...)

- Josh



You may want to try asking on the supercard board. the developer seems like a 
reasonable guy.

I just picked up a card recently as well.

Re: Writing 8" floppies with SuperCard Pro

[Jay Jaeger]

Looks interesting - kind of like a catweasel using a USB bus instead of
a PCI bus.

I have only used my catweasel for reading, but in theory it could write
as well.

As for floppy emulators on the drive side, I have an SD HxC Floppy
emulator (www.lotharek.pl) which I am currently using with an Altos
8000-2 to test it (just booted successfully for the first time today).
One can write to it as a floppy drive, too, which I have done - a way to
capture an image using a running system.

Aside from the write pre-comp thing which you seem to have in hand  (and
which is generally handled by the *drive*, not the controller, i.e., the
bit timing from the controller does not change, as far as I know), one
other thing you should check is to make sure that you have your
termination in place on the drive, otherwise it can mess things up on
writes.

I am presuming that your SuperCard properly terminates the *read* lines
(RawData# in particular, and, if the drive has its own data separator
and you can use it from the SuperCard Pro, SepData# and SepClk#, as
well) - otherwise that could be an issue, too.  I see a few SMD
components in the photo, but unless they are hiding under the board, I
didn't see any components placed near the connector where one might
expect termination.  I'd be really surprised if the designers forgot
that, but it never hurts to ask, just in case.

JRJ



On 8/11/2015 7:27 PM, Josh Dersch wrote:
> Here at the museum I'm evaluating the use of a SuperCard Pro 
> (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate 8" 
> floppies from various machines.  It's not technically supported (the manual 
> states that it *should* work but has not been tested, etc.)  The disks I'm 
> reading are nothing exotic (They're standard double-density, double-sided 
> disks with an IBM format -- I could use a PC and ImageDisk to do the job, but 
> the SuperCard is very convenient, in theory...)
> 
> Thus far I've been successful in creating images of floppies, but less 
> successful in writing them back out.  Thus far I've tried a pair of Shugart 
> 851s and a Qume QumeTrack 842.  I'm using a DBit FDADAP 
> (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals.  
> (And the 851s are jumpered properly for the TG43 signal, as far as I can 
> tell).  I've also tried a variety of media (Verbatim, Maxell) with the same 
> results (though the position of the bad data varies from attempt to attempt).
> 
> The issue is that upon reading back a disk that has been written via the 
> SuperCard, data is fine up until about cylinder 60, at which point bad 
> sectors start appearing more and more frequently (though most of the data is 
> still OK).  I tried disabling TG43 just to see if it made a difference, and 
> it does - with TG43 disabled sectors written past cylinder 43 read back as 
> garbage.
> 
> I'm running short of ideas.  Anyone else have any experience with this combo? 
>  Any suggestions on troubleshooting tips?
> 
> Thanks,
> Josh
> 
> Sr. Vintage Software Engineer
> Living Computer Museum
> www.livingcomputermuseum.org
> 
> 
> 
> 

Re: Writing 8" floppies with SuperCard Pro

[Fred Cisin]

On Wed, 12 Aug 2015, Josh Dersch wrote:
Thus far I've been successful in creating images of floppies, but less 
successful in writing them back out.  Thus far I've tried a pair of 
Shugart 851s and a Qume QumeTrack 842.  I'm using a DBit FDADAP


I agreee with Eric and Chuck.

A quick experiment, . . .
Howzbout take one of those images, and instead of writitng to an 8" drive, 
try writing it to a 1.2M 5.25" drive.

Re: Writing 8" floppies with SuperCard Pro

[Chuck Guzis]

On 08/11/2015 05:53 PM, Josh Dersch wrote:


Absolutely no idea -- the  manual isn't particularly technical and
the SDK mentions nothing.  I'll see if there's anything to be dug up
in this regard.  (Thanks also to Eric for suggesting this
problem...)


There should certainly be enough horsepower there to do just about 
anything.  The cheap Chinese emulators use a little STM32F0 ARM Cortex 
M0 family MCU--dirt-cheap.  There's a bit of logic to perform level 
shifting and OC interface, but that's about it.  If you encode/decode 
MFM data on the fly, 32K is more than enough for track storage at 500Khz 
and a little buffering.  Some years back, I did an emulator using a 
ATMega162 DIP and some external SRAMm running at 8MHz.  Still more than 
enough, but a little tighter in coding.  The Chinese ones get away cheap 
because the format and encoding is predetermined.


But back to write precompensation.  The general theory is this.

Outer tracks have lower linear bit densities than inner ones because 
they're longer from index to index.  (Would you rather run a race on the 
inside or the outside track?)  Thus, bits (or rather changes in 
direction of magnetization) are closer together.  Depending on head 
construction and track width, adjacent bits can be shifted via 
interference from the nominal bit timing window (yes, that means a bit 
already written can be shifted away from its nominal window timing 
center even though you put it there originally).


So, the scheme is to "write with history".  That is, a shift register is 
used to remember what was last written, what you're currently writing 
and then what's about to be written--and the write signal shifted a few 
hundred nanoseconds "early" or "late" (or not at all) according to 
current, past and future data, which produces a train that's closer to 
optimal.


All of which explains why the results with no precompensation get worse 
the shorter the track gets.


Another approach is to use "zoned" recording, where the disk is divided 
into zones of varying bit density, according to how close to the hub 
they are.  You may be familiar with this with the Victor 9000 or early 
Mac floppy drives, but the technique is much older than floppies.


Hope this helps,
Chuck

Re: msc 8009 docs

[Al Kossow]

On 8/11/15 9:43 AM, joseph lang wrote:

I'm trying to find docs for monolithic systems 8009 board.
multibus I, z80, RAM ROM 2 serial, FDC.
I see references to the board online but no actual docs.
I'm looking for information (schematic) for the on board interrupt logic
and bus interface.

I've figured out enough to get CP/M 2.2 running on it but things like
interrupts,bus time out and arbitration are implemented in PALs and defy
my attempts at reverse engineering.

Even docs from another model (800X) may prove useful since similar
logic may be used.

thanks
joe lang



I have it scanned. I'll have it up on bitsavers later tonight.

Re: msc 8009 docs

[Al Kossow]

On 8/11/15 2:48 PM, Al Kossow wrote:


I have it scanned. I'll have it up on bitsavers later tonight.



It's uploaded to http://bitsavers.org/pdf/monolithicSystems
it will take a couple of hours for the mirrors to pick it up.

Did your board have a monitor/bootstrap ROM? If so, have you dumped it?
I've got a board around somewhere..

AlgolW

[Brent Hilpert]

On 2015-Aug-11, at 11:06 AM, Clem Cole wrote:
> On Mon, Aug 10, 2015 at 1:00 PM,  wrote:
>> From: Brent Hilpert 
>> 
>> There was also AlgolW, supported on MTS.
>> 
>> As MTS was being mentioned earlier I was going to ask if anyone knew
>> whether the AlgolW compiler was included in the available distribution.
>> 
> ​The sources are available - they were googlable - send me a note off list
> and I can put together a tar image of what I have.  FYI:  It was written
> PL/360.  I did some hacking on it under TSS years ago.​ IIRC  Wirth did
> AlgolW on the 360 at Stanford which was running one of the OS/360 flavors.
>  CMU ported to TSS and Michigan to MTS.

I brought up AlgolW on the list a few years ago and someone clarified it was 
Wirth's successor to Algol 60,
but that's also interesting if the MTS compiler actually is or traces back to 
Wirth's implementation.


> also check out:
> The Programming Languages Genealogy Project
> 
> http://everything2.com/title/the+Programming+Languages+Genealogy+Project


I was, so to speak, part of the experience mentioned by user dabcanboulet there:
used AlgolW as a 1st-year student, was then subjected to Pascal in 2nd year and 
felt Pascal was a step backwards.

I still have greenbar listings of my student programs but threw out my card 
decks 20-or-so years ago.


On 2015-Aug-09, at 11:33 AM, Sean Caron wrote:
> On Sun, Aug 9, 2015 at 2:25 PM, Dave G4UGM  wrote:
>> I believe that its included, but I haven't tried it.

> Yes, *ALGOLW is included and working in the D6.0 MTS tapes.


Can't start into it now due to moving, but sometime in the future I may look at 
getting hercules and MTS going and trying out the compiler.

Re: AlgolW (was: cctech Digest, Vol 14, Issue 10)

[Mike Alexander]

--On August 11, 2015 at 2:06:43 PM -0400 Clem Cole  
wrote:



On Mon, Aug 10, 2015 at 1:00 PM, 
wrote:


From: Brent Hilpert 

There was also AlgolW, supported on MTS.

As MTS was being mentioned earlier I was going to ask if anyone knew
whether the AlgolW compiler was included in the available
distribution.



​The sources are available - they were googlable - send me a note
off list and I can put together a tar image of what I have.  FYI:  It
was written PL/360.  I did some hacking on it under TSS years ago.​
IIRC  Wirth did AlgolW on the 360 at Stanford which was running one
of the OS/360 flavors.   CMU ported to TSS and Michigan to MTS.

also check out:
The Programming Languages Genealogy Project

http://everything2.com/title/the+Programming+Languages+Genealogy+Proj
ect

​Clem​


One minor correction: it was Newcastle that ported AlgolW to MTS, not 
Michigan.


I have a TAR file with the MTS source for AlgolW and notes about how to 
install it in MTS.  The manual for AlgolW in MTS is available at 
.

Re: And speaking of ALGOL

[Mark Kahrs]

I assure you Chuck, I do know the original B5500 ALGOL having written my
first program on one.

For those of you who might be interested, I sent a listing of the B6700
ALGOL compiler source code to the CHM.

I'm surprised no one has mentioned the Burroughs extensions to ALGOL to
optimise|ize the use of the native string instructions.

Re: And speaking of ALGOL

[Chuck Guzis]

On 08/11/2015 07:23 PM, Mark Kahrs wrote:

I assure you Chuck, I do know the original B5500 ALGOL having written
my first program on one.

For those of you who might be interested, I sent a listing of the
B6700 ALGOL compiler source code to the CHM.

I'm surprised no one has mentioned the Burroughs extensions to ALGOL
to optimise|ize the use of the native string instructions.


Mark, were you ever involved with the BSP?  That, and the TI ASC were 
the dark-horse supercomputer entries way back when.


--Chuck