simulating a Burroughs B6700 system?
Nigel Williams
700-series machines and follow-on plans to recover ALGOL, ESPOL, MCP,
Intrinsics and so on with the aim to have a functional Burroughs Large
System.
The simulated model is likely to be the B5700 and/or B6700. The
current indecision is due to being unable to determine the differences
between these models and the lack of any source-code for the B6700 on
Bitsavers.
I have copies of Organick, Doran, all the relevant Bitsavers files,
results of search-engine trawling etc., however the following are
proving, so far, elusive; I hope someone can help:
o reference manuals for the B5700 - to determine differences with
the B6700
o an accurate summary of the model differences, initially B5700 -
B6700[2]
o machine readable[1] copies of BINDER, CANDE, WFL, ESPOL, ALGOL,
MCP, Intrinsics [3] [4]
o pictures of 700-series front-panel (blinkenlight) consoles,
particularly the B6700
Footnotes for list:
[1] manageable by a modern system.
[2] ultimately all the Bxx00 models - see the website below for an
attempt at a comprehensive Burroughs large systems product-model
matrix.
[3] it has been suggested to me, a couple of times, that only the
source-listings have survived.
[4] and any other required software pieces needed to start and operate
MCP.
The project is being documented here:
www.retroComputingTasmania.com (see the B6700 link)
Any comments, tips or assistance would be appreciated:
thanks,
nigel.
Chris Burrows
news:cacc5ef2-54d1-4e03...@t9g2000prh.googlegroups.com...
>
> I have copies of Organick, Doran, all the relevant Bitsavers files,
> results of search-engine trawling etc., however the following are
> proving, so far, elusive; I hope someone can help:
>
> o reference manuals for the B5700 - to determine differences with
> the B6700
You might need to take a trip to the Univeristy of Minnesota. The Charles
Babbage Institute lists the following items in their collection:
http://www.cbi.umn.edu/collections/inv/burros/cbi00090-074.html
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com
Peter Flass
> I have a project (slowly) underway to build a simulator for one of the
> 700-series machines and follow-on plans to recover ALGOL, ESPOL, MCP,
> Intrinsics and so on with the aim to have a functional Burroughs Large
> System.
Bookmarked!
Mike Hore
> I have a project (slowly) underway to build a simulator for one of the
> 700-series machines and follow-on plans to recover ALGOL, ESPOL, MCP,
> Intrinsics and so on with the aim to have a functional Burroughs Large
> System.
>
> The simulated model is likely to be the B5700 and/or B6700. The
> current indecision is due to being unable to determine the differences
> between these models and the lack of any source-code for the B6700 on
> Bitsavers.
I guess you can tell from the manuals on bitsavers that these models are
quite a bit different -- especially, the B5000/5500/5700 didn't have a
"cactus stack" or display registers. The B6500/6700 really did fix all
the shortcomings.
>
> I have copies of Organick, Doran, all the relevant Bitsavers files,
> results of search-engine trawling etc., however the following are
> proving, so far, elusive; I hope someone can help:
>
> o reference manuals for the B5700 - to determine differences with
> the B6700
AFAIK the B5700 was essentially a B5500 implemented on later technology.
But to the programmer, it was a B5500. Somebody correct me if I'm wrong.
http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1021326_B5500_RefMan_May67.pdf
This is a wonderful project, and I certainly wish you all the best!!
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
Louis Krupp
dangling pointers, etc., and you've just simulated a B6700. ;)
Louis
Nigel Williams
wrote:
> I guess you can tell from the manuals on bitsavers that these models are
> quite a bit different -- especially, the B5000/5500/5700 didn't have a
> "cactus stack" or display registers. The B6500/6700 really did fix all
> the shortcomings.
my naive appreciation was that "display registers" and hardware
support for the cactus stack were a performance optimizations and not
necessarily reflected in the ISA (instruction set architecture).
My understanding, so far, is that there is a distinct 700-series of
machines (B5700, B6700, B7700) which are "loosely" compatible,
distinct from the earlier B5000/B5500 (500-series) machines; hopefully
someone will know for sure.
But yes this is exactly one of the (many) questions which would be
useful to clarify.
I am leaning heavily on the comment by Organick in his book [1], that
suggests they were more or less equivalent except for speed, memory
expansion and multi-CPU, I/O processor capacity. I also reference this
paper http://www.ajwm.net/amayer/papers/B5000.html which contains
similar supporting comments that the B5700/B6700 only differed in
capacity and performance aspects and not ISA.
> This is a wonderful project, and I certainly wish you all the best!!
Thank you, I am not expecting it to be a swiftly and deftly executed
affair (i.e. completed in short order) but more likely a steady
incremental persistent exercise spread over months or years if needed.
Just collating the facts and technical specifications is taking quite
a bit of time!
[1] [Org73]Organick, Elliott I., Computer System Organization: The
B5700/B6700 Series. Academic Press, Inc., New York, 1973.
The principal purpose of this book is to offer through informal
exposition a hopefully revealing and fresh perspective of the B6700
(and by back reference the B5700), its general design and design
rationale, and its relative potential as a computer system. The B6700
represents in some sense a best display (i.e., an improved
representation) of the corresponding ideas in the B5700. In other
respects, such as memory size and raw speed, the B5700 is simply a
more limited version of the B6700. For this reason no explicit
discussion of the B5700 and its comparison with the B6700 will be
undertaken in this relatively
short treatment.
Nigel Williams
wrote:
> Find a PC that runs for a while without crashing due to buffer exploits,
> dangling pointers, etc., and you've just simulated a B6700. ;)
:-) Another good reason why this architecture and family of machines
should be recovered and available in a form (i.e. via a simulator) for
inspection and introspection.
Louis Krupp
> On Mar 1, 6:37 pm, Mike Hore <mike_hore...@OVE.invalid.aapt.net.au>
> wrote:
>> I guess you can tell from the manuals on bitsavers that these models are
>> quite a bit different -- especially, the B5000/5500/5700 didn't have a
>> "cactus stack" or display registers. The B6500/6700 really did fix all
>> the shortcomings.
>
> my naive appreciation was that "display registers" and hardware
> support for the cactus stack were a performance optimizations and not
> necessarily reflected in the ISA (instruction set architecture).
>
> My understanding, so far, is that there is a distinct 700-series of
> machines (B5700, B6700, B7700) which are "loosely" compatible,
> distinct from the earlier B5000/B5500 (500-series) machines; hopefully
> someone will know for sure.
>
> But yes this is exactly one of the (many) questions which would be
> useful to clarify.
I don't believe there is an architectural distinction between the B5500
and B5700. I spent a summer at the Sierra Madre Villa plant where the
B6500 was under development (I was an immature 18-year-old nerd with an
inflated sense of my own ability, so I can't say that I did anything
useful), and I don't remember the B5700 even being mentioned. There was
a cross-compiler, as I recall, that took the B6500 MCP source and
generated B6500 machine code; I have the vague notion that compiling
its own MCP was a major milestone for the B6500. The B6700 was an early
incremental improvement to the B6500.
The B7700 and the B6700 were source-code compatible, if not object-code
compatible. The B7700 featured more processors and more asynchronous
I/O if I recall correctly. The B6800 and B6900 were improvements on the
B6700, and the B7800 and B7900 were compatible successors to the B7700.
Just to keep things confusing, the B5900 was a smaller version of the
B6800 (or maybe B6900) with no resemblance to the B5500/B5700.
Louis
Scott Lurndal
We had a B6800 and a B7900 at 460 Sierra Madre Villa (Pasadena, California)
in the early 80's. The B5900 had the same form factor as the B4900
(they both used the same I/O base cabinets for DLP's). I seem to recall
the B5900 being used as a front-end processor for the B7900, but could
be all wet. Pasadena was designing and building medium systems at that
time; the B6800 was doing MIS stuff (payroll, etc). The B7900 was used
by the hardware designers to run simulations. I think the 6800 had the
global memory option.
scott
Jim Haynes
> I guess you can tell from the manuals on bitsavers that these models are
> quite a bit different -- especially, the B5000/5500/5700 didn't have a
> "cactus stack" or display registers. The B6500/6700 really did fix all
> the shortcomings.
Yes, the B5700 was simply a B5500 with the ability to attach B6500 memory
modules where the B5000/B5500 could attach drums. You don't want to
simulate it except for whimsical reasons.
Nigel Williams
I went looking in comp.arch and found an excellent post (previously
unknown to me) by Paul Kimpel covering much detail about the B5500/
B5700 and B6700 differences.
So there seems to be quite a bit of confusion between the published
texts, newsgroup comments, and other sources about lineage of the
various models.
Does anyone have releasable version-aligned copies of the B6700 ALGOL,
ESPOL and DMCP, TSS-MCP etc?
Louis Krupp
To the best of my recollection, the B6700 had the MCP, period, and the
B7000 series had its own MCP (I believe the sources were merged eventually).
The B5500, if I recall correctly, had the DF ("Disk File"?) MCP (the
original system used magnetic drums, and there may have been an MD MCP)
and the TS ("Time Sharing") MCP with support for CANDE ("Command And
Edit" system designed for teletypes and so on).
The B5500/B5700 was long ago, and its architecture was not nearly as
elegant as that of the Large Systems (B6700, etc) series. You'll have a
lot more fun emulating the B6700.
Louis
Al Kossow
> You'll have a
> lot more fun emulating the B6700.
>
There is some hope that I can recover the UCSC 5500 MCP tapes we have at the computer history museum.
I have had absolutely no luck locating software for the 6700 or later.
HVlems
Perhaps useful: I have a copy (on paper) of this book:
Burroughs B7700 Information Processing Systems Reference Manual.
Hans
Edward Reid
> my naive appreciation was that "display registers" and hardware
> support for the cactus stack were a performance optimizations and not
> necessarily reflected in the ISA (instruction set architecture).
The A/B/X/Y registers were optimizations. And the B7700 had an associative
memory cache. But the display registers were definitely part of the ISA.
> I am leaning heavily on the comment by Organick in his book [1]
Avoid leaning heavily on Organick for this project. Although he explains
the concepts very well, the details are often missing.
> Just collating the facts and technical specifications is taking quite
> a bit of time!
You've probably already been looking on bitsavers.org, which has most of
the old manuals. In those days, the details of the instruction set were
well documented. The one thing missing, then and later, was details of how
the display registers get updated. The procedure enter and exit instruction
descriptions had some detail followed by a sentence of serious arm-saving,
akin to "now magic happens". There are a number of subtleties to display
update, and especially to doing it efficiently.
The other complication that comes to mind is I/O. You probably won't have
much trouble emulating printers and card readers. Even tapes may be easy
enough. Disk will be tougher. And unlike some earlier OSs, the B6700 MCP
required disk.
Unfortunately I also cannot help with copies of the software. And if I had
kept any, they would be on nine-track NRZI tape and you'd have to find the
hardware to read them.
Edward (who hasn't dropped in here in a while, being busy with other
things, including looking for work that doesn't require serious travel)
Nigel Williams
wrote:
> Avoid leaning heavily on Organick for this project. Although he explains
> the concepts very well, the details are often missing.
Thanks for the tip, I am beginning to discover just that. I am using
Bob Doran's book as well which fills in some gaps.
> well documented. The one thing missing, then and later, was details of how
> the display registers get updated. The procedure enter and exit instruction
> descriptions had some detail followed by a sentence of serious arm-saving,
> akin to "now magic happens". There are a number of subtleties to display
> update, and especially to doing it efficiently.
Another avenue suggested is to access a Unisys ClearPath instance to
see if it shows what is going on - although a modern implementation of
e-Mode I understand much of the basics are still the same.
> Unfortunately I also cannot help with copies of the software. And if I had
> kept any, they would be on nine-track NRZI tape and you'd have to find the
> hardware to read them.
Yes, it would seem little (as of now nothing) has been kept in
readable form for the B6700. We have Burroughs Pascal for the B6700
trapped on tape. The author of DCALGOL hopes to find the tape with the
source code for same. Others are looking but so far nothing more has
come to light.
We are however having more success with the B5500 - we recently
tracked down the B5500 cold start program which initialized the disks,
loaded DMCP from tape etc.
Edward Reid
> I understand much of the basics are still the same.
Much is the same. Some instructions have been deimplemented. At least one
hardware toggle was available on the B6700 which no longer exists -- the
related ALGOL syntax was removed over 30 years ago. The biggest change is
that back then, program code could modify descriptors directly, so you have
to get the internals of descriptors exactly right. (Such code was generated
by the compilers and could not be directly written by programmers, so you
only have to be concerned with the former.)
But yes, for the great majority of the ISA, it hasn't changed. It has
changed more than on IBM systems, where programmers can execute arbitrary
code and there's no opportunity to upgrade the code by forced
recompilation. But still it's mostly the same.
Edward
--
Art Works by Melynda Reid: http://paleo.org
HVlems
Weren't the ALGOL, DMALGOL and DCALGOL compilers built from the same
source, with $ cards for conditional compilation?
Hans
Nigel Williams
> Weren't the ALGOL, DMALGOL and DCALGOL compilers built from the same
> source, with $ cards for conditional compilation?
I have corresponded with Ivan Godard who was the author of DCALGOL
(1968-1971) during the time when the B6500 group was in Pasadena. Ivan
says that any codebase merging happened after his time with the group
and possibly around the time DMALGOL was developed.
Paul Kimpel
Since DCAlgol is (or is supposed to be) a perfect superset of Extended
Algol, I find it difficult to believe that the two compilers were
maintained as separate source files, but it's even more difficult to
argue with someone who was there at the time. SYSTEM/PATCH and its
related techniques were in full flower by then, so it's possible that
the two compilers could have been maintained as separate source files by
transferring patch files from Algol to DCAlgol.
Assuming the two source files were originally separate, Ivan is probably
right about the timing of the merge of the source files -- DMAlgol was
developed shortly after his time (ca. 1973-73, as the field test for
DMSII was in 1974). I've confirmed that the three compilers are
currently generated from the same source, SYMBOL/ALGOL.
Curiously, that source (from SSR 47.1, MCP 6.0), shows patchmarks for
some of the "$SET OMIT = NOT DMALGOL" code as having been applied in
level 24 (about right for the initial DMSII development effort), but the
corresponding "$SET OMIT = NOT DCALGOL" code has NO PATCHMARK. This does
not necessarily mean that those lines are original code from the
mid/late 1960s, but it does suggest it. Still... Ivan was there and I
wasn't.
--
Paul
HVlems
I still have a hardcopy of the Mk 3.1 (I think) Algol compiler. Would
it be helpful if I dug it out and had a look?
Hans
Peter Flass
>On May 31, 4:26 am, Paul Kimpel <paul.kim...@digm.com> wrote:
>> > On 5/29/2010 10:01 PM, Nigel Williams wrote:
>> >
>>> > > On May 27, 9:10 pm, HVlems<hvl...@freenet.de> wrote:
>>>> > >> Weren't the ALGOL, DMALGOL and DCALGOL compilers built from
>the same
>>>> > >> source, with $ cards for conditional compilation?
>> >
>>> > > I have corresponded with Ivan Godard who was the author of >DCALGOL
>>> > > (1968-1971) during the time when the B6500 group was in
>Pasadena. Ivan
>>> > > says that any codebase merging happened after his time with the
>group
>>> > > and possibly around the time DMALGOL was developed.
>> >
>> > Since DCAlgol is (or is supposed to be) a perfect superset of
>Extended
>> > Algol, I find it difficult to believe that the two compilers were
>> > maintained as separate source files, but it's even more difficult >to
>> > argue with someone who was there at the time. SYSTEM/PATCH and its
>> > the two compilers could have been maintained as separate source
>files by
>> > transferring patch files from Algol to DCAlgol.
>> >
>> > Assuming the two source files were originally separate, Ivan is
>probably
>> > right about the timing of the merge of the source files -- DMAlgol
>was
>> > developed shortly after his time (ca. 1973-73, as the field test >for
>> > DMSII was in 1974). I've confirmed that the three compilers are
>> > currently generated from the same source, SYMBOL/ALGOL.
>> >
>> > Curiously, that source (from SSR 47.1, MCP 6.0), shows patchmarks >for
>> > some of the "$SET OMIT = NOT DMALGOL" code as having been applied >in
>> > level 24 (about right for the initial DMSII development effort),
>but the
>> > corresponding "$SET OMIT = NOT DCALGOL" code has NO PATCHMARK.
This >does
>> > not necessarily mean that those lines are original code from the
>> > mid/late 1960s, but it does suggest it. Still... Ivan was there and >I
>> > wasn't.
>> >
>> > --
>I still have a hardcopy of the Mk 3.1 (I think) Algol compiler. Would
>it be helpful if I dug it out and had a look?
>Hans
For some reason Thunderbird choked on replying to this, so I had to
manually cut-and-paste. Bitsavers has lots of listings for the 5500 but
nothing for the 6700. You might want to see if Al could get it scanned
and returned to you.
Nigel Williams
> I still have a hardcopy of the Mk 3.1 (I think) Algol compiler. Would
> it be helpful if I dug it out and had a look?
> Hans
Hi Hans,
you have a hardcopy listing of a B6700/7700 ALGOL compiler? that is
fantastic news as it would be the first item of software found for
that Burroughs family in an easily recoverable form.
If you want any help getting it digitised I am eager to assist.
HVlems
wrote:
Well, I did find it and have it on my desk. It's at least 2 kg, say 5
lbs.
The title reads: B5000/B6000/B7000 SERIES MARK 3.3 SYSTEM RELEASE
I scanned the first page, if you like a copy mail me at hvlems-at-
zonnet-dot-nl
Hans
Larry Krablin
ERROR; % MUST SET ALGOL, DCALGOL OR DMALGOL $ OPTION
00042000 24.048.018
Note the 2.4 patchmark. 2.4 was released sometime around 1972, as Paul
Kimpel and I can clearly recall.
Larry Krablin
Unisys MCP Architecture
"HVlems" <hvl...@freenet.de> wrote in message
news:f8576879-8471-4b51...@o15g2000vbb.googlegroups.com...
al.li...@gmail.com
Paul Kimpel
and are working (e.g., Rich Cornwell's SimH-based one at
https://sky-visions.com/burroughs/ and Nigel's and my browser-based one
at http://www.phkimpel.us/B5500/). We have a complete Mark XIII software
release from 1971, all of the source code from the Mark XV release, and
Rich has done a lot of work transcribing patch listings from
bitsavers.org in an attempt to build Mark XVI from Mark XV. Bitsavers
has a lot of documentation, including a good number of engineering
documents. See http://bitsavers.org/pdf/burroughs.
For the B6500/6700, we are nowhere near as well off. Bitsavers has a
good selection of user-level documents, but we have almost no
engineering documents for the system. There is also a good collection of
documents at the Charles Babbage Institute in Minneapolis, but those are
not on line.
Bitsavers does have listings for a pre-release version of the B6500 MCP
(Mark 0), a B6500 ESPOL compiler written for the B5500, and a batch-mode
simulator, also written for the B5500. We have transcribed those and
successfully compiled the resulting source, but not yet tried to do much
with them. See
https://github.com/retro-software/B5500-software/tree/master/B6500-Simulator.
We have a piece of the Mark II.1 source code, including the MCP, but not
the Algol or ESPOL compilers, nor the system intrinsics. The dialect of
ESPOL used with Mark II.1 changed too much to allow us to use the B5500
version of that compiler, at least in its present form. Without those
compilers and the intrinsics, it's going to be difficult to do much of
anything useful.
Thus, the project to emulate the B6500/6700 is stalled until we can
recover a couple more critical pieces of software.
We remain hopeful that more pieces (and perhaps a more complete software
release) in the form of listings and tapes are out there and will
eventually surface. We have access to recovery services for old magnetic
tapes, and some participants have successfully recovered data from
40-year old tapes. We are interested in knowing about ANYTHING anyone
has, but especially media, listings, and documents from the 1970s. If
anyone has anything they think might be relevant, please post on this
newsgroup or contact me directly. Thanks.
Paul
Hans Vlems
The ALGOL compiler listing I sent to Nigel is not useful because it is III.0 and too new?
Or is the print quality too low ?
Hans
Paul Kimpel
-------- Original Message --------
From: Hans Vlems <jhlm...@gmail.com>
Subject: simulating a Burroughs B6700 system?
problem is that it's too new. By this time (1981), 6-bit character
support (BCL) had been removed from the compiler, and I suspect a number
of MCP interfaces had changed.
Apparently the print quality was not any more serious a problem that it
would have been for any other line-printer listing of the era. Jim
Fehlinger OCR-ed the text, and I proofed it to the point it would
compile successfully under the modern MCP, but it needs another thorough
proof-reading and no doubt lots of corrections. I set that project aside
in early 2016 due to the press of other duties, and never got back to it.
Even after cleaning up the transcription -- and it's almost impossible
to catch all of the errors in a program of this size -- it would be a
very difficult task to try to back-port this compiler so that it would
work on a II.1 (1972) MCP.
If anyone is interested in picking up this project, though, and seeing
what they can do with it, I still have all the files.
Paul