OPENMPE Archives

March 2003

OPENMPE@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Alan Tibbetts <[log in to unmask]>
Reply To:
Alan Tibbetts <[log in to unmask]>
Date:
Mon, 3 Mar 2003 19:03:34 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
Gavin Scott wrote:
> Yes, exactly, but...  The "150-odd PA-RISC instructions" are the easy
> part, requiring comparatively little development effort.  It's not quite
> a "weekend project" but the instruction set is well specified, nicely
> modular (you only have to worry about one instruction at a time), etc.
>
> The parts that are *hard* are the rest of the hardware system visible to
> software.  This means parts of the system chipset, each I/O interface,
> and the actual peripherals attached to those interfaces.
>
> These devices such as the SCSI interface, the LAN interface, and so
> forth, are each as complicated in their own right as the PA-RISC
> instruction set, and for the most part there's no documentation
> available that tells you what you need to know to simulate them.
>
> So a PA-RISC emulator is easy.  An HPe3000 complete hardware emulator is
> much, much more difficult.

Gavin is sooo correct.  For the Kestrel (HP1000 work-alike computer)
that Strobe Data produces, it took less time to design the CPU
hardware, write the instruction set firmware, design the legacy
backplane cards and do the PC board layouts, design the sheetmetal for
the chassis, and build the first working unit than it did to write the
emulation of the system console interface and the CS-80 interface.

The book "PA-RISC 2.0 Architecture" by Gerry Kane is about 550 pages
long and describes the instruction set very well.  It presents the
details of the memory addressing, fault handling, and privilege
management, plus a good bit of other stuff.  The total information
that it presents about the I/O system is four paragraphs *in the
overview*!  A distillation of the information in those four paragraphs
is:  I/O is memory mapped, it can use DMA, and it can cause interrupts.

With that level of documentation, it might be possible to produce a
working MPE emulation sometime around the year 3000.

Obviously, now that there is a reasonable expectation of being able to
obtain a license to execute MPE on an emulator, anyone thinking of
producing one must move on to obtaining the details of the I/O system
that will be needed to communicate with the real-world.  A "compute
only" emulation makes a great computer science senior project, but
isn't likely to meet the needs of anyone in OpenMPE.

--
Alan Tibbetts           Strobe Data, Inc.
Project Manager         8405 165th Ave. NE
425 861 4940            Redmond WA
[log in to unmask]      98052-3913

ATOM RSS1 RSS2