CBM's Plans for the RISC-Chipset By:  Dave Haynie

#33630 comp.sys.amiga.misc 8k
From: dave.haynie@scala.com (Dave Haynie)
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.hardware
Subject: Re: CBM4s Plans for the RISC-Chipset
Date: Tue, 24 Jan 1995 23:21:15 GMT
Organization: Scala Inc., US Research & Development

In <3f0c67$nfh@news.tuwien.ac.at>, e9226006@stud1.tuwien.ac.at (Nenad
Steric) writes:
>Just found this article in c.s.a.advocacy and thought it would interest
someone here too.
>Following the original article : ...

>Here are the highlights of an interview of Chris Ludwig, an ex-member of
>CBM's engineering staff, at the World of Amiga exposition, printed in
>the french mag "Amiga News" January 1995.

>AN: Who decided the choice of the CPU [HP-PA]: the developement team
>or CBM?
>
>CL: It was CBM's decision. We spent a lot of time choosing the best
>CPU for our needs. Our decision was based on these factors:
>compatibilty with existing HP products because they've bought
>Apollo (graphic stations manufactured) and compatibilty with 68000
>(there is a 68000 emulation mode in the PA-RISC).

Wrong.  The HP-PA was chosen for use in The RISC Project (Hombre) primarily
based on the needs of that project.  HP-PA code is reasonably dense for a
RISC processor, the instruction set is easily extensible, the core is small
enough to sit on a chip occupied by other functional units (blitter,
copper, system control), etc.  There is no "68000 emulation mode" in
PA-RISC, the Apollos Commodore had were 680x0 based and not an issue
anyway.

>AN: Is this emulation hardware ?
>
>CL: Both. In a lot of cases, the instructions' architecture is
>similar to the 68000 and there are also software emulation tricks,
>so that makes the porting easier.

HP-PA offers the same feature that makes porting from 680x0 to SPARC or
PowerPC easier -- big endian word ordering.  That's it.  We had some
concern and the early stages of a future plan for use of the Hombre chipset
in high-end Amigas (based on my "Acutiator" system architecture), but that
would initially be as a graphics card, not a host CPU.  The first target
for Hombre would be a next-generation CD32 replacement with no software
compatibility.

>AN: So it will be quite easy to create a portable AmigaDOS for
>HP-RISC?

>CL: Exactly.

Nope.  Lots of the AmigaOS was in assembly, and would have to be rewritten.
There's a good chance data alignment issues would be an additional problem,
even on C code, though Apple solved some of this by building in special
compiler options for alignment control.

>It was one of the main reasons for the choice of HP's CPU.

Not even in the top 10 as far as the reasons for the choice.

>CL: We already got software emulation of the four parts of the chipset,
>they are working well so we're quite happy.
>AN: Will these four chips be a single chip later ?

The design called for two chips.  The PA-RISC core, blitter, copper, etc.
live in a "system control" chip, roughly analogous to Agnus/Alice/Andrea,
at least in a rough sense.  The other was the actual video display chip,
the same basic idea as Denise/Lisa/Monica.  Neither design was finished;
more work was done on the former, but it's a much larger chip.  And there
was basically one guy working on it, Ed Hepler.  Tim MacDonald (AAA Monica
designer) worked on the display chip for awhile, before he left C= and went
to work on display chips for Compaq.

>CL: Of course, it will, but we don't need extraordinary backup, at least
>not much more than what we needed in the past.  We can certainly do it
>in 18 months with reasonable backup.

The initial schedule of 18 months was for the Hombre game machine hardware.
There's no real OS here, just a library of routines, including a 3D
package, which would probably be licensed.  The Amiga OS was not to have
run on this system in any form.  An AmigaOS port to RISC for "Amiga" RISC
machines was something those of us in the high-end group were certainly in
favor of, but it was not at the time under consideration by management.  Of
course, at that time, Commodore was going down fast, so there no money for
any of that stuff.

>AN: Windows NT will running on it.
>CL: Yes, Windows NT works on PA-RISC and we won't do anything to prevent
>it (WinNT) from working on our system.

Supposedly an NT port is underway for PA-RISC, but not yet released.  Even
at that, there's no reference platform for building binary compatible
systems.  Clearly this could be solved by the HAL (Hardware Abstraction
Layer) that NT talks to on all machines, kind of a higher-level BIOS.  Yet
despite the clear logic of that approach, the short sighted weenies who
seem to control the system architectures (if you can call them that) of the
Next Generation Personal Computers don't seem to have advanced much beyond
the 1970s when it comes to these areas.  Look no further than the PReP
nonsense for a good example; Apple and IBM have spent years arguing about
hardware trivialities that shouldn't be anything a "shinkwrapped OS" should
ever have to be directly concerned about.  Maybe NT did better, but maybe
not.

Even if you had NT, what would you really have?  My guess is a slower way
to run Windows 3.1 programs than you current get on cheap PClones.  Native
NT applications are rare.  Native NT applications that support MIPS and
Alpha platforms, which have been shipping for quite some time, are rarer
still.  Rarer even still are applications compiled for PowerPC, since only
Motorola is pushing that.  Microsoft could have gone to a CPU-neutral
distribution format, but again, why do something the right way, only the
users benefit.  And they're not to be trusted.

>It will be a system running three OS (including HP's own OS).

We never intended to run HP-UX, and at least at the time, HP was very
nervous about direct competition (which is why the PA-RISC isn't available
off the shelf like SPARC, MIPS, PowerPC, etc.).  It would have been
impossible to legally run it.

>AN: Mr Amor of CEI told on Portal last day that he wasn't quite sure on
>the choice of the RISC chip.  He said Macs and PCs are heading to the
>PPC,

That's a valid concern for "computer-level" machines, such as what most
people think of as a RISC-Amiga (eg, any RISC machine running a native port
of the AmigaOS).  It's a non-issue with games machines, there aren't two
machines out there with compatible CPUs, and the CPU is the least of your
worries, since every graphics subsystems is even more different from one
another than the host CPU.  Again, PA-RISC was the choice of what's best
for the Hombre chipset and probably a games machine or low-cost, high
performance smart 3D graphics subsystem (Hombre will be both if it's ever
built).

>[...] In short: It's important for them to have a cheap chipset version
>for multimedia stuff, video games ...  Some of the old screenmodes will
>be present and new ones should be impressive

Hombre doesn't support any of the existing modes.  It does support 16 and
24-bit true color displays, I don't know if there's a LUT mode or not.  The
main emphasis is on 16-bit direct color.  You could have four 16-bit
playfields active at once, and there were blitter mathematics (something
like in AAA, only better) that could operate very efficiently on 16-bit
pixels.

>heard and seen from Sega's Saturn specs, it should not even come close to
>the new Amiga Chipset specs,

Strictly speaking, Hombre is not an Amiga chip set.  While it supports some
of the Amiga ideas, it's no more Amiga compatible than an SVGA chip (less,
actually, since all SVGA chips support planar as well as chunky displays,
at least up to 4 bits/pixel).  This shouldn't be a big deal anyway, the
planned Retargetable Graphics system for AmigaOS 4.0 was to support chunky
pixels, though much more work was needed for that, especially to handle
direct mapped color.

Dave Haynie          | ex-Commodore Engineering |  See my first film
Sr. Systems Engineer |      Class of '94        | "The Deathbed Vigil"
Scala Inc., US R&D   | C= Failure n. See: Greed |     info@iam.com

 "Caught a bolt of lightning, cursed the day he let it go" -Pearl Jam
 

...And, Mr. Haynie's response to my request for reprint permission was
also illuminating:

#20 jcompton 4k
From: Dave Haynie                      <dave.haynie@scala.com>
Subject: Reprint right request, sir.
Date: Wed, 25 Jan 95 11:17:52 EST
Reply-To: Dave Haynie                  <dave.haynie@scala.com>

Yeah, sure.  I guess you should mention that in both cases, we're acting on
whatever information we have on the Hombre project.  This was kept pretty
hush-hush, not only because it was The Secret Project, but since Ed Hepler
was for the first two years or so the only guy working on it, he didn't
necessarily have lots of design review meetings.  My only direct
involvement with the project was simply ensuring Ed knew about my
requirements for Hombre to be used as a PCI card, which was in the specs
last I saw them.  I certainly haven't seen anything about the project since
June, but I do know what was said about it last Spring.  The only software
work at the time was Dr.  Alan Havemose's investigation of 3D libraries; no
plans were underway for any kind of AmigaOS port at the time.

Many issues hadn't been resolved by the time I left.  It was assumed that
most of the "generic peripheral" type things would hang off the PCI bus,
though few should be necessary for a games machine.  They hadn't decided on
the audio subsystem; there was at one time talk about adopting the 8
channel subsystem from Mary (AAA), but there was also talk about using an
off-the-shelf sound chip or cheap DSP.

Should Hombre ever see the light of day, there's certainly the possibility
that more traditional Amiga features could be incorporated, especially if
AAA is not also resurrected (keep in mind that during most of the life of
the Hombre project, it was assumed that AAA would exist and it would be
much too expensive for games machines or very low end personal computers).
It's possible that a port of the Amiga OS could be done, but it would be
lots of work, even if they could get together enough Amiga programmers to
get the thing going intelligently.  And of course the emulation technology
has been around for awhile.  A 680x0 is not that hard to emulate,
especially since applications under the AmigaOS run in user mode, so no
supervisor instructions (all the MMU codes, for instance) need be emulated.
And emulation should be much faster than under the Mac, since library calls
are all indirected jumps, not A-line traps.
BACK