[cctalk] Illiac II Library Routine
A friend of mine passed away about a year ago, and his wife is just getting around to sorting through his many books, papers, etc. The title of the heading title is what caught my attention. My current plan is to scan the 9 page paper and make it available to interested parties. Since me my plan is to bring many of his books/manuals to VCFMW in September. The identification is "A complete NICAP program which does matrix arithmetic." The heading is: University of Illinois Graduate College Department of Computer Science Illiac II Library Routine F1-UOI-MTRZAL-82-NI After I get it scanned, I will submit it Bitsavers and give the original to the Computer History Museum. There may end up being more such papers as his stuff continues to be sorted through. Marvin
[cctalk] Re: Experience using an Altair 8800 ("Personal computer" from 70s)
> The LINC exhibited at VCF 10.0 was one of two systems the fine folks of the > Washington University team who originally designed and built the LINC > scraped together and got working in time for the Festival, and their > presentation therein. That system went with Bruce Damer to the DigiBarn > (Bruce was instrumental in putting together the presentation for VCF X) and > then a few years ago went off to the System Source Museum in Maryland. I can confirm that it is still on active display at System Source. Although a bit off topic, I think the readers of the list would be happy to hear it is more or less still functional. The power supply required some work (caps and some failed parts on a regulator card as figured out by Dave Gesswein) as did the LINCtape drives (new bearings, tension adjustments on the belts), and probably some other things I'm forgetting. Early this year it was successfully brought into LAP6 and played a game of Pong for the first time in years :) Unfortunately the LINCtapes themselves have degraded and started not reliably reading, so it was decided to not mess with them any further until they could be imaged. I'm not sure if they've made any progress since - most of this was from my visit back in January. Regards, CJ On Sat, Jun 8, 2024 at 9:53 PM Sellam Abraham via cctalk < cctalk@classiccmp.org> wrote: > On Sat, Jun 8, 2024 at 7:43 AM Jon Elson via cctalk > > wrote: > > > On 6/7/24 20:42, Vincent Slyngstad via cctalk wrote: > > > On 6/7/2024 6:19 PM, Jon Elson via cctalk wrote: > > >> OK, I have to chime in here. I worked for Artronix about > > >> 1972. The LINC computer was developed at MIT for use in > > >> biomedical research labs, and a bunch of people involved > > >> with it later moved to Washington University in St. > > >> Louis. The Biomedical Computer Lab there later added some > > >> features such a a crude memory mapping unit and more > > >> memory, and called this the Programmed Console, so as not > > >> to scare people away. Artronix began building these PC's > > >> and selling them to hospitals for radiation therapy > > >> planning. I have no idea how many were sold. They were > > >> built into a desk, and used 7400-series logic chips. They > > >> etched their own PC boards, drilled them by hand and > > >> soldered in the chips by hand. I wrote a series of > > >> diagnostics for them. > > > > > > Do any survive? I've looked for them but never found one. > > > > An Artronix PC? I seriously doubt it, but it is possible. > > There is at least one LINC that was restored about a decade > > ago, and taken out to VCF 10. If an Artronix PC did evade > > the scrapper, it would not be that hard to get it running again. > > > > Jon > > > > Is it Artronix or Artronics, out of Plainfield, New Jersey (according to > the label, formally TechArt Systems 2000)? Because if the latter, I have > one right here, though I can't tell you the model number because it is not > displaying one. The serial number seems to indicate it was made in 1984. > > Here's a link to an ad in PC World circa 1984 ==> > > https://books.google.com/books?id=-C_xVnQCcsEC=PA48=artronics++plainfield=en=X=2ahUKEwiv_-DQs82GAxWPmO4BHahVB_YQ6AF6BAgEEAI#v=onepage=artronics%20%20plainfield=false > > The LINC exhibited at VCF 10.0 was one of two systems the fine folks of the > Washington University team who originally designed and built the LINC > scraped together and got working in time for the Festival, and their > presentation therein. That system went with Bruce Damer to the DigiBarn > (Bruce was instrumental in putting together the presentation for VCF X) and > then a few years ago went off to the System Source Museum in Maryland. The > second backup/parts system went with me. I eventually sold my system* to a > private collector. Unfortunately, I never had a chance to do anything with > it. > > Sellam > > * When my collection was effectively stolen, the console was taken by the > scrappers but I retained the CPU cabinet. I eventually sold the CPU to the > private collector, and I more recently learned he was subsequently able to > recover the console from the said scrappers and reunite the parts to make > the system whole again. In any event, it was due some parts and much > effort to be made working. >
[cctalk] Re: Intel 8086 - 46 yrs. ago
> On Jun 10, 2024, at 12:18 PM, Joshua Rice via cctalk > wrote: > > On 10/06/2024 05:54, dwight via cctalk wrote: >> No one is mentioning multiple processors on a single die and cache that is >> bigger than most systems of that times complete RAM. >> Clock speed was dealt with clever register reassignment, pipelining and >> prediction. >> Dwight > > Pipelining has always been a double edged sword. Splitting the instruction > cycle into smaller, faster chunks that can run simultaneously is a great > idea, but if the actual instruction execution speed gets longer, failed > branch predictions and subsequent pipeline flushes can truly bog down the > real-life IPS. This is ultimately what led the NetBurst architecture to be > the dead-end it became. RISC can do pipelining much more easily (as Cray first demonstrated around 1964, with the CDC 7600). For one thing, "bypass" is doable, and widely used, in machines that use both pipelining and multiple functional units. I remember the SiByte 1250 and/or the Raza XLR (both MIPS64, early 2000s) but I assume it was done well before then. > DEC came across another issue with the PDP-11 vs the VAX. Although the > pipelined architecture of the VAX was much faster than the PDP-11, the actual > time for a single instruction cycle was much increased, which led to > customers requiring real-time operation to stick with the PDP-11, as it was > much quicker in those operations. This, along with it's large software > back-catalog and established platform led to the PDP-11 outliving it's > successor. Josh Rice That reminds me of the Motorola 68040. I did the fastpath for an FDDI switch (doing packet switching in software) on one of those. I discovered that the VAX-like addressing modes that look so nice on the 68040 takes a bunch of cycles, but there was a "RISC subset" using just the simplest addressing modes that would produce single cycle execution. So I limited my code to just those. The other weirdness was branch prediction. The 68040 had no branch prediction cache, instead it would statically predict all branches to be taken. Note the difference from the usual practice, which is to predict backward branches as taken and forward ones as not taken. No problem either way, but it just meant that the assembly code looked a bit odd because an if/then/else block would have the unlikely case immediately after the branch (fall through, not the predicted case) and after that the likely case (branch taken, as predicted). It was fun to do 60k packets per second on a 25 MHz processor... paul
[cctalk] Re: Intel 8086 - 46 yrs. ago
It's interesting and probably indicative of some mindset where a discussion of the evolution of a given architecture is being discussed that specific technical aspects are most often mentioned, even though most of those are holdovers from the 1960s, just made smaller. My take is "why were these advancements necessary"? In other words, what parallel non-CPU/societal developments caused the shift in thinking? I recall that when the 8086 was announced by Intel, it wasn't the first 16-bit CPU by a long shot, nor was Intel doing a hard-sell on it. 8-bit in the personal computer still reigned supreme and the prospect of a 64KB 16-bit system costing considerably more than a similarly-performing 8 bit system wasn't particularly attractive. What was the catalyst? My .02 on the matter, FWIW. --Chuck
[cctalk] Re: Intel 8086 - 46 yrs. ago
On 10/06/2024 05:54, dwight via cctalk wrote: No one is mentioning multiple processors on a single die and cache that is bigger than most systems of that times complete RAM. Clock speed was dealt with clever register reassignment, pipelining and prediction. Dwight Pipelining has always been a double edged sword. Splitting the instruction cycle into smaller, faster chunks that can run simultaneously is a great idea, but if the actual instruction execution speed gets longer, failed branch predictions and subsequent pipeline flushes can truly bog down the real-life IPS. This is ultimately what led the NetBurst architecture to be the dead-end it became. DEC came across another issue with the PDP-11 vs the VAX. Although the pipelined architecture of the VAX was much faster than the PDP-11, the actual time for a single instruction cycle was much increased, which led to customers requiring real-time operation to stick with the PDP-11, as it was much quicker in those operations. This, along with it's large software back-catalog and established platform led to the PDP-11 outliving it's successor. Josh Rice
[cctalk] Re: Intel 8086 - 46 yrs. ago
On 10/06/2024 00:28, ben via cctalk wrote: The CPU Price it keeps going UP ... :( 8008 $25 1975 8080 $75 MITS kit 1975 8088 $125 386 $130 (286 $20) Hardly, you can pick up a new CPU today for less than $50. It's not going to be particularly fast, but it'll run circles round most decade old CPUs. I think the biggest change (other than speed, word length etc), is number of SKUs. For desktop systems, there are dozens of different SKUs per microarchitecture, each with varying cache size, core count, clockspeed, and present/absent integrated graphics. In the server space, the varying SKUs are amplified, with number of PCIe lanes, socket support etc almost multiplying the number of SKUs by an order of magnitude. Josh Rice
