test-drb

test-drb@ccmp.vtda.org

101090 discussions

First Retail version of MS-DOS was Re: Ibm s-100 system?

by cctalk＠ibm51xx.net

I am not sure if 5.00 was the first Retail version. I know that for fact there is a 3.2 version released in the blue plexiglass Microsoft retail packaging. The 4.x versions are usually gray boxed with some having OEM/new computer stickers. -Ali

9 years, 7 months

Ibm s-100 system?

by billdegnan＠gmail.com

Byte Jan 1981 page 204 refers to an IBM S-100 microcomputer system IBM demoed in Europe. Anyone here seen this machine or heard about it? Bill Degnan twitter: billdeg vintagecomputer.net

9 years, 7 months

WTB: Sun Voyager Bag, Oberheim Synthesizer

by ethan＠757.org

Two things on the hunt list: 1. Sun Sparcstation Voyager bag (the bag to put it in) 2. Oberheim Matrix 6, 6R or 1000 synthesizers.

9 years, 7 months

bit slice chips (was Re: Harris H800 Computer)

by spacewar＠gmail.com

On Thu, Apr 21, 2016 at 12:07 AM, Raymond Wiker <rwiker at gmail.com> wrote: > I was a bit surprised to see that it used 2901 with a date code of 1985 - > the 2901 was introduced 10 years before. The 2901 was the workhorse bit-slice data path chip for many years. The A, B, and C suffix parts were progressively faster variants introduced later. Eventually there were CMOS versions, and 16-bit-wide versions. While AMD introduced the 2903 and 29203 as functionally improved (but not directly compatible) 4-bit parts, they weren't nearly as widely used as the 2901. Most other bit-slice parts can be considered "also-ran" at best, with the Intel 3001 and 3002 probably being the next most successful. MMI tried to beat AMD to market with the 5701/6701, which was very similar to (but not compatible with) the 2901, but they were late to market and AMD won. Motorola offered the MC10800 ECL bit slice series, which were significantly faster at introduction than the contemporary Am2900 parts, but AMD kept introducing faster 2901s. Some later 2901 variants from AMD and National Semiconductor actually used ECL internally, but had normal TTL I/O, but the CMOS that followed were even faster than those.

9 years, 7 months

bit slice chips (was Re: Harris H800 Computer)

by jnc＠mercury.lcs.mit.edu

> From: Jon Elson > The 11/45 and 11/70 are mostly the same processor. ... > the data paths boards and FPU are the same part numbers 'Yes' to the FPP (well, there are two versions, the FP11-B and FP11-C, but they are both identical in the two machines). 'No' to the data paths, though: e.g. the M8100 in the /45 (the board with the 74S181's on it) is replaced by the M8130 in the /70. The two are _very_ similar, but I suspect not interchangeable (examing the prints shows minor differences). AFAIK, the only non-FPP board in the CPU which is interchangeable between the two machines is the M8132 (instruction register decode & condition codes) - and only to the KB11-D /45 variant, not the -A. {As always, just want to be accurate! :-} Noel

9 years, 7 months

bit slice chips (was Re: Harris H800 Computer)

by jnc＠mercury.lcs.mit.edu

> AFAIK, the only non-FPP board in the CPU which is interchangeable > between the two machines is the M8132 (instruction register decode & > condition codes) So it seems like there's an(other) error in the DEC documentation. If one looks at 11/70 Maintenance Manual (EK-11070-MM-002), it says (pg. 1-3) that the KB11-C (11/70 later CPU) contains an M8133 ROM and ROM Control board, the same as the KB11-B (earlier CPU, pg. 1-4), _but_ ... The KB11-C prints include the drawings for the M8123 (also used by the KB11-D, the later /45 CPU). Other manuals confirm that the KB11-C uses the M8123 (see, e.g., the KB11-A,D Maintainence Manual, EK-KB11A-MM-004, pg 1-1). I _thought_ the KB11-D used two of the same boards as the KB11-C, but then, when I went to check, to be sure I had the correct info (before sending out my email intended to "just want to be accurate", sigh), I relied on the DEC manual... :-( Oh well, that's what I get for relying on DEC manuals! :-) Noel

9 years, 7 months

Accelerator boards - no future? Bad business?

by jnc＠mercury.lcs.mit.edu

> From: Jules Richardson > I can't see the point in modern upgrades .. At the point where people > start adding emulated storage, USB interfaces, VGA display hardware > etc. it stops being a vintage system and starts being a modern version > which just happens to still have a few vintage parts. I agree with you to some degree, but... Some components are just hard/impossible to find now - like old original disk drives (seen any RP0x's for sale recently?), or Able ENABLE's - and in any case running the disks is both non-trivial (power/heat) and risks damaging what are effectively museum pieces. So one is left with the choice of modern replacements, or nothing. And I'm not capable of building an RP0x, but building a board that uses an SD memory card to emulate an RP0x, that's within my grasp. And it takes a lot less room and power, to boot. Also, the _systems_ were designed to have upgrades installed, and did, BITD - many of which were not conceived when the machine first came out. E.g. our 11/45 at LCS wound up with 1MB MOS memory boards in it (much smaller and less power-hungry than the original memory), and high-speed LANs, neither of which were ever envisaged when the machine was built. I don't see that building, say, a UNIBUS USB interface now is really that different from building a high-speed LAN board BITD. I do agree that if you replace stuff that _is_ still available and perfectly functional (e.g. QBUS memory and processors), you might just as well run a simulator. But there's a lot of stuff that's not in that category (above). Noel

9 years, 7 months

CDC 6600/Cyber 73 Memories - WAS: Harris H800 Computer

by rickb＠bensene.com

Mark J. Blair wrote: > I also seem to remember an operator's console with two round CRTs on it, > but I might have fabricated that memory from whole cloth. > I think that you were remembering the console of one of the Control Data 6000/Cyber-70 series computers that you may have seen somewhere. This series of Control Data machines were famous for their consoles with two large, round, green-phosphor monitors that used vector drawn-characters (generated by one of the Peripheral Processors). Most of the normal system screens were all text, but there were some special programs written (including a nice graphical chess game, a little program that would put up eyes on the screens that would look around and blink, and some others that don't come to mind at the moment. I operated one of these systems (a Control Data Cyber 73 -- http://bitsavers.trailing-edge.com/pdf/cdc/cyber/brochures/Cyber70_Mod73 _Feb71.pdf) at Tektronix in Beaverton, Oregon, from 1977 through around 1980. It had two CPUs, 131K (60-bit words) of core, ECS (extended core storage), and 20 Peripheral Processors, a combined punched card reader/punch, something like 12 "washing machine" type multi-platter cartridge disk drives (that held something like 300 MB each), two 9-track tape drives and one 7-track tape drive. It also had a big chain printer that was noisy, but pretty fast. The machine had a channel interface to a Modcomp communications processor (with communication maintained by one or more Peripheral Processor programs), that provided serial I/O to terminals scattered all over the company by some kind of serial concentrator that I can't remember. There was also a big modem pool for dial-in use. The system ran a locally-modified version of the Kronos Timeshared operating system. The system was used primarily by engineering departments (research and product development) for CAD and CAD software development, circuit simulation (SPICE), cross-assembling microprocessor code, and mathematical modeling. The machine was an all-transistor design, based on the CDC 6600 processor. It was liquid cooled, and had a large cooler unit that sat with the machine that cooled the coolant (water) and circulated it through the chassis, venting the heat (which was substantial) through a special venting system. I remember the CDC Field guys talking about horror stories when there were leaks in the cooling system. We never had any problems while I was there. One day I was at the console when one of the big high-voltage rectifier tubes that were in the console decided to short. I was watching one of the system monitor displays, and suddenly I saw the display collapse into a single very bright horizontal line. I noted that the other display also did the same thing. I also heard a funny noise that sounded kind of scary, so I started to push my wheeled chair away from the console, but not soon enough to avoid a shower of sparks and even some molten metal that spewed out from the console. I had a few small burns on my arms, and one little blob of molten metal burned a hole in my pant leg. One of the other operators in the machine room managed to hit the power switch for the console and shut it off. Then the fire suppression alarm went off indicating that the Halon was going to dump soon, so he ran back and hit the override since the sparking and smoke had settled once the power was off. Despite this, the fire department showed up (the fire suppression system in the computer room had a direct line to the fire department), and we had to tell them it was a (semi) false alarm. The machine kept running just fine, and we were able to keep tabs on it with a serial terminal hooked up to the machine that had a program running that kind of emulated the console displays. The CDC guys were there very quickly, and ended up having to replace two (IIRC) big rectifier tubes, and one burnt up power resistor. When they powered it up, the screens came up just as they were before the event occurred, and all was well. I really enjoyed those days. The machine was really cool, and I have a lot of great memories of those times. The Living Computer Museum (http://www.livingcomputermuseum.org) in Seattle, WA, has rescued a smaller version of a system like this based on the 6500 processor that is undergoing restoration. Sorry for changing the subject (but at least I updated it in the Subject: line). -Rick -- Rick Bensene The Old Calculator Museum http://oldcalculatormuseum.com

9 years, 7 months

VCF East pictures

by cctalk＠ibm51xx.net

> Simplest just to read the article (it's not very long): > > http://www.swtpc.com/mholley/PopularElectronics/Feb1975/PE_Feb1975.htm > Thanks Bill. That is pretty cool! -Ali

9 years, 7 months

Z80 /WAIT signal question

by spacewar＠gmail.com

A friend building a Z80 system asked me about whether the Z80 /WAIT signal has any effect during machine cycles that aren't memory/IO/intack cycles (i.e., neither /MREQ and /IORQ asserted). The user manual only describes the use of /WAIT for adding wait states, so I expect it probably only affects mem/IO/intack cycles, but I can't find anything definitive in the user manual. I'm hoping someone can save me the time of hooking up a logic analyzer and running the experiment. Thanks! Eric

9 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb