Having read a couple of different takes on this, I see the concern but I’m not sure I agree with Ken’s take.
Basically he’s saying it’s not really a microprocessor because the CROM isn’t on-die. That might indeed be a reasonable definition of microprocessor. However, it’s also the case that other designs of the era did not have an on-board CROM.
An example is the Fairchild F8, which put it on a second chip along with the PC - this seems like a direct analog. I’ve yet to see anyone claim the F8 is not a microprocessor.
This was not common among the systems we are familiar with today, it was relatively common among those processors developed for larger machines, which was the case here. Since the underlying ISA was not specified, and was always intended to change across platforms, putting it on a ROM was a no-brainer.
I’m not going to claim I know the answer one way or the other, but I’m inclined to say that I would not outlaw this because of the location of the CROM.
I think non-overlapping two phase has the same effect.
(I recall that the T9000 was four-phase on the inside, and some blocks used phases 1 and 3 to be truly overlapping, others 1 and 3+4, IIRC. Of course I probably don’t remember correctly, but I do know there were two clocking styles. In fact the whole chip was a great mish-mash of different design styles, one reason for it being late and grossly missing the clock speed target.)
It is very good. I found it interesting that you listed “Address width” as 16 in the information box. I had not seen anything about that and had guessed that addresses would be 8 bits per chips as well (so 24 bits with 3 chips).
Ken’s argument is that the labeled picture of the chip is a lie and that there is nothing like a PC in it. He was able to examine the circuit used in the court case (which I haven’t seen) and claimed an external TTL register chip was used as the PC and that the next address was generated by the ROM. That would make the TTL and ROM a standalone finite state machine - it would be able to follow a sequence of instructions on its own independently (or mostly so) from the AL1 chip. As you noted in the article, other people don’t agree.
At 9 minutes of this 1 hour talk about the TMS9918 there is an explanation about the four phase technology Texas Instruments called “ratioless logic” NMOS but which is better known as “domino logic”.
Excellent - thanks for that! I came across domino in the context of CMOS and didn’t quite understand it (my head was full of NMOS). And yet that presentation tells us that TI were using it in PMOS days - to keep power down.
That’s a terrific video - thanks! The 9918 is course a classic retro chip.
Here’s a link to the book he references in the slide about ratioless logic if you want to go a little deeper (link is to a 350 page PDF).
It would be interesting to build some dynamic logic on a breadboard using larger capacitors. I think you can build pass gates (“transmission gates”) using CD4007 chips, which are still available. I’ve seen reference to an issue with not having access to the “fourth terminal” (“body”) of the FETs but never understood.
I’m afraid we gone off topic on the thread here. But this is good stuff.
As I understood it from that talk, ratioless logic NMOS is all about floating state and transient capacitance and everything is processed on the rising edge. (So, many nodes don’t really have a state and everything is in flux.)
extra instructions - see below - for support of threaded interpreted languages, for arithmetic including multiplication, swap, multiple register push and pull, one-byte subroutine calls (8 available, vectored through ROM)
16-bit I register to support threaded interpreted code
That was it. Sadly that is one of the most misleading titles I have seen.
A improved X86 cpu comes to mind, with all the IBM PC stuff now
flooding the market place, or PASCAL some thing.
I was wrong about the encoding how ever,I must have been thinking of
a 16 bit computer of some sort.
A great find - thanks! That’s The Next Generation of Microprocessor by Timothy Stryker of Samurai Software. It starts with a bit of a survey of the state of play, of microprocessor systems supporting high level languages
No doubt a fair amount of confusion exists at present as to just how to go about the implementation of a high-level language in hardware. National Semiconductor and Zilog have each introduced single-chip microcomputers incorporating small BASIC interpreters in on-chip ROM (read-only memory). While this is a step in the right direction, the utility of these chips is greatly diminished by their slow processing speeds. The low-level architectures of both chips are entirely conventional in nature, and the fact that they happen to incorporate BASIC on-chip rather than in an external ROM represents merely an advantage in terms of decreasing system chip count. Higher up on the scale are Western Digital’s Pascal and Ada Microengines, multichip processors that have experienced only limited market acceptance due to their high costs. The Intel iAPX-432 processor appears to be a promising development in this area, but the great complexity of its architecture would appear to put it out of the sights of most potential users for the time being.
… An Alternative
The primary disadvantage of using FORTH as the basis for the hardware implementation of a high-level language is, as discussed, its threaded nature. I would like to present an alternative scheme that skirts these difficulties and that represents a viable, cost-effective approach to the implementation of a high-level language in hardware.
The article goes on to sketch a paper design for a CPU (8 bit databus, many 16 bit operations) running FORTH-ish opcodes. Having identified 33 desirable operations, the author then dedicates 192 opcodes to pushes of literal values. Maybe that’s an excellent idea, but it’s a surprise to me.
There’s even a pinout for a 40 pin DIP…
Some readers may notice that this is the same pinout as that for the 6502 microprocessor.
In closing, he writes
Stack-oriented high-level-language hardware represents an eminently practical, cost-effective mechanism for extracting minicomputer performance from microcomputer hardware — at “nanocomputer” cost.
The reason that this development has been so long in coming is due to a number of factors, not the least of which is that until recently softwareoriented personnel have had little input into instruction-set design. In addition, an architecture of the sort presented here would probably not have been feasible prior to the advent of VLSI (very-large-scale integration) as a commercially viable massproduction technology.
In this connection, it is amusing to note that Electronics magazine once ran as part of a “New Year’s Wish List” the fervent hope that Intel Corporation’s Gordon Moore be granted “inspiration on what to do with a chip holding 1 million transistors.” This wish may be granted yet
Rather than encoding constants, have threads start on even bytes,if encoding FORTH.
0xxx xxxx , xxxx xxxx call rather than a 15 bit immediate,
where xxxx xxxx xxxx xxx0 is the call.address. A mode flag?
Load,store and lea could be added for a tiny PASCAL or a C subset.
It reminds me of CITNTCODE virtual cpu which is the target of the BCPL compiler (one target, anyway). It’s an 8-bit bytecode for an intersting machine which has a 2-deep register set and all data is generally expressed as offsets from a location (stack, globals, statics), but it has a wealth of one-byte opcodes to load (and add/sub) constants - derived (AIUI) from optimising the instruction set based on the output of the compiler. (e.g. you can add from 1 to 10 but only subtract from 1 to 4) So you can load constants into the 2-deep register “stack” from minus 1 to plus 10 with another byte instructions to load a positive or negative constant (data value 8,16 or 32 bits in-line after the opcode). It also has one byte instructions to load and store a value from/to a stack offset (3 to 16 words from the start of the stack) rather than a form of pop/push operation. (This is to make frequently used local variables quick to access)
So at a first glance it might seen a bit RISCy but adding in all these compound opcodes does make it more CISCy - and maybe why not? If you have the bytecodes left over and the silicon (or software in this case) to decode them?
