test-drb January 2006

test-drb@ccmp.vtda.org

240 participants
511 discussions

by rcini＠optonline.net

All: I received an interesting message from Forrest Mims today so I thought I'd pass it on: Rich From: FMims@ To: rcini@ CC: forrest.mims@ Subject: Forrest Mims to Rich's classic computing lab Date: Tue, 17 Jan 2006 11:12:28 EST Dear Rich, Great web site. Glad to see what you are doing. Regarding the date MITS was founded, our first meeting was in Ed Robert's kitchen at 4809 Palo Duro, NE, in Albuquerque shortly after my first article on a model rocket light flasher was published in the September 1969 issue of MODEL ROCKETRY. Our first product was the TLF-1 model rocket light flasher, which was based on my design. We incorporated in January 1970, each of us providing a $100 check for startup funds. My check was written in the lawyer's office. It is dated "16 Jan 1970." Ed may have said we began in 1968 because he had founded Reliance Engineering earlier. We had been talking about starting a company in 1968, also, but did not have a reasonable product idea until my 1969 light flasher. I'm sending these details because of the interest in the history of MITS and a forthcoming museum exhibit in Albuquerque that will cover the history of the PC. Please feel free to use any of this if you like. And best wishes for your web site. Best regards, Forrest Forrest M. Mims III www.forrestmims.org <http://www.forrestmims.org/> www.sunandsky.org

18 years, 11 months

Recent history: Apple/Sun merger

by news＠computercollector.com

http://www.theregister.com/2006/01/12/sun_apple_snapple/ "Sun Microsystems tried to acquire Apple once and then almost merged with Apple on two other occasions, according to Sun co-founder Bill Joy." ----------------------------------------- Evan Koblentz's personal homepage: http://www.snarc.net Computer Collector Newsletter: >> http://news.computercollector.com Mid-Atlantic Retro Computing Hobbyists & Museum: >> http://www.marchclub.org >> http://groups.yahoo.com/group/midatlanticretro/

18 years, 11 months

Core overheating

by Billy.Pettit＠wdc.com

cclist wrote: On 1/16/2006 at 7:44 PM Philipp Hachtmann wrote: >What do you think? Do I have to be careful? I never thought I could >program my computer to death. >And such problems aren't mentioned in my programmers' guide and operation >manuals. IIRC, it was indeed a problem on the CDC 7600 PPU's. A very tight (e.g., UJN 0) loop would cause core to overheat. The 7600 added a duty-cycle integrator so that repeated accesses to the same location in a short amount of time would actually slow things down a bit to avoid that problem. But the 7600 was a very fast machine for its time. Cheers, Chuck Okay, Two points. Halt and Catch Fire was a fictious command. This was sort of an in-group joke. I first saw them described when the IBM 360 was announced in 1963. But they were already old at that time. I came across one of the lists a few months ago in a clean up. Others included: Read and Stretch Tape; Read Card and Shred; Seek Disk and Crash; Print Line and Jam Paper (w./ a variation of Print and Tear Ribbon); Type Wrong Character; Jump To Illegal Address; etc. You can probably create your own. In fact Datamation ran a humor article and asked for creative commands. They published some of the best ones. Any old timer refers to this class of humour as Halt and Catch Fire, since it was usually first on the list. My favorite was Execute and Hang, since it happened often in CDC 3000 machines. We called them Blue Sky commands since the machine went into an undefined state. I'll bet that some of the other old timers better organized than I, still have those lists and will reply with them. Second point. I worked on a lot of 7600s. And I was on the team that designed the Cyber 17X replacements. I never heard of one catching fire. The core ran at 27.5ns cycle time (actually, that was when the data was available - you still had to restore it, since core read out switched the state of the core). That was fastest that core ever was used in a commercial product. At least we advertised it that way. But, if you have a 7600 logic module, look at it closely. The modules is aluminum heat sink on 5 sides - the connector is on the 6th side. It screwed into a solid "cold bar" that had Freon piped through it. There were "cold plates" inserted between modules. All of this removed the heat from the module quickly. The PCBs are actually in a miniature refrigerator. The circuits had thermal compensation built in for the memory modules. Seymour had thought of tight loops and used them to test memory during design. Many of the field memory tests were coded to as tight as possible to stress the memory. Halt and Catch fire was a joke. I never heard of 7600 catching fire. We had a chassis melt once, when the refrigeration stopped and the fail safes all failed. But no fires. Billy

18 years, 11 months

Stumbled across Ed Thelen's site today

by legalize＠xmission.com

....while looking for maps of Nike missile bases :-) At any rate, he's got a lot of computing ephemera online that doesn't look like its duplicated elsewhere. <http://ed-thelen.org/comp-hist/on-line-docs.html> This is probably "old news" to you guys, particularly since Al Kossow is quoted at the bottom of the page, but I found it cool anyway. :) -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

18 years, 11 months

RK07 questions

by henk.gooijen＠oce.com

Ok, I was so curious that I did the test with the servo head disconnected. It is sure a different movement! First let me describe the head movement in more detail. In stand-by, the heads are in what I call the "home" position. When the movement starts, the heads come out of the home position at a moderate speed, and when the heads are at "track 0", the speed drops and the heads move at a slower speed towards the centre of the pack. Then the movement stops, and starts at that same slow speed towards the home position. However, the heads stop at what I call that "track 0" position, and stay there until I press the LOAD button again. Then the heads move *fast* to the home position. Now with the servo head disconnected ... To quote 'Allo Allo': "listen very carefully, I will do this only once", well sort-of :-) The heads move at the moderate speed to "track 0", but stay at that speed while the heads move to the centre. That movement now looks a lot faster! At the centre the movement stops, and the heads move at that speed (or was it even faster?) not to the "track 0" position, but to the home position. The FAULT light is now ON. I reconnected the servo head. Time to sleep a night to get new fresh insights ... - Henk. This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message. Thank you for your cooperation.

18 years, 11 months

RK07 questions

by henk.gooijen＠oce.com

Hi all, I am working on the last peripheral device connected to my 11/34, two RK07s. This will be my first experience with RK07 drives, so I have a few questions. I installed the RK611 in the system (in an expansion box) and made sure that the UNIBUS is OK. The 11/34 starts, and I can boot RT11 from DL0:. ".SH DEV" shows that the DM.SYS driver is installed. However, after loading a pack the RT11 commands ".DIR DM0:" or ".INIT DM0:" report an error. I must say that the READY light did not turn ON on the drive. I switched the 11/34 OFF, because I think I need to take a closer look at the RK07 drive itself first. Here is what I did and saw. I removed the metal cover at the top-rear side. Now you can see the big magnet and the head assembly. I first checked the "emergency retract" mechanism. When you push down the lever that locks the heads, and gently push the head assembly forward toward the cartridge compartment, the heads are pulled back as soon as the little microswitch is (dis)engaged. Then I loaded a pack and pushed the LOAD button. After some 20 seconds the disk has spun up (I assume), because the heads start to move. The heads first move at a moderate speed toward the centre of the cartridge (I would say a full travel), stop, and then move back at that same speed, but not completely to the home position. Again, I *assume* that the heads detected track 0 and stay there. However, the READY lamp does not go ON. It could not, because the lamp was defective :-) After replacing the lamp with a checked-good lamp, I repeated the exercise. The heads show the same movement, but the READY light stays OFF. 1. Is that head movement behaviour correct? I will try to make a movie of the movement this weekend ... 2. What would the head movement be if the pack was bulk-erased? 3. Should the READY lamp go ON? An other thing I noticed. As the 11/34 is OFF, there is no controller connected to the RK07 drive. OK, it is, but not powered. With the RL drives the FAULT lamp will be ON if the controller is not powered. Is this the same for the RK07? The RK611 controller is not powered, but the FAULT lamp stays OFF. I did check that the lamp is OK. Is this correct behaviour? thanks, - Henk, PA8PDP. This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message. Thank you for your cooperation.

18 years, 11 months

AC power on front panels

by henk.gooijen＠oce.com

Thanks for that remark, Pete! I did not want to go into "pedantic" mode, but I was indeed thinking about the capacitors in the EMI filter, but thought that chances are very slim that they fail. But they can! Once in ten years is good, except if it's *your* filter that fails :-) The caps in the EMI filter have a very small leakage current, so if you are 'energy-concious' pulling the plug is truely the only option. - Henk, PA8PDP. > -----Original Message----- > From: cctalk-bounces at classiccmp.org > [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Pete Turnbull > Sent: dinsdag 17 januari 2006 9:06 > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: AC power on front panels > > On Jan 16 2006, 13:59, Patrick Finnegan wrote: > > On Monday 16 January 2006 04:09, Gooijen, Henk wrote: > > > > I always pull the plugs on my PDP-11s, because the small > transformer > > > in the power controller is always connected. > > > > You could also just flip off the breaker on the power controller, > which > > disconnects everything* in the PCU from the mains. > > > > * Except for the EMI filter, inlet power cable, plug from the wall, > etc. :) > > I've had to repair 861 power controllers twice in the last > ten years or so -- once was indeed the EMI filter :-) > > -- > Pete Peter Turnbull > Network Manager > University of York This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message. Thank you for your cooperation.

18 years, 11 months

AC power on front panels

by rcini＠optonline.net

All: I'm playing around with my relatively new IMSAI and I was pondering the following. The unit is constructed with the front panel power switch unconnected and the corresponding terminals on the power supply board jumpered together. There is a mains switch on the rear panel which takes the place of the front panel switch. While for safety reasons I cannot disagree with the approach - it's plain stupid to put uninsulated mains voltage in a low-voltage area (and unpassable by UL evaluators I'm sure) - it detracts a bit from its use because you have to reach behind the unit to turn it on. Has anyone come up with an elegant solution to being able to use the front panel power switch while keeping it safe? I was toying with some sort of low-voltage circuit (small LV transformer and relay, with the front panel switch in the loop on the coil side). Another idea I had was to hot glue a dielectric insulator board (that gray cardboard kind of stuff) over the parts of the front panel that would be exposed. Ideas? Too much time on my hands? Rich Rich Cini Collector of classic computers Build Master for the Altair32 Emulation Project Web site: <http://highgate.comm.sfu.ca/~rcini/classiccmp/> http://highgate.comm.sfu.ca/~rcini/classiccmp/ /************************************************************/

18 years, 11 months

Speaking of 6502s, was Re: 70's micros still available -

by pete＠dunnington.plus.com

On Jan 17 2006, 9:39, Graham Toal wrote: > > On 1/4/06, Tony Duell <ard at p850ug1.demon.co.uk> wrote: > > > What languages were available for the BBC Micro (without a second > > > processor[1]), I wonder. I know about BASIC, Pascal, Forth, Lisp > > > > There was an Acornsoft BCPL. > > There is known to be a Beebug C, but I never managed to track it down. > > > > The C I did manage to track down (not proper C but Small-C, and indeed > > only a limited subset of even that) was done by Dr. A. J. Travis. I > > wrote a project in this, and really liked it. > > COMAL was very nice. What BBC Basic should have been ;-) > > I presume you do know about Acornsoft C. (I did some of the QA > on that compiler) > > There was a LOGO of sorts, I seem to recall, but hard pressed to > remember any details. It may have been a hack job in basic actually. I have here BBC BASIC (at least five versions), COMAL, LISP, Acornsoft FORTH, FORTH79, and JBFORTH (from HCCS) (and there's at least one more FORTH), Acornsoft LOGO (two 16K sideways ROMs), Logotron LOGO (one 16K ROM), HCCS LOGO (also one 16K ROM), microPROLOG, various 6502 assemblers, Beebug C (on a disk here somewhere), Acornsoft C, and BCPL. I'm sure there are more. I keep my ROM images in separate directories, and "Languages" is one of the larger ones. "FilingSysts" is a similar size, there are some smaller ones, and of course the catchall "Utilities" containing everything from spreadsheets to printer utils to graphics extensions is the biggest. You might be surprised to know that "Comms", containing terminal emulators, is the next biggest, though. -- Pete Peter Turnbull Network Manager University of York

18 years, 11 months

deformatting floppies

by chrism3667＠yahoo.com

I would have thought it best to take a magnet to a hd disk before popping in a 720k drive to be formatted, but it seems to not have any (or much) effect. Even using a chunky rare earth magnet! Can someone explain? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 11 months

← Newer
1
...
22
23
24
25
26
27
28
...
52
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 January 2006