Questions on the days finds

From: Philip.Belben_at_pgen.com <(Philip.Belben_at_pgen.com)>
Date: Sun Feb 14 22:55:31 1999

>> Yes but what's interesting is that the bit-slice 4052 is software
>> compatible with the 6800 powered 4051!!! The 4052 is a 16 bit machine.
I'm
>> guessing that Tektronix used the bit slice CPU so that they could retain
>> the same software but gain the power of the 16 bit system.
>
> From what I recall (looking at Philip's 4052 service docs), the
> instruction set is not identical. There's at least one 6800 instruction
> missing on the 4052. And there are (of course) some extra instructions on
> the 4052 that aren't on the 6800. That's why some ROMs are 4052 and later
> only.

IIRC, the only 6800 instruction not present on the 4052/54/52A/54A was DAA
- decimal addition adjustment. Since the 6800 has no decimal subtraction
adjustment, it was pretty useless anyway.

The main difference is the 128K byte address space. Two bits in the
processor status register were used for the 17th address bit (most
significant) - one for instruction fetches (default 1) and one for data
load/store (default 0). Most of the additional instructions manipulated
these. Nice features included: if you changed the bit for the instruction
fetches, it didn't actually change until the next ALUOUT -> PC microcode
instruction, i.e. branch or jump.


> At the hardware level, the 4052 is 16 bit. But the microcode implements
> an 8 bit processor - the 16 bit operations are used for calculating
> addresses only. IIRC there are hardware features (like separate odd and
> even ROMs) that would make it easy to make it a true 16 bit machine. But
> it wasn't.

Almost exactly. And it's not just separate odd and even ROMs - it has
separate odd and even address buses! These hardware features do speed it
up, though. The other main application of the 16 bit data path was that
2-byte instructions were fetched with a single memory cycle, and this
happens quite often. The odd/even address logic meant this could be done
at an odd or an even address and still work.

My guess is that the hardware guys put a lot of work into that
architecture, wanting to make it both nice and 16bit and like the 6800.
Unfortunately, this took rather a long time, so the software guys just
wrote a 6800 near-emulator in microcode so as to speed the software
migration process. But this is just a guess.

Philip.
Received on Sun Feb 14 1999 - 22:55:31 GMT