RTX-2000 processor PC/AT add-in card (any takers?)

Chuck Guzis cclist at sydex.com
Mon Apr 10 19:45:38 CDT 2017

On 04/10/2017 04:47 PM, Jecel Assumpcao Jr. via cctalk wrote:

> The 64KB segments in the 8086 were not a problem for Pascal (or
> Smalltalk, as shown by the Xerox PARC Notetaker computer) because each
> heap object and each proceedure can live in a different segment to take
> advantage of the whole memory. A single object (like an array) can't be
> split into multiple segments which limits us to small objects (this is
> not a problem for Smalltalk which can completely hide such splits as
> shown in the Mushroom computer).

Oh, heck, I pointed out the problems with segment-offset addressing
before the 8086 was released on silicon to Intel applications engineers.
   They didn't seem to think it was a big deal.  I even asked for an
"add to far" instruction that would get rid of the nasty bit
manipulation, but to no  avail.

But for tiny, small and compact memory models, the 8086 is just fine.

Speculatively, I don't think that the 8086 was initially considered as a
minicomputer-type processor, but more of an extension of the x80
architecture to serve the embedded world.   No privileged mode, strange
segment/offset addressing, etc.  I suspect that at some point, Intel had
its big-system hopes pinned on the iA432 chipset.

The fiction of automatic translation from 8080/85 code was just that.  I
recall that "Fast Eddie", our local sales rep made the mistake of
telling a tall one that Intel's assembly-language translator produced
smaller code that ran faster than the x80 version.  I called him on it
and gave him a sample program that ran under ISIS-II and told him to do
his best.  It was a floating-point package, with test data.   Straight
code; no fancy macros.   I probably still have the original code somewhere.

So, we went down to the local sales office in Santa Clara where there
was an MDS all set up, complete with hard drive and the 80-to-86
translator.  I cautioned the sales engineer that the code did a lot of
tricky stuff with flags, so any translation would have to be very accurate.

The program went in (it was about 10 AM) and the MDS just ground and
ground...  12:30 came around and we were treated to lunch while the
translator worked on the miserable 3000 lines of 8080 assembly.  Back
from lunch, nothing...   By 5 PM, we had gotten nowhere, so we said our
goodbyes and told him to contact us when they finally got it to work.

Two weeks passed and Fast Eddie called to say that they had finally got
the translation done (after some tweaking of the translator).  The
result was that the translated code was nearly twice as large as the x80
code and, while the program executed, it gave the wrong answers (we
didn't tell them what the answers should be as part of the test).

I was advocating the very new Motorola 68K chip and had even produced a
(wirewrap) prototype CPU board that ran enough code to get to the "Hello
world" stage.  Unfortunately, Bill Davidow was on our BOD and he said in
no uncertain terms that it would be a cold day in Hell if one of the
companies he shepherded used a competitor's CPU.   So we eventually
wound up using the 80186, and added a spot for the 80286 on the CPU board.

We got it all working, but it was a long slog because we were using
prerelease silicon and a bug could stop us dead for two weeks or more
while we awaited the next stepping.


More information about the cctech mailing list