29 Jul
2004
29 Jul
'04
8:59 a.m.
Ok, I don't know if this is possible, but it would be handy so I'll throw
the idea out and see if the more electrically inclined have any ideas.
My specific issue is the HP2100A, 2100S, and 21MX M/E/F systems. However, I
suspect this problem is present in other machines... DEC, DG, etc.
The loader roms and microcode roms (two different chips) for each system are
pretty much impossible to find. I'd like to make copies of them both for
myself to use in other systems I currently have, and also to have a set of
spares around. In addition, I'd like to make copies for other classiccmp'ers
who may have systems that want/need a particular firmware or loader rom
option. Finally, there are some roms that people have posted images for
online that I'd like to burn myself because I don't have those particular
roms.
Since the blank chips are nigh impossible to find anymore... is it possible
to use something like a PIC chip on a small DIP carrier card, that could be
plugged into an existing loader rom or microcode rom socket and function
just like the "real thing" to the system? Would this be something terribly
difficult to build? A cute twist on this.... extending the idea further....
Put a bunch of NVram or an EEprom on the little carrier card. In the NVram
could be stored multiple ROM images. Then via a switch on the card (when the
system is powered off of course), you could select if the chip was a mag
tape loader rom, or a paper tape loader rom, etc. For the microcode roms you
could switch between FFP and IOP for example. When you wanted to change the
set of rom images in the DIP package, you just hook it up to a serial port
and download to change the available sets on it.
The WCS card for HP boxes comes close to this, but there's no battery
backup, and you can't program it easily with a PC. WCS cards probably aren't
terribly easy to find anyways.
Is this a pipedream? It would allow DEC'ies to have more loader roms they
dont currently have by exchanging images via the net, etc. Not just an HP
thing - but I realize it would have to be a different design electrically to
work on the other machines. I'm thinking of a universal rom with different
electrical interfaces on the carriers perhaps?
Everyone talks about preserving ROM/PROM contents. But if the blank roms are
unobtainium, we need to take the next step.
Any thoughts?
Jay West
---
[This E-mail scanned for viruses by Declude Virus]
29 Jul
29 Jul
9:12 a.m.
I had written...
The loader roms and microcode roms (two different
chips) for each system
are
pretty much impossible to find.
In case it
wasn't obvious... I was saying the BLANK loader rom chips and
BLANK microcode rom chips were impossible to find. Blanks are necessary to
burn copies :)
Jay
---
[This E-mail scanned for viruses by Declude Virus]
10:01 a.m.
Jay West wrote:
Since the blank chips are nigh impossible to find
anymore... is it possible
to use something like a PIC chip on a small DIP carrier card, that could be
plugged into an existing loader rom or microcode rom socket and function
just like the "real thing" to the system?
You wouldn't use a PIC chip for something like this. A PIC would be
used in a microcontroller-type application, where program-controlled
behaviour is required. To replace a ROM, we could simply use another
ROM (or PROM, EPROM, EEPROM, Flash ROM, etc.) with a pinout adaptor.
People are already doing this for PROMs in mobile radios. These PROMs
are in fact the same chips as one finds in a PDP-11 for booting (M9312)
and for storing the 8008 firmware in an 11/34 console card. The
PROMs in question are 82S131, 74S571 or Am27S13 types (512x8). I have
some blanks here to fix a console card, as it happens.
Scroll down here:
http://www.open.org/~blenderm/syntorx/legacy.html
to the section headed "EPROM Conversion" to read about the PROM
replacements for Syntor radios. And see this page:
http://www.open.org/~blenderm/syntorx/legacyeprom.html
for photos of a completed adaptor.
Do you know the chip numbers and/or specs for the ROMs you wish to
emulate?
--
John Honniball
coredump(a)gifford.co.uk
10:02 a.m.
Do you know the chip numbers and/or specs for the ROMs
you wish to
emulate?
Personally, I'd like to have something with a ROM interface on one side
(and probably EEPROM onboard), with a serial interface so the contents
can be changed, preferably live. I built such a thing once on a
breadboard; I wired it in in place of the character-generator ROM of an
ascii terminal (a TVI955). The wiring was not up to the frequencies
required, but fortunately, it being just the character generator, all
that happened was snow on the screen. But it _was_ cool to be able to
download new character glyphs live. :-)
The devices I'd most want to do this with at the moment are 27256s. I
suppose I should just build/buy a conventional EPROM programmer; 27256s
(and even 28256s) are not all that scarce last I looked.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:24 a.m.
John wrote...
You wouldn't use a PIC chip for something like
this. A PIC would be
used in a microcontroller-type application, where program-controlled
behaviour is required.
A pic wouldn't be needed just to replace the rom... but I think it would be
a good choice to implement the RS232 interface and logic to download new
code to the NVRAM or EEPROM, when the contents were being changed.
Jay
---
[This E-mail scanned for viruses by Declude Virus]
12:08 p.m.
Ok, I don't know if this is possible, but it would be handy so I'll throw
the idea out and see if the more electrically inclined have any ideas.
My specific issue is the HP2100A, 2100S, and 21MX M/E/F systems. However, I
suspect this problem is present in other machines... DEC, DG, etc.
The loader roms and microcode roms (two different chips) for each system are
pretty much impossible to find. I'd like to make copies of them both for
myself to use in other systems I currently have, and also to have a set of
spares around. In addition, I'd like to make copies for other classiccmp'ers
who may have systems that want/need a particular firmware or loader rom
option. Finally, there are some roms that people have posted images for
online that I'd like to burn myself because I don't have those particular
roms.
Since the blank chips are nigh impossible to find anymore... is it possible
to use something like a PIC chip on a small DIP carrier card, that could be
I would doubt it. Those old fusible-link PROMs were actually quite fast
with access times of <50ns in many cases. And the designs depended on it.
I've ben looking at the HP98x0 calculator processor with a view to
designing a diagnostic PCB for it. It became pretty obvious that the
microcode PROMs could not be replaced, for example, with most common
EPROMs suitably wired -- they were just too slow.
Using a microcontroller to simulate a PROM is going to be even slower, I
would think.
Bootstrap ROMs -- that is to say ones that are mapped into the normal
memory space, as opposed to microcode PROMs which are used to control the
CPU, could generally be slower, and you might get away with EPROMs here.
In which case you could use, say, a 32K EPROM to store 128 256 byte
images and use a 7 position DIP switch (connected to the high 78 address
lines of the EPORM) to select between them.
-tony
12:54 p.m.
Tony wrote...
I would doubt it. Those old fusible-link PROMs were
actually quite fast
with access times of <50ns in many cases. And the designs depended on it.
Surely
that's easy to get around. Upon power up - or when a reset button is
pushed, the device reads the image from EEprom and places it into SRAM,
which is what is actually accessed. Isn't SRAM fast enough?
Jay West
3:53 p.m.
Tony wrote...
Yes, modern SRAM is fast enough. But that's 'easy' in theory. Firstly you
have to have some way of switching the SRAM between the device and the
loader (or use dual-port SRAM, which is darn expensive if it's fast).
Secondly, you need to halt the device while the SRAM is loaded.
Neither problem is difficult, but the second probably involves some
modifications to the device (if only to the reset circuit), and the
daughterboard ceases to be a 1 or 2 chips.
-tony
I would doubt it. Those old fusible-link PROMs
were actually quite fast
with access times of <50ns in many cases. And the designs depended on it.
Surely that's easy to get around. Upon power up - or when a reset button is
pushed, the device reads the image from EEprom and places it into SRAM,
which is what is actually accessed. Isn't SRAM fast enough?
30 Jul
30 Jul
1:29 a.m.
Tony wrote...
Yes, modern SRAM is fast enough. But that's
'easy' in theory. Firstly you
have to have some way of switching the SRAM between the device and the
loader
Dual port SRAM is one answer. Or, I'm not sure what the power on test
in
microcode does on the MX's, but my guess is it doesn't touch the add-on
microcode. The loader roms probably aren't touched either until called from
the front panel. If the RPL stuff is turned on, it may though. I think the
RPL stuff may have a built in delay cycle, and the EEprom to SRAM copy would
be done by then. My initial guess is that upon powerup, the device would
copy from NVRAM or EEprom to SRAM, then switch the SRAM to be available to
the host. I would think this process would be awfully fast.
(or use dual-port SRAM, which is darn expensive if
it's fast).
Expensive is better than not ever having any blank old-style proms
:)
Secondly, you need to halt the device while the SRAM
is loaded.
I would envision the SRAM load to only happen once, during power up. One
could build in a reset button and dip bank switch or micro rotary switch
that would make it load different contents, but it would be up to the
operator not to do that while the system was running.
Neither problem is difficult, but the second probably
involves some
modifications to the device (if only to the reset circuit), and the
daughterboard ceases to be a 1 or 2 chips.
Chip count would be highly desireable to
keep to a minimum. I don't know how
this would apply to non-HP systems, but on the HP boxes there's another
approach. On the E series for example, there are four 14pin sockets in very
close proximity on the cpu board for loader roms. One could build a single
larger daughtercard that would plug into all 4 four loader rom sockets
simultaneously. You would have more real estate on the daughterboard to use,
plus, perhaps you could get "economies of scale" by having one SRAM service
the four rom data at once.
Just some uninformed thoughts on my part :)
Jay
---
[This E-mail scanned for viruses by Declude Virus]
9:46 a.m.
Tony wrote...
Sure, but have you looked at the price :-)
Yes, modern SRAM is fast enough. But that's
'easy' in theory. Firstly you
have to have some way of switching the SRAM between the device and the
loader
Dual port SRAM is one answer. Or, I'm not sure what the power on test
in microcode does on the MX's, but my guess is it
doesn't touch the add-on
microcode. The loader roms probably aren't touched either until called from
the front panel. If the RPL stuff is turned on, it may though. I think the
OK. I was thinking about the microcode ROMs in an HP9810 (somethign that
_I_ am working on, and those are most certainly 'hit' as soon as INIT is
deaseserted and the microocde program counter starts to change. I prefer
to think of general-purpose solutions (i.e. somethign that will replace
every 256*4 ROM), rather than soemthing that works only in specific
machines under specific circumstances.
-tony
12:26 p.m.
OK. I was thinking about the microcode ROMs in an
HP9810 (somethign that
_I_ am working on, and those are most certainly 'hit' as soon as INIT is
deaseserted and the microocde program counter starts to change. I prefer
to think of general-purpose solutions (i.e. somethign that will replace
every 256*4 ROM), rather than soemthing that works only in specific
machines under specific circumstances.
I must not be getting it, somehow.
Why can't you just use a 45ns or 55ns 27c256 or 27c512 and swizzle the
pinout? These are around $3 per chip, and seem to meet the requirements.
Vince
31 Jul
31 Jul
2:02 a.m.
At 05:26 PM 7/30/04 -0700, you wrote:
For one thing the parts used in the HP 1000 are 25 to 35 nS parts. Also
the enable and other control lines are very different so you'd need a fair
amount of glue chips and probably a buffer.
Joe
OK. I was
thinking about the microcode ROMs in an HP9810 (somethign that
_I_ am working on, and those are most certainly 'hit' as soon as INIT is
deaseserted and the microocde program counter starts to change. I prefer
to think of general-purpose solutions (i.e. somethign that will replace
every 256*4 ROM), rather than soemthing that works only in specific
machines under specific circumstances.
I must not be getting it, somehow.
Why can't you just use a 45ns or 55ns 27c256 or 27c512 and swizzle the
pinout? These are around $3 per chip, and seem to meet the requirements.
Vince
1 Aug
1 Aug
12:30 a.m.
At 14:29 30/07/2004, Jay West wrote:
Just my idle thought, reading through this thread, but would it be possible
to provide some sort of battery backup (maybe rechargeable?) for the SRAM
on this device? Then you don't have to worry about copying out of EPROM
(or whatever) into the SRAM in those few ns as you power up the machine, as
it's already in there from last time? Have a hefty enough battery to run
the PIC/whatever, and you can even select the ROM image and re-load the
SRAM while the rest of the system is still powered off.
Rob
Secondly, you
need to halt the device while the SRAM is loaded.
I would envision the SRAM load to
only happen once, during power up. One
could build in a reset button and dip bank switch or micro rotary switch
that would make it load different contents, but it would be up to the
operator not to do that while the system was running. 
7400
days inactive
7403
days old
13 comments
8 participants
participants (8)
-
ard＠p850ug1.demon.co.uk -
classiccmp.org＠irrelevant.fsnet.co.uk -
coredump＠gifford.co.uk -
jwest＠classiccmp.org -
mouse＠Rodents.Montreal.QC.CA -
rigdonj＠cfl.rr.com -
vrs＠msn.com -
waisun.chia＠hp.com