Intersting. That was what powered my first unix box at home. A
Cosmos CMS-16/UNX. 8 MHz MC68000. (And later computers at home with
the MC68010 and MC68020.)
That would certainly get room for more "feet" of memory
(measured in length of punched tape used to store the program, and 10
bytes/inch, or 120 bytes/foot. A lot of the LSI-11's address space was
taken up with ROMs for the OS, and not much space left to expand. IIRC,
the quad-wide LSI-11 could not address more than 32 K words (64 K bytes)
total. The MC68000 could access up to 16 MB. So, assuming that the
firmware expanded to a full 64 K bytes (added features), and perhaps to
128 K bytes (less efficient coding or more on-screen prompting text),
that still leaves most of the 16 MB for part programs. O.K. 512K for
the firmware, and another 512K for the memory mapped I/O ports to leave
15 MB for the part program would translate into 131,072 "feet" of
memory, or about 24.8 *miles*. I never did bother measuring how much
punched tape a 10-1/2" reel could handle, but I would be surprised to
see it holding more than a mile of tape. So there would be no need to
fill the entire available address space with RAM. :-)
Oh yes -- and to put it in perspective, my Emco-Maier
Compact-5/CNC lathe runs from a single Mostek 6502 -- again 64K bytes
maximum address space and a much less capable CPU.
[ ... ]
[ ... ]
Well ... have you been able to compare the behavior of *all*
axes with similar motion commands? Each axis has its own power supply
(a single phase from a three phase transformer) and has its own
saturable reactor, so you could perhaps be measuring a different axis
than you are exercising.
You can command each axis to move a specified distance at rapid
move rate from the control pod. I forget the sequence of commands, but
you select the axis with a three position rotary switch, the distance
1", 0.1" 0.01" or 0.001" by another rotary switch, and then command the
move by pressing one of those switches as a pushbutton (which it can be
as well as a rotary switch). This is in manual mode, obviously. And it
does not require loading a program.
Does yours have the punched tape reader? Do you have access to
something which will punch the tape -- a Teletype ASR-33 will do among
other things, since the codes used are ASCII.
Well ... the monitoring really needs a test program performing
the moves. You'll find the saturable reactor acting as a reactor at a
stop, or at a certain range of slow speeds, but as the step rate gets
above a certain threshold, it will go to the saturated mode so you get
more voltage from the power supply to the driver transistors.
If yours is a new enough machine, you can probably unplug the
axes stepper motors from the hinge-out heat-sink panel (IIRC, down near
the bottom), while the really early ones require removing wires one at a
time from a terminal strip (again IIRC).
My machine is being converted to servo motors with the EMC
program to control it (and I'm hung up on making the replacement belt
housing and motor mount for the Y axis). The stepper machines have a
recess in the knee for the stepper motor, but the servo motor is much
longer and has to pass beside the knee instead, so an angled belt
housing and mount instead of straight up and down.
Less than 1K byte. :-) As I just mentioned in another branch of
this thread, a "foot" is 120 bytes on punched tape. AFIK, they *still*
rate them in feet, even though they don't have punched tape readers any
I can't go down and check anything on what is left of mine
because I'm in the recover phase from my first cataract surgery, and
under rules of "don't pick up anything over twenty pounds". Then there
will be a short while when I can pick up heavy things again, and then
I'll go in for the second eye. (FWIW, the improvement in the first eye
is *amazing*. I had not realized how much I had lost.
I taught myself assembler on a MC68008 machine and thought it was great,
a bit later we covered it at college where we were taught 6502
assembler, that was painful going from byte, word, and long word
instructions to byte. For some time I would occasionally use Motorola op
codes and wonder why it wouldn't assemble. Did some useful coding on the
6502 but it was arcane compared to the MC68000. The article published by
Motorola about the designing of the MC68000 made interesting reading.
David Billington fired this volley in
Heh! The 6502! The Commodore-64! An associate and I wrote the DOS and
accessories for the Lt. Kernal hard-disk DOS for the C64 and C128.
[ ... ]
[ ... ]
And being stuck with index registers which were only 8-bits
long, and a stack pointer which was stuck in the second 256-byte page of
I much preferred the 6800, which had true 16-bit index
registers, and a true 16-bit stack pointer so you could put the stack
wherever you wanted.
The 6809 later had instructions for treating the two 8-bit
accumulators as a single 16-bit one, as well as indexing off both stack
pointers, both index registers, and the program counter, making
position-independent code a lot easier to write. (And OS-9 *required*
position-independent code as well as reentrant code.)
Take a look at the 6809 sometime. It is not a 68000, but is
more of a 16-bit processor than the Intel 8088 was. :-)
The problems are resolved.
The replacement of the blown fuse, together with manual cleaning and
lubrication of the X axis screw and the same with the Z now has the
machine running rapids on all axes.
The machine has obviously sat for sometime.
Thanks for all the input.