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.