Exec8 emulator
Andy Staszko
If so, do any have the source code available as well?
I want to indulge in some nostalgia and port it to OS/2(eCS).
I used to work on Univac 1100's in the 70's witing in assembler and ALGOL60.
Yes - they had an ALGOL60(!) system. They alsol had a SIMULA67 system
but I never got round to using that.
Andy Staszko
Calvin W. Kline, jr.
Univac Simulator 1.2
http://www.classiccmp.org/pipermail/cctech/2004-March/027327.html
http://www.simtel.net/product.php?url_fb_product_page=57390
"This program simulates a UNIVAC.) computer, either model I or model
II. It is written with the encouragement of UNISYS Corporation, and
accurately simulates these two computers from the middle 1950s.
Version 1.2 contains a number of bug fixes, a complete simulation of
the UNIVAC High Speed Printer (including its plugboard and its
Multi-Line capability), and a greatly improved assembler.
The program itself is freeware, but if you register (for $35) you will
get extensive documentation and an additional example tic-Tac-Toe
program."
Al Kossow
> "This program simulates a UNIVAC.) computer, either model I or model
> II.
>
>>Are there any out there hosted on the PC platform?
>>If so, do any have the source code available as well?
>>
An "Exec8" emulator would require the simulation of an 11xx
series processor, (1110, 1108, 1106, 1100/xx etc.)
A UNIVAC I or II is not remotely similar to these machines.
andrew williams
and someone asked one of the Unisys people at an open discussion if
there were plans to migrate IX machines to PC hardware in the same way
I understand the old Burroughs systems have been migrated.
The reply was that this had been experimented with, but the execution
speeds were comparable with @flit. I assumed back then that they were
talking about x86 hardware - the 64-bit Power-PC architecture was
already (?) available back then.
Now AMD have taken the big step forward in this area - 64-bit *with*
speed - maybe these plans have been revived.
George Gray
> An "Exec8" emulator would require the simulation of an 11xx
> series processor, (1110, 1108, 1106, 1100/xx etc.)
>
> A UNIVAC I or II is not remotely similar to these machines.
Very true. The UNIVAC I and II had a 72-bit word and used decimal
addressing. The modern 1100/2200 Series (1107, 1108, 1106, etc.) has
a 36-bit word and has binary addressing.
I say the modern 1100/2200 Series because the earlier 1100s were also
architecturally different. The 1101 (Atlas I) had a 24-bit word and
drum memory. The 1102 was also 24-bit/drum. The 1103 did have a
36-bit word, but in a two-address instruction format. The first 1103s
used electrostatic
memory, but the later ones used core. The 1104 was a 24-bit machine
using core memory. The 1105 was an 1103 with an improved I/O system.
The 1107 ran EXEC I or EXEC II, but never EXEC 8.
Stephen Fuld
"andrew williams" <andrew....@t-online.de> wrote in message
news:995f2314.04041...@posting.google.com...
> I was at a user-group conference back in the late 90's (at Strasbourg)
> and someone asked one of the Unisys people at an open discussion if
> there were plans to migrate IX machines to PC hardware in the same way
> I understand the old Burroughs systems have been migrated.
Sort of. The current low end of what was the A-Series are actually PC
hardware with a program, provided by Unisys, that does the emulation. But
it is only for the low end. While PC speeds have been increasing
dramatically, the cost of the emulation is such that such a system can't
compete in pure performance with dedicated hardware. Thus the high end of
that line is still done with dedicated hardware.
For the descendents of the 1100 series, the problem is somewhat worse. The
emulation would be slower, due to the difficulty of supporting 35 bits, and
partial words on 8 bit byte hardware, so it would only be performance
competitive for very low end systems. But in the IX world, as contrasted
with the A-series world, there never were any productized very low end
systems. In fact, several projects at doing "desk side" 1100s were cancelled
before productization. The thoughts back then were that it wouldn't make
money. (I make no statement about the correctness of that thought.)
So Unisys would have to make a marketing decision that they have so far
refused to do - that is, to market a low end IX series. Given that it was
problematical back then, I really question its market viability now. The
"small" 1100 sites are disappearing and there are virtually no new-name
customers, who might be candidates for such a system. There is probably a
small market for additional development or test systems for large existing
customers, or even as a partition in a one of the new clustered X86 systems,
but it isn't clear that this would be a market winner for Unisys, given the
support costs and the inevitible reduced software revenue from such a
system, and potential loss of a larger system sale.
--
- Stephen Fuld
e-mail address disguised to prevent spam.
Lueko Willms
schrieb s.f...@PleaseRemove.att.net (Stephen Fuld)
auf /COMP/SYS/UNISYS
in 5TUec.16528$K_.4...@bgtnsc05-news.ops.worldnet.att.net
ueber Re: Exec8 emulator
SF> But in the IX world, as
SF> contrasted with the A-series world, there never were any productized
SF> very low end systems. In fact, several projects at doing "desk side"
SF> 1100s were cancelled before productization.
What about the "Mapper 5" systems?
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)
Stephen Fuld
"Lueko Willms" <l.wi...@jpberlin.de> wrote in message
news:96ok1...@jpberlin-l.willms.jpberlin.de...
> Am 13.04.04
> schrieb s.f...@PleaseRemove.att.net (Stephen Fuld)
> auf /COMP/SYS/UNISYS
> in 5TUec.16528$K_.4...@bgtnsc05-news.ops.worldnet.att.net
> ueber Re: Exec8 emulator
>
> SF> But in the IX world, as
> SF> contrasted with the A-series world, there never were any productized
> SF> very low end systems. In fact, several projects at doing "desk side"
> SF> 1100s were cancelled before productization.
>
> What about the "Mapper 5" systems?
Interesting point. But AFAIR, the Mapper 5 system was not an 1100 based
system, but a 68000 type microprocessor running a ported Mapper, and nothing
else. Thus it doesn't qualify, at least by my definition, of a "deskside
1100" because it wouldn't run an arbitrary 1100 program. Indeed, it didn't
run OS 1100. But my memory may be faulty here. :-( If someone else has
memories of this system, please chime in.
I think the System 11, AKA Mapper 10, AKA 2200/100 was the smallest true
1100 system actually marketed. The Orion project, which was a smaller
system got running in development (I heard got through SYS FIN, which is
pretty far) before it was cancelled. But again, my memory may be faulty.
Tom Sherren
MAPPER 5 ran a Univac-custom version of the MUSS, the Manchester University
Software System. MUSS was a virtual memory system that ran reasonably well on
the Motorol 68000 series. The Univac version of MUSS (DSOS?) was intented
for departemental-level SperryLink servers. It ran on a SLC-built Motorola
68010/68020 platform codename "Gemstone".
They didn't use Unix, because at the time (mid 1980s) there was no way to get
a commercial license for Unix.
MAPPER 5 was succeeded by a native Unix version, called MAPPER-C.
Stephen Fuld
"Tom Sherren" <so...@no.spam.i.am> wrote in message
news:c5jv9c$1a81$1...@si05.rsvl.unisys.com...
First of all, Hi Tom. Good to hear from you.
> MAPPER 5 ran a Univac-custom version of the MUSS, the Manchester
University
> Software System. MUSS was a virtual memory system that ran reasonably
well on
> the Motorol 68000 series.
I vaguely remember that. Was MUSS the OS? Was Mapper recoded in some "MUSS
Language" prior to the C recode or was it an early version of the C recode
(pre Unix)?
Tom Sherren
Hi Stephen,
MUSS was, indeed, the operating system.
MAPPER was written in Manchester University Systems (?) Language (MUSL).
We had a lot of fun with the name. It was not a bad thing those days to be
MUSL-headed. Etc etc.
I am ignorant about the details of the MAPPER C project. There was some work
done translating MUSL to C, but I doubt that went very far.
Ah, those were the days. A 28 MB Winchester disk was the big thing.
Regards,
Tom Sherren
Al Kossow
>
> Hi Stephen,
>
> MUSS was, indeed, the operating system.
>
> MAPPER was written in Manchester University Systems (?) Language (MUSL).
> We had a lot of fun with the name. It was not a bad thing those days to be
> MUSL-headed. Etc etc.
>
> I am ignorant about the details of the MAPPER C project. There was some work
> done translating MUSL to C, but I doubt that went very far.
>
> Ah, those were the days. A 28 MB Winchester disk was the big thing.
>
> Regards,
>
> Tom Sherren
>
Is there any possiblity that the software has survived?
It would be an interesting software system to simulate
(along with 70's era Execs on 11xx's)
sro
Unisys is missing the entire point with this one - instead of worrying
about losing small customers to this potential machine (which could be
prevented with some easy crippling,<which they are already very good
at>), think of the possibilities for training, demos, and development.
I have several 'p.c.' people at my site that would love to learn more
about the 2200, but I can't afford to have them 'training' on my
production system. And being able to try out new system software
configs, gens, and do development would be invaluable. Unisys should
be GIVING a system like this away to encourage people to stay on a
2200 and to entice new people over to it. It's worth a try...the last
20 years of their lousy marketing strategy has managed to diminish
their market share for one of (if not the best) computer systems ever
made. Having a 'little' IX running on a VMware partition under W2K
would be a dream come true...and wouldn't be that hard to do...I
suspect it's already being done somewhere....anybody listening at
Unisys??......
btw, I have probably one of the smallest IX shops anywhere.....
Richard Steiner
>anybody listening at Unisys??
This is a rhetorical question, of course... :-(
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.
David W. Schroth
> Here in comp.sys.unisys, sot...@co.hinds.ms.us (sro) spake unto us, saying:
>
>
>>anybody listening at Unisys??
>
>
> This is a rhetorical question, of course... :-(
>
Of course, there's someone listening at Unisys. Besides myself, I
noticed Tom Sherren participating in this thread.
Neither of us can *do* anything within Unisys based on what we hear in
this forum.
Regards,
David W. Schroth
Tom Sherren
What a concept!
I don't know if it survived... However if it did, it is on a QIC tape
cartridge written in MUSS format by a very early funky SCSI tape drive that
may be incompatable with anything available today.
Tom Sherren
Unisys - Roseville, MN USA
Return address is bogus to avoid spam.
My real address looks like Thomas dot Sherren at unisys dot com
Richard Steiner
"David W. Schroth" <David....@unisys.com> spake unto us, saying:
>Richard Steiner wrote:
>> Here in comp.sys.unisys, sot...@co.hinds.ms.us (sro) spake unto us, saying:
>>
>>>anybody listening at Unisys??
>>
>> This is a rhetorical question, of course... :-(
>
>I don't think the question (or response) is phrased correctly.
True, and I must apologize for being imprecise.
It was the "Powers That Be" at Unisys that I was referring to, of course,
not folks like yourself and Tom (and the other interesting folks who pop
by here from time to time).
>Of course, there's someone listening at Unisys. Besides myself, I
>noticed Tom Sherren participating in this thread.
While my direct involvement with Unisys technology has been a wee bit
limited recently, I still appreciate the fact that some of you folks
are interested enough to continue to partitipate here.
Thank you. :-)
I wish more people from Unisys were, to be honest, since it might expose
them to ideas and information that they are otherwise sheltered from, but
it seems that very few people at any given company are interested in any
of the online forums.
I find that disappointing, especially given the hihg level of technical
and cultural cross-pollination that can occur in places like USENET...
>Neither of us can *do* anything within Unisys based on what we hear in
>this forum.
Not overtly or even directly, perhaps. Still, something constructive
might result from the discussions here in time.
Who knows, someone like you might become CEO someday. :-)
Richard Steiner
so...@no.spam.i.am (Tom Sherren) spake unto us, saying:
>In article <c5mu2f$o0f$1...@spies.com>, a...@spies.com (Al Kossow) wrote:
>
>>Is there any possiblity that the software has survived?
>>It would be an interesting software system to simulate
>>(along with 70's era Execs on 11xx's)
>
>What a concept!
>
>I don't know if it survived... However if it did, it is on a QIC tape
>cartridge written in MUSS format by a very early funky SCSI tape drive that
>may be incompatable with anything available today.
Given some of the folks I've seen in alt.folklore.computers and other
places, and given the nature of the hardware some of those folks tend
to collect, it would surprise me considerably if such a tape proved to
be completely unreadable.
Stephen Fuld
"David W. Schroth" <David....@unisys.com> wrote in message
news:c5orlj$1hai$1...@si05.rsvl.unisys.com...
> Richard Steiner wrote:
> > Here in comp.sys.unisys, sot...@co.hinds.ms.us (sro) spake unto us,
saying:
> >
> >
> >>anybody listening at Unisys??
> >
> >
> > This is a rhetorical question, of course... :-(
> >
> I don't think the question (or response) is phrased correctly.
>
> Of course, there's someone listening at Unisys. Besides myself, I
> noticed Tom Sherren participating in this thread.
So you and Tom are "The Power of 2"? :-)
Sorry, I couldn't resist.
Stephen Fuld
"sro" <sot...@co.hinds.ms.us> wrote in message
news:7244954c.04041...@posting.google.com...
I don't necessarily disagree. There would be benefits from doing such a
thing, and many of them would be the kinds of things you are talking about.
But there is also a cost (support etc.). I certainly don't know enough to
do the calculations, but in the past, Unisys has decided that is wasn't
worth it. I am not commenting on the correctness of that decision, as I
don't know enough to do so.
Marc Wilson
Fuld) wrote in <5TUec.16528$K_.4...@bgtnsc05-news.ops.worldnet.att.net>::
>
>"andrew williams" <andrew....@t-online.de> wrote in message
>news:995f2314.04041...@posting.google.com...
>> I was at a user-group conference back in the late 90's (at Strasbourg)
>> and someone asked one of the Unisys people at an open discussion if
>> there were plans to migrate IX machines to PC hardware in the same way
>> I understand the old Burroughs systems have been migrated.
>
>Sort of. The current low end of what was the A-Series are actually PC
>hardware with a program, provided by Unisys, that does the emulation. But
>it is only for the low end. While PC speeds have been increasing
>dramatically, the cost of the emulation is such that such a system can't
>compete in pure performance with dedicated hardware. Thus the high end of
>that line is still done with dedicated hardware.
>
>For the descendents of the 1100 series, the problem is somewhat worse. The
>emulation would be slower, due to the difficulty of supporting 35 bits, and
>partial words on 8 bit byte hardware, so it would only be performance
>competitive for very low end systems. But in the IX world, as contrasted
>with the A-series world, there never were any productized very low end
>systems. In fact, several projects at doing "desk side" 1100s were cancelled
>before productization. The thoughts back then were that it wouldn't make
>money. (I make no statement about the correctness of that thought.)
On the other hand, there *was* the MAPPER-10, which was pretty small if not
quite "desk-side".
>So Unisys would have to make a marketing decision that they have so far
>refused to do - that is, to market a low end IX series. Given that it was
>problematical back then, I really question its market viability now. The
>"small" 1100 sites are disappearing and there are virtually no new-name
>customers, who might be candidates for such a system. There is probably a
>small market for additional development or test systems for large existing
>customers, or even as a partition in a one of the new clustered X86 systems,
>but it isn't clear that this would be a market winner for Unisys, given the
>support costs and the inevitible reduced software revenue from such a
>system, and potential loss of a larger system sale.
I can see a number of possible uses. I develop code for MAPPER systems, on
a PC. I'd *love* to have a 2200-emulator, as there's no way I can ever
afford the money, the space or the time to get a real 2200. I can think of
at least one organisation that would buy serious multiples of 2200
emulators to give developers (or small groups of developers) their own
machines. I develop code on 2 machine with 2 x 2.8 GHz Xeons and 2GB of
RAM- even at "flit-like" speeds that would be tolerable, I suspect. The
ideal solution would be an image that could run under VMWare.
--
Marc Wilson
___________________________________________________________________
Cleopatra Consultants Limited - IT Consultants - CoolICE Partner - MAPPER Associate
Tel: (44/0) 845 665-3012 Fax: (44/0) 871 236-1531
Mail: in...@cleopatra.co.uk Web: http://www.cleopatra.co.uk
___________________________________________________________________
MAPPER User Group mailing list: send *SUBSCRIBE to M...@cleopatra.co.uk
Stephen Fuld
"Marc Wilson" <ma...@cleopatra.co.uk> wrote in message
news:1u7280dtdlvkeal9i...@4ax.com...
Yes, I mentioned that system, AKA System 11, AKA 2200/100 in a previous post
in this thread. One of the projects I was referring to (Orion?) was a true
desk-side system, about the size of PC server box.
> >So Unisys would have to make a marketing decision that they have so far
> >refused to do - that is, to market a low end IX series. Given that it
was
> >problematical back then, I really question its market viability now. The
> >"small" 1100 sites are disappearing and there are virtually no new-name
> >customers, who might be candidates for such a system. There is probably
a
> >small market for additional development or test systems for large
existing
> >customers, or even as a partition in a one of the new clustered X86
systems,
> >but it isn't clear that this would be a market winner for Unisys, given
the
> >support costs and the inevitible reduced software revenue from such a
> >system, and potential loss of a larger system sale.
>
> I can see a number of possible uses. I develop code for MAPPER systems, on
> a PC. I'd *love* to have a 2200-emulator, as there's no way I can ever
> afford the money, the space or the time to get a real 2200. I can think
of
> at least one organisation that would buy serious multiples of 2200
> emulators to give developers (or small groups of developers) their own
> machines. I develop code on 2 machine with 2 x 2.8 GHz Xeons and 2GB of
> RAM- even at "flit-like" speeds that would be tolerable, I suspect. The
> ideal solution would be an image that could run under VMWare.
Yes, good points. There is no doubt a market for such a product. The
question is whether the market size justifies the cost to Unisys. In the
past they have decidedd it doesn't.
Randall Bart
awe as "Stephen Fuld" <s.f...@PleaseRemove.att.net> uttered:
>I don't necessarily disagree. There would be benefits from doing such a
>thing, and many of them would be the kinds of things you are talking about.
>But there is also a cost (support etc.). I certainly don't know enough to
>do the calculations, but in the past, Unisys has decided that is wasn't
>worth it. I am not commenting on the correctness of that decision, as I
>don't know enough to do so.
The Burroughs/Sperry/Unisys Sales Prevention Department hasn't listened
to us techies for 40 years. They aren't going to start now.
--
RB |\ © Randall Bart
aa |/ ad...@RandallBart.spam.com Bart...@att.spam.net
nr |\ Please reply without spam I LOVE YOU 1-917-715-0831
dt ||\ Game with the words: http://multibabel.brainthru.com
a |/ Ghost town: http://Chernobyl.brainthru.com
l |\ DOT-HS-808-065 The Church Of The Unauthorized Truth:
l |/ MS^7=6/28/107 http://yg.cotut.com mailto:s...@cotut.com
Lewis Cole
> 'Twas Sat, 17 Apr 2004 06:12:16 GMT when all comp.sys.unisys stood in
> awe as "Stephen Fuld" <s.f...@PleaseRemove.att.net> uttered:
>
> >I don't necessarily disagree. There would be benefits from doing such a
> >thing, and many of them would be the kinds of things you are talking about.
> >But there is also a cost (support etc.). I certainly don't know enough to
> >do the calculations, but in the past, Unisys has decided that is wasn't
> >worth it. I am not commenting on the correctness of that decision, as I
> >don't know enough to do so.
>
> The Burroughs/Sperry/Unisys Sales Prevention Department hasn't listened
> to us techies for 40 years. They aren't going to start now.
Before this thread dies off completely or goes off much further
into small 1100/2200 system history and/or what Unisys should or
should not do, would anyone care to address the piddly point of
whether or not it's even possible anymore for anyone *OUTSIDE*
of Unisys to write a PC-based 2200 system simulator program
capable of simulating a relatively recent 2200 system
(say, for example, a 2200/500 or 2200/900)?
(Note that when I say, "2200 system simulator", I mean *SYSTEM*
simulator [i.e. something that's analogous to system mode FLIT]
and not an Exec8 simulator [i.e. something that's analogous to
program mode FLIT].)
I suspect the answer to this question might well be, "no", for
all practical purpose (at least not legally).
I say this because ever since the 1100/60, a critical part of
any 1100/2200 system is its system support processor (called
the System Control Facility [SCF] on 2200/500 and 2200/900
systems).
So far as I know, the only meaningful documentation concerning
the protocol between the support processor and the 2200 system
that's visible outside of Unisys is in the source code of the
OS1100/OS2200 operating system.
Now, I don't know what sort of agreement(s) exists between
Unisys and its customers, but since I recall that the words
"confidential" and "proprietary" were scattered through out
the OS source the last time I looked at it, it wouldn't
surprise me if there weren't one or more clauses in those
agreements (say, something along the lines of a "no reverse
engineering" clause and non-disclosure clause) which would
effectively prevent anyone outside of Unisys from coming up
with a legally "clean" functional description of the support
processor that could then be used in a non-Unisys written
2200 system simulation.
Am I missing something here?
Does anyone know of any documentation that anyone can now get
a hold of which documents at least those few Exec Link
Function (ELF) messages exchanged between the SCF and
2200/500 or 2200/900 systems which are actually needed to boot
and run such a system?
If no such documentation exists, does anyone know whether or not
there is a way for someone with access to the OS2200 source
and/or executable to provide a functional description of those
ELF's to someone who doesn't in such a way that it does not
violate (in either letter or in spirit) any legal agreement with
Unisys?
(For example, could someone boot up a 2200/500 or 2200/900 boot
tape on a system mode FLIT simulation with breakpoints set to
freeze things whenever an ELF message or ELF response received,
and then pass along what the messages and responses look like
to complete stranger without legal problems?)
Lueko Willms
schrieb l_c...@juno.com (Lewis Cole)
auf /COMP/SYS/UNISYS
in 817f0147.04041...@posting.google.com
ueber Re: Exec8 emulator
LC> Before this thread dies off completely or goes off much further
LC> into small 1100/2200 system history and/or what Unisys should or
LC> should not do, would anyone care to address the piddly point of
LC> whether or not it's even possible anymore for anyone *OUTSIDE*
LC> of Unisys to write a PC-based 2200 system simulator program
LC> capable of simulating a relatively recent 2200 system
LC> (say, for example, a 2200/500 or 2200/900)?
Technically, I'm very sure, this would be possible.
Others already mentioned that mapping a 36-bit-word and its 9-bit-
quarter-words on an 8- resp. 32-bit machine would not be very fast.
That aside, since the OS code was always distributed in source form,
it should be possible to emulate it, resp the hardware architecture
behind it.
But copyright stands against it.
And if it would not be for copyright issues, who would want to
develop it? Support it?
Would it be possible to sell the product and recover the development
costs by the proceeds?
If not, would enough people be prepared to do it for free?
Questions...
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
Schriftsteller, Politiker, Komödianten und andere öffentliche
Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
einer Notiz wert, so galt mir in solchen Fällen der Wahlspruch: à
corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
- Karl Marx 17.11.1860 (Herr Vogt, Kapitel XI)
Kurt Duncan
difference between program-mode and system-mode emulation.
The OS can be emulated along with the hardware. This gives us a
static-point emulator.
Drawbacks:
() It would have to be reworked every couple of EXEC releases to stay
current.
() Would probably never be functionally identical, and (due to complexity)
doubtful it would be functionally complete. Much much coding. Think
facilities. Yuck.
() Not good for training OS support personnel (no SYSGEN or anything of the
like)
Benefits:
() Speed - since it runs native on x86 (or whatever), I suspect it'll be an
order of magnitude faster than the alternative.
The hardware can be emulated, based on one selected platform the OS
recognizes, then the Exec and all supporting software is loaded and run on
the emulator.
Drawbacks:
() Difficulty of truly emulating all the characteristics of the selected
hardware subsystem. Previous threads have mentioned SCF - communicating
with the SSP.
() Suppose U-inc. decides to legally prevent using OS2200 on any hardware
not sold by them? It's a license agreement - they can do it.
Benefits:
() True emulation of virtually every aspect of the OS environment; no need
to rewrite software, it's already written.
() No need to rewrite the emulator for each successive Exec release, at
least until the emulated hardware goes unsupported.
Is it possible to do the emulation? I don't know. The environment emulator
would be easier, but more time-consuming, I think. The hardware emulator
would require access to all EXEC source code, and preferably a full set of
current release tapes. That pesky copyright and license agreement keeps
getting in the way. Maybe if U-Inc. sold a renewable $100/year (or
whatever) license to all software purely for developmental purposes... but
from their point of view, why would they do that?
If such a beast existed, it would certainly drive down the TCO for a
2200-class mainframe. It might keep the line in existence longer. It would
also make it possible (although perhaps not any more likely) for more
third-party developers to enter to 2200 world. Perhaps any that are still
there, might be able to stay in business longer, though. Even U-Inc.
development would be more cost-effective.
Lewis Cole
> Am 18.04.04
> schrieb l_c...@juno.com (Lewis Cole)
> auf /COMP/SYS/UNISYS
> in 817f0147.04041...@posting.google.com
> ueber Re: Exec8 emulator
>
> LC> Before this thread dies off completely or goes off much further
> LC> into small 1100/2200 system history and/or what Unisys should or
> LC> should not do, would anyone care to address the piddly point of
> LC> whether or not it's even possible anymore for anyone *OUTSIDE*
> LC> of Unisys to write a PC-based 2200 system simulator program
> LC> capable of simulating a relatively recent 2200 system
> LC> (say, for example, a 2200/500 or 2200/900)?
>
> Technically, I'm very sure, this would be possible.
>
Technically, I agree.
But as I tried to point out in much of the remainder of my
original posting, legally, I'm not so sure.
And "legally", if you can't get there from here, "technically"
doesn't matter.
>
> Others already mentioned that mapping a 36-bit-word and its 9-bit-
> quarter-words on an 8- resp. 32-bit machine would not be very fast.
>
It's a piddly point, but I believe what "others"
(specifically Stephen Fuld) mentioned is that an x86
simulation/emulation of a processor is (1) not as fast as a
real hardware processor and (2) is not as fast as a
software simulation/emulation that doesn't have to
compensate for differences between the native processor
word width and word make up and the native word width and
word make up of the simulated processor.
This is not the same as saying that an x86 simulation of a
2200 IP won't be very fast because of the difference in the
word width and word make up between the x86 and a simulated
2200 IP as your statement seems to suggest.
It only takes about four 386 assembly language instructions
to extract any field from a 36-bit 2200 word.
Inserting any field into a 36-bit 2200 word takes about the
same.
(Of course, the x86 instruction count goes up dramatically if
you need to synchronize access to a 2200 word between multiple
threads that can get at the word.)
This is only a small fraction of the total number of x86
instructions that must be executed to simulate a 2200 IP.
There are actually several things that make it difficult
to efficiently simulate a 2200 IP on an x86 CPU, but if I
had to choose one, it would be that the x86 doesn't have
enough general purpose registers.
As a result, it looks like a lot of register shuffling is
necessary just to save things out of the way.
A 64-bit host word does every little to change this.
If that's the case, you may ask why is it that the
Unisys-written 2200 system simulator is rumored to have only
run about as fast as FLIT when it was run many moons ago?
I don't know, but I have some suspicions, not the least of
which is based on the fact that it was written in a high
level language.
It's not just that assembly is faster, it's that a high
level language implies the use of a runtime library that
likely has a fixation with making calls on the host OS.
That's just about the best way I can think of to kill off
the performance of any user program.
My own back-of-the-envelope scratchings suggest that it
should be possible to execute one simple 2200 instruction
by executing around 200 to 500 real x86 instructions.
This isn't pretty, but since I recall seeing a benchmark
that showed a 500MHz PIII was capable of 1500 MIPs, it
suggests a best case performance of about 3 million 2200
instructions per second on such an x86 host.
Of course, when you factor in a "typical" 2200 instruction
mix, the overhead of executing other parts of the
simulator and other user programs, and the huge overhead
of the host OS, I'd be surprised if it were possible to
get any where near one tenth of that figure.
However, using one of today's 2+ GHz x86's, that works out
to better than one 2200 MIP which, if I recall correctly,
is faster than a system mode FLIT simulation of a 2200/900
system on a 2200/900.
To me, that's not very "fast" at all, but it might be
"fast enough" to be tolerable (although just barely).
> That aside, since the OS code was always distributed in source form,
> it should be possible to emulate it, resp the hardware architecture
> behind it.
>
> But copyright stands against it.
>
Actually, I believe that the OS code is (or was) at times
distributed in executable form only.
Perhaps my memory is playing tricks on me, but I think that
this was the case with certain 1100/50 systems
(AKA "Mapper 10"/"System 11").
Be that as it may, I don't believe that copyright stands
stands against anything here.
I'm not a lawyer and so what I say should obviously be
taken with a very large grain of salt, but consider what
happened with the original IBM PC and AT ROM BIOS's.
I'd be surprised if the source for these ROM BIOS's
weren't copyrighted by IBM.
That didn't prevent Phoenix Technologies from coming up with
a "100% compatible" version that was also 100% legal.
Phoenix managed this trick by having a group of "virgin"
engineers who'd never seen the IBM BIOS write up their own
version based on a functional description of what was in
the IBM ROM BIOS derived by a group of "contaminated"
Phoenix engineers who had studied it.
This same trick should be possible with the ELF interface
*PROVIDED* that something else doesn't stand in the way.
That's why I mentioned a "no reverse" engineering clause
and a non-disclosure as possible (even probable?)
obstacles in my original posting.
> And if it would not be for copyright issues, who would want to
> develop it? Support it?
>
> Would it be possible to sell the product and recover the development
> costs by the proceeds?
>
> If not, would enough people be prepared to do it for free?
>
> Questions...
>
It seems to me that these questions are irrelevent if it's not
legally possible for someone outside of Unisys to write a
reasonably functional 2200 system simulator in the first place.
(Why would *ANYONE* waste their time to cook up the parts of a
2200 system simulator they can if they can't cook up the one
part of the simulator they need to make the whole thing work?)
But since you raised these questions anyway, let me wave my
arms at them by raising three points.
First, if you look at things from the same prospective as
Unisys, you'll probably reach the same conclusion as Unisys.
Therefore, if you look at whether or not a 2200 system
simulator should be written from the prospective of how
much money you can make from doing so, then I think it's
probably safe to say that no one outside of Unisys will
ever write one.
Fortunately, there are odd balls among us who try to write
things with little (if any) concern at the time for how
much money they might eventually make.
It seems to me that this is important because it virtually
guarantees that, from time to time, folks outside of Unisys
will try to write a 2200 system simulator and, provided
that it's possible to do so, one of them will eventually
complete it as well.
Second, it seems to me that things change the instance a
freely (or *EXTREMELY* cheaply) 2200 system simulator
becomes readily available, even if it's in an extremely
crude form to begin with (just so long as it shows up
some time *Real Soon Now*).
Presumably, only hardcore 2200 techweenies would be
interested in such a thing initially, but if it works
reasonably well and is bearably fast, then it seems to
me that the target audience/market would likely grow to
include those who might have a passing interested in
some of the applications you can run on a 2200.
If that's the case, then the answers to the questions
you've asked likely won't be the same ones you'll get if
you ask them again after a working system simulator has
been running around for a while.
Finally, my crystal ball is no better (and may well be
worse) than everyone elses on this topic, but it seems to
me that the best predictor of what could happen with a
2200 system simulator is probably what has happened with
other system simulators.
I don't know of that many, but so far as I can tell, the
Hercules system simulator which simulates IBM
System/370, ESA/390, and z/Architectures systems seems
to be alive and well.
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
>
<snip>
P.S. My apologizes to the readers of this news group for
the length of this tome.
Lewis Cole
> A point has been made, somewhere buried in this thread, regarding the
> difference between program-mode and system-mode emulation.
>
<difference description snipped>
>
> Is it possible to do the emulation? I don't know. ...
Well, in the case of a 2200/900 system simulator (what you
call a "hardware emulator"), I think I do know.
If it's possible to come up with a legal, functional
description of those few Exec Link Function (ELF) messages
and responses that are needed to boot and run a real
2200/900, then it's possible to write a functional 2200/900
system simulator using that description and other existing
generally available documentation.
If it's not possible to come up with such a description,
then it's not possible to write a functional 2200/900
system simulator.
It's that simple.
This is not to say that writing such a simulator would be
easy or quick or that it might not be extremely desirable
to "tune" the simulator using information obtained using
FLIT.
(By "tune", I mean derive reasonable values from a FLIT
simulation to replace those that would/could be used
just to get the simulator running.
For example, since I haven't run across anything that
gives the quantum timer ticks or instruction cycle
counts for each 2200 instruction, it would make sense to
me to come up with them via FLIT.
Obviously, it would nice to have access to a 2200.)
(Note that since I've never been interested in the gory
details of how bits get from a channel to a terminal, I've
never looked into whether or not there's enough detail in
available documentation to figure out how to simulate a
DCP.
Obviously, if there isn't, then any 2200 software that
can't be run from the operator console could well be a
problem.)
Beyond that (i.e. beyond the 2200/900), I don't know.
I do know that the 2200/XPA Processor and Storage manual
(excuse me, make that the 2200/XPA Processor PRM), no
longer describes the IOP (at least, not in the last
version of the manual that I've seen.)
Obviously, if that trend continues in future 2200 systems,
then it won't be possible to simulate 2200 systems due to
a lack of sufficient information needed to write a
critical part of the simulator.
As for whether it's possible to write an Exec8 simulator
(what you call an "environment emulator"), I neither know
nor care.
> ... The environment emulator
> would be easier, but more time-consuming, I think.
I don't know what would make you think this, but since
have no interest in such a thing, I won't comment
further other than to say that I don't see why it
shouldn't be easier and less time consuming to write
a working 2200 system simulator than an Exec8
simulator.
It seems to me that there's less stuff (hardware) to
be concerned with simulating and what there is is
more completely described.
> ... The hardware emulator
> would require access to all EXEC source code, and preferably a full set of
> current release tapes. ...
A 2200 system simulator would require access to exactly
the same stuff that a real 2200 system would require.
Therefore, if you're at a 2200 site, you presumably
already have "access" to that which you need to boot and
run a 2200 system simulator.
(That's assuming, of course, legal requirements don't
get in the way and that you can pry whatever you need out
of your SA's hands).
> ... That pesky copyright and license agreement keeps
> getting in the way. Maybe if U-Inc. sold a renewable $100/year (or
> whatever) license to all software purely for developmental purposes... but
> from their point of view, why would they do that?
>
As I noted in my last posting to Lueko Willms, I
don't believe that Unisys's copyrights to its
source or anything else get in the way at all.
Does anyone have a specific scenario they can toss
out which would illustrate why they think Unisys's
copyrights would be a problem?
<remainder of posting snipped>
Marc Wilson
wrote in <c60m32$2oh$1...@news.lsil.com>::
>
>The hardware can be emulated, based on one selected platform the OS
>recognizes, then the Exec and all supporting software is loaded and run on
>the emulator.
>Drawbacks:
>() Difficulty of truly emulating all the characteristics of the selected
>hardware subsystem. Previous threads have mentioned SCF - communicating
>with the SSP.
>() Suppose U-inc. decides to legally prevent using OS2200 on any hardware
>not sold by them? It's a license agreement - they can do it.
If I could get a 2200-emulator for a sensible amount of money, I'd we
willing to buy a Unisys-badged server to run it on. Or even a laptop: I
wouldn't be looking for blazing speed, just functional equivalence. If I
can show that the code runs, I can sort out benchmarks etc at a later date.
In general, efficient MAPPER code is efficient MAPPER code; if it's fast on
the PC, it should be fast on the 2200, apart from some well-know
platform-specific issues.
Marc Wilson
wrote in <c60m32$2oh$1...@news.lsil.com>::
>Is it possible to do the emulation? I don't know. The environment emulator
>would be easier, but more time-consuming, I think. The hardware emulator
>would require access to all EXEC source code, and preferably a full set of
>current release tapes. That pesky copyright and license agreement keeps
>getting in the way. Maybe if U-Inc. sold a renewable $100/year (or
>whatever) license to all software purely for developmental purposes... but
>from their point of view, why would they do that?
Well, Microsoft do it, in various versions (MSDN, Technet, Direct Access)-
it seems to be worthwhile for them.
Marc Wilson
<817f0147.04041...@posting.google.com>::
>Actually, I believe that the OS code is (or was) at times
>distributed in executable form only.
>Perhaps my memory is playing tricks on me, but I think that
>this was the case with certain 1100/50 systems
>(AKA "Mapper 10"/"System 11").
IIRC, some "low end" machines were Absolute Only releases, at the higher
end you had a choice. Sites I've worked at always went for Symbolic
releases, so that local code and more rapid bug fixes were possible.
>Be that as it may, I don't believe that copyright stands
>stands against anything here.
>I'm not a lawyer and so what I say should obviously be
>taken with a very large grain of salt, but consider what
>happened with the original IBM PC and AT ROM BIOS's.
>I'd be surprised if the source for these ROM BIOS's
>weren't copyrighted by IBM.
>That didn't prevent Phoenix Technologies from coming up with
>a "100% compatible" version that was also 100% legal.
>Phoenix managed this trick by having a group of "virgin"
>engineers who'd never seen the IBM BIOS write up their own
>version based on a functional description of what was in
>the IBM ROM BIOS derived by a group of "contaminated"
>Phoenix engineers who had studied it.
IANAL either, but:
There will almost certainly be a provision against reverse engineering in
any contract you sign with Unisys. I suspect that the state of the art in
contract law has moved along also, and perhaps Phoenix would not get away
with the same manoeuvre if done today. This would almost certainly have to
be done with at least approval from Unisys, if not active co-operation.
Marc Wilson
<817f0147.04041...@posting.google.com>::
>(Note that since I've never been interested in the gory
>details of how bits get from a channel to a terminal, I've
>never looked into whether or not there's enough detail in
>available documentation to figure out how to simulate a
>DCP.
You could restrict it to simulating an HLA instead- much simpler, as it
only needs to deal with TCP/IP.
David W. Schroth
A number of us here in Roseville are delighted to see Mr. Bootstrap
surfacing in this newsgroup...
> "Kurt Duncan" <kurt....@lsil.com> wrote in message news:<c60m32$2oh$1...@news.lsil.com>...
>
>>A point has been made, somewhere buried in this thread, regarding the
>>difference between program-mode and system-mode emulation.
>>
>
>
> <difference description snipped>
>
>>Is it possible to do the emulation? I don't know. ...
>
>
> Well, in the case of a 2200/900 system simulator (what you
> call a "hardware emulator"), I think I do know.
> If it's possible to come up with a legal, functional
> description of those few Exec Link Function (ELF) messages
> and responses that are needed to boot and run a real
> 2200/900, then it's possible to write a functional 2200/900
> system simulator using that description and other existing
> generally available documentation.
> If it's not possible to come up with such a description,
> then it's not possible to write a functional 2200/900
> system simulator.
> It's that simple.
Hey. We in the Exec don't have a particularly accurate description of
ELFs and their functionality, why should an emulator writer get such an
advantage? :-)
>
> This is not to say that writing such a simulator would be
> easy or quick or that it might not be extremely desirable
> to "tune" the simulator using information obtained using
> FLIT.
> (By "tune", I mean derive reasonable values from a FLIT
> simulation to replace those that would/could be used
> just to get the simulator running.
> For example, since I haven't run across anything that
> gives the quantum timer ticks or instruction cycle
> counts for each 2200 instruction, it would make sense to
> me to come up with them via FLIT.
Or you could do what FLIT does, and plug in (un)reasonably arbitrary
values as needed....
> Obviously, it would nice to have access to a 2200.)
Should I see if we could get a salesman to visit you? :-)
>
> (Note that since I've never been interested in the gory
> details of how bits get from a channel to a terminal, I've
> never looked into whether or not there's enough detail in
> available documentation to figure out how to simulate a
> DCP.
> Obviously, if there isn't, then any 2200 software that
> can't be run from the operator console could well be a
> problem.)
Emulating a DCP, while doable, doesn't seem particularly worthwhile.
Emulating an NIOP seems like a better deal to me.
>
> Beyond that (i.e. beyond the 2200/900), I don't know.
> I do know that the 2200/XPA Processor and Storage manual
> (excuse me, make that the 2200/XPA Processor PRM), no
> longer describes the IOP (at least, not in the last
> version of the manual that I've seen.)
> Obviously, if that trend continues in future 2200 systems,
> then it won't be possible to simulate 2200 systems due to
> a lack of sufficient information needed to write a
> critical part of the simulator.
Sounds like a documentation UCF is in order...
>
> As for whether it's possible to write an Exec8 simulator
> (what you call an "environment emulator"), I neither know
> nor care.
>
Clearly it's possible, we have an existence proof (name of FLIT). It
strikes me as rather more work for rather less accurate results. Doing
it on another platform is probably considerably more difficult than
doing it on a 2200 - a number of highly used 2200 features (think
symbionts) don't map particularly well to Wintel or *nix.
>
>> ... The environment emulator
>>would be easier, but more time-consuming, I think.
>
>
> I don't know what would make you think this, but since
> have no interest in such a thing, I won't comment
> further other than to say that I don't see why it
> shouldn't be easier and less time consuming to write
> a working 2200 system simulator than an Exec8
> simulator.
> It seems to me that there's less stuff (hardware) to
> be concerned with simulating and what there is is
> more completely described.
>
I think Lewie nailed this one.
>
<snip>
Regards,
David W. Schroth
Kurt Duncan
"Lewis Cole" <l_c...@juno.com> wrote in message
news:817f0147.04041...@posting.google.com...
<snip>
> further other than to say that I don't see why it
> shouldn't be easier and less time consuming to write
> a working 2200 system simulator than an Exec8
> simulator.
> It seems to me that there's less stuff (hardware) to
> be concerned with simulating and what there is is
> more completely described.
>
After further review, the officials on the field agree with one Mr. Lewis
Cole. I should have said, "easier for me, given the access I have to
anything resembling specifications"
> A 2200 system simulator would require access to exactly
> the same stuff that a real 2200 system would require.
>
I can do most of the work for the exec emulator using nothing but the online
documentation. I'm basically doing what the Phoenix BIOS engineers did -
taking funtional specs and re-engineering from scratch. This doesn't
require access to source code or internal hardware docs. I may be wrong,
but I cannot imagine being able to write a hardware emulator that I can boot
an existing Exec with, without the Exec source code in hand.
> Does anyone have a specific scenario they can toss
> out which would illustrate why they think Unisys's
> copyrights would be a problem?
>
Licenses: Being somewhat removed from anything resembling a true 2200
system, I have no access to release tapes, source code, anything. Licensing
(or rather, my lack of one) prevents me from obtaining information that
would be critical to developing the hardware emulator. If I had the tapes
on 9-track, at the very least I could scan them into my PC, unwrap the
copy,g and program file formats and peruse the symbolic elements. (Eons
later, the first code emerges, but that's a separate issue).
Copyrights: Also, a good hardware manual to explain all those bizarre
hardware op-codes - what they mean, and what behavior is expected from
them - would be essential. For me, anyway. AFAIK, no such manuals are
available online; and copyright certainly prevents me from obtaining copies
of anything that might be laying about.
Stephen Fuld
news:<978CA...@jpberlin-l.willms.jpberlin.de>...
snip
> > Others already mentioned that mapping a 36-bit-word and its 9-bit-
> > quarter-words on an 8- resp. 32-bit machine would not be very fast.
> >
>
> It's a piddly point, but I believe what "others"
> (specifically Stephen Fuld) mentioned is that an x86
> simulation/emulation of a processor is (1) not as fast as a
> real hardware processor and (2) is not as fast as a
> software simulation/emulation that doesn't have to
> compensate for differences between the native processor
> word width and word make up and the native word width and
> word make up of the simulated processor.
> This is not the same as saying that an x86 simulation of a
> 2200 IP won't be very fast because of the difference in the
> word width and word make up between the x86 and a simulated
> 2200 IP as your statement seems to suggest.
That is exactly right. I never made any representations about absolute
speed. I did make a "relative" comparison, noting that having to emulate
the 36 bit word stuff would make an 1100 series emulator slower than an
emulator for a byte oriented system, specifically, the A-Series. This is to
differentiate a potential 1100 series emulator from the A series emulator
which is a standard Unisys offering, having replaced the low end A-series
dedicated hardware solutions.
Stephen Fuld
>
> "Lewis Cole" <l_c...@juno.com> wrote in message
> news:817f0147.04041...@posting.google.com...
> <snip>
> > further other than to say that I don't see why it
> > shouldn't be easier and less time consuming to write
> > a working 2200 system simulator than an Exec8
> > simulator.
> > It seems to me that there's less stuff (hardware) to
> > be concerned with simulating and what there is is
> > more completely described.
> >
>
> After further review, the officials on the field agree with one Mr. Lewis
> Cole.
Let me chime in with a minority opinion. Remember, it is not just a CPU/IOP
emulator that you would need to have something useful. You would need some
peripherals such as disks and tapes in order to even boot, much less use the
system. Now would you want to attach "real" Unisys peripherals to the
system on which your emulator is running ? That means doing a fair amount
of hardware integration, probably some low level work, perhaps even a
hardware design for some kind of adaptor, not to mention a potentially
rather nasty piece of code to get the commands that your emulator outputs to
the actual hardware through whatever adaptor you have. Don't want to go
through that? Then you have to emulate the peripherals as well.
Essentially, you have to take the commands that your emulator puts out and
"convert" them into something that the hardware you have understands. While
I am not saying that either of these is impossible, the work involved
mitigates against the task of emulating the Exec. While the Exec emulation
might be more code to write, it is probably much simpler code. So, at least
to me, it isn't clear which is easier, even given all the documentation.
> I should have said, "easier for me, given the access I have to
> anything resembling specifications"
>
> > A 2200 system simulator would require access to exactly
> > the same stuff that a real 2200 system would require.
> >
>
> I can do most of the work for the exec emulator using nothing but the
online
> documentation. I'm basically doing what the Phoenix BIOS engineers did -
> taking funtional specs and re-engineering from scratch.
In fact, historically, that is what the people who wrote the first Exec 8
did! They first developed the user documentation (essentially UP 4144) then
wrote the code to implement what was documented. (This is from a
presentation on Univac history given at the 25th year anneversery of USE by
John McGowan)
>This doesn't
> require access to source code or internal hardware docs. I may be wrong,
> but I cannot imagine being able to write a hardware emulator that I can
boot
> an existing Exec with, without the Exec source code in hand.
>
> > Does anyone have a specific scenario they can toss
> > out which would illustrate why they think Unisys's
> > copyrights would be a problem?
> >
>
> Licenses: Being somewhat removed from anything resembling a true 2200
> system, I have no access to release tapes, source code, anything.
Licensing
> (or rather, my lack of one) prevents me from obtaining information that
> would be critical to developing the hardware emulator. If I had the tapes
> on 9-track, at the very least I could scan them into my PC, unwrap the
> copy,g and program file formats and peruse the symbolic elements. (Eons
> later, the first code emerges, but that's a separate issue).
Yes, the EON code would be first, followed by the TON code! If you "get"
this, you probably should retire! :-)
Keith Stone
> > It seems to me that there's less stuff (hardware) to
> > be concerned with simulating and what there is is
> > more completely described.
> >
>
> I think Lewie nailed this one.
>
> >
> <snip>
> Regards,
>
> David W. Schroth
I agree. In the Wintel and Mac world there exists a fine hardware
emulation of a pentium chip set that by operating at the hardware
emulation level allows you to load multiple OS's, as opposed to
emulating at the OS level, which would still require some instruction
set intepretation.
If you did a hardware emulation of the 2200 you could load TOPS! ;-)
In any case I'd like one, but not likely at the price Unisys would
ask. It would be nice if they'd allow an open source implementation,
but they've not been too friendly to open source (or any kind of
source) for a while.
I'm debating writting something to read the program files I have in
punch card format and extract things. By the sime I parse the program
file TOC that's Fieldata characters, converted to ASCII, which neeeds
to be converted back to a 36 bit word (then of course figuring the
appropriate sector offset) it might be easier to write something I
could run FURPUR on.
Keith Stone
Winston Salem, NC
David W. Schroth
> "Lewis Cole" <l_c...@juno.com> wrote in message
> news:817f0147.04041...@posting.google.com...
> <snip>
>
>>further other than to say that I don't see why it
>>shouldn't be easier and less time consuming to write
>>a working 2200 system simulator than an Exec8
>>simulator.
>>It seems to me that there's less stuff (hardware) to
>>be concerned with simulating and what there is is
>>more completely described.
>>
>
>
> After further review, the officials on the field agree with one Mr. Lewis
> Cole. I should have said, "easier for me, given the access I have to
> anything resembling specifications"
>
>
>>A 2200 system simulator would require access to exactly
>>the same stuff that a real 2200 system would require.
>>
>
>
> I can do most of the work for the exec emulator using nothing but the online
> documentation. I'm basically doing what the Phoenix BIOS engineers did -
> taking funtional specs and re-engineering from scratch. This doesn't
> require access to source code or internal hardware docs. I may be wrong,
> but I cannot imagine being able to write a hardware emulator that I can boot
> an existing Exec with, without the Exec source code in hand.
>
I'm going to disagree with you here. The available documentation for
the architecture and instruction set is sufficient, IMO, to allow one to
write a hardware emulator that one could boot an existing Exec with.
I cannot say the same about the documentation for the Exec and the Exec
APIs. It's better (much, much better) than it was in the good old days,
but it's till not sufficient.
<snip>
>
>
> Licenses: Being somewhat removed from anything resembling a true 2200
> system, I have no access to release tapes, source code, anything. Licensing
> (or rather, my lack of one) prevents me from obtaining information that
> would be critical to developing the hardware emulator. If I had the tapes
> on 9-track, at the very least I could scan them into my PC, unwrap the
> copy,g and program file formats and peruse the symbolic elements. (Eons
> later, the first code emerges, but that's a separate issue).
>
> Copyrights: Also, a good hardware manual to explain all those bizarre
> hardware op-codes - what they mean, and what behavior is expected from
> them - would be essential. For me, anyway. AFAIK, no such manuals are
> available online; and copyright certainly prevents me from obtaining copies
> of anything that might be laying about.
>
I'm sure such manuals exist. I'm also sure they're devilishly hard to
find. I've helped others find them in the past, so I know it can be
done. Maybe Lewie remembers the name and number of the appropriate
manual...
Regards,
David W. Schroth
Marc Wilson
>Let me chime in with a minority opinion. Remember, it is not just a CPU/IOP
>emulator that you would need to have something useful. You would need some
>peripherals such as disks and tapes in order to even boot, much less use the
>system. Now would you want to attach "real" Unisys peripherals to the
>system on which your emulator is running ? That means doing a fair amount
>of hardware integration, probably some low level work, perhaps even a
>hardware design for some kind of adaptor, not to mention a potentially
>rather nasty piece of code to get the commands that your emulator outputs to
>the actual hardware through whatever adaptor you have. Don't want to go
>through that? Then you have to emulate the peripherals as well.
Well, we know it's possible, because the 2200 does it the other way round:
it uses what are basically arrays of PC disks to emulate something with a
28-word sector structure.
Al Kossow
>>emulator that you would need to have something useful. You would need some
>>peripherals such as disks and tapes in order to even boot, much less use the
>>system. Now would you want to attach "real" Unisys peripherals to the
>>system on which your emulator is running ?
I would suggest looking at what Bob Supnik has done with his SIMH
simulator.
I am interested in Burroughs/Univac system simulation from the aspect
of historical preservation, which is why I was talking about simulation
of 1108's and 1106's.
Stephen Fuld
> In comp.sys.unisys, "Stephen Fuld" <s.f...@PleaseRemove.att.net> (Stephen
> Fuld) wrote in
<Yuchc.9058$um3.2...@bgtnsc04-news.ops.worldnet.att.net>::
>
> >Let me chime in with a minority opinion. Remember, it is not just a
CPU/IOP
> >emulator that you would need to have something useful. You would need
some
> >peripherals such as disks and tapes in order to even boot, much less use
the
> >system. Now would you want to attach "real" Unisys peripherals to the
> >system on which your emulator is running ? That means doing a fair
amount
> >of hardware integration, probably some low level work, perhaps even a
> >hardware design for some kind of adaptor, not to mention a potentially
> >rather nasty piece of code to get the commands that your emulator outputs
to
> >the actual hardware through whatever adaptor you have. Don't want to go
> >through that? Then you have to emulate the peripherals as well.
>
> Well, we know it's possible, because the 2200 does it the other way round:
> it uses what are basically arrays of PC disks to emulate something with a
> 28-word sector structure.
I never said it was impossible, just a lot of work. Remember, we were
comparing the amount of work needed for a 2200 series hardware emulator with
a 2200 OS emulator. Everyone else seemed to think that building just the
hardware simulator would be easier, but I am not so sure, especially when
you have to add the work of emulating the peripherals.
Mike
personnel) lost credibility when Sperry discontinued Orion. Instead of
Orion, DEC equipment was used.
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote in message
news:02dgc.41836$K_.9...@bgtnsc05-news.ops.worldnet.att.net...
Mike
eCommunity http://ecommunity.unisys.com, and add your comments. -- As I'm
sure everyone knows, you must register :-( .
Once you log in, click on:
<> "Ask our experts"
<> and then "ClearPath IX"
<> and finally "magellen" It is currently message number 87 (9:25 CDST on
4/20/2004). There is very little activity so it will likely be message
number 87 for a long time.
Who knows what's possible if there is enough demand.
cheers,
Mike
"Marc Wilson" <ma...@cleopatra.co.uk> wrote in message
news:gr0a80do4f34docko...@4ax.com...
Keith Stone
> I never said it was impossible, just a lot of work. Remember, we were
> comparing the amount of work needed for a 2200 series hardware emulator with
> a 2200 OS emulator. Everyone else seemed to think that building just the
> hardware simulator would be easier, but I am not so sure, especially when
> you have to add the work of emulating the peripherals.
If memory serves, I remember a company whose name originated from an
inability to consistently spell "peripheral", so I understand a
concern about emulating one. ;-)
I don't think anyone's talking about trying to hook up a drum, so from
a storage standpoint I think you could emulate disk devices using
storage containers the same way Virtual PC does it. Tapes would
certainly be trickier. You wouldn't need to emulate a DCP (or god
forbid a GCS), simply translate the calls from CMS (yes you'd need
some com handler running) to a LAN controller, the same way Virtual PC
translates the calls to a simulated LAN card, then ships out the
packets using the existing LAN environment.
Emulating a modern 2200 should be easier than something like a
1106/1108 (or for excitement a 1100/40) because many of the
peripherals in use are the same (at the hardware level) as you'd have
in a common midrange box.
At the hardware level you have the instruction set, channels, etc. If
the OS level you have hundreds of API's to emulate, services to
provide, etc. I think there's a significantly greater level of effort
emulating the OS.
Lewis Cole
Actually, as far as I can tell, simulation of a disk or tape
subsystem (i.e the peripherals needed to boot a 2200 system
simulator) doesn't appear to be all that difficult to do.
In fact, if you treat the simulated devices (or more
specifically, their media) as host OS files in basically the
same sort of way that system mode FLIT does, if you
successfully warp your mind into viewing peripheral
controllers (especially SCSI ones) as just another simulated
command interpreter that just happens to work on those files,
if you judiciously restrict your I/O configuration to be
made up of a lot of IOP's that each have a single SCSI
channel with a single SCSI CU with a single SCSI device (so
as to avoid dealing with multiple I/O paths), if you accept
as a given that OS2200 will load correct SCDT's in all those
IOP's (so that the IOP simulations can safely ignore the
SCSI channel types recorded in those SCDT's which are not
documented in the 2200/900 IP PRM), if you are willing to
let the SCSI disk CU's to use a 509 byte disk record length
instead of its usual 512 byte disk record length (so that
it doesn't matter that the IOP's record pad/strip feature
is mentioned in the 2200/900 IP PRM, but never described),
if you constantly remind yourself that while a 2200/900
doesn't support SCSI channels or peripherals, but a 2200/500
does and is otherwise virtually identical, then I might even
be willing to go so far as to say that simulating a disk or
tape subsystem looks to be pretty straight forward. ;-)
I know that there's no particular reason why anyone should
believe me when I say things like this.
I haven't actually written a working 2200 system simulator
which I can trot out to prove to everyone that what I say
is relatively accurate.
Nevertheless, it just so happens that I've been chewing
over how to make a 2200/900 system a simulator for several
years now, starting sometime before Mr. Duncan announced
in this newsgroup back in August of 2000 that he was
working on OS1100 ["environment"] emulator in his spare time.
So, when I say things like it would be possible for someone
outside of Unisys to write a functional 2200/900 system
simulator if only a functional description of the ELF
messages and responses needed to boot a real 2200/900 were
legally available, I really do mean it in a way that is not
as theoretically based as you might be assuming.
As for how much work is to to implement a system simulator
compared to an Exec8 simulator, I don't know.
To get a feel for that, perhaps Mr. Duncan will wave his
arms at how is "environment emulator" is coming along.
Mr. Duncan?
Lewis Cole
>
> A number of us here in Roseville are delighted to see Mr. Bootstrap
> surfacing in this newsgroup...
>
Thanks Mr. Schroth.
It's nice to know that I still have some entertainment
value out that way. ;-)
It's also nice to know that you've managed to beat off the
alligators long enough to make your own appearance in this
newsgroup as well.
And later that same day, he also wrote:
> >
> > Copyrights: Also, a good hardware manual to explain all those bizarre
> > hardware op-codes - what they mean, and what behavior is expected from
> > them - would be essential. For me, anyway. AFAIK, no such manuals are
> > available online; and copyright certainly prevents me from obtaining copies
> > of anything that might be laying about.
> >
>
> I'm sure such manuals exist. I'm also sure they're devilishly hard to
> find. I've helped others find them in the past, so I know it can be
> done. Maybe Lewie remembers the name and number of the appropriate
> manual...
>
I'm not quite sure what "bizarre hardware op-codes"
Mr. Duncan is interested in.
Surely, he can't be referring to 2200 instructions. ;-)
If that somehow does happen to be the case, well, the
last 2200 IP PRM that I know of is the 2200/XPA IP PRM
(7833 4083-001).
Before that was Volume 2 ("Instruction Repertoire") of
the 2200/900 System Processors PRM (7833 0669-000).
As it turns out, when I tried to order that one some
years back, I was told that it was not available.
That's why I was very happy when a certain individual
in Roseville was kind enough to give me the XPA PRM.
It's been some years now since I've tried to order a
manual from Unisys, but they used to be willing to
sell manuals to individuals, just so long as the
manual wasn't something they considered restricted in
some way.
All I had to do was browse around the Unisys Web site
(or the Unisys Bookstore Web site) until I found
something interesting, and then call up Unisys and
give them the part number and my credit card number.
David W. Schroth
> If you are truely interested in an Intel based emulation of OS 2200, look in
> eCommunity http://ecommunity.unisys.com, and add your comments. -- As I'm
> sure everyone knows, you must register :-( .
>
> Once you log in, click on:
> <> "Ask our experts"
> <> and then "ClearPath IX"
> <> and finally "magellen" It is currently message number 87 (9:25 CDST on
> 4/20/2004). There is very little activity so it will likely be message
> number 87 for a long time.
>
> Who knows what's possible if there is enough demand.
>
> cheers,
> Mike
>
I'll note that at least one set of experts (numbering at least one, but
possibly higher) does not participate in the ecommunity forums.
Largely because the managers of the forum seem unwilling to support
people who prefer using software other than the "approved" software to
access the forums.
YMMV.
Regards,
David W. Schroth
BTW, I don't know how they spell it in the forums, but we spell it
Magellan here.
Stephen Fuld
----- Original Message -----
From: "David W. Schroth" <David....@unisys.com>
Newsgroups: comp.sys.unisys
Sent: Wednesday, April 21, 2004 7:00 AM
Subject: Re: Exec8 emulator
snip
> BTW, I don't know how they spell it in the forums, but we spell it
> Magellan here.
For those of us who don't participate in that forum, can you give a brief
description of Magellan, its features, development status and any official
Unisys marketing plans. Nothing confidential of course.
David W. Schroth
> ----- Original Message -----
> From: "David W. Schroth" <David....@unisys.com>
> Newsgroups: comp.sys.unisys
> Sent: Wednesday, April 21, 2004 7:00 AM
> Subject: Re: Exec8 emulator
>
>
> snip
>
>
>>BTW, I don't know how they spell it in the forums, but we spell it
>>Magellan here.
>
>
> For those of us who don't participate in that forum, can you give a brief
> description of Magellan, its features, development status and any official
> Unisys marketing plans. Nothing confidential of course.
>
Chuck Stevens
> I don't know, but I have some suspicions, not the least of
> which is based on the fact that it was written in a high
> level language.
> It's not just that assembly is faster, it's that a high
> level language implies the use of a runtime library that
> likely has a fixation with making calls on the host OS.
>
> That's just about the best way I can think of to kill off
> the performance of any user program.
I'm not at all convinced that it's a general characteristic of higher-level
languages regardless of environment, although it may be true for some
platforms (perhaps including the 2200).
On the MCP-based systems, comparison with assembly is meaningless because
there is no assembler to begin with. I've been told that back in the Dark
Ages the engineers building the B5000 found that the ALGOL compiler they
wrote in ALGOL produced considerably *faster* object code than the ALGOL
cross-compiler they wrote in assembler initially to compile it (this in the
days when they were still simulating the B5000 hardware on a Philco 2000,
before the first one had been built). As soon as they had successfully
triple-compiled that ALGOL compiler, there was no longer a need for the
assembler version.
Although some of the languages on the MCP-based systems do make occasional
calls to runtime libraries, such calls by no means represent the core
functions of the language on those systems, for which the compilers generate
object code directly. When the need arises to talk to the operating
system, the generated object code calls the operating system. For the
"critical path" processes associated with the language, the compilers
generate executable object code.
-Chuck Stevens
Stephen Fuld
> Stephen Fuld wrote:
snip
> > For those of us who don't participate in that forum, can you give a
brief
> > description of Magellan, its features, development status and any
official
> > Unisys marketing plans. Nothing confidential of course.
> >
> I don't participate in the forum, so I can't speak to what's there.
I'm sorry, I confused you. I meant can you tell us information (only that
which is publically available) about Magellan?
David W. Schroth
> "David W. Schroth" <David....@unisys.com> wrote in message
> news:c66fgv$1eh5$1...@si05.rsvl.unisys.com...
>
>>Stephen Fuld wrote:
>
>
> snip
>
>
>>>For those of us who don't participate in that forum, can you give a
>
> brief
>
>>>description of Magellan, its features, development status and any
>
> official
>
>>>Unisys marketing plans. Nothing confidential of course.
>>>
>>
>>I don't participate in the forum, so I can't speak to what's there.
>
>
> I'm sorry, I confused you. I meant can you tell us information (only that
> which is publically available) about Magellan?
>
I don't know what information is publically available about Magellan.
Dan Nissen
the public at http://public.support.unisys.com/support.htm. This includes a
whole bunch that contain the work ELF. I don't know if they are complete
enough descriptions to build an emulator.
Dan Nissen
"Lewis Cole" <l_c...@juno.com> wrote in message
news:817f0147.04041...@posting.google.com...
David W. Schroth
I have to say that I believe simulation of an 1108 (if you can simulate
an 1108, you've simulated an 1106) would be *much* more difficult than
simulation of one of the later models. I'm not aware of any definitve
documentation of the instructions specific to the 1108 that were dropped
in later models.
And while I can lay my hands on Exec sources going back to 38R5, I
wouldn't begin to know where to look for level 33 or level 35 sources.
Al Kossow
>>
> I have to say that I believe simulation of an 1108 (if you can simulate
> an 1108, you've simulated an 1106) would be *much* more difficult than
> simulation of one of the later models. I'm not aware of any definitve
> documentation of the instructions specific to the 1108 that were dropped
> in later models.
>
> And while I can lay my hands on Exec sources going back to 38R5, I
> wouldn't begin to know where to look for level 33 or level 35 sources.
>
Sigh... John Dobnick at the UW-Milw had them as recently as a few
years ago in a tape rack in his office the last time I visited him
before he died. When I asked what had happened to the contents of
his office, it had all been thrown away.
This discovery is one of the things that had prompted me the past few
years to intensify my efforts to try to find as much of the software
from the mid-70's and earlier that still exists. While a LOT of DEC,
CDC, and IBM software survives, I have not heard of much from either
Burroughs or Univac that has been survived.
Stephen Fuld
> Al Kossow wrote:
>
> >>>Let me chime in with a minority opinion. Remember, it is not just a
CPU/IOP
> >>>emulator that you would need to have something useful. You would need
some
> >>>peripherals such as disks and tapes in order to even boot, much less
use the
> >>>system. Now would you want to attach "real" Unisys peripherals to the
> >>>system on which your emulator is running ?
> >
> >
> > I would suggest looking at what Bob Supnik has done with his SIMH
> > simulator.
> >
> > I am interested in Burroughs/Univac system simulation from the aspect
> > of historical preservation, which is why I was talking about simulation
> > of 1108's and 1106's.
> >
> >
> I have to say that I believe simulation of an 1108 (if you can simulate
> an 1108, you've simulated an 1106)
But you have to run the simulator on a system with half speed memory. :-)
> would be *much* more difficult than
> simulation of one of the later models. I'm not aware of any definitve
> documentation of the instructions specific to the 1108 that were dropped
> in later models.
The 1108 Processor and Storage Reference Manual. I have one packed up
somewere. It told you pretty much everything you had to know. And there
would be fewer instructions to simulate! :-)
Al Kossow
>
> The 1108 Processor and Storage Reference Manual. I have one packed up
> somewere. It told you pretty much everything you had to know. And there
> would be fewer instructions to simulate! :-)
A scan can be found at:
www.bitsavers.org/pdf/univac/1100/UP-4053r1_1108prog.pdf
Mike
why I was surprised to see "Magellen" (sic) as the subject of a question on
eCommunity.
The question was:
"The LX140 laptop looks great for the MCP people. When will the IX/2200 side
(i.e. the red-headed stepchildren of Unisys) see a similar product?"
The response was:
"At this time Marketing have no plans to release an OS 2200 version of the
MCP LX140." (sic)
Cheers,
Mike
"David W. Schroth" <David....@unisys.com> wrote in message
news:c68j50$2ra6$1...@si05.rsvl.unisys.com...
Rob Singers
words of wisdom
> Largely because the managers of the forum seem unwilling to support
> people who prefer using software other than the "approved" software to
> access the forums.
I'm curious, by this do you mean a browser other than IE? If so it's
probably because IE accounts for ~99% of the traffic that hits Unisys
external sites. That said Mozilla and Opera are becoming the credible
competitor that Netscape never was and that situation may change.
--
rob singers
pull finger to reply
Kurt Duncan
trail out quite so soon...
I've been piddling around with emulating the OS in my spare spare time. If
I had software release tapes to play with, I'd piddle around emulating the
hardware instead. What is, is.
Right now, all I really want to do is (using an x86 machine) sign on to
DEMAND mode, write a quick TIP program, assemble it, start a TIP session,
and run the program. At the rate I'm going, this'll probably be done about
the time I retire...
However, I would certainly be inclined to spend more time and energy on the
project if I thought it had some legs... or a loose coalition of people
designing/writing, whatever...
Exactly what is the level of interest out here?
And does anybody have an electronic copy of the PCT structures guide (the
one that never gets distributed because it changes so often)?
David W. Schroth
<snip>
>
> And does anybody have an electronic copy of the PCT structures guide (the
> one that never gets distributed because it changes so often)?
>
>
A quibble - the PCT structures don't actually change that often.
Stephen Fuld
> This has certainly been an interesting discussion, and I hope it doesn't
> trail out quite so soon...
snip
> And does anybody have an electronic copy of the PCT structures guide (the
> one that never gets distributed because it changes so often)?
Why do you care? Except for ER PCT$ and equivalent bank basing techniques,
which presumably don't use anything exotic in the PCT, it is invisible to a
user program. Even if you are building an Exec 8 emulator, you needent
emulate the internal structure, only the user program visible parts.
andrew williams
The last time the PCT was officially documented was with CP IX 6.1,
but I am pretty certain that some of the tables were documented
incorrectly.
The way to go is apparently to look at the appropriate MASM procs /
DCL elements in the Exec sources. That at least is what Unisys
replied when I raised a contact on the issue. I have done it recently
and found (using an old manual for field-names and then IACULL) the
appropriate tables very well documented.
Kurt Duncan
>
> Why do you care? Except for ER PCT$ and equivalent bank basing
techniques,
> which presumably don't use anything exotic in the PCT, it is invisible to
a
> user program. Even if you are building an Exec 8 emulator, you needent
> emulate the internal structure, only the user program visible parts.
>
True enough, except I myself wrote several programs, usually the ones which
did a CONECT call, which used ER PCT$ or else based the PCT bank, in order
to find some useful info which wasn't available any other way (e.g.,
commonbanks which need to know if they're in TIP or DEMAND mode). Lacking
this info, I'll use my own internal data structs, but I'll do so in a manner
easily convertible to actual PCT structure. Most likely I'll have a shadow
PCT - that is, all ER's that request PCT info will generate an appropriate
conversion; all accesses the a based PCT bank will do the same (it'll be
slower, but such access isn't likely to make up a large portion of
processing load).
David Schroth quibbled about them not really changing that much - yep. But
the potential for change, was cited (at least to me) as the reason why the
documentation wasn't widely available - they didn't want to document
something for the customers, then be locked into it. Same reason the
internal data structures guide wasn't orderable for a looonng time. (It is
now, and has been for, well, forever).
Andrew Williams suggests looking at the MASM procs. Andrew Williams stops
short of offering them so that I /could/ look at them. :-)
Stephen Fuld
> "Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote in message
> news:Vmeic.28746$um3.5...@bgtnsc04-news.ops.worldnet.att.net...
> >
> > Why do you care? Except for ER PCT$ and equivalent bank basing
> techniques,
> > which presumably don't use anything exotic in the PCT, it is invisible
to
> a
> > user program. Even if you are building an Exec 8 emulator, you needent
> > emulate the internal structure, only the user program visible parts.
> >
>
> True enough, except I myself wrote several programs, usually the ones
which
> did a CONECT call, which used ER PCT$ or else based the PCT bank, in order
> to find some useful info which wasn't available any other way (e.g.,
> commonbanks which need to know if they're in TIP or DEMAND mode). Lacking
> this info, I'll use my own internal data structs, but I'll do so in a
manner
> easily convertible to actual PCT structure. Most likely I'll have a
shadow
> PCT - that is, all ER's that request PCT info will generate an appropriate
> conversion; all accesses the a based PCT bank will do the same (it'll be
> slower, but such access isn't likely to make up a large portion of
> processing load).
That is certainly what I would do.
Keith Landry
Kurt Duncan
Once you've established a form of translation, you master the CD's according
to that translation.
I don't know how 2200 software is released today. When I used to work with
2200 systems, they sent us release tapes. A release tape has a particular
format, involving multiple files in a particular order on the release tape.
One of these files contains a catalog of the remaining files on the tape,
including the software titles and revisions.
In order to be useful, a 2200 emulator (including a laptop system) would
need to read, write, and generally live in the world of 2200 files. It
would also need a very good system for importing and exporting files from a
real 2200 system. Finally, there would need to be a method of presenting
released software as a set of 2200 files, even if the media were CDR.
Because of that requirement, there would need to be an emulation overlay
that would allow a CDR to be "seen" as a virtual tape. I suppose you could
set it up as a removable disk pack, but I've always been more comfortable
doing software installs from tape than from disk.
There are a number of possible variations on this; since you specifically
mentioned a laptop, I suppose it's unlikely that the software would be
installed directly from tape; but then again, not impossible.
To others:
What media is Unisys using for 2200 release tapes these days?
"Keith Landry" <kla...@charter.net> wrote in message MCP systems support
Lewis Cole
> MCP systems support CD/CD-RW drives. MCP system software is distributed
> on CD. How would an OS2200 laptop get its software?
>
If by "an OS2200 laptop" you mean a 2200 system simulator
program running on a laptop (assuming that the laptop was
powerful enough to do so in the first place), I assume
that the copy of OS2200 running on the simulator would
get its software in the "obvious" way, namely the same
way that OS2200 got into the system simulator in the
first place ... from a simulated tape (mounted on a
simulated tape drive of the simulated 2200 system) that
in reality just happened to be one or more files in the
file system of the OS that's actually running on the
laptop (i.e. the host OS).
These files could be on just about any medium that is
supported by the host OS ... the laptop's hard disk, a
hard disk that the laptop has access to via a network,
a CD or DVD, even removable media like a floppy or Zip
disk or flash card if the simulated tape on the medium
were small enough.
As for how the simulated tape would get into such files,
I assume that the "obvious" way would also apply in this
case as well, namely through the use of one or more
utility programs possibly splattered across several
different platforms.
For example, one scenario would be to use the @TTF
("Tape To Fastrand") processor on a real 2200 system
to convert the contents of a real live tape into a
mass storage file on a real 2200 system.
Somehow, a miracle would occur which would result in
bits from this file being downloaded into a mass
storage file on a PC.
A program on the PC would then fondle the contents of
this file so that it would look like a simulated tape
as far as the 2200 system simulator program is
concerned.
This file or set of files would then be put onto what
ever medium you wanted to use for distribution to the
2200 laptops of the world.
When the time comes to install the new 2200 software
on the simulated 2200 system, you would do the
simulated equivalent of what you would do if you were
installing the software from a real tape on a real
2200 system.
It's just that when the time comes to mount a real
tape, you'd tell the 2200 simulator to use the host
file(s) containing the bits of the simulated tape.
If by "an OS2200 laptop" you mean an Exec8 simulator
program running on a laptop, well, your guess is as
good as (if not probably better than) mine.
My best guess, though, is that since the system
software you'd want to update is part of the Exec8
simulator program itself, then whatever updates
you'd want to install would again hopefully be in
form of some files in the file system of the host
OS (e.g. new DLL's).
Stephen Fuld
snip
> I have to say that I believe simulation of an 1108 (if you can simulate
> an 1108, you've simulated an 1106) would be *much* more difficult than
> simulation of one of the later models. I'm not aware of any definitve
> documentation of the instructions specific to the 1108 that were dropped
> in later models.
OK, so now that you can get the documentation on line (and I can tell you it
is much simpler hardware to emulate as it did so much less - all of the
dropped instructions were privlidged ones, most were I/O and doing I/O on
the 1108 was much simpler than setting up complex CCW lists, worrying about
different channel types, etc.) that problem is resolved.
> And while I can lay my hands on Exec sources going back to 38R5, I
> wouldn't begin to know where to look for level 33 or level 35 sources.
Wan't some late version of Exec level 37 the last to support the 1108? Can
you gat access that far back?
If so, you are "good to go"! :-)
Edward Reid
> But there is also a cost (support etc.). I certainly don't know enough to
> do the calculations, but in the past, Unisys has decided that is wasn't
> worth it.
From an MCP point of view ...
The LX100 line -- the laptop MCP, of which the LX140 is the latest --
comes with no support. The last I heard, you could not even buy
support on an hourly basis. There was talk at UNITE about possibly
making some provision for paid hourly support, but I don't know if
anything came of it. In essence, Unisys realized that the support cost
would drown the system and just didn't do it.
Dollars were thrown around somewhere. IIRC, the current software
license cost for an LX100 is $3,000. That's a one time fee, and
there's no upgrade path -- when you need to upgrade, you buy a new
laptop and a new software license. OTOH, you can run that old one as
long as you want, for only the cost of the electricity for a laptop.
You have to buy the laptop from a limited list of high end boxes, so
you're looking at about eight grand for the whole system. A lot of
developers only need this every 2-3 years, so it's not bad at all as a
cost of doing business.
A development license includes all the MCP software. Obviously it *is*
a development license; you're not allowed to use it for production
work. But it's a great marketing device, since it allows the techies
on site to try out the goodies that the managers haven't been
persuaded to buy. There's also a license for a demo system -- don't
recall the cost -- with fewer goodies, in particular no compilers,
intended mostly I think for people marketing third party software who
need a system to demo it on.
While it seems agreed that a 2200-CPU emulator would be considerably
slower than an MCP-CPU emulator, it's worth pointing out that the
LX100 systems are quite fast. A system relatively half or a quarter as
fast would still be extremely useful to developers. Heck, a tenth as
fast would probably be useful. A three-year-old LX100 is a lot faster
than the B6700 I used back in 1972, and on that B6700 my compiles had
to compete with production work. So I don't buy the argument that
Unisys hasn't come out with an emulated 2200 system because it would
be too slow; they must have other reasons.
On whether to emulate purely the hardware or a soft/hard combination:
there's an interesting history to look at in Wintel emulators running
under the Mac OS. First there was Soft PC, which emulated the x86 for
user program code and emulated the most critical parts of DOS by
custom 680x0 code. The followon was the similarly designed
SoftWindows. But then Virtual PC came out and mostly swamped the other
products. Virtual PC did a better job of hardware emulation (probably
because it focussed on only that), was simpler and more reliable
because it didn't depend on knowing anything about the internals of
Windows, and it was OS-agnostic -- ran DOS or Windows or OS/2 or
Linux, anything that ran on Intel-type hardware. Today, Virtual PC is
generally the only product you hear about in that arena.
Edward Reid
Tom Herbertson
...
> On whether to emulate purely the hardware or a soft/hard combination:
> there's an interesting history to look at in Wintel emulators running
> under the Mac OS. First there was Soft PC, which emulated the x86 for
> user program code and emulated the most critical parts of DOS by
> custom 680x0 code. The followon was the similarly designed
> SoftWindows. But then Virtual PC came out and mostly swamped the other
> products. Virtual PC did a better job of hardware emulation (probably
> because it focussed on only that), was simpler and more reliable
> because it didn't depend on knowing anything about the internals of
> Windows, and it was OS-agnostic -- ran DOS or Windows or OS/2 or
> Linux, anything that ran on Intel-type hardware. Today, Virtual PC is
> generally the only product you hear about in that arena.
And the company which produced it, Connectix, has been acquired by
Microsoft, who are reportably busy preparing a new version which will
run on the G5 processor, which lacks psuedo-little-endian mode, upon
which the current version relies. (A motto which could be found in the
animation in the about box of a previous Connectix version was "Endian
Little Hate We.")
--
Tom Herbertson
Unisys (Net2: 656 6427) Mail Stop 320, Mission Viejo CA 92691-2792 USA
Voice: +1 949 380 6427 mailto:tom.her...@unisys.com (office)
FAX: +1 949 380 6560 or mailto:herbe...@cox.net (home)
- My opinions are my own; I do not speak for Unisys or anyone else -
Andy Mountford
>
>From an MCP point of view ...
>
>The LX100 line -- the laptop MCP, of which the LX140 is the latest --
>comes with no support. The last I heard, you could not even buy
>support on an hourly basis. There was talk at UNITE about possibly
>making some provision for paid hourly support, but I don't know if
>anything came of it. In essence, Unisys realized that the support cost
>would drown the system and just didn't do it.
>
<snip>
>
I don't know how rigorously this policy is pursued in the US but, in
the UK, we would *far* rather you reported a fatal COMS error (say) on
your LX100 than on your N million-dollar production 8 X CS580! Should
it turn out to be LX100 specific then it probably won't get fixed but
a bona fide COMS bug would be fixed with our grateful thanks for
reporting it.
Of course, what frightens Unisys is the prospect of problem reports
such as "I was comparing the emulation on my LX100 with the way my
NX5800 used to work and..." or "My LX100 is running slowly" or "My
LX100 has just hung" etc.
Regards,
Andy
mdarnell
packrat and have manuals all the way back to Exec II.
"Dan Nissen" <dan.n...@unisys.com> wrote in message news:<c690vu$3f2$1...@si05.rsvl.unisys.com>...