Imagine a 32-bit 9900

[apersson850]

Are you an anti-VAXer?

[Willsy]

I must admit, the idea of something like this is very appealing - I'm salivating at the thought! But who would use it?

[Tuxon86]

2 hours ago, Willsy said:

I must admit, the idea of something like this is very appealing - I'm salivating at the thought! But who would use it?

Some of the Ti members here would, i guess.  As a hobby machine, kind of like the Commander X16 or the redux C65, it wouldn't be a commercial succes but a fun little hobby fpga based project. 

[GDMike]

Quote

Who'd use it

I'm wondering if we're trying to make a PC. 

[jbdigriz]

On 2/11/2022 at 12:31 PM, FarmerPotato said:

Imagine how you might go about extending the 9900 family to 32-bit. What problems do you run into and what solutions do you propose?
 

Yes, TI started over fresh with their 32-bit architectures like TMS320 and TMS340. (TMS430 is 16-bit again.) Except for 340, these are still going strong, alongside TI’s 32-bit ARM offerings. 

A definition of 32-bit will include 32-bit internal data path, really everything wider like registers, address space, arithmetic. 

 

I guess this 9900 would be designed in the 386 era? 
 

It must be 9995 compatible, and 99105 if you’re familiar with that.  99105 does have some 32-bit arithmetic and some 2 word opcodes.

 

Note: many 32-bit architectures pack two 16-bit instructions into a 32-bit word. 
 

Not 32-bit, but the Freedom CPU (64-bit superpipelined RISC) project started out with a 9900-inspired memory-to-memory architecture IIRC. You might want to review that for ideas.

 

Are you talking about just an IP core for implementation with an FPGA? That appoach has merit, esp with AMD buying Xilinx and planning to add FPGA capability to CPUs, which could make for a killer development setup. Or a bit-slice machine, maybe? I know TI made some 8 and 32-bit TTL ALUs at one point, if you can find them any more. I have seen 32-bit designs using 74181s or 2903s. Huge boards, though.

 

I am told* that TI actually considered 32 bit CPUs pre 32020 at least twice, once in the late '70s I believe for a 32-bit version of the 980 mini at the request of GSI, TI's original parent company, and somehat later a 32-bit 990 uP code-named "Viking", not to be confused with the TMS390 Super Sparc chip with the  same code name. (A nice 32-bit SPARC V8 RISC design that would be a good basis for a 9900 emulator, btw, hint, hint.)

 

The 980 plan was was dropped when the Moto 68K came out. GSI bought Varian/Interdata 32-bit machines instead. I was told also that there was a 991 project that would  have put a 68K cpu in a 990 chassis. This got to the point of an OS being designed, DPOS (Distributed Processing Operating System, I believe) which, if I understand correctly, and I'm awaiting confirmation on, was what eventually became DNOS. I'm not sure if the 991 would have used the TILINE bus unmodified, but at any rate it was eventually dropped. NIH syndrome is my guess. Any current or former TI employees that want to chime in here, please do so!

 

The idea of a 32 or 64 bit 9900 ISA is intriguing. Multicore, SMP, cached, superpipelined,MMU,fp in hardware, yes. Please spare us Intel style memory segmentation, though, if anyone attempts anything like this.

 

Odd that TI seems never have done much with the NS32000 series once they got it. Overall though the TI DSPs and derivatives, especially the multi-core ones with ARM hosts, PRUs, etc. are very nice and would also make a great 9900 emulation platform.

 

*private correspondence with former  TI employees directly involved in the above mentioned projects.

 

jbdigriz

 

 

Edited February 15, 2022 by jbdigriz

[jbdigriz]

On 2/11/2022 at 2:32 PM, GDMike said:

I think that TMS32010 is a 32 bit HOST type processor, meaning it can attach itself to the 9900?

The '10 is 16 bit, but yes it has a host processor interface. So does the TMS32020 iirc, and I believe it will also work with 16-bit hosts.

 

PS. Some interesting TMS320 history, also relevant to TI's thinking wrt a 990/9900 successor, at the TI Houston Alumni Association site: https://www.tihaa.org/historian/TMS32010-12.pdf

 

The "Ashtray Incident" is, uh...amusing.

Edited February 15, 2022 by jbdigriz
postscript

[jbdigriz]

5 hours ago, Tuxon86 said:

Some of the Ti members here would, i guess.  As a hobby machine, kind of like the Commander X16 or the redux C65, it wouldn't be a commercial succes but a fun little hobby fpga based project. 

There are a lot of people pining, just pining, for a modern ISA that is NOT built on top of layers of hidden processing units with user and even system-opaque microcode and/or even whole microprocessors and controllers running their own, unreadable OS or executives. There is a need for CPUs that are completely transparent and "free". This expands the potential market. Whether this could be a commecial success is anybody's guess, but maybe in a few years when a good design is ready, maybe there will be a glut of fab capacity by then with all the gazillions being spent today, and it might be feasible. You never know.

Edited February 15, 2022 by jbdigriz

[jbdigriz]

21 hours ago, FarmerPotato said:

I’ve been inspired by TI’s NuBus lately. The only NuBus systems historically were:

 

TI’s Explorer (based on NuMachine)

the TI business system 1500 (Unix)

Macintosh II

NeXT workstation

 

 

NuBus specifies how 8,16, and 32 bit bus accesses work together. There is no need for read-before-write. There are two extra bus bits, one is R/W but the other combines with the lower two address bits to encode the transfer size. Which is either 32 bits, the top/bottom 16 bits, or one of 4 bytes. 
 

Recall how earlier I mentioned 1 extra in the Byte field indicator.

 

This maps exactly to the NuBus transfer size bits. And it leaves an unused mode… in NuBus that is a block move of 1-16 bytes. Hmm. 

This is all just wild dreaming. But it could all be done in an FPGA and run at 100 MHz. Still, who but us 9900 fans would want such a thing?

 

 

There might be some interest from people wanting to replicate LISP machines, which are near unobtainium these days. A subset of Mac II'ers would be a subset of those.

 

Oh, wait, I misunderstood. You're talking about putting something on the NuBus, not the bus controller/interface itself, which can probably still be found if you look hard. Oops. Good idea, though.

 

Edited February 15, 2022 by jbdigriz

[+FarmerPotato]

9 hours ago, jbdigriz said:

There might be some interest from people wanting to replicate LISP machines, which are near unobtainium these days. A subset of Mac II'ers would be a subset of those.

 

Oh, wait, I misunderstood. You're talking about putting something on the NuBus, not the bus controller/interface itself, which can probably still be found if you look hard. Oops. Good idea, though.

 

I am talking about a NuBus backplane, and the bus controller interface.   I like NuBus because it's a TI owned-standard, and really good actually. It uses EuroBus hardware, and the B row of 32 pins is mostly power and ground, which I can repurpose.

 

The actual chips in the 1990 TI "NuBus Interface Products Data Book" are unobtanium, for instance SN74ACT2440.  But the logic is thoroughly documented by TI and the IEEE standard, and would fit into a CPLD, aside from the 32-bit address latch. (some TI chips have gobs of pins.)

 

 

There are a few folks who build NuBus cards for the Macintosh II. I think they just make their own bus interface.

 

[GDMike]

2 hours ago, jbdigriz said:

The '10 is 16 bit, but yes it has a host processor interface. So does the TMS32020 iirc, and I believe it will also work with 16-bit hosts.

 

PS. Some interesting TMS320 history, also relevant to TI's thinking wrt a 990/9900 successor, at the TI Houston Alumni Association site: https://www.tihaa.org/historian/TMS32010-12.pdf

 

The "Ashtray Incident" is, uh...amusing.

Yes, I was really meaning to imply the 32020-60, but it's all good. I think this would actually be the best way to go with about 8 GB of pixel block transfer shared ram and about 8 of these chips..

Hmm I guess Wally kept his job? Smoking can be dangerous to someone's health.

Edited February 15, 2022 by GDMike

[jbdigriz]

19 minutes ago, GDMike said:

Yes, I was really meaning to imply the 32020-60, but it's all good. I think this would actually be the best way to go with about 8 GB of pixel block transfer shared ram and about 8 of these chips..

Well the '10 and the '20 are both actually 16/32 designs. Had to review the datasheets, something was bothering me about my reply there. 16-bit instructions and memory bus, but 32 bit ALU with 16x16 multiplier. And I was thinking of the TMS340's host interface. TMS320 had a serial interface that could be used for coprocessors, multi-processing, mmu's, etc. I imagine connect to a host processor as well, though. I must admit I've been meaning to play around with some of these DSP's. Time to take a deeper dive in the docs.

 

Quote

Hmm I guess Wally kept his job? Smoking can be dangerous to someone's health.

I had a waitress nearly ashtray a gal I was having dinner with one time. I swear it didn't look like an accident, either. Naturally we all decided to call it one, though. ?

 

Edited February 15, 2022 by jbdigriz

[jbdigriz]

54 minutes ago, FarmerPotato said:

I am talking about a NuBus backplane, and the bus controller interface.   I like NuBus because it's a TI owned-standard, and really good actually. It uses EuroBus hardware, and the B row of 32 pins is mostly power and ground, which I can repurpose.

Cool, in that case, yes, there might be some interest outside the TI community if you adhere to the standard. I think the MacII connectors are slightly different, maybe, but I'm not certain on that.

 

Quote

The actual chips in the 1990 TI "NuBus Interface Products Data Book" are unobtanium, for instance SN74ACT2440.  But the logic is thoroughly documented by TI and the IEEE standard, and would fit into a CPLD, aside from the 32-bit address latch. (some TI chips have gobs of pins: 32 AD in, 32 address out, 32 data in/out.)

 

The NuBus S1500s were I think the only TI computers that were what we think of as multi-processor capable today. You could put multiple 990 CPUs in one box but they functioned either as logically distinct machines, or as coprocessors, for example using a 990/5 board as an sync/async I/O processor in a 990 setup. So, yes, I'd be interested in a backplane and interfaces for a replicated S1520 or Explorer. The real deals there are quite too expensive and inaccessible from my perspective.

Quote

There are a few folks who build NuBus cards for the Macintosh II. I think they just make their own bus interface.

 

Might be good to compare notes with them. You're still sticking with E-bus for the Geneve 2020 though, right?

Edited February 15, 2022 by jbdigriz

[jbdigriz]

1 hour ago, FarmerPotato said:

I am talking about a NuBus backplane, and the bus controller interface.   I like NuBus because it's a TI owned-standard, and really good actually. It uses EuroBus hardware, and the B row of 32 pins is mostly power and ground, which I can repurpose.

 

 

The NuBus is limited in speed is the only drawback I see for anything like a new design processor. What, 10Mhz? Apple maybe bumped it up some from there, I think 20 Mhz, on later NuBus Macs.

[+FarmerPotato]

6 hours ago, jbdigriz said:

Cool, in that case, yes, there might be some interest outside the TI community if you adhere to the standard. I think the MacII connectors are slightly different, maybe, but I'm not certain on that.

 

The NuBus S1500s were I think the only TI computers that were what we think of as multi-processor capable today. You could put multiple 990 CPUs in one box but they functioned either as logically distinct machines, or as coprocessors, for example using a 990/5 board as an sync/async I/O processor in a 990 setup. So, yes, I'd be interested in a backplane and interfaces for a replicated S1520 or Explorer. The real deals there are quite too expensive and inaccessible from my perspective.

Might be good to compare notes with them. You're still sticking with E-bus for the Geneve 2020 though, right?

That's interesting about the 990s. I understand intelligent I/O peripherals, but the extra 990/5 was the same as a standalone master CPU card?

 

Theoretically, you could use a Macintosh II motherboard to host Explorer CPUs. I think

 

Kontron & E-Bus

 

When I was adhering to the Retrobrewcomputing.org ECB standard, aka Kontron with extensions, I thought there might be some overlap. Well, I've done that, and someone can put my 99105 into a ECB backplane if they want to try it, but I don't see any ECB peripherals being of maximum use. 

Kontron had the awful daisy-chain where every card has input and output pin for arbitration and interrupt I/O, which breaks 4 lines of the bus & require jumpers for them in empty slots. E-Bus does the same thing.

 

7 hours ago, jbdigriz said:

You're still sticking with E-bus for the Geneve 2020 though, right?

Though there are lots of good ideas in the E-Bus book, the arbitration is awful. And its address space is just 1 MiB; I plan on 32MiB.

 

The E-bus arbiter 74LS2001, seen in 1981, was like Intel's 8289 arbiter for MultiBus, and I'm not excited about building a system around either one.  

 

NuBus

 

In contras, the NuBus backplane is 3x32 lines straight-through, with power and some terminations. So there's nothing hard to reproduce there. All the logic is in the cards themselves.

 

The arbitration is elegant. No central control (beyond a hard-wired 4-bit Slot ID on the backplane.) Parallel, and completely fair (nobody starves). The schematic is easy to understand, and fits into a CPLD plus an open-collector buffer/driver.

 

It was designed for plug-and-play configuration, especially for interrupts. (Then there was A/ROSE...)

 

 

Anyhow, I'm taking ideas from NuBus, but only using a subset of the pins, leaving the others reserved. 

 

 

[jbdigriz]

50 minutes ago, FarmerPotato said:

That's interesting about the 990s. I understand intelligent I/O peripherals, but the extra 990/5 was the same as a standalone master CPU card?

Right, there's a post on the vcfed TI subforum from somebody who did this. Whether this took any special coding he didn't say and I can't ascertain, but I think it would involve some shared memory. I am told this (cough) emulated bit-slice COBOL accelerator I have in this (cough) emulated /10A based DART system works in similar fashion. Know more when I examine the software on the (cough) emulated Fujitsu drive image ?

Quote

 

Theoretically, you could use a Macintosh II motherboard to host Explorer CPUs. I think

OK, Hans23 has a post in another thread about the Mac II-based Microexplorer. They even have TI badging. Not the same boards as the TI Explorer and follow ons, though, and those boards won't work in a Mac. Dimensions, for one thing, and connectors slightly different, as I understand it. Not sure how much anything else differs, although one would expect some significant software differences.

 

Quote

 

Kontron & E-Bus

 

When I was adhering to the Retrobrewcomputing.org ECB standard, aka Kontron with extensions, I thought there might be some overlap. Well, I've done that, and someone can put my 99105 into a ECB backplane if they want to try it, but I don't see any ECB peripherals being of maximum use. 

Kontron had the awful daisy-chain where every card has input and output pin for arbitration and interrupt I/O, which breaks 4 lines of the bus & require jumpers for them in empty slots. E-Bus does the same thing.

 

Though there are lots of good ideas in the E-Bus book, the arbitration is awful. And its address space is just 1 MiB; I plan on 32MiB.

 

The E-bus arbiter 74LS2001, seen in 1981, was like Intel's 8289 arbiter for MultiBus, and I'm not excited about building a system around either one.  

 

NuBus

 

In contras, the NuBus backplane is 3x32 lines straight-through, with power and some terminations. So there's nothing hard to reproduce there. All the logic is in the cards themselves.

 

The arbitration is elegant. No central control (beyond a hard-wired 4-bit Slot ID on the backplane.) Parallel, and completely fair (nobody starves). The schematic is easy to understand, and fits into a CPLD plus an open-collector buffer/driver.

 

It was designed for plug-and-play configuration, especially for interrupts. (Then there was A/ROSE...)

 

 

Anyhow, I'm taking ideas from NuBus, but only using a subset of the pins, leaving the others reserved. 

 

 

Sounds like a good match for a 99105, then. Or even an FPGA /12, which would be even nicer.

 

I will take this opportunity to correct an misstatement I made earlier in this thread. Sorry, my posting skilz have got rusty. But, when GSI selected a 32-bit machine, it was Perkin-Elmer/Interdata, not Varian, which I think I said. Probably a 7/32 or 8/32 but I didn't get the details.

 

Edited February 16, 2022 by jbdigriz

[+FarmerPotato]

22 hours ago, jbdigriz said:

There are a lot of people pining, just pining, for a modern ISA that is NOT built on top of layers of hidden processing units with user and even system-opaque microcode and/or even whole microprocessors and controllers running their own, unreadable OS or executives. There is a need for CPUs that are completely transparent and "free". This expands the potential market. Whether this could be a commecial success is anybody's guess, but maybe in a few years when a good design is ready, maybe there will be a glut of fab capacity by then with all the gazillions being spent today, and it might be feasible. You never know.

That’s a fascinating point of view. It is exactly how I feel about our 9900s! Commercial ? IDK. I think there are several embedded CPUs you can look too, maybe RISC V will satisfy. 
 

I haven’t studied RISC-V but I’d like to. ARM64 world has become a multiprocessor monster with specialized cores inside cores inside a die.. I’ve only done assembly on a Cortex M0, which is not too opaque. 
 

I like TI’s MSP430 16-bit ISA. It’s small and it’s got support in LLVM / Clang. it’s a RISC-y load-store architecture with clever pseudo instructions. Plus its got Forth and a place in “FRAM for dummies.”

Fab: at a SVFIG meeting I heard about Google opening up foundry slots to people wanting to design open source chips. 

 

 

 

[+FarmerPotato]

On 2/14/2022 at 1:52 PM, FarmerPotato said:

In 16-bit mode, the 16-bit instructions are the exact same code as 99xxx , but are “expanded” in the CPU pipeline with 0s in any new fields.

While thinking about the stack machine yesterday, I had a brainwave. 
 

Or

 

A funny thing happened on the way to superscalar...

 

superscalar means that you issue multiple instructions at once, to multiple pipelines. Obviously they need to not have data dependencies. 
 

 

I make an instruction cache, say 16 words. The instruction decoder presents the scheduler with instructions that can execute in parallel, or almost so. 
 

For a 32-bit general Format I, the assembler makes two  instructions for 16-bit halves. The Decoder joins them and presents the Scheduler with one 32-bit operation. 

MOVL R0,R2 is a macro for:

MOV R0,R2

MOV R1,R3

The Scheduler signals the  Integer ALU to do one 32-bit operation with carry and status bits as appropriate. 
 

Alternately, there is a stub instruction between them, like "Add with Carry" ADC, or "Join Status" JST, that means treat them as one, with carry, overflow, status as appropriate for a 32-bit operation.  

The Decoder has time to figure this out while the previous instruction is executing. 

 

TI made the AM, SM Multiple instructions for 32-bit, so maybe those are adequate. Add Multiple is two words, in the second is a byte count from 4 to 16 for the operand  sizes. 
 

Such code can be backwards compatible to 9995, by using the MID handler (interrupt 2) to catch the AM or JST  and to do them in software. Especially since the 32-bit operation is assembled as two 16-bit ops. 
 

In a similar way, 32-bit address pointers can be conjured. Perhaps beginning with a LDS or LDD, the next two instructions have combined operands. 
 

Or, do like the AM: use a prefix opcode that means "do double width addresses or data on the next 16-bit instruction." This too could be emulated on a 9995.

 

Essentially, the whole 16-bit instruction set is replicated as 32-bit instructions where the bottom half is the original 16-bit instruction. 
 

Register access means the register and the one following.  Or maybe there is a prefix bit to treat the workspace as 16 long word registers instead. The new R16-R31 we'll call X0 to X7. Yet another mode turns the register number into floating point size, 8-byte registers.  In assembly, referred to as F0 to F7. 
 

I worked out how the ALU can be turned into a RADIX-100 floating point unit.  Look-ahead carry is essential--and can be done in 8-bit slices, plenty fast enough. (Look Ahead vs Ripple Carry--Google it.) 

TI used IBM format floating point in the 990/12. It's awful. The 99110 implements the 32-bit variety, while the 990/12 covers 64 and 128 bit floats.

 

All these double and quad word registers still refer to a contiguous workspace.  So no problems with the WP. RTWP, LWP, etc.  Where 16-bit register N is at address WP+2*N, the wider varieties Xn are at WP+4*N and Fn are at WP+8*N. 
 

This is kinda growing on me. I like the idea of 16-bit code but executed two at a time. The external bus is 32-bits wide. 

And same code might even still run on a 9995 or 99000 provided you write the MID handler. This is exactly how TI envisioned the larger 9900 family. 
 

Workspace Cache

 

Registers are cached. It takes no time to address a register source (all other 9900s incur at least one cycle.) 

 

 I drew a scheme where 4 register files are present in cache. The least recently used LRU is evicted when necessary. 
 

Another goal is to eliminate the overhead of BLWP, RTWP, interrupt context switches. For that, all 3 registers WP, PC, ST, are transferred to cache at once. 

I experimented with logic to detect when an ordinary memory write crosses through a cached register.

 

I believe it requires an assumption that any WP is aligned on a 32-byte multiple. Not a huge liability. Maybe, it you run code with a non-aligned WP, you lose the   benefit of caching. 
 

Result? 
 

Where the 99000 optimized MOV to just 3 cycles, this eliminates the source and destination operand cycles. For registers, I think MOV and friends now take ONE CYCLE. Assuming a full instruction pipeline,  the ALU is never idle. Every cycle, one instruction is "issued" and one is "retired" so that on average each costs one cycle. 
 

It's even possible that MOV doesn't even need to occupy the ALU. Though it does need to update status bits.
 

 

 

Plenty more problems to think on. For instance, where does BLWP find room to store a 32-bit return address?
 

Maybe it goes into R26... It's counterpart, RTWP32, is easily nestled in-there were 4 

Unused reserved bits in RTWP. (99000 defines two more flavors of RTWP. 380C16, "The Last 9900", seems to define one of its own--I see it in driver code.) 

I meant to end this--still plenty of problems remaining. 
 

 

 

 

 

 

[hhos]

"Except for 340, these are still going strong, alongside TI’s 32-bit ARM offerings."

 

Has TI stopped making the 340s?  I was fairly impressed with both the '10 and the '20. Are they not available now?

[+FarmerPotato]

On 11/21/2024 at 2:15 PM, hhos said:

"Except for 340, these are still going strong, alongside TI’s 32-bit ARM offerings."

 

Has TI stopped making the 340s?  I was fairly impressed with both the '10 and the '20. Are they not available now?

There was no development after 1990, and I dunno when they ceased production or sales.  The SMJ34020 was available for longer (military version for fighter jet graphics.)  

 

 

[Gary from OPA]

8 hours ago, FarmerPotato said:

There was no development after 1990, and I dunno when they ceased production or sales.  The SMJ34020 was available for longer (military version for fighter jet graphics.)  

 

 

As of April 2024, the SMJ34020 is listed as NRND "not recommended for new designs", meaning it's in production only to support existing customers.

[+FarmerPotato]

4 hours ago, Gary from OPA said:

As of April 2024, the SMJ34020 is listed as NRND

Wow! I downloaded that data sheet a while ago and did not think to look for dates! 
 

How did you find it? I got it by guessing the URL   Figured TI forgot to delete it. 

 

 

[Gary from OPA]

25 minutes ago, FarmerPotato said:

Wow! I downloaded that data sheet a while ago and did not think to look for dates! 
 

How did you find it? I got it by guessing the URL   Figured TI forgot to delete it. 

 

 

they update their datasheets now and then with added pages at the bottom about product life, etc.

 

https://www.ti.com/lit/ds/symlink/smj34020a.pdf