11 Sep
2015
11 Sep
'15
2:41 p.m.
That triggers again a question I had for a while ...
HOW OFTEN theses old PROM fail ??
Who had been through this problem and does it "really" worth to have some
blanks
"just in case" ??
---
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
11 Sep
11 Sep
4:35 p.m.
Gerard wrote....
----
HOW OFTEN theses old PROM fail ??
Who had been through this problem and does it "really" worth to have some
blanks "just in case" ??
----
1) Once is enough, if it is the only known copy of that particular rom. But
in general they are very reliable. More often than not - when they fail -
something else took them out in the process of it's failure. I have had a
prom failure all by itself though.
2) It's extremely worth it. For one.... many of the machines run by people
on this list immediately become boatanchors if a prom fails, especially if
it's a microcode rom. Second... you're missing the more general case - say I
have a HP21MX that was running 2000/Access and I now want to run RTE-6/VM.
Guess what - I need the microcode roms that are required for RTE-6/VM.
Fortunately, other collectors have taken the time to copy their proms and
upload them online (bitsavers is a great example). So I can download their
rom images and burn a new set for running new software I had not been able
to run before. Another example - say my machine came with only paper tape.
Two years later I happen to acquire a disc drive. Sure would be nice if I
could just download the loader rom image and burn it so that I can boot from
that device. With a burner and blanks, all that is possible.
Best,
J
8:02 p.m.
On Fri, Sep 11, 2015 at 12:41 PM, GerardCJAT <gerardcjat at free.fr> wrote:
HOW OFTEN theses old PROM fail ??
Note that some bipolar PROMs suffer from fuse regrowth, where bits
that have been programmed gradually revert to an unprogrammed state.
This was a big problem with NiCr fuses. Later bipolar PROMs used
different fuse materials; TiW was one of the later choices. I don't
know whether TiW or other newer fuses have regrowth issues, but if
they do, it's slower than NiCr.
It is possible to recover the bits from a bipolar PROM with regrowth
by decap and optical inspection, because the regrowth happens in
relatively narrow tendrils which are visibly different than an
unprogrammed fuse. I've actually seen that done.
There is speculation that it could be done without decap by trying to
blow each unblown fuse and measuring the energy required to blow the
fuse; a regrown one should require less energy. I'm not aware of
anyone actually having done it that way. I wouldn't trust a
one-of-a-kind PROM to that process.
Obviously it's best to dump the PROM contents before regrowth becomes an issue.
12 Sep
12 Sep
7:03 p.m.
If you still have a working machine, why not disassemble the boot
ROMs. They are only a few instructions long.
Making a listing for the 21MX makes it easy to check them from the front
panel.
As I recall, in the boot sequence, it transfers the ROMs to ram and then
executes it.
Dwight
13 Sep
13 Sep
9:42 a.m.
Dwight wrote...
If you still have a working machine, why not
disassemble the boot ROMs.
They are only a few instructions long.
Not necessary, as the source and binary for all the loader roms is in the
aforementioned manual. None of them are "only a few instructions long". Most
of them are a couple pages of assembler code.
As I recall, in the boot sequence, it transfers the
ROMs to ram and then
executes it.
Pressing the IPL/TEST button does the following:
1) It executes cpu diagnostic 1 (registers and a few functions) and 2 (quick
memory test, up to 32kw) that are stored in microcode.
2) It transfers any one of the four installed loader roms (as designated by
switch register bits 15 & 14) to the last (up to 32kw) 64 words of memory.
3) Any I/O instructions in the loader are automatically patched during the
transfer (based on switch register bits 11 through 6) so that the correct
I/O address (device) is referenced.
4) The program counter is set to the first word of the last (up to 32kw) 64
words.
Then you can hit the run switch to execute the (patched) loader.
Interesting to me... on the 2100A/S, the last 64 words of memory can be
protected. They cannot be accessed unless the "loader enable" button/light
has been pressed. This makes it less likely that your loader (which had to
be hand entered on that model as it didn't support "loader roms") would
accidentally be clobbered by other code. The loader enable button stays on
until the computer reaches a halt instruction or the halt button is pressed.
So the typical process was to set the program counter to the first word of
the last 64 words (up to 32kw) of memory, press loader enable, then run.
Once the loader finished loading whatever it's target was, it would halt
(thus re-protecting the loader). Then the user could press run to execute
the target code and not worry about the loader getting toasted.
Best,
J
11:10 a.m.
From: jwest at classiccmp.org
Dwight wrote...
My main thinking was the best place to save a boot is to save it on paper.I
recall looking at mine to see how the flag worked.( not mass storage yet so needed a
serial loader ).Dwight
If you still have a working machine, why not
disassemble the boot ROMs.
They are only a few instructions long.
Not necessary, as the source and binary for all the loader roms is in the
aforementioned manual. None of them are "only a few instructions long". Most
of them are a couple pages of assembler code.
As I recall, in the boot sequence, it transfers
the ROMs to ram and then
executes it.
Pressing the IPL/TEST button does the following:
1) It executes cpu diagnostic 1 (registers and a few functions) and 2 (quick
memory test, up to 32kw) that are stored in microcode.
2) It transfers any one of the four installed loader roms (as designated by
switch register bits 15 & 14) to the last (up to 32kw) 64 words of memory.
3) Any I/O instructions in the loader are automatically patched during the
transfer (based on switch register bits 11 through 6) so that the correct
I/O address (device) is referenced.
4) The program counter is set to the first word of the last (up to 32kw) 64
words.
Then you can hit the run switch to execute the (patched) loader.
Interesting to me... on the 2100A/S, the last 64 words of memory can be
protected. They cannot be accessed unless the "loader enable" button/light
has been pressed. This makes it less likely that your loader (which had to
be hand entered on that model as it didn't support "loader roms") would
accidentally be clobbered by other code. The loader enable button stays on
until the computer reaches a halt instruction or the halt button is pressed.
So the typical process was to set the program counter to the first word of
the last 64 words (up to 32kw) of memory, press loader enable, then run.
Once the loader finished loading whatever it's target was, it would halt
(thus re-protecting the loader). Then the user could press run to execute
the target code and not worry about the loader getting toasted.
Best,
J
1:23 p.m.
Dwight wrote...
----
My main thinking was the best place to save a boot is to save it on paper.I
recall looking at mine to see how the flag worked.( not mass storage yet so
needed a serial loader ).
-----
Ah, gotcha. Yep, you're right!
On a few loaders where the part #'s were obscured, I had to do exactly that
(disassemble first handful of instructions to see which one it was).
Best,
J
10:44 p.m.
On Sunday, September 13, 2015 at 8:42, Jay West wrote:
3) Any I/O instructions in the loader are
automatically patched during
the transfer (based on switch register bits 11 through 6) so that the
correct I/O address (device) is referenced.
It's actually a bit more nuanced than this. What occurs is:
3a) Except for halt instructions, any I/O instruction referencing select
code 10 (octal) or greater is patched by adding the select code
value in the switch register minus 10.
This means that (a) halt instructions, which are in the I/O group, are not
altered, (b) DCPC I/O instructions, which reference select codes 2, 3, 6,
or 7 are not altered, and (c) interfaces that use two select codes, e.g.,
the 7900 disc interface, get both select codes updated properly. It also
implies that all loaders are written to reference select code 10 (or 10 and
11, etc.).
3b) The two's-complement of the memory address of the first word of the
loader is stored in the last word in memory.
This is so that loaders can check that what they are loading does not
overwrite the loader itself. For example, the paper tape loader does a HLT
55 if the absolute binary tape contains a record that would overlay the
loader executable code.
3c) The contents of the penultimate memory location is patched by adding
the select code value in the switch register minus 10.
This is used to patch the select code into an optional DCPC control word,
which is a constant and not an I/O instruction and so wouldn't be patched
by (3a). Loaders that use DCPC, e.g., the disc loaders, place their DCPC
control word at this location.
There's actually quite a lot going on under the hood for that IBL button
press.
-- Dave
11:26 p.m.
On Sun, Sep 13, 2015 at 7:44 PM, J. David Bryan <jdbryan at acm.org> wrote:
On Sunday, September 13, 2015 at 8:42, Jay West
wrote:
For the curious the source code for the Initial Binary Loader
microcode is listed on pages D-16 and D-17 of this manual:
http://www.bitsavers.org/pdf/hp/1000/1000_MEF_EngrRef/92851-90001_Mar81_1.1…
It is reasonably well commented, but still not completely obvious
exactly what and why it is doing what it is doing without something
like Dave's explanation above.
3) Any I/O instructions in the loader are
automatically patched during
the transfer (based on switch register bits 11 through 6) so that the
correct I/O address (device) is referenced.
It's actually a bit more nuanced than this. What occurs is:
3a) Except for halt instructions, any I/O instruction referencing select
code 10 (octal) or greater is patched by adding the select code
value in the switch register minus 10.
This means that (a) halt instructions, which are in the I/O group, are not
altered, (b) DCPC I/O instructions, which reference select codes 2, 3, 6,
or 7 are not altered, and (c) interfaces that use two select codes, e.g.,
the 7900 disc interface, get both select codes updated properly. It also
implies that all loaders are written to reference select code 10 (or 10 and
11, etc.).
3b) The two's-complement of the memory address of the first word of the
loader is stored in the last word in memory.
This is so that loaders can check that what they are loading does not
overwrite the loader itself. For example, the paper tape loader does a HLT
55 if the absolute binary tape contains a record that would overlay the
loader executable code.
3c) The contents of the penultimate memory location is patched by adding
the select code value in the switch register minus 10.
This is used to patch the select code into an optional DCPC control word,
which is a constant and not an I/O instruction and so wouldn't be patched
by (3a). Loaders that use DCPC, e.g., the disc loaders, place their DCPC
control word at this location.
There's actually quite a lot going on under the hood for that IBL button
press.
-- Dave
3268
days inactive
3271
days old
8 comments
6 participants
participants (6)
-
dkelvey＠hotmail.com -
gerardcjat＠free.fr -
glen.slick＠gmail.com -
jdbryan＠acm.org -
jwest＠classiccmp.org -
spacewar＠gmail.com