Re: General Question about UNIBUS backplanes

[Noel Chiappa]

> From: Bill Degnan

> I removed the core backplanes and returned the DD11-C to the orig
> config next to the CPU. I re-inserted cards as-was. I am not getting
> comms from the M7856.

Ugh. Not good. Does it respond on the UNIBUS? (I.e. if you try to read
the registers from the front panel?)

> I may have shorted the card.

If you somehow plugged it into one of the core backplanes, good chance, alas.
They have either -15V or +20V (I think the latter, for the MM11-U) running
around on various pins.

(Oh, BTW, you probably already know this, but just in case not: those
backplanes take specific boards in specific slots; check the manuals/prints
for the correct slots.)

Do you have a spare M7856 you can swap in to make sure the machine is
otherwise functional? If not, let me know, I have a bunch of spare M7800's,
I can send you one (known, tested good).

Noel

Re: General Question about UNIBUS backplanes

[william degnan]

There have been a lot of parallel discussions on my PDP 11/40, I am
consolidating them all here:

I now have 5 backplanes installed.  Here they are, described in order.  I
walked through this will Paul Anderson last night (thanks Paul!) to verify
everything was in the right place and in the right order, in the right
power, etc.  The +5V is a little weak but I can tweak it, etc.

1.  CPU backplane.  This is the same backplane I have had running/working
for 10 years.  There is no M2737 or M787 installed, just a stock CPU card
set.  No changes have been made.

2.  core backplane #1 32k x 16 - 18 Memory backplane 500344C.This
backplane has one set of core cards installed in the order they came from
another system.  These are electrically ok, but not tested/known to pass
memory tests.  The M8293 is set to 
9/11: M981 (1-2)
11: M8293 (3-6)
12: M7259 (1-2)
13: G114
14: H217C
15: G235

The 2nd half of the 1st core backplane is empty.

3.  The 2nd core backplane is empty.  There are M920's on either end to
connect them

4.  The next backplane is a DD11B.  This is empty other than grant cards in
each slot D.

An M9202 connects the DD11B to the next backplane

5.  The final (5th) backplane is a DD11C

In the first slot (closest to the front) GC in slot 4.

In the 2nd there is a M7261 RT11 drive controller.  This slot requires a
NPG G7273 installed if not in use, the M7761 requires this kind of slot.
It's not hooked up to anything (RL02).

In the 3rd slot is an M9312 with console prom and RL01/02 boot prom.  Not a
terminator

In the 4th slot is a M930 on top with a G7273 in 3/4.  The G7273 is
required because previously the NPG was removed from wirewrap per
requirements for installation of M7762 RL11.  This was done before I
learned I could have just used slot 2nd, which comes from the factory that
way.  Bummer but that's what I've got.

WHEN I POWER UP - I have full console access, everything "works" and now I
have to start diagnosing the core to find at least 16K that I can play
with. With the current set of core cards  I can toggle in data into
addresses, but it's not perfect (line 2 sticks).  Once I am operating
with a working set of core I will then turn my attention to the RT11 card,
and find a working serial card so I can use a terminal and PDP11GUI, etc.

I have spare core cards to draw upon, I had pulled a good set for my 11/05
I could always use those if need be.

Thanks everyone for your help and suggestions.

Bill

Re: General Question about UNIBUS backplanes

[Mattis Lind]

2016-05-24 14:50 GMT+02:00 william degnan :

> There have been a lot of parallel discussions on my PDP 11/40, I am
> consolidating them all here:
>
> I now have 5 backplanes installed.  Here they are, described in order.  I
> walked through this will Paul Anderson last night (thanks Paul!) to verify
> everything was in the right place and in the right order, in the right
> power, etc.  The +5V is a little weak but I can tweak it, etc.
>
> 1.  CPU backplane.  This is the same backplane I have had running/working
> for 10 years.  There is no M2737 or M787 installed, just a stock CPU card
> set.  No changes have been made.
>
> 2.  core backplane #1 32k x 16 - 18 Memory backplane 500344C.This
> backplane has one set of core cards installed in the order they came from
> another system.  These are electrically ok, but not tested/known to pass
> memory tests.  The M8293 is set to 
> 9/11: M981 (1-2)
> 11: M8293 (3-6)
> 12: M7259 (1-2)
> 13: G114
> 14: H217C
> 15: G235
>
> The 2nd half of the 1st core backplane is empty.
>
> 3.  The 2nd core backplane is empty.  There are M920's on either end to
> connect them
>
> 4.  The next backplane is a DD11B.  This is empty other than grant cards in
> each slot D.
>
> An M9202 connects the DD11B to the next backplane
>
> 5.  The final (5th) backplane is a DD11C
>
> In the first slot (closest to the front) GC in slot 4.
>
> In the 2nd there is a M7261 RT11 drive controller.  This slot requires a
> NPG G7273 installed if not in use, the M7761 requires this kind of slot.
> It's not hooked up to anything (RL02).
>
> In the 3rd slot is an M9312 with console prom and RL01/02 boot prom.  Not a
> terminator
>
> In the 4th slot is a M930 on top with a G7273 in 3/4.  The G7273 is
> required because previously the NPG was removed from wirewrap per
> requirements for installation of M7762 RL11.  This was done before I
> learned I could have just used slot 2nd, which comes from the factory that
> way.  Bummer but that's what I've got.
>
> WHEN I POWER UP - I have full console access, everything "works" and now I
> have to start diagnosing the core to find at least 16K that I can play
> with. With the current set of core cards  I can toggle in data into
> addresses, but it's not perfect (line 2 sticks).  Once I am operating
> with a working set of core I will then turn my attention to the RT11 card,
> and find a working serial card so I can use a terminal and PDP11GUI, etc.
>
> I have spare core cards to draw upon, I had pulled a good set for my 11/05
> I could always use those if need be.
>
> Thanks everyone for your help and suggestions.
>
> Bill
>


But the M9312 has bus terminating resistors (unless you actually desoldered
those!). Then you have three terminators in your system! One in the M891 at
the CPU, one in the M9312 in slot 3 of last DD11, and then a M930 in slot 4
of DD11.

If you want the M9312 you should put it with W1-W5 installed in the slot 4
where you have the M930. You should not have both a M930 and M9312 (when
you have the M891).

/Mattis

Re: General Question about UNIBUS backplanes

[william degnan]

>
>
>
>
> But the M9312 has bus terminating resistors (unless you actually desoldered
> those!). Then you have three terminators in your system! One in the M891 at
> the CPU, one in the M9312 in slot 3 of last DD11, and then a M930 in slot 4
> of DD11.
>
> If you want the M9312 you should put it with W1-W5 installed in the slot 4
> where you have the M930. You should not have both a M930 and M9312 (when
> you have the M891).
>
> /Mattis
>


After I sent the email to this group, I checked the M9312 and found it was
terminated.  I was told it was not, I should have checked for myself but I
grew suspicious that it should be by default.  Now, the M9312 is in the
last slot, and I removed the M930.  There is nothing except a grant card in
the 3rd slot.

I fixed the core problem I described in my email.  I also am able to store
into core and run "chase the lights",  I have generally speaking a working
16K system.

Thanks again.

Next - Get a serial card running and resume efforts to boot RT11 from an
RL02 drive.

Bill

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: General Question about UNIBUS backplanes

[Mattis Lind]

2016-05-24 15:37 GMT+02:00 william degnan :

> >
> >
> >
> >
> > But the M9312 has bus terminating resistors (unless you actually
> desoldered
> > those!). Then you have three terminators in your system! One in the M891
> at
> > the CPU, one in the M9312 in slot 3 of last DD11, and then a M930 in
> slot 4
> > of DD11.
> >
> > If you want the M9312 you should put it with W1-W5 installed in the slot
> 4
> > where you have the M930. You should not have both a M930 and M9312 (when
> > you have the M891).
> >
> > /Mattis
> >
>
>
> After I sent the email to this group, I checked the M9312 and found it was
> terminated.  I was told it was not, I should have checked for myself but I
> grew suspicious that it should be by default.  Now, the M9312 is in the
> last slot, and I removed the M930.  There is nothing except a grant card in
> the 3rd slot.
>

Good. But what is the status of W1-W5 of the M9312? Installed or not?

The usage of AU1 and AV1 differs in Unibus slot versus a Modified Unibus
(MUD) slot. The MUD slot uses those two pins for +20V Core power. You don't
want to have the jumpers installed when you put the M9312 in a MUD slot (if
there is +20V in your system). Then smoke will escape I guess.

But If you use it as a terminator in a unibus slot then then you want them
to terminate the BGx and NPG lines thus you need to install the jumpers.

Now I don't really know if your backplane has MUD wiring or not. I think
MUD wiring is a later DEC invention when there were selfcontained unibus
core memory modules. Not entire backplanes.

But be carful with the jumpers. On the M9302 for example there are big
print that tell you something will go bad if you install it in a MUD slot...


>
> I fixed the core problem I described in my email.  I also am able to store
> into core and run "chase the lights",  I have generally speaking a working
> 16K system.
>

Sounds really good!


> Thanks again.
>
> Next - Get a serial card running and resume efforts to boot RT11 from an
> RL02 drive.
>

What never was clear to me was if you actually could access the serial card
or not from the console. I.e. did it respond when addressing it? If it did
respond I would check that there were correct power supplied to the 1488
driver.

/Mattis


>
> Bill
>
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 
>

Re: General Question about UNIBUS backplanes

[william degnan]

>
>
>
> What never was clear to me was if you actually could access the serial card
> or not from the console. I.e. did it respond when addressing it? If it did
> respond I would check that there were correct power supplied to the 1488
> driver.
>
> /Mattis
>
>
>
The M9312 does yes  have the terminators installed.

I have not been able to activate the M9312 with the DD11C backplane
"behind" the newly-installed core and DD11B backplanes.  I don't know if I
fried it somehow recently.  It was working before.   The M9312 is installed
on the 4th slot in the DD11C with a NPG card below it.  It is also possible
that instead I am not communicating with the cards in the back of the bus.

Typically I toggle and run from address 165144 from the front panel, then
use the console program from a terminal to go from there.  Since my recent
shenanigans with the backplanes the console program does not appear to load
nor run.

When I load the address 165144 I see the correct address on the front
panel.  RUN BUS PROC CONSOLE are all lit.  When I enable and start the
system the address lights go out except 020 (2nd to last light).  The RUN
BUS PROC CONSOLE stay lit.

When I examine
165144 177570
165146 177570
165150 177570
165152 177570
etc

I don't know the status of my M7856 card.  There are things I can try but
first I believe I should test to see if I am "pinging" to the DD11C at
all.  I also need to check power output levels and adjust.

I am thinking also test the MOS RAM from the DD11C by itself to see what
that tells me.  I know to address the RAM somewhere other than the 16K
space from 000.

Bill

Re: General Question about UNIBUS backplanes

[william degnan]

The DD11C was modified a while back. I also need to probe the system to
confirm what slots need a NPG grant card, make sure everything is
documented.  I *think* it's slot 4 and 2 that need them, but I should
verify this vs. the manual default.

Re: General Question about UNIBUS backplanes

[j...@cimmeri.com]

On 5/24/2016 8:37 AM, william degnan wrote:
...  I fixed the core problem I 
described in my email. ... Bill 


B, what was the issue with the core, 
that you fixed it so fast?


- J.

Re: General Question about UNIBUS backplanes

[william degnan]

On Tue, May 24, 2016 at 11:17 AM, j...@cimmeri.com  wrote:

>
>
> On 5/24/2016 8:37 AM, william degnan wrote:
>
>> ...  I fixed the core problem I described in my email. ... Bill
>>
>
> B, what was the issue with the core, that you fixed it so fast?
>
> - J.
>

I guessed that the G114 was bad based on a hunch.

I had a spare.

b



-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Front panel switches - what did they do?

[Swift Griggs]

Since I'm an igmo about most machines before the mid-eighties (and still 
fuzzy even on most of those), I'm curious about all these older machines 
with front panel buttons and switches. What all did they do? You could 
actually program them using the front panel right? Some of them 
bootstrapped this way, too? What kind of "language" was used for that 
(ie.. what were the basic mechanics)? Did the buttons ever change color? 
Were you considered a badass if you had switch flipping all memorized down 
to an art? Were they mainly multi-position toggle switches or on/off 
buttons?

They just seem to be a lot more important on older mainframes and minis. 
Also, what was the main reason for the blinkenlights? Was it to show 
system load or specific system states?

Just curious. I'm learning a ton from reading these threads on older 
machines, but there is so much I don't know. 

-Swift

Re: Front panel switches - what did they do?

[william degnan]

On Tue, May 24, 2016 at 11:38 AM, Swift Griggs 
wrote:

>
> Since I'm an igmo about most machines before the mid-eighties (and still
> fuzzy even on most of those), I'm curious about all these older machines
> with front panel buttons and switches. What all did they do? You could
> actually program them using the front panel right? Some of them
> bootstrapped this way, too? What kind of "language" was used for that
> (ie.. what were the basic mechanics)? Did the buttons ever change color?
> Were you considered a badass if you had switch flipping all memorized down
> to an art? Were they mainly multi-position toggle switches or on/off
> buttons?
>
> They just seem to be a lot more important on older mainframes and minis.
> Also, what was the main reason for the blinkenlights? Was it to show
> system load or specific system states?
>
> Just curious. I'm learning a ton from reading these threads on older
> machines, but there is so much I don't know.
>
> -Swift
>
>
Here's a power point pres I did at VCF-E4, this will get you started.
Using Altair 680b front panel in basic terms is covered a few slides in.

http://vintagecomputer.net/vcf4/How_to_Session/

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Board swapping (was Re: General Question about UNIBUS backplanes)

[Ethan Dicks]

On Tue, May 24, 2016 at 11:36 AM, william degnan  wrote:
> On Tue, May 24, 2016 at 11:17 AM, j...@cimmeri.com  wrote:
>> B, what was the issue with the core, that you fixed it so fast?
>
> I guessed that the G114 was bad based on a hunch.
>
> I had a spare.

Q. How do you know the guy on the side of the highway with a flat tire
is a DEC Field Service Engineer?

A. He's swapping out all the tires to see which one is flat.

(or from net.jokes in 1981...
https://groups.google.com/forum/#!topic/net.jokes/GQ2B6HZIY_4 )

The way I heard it was:
How do you tell if a man with a flat tire is a DEC Field Service Rep?
Look in the trunk; if he's from DEC F.S. he'll have three spares with little
red tags on them and no jack.

-ethan

Re: Front panel switches - what did they do?

[Jon Elson]

On 05/24/2016 10:38 AM, Swift Griggs wrote:

Since I'm an igmo about most machines before the mid-eighties (and still
fuzzy even on most of those), I'm curious about all these older machines
with front panel buttons and switches. What all did they do? You could
actually program them using the front panel right? Some of them
bootstrapped this way, too? What kind of "language" was used for that
(ie.. what were the basic mechanics)? Did the buttons ever change color?
Were you considered a badass if you had switch flipping all memorized down
to an art? Were they mainly multi-position toggle switches or on/off
buttons?


The PDP-5 I did a fair bit of work on needed a bootstrap 
program loaded in from switches, it had no internal ROM for 
that.  And, whenever a program crashed, it generally wiped 
the entire contents of memory, so the boot had to be 
reloaded by hand.  We actually wore out the switches.  It 
was about 15-20 12-bit words that needed to be entered.  We 
had DECtape on that machine, so we generally entered to boot 
loader for that.


The LINC was also a 12-bit computer, but it had built-in 
boot hardware.  it was not a boot loader program in a ROM, 
but when you pressed the load button, it would execute an 
I/O command from the left switches, and the right switches 
told it where to put it in memory.  So, that was a big 
advance, a one-button boot.


You could use the switches to patch a program you were 
debugging, look at memory locations to examine temporary 
data values, etc.


A few machines had lighted switches.  These would generally 
be white buttons with lamps behind them.
The only one I know of that changed color was the power 
button ("key" in IBM-speak) on IBM 360's.  It lit red while 
the power-up sequence was in progress, then turned white 
when all power supplies were up.  IBM tape drives and disk 
drives had lighted buttons to show status, different color 
buttons and indicators gave them different colors, but they 
were generally just lit and unlit, but not multi-color.


DEC PDP machines generally had a few switches that were 
multi-position,  Such as stop/single-step and load 
address/examine, otherwise they were all on-off.


IBM 360's had a row of switches that were multi-position, 
mostly for FE diagnostic purposes.  The data and address 
switches were all on/off.


Jon

RE: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[David Collins]

Here are the binaries for all the EPROMs on processor PCA for my 7596A.  The
PCA part number is 07595-60100 and is different from the one in the manual
which is a 07595-60200 so I assume my PCA is older than the one in the
manual. 

The EPROMs on the PCA are as follows:

17225-18001 U26
17225-18002 U35
17225-18003 U41
17225-18004 U42
07595-18097 U28
07595-18098 U37
Unknown U27 - no part number label 
Unknown U36 - no part number label

Binaries for each chip are attached. All are 27512 EPROMs.

I have also included photos of the PCA and the EPROMs in position.  Hope
that helps.

David Collins
Curator
HP Computer Museum
www.hpmuseum.net
 

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Martin
Peters
Sent: Monday, 23 May 2016 5:50 AM
To: General Discussion: On-Topic and Off-Topic Posts 
Subject: Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

Hi David!

David Collins:
> Martin, I might be able to help you as I think we have a 7596A.

Great! :)

> Are these EPROMs from the processor PCA?

I think so.

> Are you able to tell me which 'U'
> numbers they are in the PC board? 

No, not now. The plotter is in the shackspace in Stuttgart and I was not
there for several weeks and now I found an email saying they want to get rid
of it. I already asked for the dumps here one year ago and now it seems to
be really urgent.

> I haven't looked at the plotter itself, but the service manual we have 
> shows the following part numbers for the processor PCA
> 
> 07595-18039
> 07595-18040
> 07595-18041
> 07595-18042

I know. As I was told by the guy who took a look inside one year ago, these
parts do not exist in the revision we own. But I think, they only put the
firmware in two EPROMs at HP in a newer revision of the board.
And if not "only", I think the dumps would be helpful anyway. It would be
great if you could do a dump for me :-)

Many thanks,
Martin
--
Martin Peters
mar...@shackspace.de

RE: Front panel switches - what did they do?

[Bill Sudbrink]

I have it on good authority that Dazzlemation,
recreated source code here:

http://wsudbrink.dyndns.org:8080/dazzler.html

was initially written on paper and then toggled
in on the front panel of an Altair.  Whether
that is entirely true, I'm not sure, but evidence
in the code clearly shows that it was debugged
via the front panel.  Also, once the program was
running, its behavior (speed) was controlled
with the front panel switches.

Bill S.

Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[Ethan Dicks]

On Tue, May 24, 2016 at 10:25 AM, David Collins
 wrote:
> Here are the binaries for all the EPROMs on processor PCA for my 7596A.  The
> PCA part number is 07595-60100 and is different from the one in the manual
> which is a 07595-60200 so I assume my PCA is older than the one in the
> manual.

I did not have an 8mm socket wrench with me when I visited my 7596A so
I wasn't able to entirely remove the cover.  I did slip the camera in
under the lower edge and did extract U28 and U37 from mine for
dumping...

> The EPROMs on the PCA are as follows:
>
> 17225-18001 U26
> 17225-18002 U35
> 17225-18003 U41
> 17225-18004 U42

These were empty on my plotter, best I could tell.

> 07595-18097 U28
> 07595-18098 U37

I found these in those sockets:

07595-18095  U28
07595-18096  U37

> Unknown U27 - no part number label
> Unknown U36 - no part number label

These sockets are definitely empty on my plotter.

> Binaries for each chip are attached. All are 27512 EPROMs.

This list doesn't support attachments, so most of us didn't get them.

I'm happy to send along my copies of 07595-18095 / 07595-18096 when I
get them read out.

-ethan

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 8:38 AM, Swift Griggs  wrote:

>
> Since I'm an igmo about most machines before the mid-eighties (and still
> fuzzy even on most of those), I'm curious about all these older machines
> with front panel buttons and switches. What all did they do? You could
> actually program them using the front panel right? Some of them
> bootstrapped this way, too? What kind of "language" was used for that
> (ie.. what were the basic mechanics)? Did the buttons ever change color?
> Were you considered a badass if you had switch flipping all memorized down
> to an art? Were they mainly multi-position toggle switches or on/off
> buttons?
>
> They just seem to be a lot more important on older mainframes and minis.
> Also, what was the main reason for the blinkenlights? Was it to show
> system load or specific system states?
>
> Just curious. I'm learning a ton from reading these threads on older
> machines, but there is so much I don't know.
>
>
"Older machines" covers a lot of ground.

In my experience (PDP-11, PDP-8 PDP-15, Nova, IBM 709, DPS8 and others),
the panel switches and lights were for primarily for bootstrapping and
debugging.

Typically, there was a set of data switches (0/1 toggles) that could be set
to an address or data value, and a set of command switches (momentary
contact) that copied the data switches to some data register or memory.

For the earlier or cheaper systems, there was no 'bootstrap ROM'; so a
small program that was capable of reading the first record of a paper or
magnetic tape into memory and running it was needed. This program was
documented in ''machine language' -- a list of binary values that needed to
be placed in specific memory locations. Hypothetical example (in octal):

 Starting at location 0:

1456
3342
3300
3040
0070

(expressed in octal).

To bootstrap the machine, you loaded a paper tape containing the program
you wanted to run in the reader. Next, you hit the 'RESET' on the console;
among other things, that would set the console 'next address' register and
the instruction counter to 0.

You then set the data switches to 001100101110  (1456 in binary), and press
'DEPOSIT'. Thus would copy the data switches to memory at the location in
the 'next address' register and increment the register. You then repeated
this for each data value -- toggle in the value, press deposit. When done,
you pressed 'START'. The RESET had set the instruction counter to 0, so the
CPU would start executing code at location 0, which contains the 1456
instruction, and your bootstrap is off and running. It reads  some number
of characters from the paper tape into memory, and then starts executing
them. Those characters will be a more complex boot strap loader that will
read them rest of the tape into memory and run it.

Later or more expensive options of these machines would have a bootstrap
loader in ROM. Typically, you would toggle in the the address of the ROM
into the instruction counter and then boot device ID into the data toggles
and then start the CPU.

For the DPS8 there was a bootstrap ROM, a set of switches specifying card
reader or tape boot, the device ID and a 'BOOT' button. The data switches
would be examined by the operating system during boot to enable debugging
(pause at certain points during boot, eg).

The 709 had these massively over-engineered rocker switches,  reminiscent
of circuit breakers, and a reset switch which activated a electric motor in
the console which physically set the switches back to 0.

The PDP-15 had a 'CPU speed' knob. turning it would continuously vary the
CPU clock from 1Hz to full speed.

The blinking lights typically would have at least the instruction counter
and the accumulator. Other registers might be displayed, as well as the
instruction being executed, operand address and value, condition code bits,
IO activity, interrupt status, and much more.

Watching the instruction counter could reveal the CPU to stuck in a short
loop; or, if halted, what instruction it was at when it halted.

The console switches and lights could be used to examine memory locations
as part of debugging.

If the program was stuck in a loop, the console switches could be used to
halt the CPU and examine where in the program it was looping and the values
of the variables that controlled the loop.

Some of the mainframes had hundreds and hundreds of lights, detailing the
internal state of the machine; mostly of interest to field engineers.

-- Charles

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, william degnan wrote:
> Here's a power point pres I did at VCF-E4, this will get you started. 
> Using Altair 680b front panel in basic terms is covered a few slides in. 
> http://vintagecomputer.net/vcf4/How_to_Session/

There are some nice clean photos in that presentation. So, it was binary 
with some hexadecimal addressing. I like the slide entitled "How to test 
Machine Language Using a Program Listing Using Toggle Switches". That's 
pretty hard core. I'm surprised they didn't at least use component 
displays with LEDs to show the values rather than reading it straight off 
some blinkenlights. Maybe those weren't around yet or were too expensive.

-Swift

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 8:38 AM, Swift Griggs wrote:
> Since I'm an igmo about most machines before the mid-eighties (and still 
> fuzzy even on most of those), I'm curious about all these older machines 
> with front panel buttons and switches. What all did they do?

Primary front-panel operations were:
1 - examine and load memory locations
2 - examine and load registers, including the instruction counter
3 - start and stop processor execution (run state)
Thus with (2) you can start execution where-ever you want in 
memory

Also, depending on the machine:
4 - single-step the processor, sometimes per instruction, sometimes per 
clock cycle or instruction phase
5 - twiddle I/O devices

> You could 
> actually program them using the front panel right?

Yes

> Some of them 
> bootstrapped this way, too?

Yes. In the core days, the common thing to do would be to use the front panel 
to 'toggle in' the first bootstrap loader of some few dozen instructions/words.
Core being non-volatile, that bootstrap program would continue to reside there 
across power-down/up so you didn't have to re-toggle at every power-up.
Just set the execution-start address with the toggles, and run.


> What kind of "language" was used for that 
> (ie.. what were the basic mechanics)?

Raw machine code. Typically expressed in octal or hex depending on the machine 
instruction layout or policy, and translated to binary by the operator as you 
toggle in.


> Did the buttons ever change color?


> Were you considered a badass if you had switch flipping all memorized down 
> to an art?


> Were they mainly multi-position toggle switches or on/off 
> buttons?

Most common was two-position (up-down) toggles.
Some machines had rotary switches for such as register-display selection
Some used momentary-push-buttons for 1-0 bit cycling.


> They just seem to be a lot more important on older mainframes and minis. 
> Also, what was the main reason for the blinkenlights? Was it to show 
> system load or specific system states?

Primary intentions were:
1 - initial bootstrap as mentioned above

2 - hardware diagnosis and servicing
Earlier and larger machines might have the state of every or 
near-every flip-flop in the machine brought out to an indicator,
so you could see the entire processor state on the front panel. 
You could then use that to trace logic faults in the machine.
Simple example: if the carry flip-flop lamp isn't turning on 
after single-stepping through an ADD instruction with registers
loaded with operands which should result in carry . . .

3 - (less common) program diagnosis , i.e. used as an instruction-level 
software debugger, if one had monopoly machine access.

The improved reliablity of LSI logic over discrete and SSI, and the creation of 
ROM chips of reasonable capacity (to hold the bootstrap or a monitor), would 
bring about the demise of the blinkenlight  front panel.
Note that only a couple of the first microcomputers had blinkenlight front 
panels, and they were pretty much gone from minis and mainframes by the 
late-70s.


> Just curious. I'm learning a ton from reading these threads on older 
> machines, but there is so much I don't know. 

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Jon Elson wrote:
> The PDP-5 I did a fair bit of work on needed a bootstrap program loaded 
> in from switches, it had no internal ROM for that.

How long did it usually take to do it?

> And, whenever a program crashed, it generally wiped the entire contents 
> of memory, so the boot had to be reloaded by hand. 

Uhh, ouch! That'll learn ya! You'd better be a careful coder, then I 
guess. Sheesh.

> So, that was a big advance, a one-button boot.

Man, it seems so elementary now. Everything had to be invented sometime, I 
suppose.

> You could use the switches to patch a program you were debugging, look 
> at memory locations to examine temporary data values, etc.

It seems like that'd make working with computers a lot more "intentional" 
if you know what I mean. 

> A few machines had lighted switches.  These would generally be white 
> buttons with lamps behind them.

Hmm, so not as cool as 60's and 70's TV and movies seemed to suggest. 
Still at least it did happen.  :-)

> The only one I know of that changed color was the power button ("key" in 
> IBM-speak) on IBM 360's. 

Heh, my grandmother was a Cobol programmer on IBM 360s for Western 
National Gas (now Diamond Shamrock). She had mixed feelings about them, 
but she said they had a decent development environment vis-a-vis some of 
the competition at the time.

> IBM tape drives and disk drives had lighted buttons to show status, 
> different color buttons and indicators gave them different colors, but 
> they were generally just lit and unlit, but not multi-color.

Hmm, yeah, I seem to remember some similar style lights on old TEAC 
reel-to-reel audio gear from that era, too.

> DEC PDP machines generally had a few switches that were multi-position, 
> Such as stop/single-step and load address/examine, otherwise they were 
> all on-off.

Those multi-position switches are really cool. They remind me more of 
avionics style controls (which always seem to be the nicest physical gear 
in terms of build quality). 

-Swift

Re: Front panel switches - what did they do?

[William Donzelli]

> The improved reliablity of LSI logic over discrete and SSI, and the creation 
> of ROM chips of reasonable capacity (to hold the bootstrap or a monitor), 
> would bring about the demise of the blinkenlight  front panel.
> Note that only a couple of the first microcomputers had blinkenlight front 
> panels, and they were pretty much gone from minis and mainframes by the 
> late-70s.

The demise was really about money. All those lights, switches, wiring,
metalwork, etc. for a full panel was EXPENSIVE.

--
Will

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 9:25 AM, Swift Griggs  wrote:

> On Tue, 24 May 2016, william degnan wrote:
> > Here's a power point pres I did at VCF-E4, this will get you started.
> > Using Altair 680b front panel in basic terms is covered a few slides in.
> > http://vintagecomputer.net/vcf4/How_to_Session/
>
> There are some nice clean photos in that presentation. So, it was binary
> with some hexadecimal addressing. I like the slide entitled "How to test
> Machine Language Using a Program Listing Using Toggle Switches". That's
> pretty hard core. I'm surprised they didn't at least use component
> displays with LEDs to show the values rather than reading it straight off
> some blinkenlights. Maybe those weren't around yet or were too expensive.
>
> -Swift
>
>
Honeywell 6180 display panels:
http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html

-- Charles

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Charles Anthony wrote:
> "Older machines" covers a lot of ground.

Sorry, I should have said "machines from the 50's - 70's which used 
buttons, toggles, rockers or other switches on the front panel"

> Typically, there was a set of data switches (0/1 toggles) that could be 
> set to an address or data value, and a set of command switches 
> (momentary contact) that copied the data switches to some data register 
> or memory.

Did some of the machines have blinkenlights to show you what you were 
doing so you could see the values you were inputting? Judging from how I 
play guitar, I'd probably miskey and have to start all over etc...

> For the earlier or cheaper systems, there was no 'bootstrap ROM'; so a 
> small program that was capable of reading the first record of a paper or 
> magnetic tape into memory and running it was needed.

Was that because of cost, no availability (ie.. not invented yet), or 
what? Why didn't they have a boot ROM, BIOS, etc.. ?

> This program was documented in ''machine language' -- a list of binary 
> values that needed to be placed in specific memory locations. 
> Hypothetical example (in octal):

Ah, thanks for the example. Between this and the PPT someone posted 
earlier, I think I "get it" now.

> It reads some number of characters from the paper tape into memory, and 
> then starts executing them. Those characters will be a more complex boot 
> strap loader that will read them rest of the tape into memory and run 
> it.

Well, paper tape sure beats having to flip all those switches, it sounds 
like.

> The data switches would be examined by the operating system during boot 
> to enable debugging (pause at certain points during boot, eg).

I wish OS's still had something like this sometimes. Using a debugger over 
serial, there are times when I'd like to step through code or stop the 
whole kit-and-kaboodle. However, there are so many timers running in OS's 
these days a lot of the time that sort of thing causes major pain, 
especially with certain problematic drivers.

> The 709 had these massively over-engineered rocker switches, reminiscent 
> of circuit breakers, and a reset switch which activated a electric motor 
> in the console which physically set the switches back to 0.

Heh, that sounds cool. Could you hear the motor running after hitting the 
switch to activate it? 

> The PDP-15 had a 'CPU speed' knob. turning it would continuously vary the
> CPU clock from 1Hz to full speed.

Ohhh, neato. I wish that was more common, too. What fun! I need a machine 
with an analog dial for the clock speed and vue meters for RAM and CPU 
capacity :-)
 
> The blinking lights typically would have at least the instruction 
> counter and the accumulator. Other registers might be displayed, as well 
> as the instruction being executed, operand address and value, condition 
> code bits, IO activity, interrupt status, and much more.

That makes good sense, really. It doesn't seem so mysterious when you 
describe it, now.

> Watching the instruction counter could reveal the CPU to stuck in a 
> short loop; or, if halted, what instruction it was at when it halted.

Hmm, again, that wouldn't be so bad to have even today.

> Some of the mainframes had hundreds and hundreds of lights, detailing 
> the internal state of the machine; mostly of interest to field 
> engineers.

It probably still impressed the suits when they walked the data center. 
I've done data center tours with row after row of HP or Dell x86 servers 
and it's not much to look at. 

-Swift

RE: Front panel switches - what did they do?

[Bill Sudbrink]

Swift Griggs wrote:
> Machine Language Using a Program Listing Using Toggle Switches". That's
> pretty hard core. I'm surprised they didn't at least use component
> displays with LEDs to show the values rather than reading it straight
> off some blinkenlights.

It's much easier to tell if you have a stuck bit
(data or address) with simple LEDs.  This was (and is)
a real possibility in old machines.  Trying to watch
for patterns of HEX or OCT digits to provide the same
info would be really tough.

Bill S.

Re: Front panel switches - what did they do?

[Jon Elson]

On 05/24/2016 11:32 AM, Swift Griggs wrote:

On Tue, 24 May 2016, Jon Elson wrote:

The PDP-5 I did a fair bit of work on needed a bootstrap program loaded
in from switches, it had no internal ROM for that.

How long did it usually take to do it?
We had contests, I think some people got under 15 seconds.  
All from memory, of course!



And, whenever a program crashed, it generally wiped the entire contents
of memory, so the boot had to be reloaded by hand.

Uhh, ouch! That'll learn ya! You'd better be a careful coder, then I
guess. Sheesh.
This could happen on any computer, but it seemed the PDP-5 
(and PDP-8, same instruction set) were most likely to do 
this.  Actually, the PDP-5 had the instruction counter as 
location zero of memory, so it may have been more prone to it.


Jon

Re: Front panel switches - what did they do?

[Jon Elson]

On 05/24/2016 11:34 AM, William Donzelli wrote:

The improved reliablity of LSI logic over discrete and SSI, and the creation of 
ROM chips of reasonable capacity (to hold the bootstrap or a monitor), would 
bring about the demise of the blinkenlight  front panel.
Note that only a couple of the first microcomputers had blinkenlight front 
panels, and they were pretty much gone from minis and mainframes by the 
late-70s.


The early PDP-11s had a diode matrix ROM for the boot 
memory.  You could change the boot code with a wire cutter 
and soldering iron.


Jon

RE: Front panel switches - what did they do?

[Bill Sudbrink]

I wrote:
> Swift Griggs wrote:
> > Machine Language Using a Program Listing Using Toggle Switches".
> > That's pretty hard core. I'm surprised they didn't at least use
> > component displays with LEDs to show the values rather than
> > reading it straight off some blinkenlights.
> 
> It's much easier to tell if you have a stuck bit
> (data or address) with simple LEDs.  This was (and is)
> a real possibility in old machines.  Trying to watch
> for patterns of HEX or OCT digits to provide the same
> info would be really tough.

By the way, that's why most front panel implementations have
a "light check" function.

Bill S.

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Charles Anthony wrote:
> Honeywell 6180 display panels: 
> http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html

Holy rocker switch, Batman! Is that all for one machine? That looks like a 
man-machine interface to run a nuclear power plant or something. FOUR 
panels. The black panel looks uber-cool. That definitely looks like 
something from a 60's or 70's James bond film. There needs to be a villain 
about ready to launch a missile standing next to one.

Oh and here is a replica of an Apollo launch computer with a component LED 
display like I was mentioning: 

http://i.imgur.com/bbXZVcx.jpg

... probably too expensive to embed in a computer system, but still hard 
to beat for geek aesthetics. 

-Swift

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Jon Elson wrote:
> The early PDP-11s had a diode matrix ROM for the boot memory.  You could 
> change the boot code with a wire cutter and soldering iron.

Is that similar to "wire wrap" ? I remember my grandmother talking about 
having to snip wires connected to diodes. I think this was in the 50's but 
it might have been the 60's, too. She mentioned something like that. 

-Swift

Re: Front panel switches - what did they do?

[dwight]

Most early machines had core memory. If they hadn't crashed
crashed it, the bootstrap was still in memory. I crash my
core regularly.
Dwight



From: cctalk  on behalf of Swift Griggs 

Sent: Tuesday, May 24, 2016 9:54:17 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Front panel switches - what did they do?

On Tue, 24 May 2016, Charles Anthony wrote:
> Honeywell 6180 display panels:
> http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html

Holy rocker switch, Batman! Is that all for one machine? That looks like a
man-machine interface to run a nuclear power plant or something. FOUR
panels. The black panel looks uber-cool. That definitely looks like
something from a 60's or 70's James bond film. There needs to be a villain
about ready to launch a missile standing next to one.

Oh and here is a replica of an Apollo launch computer with a component LED
display like I was mentioning:

http://i.imgur.com/bbXZVcx.jpg

... probably too expensive to embed in a computer system, but still hard
to beat for geek aesthetics.

-Swift

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 9:44 AM, Swift Griggs  wrote:

>
> It probably still impressed the suits when they walked the data center.
> I've done data center tours with row after row of HP or Dell x86 servers
> and it's not much to look at.
>
>
Definitely.

Several OSes would show distinctive 'idle' patterns on the lights, this
provided a quick visual cue about system load for the big multi-user
systems.

As I understand it, the Transputer (an early multicpu system designed to
parallel computation had a simple buf effective display -- an LED for for
each CPU indicatiing if the CPU was working or idle, this told you at a
glance if you parallelization algortihim was effective.

-- Charles

Re: Front panel switches - what did they do?

[Al Kossow]

On 5/24/16 9:34 AM, William Donzelli wrote:

> The demise was really about money. All those lights, switches, wiring,
> metalwork, etc. for a full panel was EXPENSIVE.
>

And the functionality could be replaced by scan chains connected to a small 
computer
so you still had all the visibility w/o the expense. Amdahl mainframes and the 
Xerox
Dorado come to mind.

When hardware was BIG, it was easier just to put major controller registers on 
panels
above the logic, ala DEC peripheral controllers, or on maintenance panels that 
the
customers would never see (Burroughs, Univac)

Something else that control panels could do is single step or single cycle a 
CPU.

A few PDP's had a knob that would let you vary the processor clock rate (from 
memory,
the PDP-6, 7, 10 and 12)

Re: Front panel switches - what did they do?

[Mouse]

>>> The PDP-5 I did a fair bit of work on needed a bootstrap program
>>> loaded in from switches, it had no internal ROM for that.
>> How long did it usually take to do it?
> We had contests, I think some people got under 15 seconds.
> All from memory, of course!

I don't think I ever used a PDP-5, but I did, back in the late '70s,
use some HP rackmount machine with lighted buttons for front-panel
switches and a manually-entered bootstrap.  I got good at entering its
bootstrap, to the point where the limiting factor was speed of moving
my fingers between switches; once the code was memorized, dexterity was
the limiting factor for speed.  (I don't remember how long the
bootstrap was; I think it was something like six or eight instructions.
Probably something like "set DMA address and source sector in disk
controller, tell disk controller to read, wait for completion, jump to
loaded code".  Probably only some five or ten seconds to enter.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 9:34 AM, William Donzelli 
wrote:

> > The improved reliablity of LSI logic over discrete and SSI, and the
> creation of ROM chips of reasonable capacity (to hold the bootstrap or a
> monitor), would bring about the demise of the blinkenlight  front panel.
> > Note that only a couple of the first microcomputers had blinkenlight
> front panels, and they were pretty much gone from minis and mainframes by
> the late-70s.
>
> The demise was really about money. All those lights, switches, wiring,
> metalwork, etc. for a full panel was EXPENSIVE.
>
>
Yep. Later model models of the Honeywell 6180 replaced all of those display
panels with a minicomputer that generated video terminal displays of the
data.

-- Charles

Re: Front panel switches - what did they do?

[Chuck Guzis]

The switches on, say, an IBM 1401 and 1620 were negligible.  The lights
could tell a lot about the state of the system, however.

The CDC 6000-7000-STAR, etc. had no switches or lights.There was a
"deadstart panel" with a matrix of toggle switches whose contents were
initially used to start the system.   The operator's console was used
for interaction.  In fact, if one's hearing is blocked out, it's pretty
much impossible to tell if a 6600 is powered on and "hung" or just
powered off.  The display had to be refreshed every few milliseconds or
it went blank.

The STAR and 7000 used "MCUs"--basically a minicomputer with its own
memory and display that allowed one to manipulate all sorts of
interesting things.  The STAR MCU had its own drum, which was initially
loaded from paper tape.

Memory-and-address switches are not to be confused with "sense
switches".  An interesting early feature of FORTRAN was the ability to
interrogate the status of (usually 4) hardware or software switches.
There was a less-used feature of "sense lights".

When requesting that the operator mount a particular tape, for example,
the message to the operator was something like "PLS MOUNT TAPE  
UNIT yyy 1 UP AND GO".

FORTRAN II had the "IF SENSE SWITCH..." statement; Some FORTRAN IV
versions used library routines to do the same thing; e.g. SSWITCH, SLITET).

--Chuck

Re: Front panel switches - what did they do?

[Paul Koning]

A couple of observations.

Taking the PDP-11 as a fairly typical example, the switches are "data" and 
"address".  While running, the data switches were visible to the software, and 
could do something if you wanted to (typically this wasn't done).  When 
stopped, you could set an address in the address switches, and examine memory 
at that address (showing it in the lights) or change it (with the data supplied 
by the data switches).  You could also start at the address in the address 
switches.

Also, while running, the lights would display some bit of system state.  On a 
fair number of PDP-11s, you could select what to display.  When running RT-11 
you would typically ask for the "display register", a register written by 
software that appears in the lights and contains the idle pattern.  The pattern 
would slow down as the system got busy.

On other operating systems, say RSTS/E, you'd ask for "data paths" which was 
some internal state except during a WAIT instruction, when it would show the 
contents of R0.  That was where RSTS would put its idle lights pattern.  The 
result is that you'd see the clear pattern on a nearly idle machine, a blur if 
the machine is busy, or a frozen pattern if the machine was stuck in an 
infinite loop.  With experience, you could gauge what sort of thing a system 
was doing by its lights.  This is why in RSTS/E development we had Field 
Service remove the "remote diagnostics" (no lights) consoles and put the lights 
ones back in.

Very early PDP-11 systems needed to have some bootstrap toggled in, but by the 
time I saw my first one (1973) diode based boot cards (16 words, just enough 
for early disk drives) had appeared.

Other machines might be different.  Some had vast quantities of lights to show 
a lot of internal state at the same time; I remember Burroughs mainframes and 
some IBM/360 models (360/65?) in particular.  A few had none at all: the CDC 
6000 mainframes had a CRT display under program control, but no lights 
whatsoever.  It did have a boot loader, in the form of a 12 by 12 array of 
toggle switches -- a 12 word changeable ROM.  :-)

The first machine I got my hands on, a Philips PR8000 -- 24 bit minicomputer -- 
had 8 digit light displays -- 8 octal digits for the 24 bits of data.  And the 
data entry was with 8 sets of buttons, one set for each octal digit.  The 
buttons were marked 4/2/1 and arranged so you could enter a digit with one 
finger press:

   |   2   |
   | 4 | 1 |

so pressing in the middle would get you 7, bottom center a 5, etc.

The "boot ROM" was mentioned, which applies to various DEC machines.  On some 
other machines, the boot operation might not be a small program but a 
specialized hardware action instead.  That applies to the CDC mainframes, for 
example, as well as machines like the IBM 1620.  There a boot operation 
("deadstart", "initial program load") might put the CPU and I/O devices in some 
specific state and then start a data transfer from some selected device to some 
fixed memory location.

paul

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 9:54 AM, Swift Griggs wrote:
> On Tue, 24 May 2016, Charles Anthony wrote:
>> Honeywell 6180 display panels: 
>> http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html
> 
> Holy rocker switch, Batman! Is that all for one machine? That looks like a 
> man-machine interface to run a nuclear power plant or something. FOUR 
> panels. The black panel looks uber-cool. That definitely looks like 
> something from a 60's or 70's James bond film. There needs to be a villain 
> about ready to launch a missile standing next to one.


I think one of the most impressive front panels is that of the IBM 360/91:

http://www.columbia.edu/cu/computinghistory/36091.html

Re: Front panel switches - what did they do?

[Paul Berger]

On 2016-05-24 1:54 PM, Swift Griggs wrote:

On Tue, 24 May 2016, Charles Anthony wrote:

Honeywell 6180 display panels:
http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html

Holy rocker switch, Batman! Is that all for one machine? That looks like a
man-machine interface to run a nuclear power plant or something. FOUR
panels. The black panel looks uber-cool. That definitely looks like
something from a 60's or 70's James bond film. There needs to be a villain
about ready to launch a missile standing next to one.

Oh and here is a replica of an Apollo launch computer with a component LED
display like I was mentioning:

http://i.imgur.com/bbXZVcx.jpg

... probably too expensive to embed in a computer system, but still hard
to beat for geek aesthetics.

-Swift


The most impressive one I ever saw was when I was in technician school 
we had a tour of the underground in North Bay Ont. where we saw what was 
probably the last running AN/FSQ-7, the operator panel was very impressive.


Some of the early 370 systems that still had blinkenlights only had one 
or two rows and  rotary switchs selected what you where viewing.  
Attached to the switch there was a cylinder behind the panel that showed 
a legend of what the lights meant for the selected location.  The also 
had hex dials on the panel for data input.


Paul.

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 9:34 AM, William Donzelli wrote:
>> The improved reliablity of LSI logic over discrete and SSI, and the creation 
>> of ROM chips of reasonable capacity (to hold the bootstrap or a monitor), 
>> would bring about the demise of the blinkenlight  front panel.
>> Note that only a couple of the first microcomputers had blinkenlight front 
>> panels, and they were pretty much gone from minis and mainframes by the 
>> late-70s.
> 
> The demise was really about money. All those lights, switches, wiring,
> metalwork, etc. for a full panel was EXPENSIVE.


Well, everything is about money, so to speak.
Reducing costs was one motivation for eliminating the front panel, but not what 
made it practical or feasible to do so.

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 9:56 AM, Swift Griggs  wrote:

> On Tue, 24 May 2016, Jon Elson wrote:
> > The early PDP-11s had a diode matrix ROM for the boot memory.  You could
> > change the boot code with a wire cutter and soldering iron.
>
> Is that similar to "wire wrap" ? I remember my grandmother talking about
> having to snip wires connected to diodes. I think this was in the 50's but
> it might have been the 60's, too. She mentioned something like that.
>
>
Wirewrap is solderless.

https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Wire_Wrapping.jpg/220px-Wire_Wrapping.jpg

Very good for prototyping, automated wirewrapping was for some production.


-- Charles

Re: Front panel switches - what did they do?

[Marc Howard]

Those aren't LED's on the Apollo display.  They are EL's (Electro
Luminescent displays).  Each segment of each digit was controlled by a
relay.  They astronauts eventually got use to the tinkling sound of the
relays.

In fact the entire console panel of the command module was a giant EL,
covered mostly in gray paint except where switch legends were needed.  ELs
were highly reliable and dim-able. Unfortunately they required a relatively
high voltage (22 volts or so) which is why relays were needed to control
the display segments on the computer readouts.

I'm surprised no one has mentioned the control panel of the IBM 360/91:
https://en.wikipedia.org/wiki/IBM_System/360#/media/File:360-91-panel.jpg

Marc


On Tue, May 24, 2016 at 9:54 AM, Swift Griggs  wrote:

> On Tue, 24 May 2016, Charles Anthony wrote:
> > Honeywell 6180 display panels:
> >
> http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html
>
> Holy rocker switch, Batman! Is that all for one machine? That looks like a
> man-machine interface to run a nuclear power plant or something. FOUR
> panels. The black panel looks uber-cool. That definitely looks like
> something from a 60's or 70's James bond film. There needs to be a villain
> about ready to launch a missile standing next to one.
>
> Oh and here is a replica of an Apollo launch computer with a component LED
> display like I was mentioning:
>
> http://i.imgur.com/bbXZVcx.jpg
>
> ... probably too expensive to embed in a computer system, but still hard
> to beat for geek aesthetics.
>
> -Swift
>
>
>

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 10:25 AM, Charles Anthony wrote:

> Very good for prototyping, automated wirewrapping was for some
> production.


There was also automated "stapled wire".  I forget the name for the process.

I still prototype projects where I'm not entirely sure of what I'm after
using wirewrap.  It's one-off, unlike PCB, but very handy.

--Chuck

Re: Front panel switches - what did they do?

[jwsmobile]

On 5/24/2016 9:56 AM, Swift Griggs wrote:

On Tue, 24 May 2016, Jon Elson wrote:

The early PDP-11s had a diode matrix ROM for the boot memory.  You could
change the boot code with a wire cutter and soldering iron.

Is that similar to "wire wrap" ? I remember my grandmother talking about
having to snip wires connected to diodes. I think this was in the 50's but
it might have been the 60's, too. She mentioned something like that.
Diode boards were one form of read only storage in systems.  Another was 
the IBM and other's capacitance system.


The diode boards could be done by populating a board with all possible 
diodes, then clipping them, but the cost of diodes in early days made it 
such that they typically soldered the pins into boards to create the ROM 
arrays.


This is a system which used it, the Microdata 800.  This manual 
describes the assembler, and the assembler addressed the diode map as 
well as the parts map.


http://bitsavers.trailing-edge.com/pdf/microdata/800/69-1-0800-002_AP800_Assembly_Pgm_Jul69.pdf

thanks
Jim

-Swift

Re: Front panel switches - what did they do?

[Sean Conner]

It was thus said that the Great Swift Griggs once stated:
> On Tue, 24 May 2016, william degnan wrote:
> > Here's a power point pres I did at VCF-E4, this will get you started. 
> > Using Altair 680b front panel in basic terms is covered a few slides in. 
> > http://vintagecomputer.net/vcf4/How_to_Session/
> 
> There are some nice clean photos in that presentation. So, it was binary 
> with some hexadecimal addressing. I like the slide entitled "How to test 
> Machine Language Using a Program Listing Using Toggle Switches". That's 
> pretty hard core. I'm surprised they didn't at least use component 
> displays with LEDs to show the values rather than reading it straight off 
> some blinkenlights. Maybe those weren't around yet or were too expensive.

  Work with binary, octal and/or hexadecimal enough, and you'll learn how to
sight read binary patterns.  The conversion is pretty simple:

  OCTAL HEX
- - -   0   - - - - 0   
- - *   1   - - - * 1
- * -   2   - - * - 2
- * *   3   - - * * 3
* - -   4   - * - - 4
* - *   5   - * - * 5
* * -   6   - * * - 6
* * *   7   - * * * 7
* - - - 8
* - - * 9
* - * - A (or 10)
* - * * B (   11)
* * - - C (   12)
* * - * D (   13)
* * * - E (   14)
* * * * F (   15)

  So a byte value of

* - - * - * * -

is hexadecimal 96.  On Octal, it wold be 226.

  -spc (I'll leave he decimal value to the reader)

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 11:00 AM, jwsmobile wrote:

> Diode boards were one form of read only storage in systems.  Another
> was the IBM and other's capacitance system.

...and the "transformer" ROS used on the 360/40 (and others).

--Chuck

Re: Front panel switches - what did they do?

[Sean Conner]

It was thus said that the Great Swift Griggs once stated:
> On Tue, 24 May 2016, Charles Anthony wrote:

> > The data switches would be examined by the operating system during boot 
> > to enable debugging (pause at certain points during boot, eg).
> 
> I wish OS's still had something like this sometimes. Using a debugger over 
> serial, there are times when I'd like to step through code or stop the 
> whole kit-and-kaboodle. However, there are so many timers running in OS's 
> these days a lot of the time that sort of thing causes major pain, 
> especially with certain problematic drivers.

  The Amiga has a minimal debugger embedded in the ROM that ran over the
serial port (9600 8n1).  It would automatically become active when a Guru
Meditation (similar to a Unix kernel panic, or the Mac bomb, or the Windows
Blue Screen of Death) but you could get to it at other times as well (I
played around with it a bit).  The debugger is *very* minimal (hex dumps of
memory and registers, you could modify memory and registers, resume, etc).

> > Some of the mainframes had hundreds and hundreds of lights, detailing 
> > the internal state of the machine; mostly of interest to field 
> > engineers.
> 
> It probably still impressed the suits when they walked the data center. 
> I've done data center tours with row after row of HP or Dell x86 servers 
> and it's not much to look at. 

  The original Connection Machine had one LED per CPU (max 65,536).  You
could get some pretty impressive visuals out of that one.

  -spc

Re: Front panel switches - what did they do?

[Al Kossow]

On 5/24/16 10:44 AM, Chuck Guzis wrote:

> There was also automated "stapled wire".  I forget the name for the process.
> 

stitch wire

you spot weld to a socket post

Re: Front panel switches - what did they do?

[Paul Koning]

> On May 24, 2016, at 2:07 PM, Chuck Guzis  wrote:
> 
> On 05/24/2016 11:00 AM, jwsmobile wrote:
> 
>> Diode boards were one form of read only storage in systems.  Another
>> was the IBM and other's capacitance system.
> 
> ...and the "transformer" ROS used on the 360/40 (and others).

You mean "Core rope memory"?  I just fixed the Wikipedia article to correct the 
history for that technology.

paul

Re: Front panel switches - what did they do?

[Eric Smith]

On Tue, May 24, 2016 at 12:25 PM, Paul Koning  wrote:
>> On May 24, 2016, at 2:07 PM, Chuck Guzis  wrote:
>> ...and the "transformer" ROS used on the 360/40 (and others).
> You mean "Core rope memory"?

IBM's TROS and Core Rope Memory use the same principle, but the
physical construction is significantly different. Core rope memory was
very labor-intensive to manufacture, while TROS was not.

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Brent Hilpert wrote:
> I think one of the most impressive front panels is that of the IBM 360/91:
>   http://www.columbia.edu/cu/computinghistory/36091.html

Ha! I was looking at that and I said to myself "This looks like something 
that'd have been at NASA during the Apollo missions on some old newsreel." 
Then @2 seconds later I see one of the photos has a banner in the 
background saying... "NASA". 

-Swift

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Marc Howard wrote:
> Those aren't LED's on the Apollo display.  They are EL's (Electro 
> Luminescent displays).  Each segment of each digit was controlled by a 
> relay.  They astronauts eventually got use to the tinkling sound of the 
> relays.

Is that the same as the EL that was used in the 1980's on lots of old 
stereo gear ? Ie.. you'd hit rewind and some little backlit 
glass-and-silkscreen template would say "Rewind" in blue or green or etc..

I LOVE the way that looks. That's one of the reasons why I love the Amiga 
CD32 (not that I own one yet). It looks like a hifi stereo component 
from the 1980s. I have a Kenwood electronic EQ and spectrum analyzer that 
has all kinds of EL elements on the front of it. I still use it daily. 
It's awesome. 

-Swift

Re: Front panel switches - what did they do?

[Eric Smith]

On Tue, May 24, 2016 at 12:58 PM, Swift Griggs  wrote:
> Is that the same as the EL that was used in the 1980's on lots of old
> stereo gear ? Ie.. you'd hit rewind and some little backlit
> glass-and-silkscreen template would say "Rewind" in blue or green or etc..

Those were typically vacuum fluorescent (VFD).

Re: Front panel switches - what did they do?

[Paul Anderson]

I used to have a notebook of toggle in programs for the PDP8s and PDP11s,
but it seems to be lost forever.

Not being a software person it takes me hours to write and debug the
simplest routines. Is there a site with a list of toggle in maintenance
programs?

On Tue, May 24, 2016 at 11:23 AM, Charles Anthony <
charles.unix@gmail.com> wrote:

> On Tue, May 24, 2016 at 8:38 AM, Swift Griggs 
> wrote:
>
> >
> > Since I'm an igmo about most machines before the mid-eighties (and still
> > fuzzy even on most of those), I'm curious about all these older machines
> > with front panel buttons and switches. What all did they do? You could
> > actually program them using the front panel right? Some of them
> > bootstrapped this way, too? What kind of "language" was used for that
> > (ie.. what were the basic mechanics)? Did the buttons ever change color?
> > Were you considered a badass if you had switch flipping all memorized
> down
> > to an art? Were they mainly multi-position toggle switches or on/off
> > buttons?
> >
> > They just seem to be a lot more important on older mainframes and minis.
> > Also, what was the main reason for the blinkenlights? Was it to show
> > system load or specific system states?
> >
> > Just curious. I'm learning a ton from reading these threads on older
> > machines, but there is so much I don't know.
> >
> >
> "Older machines" covers a lot of ground.
>
> In my experience (PDP-11, PDP-8 PDP-15, Nova, IBM 709, DPS8 and others),
> the panel switches and lights were for primarily for bootstrapping and
> debugging.
>
> Typically, there was a set of data switches (0/1 toggles) that could be set
> to an address or data value, and a set of command switches (momentary
> contact) that copied the data switches to some data register or memory.
>
> For the earlier or cheaper systems, there was no 'bootstrap ROM'; so a
> small program that was capable of reading the first record of a paper or
> magnetic tape into memory and running it was needed. This program was
> documented in ''machine language' -- a list of binary values that needed to
> be placed in specific memory locations. Hypothetical example (in octal):
>
>  Starting at location 0:
>
> 1456
> 3342
> 3300
> 3040
> 0070
>
> (expressed in octal).
>
> To bootstrap the machine, you loaded a paper tape containing the program
> you wanted to run in the reader. Next, you hit the 'RESET' on the console;
> among other things, that would set the console 'next address' register and
> the instruction counter to 0.
>
> You then set the data switches to 001100101110  (1456 in binary), and press
> 'DEPOSIT'. Thus would copy the data switches to memory at the location in
> the 'next address' register and increment the register. You then repeated
> this for each data value -- toggle in the value, press deposit. When done,
> you pressed 'START'. The RESET had set the instruction counter to 0, so the
> CPU would start executing code at location 0, which contains the 1456
> instruction, and your bootstrap is off and running. It reads  some number
> of characters from the paper tape into memory, and then starts executing
> them. Those characters will be a more complex boot strap loader that will
> read them rest of the tape into memory and run it.
>
> Later or more expensive options of these machines would have a bootstrap
> loader in ROM. Typically, you would toggle in the the address of the ROM
> into the instruction counter and then boot device ID into the data toggles
> and then start the CPU.
>
> For the DPS8 there was a bootstrap ROM, a set of switches specifying card
> reader or tape boot, the device ID and a 'BOOT' button. The data switches
> would be examined by the operating system during boot to enable debugging
> (pause at certain points during boot, eg).
>
> The 709 had these massively over-engineered rocker switches,  reminiscent
> of circuit breakers, and a reset switch which activated a electric motor in
> the console which physically set the switches back to 0.
>
> The PDP-15 had a 'CPU speed' knob. turning it would continuously vary the
> CPU clock from 1Hz to full speed.
>
> The blinking lights typically would have at least the instruction counter
> and the accumulator. Other registers might be displayed, as well as the
> instruction being executed, operand address and value, condition code bits,
> IO activity, interrupt status, and much more.
>
> Watching the instruction counter could reveal the CPU to stuck in a short
> loop; or, if halted, what instruction it was at when it halted.
>
> The console switches and lights could be used to examine memory locations
> as part of debugging.
>
> If the program was stuck in a loop, the console switches could be used to
> halt the CPU and examine where in the program it was looping and the values
> of the variables that controlled the loop.
>
> Some of the mainframes had hundreds and hundreds of lights, detailing the
> internal state of the machin

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 11:22 AM, Al Kossow wrote:
> 
> 
> On 5/24/16 10:44 AM, Chuck Guzis wrote:
> 
>> There was also automated "stapled wire".  I forget the name for the
>> process.
>> 
> 
> stitch wire
> 
> you spot weld to a socket post


Yes, but there was a trademarked name for the process that slips my
mind.  Capable of very high densities.

--Chuck

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 11:39 AM, Eric Smith wrote:
> On Tue, May 24, 2016 at 12:25 PM, Paul Koning
>  wrote:
>>> On May 24, 2016, at 2:07 PM, Chuck Guzis 
>>> wrote: ...and the "transformer" ROS used on the 360/40 (and
>>> others).
>> You mean "Core rope memory"?
> 
> IBM's TROS and Core Rope Memory use the same principle, but the 
> physical construction is significantly different. Core rope memory
> was very labor-intensive to manufacture, while TROS was not.

There's a photo here;

http://www.cs.sun.ac.za/museum/memory.html

I seem to recall that reworking the 360/30 microprogramming was
preferred by tinkerers over the 360/40 was primarily that CROS was
easier to work with than TROS.

I don't recall what the RCA Spectrolas used.

--Chuck

Re: Front panel switches - what did they do?

[Eric Smith]

On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis  wrote:
> Yes, but there was a trademarked name for the process that slips my
> mind.  Capable of very high densities.


Multiwire?

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 11:58 AM, Swift Griggs wrote:
> On Tue, 24 May 2016, Marc Howard wrote:
>> Those aren't LED's on the Apollo display.  They are EL's (Electro 
>> Luminescent displays).  Each segment of each digit was controlled by a 
>> relay.  They astronauts eventually got use to the tinkling sound of the 
>> relays.
> 
> Is that the same as the EL that was used in the 1980's on lots of old 
> stereo gear ? Ie.. you'd hit rewind and some little backlit 
> glass-and-silkscreen template would say "Rewind" in blue or green or etc..
> 
> I LOVE the way that looks. That's one of the reasons why I love the Amiga 
> CD32 (not that I own one yet). It looks like a hifi stereo component 
> from the 1980s. I have a Kenwood electronic EQ and spectrum analyzer that 
> has all kinds of EL elements on the front of it. I still use it daily. 
> It's awesome. 


You might be thinking of vacuum-flourescent displays, the green or green-blue 
displays prevalent on calculators, VCRs, microwave ovens, etc. in the 70-90's 
(sometimes with some red phosphor). The principle of VF displays is essentially 
that of a CRT: vacuum bottle with hot filament emitting electrons accelerated 
to an anode to hit a phosphor to emit light. 

EL (Electro-luminescent) is another technology that more-directly excites the 
phosphor with an AC supply. No vacuum bottle or hot filament. 
Nowhere near as prevalent as VF.

VAX-11/730 and Emulex UC17 woes

[Josh Dersch]

Hi all --

I'm working on restoring a VAX-11/730 at the museum and things have been going 
pretty well thus far.  I've been bootstrapping the console and diagnostics from 
simulated TU58 (images from: https://github.com/NF6X/VAX-11-730-Console-v57).  
All of the TU58-based diagnostics are passing.

I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage and 
I'm having trouble with it.  I thought I'd check with you guys to see if any of 
you have seen this issue or have any idea where I might be obviously going 
wrong before I start digging deeper into this.

The current issue is that I can't get the UC17's built in diagnostic/utility 
(referred to as the 'FRD' in the manual) to run.  I am following all of the 
steps to the letter (see the manual here 
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C_UC17_Dec90.pdf,
 pages 71-79 (section 4.5.7)) and I'm getting the right values back when 
examining the SA register during the process, but executing "S 80" halts after 
a second or so with:

?08  PC=0298

Which is an odd way for it to halt, 08 means "No user WCS" according to the 
11/730 user's guide.  

Here's the full conversation, just in case:

>>> I
>>> D/L/P F26800 8000
>>> D/L/P F26804 8001
>>> D/W/P FFF46A 3003
>>> E/W/P FFF46A
P 00FFF46A  0100
>>> D/W/P FFF46A 4401
>>> E/W/P FFF46A
P 00FFF46A  0400
>>> S 80

?08  PC=0298

I've confirmed that the issue isn't with the card, I can run the FRD without 
issue on it, in an 11/44 we have here.

I've done my best to ensure that everything is sane on the UNIBUS; my 
understanding from the 11/730 manuals is that by default none of the SPC slots 
have the NPG wire-wrap fitted and that any empty SPC slots need to have an NPG 
grant card installed.  (This makes sense given how difficult the backplane is 
to access, it requires pulling the power supply out first.)  Just to make sure, 
I have double-checked that the NPG wirewrap jumper is not present on Slot 10, 
where the UC17 is installed.  At the moment the grant chain should be unbroken 
as far as I can tell, here is the current configuration:

TOP
Slot 1 -Empty (normally RB730 option)
Slot 2- Empty (normally FPA option)
Slot 3- M8390 (DAP)
Slot 4- M8391 (MCT)
Slot 5- M8394 (WCS)
Slot 6- M8750 (1mb memory)
Slot 7- M8750 (1mb memory)
Slot 8- M8750 (1mb memory)
Slot 9- M8750 (1mb memory)
Slot 10- Emulex UC17
Slot 11- DMF32-AA
Slot 12- M9302 terminator | G7273 grant
BOTTOM

Thanks as always for the help.
- Josh

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 12:08 PM, Chuck Guzis wrote:
> On 05/24/2016 11:22 AM, Al Kossow wrote:
>> 
>> On 5/24/16 10:44 AM, Chuck Guzis wrote:
>> 
>>> There was also automated "stapled wire".  I forget the name for the
>>> process.
>> 
>> stitch wire
>> 
>> you spot weld to a socket post
> 
> Yes, but there was a trademarked name for the process that slips my
> mind.  Capable of very high densities.


I've wondered what the trade name for this was:
http://www.cs.ubc.ca/~hilpert/e/HP21xx/pics/large/crimps.jpg

Mid-late 60s usage but I've never heard a name for it.
Note the posts are not square - they're not standard wire-wrap posts with a 
different connector.

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 10:00 AM, Charles Anthony <
charles.unix@gmail.com> wrote:

>
>
> On Tue, May 24, 2016 at 9:44 AM, Swift Griggs 
> wrote:
>
>>
>> It probably still impressed the suits when they walked the data center.
>> I've done data center tours with row after row of HP or Dell x86 servers
>> and it's not much to look at.
>>
>>
> Definitely.
>
> Several OSes would show distinctive 'idle' patterns on the lights, this
> provided a quick visual cue about system load for the big multi-user
> systems.
>
> As I understand it, the Transputer (an early multicpu system designed to
> parallel computation had a simple buf effective display -- an LED for for
> each CPU indicatiing if the CPU was working or idle, this told you at a
> glance if you parallelization algortihim was effective.
>
>
Oops. Connection Machine, not Transputer.



> -- Charles
>
>

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 12:18 PM, Brent Hilpert wrote:

> EL (Electro-luminescent) is another technology that more-directly
> excites the phosphor with an AC supply. No vacuum bottle or hot
> filament. Nowhere near as prevalent as VF.

You still see them in military/aerospace applications. Planar used to be
industry leader in those, but it was acquired a couple of years ago by a
Finnish outfit, Beneq.

The business unit is called Lumineq:

http://lumineq.com/

Thin-film EL displays are pretty cool.  They're transparent.  Like all
modern EL displays, they're pre-patterned with display elements.

--Chuck

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 12:15 PM, Eric Smith wrote:
> On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis 
> wrote:
>> Yes, but there was a trademarked name for the process that slips
>> my mind.  Capable of very high densities.
> 
> 
> Multiwire?

That sounds familiar!

--Chuck

Re: VAX-11/730 and Emulex UC17 woes

[Glen Slick]

On Tue, May 24, 2016 at 12:27 PM, Josh Dersch
 wrote:
> Hi all --
>
> I'm working on restoring a VAX-11/730 at the museum and things have been 
> going pretty well thus far.  I've been bootstrapping the console and 
> diagnostics from simulated TU58 (images from: 
> https://github.com/NF6X/VAX-11-730-Console-v57).  All of the TU58-based 
> diagnostics are passing.
>
> I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage 
> and I'm having trouble with it.  I thought I'd check with you guys to see if 
> any of you have seen this issue or have any idea where I might be obviously 
> going wrong before I start digging deeper into this.
>
> The current issue is that I can't get the UC17's built in diagnostic/utility 
> (referred to as the 'FRD' in the manual) to run.  I am following all of the 
> steps to the letter (see the manual here 
> http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C_UC17_Dec90.pdf,
>  pages 71-79 (section 4.5.7)) and I'm getting the right values back when 
> examining the SA register during the process, but executing "S 80" halts 
> after a second or so with:
>
> ?08  PC=0298
>
> Which is an odd way for it to halt, 08 means "No user WCS" according to the 
> 11/730 user's guide.
>
> Here's the full conversation, just in case:
>
 I
 D/L/P F26800 8000
 D/L/P F26804 8001
 D/W/P FFF46A 3003
 E/W/P FFF46A
> P 00FFF46A  0100
 D/W/P FFF46A 4401
 E/W/P FFF46A
> P 00FFF46A  0400
 S 80
>
> ?08  PC=0298
>
> I've confirmed that the issue isn't with the card, I can run the FRD without 
> issue on it, in an 11/44 we have here.
>

Don't know if this will help at all.  Not sure if the UC07 and UC17
share the same firmware and VAX host resident FRD code. On the QBus
UC07 version (firmware version G143R) there is a short stub located at
80h which jumps to the main code at 280h. (If you have a VCB02 instead
of a serial console you start at 82h which then jumps to 282h and does
something slightly different).

I dumped the memory for this code from the VAX and entered it into
SIMH to use SIMH as an VAX unassembler and this is what it looks like.
If the UC17 host resident VAX code is the same, any clues here as to
what might be causing a halt on the 11/730?

sim> e -m 80-87
80: BRB 85
82: BRW 282
85: BRW 280

sim> e -m 280-3d3
280:BRB 298
282:BISB2 #1,27F
286:MOVL #8003,@#2008800C
291:MTPR #800,#4
298:MOVL #8002,@#20088008
2A3:NOP
2A4:MTPR #1F,#12
2A7:MOVAL 400,R1
2AE:MOVL #200,R2
2B5:MOVL #0,(R1)+
2B8:SOBGTR R2,2B5
2BB:MOVL #20001468,R5
2C2:CLRW (R5)
2C4:BITW #800,2(R5)
2CA:BEQL 2C4
2CC:MOVW #3003,2(R5)
2D2:CMPW #100,2(R5)
2D8:BNEQ 2D2
2DA:MOVW #4600,2(R5)
2E0:CMPW #400,2(R5)
2E6:BNEQ 2E0
2E8:MOVW #400,2(R5)
2EE:TSTB 27F
2F1:BEQL 30E
2F3:MOVL #1,R0
2F6:JSB @#20040008
2FC:CMPB #18,R0
2FF:BNEQ 304
301:BRW 362
304:EXTZV #0,#7,R0,R0
309:MOVL R0,R2
30C:BRB 338
30E:MFPR #20,R1
311:BBC #7,R1,362
315:MFPR #21,R2
318:EXTZV #0,#7,R2,R2
31D:CMPB R2,#13
320:BNEQ 338
322:MFPR #20,R0
325:BBC #7,R0,322
329:MFPR #21,R0
32C:EXTZV #0,#7,R0,R0
331:CMPB R0,#11
334:BNEQ 322
336:BRB 362
338:BISW2 #200,R2
33D:MOVW R2,2(R5)
341:MOVW 2(R5),R2
345:BITW #200,R2
34A:BEQL 341
34C:BICL2 #200,R2
353:MOVW R2,2(R5)
357:MOVW 2(R5),R2
35B:BITW #200,R2
360:BNEQ 357
362:MOVW 2(R5),R2
366:BITW #100,R2
36B:BEQL 2EE
36D:MOVW R2,2(R5)
371:MOVW 2(R5),R2
375:BITW #100,R2
37A:BNEQ 371
37C:BICW2 #100,R2
381:MOVW R2,2(R5)
385:EXTZV #0,#7,R2,R2
38A:BEQL 3C4
38C:TSTB 27F
390:BEQL 3B3
392:MOVB R2,3CF
399:MOVAL 3C7,R0
3A0:JSB @#2004000C
3A6:MOVW 2(R5),R2
3AA:BITW #100,R2
3AF:BEQL 3A6
3B1:BRB 36D
3B3:MFPR #22,R1
3B6:BBC #7,R1,3B3
3BA:MTPR R2,#23
3BD:MFPR #22,R1
3C0:BBC #7,R1,3BD
3C4:BRW 2EE

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 11:39 AM, Eric Smith wrote:
> On Tue, May 24, 2016 at 12:25 PM, Paul Koning  wrote:
>>> On May 24, 2016, at 2:07 PM, Chuck Guzis  wrote:
>>> ...and the "transformer" ROS used on the 360/40 (and others).
>> You mean "Core rope memory"?
> 
> IBM's TROS and Core Rope Memory use the same principle, but the
> physical construction is significantly different. Core rope memory was
> very labor-intensive to manufacture, while TROS was not.


We were discussing this last year, perhaps I'm being pedantic but I would note 
that while, as you say, there is commonality of principle in use of induction 
and the selective weave to represent the data, TROS and core rope (of the sort 
used in the AGC) also have differences in their principles of operation - 
they're not just physical variations on each other.

Re: Front panel switches - what did they do?

[Norman Jaffe]

The IBM 1800 was a much simpler machine than the IBM 360/370, yet it had a 
pretty complex front panel - 
http://www.dvq.com/1800/photos/paneln.JPG 
... since not all of the registers could be displayed at the same time . 
- Original Message -

From: "Paul Berger"  
To: cctalk@classiccmp.org 
Sent: Tuesday, May 24, 2016 10:18:45 AM 
Subject: Re: Front panel switches - what did they do? 

On 2016-05-24 1:54 PM, Swift Griggs wrote: 
> On Tue, 24 May 2016, Charles Anthony wrote: 
>> Honeywell 6180 display panels: 
>> http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html
>>  
> Holy rocker switch, Batman! Is that all for one machine? That looks like a 
> man-machine interface to run a nuclear power plant or something. FOUR 
> panels. The black panel looks uber-cool. That definitely looks like 
> something from a 60's or 70's James bond film. There needs to be a villain 
> about ready to launch a missile standing next to one. 
> 
> Oh and here is a replica of an Apollo launch computer with a component LED 
> display like I was mentioning: 
> 
> http://i.imgur.com/bbXZVcx.jpg 
> 
> ... probably too expensive to embed in a computer system, but still hard 
> to beat for geek aesthetics. 
> 
> -Swift 
> 
> 
The most impressive one I ever saw was when I was in technician school 
we had a tour of the underground in North Bay Ont. where we saw what was 
probably the last running AN/FSQ-7, the operator panel was very impressive. 

Some of the early 370 systems that still had blinkenlights only had one 
or two rows and rotary switchs selected what you where viewing. 
Attached to the switch there was a cylinder behind the panel that showed 
a legend of what the lights meant for the selected location. The also 
had hex dials on the panel for data input. 

Paul. 

Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[David Collins]

I realised the attachments wouldn't show in the general email but I figured the 
only people who needed the binaries right now were the original posters who got 
them directly from the email.  

I'll put up the binaries of my EPROMs and the ones of yours when you post them 
as downloads in the museum website over the next few days so they are there for 
the future for anyone else who might need them.

Martin/Joachim, let us know if any of the files you now have or will get fixes 
your issue and if a Draftmaster II  is saved as a result!!

David Collins
www.hpmuseum.net

> On 25 May 2016, at 2:17 AM, Ethan Dicks  wrote:
> 
> On Tue, May 24, 2016 at 10:25 AM, David Collins
>  wrote:
>> Here are the binaries for all the EPROMs on processor PCA for my 7596A.  The
>> PCA part number is 07595-60100 and is different from the one in the manual
>> which is a 07595-60200 so I assume my PCA is older than the one in the
>> manual.
> 
> I did not have an 8mm socket wrench with me when I visited my 7596A so
> I wasn't able to entirely remove the cover.  I did slip the camera in
> under the lower edge and did extract U28 and U37 from mine for
> dumping...
> 
>> The EPROMs on the PCA are as follows:
>> 
>> 17225-18001 U26
>> 17225-18002 U35
>> 17225-18003 U41
>> 17225-18004 U42
> 
> These were empty on my plotter, best I could tell.
> 
>> 07595-18097 U28
>> 07595-18098 U37
> 
> I found these in those sockets:
> 
> 07595-18095  U28
> 07595-18096  U37
> 
>> Unknown U27 - no part number label
>> Unknown U36 - no part number label
> 
> These sockets are definitely empty on my plotter.
> 
>> Binaries for each chip are attached. All are 27512 EPROMs.
> 
> This list doesn't support attachments, so most of us didn't get them.
> 
> I'm happy to send along my copies of 07595-18095 / 07595-18096 when I
> get them read out.
> 
> -ethan

Re: VAX-11/730 and Emulex UC17 woes

[Mike Ross]

On Wed, May 25, 2016 at 7:27 AM, Josh Dersch
 wrote:
> Hi all --
>
> I'm working on restoring a VAX-11/730 at the museum and things have been 
> going pretty well thus far.  I've been bootstrapping the console and 
> diagnostics from simulated TU58 (images from: 
> https://github.com/NF6X/VAX-11-730-Console-v57).  All of the TU58-based 
> diagnostics are passing.
>
> I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage 
> and I'm having trouble with it.  I thought I'd check with you guys to see if 
> any of you have seen this issue or have any idea where I might be obviously 
> going wrong before I start digging deeper into this.
>
> The current issue is that I can't get the UC17's built in diagnostic/utility 
> (referred to as the 'FRD' in the manual) to run.  I am following all of the 
> steps to the letter (see the manual here 
> http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C_UC17_Dec90.pdf,
>  pages 71-79 (section 4.5.7)) and I'm getting the right values back when 
> examining the SA register during the process, but executing "S 80" halts 
> after a second or so with:
>
> ?08  PC=0298
>
> Which is an odd way for it to halt, 08 means "No user WCS" according to the 
> 11/730 user's guide.
>
> Here's the full conversation, just in case:
>
 I
 D/L/P F26800 8000
 D/L/P F26804 8001
 D/W/P FFF46A 3003
 E/W/P FFF46A
> P 00FFF46A  0100
 D/W/P FFF46A 4401
 E/W/P FFF46A
> P 00FFF46A  0400
 S 80
>
> ?08  PC=0298
>
> I've confirmed that the issue isn't with the card, I can run the FRD without 
> issue on it, in an 11/44 we have here.
>
> I've done my best to ensure that everything is sane on the UNIBUS; my 
> understanding from the 11/730 manuals is that by default none of the SPC 
> slots have the NPG wire-wrap fitted and that any empty SPC slots need to have 
> an NPG grant card installed.  (This makes sense given how difficult the 
> backplane is to access, it requires pulling the power supply out first.)  
> Just to make sure, I have double-checked that the NPG wirewrap jumper is not 
> present on Slot 10, where the UC17 is installed.  At the moment the grant 
> chain should be unbroken as far as I can tell, here is the current 
> configuration:
>
> TOP
> Slot 1 -Empty (normally RB730 option)
> Slot 2- Empty (normally FPA option)
> Slot 3- M8390 (DAP)
> Slot 4- M8391 (MCT)
> Slot 5- M8394 (WCS)
> Slot 6- M8750 (1mb memory)
> Slot 7- M8750 (1mb memory)
> Slot 8- M8750 (1mb memory)
> Slot 9- M8750 (1mb memory)
> Slot 10- Emulex UC17
> Slot 11- DMF32-AA
> Slot 12- M9302 terminator | G7273 grant
> BOTTOM
>
> Thanks as always for the help.
> - Josh

That sounds a HELL of a lot like the issues I was having - and which I
haven't resolved yet. Someone provided me with a hex dump of memory
starting at location 80 as you say and what I found was that the code
I was seeing that the UC17 had loaded into memory had several
locations with quite different values to those that had been dumped
from a working system. I did the obvious and manually deposited at
least the first few 'wrong' locations to the 'correct' values; the
behaviour changed. Instead of halting with an error the run light
stayed on but no utility menu was displayed; the machine was hung. I
recently obtained and very briefly tried a second UC17 with similar
results - except on this card (same firmware version) the values in
memory prior to 'S 80' were even more 'wrong'.

Haven't got further yet but will have a hack in a few days. Do you
know beyond peradventure that the NPG wire-wrap IS removed? I don't
and will have to check.

My 11/730 also  passed all diags - well until it got to the RL02 bit
where it failed due to no RL02!

Mike


http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

Re: ND-10 software - Re: Harris H800 Computer

[Liam Proven]

On 23 May 2016 at 13:25, Torfinn Ingolfsen  wrote:
> On Sun, May 22, 2016 at 2:00 PM, Mattis Lind  wrote:
>>
>> Isn't it possible to run dosemu on FreeBSD?  I use imdv in dosemu on Linux.
>
> Unfortunately, dosemu only works on i386, not amd64.


Is that a *BSD thing? I run DOSemu on both my x86-64 Linux laptops, no problem.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Front panel switches - what did they do?

[jwsmobile]

We bought a Multiwire job on our clone of the Microdata 1600 and the 
tech it used, I think, was welded wires laid in muck that was soft.


They would fab up a firm carrier board with all the thru-holes set, then 
put down a soft pliable layer of epoxy(??).  They would weld one of the 
wires to an appropriate thru-hole then the wire would be pushed into the 
media and routed to the terminus.  Similar to wirewrap process from the 
routing requirements (keep number of connections to any post / thruhole 
adhering to design rules).  But when it was complete, you could see all 
the wires thru the goo they used after it hardened or was set up.


The set we had worked well, but was about 3500 bucks for an 
approximately 8 x 10 board with a 130pin edge card connector.  Kinda 
pricy.  However, if you had a working design, it was overnight 
turnaround with a PC.


thanks
Jim

On 5/24/2016 12:15 PM, Eric Smith wrote:

On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis  wrote:

Yes, but there was a trademarked name for the process that slips my
mind.  Capable of very high densities.


Multiwire?

Re: ND-10 software - Re: Harris H800 Computer

[Torfinn Ingolfsen]

Hello,

On Tue, May 24, 2016 at 10:24 PM, Liam Proven  wrote:
> On 23 May 2016 at 13:25, Torfinn Ingolfsen  wrote:
>> On Sun, May 22, 2016 at 2:00 PM, Mattis Lind  wrote:
>>>
>>> Isn't it possible to run dosemu on FreeBSD?  I use imdv in dosemu on Linux.
>>
>> Unfortunately, dosemu only works on i386, not amd64.
>
>
> Is that a *BSD thing? I run DOSemu on both my x86-64 Linux laptops, no 
> problem.

Possibly. Perhaps even just a FreeBSD thing.
My Fedora laptop lists dosemu packages for both i686 and x86-64:
[tingo@localhost ~]$ sudo dnf list dosemu
Last metadata expiration check: 2:48:48 ago on Tue May 24 19:37:09 2016.
Available Packages
dosemu.i686
1.4.0.8-18.20131022git.fc22
rpmfusion-free
dosemu.x86_64
1.4.0.8-18.20131022git.fc22
rpmfusion-free



-- 
Regards,
Torfinn Ingolfsen

Re: strangest systems I've sent email from

[Liam Proven]

On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote:
> Because the 808x was a 16-bit processor with 1MB physical addressing.  I
> would argue that for the time 808x was brilliant in that most other 16-bit
> micros only allowed for 64KB physical.


Er, hang on. I'm not sure if my knowledge isn't good enough or if that's a typo.

AFAIK most *8* bits only supported 64 kB physical. Most *16* bits
(e.g. 68000, 65816, 80286, 80386SX) supported 16MB physical RAM.

Am I missing something here?

I always considered the 8088/8086 as a sort of hybrid 8/16-bit processor.


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Front panel switches - what did they do?

[Brent Hilpert]

> On 5/24/2016 12:15 PM, Eric Smith wrote:
>> On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis  wrote:
>>> Yes, but there was a trademarked name for the process that slips my
>>> mind.  Capable of very high densities.
>> 
>> Multiwire?


On 2016-May-24, at 1:26 PM, jwsmobile wrote:

> We bought a Multiwire job on our clone of the Microdata 1600 and the tech it 
> used, I think, was welded wires laid in muck that was soft.
> 
> They would fab up a firm carrier board with all the thru-holes set, then put 
> down a soft pliable layer of epoxy(??).  They would weld one of the wires to 
> an appropriate thru-hole then the wire would be pushed into the media and 
> routed to the terminus.  Similar to wirewrap process from the routing 
> requirements (keep number of connections to any post / thruhole adhering to 
> design rules).  But when it was complete, you could see all the wires thru 
> the goo they used after it hardened or was set up.
> 
> The set we had worked well, but was about 3500 bucks for an approximately 8 x 
> 10 board with a 130pin edge card connector.  Kinda pricy.  However, if you 
> had a working design, it was overnight turnaround with a PC.


I haven't so much as seen a multi-wire board since ca. 1980, even in all the 
scrap and junk and surplus I've seen in the decades since.
The primary example I recall from then was a big disk controller board for a 
TI-990/10.

RE: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[David Collins]

Here's a link to the files I have.  I'll update this with the additional
images from Ethan when they are available and put a front end to the files
in the museum. 

http://www.hpmuseum.net/software/7595Afirmware.zip

David Collins

 
-Original Message-
From: David Collins [mailto:davidk.coll...@bigpond.com] 
Sent: Wednesday, 25 May 2016 12:26 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
; 'mar...@shackspace.de' ;
'Joachim Fenkes' 
Subject: RE: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

Here are the binaries for all the EPROMs on processor PCA for my 7596A.  The
PCA part number is 07595-60100 and is different from the one in the manual
which is a 07595-60200 so I assume my PCA is older than the one in the
manual. 

The EPROMs on the PCA are as follows:

17225-18001 U26
17225-18002 U35
17225-18003 U41
17225-18004 U42
07595-18097 U28
07595-18098 U37
Unknown U27 - no part number label 
Unknown U36 - no part number label

Binaries for each chip are attached. All are 27512 EPROMs.

I have also included photos of the PCA and the EPROMs in position.  Hope
that helps.

David Collins
Curator
HP Computer Museum
www.hpmuseum.net
 

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Martin
Peters
Sent: Monday, 23 May 2016 5:50 AM
To: General Discussion: On-Topic and Off-Topic Posts 
Subject: Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

Hi David!

David Collins:
> Martin, I might be able to help you as I think we have a 7596A.

Great! :)

> Are these EPROMs from the processor PCA?

I think so.

> Are you able to tell me which 'U'
> numbers they are in the PC board? 

No, not now. The plotter is in the shackspace in Stuttgart and I was not
there for several weeks and now I found an email saying they want to get rid
of it. I already asked for the dumps here one year ago and now it seems to
be really urgent.

> I haven't looked at the plotter itself, but the service manual we have 
> shows the following part numbers for the processor PCA
> 
> 07595-18039
> 07595-18040
> 07595-18041
> 07595-18042

I know. As I was told by the guy who took a look inside one year ago, these
parts do not exist in the revision we own. But I think, they only put the
firmware in two EPROMs at HP in a newer revision of the board.
And if not "only", I think the dumps would be helpful anyway. It would be
great if you could do a dump for me :-)

Many thanks,
Martin
--
Martin Peters
mar...@shackspace.de

Re: Front panel switches - what did they do?

[Eric Smith]

On Tue, May 24, 2016 at 1:49 PM, Brent Hilpert  wrote:
> We were discussing this last year, perhaps I'm being pedantic but I would 
> note that while, as you say, there is commonality of principle in use of 
> induction and the selective weave to represent the data, TROS and core rope 
> (of the sort used in the AGC) also have differences in their principles of 
> operation - they're not just physical variations on each other.

My understanding is that both used drive lines that either went
through the transformer, or around it, to either couple a drive line
to a sense line, or not. In the case of CRM, the wires are essentially
braided with the cores, while in TROS, holes are punched in strips of
flex circuit to break one of the two paths the drive line can take for
each sense position, and the transformer core is a two-part
rectangular thing rather than a little toroid.

If I'm wrong, or missing some fine point distinguishing them, I'd
welcome corrections or additional information.

RE: VAX-11/730 and Emulex UC17 woes

[Josh Dersch]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Glen Slick
> Sent: Tuesday, May 24, 2016 12:48 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: VAX-11/730 and Emulex UC17 woes
> 
> On Tue, May 24, 2016 at 12:27 PM, Josh Dersch
>  wrote:
> > Hi all --
> >
> > I'm working on restoring a VAX-11/730 at the museum and things have
> been going pretty well thus far.  I've been bootstrapping the console and
> diagnostics from simulated TU58 (images from:
> https://github.com/NF6X/VAX-11-730-Console-v57).  All of the TU58-based
> diagnostics are passing.
> >
> > I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage
> and I'm having trouble with it.  I thought I'd check with you guys to see if 
> any
> of you have seen this issue or have any idea where I might be obviously
> going wrong before I start digging deeper into this.
> >
> > The current issue is that I can't get the UC17's built in diagnostic/utility
> (referred to as the 'FRD' in the manual) to run.  I am following all of the 
> steps
> to the letter (see the manual here
> http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC175
> 1001-C_UC17_Dec90.pdf, pages 71-79 (section 4.5.7)) and I'm getting the
> right values back when examining the SA register during the process, but
> executing "S 80" halts after a second or so with:
> >
> > ?08  PC=0298
> >
> > Which is an odd way for it to halt, 08 means "No user WCS" according to the
> 11/730 user's guide.
> >
> > Here's the full conversation, just in case:
> >
>  I
>  D/L/P F26800 8000
>  D/L/P F26804 8001
>  D/W/P FFF46A 3003
>  E/W/P FFF46A
> > P 00FFF46A  0100
>  D/W/P FFF46A 4401
>  E/W/P FFF46A
> > P 00FFF46A  0400
>  S 80
> >
> > ?08  PC=0298
> >
> > I've confirmed that the issue isn't with the card, I can run the FRD without
> issue on it, in an 11/44 we have here.
> >
> 
> Don't know if this will help at all.  Not sure if the UC07 and UC17 share the
> same firmware and VAX host resident FRD code. On the QBus
> UC07 version (firmware version G143R) there is a short stub located at 80h
> which jumps to the main code at 280h. (If you have a VCB02 instead of a
> serial console you start at 82h which then jumps to 282h and does something
> slightly different).

Interesting, the UC17 has the same firmware version (G143R) on the label of the 
EPROM.  I wonder if the contents are identical.  Could you send me a dump of 
your ROM so I can compare?

> 
> I dumped the memory for this code from the VAX and entered it into SIMH
> to use SIMH as an VAX unassembler and this is what it looks like.
> If the UC17 host resident VAX code is the same, any clues here as to what
> might be causing a halt on the 11/730?

The values in/around 298 look to be identical, but I haven't dumped everything 
in memory.  I'll poke at the code, do some disassembly and see I can figure out 
what's going on...

Thanks!
Josh

> 
> sim> e -m 80-87
> 80: BRB 85
> 82: BRW 282
> 85: BRW 280
> 
> sim> e -m 280-3d3
> 280:BRB 298
> 282:BISB2 #1,27F
> 286:MOVL #8003,@#2008800C
> 291:MTPR #800,#4
> 298:MOVL #8002,@#20088008
> 2A3:NOP
> 2A4:MTPR #1F,#12
> 2A7:MOVAL 400,R1
> 2AE:MOVL #200,R2
> 2B5:MOVL #0,(R1)+
> 2B8:SOBGTR R2,2B5
> 2BB:MOVL #20001468,R5
> 2C2:CLRW (R5)
> 2C4:BITW #800,2(R5)
> 2CA:BEQL 2C4
> 2CC:MOVW #3003,2(R5)
> 2D2:CMPW #100,2(R5)
> 2D8:BNEQ 2D2
> 2DA:MOVW #4600,2(R5)
> 2E0:CMPW #400,2(R5)
> 2E6:BNEQ 2E0
> 2E8:MOVW #400,2(R5)
> 2EE:TSTB 27F
> 2F1:BEQL 30E
> 2F3:MOVL #1,R0
> 2F6:JSB @#20040008
> 2FC:CMPB #18,R0
> 2FF:BNEQ 304
> 301:BRW 362
> 304:EXTZV #0,#7,R0,R0
> 309:MOVL R0,R2
> 30C:BRB 338
> 30E:MFPR #20,R1
> 311:BBC #7,R1,362
> 315:MFPR #21,R2
> 318:EXTZV #0,#7,R2,R2
> 31D:CMPB R2,#13
> 320:BNEQ 338
> 322:MFPR #20,R0
> 325:BBC #7,R0,322
> 329:MFPR #21,R0
> 32C:EXTZV #0,#7,R0,R0
> 331:CMPB R0,#11
> 334:BNEQ 322
> 336:BRB 362
> 338:BISW2 #200,R2
> 33D:MOVW R2,2(R5)
> 341:MOVW 2(R5),R2
> 345:BITW #200,R2
> 34A:BEQL 341
> 34C:BICL2 #200,R2
> 353:MOVW R2,2(R5)
> 357:MOVW 2(R5),R2
> 35B:BITW #200,R2
> 360:BNEQ 357
> 362:MOVW 2(R5),R2
> 366:BITW #100,R2
> 36B:BEQL 2EE
> 36D:MOVW R2,2(R5)
> 371:MOVW 2(R5),R2
> 375:BITW #100,R2
> 37A:BNEQ 371
> 37C:BICW2 #100,R2
> 381:MOVW R2,2(R5)
> 385:EXTZV #0,#7,R2,R2
> 38A:BEQL 3C4
> 38C:TSTB 27F
> 390:BEQL 3B3
> 392:MOVB R2,3CF
> 399:MOVAL 3C7,R0
> 3A0:JSB @#2004000C
> 3A6:MOVW 2(R5),R2
> 3AA:BITW #100,R2
> 3AF:BEQL 3A6
> 3B1:BRB 36D
> 3B3:MFPR #22,R1
> 3B6:BBC #7,R1,3B3
> 3BA:MTPR R2,#23
> 3BD:MFPR #22,R1
> 3C0:BBC #7,R1,3BD
> 3C4:BRW 2EE

Re: strangest systems I've sent email from

[Norman Jaffe]

Without an MMU or a segmentation scheme, 16-bits = 64K. 
The 68000 is not a 16-bit processor, it's 32-bit, and exposed (ISTR) a 24-bit 
address. 
20-bits = 1M addresses, 24-bits = 16M addresses. 
You're confusing data bus width (8-bit) with address bus width (16-bit). 
- Original Message -

From: "Liam Proven"  
To: "General Discussion: On-Topic and Off-Topic Posts"  
Sent: Tuesday, May 24, 2016 1:29:48 PM 
Subject: Re: strangest systems I've sent email from 

On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote: 
> Because the 808x was a 16-bit processor with 1MB physical addressing. I 
> would argue that for the time 808x was brilliant in that most other 16-bit 
> micros only allowed for 64KB physical. 


Er, hang on. I'm not sure if my knowledge isn't good enough or if that's a 
typo. 

AFAIK most *8* bits only supported 64 kB physical. Most *16* bits 
(e.g. 68000, 65816, 80286, 80386SX) supported 16MB physical RAM. 

Am I missing something here? 

I always considered the 8088/8086 as a sort of hybrid 8/16-bit processor. 


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile 
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven 
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven 
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR) 

Re: Front panel switches - what did they do?

[Brent Hilpert]

On 2016-May-24, at 1:49 PM, Eric Smith wrote:
> On Tue, May 24, 2016 at 1:49 PM, Brent Hilpert  wrote:
>> We were discussing this last year, perhaps I'm being pedantic but I would 
>> note that while, as you say, there is commonality of principle in use of 
>> induction and the selective weave to represent the data, TROS and core rope 
>> (of the sort used in the AGC) also have differences in their principles of 
>> operation - they're not just physical variations on each other.
> 
> My understanding is that both used drive lines that either went
> through the transformer, or around it, to either couple a drive line
> to a sense line, or not. In the case of CRM, the wires are essentially
> braided with the cores, while in TROS, holes are punched in strips of
> flex circuit to break one of the two paths the drive line can take for
> each sense position, and the transformer core is a two-part
> rectangular thing rather than a little toroid.
> 
> If I'm wrong, or missing some fine point distinguishing them, I'd
> welcome corrections or additional information.


Yes, I examined this in some detail last year after mention on the list, and 
wrote it up:

http://www.cs.ubc.ca/~hilpert/e/corerope/index.html

The short of it is, schemes like TROS are using simple induction / transformer 
principles with a selective weave through the transformer cores to represent 
the data. In contrast, (AGC-style) core ropes are using switching cores and 
core-logic principles to also do the 1-of-n address decoding within the cores. 
The address decoding requires a varied weave of address wires through the 
cores, in addition to the selective weave for the data. The read/access 
operation also becomes far more complex for the AGC-style core rope.

Re: strangest systems I've sent email from

[Fred Cisin]

On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote:

Because the 808x was a 16-bit processor with 1MB physical addressing.  I
would argue that for the time 808x was brilliant in that most other 16-bit
micros only allowed for 64KB physical.


Whether 8088 was an "8 bit" or "16 bit" processor depends heavily on how 
you define those.
Or, you could phrase it, that the 8 bit processors at the time handled 
64KiB of RAM.  The 808x still could see only 64KiB at a time, but let you 
place that 64kiB almost anywhere that you wanted in a total RAM space of 
1MiB, and let you set 4 "preset" locations (CS, DS, SS, ES).  There were 
some instructions, such as MOV, that could sometimes operate with 2 of 
those presets.
Thus, they expanded a 64KiB RAM processor to 1MiB, with minimal internal 
changes.



As opposed to starting over from scratch, ala Motorola.

Starting over from scratch made it possible to build an arguably better 
processor, whereas doing minimal changes reduced (and sometimes even 
eliminated) the need to rewrite existing code.
Which is more important - theoretically better processor, or availability 
of existing software?   Not everybody would choose the same.


It was claimed that in porting Wordstar to PC, Micropro took longer to 
change the manual than to get the software working.
Accordingly, software availability for the PC was more "immediate" than 
for the Mac.   Both had extensive software availability by the end of the 
1980s, but how about during the first 6 months after release of the 
machine?


Since "Nobody programs in assembly any more, nor ever will again" 
(-Clancy/Harvey), that isn't as big a deal as it once was.




(OB_Picky:  Due to the overlap of segment and offset, on machines that had 
21 address bits, real mode actually had a maximum of 1114096 (10FFF0h) 
bytes, instead of 1048576 (10h).  That was accessed by HIMEM.SYS at a 
time when memory space was scarce enough that another 64K could make a 
big difference.)

Re: VAX-11/730 and Emulex UC17 woes

[Mike Ross]

On Wed, May 25, 2016 at 8:58 AM, Josh Dersch
 wrote:

> Interesting, the UC17 has the same firmware version (G143R) on the label of 
> the EPROM.  I wonder if the contents are identical.  Could you send me a dump 
> of your ROM so I can compare?
>
>>
>> I dumped the memory for this code from the VAX and entered it into SIMH
>> to use SIMH as an VAX unassembler and this is what it looks like.
>> If the UC17 host resident VAX code is the same, any clues here as to what
>> might be causing a halt on the 11/730?

Here's what I found comparing my code with someone else's dump:

I've been working this with Glen Slick. Here's a snippet of a recent
email with him. He provided a dump of the DMAed loader from his UC07:

The raw binary dumped on the VAX looked like this:

>>>E/P/L 80
P 0080 FD310311
>>>E
P 0084 01F83101

>>>E
P 0280 01881611
>>>E
P 0284 8FD0F9AF
>>>E
P 0288 8003
>>>E
P 028C 08800C9F
>>>E
P 0290 008FDA20
>>>E
P 0294 0408
>>>E
P 0298 00028FD0
>>>E
P 029C 089F8000
>>>E
P 02A0 01200880

First mismatch is here; P 02A0 0100F308

>>>E
P 02A4 DE121FDA
>>>E
P 02A8 000153EF
>>>E
P 02AC 8FD05100
>>>E
P 02B0 0200
>>>E
P 02B4 8100D052
>>>E
P 02B8 D0FA52F5
>>>E
P 02BC 0014688F

But mine has P 02BC FFF4688F

>>>E
P 02C0 65B45520

Mine had P 02C0 65B45500

>>>E

Ran out of time at this point - but enough to establish at least
*some* values are different.

Tried S 80 - different error! ?05 PC=0344

I did 'I' then started from scratch - D/L/P F26800... etc.

Same result.

Here's a quote from an email exchange from a couple of months ago on
same issue: dumb question: have you tried just booting it without
running FRD?

"I think that UC17 is identical to UC07 firmware-wise. At least my
UC17 EPROM is marked UC07. There is some posts on vcfed.org forum on
UC07 firmware quite recently.
Why do you need to enter the FRD? I never needed to do that. Just
inserted the SCSI2SD with the SD-card in it and booted. Worked
straight away."

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

Re: strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Liam Proven once stated:
> On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote:
> > Because the 808x was a 16-bit processor with 1MB physical addressing.  I
> > would argue that for the time 808x was brilliant in that most other 16-bit
> > micros only allowed for 64KB physical.
> 
> Er, hang on. I'm not sure if my knowledge isn't good enough or if that's a 
> typo.
> 
> AFAIK most *8* bits only supported 64 kB physical. Most *16* bits
> (e.g. 68000, 65816, 80286, 80386SX) supported 16MB physical RAM.
> 
> Am I missing something here?

  It really depends on how you view a CPU, from a hardware or software
perspective.  From a software perspective, a 68000 was a 32-bit
architecture.  From a hardware perspective, the 68000 had a 16-bit bus and
24 physical address lines and I'm sure at the time (1979) that those
hardware limits were more due to costs and manufactoring ability (a 68-pin
chip was *huge* at the time) (furthermore, the 68008 was still ineternally a
32-bit architecture but only had an 8-bit external data bus---does this mean
it's an 8bit CPU?).  The 68020 (I'm not sure about the 68010) had a 32-bit
physical address bus.

  You are right in that most 8-bit CPUs supported only 16 bits for a
physical address but there were various methods to extend that [1] but
limited to 64k at a time.

> I always considered the 8088/8086 as a sort of hybrid 8/16-bit processor.

  Again, internally, the 8088 was a 16-bit archtecture but with an 8-bit
external data bus (and a 20-bit physical address space).  The 8086 had a
full 16-bit external data bus (and still 20-bit address space) and thus, was
a bit more expensive (not in CPU cost but more in external support with the
motherboard and memory bus).  The 80286 still had an external 16-bit bus but
had 24-physical address lines (16MB).

  The 8088/8086 could address 1MB of memory.  The reason for the 640k limit
was due to IBM's implementation of the PC, chopping off the upper 384K for
ROM and video memory.  MS-DOS could easily use more, but it had to be a
consecutive block.  Some PCs in the early days of the clones did allow as
much as 700-800K of RAM for MS-DOS, but they weren't 100% IBM PC compatible
(BIOS yeah, but not hardware wise) and thus, were dead ends at the time.

  -spc

[1] Bank switching was one---a special hardware register (either I/O
mapped or memory mapped, depends upon the CPU) to enable/disable
banks of memory.

Re: Front panel switches - what did they do?

[Paul Berger]

On 2016-05-24 4:13 PM, Chuck Guzis wrote:

On 05/24/2016 11:39 AM, Eric Smith wrote:

On Tue, May 24, 2016 at 12:25 PM, Paul Koning
 wrote:

On May 24, 2016, at 2:07 PM, Chuck Guzis 
wrote: ...and the "transformer" ROS used on the 360/40 (and
others).

You mean "Core rope memory"?

IBM's TROS and Core Rope Memory use the same principle, but the
physical construction is significantly different. Core rope memory
was very labor-intensive to manufacture, while TROS was not.

There's a photo here;

http://www.cs.sun.ac.za/museum/memory.html

I seem to recall that reworking the 360/30 microprogramming was
preferred by tinkerers over the 360/40 was primarily that CROS was
easier to work with than TROS.

I don't recall what the RCA Spectrolas used.

--Chuck



The CROS cards used in a 360/30 where the same size as an 80 column card 
on purpose so you could you a keypunch machine to program the microcode.

VAX 4000 model 500.

[Rod Smallwood]

Hi

My main system a VAX 4000 Model 500 with a KA680 CPU has just 
started halting at test 51 on power up.


Does any body know where I can lay my hands on a spare KA680?


Rod

Re: strangest systems I've sent email from

[Swift Griggs]

On Tue, 24 May 2016, Fred Cisin wrote:
> (OB_Picky:  Due to the overlap of segment and offset, on machines that had 21
> address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
> instead of 1048576 (10h).

This was always the biggest pustule on the facade of x86 to me. Gate A20 
and other chicanery was nasty business. It always struck me as a hardware 
hack to work around earlier bad design. Sure, you can eschew segmentation 
and try to use multiple instructions to delivery some flat addressing, and 
then your code was snail-slow. Real mode in 16 bit on x86 was/is some 
fairly vulgar stuff due to segmentation (hate hate hate). Then it was made 
"all better now" by protected mode and segment descriptors later *pat 
pat*. Yeah. Ugh. Pleah. Ick.

All that fun sent me running into the arms of the M68k and it's git, and 
later MIPS (queue hallelujah chrous from the clouds). I'm not a MIPS god 
(we have a some here), but much love and respect to the architecture 
nonetheless. I know enough to know "that's the good stuff". Nowadays I 
wonder, since I'm using flat memory on the Unix boxes I code in (now 
pretty much just in C, I haven't done ASM in a long while), what kind of 
masochist maintains the SLAB/SLUB allocators for x86 Unix variants these 
days. I want to buy them a six pack, pat them on the back, and say "you're 
a braver man than, I."

-Swift

Re: strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Fred Cisin once stated:
> On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote:
> >Because the 808x was a 16-bit processor with 1MB physical addressing.  I
> >would argue that for the time 808x was brilliant in that most other 16-bit
> >micros only allowed for 64KB physical.
> 
> Whether 8088 was an "8 bit" or "16 bit" processor depends heavily on how 
> you define those.
> Or, you could phrase it, that the 8 bit processors at the time handled 
> 64KiB of RAM.  The 808x still could see only 64KiB at a time, but let you 
> place that 64kiB almost anywhere that you wanted in a total RAM space of 
> 1MiB, and let you set 4 "preset" locations (CS, DS, SS, ES).  There were 
> some instructions, such as MOV, that could sometimes operate with 2 of 
> those presets.
> Thus, they expanded a 64KiB RAM processor to 1MiB, with minimal internal 
> changes.

  To further explain this.  The 8086 (and 8088) was internally a 16-bit CPU. 
Since you could only address 64K, Intel used four "segment" registers to get
around this limit.  The four registers are CS, DS, ES and SS, and were the
upper 16 bits of the 20-bit address [1].  A physical address was calculated
as:

+++
|  16-bit segment |
+++

+++
+   | 16-bit offset   |
+++
=

   ++++
   | 20-bit physical addr |
   ++++

  Instructions were read from CS:IP (CS segment, IP register), most reads
and write to data sent to DS:offset, with some exceptions.  Pushes and pops
to the stack went to SS:SP and reads/writes with the BP register also used
the SS segment (SS:BP).  The string instructions used DS:SI as the source
address and ES:DI as the destination address.  And you could override the
default segment for a lot of instructions.  So:

mov ax,[bx] -- SRC address is DS:BX
mov es:[bx],ax  -- DEST address is ES:BX

  Technically, you could address as much as 256K without changing the
segment registers.

  I got used to this, but I still preferred programming on the 6809 (8-bit
CPU) and 68000.  *Much* nicer architectures.

  -spc (And the 80386 introduced paging to this mess ... )

[1] Starting with the 80286, in proected mode, they are treated
differently and no longer point to a physical address.  But that's
beyond the scope of *this* message.

Re: VAX 4000 model 500.

[Glen Slick]

On Tue, May 24, 2016 at 2:29 PM, Rod Smallwood
 wrote:
> Hi
>
> My main system a VAX 4000 Model 500 with a KA680 CPU has just started
> halting at test 51 on power up.
>
> Does any body know where I can lay my hands on a spare KA680?
>

A month ago this one went by cheap enough on eBay at $50 that I was
tempted to try to grab it just to have another spare in case I or
someone else needed one some day. Too bad I passed on it. Sometimes
you can find good deals on them on eBay, but of course not when you
really need one.

http://www.ebay.com/itm/262393891988?orig_cvip=true

Re: Front panel switches - what did they do?

[Sean Caron]

On Tue, 24 May 2016, Swift Griggs wrote:



It probably still impressed the suits when they walked the data center.
I've done data center tours with row after row of HP or Dell x86 servers
and it's not much to look at.

-Swift



It's true, modern computers are pretty dull to look at, but you can still 
find some stunning views in the data center from time to time.


A fair bit of what I manage is storage and I have several rows laid out 
such that there is basically nothing but racks of JBOD disk down all one 
side, or even both sides of an entire row. When my end users make the 
equipment sing, it's fun to switch off the lights on the floor and watch 
it dance.


All the JBODs could be used as a crude dot matrix to spell out a phrase. I 
need to write a little script for that ... ;)


Best,

Sean

Re: Front panel switches - what did they do?

[Ethan Dicks]

On Tue, May 24, 2016 at 3:28 PM, Chuck Guzis  wrote:
> On 05/24/2016 12:15 PM, Eric Smith wrote:
>> On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis 
>> wrote:
>>> Yes, but there was a trademarked name for the process that slips
>>> my mind.  Capable of very high densities.
>>
>> Multiwire?
>
> That sounds familiar!

The last COMBOARD product, for VAX BI used a similar technology from
Augat called "Unilayer" - it was a bunch of wires autorouted from the
netlist and stuck together and applied as a "mat" on each side of a
perfboard with plated-through holes and tacked down at each via/wire
junction, then small machine pin inserts were stuffed into the vias
that became the sockets.  We did it because of the 10-layer
requirements of VAX BI and the costs of spinning up such a thick board
in the early 1990s.  Augat had a VAX BI "blank" and we sent them our
layout and netlist and got back a stack of boards.  They were
expensive, but for the size of run we did, it was cheaper than the
setup costs for our own PCB, and guaranteed to be compliant in the "BI
Corner" which was essential for success.  We sold a few.  I still have
the remainder of the run.  Unless one needs a 68010 with some local
RAM and a Z8650 SIO as a VAX peripheral, they are mostly a curiosity.
I ported our HASP and 3780 products to it, but we never had any
customer demand for SNA for VAX BI, so that never happened.

So if not Multiwire, perhaps Unilayer.  They are similar but visibly
distinguishable.

-ethan

Re: strangest systems I've sent email from

[Fred Cisin]

On Tue, 24 May 2016, Swift Griggs wrote:

This was always the biggest pustule on the facade of x86 to me. Gate A20
and other chicanery was nasty business. It always struck me as a hardware
hack to work around earlier bad design.

to work around earlier LIMITED design.

IFF 64K is reasonable for you, then x86 is excellent.

If you barely need a little more (a few 64K blocks), then it is OK.
(such as XenoCopy)

If you really need more, then it is a PITA.


Keep in mind, that it was coming into a 64K world, and wasn't intended to 
last much past that.
If you are trying to use a 64K address processor in a multi-megabyte 
world, it's going to be a miserable misfit.

(like trying to use an air-cooled VW bus for commercial hauling)

Yeah, we use what's handy, even if it's not really suitable.

Re: strangest systems I've sent email from

[Guy Sotomayor Jr]

> On May 24, 2016, at 1:29 PM, Liam Proven  wrote:
> 
> On 22 May 2016 at 04:52, Guy Sotomayor Jr  wrote:
>> Because the 808x was a 16-bit processor with 1MB physical addressing.  I
>> would argue that for the time 808x was brilliant in that most other 16-bit
>> micros only allowed for 64KB physical.
> 
> 
> Er, hang on. I'm not sure if my knowledge isn't good enough or if that's a 
> typo.
> 
> AFAIK most *8* bits only supported 64 kB physical. Most *16* bits
> (e.g. 68000, 65816, 80286, 80386SX) supported 16MB physical RAM.
> 
> Am I missing something here?
> 
> I always considered the 8088/8086 as a sort of hybrid 8/16-bit processor.
> 

My definition of a CPU’s bitness is the native register width and not the
bus width (or ALU width).

From that definition, the 8088/8086 are 16-bit CPUs.  I would certainly
consider the 68K, etc to be 32-bit CPUs.  The 80286 was definitely a 16-bit
CPU and *any* 80386 (SX, DX, whatever) are most definitely 32-bits.

Your argument would say that most of the low end IBM 360’s would be
16-bit machines which is insane.

TTFN - Guy

Re: Board swapping (was Re: General Question about UNIBUS backplanes)

[David Brownlee]

On 24 May 2016 4:45 pm, "Ethan Dicks"  wrote:
>
> On Tue, May 24, 2016 at 11:36 AM, william degnan 
wrote:
> > On Tue, May 24, 2016 at 11:17 AM, j...@cimmeri.com  wrote:
> >> B, what was the issue with the core, that you fixed it so fast?
> >
> > I guessed that the G114 was bad based on a hunch.
> >
> > I had a spare.
>
> Q. How do you know the guy on the side of the highway with a flat tire
> is a DEC Field Service Engineer?
>
> A. He's swapping out all the tires to see which one is flat.
>
> (or from net.jokes in 1981...
> https://groups.google.com/forum/#!topic/net.jokes/GQ2B6HZIY_4 )
>
> The way I heard it was:
> How do you tell if a man with a flat tire is a DEC Field Service Rep?
> Look in the trunk; if he's from DEC F.S. he'll have three spares with
little
> red tags on them and no jack.

My favourite at the time was:

Q: How does DEC Field Circus deal with a flat tyre?
A: Swap the wheels one by one until the issue is resolved.

Q: How does DEC Field Circus deal with a flat battery?
A: Swap the wheels one by one until the issue is resolved.

:)

Re: Front panel switches - what did they do?

[Swift Griggs]

On Tue, 24 May 2016, Sean Caron wrote:
> It's true, modern computers are pretty dull to look at, but you can 
> still find some stunning views in the data center from time to time.

Heh, that would be when the sales girls come walking through doing client 
tours on Fridays while one of us geeks is doing service under the raised 
floor. Stunning views. j/k ;-P

> All the JBODs could be used as a crude dot matrix to spell out a phrase. 
> I need to write a little script for that ... ;)

That reminds me of this MIT hack:
https://www.youtube.com/watch?v=OnCNGNv-Fds

-Swift

Re: strangest systems I've sent email from

[Guy Sotomayor Jr]

> On May 24, 2016, at 2:32 PM, Swift Griggs  wrote:
> 
> On Tue, 24 May 2016, Fred Cisin wrote:
>> (OB_Picky:  Due to the overlap of segment and offset, on machines that had 21
>> address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
>> instead of 1048576 (10h).
> 
> This was always the biggest pustule on the facade of x86 to me. Gate A20 
> and other chicanery was nasty business. It always struck me as a hardware 
> hack to work around earlier bad design. Sure, you can eschew segmentation 
> and try to use multiple instructions to delivery some flat addressing, and 
> then your code was snail-slow. Real mode in 16 bit on x86 was/is some 
> fairly vulgar stuff due to segmentation (hate hate hate). Then it was made 
> "all better now" by protected mode and segment descriptors later *pat 
> pat*. Yeah. Ugh. Pleah. Ick.

As someone who was there and participated in the whole A20 gate issue,
I can tell you why it was there (and Intel in it’s most recent chipsets finally
eliminated it).  It was for SW compatibility.

There was a well know piece of software (at the time…who’s name escapes
me) that make use of the fact that on the 8088, addresses wrapped around
at 1MB.  They took great advantage of it.  Unfortunately when IBM was
working on the PC AT with a 80286 (with 24-bit physical addresses) the
clever hack no longer worked.  So we had to put in a way to emulate the
wrap-around at 1MB…that was the A20 gate.

The initial implementation of the A20 gate was implemented by the
keyboard controller(!) because it was discovered late in the PC AT
development cycle and we couldn’t add more logic to the board (but we
could add some wires).

TTFN - Guy

Re: strangest systems I've sent email from

[Swift Griggs]

On Tue, 24 May 2016, Guy Sotomayor Jr wrote:
> The initial implementation of the A20 gate was implemented by the 
> keyboard controller(!) because it was discovered late in the PC AT 
> development cycle and we couldn?t add more logic to the board (but we 
> could add some wires).

That's very bizzare. It still makes me feel dirty just thinking about it, 
but it's interesting nonetheless. I wonder about some of the "clever hack" 
software that squeezed a tad bit more memory by dancing around/in 
previously reserved memory. Isn't that sort of how Quarterdeck got started 
? I also remember XMS and EMS and all that fun, though the Amiga geek 
inside me is screaming that I shouldn't reveal that.

-Swift

Re: strangest systems I've sent email from

[Guy Sotomayor Jr]

> On May 24, 2016, at 3:10 PM, Swift Griggs  wrote:
> 
> On Tue, 24 May 2016, Guy Sotomayor Jr wrote:
>> The initial implementation of the A20 gate was implemented by the 
>> keyboard controller(!) because it was discovered late in the PC AT 
>> development cycle and we couldn?t add more logic to the board (but we 
>> could add some wires).
> 
> That's very bizzare. It still makes me feel dirty just thinking about it, 
> but it's interesting nonetheless. I wonder about some of the "clever hack" 
> software that squeezed a tad bit more memory by dancing around/in 
> previously reserved memory. Isn't that sort of how Quarterdeck got started 
> ? I also remember XMS and EMS and all that fun, though the Amiga geek 
> inside me is screaming that I shouldn't reveal that.
> 

No it was to allow accessing memory without having to reload a segment
register.  It was a space and performance optimization.  There was no additional
memory.

As I recall, SW needed to access something in the BIOS ROM(s) and also 
the contents of low memory.  Normally, that would have involved reloading a 
segment 
register (and restoring it when done) but by organizing the code properly and
setting the segment registers it was possible to access both the low *and* high
regions without reloading a segment register.  That is, put a large value in the
segment register and when you wanted to access low memory, use a large offset.
When you wanted to access high memory, use a small offset.  You could access
32KB of high and 32KB of low without reloading a segment register (or any 
particular
split you wanted).

These are the sort of “tricks” that most people don’t think much about when
dealing with multi-GB memory environments.  There are still cases where every
byte (and cycle) count and doing these sorts of “tricks” is what determines if
the product is doable or not.

TTFN - Guy

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 02:21 PM, Paul Berger wrote:

> The CROS cards used in a 360/30 where the same size as an 80 column
> card on purpose so you could you a keypunch machine to program the
> microcode.

But I believe that the CROS cards were mylar, no?

--Chuck

Re: Front panel switches - what did they do?

[Chuck Guzis]

On 05/24/2016 02:52 PM, Ethan Dicks wrote:

> So if not Multiwire, perhaps Unilayer.  They are similar but visibly 
> distinguishable.

Hitachi Chemical still seems to be active in this area:

http://www.hitachi-chemical.com/products_pwb_05.htm

--Chuck

Re: Front panel switches - what did they do?

[Paul Berger]

On 2016-05-24 7:44 PM, Chuck Guzis wrote:

On 05/24/2016 02:21 PM, Paul Berger wrote:


The CROS cards used in a 360/30 where the same size as an 80 column
card on purpose so you could you a keypunch machine to program the
microcode.

But I believe that the CROS cards were mylar, no?

--Chuck


Yes mylar with copper tracks keypunch was used to cut tracks as required.

Paul

RE: VAX-11/730 and Emulex UC17 woes

[Josh Dersch]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mike Ross
> Sent: Tuesday, May 24, 2016 2:15 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: VAX-11/730 and Emulex UC17 woes
> 
> On Wed, May 25, 2016 at 8:58 AM, Josh Dersch
>  wrote:
> 
> > Interesting, the UC17 has the same firmware version (G143R) on the label
> of the EPROM.  I wonder if the contents are identical.  Could you send me a
> dump of your ROM so I can compare?
> >
> >>
> >> I dumped the memory for this code from the VAX and entered it into
> >> SIMH to use SIMH as an VAX unassembler and this is what it looks like.
> >> If the UC17 host resident VAX code is the same, any clues here as to
> >> what might be causing a halt on the 11/730?
>
> Here's what I found comparing my code with someone else's dump:
> 
> I've been working this with Glen Slick. Here's a snippet of a recent email 
> with
> him. He provided a dump of the DMAed loader from his UC07:
> 
> The raw binary dumped on the VAX looked like this:
> 
> 
> 

Thanks.  Glen sent me his dump and I compared with mine.  I have the same three 
differences:

D 02A0 01200880   // 0100F308
D 02BC 0014688F   // FFF4688F
D 02C0 65B45520   // 65B45500

(commented values are the ones that differ on my machine).

This changes the code as below:

-> 298:MOVL #8002,@#F30808   (was: 298:MOVL #8002,@#20088008)
2A3:NOP
2A4:MTPR #1F,#12
2A7:MOVAL 400,R1
2AE:MOVL #200,R2
2B5:MOVL #0,(R1)+
2B8:SOBGTR R2,2B5
-> 2BB:MOVL #FFF468,R5   (was 2BB:MOVL #20001468,R5)

I suspect these values are changed "on the fly" based on the machine type 
punched into the SA register as the last step before the "S 80" command; in 
particular, the source address for the MOVL instruction at 2BB now makes more 
sense, corresponding to a value in the UBA register set for the UC17.

However, F30808 doesn't make sense as the destination argument address for the 
MOVL at 298.  This looks like a map register for an 11/750 (as documented in 
the UC17 manual as being at F30800/F30804) and I wondered if it should be 
similar to the value for the 11/730 (F26800/F26804).

So I changed the instruction at 298 to:

MOVL #8002,@#F26808

(which corresponds to a change in the value at 2A0 to 0100F268)

On the VAX-11/730 and did an "S 80" and lo and behold, it works!

I suspect either a typo in the manual for the machine type designator word, or 
a revision difference between firmware and documentation.

- Josh

Re: VAX-11/730 and Emulex UC17 woes

[Mike Ross]

On Wed, May 25, 2016 at 11:03 AM, Josh Dersch
 wrote:

*another snip*

> Thanks.  Glen sent me his dump and I compared with mine.  I have the same 
> three differences:
>
> D 02A0 01200880   // 0100F308
> D 02BC 0014688F   // FFF4688F
> D 02C0 65B45520   // 65B45500
>
> (commented values are the ones that differ on my machine).
>
> This changes the code as below:
>
> -> 298:MOVL #8002,@#F30808   (was: 298:MOVL #8002,@#20088008)
> 2A3:NOP
> 2A4:MTPR #1F,#12
> 2A7:MOVAL 400,R1
> 2AE:MOVL #200,R2
> 2B5:MOVL #0,(R1)+
> 2B8:SOBGTR R2,2B5
> -> 2BB:MOVL #FFF468,R5   (was 2BB:MOVL #20001468,R5)
>
> I suspect these values are changed "on the fly" based on the machine type 
> punched into the SA register as the last step before the "S 80" command; in 
> particular, the source address for the MOVL instruction at 2BB now makes more 
> sense, corresponding to a value in the UBA register set for the UC17.
>
> However, F30808 doesn't make sense as the destination argument address for 
> the MOVL at 298.  This looks like a map register for an 11/750 (as documented 
> in the UC17 manual as being at F30800/F30804) and I wondered if it should be 
> similar to the value for the 11/730 (F26800/F26804).
>
> So I changed the instruction at 298 to:
>
> MOVL #8002,@#F26808
>
> (which corresponds to a change in the value at 2A0 to 0100F268)
>
> On the VAX-11/730 and did an "S 80" and lo and behold, it works!


Ooooh! I'll have to try that! Thanks. Great sleuthing!


Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

Re: Front panel switches - what did they do?

[Charles Anthony]

On Tue, May 24, 2016 at 9:44 AM, Swift Griggs  wrote:

> On Tue, 24 May 2016, Charles Anthony wrote:
> > "Older machines" covers a lot of ground.
>
> Sorry, I should have said "machines from the 50's - 70's which used
> buttons, toggles, rockers or other switches on the front panel"
>
> > Typically, there was a set of data switches (0/1 toggles) that could be
> > set to an address or data value, and a set of command switches
> > (momentary contact) that copied the data switches to some data register
> > or memory.
>
> Did some of the machines have blinkenlights to show you what you were
> doing so you could see the values you were inputting? Judging from how I
> play guitar, I'd probably miskey and have to start all over etc...
>

Hah. Video of some toggling in a bootstrap...
https://www.youtube.com/watch?v=iIsZVqhaneo



>
> > The 709 had these massively over-engineered rocker switches, reminiscent
> > of circuit breakers, and a reset switch which activated a electric motor
> > in the console which physically set the switches back to 0.
>
> Heh, that sounds cool. Could you hear the motor running after hitting the
> switch to activate it?
>
> Oh yes. *whir* *CLUNK*

-- Charles