Hacker News Reader

Comment by kens | Hacker News Reader

I'm sure there are a bunch of people on HN who have used the i960. Author here if anyone has questions about the article.

View on HN

At the time I worked for a small compiler shop, and we had a C compiler for the i960 — https://web.archive.org/web/19971014124149/http://www.archel... — In particular I wrote the standalone instruction scheduler described under ‘Scheduler optimizations’, particularly useful for the superscalar variants.

I worked on a bunch of MPEG-2 encoder and decoder designs using the i960CF and i960RP when I was at Optivision. Here's a photo of an MPEG-2 encoder (found on E-bay) that used the i960CF and a PCI interface chip designed specifically for the i960CA/CF, the PLX PCI9060.

https://www.w6rz.net/opti.jpg

With all the interest in retro computing these days, I wish I had kept more stuff from the 80's and 90's. Here's all I have left, an i960CA-16 chip from a development board that I had replaced with an i960CF and a manual.

https://www.w6rz.net/i960ca.png

https://www.w6rz.net/i960camanual.png

I found another item that I hung onto. A CD with the i960 tools including gcc (looks like it's gcc 2.7.2). Also has a bunch of manuals in PDFs.

https://www.w6rz.net/IQ80960RXK5_2.iso

105,078,784 bytes.

That's a nice collection of documents on the i960 RM and RN chips.

That's pretty neat. I enjoy seeing first-gen designs like this, before everything gets integrated down to one chip.

No shortage of PLDs and dual port ram on there. And not one but two CL4040 encoders from C-Cube.

What was the reason for having both a i960 lacking a FPU along a probably much more powerful TMS320? Was PCI in general a weak point of the dsp chip and a strong point of the 960?

The CL4040 had two CL4020 chips in the package. It took four chips to encode 1/2 D1 resolution (352x480), so this was the smallest MPEG-2 encoder possible at the time (1995).

The TMS320 chip was the audio encoder and was only capable of MPEG-1 Layer 2 coding.

The i960 was primarily used for bitstream multiplexing, either Transport Stream or Program Stream. The idea was to offload the host so that you could have many encoders in a cheap PC (with a big power supply).

I worked at Applied Microsystems (now defunct). We made in-circuit emulators and did one for the 80960CA variant. I remember that processor had an undocumented (IIRC) feature called "Incremental Trace" that would allow the emulator to keep track of what the processor was doing. We used it to develop an execution trace disassembler for the processor.

I seem to remember HP/Boise was using a lot of the CA parts for use in printers. They had one of our emulators, and I remember that we once got a report of the emulator probe tip having caught fire (!) due a short or some such.

I enjoyed working with the CA part. I also worked with the 80960MX part. Now, that was an odd processor!

Following up my own post, I also remember the hardware guys having occasional phone calls with some guy known only as "Larry" at Intel. I'm guessing he was a microcode guy or some such. Would be interesting to know more about him.

HP (Panacom) in Waterloo used them in X terminals. Edit: Specifically the HP 700/RX.

I'm not so sure the F-18 Stores Management Processor used the i960MX. Any sources to confirm that?

There has been some interest recently in the F-22 Common Integrated Processor using the i960MX, as the USAF wishes to retire older F-22 Block 20 Aircraft.

Apparently, newer F-22 Blocks use FPGAs to provide a functional soft core of the i960MX, without having to locate long obsolete chip sources for legacy avionics designed in the 80s

Of course I have a source :-) https://www.google.com/books/edition/Avionic_Systems_Design/...

It was upgraded from the HAC-32 (Hughes system with the i960 MX) to PowerPC around 2002. See page I-12 of https://studylib.net/doc/11020640/navy-training-system-plan-......

Very interesting article. The 35(!) i960s in the F22. Do you know how they were ..distributed?

Interesting. Thanks for the references.

Labtam x-terminals and ultimately edge routers did. I briefly worked doing regional network deployment and support with them, and some board replacements in the field. Tektronix bought out their IPR. (Australian company, one of the last manufacturing IT companies doing on shore assembly)

They ran a Unix kernel and had a very good networking stack. I believe they coded early to the emerging new TCP flow control models.

> The die was too large for the optical projection of the mask, with the result that the corners of the circuitry needed to be rounded off.

How big is the die in the picture?

The die is 620x680 mil. https://archive.org/details/guidetoriscmicro0000unse/page/26...

Was the i960 in laserprinters?

Yes, laser printers were one of the big markets for the i960. The Am29000 was their main competitor. (People nowadays probably don't realize how computationally intensive laser printers were.)

There is an apocryphal story* where the fancy new laser printer was having strange issues and would become unresponsive for long periods of time. The sysadmin tasked with figuring it out managed to trace it down to one user who kept sending strange print jobs that took forever and never printed anything. When asked about the jobs the programmer said that the processor in the printer was much more powerful than anything else in the company so he added a postscript target to his engineering programs so they ran simulations on the printer.

* That is, I don't remember where where I first heard it, probably a usenet post somewhere

I heard it about Berthold K P Horn https://www.eecs.mit.edu/people/berthold-horn/, professor of machine vision. And it was extra convenient because he wanted to output the result of the computation as an image anyway, and what better way than with a high-quality printer?

Hmm, that almost seems like fair-game.

My officemate Paul Heckbert wrote a ray tracer in PostScript after we realized that the laser printer's processor was much more powerful than our "real" computer. As you might expect, the interpreted PostScript ray tracer was extremely slow but it did eventually generate an image, I think at 32x32 resolution.

Compared with dot matrix printers, sure. But more so than inkjets?

SPARCprinters were like WinModems of their time: they offloaded all the Display PostScript processing to the host. The printer was essentially interfaced like an external monitor; the host would do all the rendering and then read out a finished image for the printer to immediately lay down on paper.

The NeXT laser did the same.

I remember hearing that for a few years, the LaserWriter (or was it the LaserWriter II?) was the most powerful computer you could buy from Apple.

The original LaserWriter came out in 1985 with a M68000 CPU running at 12 MHz, with 512 KB working RAM and a 1 MB framebuffer.

The Macintosh at the time had the same M68000 CPU, only running at only 8 MHz and with 128 KB of RAM (or 512 KB for the Fat Mac) which was shared with screen RAM.

That's misleading. The reason was not because it's a "laser printer" but because it was running PostScript (which is a full fledge programming language). Had the "API" been a trivial image printer (like the NeXT laser printer), then the compute requirements would have been far less intense.

Reply on news.ycombinator.com