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
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
....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>
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.
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.
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.
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/
/************************************************************/
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
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
