The Importance of Terminology's Quality

[John W Kennedy]

Re: The Importance of Terminology's Quality

Martin Gregorie wrote:

On Sat, 23 Aug 2008 00:06:28 -0400, John W Kennedy wrote:
>

>Martin Gregorie wrote:

>>Not necessarily. An awful lot of CPU cycles were used before microcode
>>was introduced. Mainframes and minis designed before about 1970 didn't
>>use or need it

>No, most S/360s used microcode.

>
I never used an S/360.
>
I thought microcode came into the IBM world with S/370 and Future Series
(which later reappeared as the AS/400, which I did use). Didn't the S/370
load its microcode off an 8 inch floppy?

Some did, but not all. The 370/145 was the first, and made a big splash
thereby.

As to the 360s:

20 (Incompatible subset) I don't know
22 (Recycled end-of-life 30) CROS
25 Loaded from punched cards
30 CROS
40 TROS
44 (Subset) None
50 CROS
60, 62, 65 ROS
64, 66, 67 ROS
70, 75 None
85 I don't know
91, 95 I don't know -- probably none
195 I don't know

CROS used plastic-coated foil punched cards as the dielectrics of 960
capacitors each.

TROS used little transformer coils that might or might not be severed.

ROS means it was there, but I don't know the technology.
--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only
the obeisance of others! Thus is bad government born! Hold in your
heart that you and the people are one, human beings all, and good
government shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)

[Martin Gregorie]

Re: The Importance of Terminology's Quality

On Sat, 23 Aug 2008 21:22:05 -0400, John W Kennedy wrote:

Martin Gregorie wrote:

>On Sat, 23 Aug 2008 00:06:28 -0400, John W Kennedy wrote:
>>

>>Martin Gregorie wrote:
>>>Not necessarily. An awful lot of CPU cycles were used before
>>>microcode was introduced. Mainframes and minis designed before about
>>>1970 didn't use or need it
>>No, most S/360s used microcode.

>>
>I never used an S/360.
>>
>I thought microcode came into the IBM world with S/370 and Future
>Series (which later reappeared as the AS/400, which I did use). Didn't
>the S/370 load its microcode off an 8 inch floppy?

>
Some did, but not all. The 370/145 was the first, and made a big splash
thereby.
>

...snip...

Thanks for that. As I said, during most of that era I was using ICL kit.
Microcode was never mentioned in the 1900 contect. Hoiwever, they had a
very rough approximation called extracodes. though they were closer to
software traps than microcode: if hardware didn't implement an op code
the OS intercepted it and ran equivalent code. This was used for i/o
operations and for FP instructions on boxes that didn't have FP hardware.
As a result all boxes executed the same instruction set. Some opcodes
might be very slow on some hardware but it would execute.

The 2900 series had huge amounts of microcode - it even defined both
memory mapping and opcodes. You could run 1900 code (24 bit words, fixed
length instructions, ISO character codes) simultaneously with 'native'
code (8 bit bytes, v/l instructions, EBCDIC) with each program running
under its usual OS (George 3 for 1900, VME/B for 1900).

The only other systems I'm aware of that could do this were the big
Burroughs boxes (6700 ?), which used a byte-based VM for COBOL and a word-
based VM for FORTRAN and Algol 60) and IBM AS/400 (OS/400 could run S/34
code alongside S/38 and AS/400 code). AFAICT Intel virtualisation doesn't
do this - all code running under VMware or any of the other VMs is still
running in a standard Intel environment.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[norseman]

Re: The Importance of Terminology's Quality

Arne Vajhøj wrote:

Paul Wallich wrote:

>Martin Gregorie wrote:

>>On Fri, 22 Aug 2008 22:56:09 +0000, sln wrote:
>>>On Thu, 21 Aug 2008 09:11:48 -0500, rpw3@rpw3.org (Rob Warnock) wrote:
>>>>sln@netherlands .comwrote:

....(snip)

I thought microcode was relative well defined as being the software
used to implement instructions that were not fully implemented in
hardware.
>
http://en.wikipedia.org/wiki/Microcode does not make me think otherwise.
>
Arne
--

http://mail.python.org/mailman/listinfo/python-list

>

=============== =========
Right on. Microcode is the CPU's macro(s).
Machine language is the bit patterns that cause whatever.
The CPU designer decides these.
Assembly is the human memory aid nmenonices assigned to the

bit patterns. This allows re-assigning bit patterns to the
nmenonices when changing designers. An Assembler usually
has a few computing aids so the poor human doesn't have to
keep using his fingers to decide the address of or distance
to something. :) Later models of Assemblers try to emulate
a high level compiler in terms of added functions supplied.
At any rate: Assembly is the nmenonices , Assembler is the
program that converts the nmenonices to machine code.

ld a,02h
ld b,1Ah
Call OS

0E021E1ACD20 (or z0: db 0E021E1ACD20h for direct implant)

000011100000001 000001111000011 010110011010010 0000

On the Z80:
The first set is Assembly
The second is the hexadecimal version of the Assembly
The third is the machine language it generates represented in binary.
(Do you really want to write Excel solely in machine language? You do
realize the program would be completely non-portable?)

On a Televideo screen this is the CLEAR SCREEN command. It was the
standard clear screen for most terminals of the CP/M days. One could
simply use the debugger, type in the hex and save as z.com. Then when
one typed z<crthe jumbled up screen cleared to system prompt in the
upper left.
(Naturally Microsoft couldn't allow the standards long in use so today
this would be stated as CLS<ENTER>. :)

Question: What does any of this have to do with:
The Importance of Terminology's Quality
when using Webster to define the words in the above line?


Been fun.

Steve
norseman@hughes .net

[Robert Maas, http://tinyurl.com/uh3t]

Re: The Importance of Terminology's Quality

From: George Neuner <gneun...@comca st.net>

A friend of mine had an early 8080 micros that was programmed
through the front panel using knife switches

When you say "knife switches", do you mean the kind that are shaped
like flat paddles? I think that would be the IMSAI, which came
after the ALTAIR. Those flat paddle-shaped switched would
presumably be much more comfortable on the fingers than the
standard metal toggle switches on the ALTAIR. I had an ALTAIR,
which made front-panel programming rather painful on the fingers.

... toggle in the binary address, latch it, toggle in the binary
data, latch it, repeat ad nauseam.

For manually loading software in sequential locations, you have to
enter the binary address only once. After that, you press the
EXAMINE-NEXT toggle to increment the address by one. That reduced
the effort by nearly a factor of 3. Instead of toggling a 16-bit
address and EXAMINE and 8-bit datum and STORE each time, you toggle
just EXAMINE-NEXT and 8-bit datum and STORE for each consecutive
memory location after the first. Note the address and data toggles
are bistable, stay in whatever position you left them in, whereas
the three control toggles (EXAMIME EXAMINE-NEXT STORE) are spring
loaded, making momentary contact when you force them then spring
back to inactive when you release them.

It had no storage device initially ... to use it you had to input
your program by hand every time you turned it on.

Almost but not quite true. With static RAM, most of the data can
survive power-downs of hours or even days. I had 28k bytes of
static RAM on my ALTAIR, so if I needed to start it up after it had
been shut down I'd toggle in the starting address by hand, EXAMINE
that, compare what shows with what's on my printed listing, and if
it matches just EXAMINE-NEXT to compare the next. In the few cases
I saw a bit or two flipped, I'd re-enter that one byte of data.

I had to do that only for my BOOT1 loader, which was hand-loaded
from front panel and took text input in 3n+1 form from Beehive 3A
terminal connected to serial port, maybe also for BOOT2 loader
which had been loaded in 3n+1 form and took input in hexadecimal
form, and maybe also for BOOT3 loader which had been loaded in
hexadecimail form from Beehive and automatically downloaded the
next bootstrap loader from modem. If only a few bytes (of BOOT2 or
BOOT3) had been damaged by days of power down, comparing binary
against listing to verify it's 99% correct, and then manually
patching just one or two bytes, would be faster and safer than
manually entering 3n+1 or hexadecimal from keyboard. But once BOOT3
was loaded, I always downloaded all the rest of the software from
the PDP-10 over the modem.

I did a little bit of programming on it, but I tired of it quickly.

Did your friend's machine have two serial ports, one for local
terminal and one for modem, and did you have access to a remote
PDP-10 or other mainframe for running a cross-assembler? Or did you
have some other computer locally available, where you could use
that other computer both to store your library of code and to
perform automated file transfer from archive on other computer to
where it's needed on IMSAI?

As did my friend - once he got the tape storage working (a new
prom)

Yeah, I never had the money to buy that, and with the PDP-10
available for both cross-assembling and archiving/downloading, I
didn't need it.

Machine coding is not relevant anymore - it's completely
infeasible to input all but the smallest program.

That's not totally true. For some educational purposes, like
*really* understanding pointers (not the kind in C so much as the
kind that are inherent in all pointer-linked data structures such
as linked lists and binary search trees etc.), it helps to have
some "hands-on" experience writing and executing machine-language
code, in a sense actually "seeing" a register first point to the
first byte of a CONS cell then by indexing with offset pointing
*through* the *second* pointer of that CONS cell to whatever the
CDR points to. Then "mission impossible" when your instructor tells
you to see if there's a way to reverse that process, whereby you
are given the register pointing to whatever the CDR points to, and
you are supposed to find the address of the original CONS cell.
Instant enlightenment, no lecture/sermon needed!

[Martin Gregorie]

Re: The Importance of Terminology's Quality

On Mon, 01 Sep 2008 12:04:05 -0700, Robert Maas, http://tinyurl.com/uh3t
wrote:

>From: George Neuner <gneun...@comca st.netA friend of mine had an
>early 8080 micros that was programmed through the front panel using
>knife switches

>
When you say "knife switches", do you mean the kind that are shaped like
flat paddles?
>

Pedantic correction:

"Knife switch" is the wrong term. These are high current switches,
typically used in the sort of heavy duty circuit where the wiring hums
when power is on or in school electrical circuits so even the back of the
class can see whether the switch is open or closed. In these a copper
'blade' closes the contact by being pushed down into a
narrow, sprung U terminal that makes a close contact with both sides of
the blade. Like this: http://www.science-city.com/knifeswitch.html

What you're talking is a flat handle on a SPST or DPST toggle switch. It
is often called a paddle switch and mounted with the flats on the handle
horizontal. Like this, but often with a longer handle:

http://www.pixmania.co.uk/uk/uk/1382717/art/radioshack/spdt-panel-mount-

paddle-s.html


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[George Neuner]

Re: The Importance of Terminology's Quality

On Mon, 1 Sep 2008 21:03:44 +0000 (UTC), Martin Gregorie
<martin@see.sig .for.address.in validwrote:

>On Mon, 01 Sep 2008 12:04:05 -0700, Robert Maas, http://tinyurl.com/uh3t
>wrote:
>

>>From: George Neuner <gneun...@comca st.netA friend of mine had an
>>early 8080 micros that was programmed through the front panel using
>>knife switches

>>
>When you say "knife switches", do you mean the kind that are shaped like
>flat paddles?
>>

>Pedantic correction:
>
>"Knife switch" is the wrong term. These are high current switches,
>typically used in the sort of heavy duty circuit where the wiring hums
>when power is on or in school electrical circuits so even the back of the
>class can see whether the switch is open or closed. In these a copper
>'blade' closes the contact by being pushed down into a
>narrow, sprung U terminal that makes a close contact with both sides of
>the blade. Like this: http://www.science-city.com/knifeswitch.html
>
>What you're talking is a flat handle on a SPST or DPST toggle switch. It
>is often called a paddle switch and mounted with the flats on the handle
>horizontal. Like this, but often with a longer handle:
>http://www.pixmania.co.uk/uk/uk/1382...t-panel-mount-
>paddle-s.html

I don't know the correct term, but what I was talking about was a tiny
switch with a 1/2 inch metal handle that looks like a longish grain of
rice. We used to call them "knife" switches because after hours
flipping them they would feel like they were cutting into your
fingers.

George

[RedGrittyBrick]

Re: The Importance of Terminology's Quality


George Neuner wrote:

On Mon, 1 Sep 2008 21:03:44 +0000 (UTC), Martin Gregorie
<martin@see.sig .for.address.in validwrote:
>

>On Mon, 01 Sep 2008 12:04:05 -0700, Robert Maas, http://tinyurl.com/uh3t
>wrote:
>>

>>>From: George Neuner <gneun...@comca st.netA friend of mine had an
>>>early 8080 micros that was programmed through the front panel using
>>>knife switches
>>When you say "knife switches", do you mean the kind that are shaped like
>>flat paddles?
>>>

>Pedantic correction:
>>
>"Knife switch" is the wrong term. These are high current switches,
>typically used in the sort of heavy duty circuit where the wiring hums
>when power is on or in school electrical circuits so even the back of the
>class can see whether the switch is open or closed. In these a copper
>'blade' closes the contact by being pushed down into a
>narrow, sprung U terminal that makes a close contact with both sides of
>the blade. Like this: http://www.science-city.com/knifeswitch.html
>>
>What you're talking is a flat handle on a SPST or DPST toggle switch. It
>is often called a paddle switch and mounted with the flats on the handle
>horizontal. Like this, but often with a longer handle:
>http://www.pixmania.co.uk/uk/uk/1382...t-panel-mount-
>paddle-s.html

>
I don't know the correct term, but what I was talking about was a tiny
switch with a 1/2 inch metal handle that looks like a longish grain of
rice. We used to call them "knife" switches because after hours
flipping them they would feel like they were cutting into your
fingers.
>

That must be a toggle switch (as MG suggested) just not the paddle type.

e.g.
<http://cpc.farnell.com/SW02861/components-spares/product.us0?sku =multicomp-1m31t1b1m1qe>
<http://tinyurl.com/64a8ld>


--
RGB

[Martin Gregorie]

Re: The Importance of Terminology's Quality

On Mon, 01 Sep 2008 20:48:23 -0400, George Neuner wrote:

I don't know the correct term, but what I was talking about was a tiny
switch with a 1/2 inch metal handle that looks like a longish grain of
rice. We used to call them "knife" switches because after hours
flipping them they would feel like they were cutting into your fingers.
>

That sounds like a sub-minature SPDT toggle switch with a normal handle.
Cheap as chips, which is probably why they were used on that front panel.
Like this by any chance?

http://www.maplin.co.uk/images/300/fh00a_ff70m.jpg

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |