Sun's Star7: Touchscreen Tablet of 1992 | Hacker News Reader

Sun's Star7: Touchscreen Tablet of 1992

wired.com

67 pointsForHackernews17 comments

Another interesting early tablet story: Go Corp.

http://www.guidebookgallery.org/books/thepowerofpenpoint/cha...

http://en.wikipedia.org/wiki/GO_Corp.

http://www.amazon.com/Startup-A-Silicon-Valley-Adventure/dp/...

And it would burn your hand if you held it too long :-). It really was pretty amazing cramming what was essentially a SPARCStation II+ into something that small. When the group showed the cable companies the environment they could have it got good reviews but it ran on a SPARCStation 10. They said they might spend $150 on the settop box hardware that year. (think Z80s + CRTC chip). Now, 22 years later, $150 actually gets you something with similar capability to the SS10 which could no doubt run the demo app just fine.

I have to imagine that $150 blows the SS10 away massively (yesterday's Nexus Player is $99 with Bay Trail silicon with a solid GPU...) -- the speed of commoditization of hardware this cycle has been pretty amazing.

The SGI guys had a similar experience when Nintendo bulk produced the N64 and sold it for $200. It was most of a $5000 workstation with better graphics hardware!

Here's a great teardown on the N64

https://www.youtube.com/watch?v=ScicrgZwvg4

> I have to imagine that $150 blows the SS10 away massively

No doubt. Remember that the base model of a SS10 had a 0.033 GHz CPU. A raspberry pi would run circles around it.

That's not even counting a modern GPU. A SPARCstation would usually be equipped with a dumb framebuffer like a CG3 card.

Computers these days are _FAST_

Actually the Raspberry Pi does not run circles around it because it has to do so much of its work through the USB bus. The Pi makes a good case study for system architecture in that regard. The trick is to compare channel bandwidth, memory, I/O, and cache to see see how those parts interact.

Sure, let's compare. I don't have every number at hand, but:

I/O: * SS10 -- Fast SCSI: 80 Mbit/sec theoretical max * Rpi -- USB2 480 Mbit/sec. Now there are certainly complaints about poor USB performance, but it's not so bad that the SS10 would beat it

Cache: * SS10 -- 32K in the base model (although later ones had more) * Rpi -- 256K

RAM: * SS10 -- depends on configuration; most machines of the era tended to have 32MB or so. I actually had an SS10 with an exotic 128MB, but half of the ram was actually on an SBus card. * Rpi -- 256MB in the lowest configuration you can buy. True, that is shared with the GPU whereas the SS10's CG3 card had its own memory if I remember right.

You are correct that the Rpi is bus and I/O crippled compared to most modern hardware. That's why I chose it as an example: even the cheapest hardware you can buy today is so much faster than a SS10. It's really astounding to think about.

And that is why it is such a great tool for learning. Lets start here:

   > I/O: * SS10 -- Fast SCSI: 80 Mbit/sec theoretical max 
   > * Rpi -- USB2 480 Mbit/sec. Now there are certainly 
   > complaints about poor USB performance, but it's not 
   > so bad that the SS10 would beat it

The SBus[1] is slower than High Speed USB[2], and yet the amount of code it takes to get 1 megabyte of data from a USB peripheral into the memory of a CPU is greater. USB is polled, the Host Controller has to continually check to see if there is something out there, SBus is not allowing it to initiate transfers from the peripheral. Further things like key presses compete with network packets for attention from the root HUB. While transactions on the Sbus(es) can happen in parallel.

Then there is the SDIO interface for the RPi's flash disk, which also competes with USB for I/O cycles on the ARM AHB bus. So at the end of the day some things are really faster (like graphics) and some things slower (like I/O), and the whole package feels remarkably similar. Can't argue on the price though, you still can't get a working SS10 for $35 as far as I can find.

[1] SBus specification -- http://bitsavers.informatik.uni-stuttgart.de/pdf/sun/sparc/8...

[2] My go to USB spec site -- http://www.beyondlogic.org/usbnutshell/usb1.shtml

[3] Summarized SS10 information -- http://www.obsolyte.com/sun_ss10/

[4] Gateway to the simplified SDIO specs -- https://www.sdcard.org/developers/overview/sdio/sdio_spec/

Usable USB2 bandwidth is about 40 MBytes/sec (you can squeeze out more, but you're talking custom devices and carefully crafted protocols).

80 MBit/sec SCSI is 8 bits wide, with pretty good utilization (depends on the drive), so it's going to do pretty well in comparison. I don't know if 1992-era drives could do (say) 100 MBytes/sec, maybe on the outer rims?

> 80 MBit/sec SCSI is 8 bits wide

No, I converted both of the speeds to MBit to make them easier to compare. The SCSI on a SS10 was 10MB/sec, so 80Mb/sec.

The bus utilization on SCSI was high, and the USB2 on a Rpi is slow but not nearly enough to make up for a 6x gap in raw bus speed.

The N64 cut down on a lot of expensive parts. Versus a typical-spec SGI Indy, the cheapest SGI, thousands of dollars were shaved off. Nintendo/SGI might have still lost money, but if an SGI workstation was a sedan, the N64 was a hot rod. All engine, no frills.

CPU - Indy: R4400SC, 16 kb L1, 1MB L2

CPU - N64: R4300i derivative embedded chip, 32 kB L1, no L2, half bus width

RAM - Indy: 16, 32, or 64 MB of RAM, plus dedicated framebuffer

RAM - N64: 4 MB of RAM (this was potentially half the cost of the system!)

Graphics - Indy: "Newport" graphics -- 1280x1024, 8 or 24 bit color, full, dedicated framebuffer

Graphics - N64: 320x240, 8, 16, or 24 bit color. typically dedicated 1/4 of system RAM to framebuffer

Storage - Indy: SCSI hard drive + SCSI magneto-optical removable

Storage - N64: not a damn thing

I/O - Indy: ethernet, ISDN, high speed serial

I/O - N64: nothing

Funny how everyone was doing the General Magic-style UI (where you had to navigate down the street to the post office to send email) back then.

That and the incredible role of sound in the UI, so annoying for today's standards. It seems they were communicating to the users of consoles and arcade machines.

Maybe both techniques were inevitable at that stage of the general public training to technology. Both were abandoned a few years later when Windows 95 and then the web made the PC really mainstream. Their language was totally different and we all got used to it quickly.

What struck me was the jarring use of both "Australian" and "Traditional" scrolling styles on the same device. The selection widgets moved along with your finger, but the room panning moved counter to your finger. That would drive me batty.

I was thinking the same thing. I wonder if they had both scrolling methods on the device for testing purposes.

The noise while drawing around the room (and outside) was horrid. Nails on chalkboard type horrid. I'd have thought the visual movement was enough to convey the idea that you were navigating. But testing again I guess.

Didn't watch the whole video, but I think that's the same device Gosling demoed 'gravity' pull on. The relationship between so-called progress and memory loss (or the lack of knowledge in that case) tickles my mind everytime.

Appeared recently on HN: https://news.ycombinator.com/item?id=8411846. Since there wasn't much discussion, we won't call the current thread a duplicate.

Reply on news.ycombinator.com