test-drb July 2007

test-drb@ccmp.vtda.org

189 participants
323 discussions

by aek＠bitsavers.org

http://pullmoll.stop1984.com/alto/ Juergen has made a lot of progress in the past month. There are some small movies up now of the simulation running games with user loaded microcode.

17 years, 5 months

Free Commodores near Seattle (Seabeck), WA

by tosteve＠yahoo.com

Do not email me, see email address below: I have several old Commodore computers that are headed for the junk-heap unless I can find an appreciative collector. I have two VIC 20's, at least two C64s, and one C128. I don't know if ANY of them still work. I think I have some Commodore peripherals too. There may be a Commodore printer as well. I want nothing for them except shipping. If you are interested - or you know someone who is, let me know and we will work something out. Bill Sipple sipplewg at wavecable.com Seabeck, Washington, USA (98380) --------------------------------- Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.

17 years, 5 months

neon glow lamps (was TTL homebrew CPUs)

by dkelvey＠hotmail.com

>From: Brent Hilpert <hilpert at cs.ubc.ca> > >dwight elvey wrote: > > > > As a note on the dekatron, these were used in some of the early > > HP counters. They were used as the first, or highest frequency, > > state of the counters. They were quite fast! > > Dwight > >I beg to differ on this. I have a couple of dekatron counters and they >only seem to be good to some 10s of KHz (unless of course, you mean that >that >was pretty fast for the time). Interestingly, one of these counters uses >two >types of dekatrons, the only obvious difference between them being the >colour >of the glow and the part number. The ones in the slower speed decades are >the >usual neon glow, in the higher speed decade a purplish glow (xenon?). I >presume >the purplish glow gas ionizes faster than neon. >I should try to ascertain more accurately the max rate of the purplish deks >but haven't yet as one of the two in the unit is failing. > >I haven't seen dekatrons in HP counters, I believe their first counter was >the >524A and, unless it was radically different than the 524B/C/D, didn't use >dekatrons. Certainly the rest of the 520 series was vacuum tube flip-flops >(AC-4 modules). Hi Bret I recall that is was an HP counter. I don't recall the fastest count but it was on the order of either 10KHz or 100KHz. I don't think it was less then that but it may have been 1MHz. I recall that like many of the HP counters of the time, the other decades were the inline 10 ea bulbs. I don't recall if these were neon or incandescent but I think they were neons driven by dual triodes. I do believe that the ring counter did have a purplish glow. Dwight _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migrati…

17 years, 5 months

Lilith computer running !

by jos.mar＠bluewin.ch

My interest in the Lilith computer has been restarted after some recent post to a.f.c. ( what a mess a.f.c. is...) I put in some extra effort and was rewarded with a Lilith that booted up into its Medos OS ( version 5.2) The last time this particular machine booted its OS was in 1990 . Which means that there is at least one machine with a complete set of microcode and higher layers avaliable. The machine remains VERY temperamental : Most attempts to boot end in disk softread errors, resetting the Lilith involves power cycling ( I looked for signs of a startupcircuit, could not find any ) Probably some diskplatter / head cleaning is due, not something I look forward too. And then there is the task of rescuing the data : with at single RS232 channel, no software and a flat directorystructure with over 500 entries, this looks also to be quite a task. That's right, the Lilith does not have a hierarchical filesystem ! It does have ethernet, but it is the very old ( first ?) 3MB standard. AFAIK it cannot be interfaced to something more recent. Jos

17 years, 5 months

MODCOMP II Revisited...

by lbickley＠bickleywest.com

My excitement over getting my MODCOMP II running in June (reference post attached) - was somewhat "premature". The MODCOMP II performed well - and then started having intermittent failures. I observed that many of the failures seemed to be the result of badly seated chips. I thought that a bit strange, since I had checked them all as part of the restoration process. As time went on, the system became even more dysfunctional - until it wouldn't run even the most rudimentary programs. I checked with a former MODCOMP hardware support person - and he asked: "What brand were the failing chips you've found so far?". I hadn't even thought about that. He said "Let me know after you check - and I wouldn't be surprised if they were all TI (Texas Instruments)". I did check - and virtually 100% were TI chips. Factoid: Many TI chips produced during 1975-77 period had very thin "legs" and poor tinning. When they were wave soldered, the solder offered them protection. However, when they were socketed (as in the MODCOMP) they had very little protection from the environment. They would rust and eventually fail. He suggested that I just replace all the TI chips in the MODCOMP if I wanted a reliable system. I decided that was too "radical". So armed with a logic analyzer and scope, I began to debug the MODCOMP - one chip at a time. After finding 20 or 30 bugs - ALL of which were TI chips - I finally "relented". I have now replaced about one hundred and fifty TI chips in the Modcomp's CPU and memory planes. I'm about 3/4 of the way through the process - and the MODCOMP is becoming very reliable. It will run basic memory diagnostics by the hour without failure. Final thoughts: The "badly manufactured" TI chips turned out to be a lot more fragile than I had originally supposed. When I removed many of them from their socket, their legs would simply fall off. It wasn't unusual to have two or three legs fall off one chip! Some were incredibly rusty over their entire surface - which wasn't at all obvious looking at them from the top. The MODCOMP sockets were "good news - bad news". Bad, because the sockets exacerbated the TI chip manufacturing issue - and good, because they made the chips easier to replace! Regards, Lyle ---------- Forwarded Message ---------- Subject: MODCOMP II Rescue Revisited... Date: Monday 04 June 2007 21:06 From: Lyle Bickley <lbickley at bickleywest.com> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> A number of you probably remember me "announcing" in Jan, 2007 that I had rescued a MODCOMP II/12 from a lab here in Silicon Valley. The link for that is below (sorry, it's slow - the pictures are large). http://bickleywest.com/modcomp.htm After a lot of work cleaning up both the CPU and I/O chassis I began checking out the system. It turned out that the I/O chassis was in pretty bad shape. I went back to the lab facility where I found the MODCOMP II - looked through several more buildings - and found another lone MODCOMP II I/O chassis. I went through the "salvage" process again - and finally picked it up about a month ago. It was in a lot better shape than the original I/O unit. And the really great news - it was an identical configuration to my original I/O chassis. After cleaning it up, doing all the usual capacitor, power supply checking - I powered it up - and everything "looked" good - and no bad "cooking" smells ;-) I cabled up the CPU and I/O unit, powered 'em up - and to my amazement the front panel controls seemed to work O.K. I then did the usual hand memory tests - and core memory worked O.K. every location I tested. I then wrote a bunch of small diagnostics (in machine code) - and found that I/O was not easy to code - but I did enough to check that the console in/out ports worked O.K. Today I loaded diagnostic monitors, and diags - and most of the system - including I/O is working! The really good news is that all 64K (words) of core memory passed the long manufacturing memory diagnostic - which even tests for "hot cores" failing. It's been months in the making this critter come alive - but it sure feels great when the diagnostics tell you that you are on the right track :-) Cheers, Lyle ------------------------------------------------------- -- Lyle Bickley Bickley Consulting West Inc. Mountain View, CA http://bickleywest.com "Black holes are where God is dividing by zero"

17 years, 5 months

JFETs in logic circuits

by cclist＠sydex.com

Someone, about a week ago, asked about JFET use in logic circuits. It turns out that the questioner was a bit ahead of the times. There's a relatively new device called a G4-FET that's made up of a MOSFET and a JFET, has 4 gates and can be used to make a 3-input NOT- majority logic element. Read about the construction here: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/10067/1/02-2177.pdf And its use in logic here: http://www.freshpatents.com/Universal-programmable-logic-gate-and- routing-method-dt20070111ptan20070008013.php Cheers, Chuck

17 years, 5 months

Looking for something to put in this space (PDP-11)

by charlesmorris＠hughes.net

Here's a pic of my PDP-11/23+ system with two RL02 drives. There is an empty space about six inches high below the second drive, as you can see. (In the rear is a power controller and a panel with 16 serial ports, although I don't have anything to hook up to them for now). http://i18.tinypic.com/4pc8sux.jpg I'm looking for either a blank panel to cover the hole, or maybe an interesting device I can fit there, if anyone has a suggestion? thanks Charles

17 years, 5 months

UK computer history gets new home

by RodSmallwood＠mail.ediconsulting.co.uk

There is quite a lot more of what happened re the Japanese codes in the various books that have been published. The breaking of JN25 by Rochfort to reveal the plan to invade Midway Island and the susequent loss of three carriers by the Japanese has been the subject of books, TV programmes and films. Another coup was the decoding of Yamamoto's inspection plans and the shooting down of his plane at extrame range by US twin engined Lockheed Lightning fighters. Some of the Japanese codes were quite weak due the mistaken belief that the Japanese language and Japanese morse code provided a level of protection. (They didn't!!) As to the Germans. The Abwehr did break the allied convoy code and a forward mobile unit in North Africa had considerable success with Montgomery's radio traffic. They did that is, until overrun and captured. Rod Smallwood -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of William Donzelli Sent: 13 July 2007 00:53 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: UK computer history gets new home > What gets me a little is the comparative lack of recognition that all > the others working on projects like Colossus have received; Turing > still gets publicity (rightly so), but not much ever gets said about > all the others who were contributing effort and ideas. This is a very common problem, especially when dealing with wartime technologies and who gets the credit. Two of the big factors are state secrecy, and the old saying "the victor writes the history books". For the former, one can look at the breaking of the Japanese codes (purple being the most famous). The Enigma and Lorenz stories are now pretty much out in the open and declassified, but the Japanese stuff is still locked up in secrecy. Under the veil of secrecy, the guys that did the work can not get the credit. For the latter, one can see just how little (almost no) credit is given to the Axis powers. There is very credible evidence that Allied codes were broken during World War 2. It is likely the Germans had some sort of equivalent of Bletchley, but is probably forever lost. The Allies were not about to give credit to the Axis engineers. Many still will not. It is bothers you - then speak up. Give the guys credit. Spread the word. They deserve it. -- Will

17 years, 5 months

VCFmidwest v3.0 begins

by jwest＠classiccmp.org

Greetings folks... from West Lafayette, Indianna. The weather is awesome this morning, the day the festival begins. I arrived around 7:30pm local time last night and met up with Pat. He was able to get me into the exhibit area to set up my HP 21MX. I called a few people to see about dinner/drinks but was unable to rouse anyone by 10pm when I was free. I'm in the hotel room getting some documents together for handouts on the 21MX/E at the show (the poyner article as well as some technical spec sheets). I'll run to Kinkos a few blocks up the street and print them off momentarily. Then it's off to a big breakfast and then exhibit hall. Remember - doors open at 10:30am, speakers at 11am, and exhibits from 2pm to 6pm. I suspect that like in years past, most of us will head out to dinner this evening. Hope to see you at the show! Jay West

17 years, 5 months

Bringing up an Altair 680...

by wh.sudbrink＠verizon.net

I've just been given access to an Altair 680. It seems to be in excellent physical condition (no rust, corrosion, dents... just some dust). Has not seen power in many years. All of the ICs are socketed. Due to the fact that the PS is incorporated onto the main board, I was planning the following: 1) Remove the main board from the case, detaching it from the front panel board. 2) Remove (carefully noting their positions) all of the ICs from the main board. 3) Attach dummy loads (24V light bulbs) to the PS at convenient locations. How many should I use? 4) Attach to AC power in this state. Assuming nothing pops, check DC voltage (voltages?) with a scope. Assuming DC looks good, allow to warm up for a few hours. 5) Scope check DC again. Power down allow to cool for a few minutes. Repeat steps 4 and 5 a few times (3? 4?). 6) If all looks good, reinstall all of the "easy to replace" ICs and do 4 and 5 again. 7) If all looks good, reinstall the rest of the ICs, restore the main board to the case and front panel. 8) Debug any logic problems (dead chips, opens, etc.). Does this look reasonable? Thanks, Bill No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.4/898 - Release Date: 7/12/2007 4:08 PM

17 years, 5 months

← Newer
1
...
14
15
16
17
18
19
20
...
33
Older →

Jump to page:

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 July 2007