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]
I just located a PDP 11/23 Plus that is going to be scrapped soon if no one is interested in it. I told the owners that I would check to see if there was any interest in the unit from a chat site I am part of. This is a rack mounted unit with 2 RL02 drives and several disks for the RL02 units also in the rack. It also has the air conditioning attached to the back of the rack. It is sitting outside (come rain or shine) so it may be vandalized at some point in time or the weather may get to it. The owners are interested in getting rid of it, but of course want a payment of some amount. They did not give me a number of what they wanted for it.
Is there any interest here on the board? I can go back and get more information on the item if needed. Just let me know what you'd like to know about it. I was going to get the SN, but couldn't find it.
I'm willing to work with anyone who is interested.....
Bill Machacek
Colo. Springs, CO
A gentleman in Baltimore sent me this email:
<start of email>
I happen to have a Wang 2200 and have been wondering about it. I used to
have a one man computer hardware design consulting company with an
office in a medical/professional office building. One day a doctor in a
nearby office had the maintenance man wheel in this Wang 2200 into my
office. No manuals, no floppies, no terminals. As far as I know it was
in working condition when it was retired circa 1996. It in a storage
area since then and I have decided it needs a good home.
<end of email>
A subsequent email showed it to be a Wang 2200 LVPC-E, made in 1983.
The machine has a single 8" floppy, but the internal hard disk has been
removed. The VP series machines had a writable microcode store, so to
execute BASIC, it had to come off of a disk. So as it stands, it will
not boot.
I asked him about his asking price and he said:
<start of email>
This unit is very heavy, so I worry about delivery. My ideal scenario is
someone would drive up and grab it from me. From what you said it would
cost more to ship (have to be by truck) than its worth.
<end of email>
If you are interested in the machine and can pick it up, please send me
an email at frustum(a)pacbell.net and I'll send you pictures and I'll give
you his email address. I'm not posting his email directly so his
address doesn't get spam harvested.
I've recently heard of an archaic IBM device, the 1092 Densely Coded Matrix
- a 10 x 15 array of switches, essentially a Big Keyboard, with customisable
plastic overlay 'keycaps'.
Could be used for input on 60's systems - 1410, my 1800, probably S/360 too.
Originally developed at the University of Missouri, for control of CNC-type
cloth cutting machines in garment trade.
Anyone got one? Seen one? Anecdotes of them?
BTW, I'm *still* engaged in a probably-hopeless search for a 1052 or 1816
(heavy-duty 1052) console to use with my 1800, in the increasingly-unlikely
event that anyone here can point me towards one...
Mike
http://www.corestore.org
Hi
Does anyone have any data books with the specs
and signals for Rockwell's 4 bit processors that
they made during the late 70's? These were in a
funny flat pack called spider chips.
Dwight
>From: "John Honniball" <coredump(a)gifford.co.uk>
>
>Dwight K. Elvey wrote:
>> Does anyone have any data books with the specs
>> and signals for Rockwell's 4 bit processors that
>> they made during the late 70's? These were in a
>> funny flat pack called spider chips.
>
>I have a book by Steve Money called "Microprocessor Data Book", and
>it lists three Rockwell 4-bit chips, the MM75, MM76 and MM78. They
>make up the PPS4/1 Series. Are they the ones you are interested in?
>
>--
>John Honniball
>coredump(a)gifford.co.uk
>
>
Hi John
Hard to say. The chips I have all have inhouse numbers on them.
It sure does sound like the right stuff though. The chips are
all 42 pin spider chips.
Dwight
Date: Fri, 30 Jul 2004 21:01:44 -0400
From: "John Allain" <allain(a)panix.com>
Subject: Re: IBM 1092
>I have a device like this, taken from IIRC an NCR device ca. 1960.
>It is definitely a keyboard and it contains a matrix of something like
>(3x8+AD0-)24 by 24 switches, and it is coded, perhaps BCD. Underneath it
>is all hand strung wires. I can dust it off and send photographs if
>you're interested.
I'm primarily interested in DEC & IBM stuff, thanks... why don't you put the
photos on a website where everyone can see them?
>1401 I've heard of. What's an 1800?
Same architecture as the 1130, but a much bigger box. Built like a
System/360, from SLT logic.
See: http://www.corestore.org/1800-2.htm
Cheers
Mike
>From: "Don Maslin" <donm(a)cts.com>
>
>
>
>On Fri, 30 Jul 2004, Joe R. wrote:
>
>> At 04:41 PM 7/29/04 -0700, you wrote:
>> >>> That's called a 'Light Emitting EPROM' and it's an expensive and
>> >>> short-lived alternative to an LED.
>> >
>> >>Is this related to things like the SER (Smoke Emiting Resistor -- one
>> >>where the power rating is massivle exceeded), SEC (Sound Emitinf Capacitor
>> >>-- an electrolytic wired backwards), the Friode (a diode that's
>> >>open-circuit both ways), etc?
>> >
>> >Sounds like what Lucas Electric used to use.
>> >http://pw1.netcom.com/~krk/lotus/humor/lucasjokes.html
>>
>> ROFL! Only someone who's had a vehicle with Lucas electronics could
>> truely appreciate that!
>>
>> Joe (x-1952 MG TD)
>
>...or had experience with Magneti Morelli eqquipment!
> xxxxxxx
> Marelli
>
> - don
>
Hi
The only problems I've ever had with Lucas was there fuel pumps,
ignition coils, distributors, alternators and fuse holders.
The Magneti Marelli stuff was actually a little better. I
never had issue with the alternators ( regulators were junk )
but then I never had an Italian car with an electric fuel pump.
For switches, the worst I ever encountered were used in
Audi's.
Dwight
>> >And thereing lies the problem. Presumably you need to program an EPROM
>> >with the firmware for this 6809. Which is somewhat hard without a
>> >programmer :-)...
>>
>> For some perhaps - at the time, myself, and almost everyone I knew worked
>> for companies with programmers, so it was not a problem. You could also get
>
>You were lucky. I was a student at the time, and in fact I built the
>program over an Easter vacation one year. I didn't have access to a
>programmer -- that's why i needed to build one.
Agreed with all your points that it may not have been possible - but I did
learn many avenues to work around such problems - when I was a student, I
"found" the only programmer in the place and got to know the guy who was in
charge of it ... :-)
My "not available" story: I was at my parents home over a long weekend when I
finally got my wirewrapped 8080 system to the point where it could use a keyboard
- as they lived in the country, there was no chance of scrounging one (I couldn't
afford to BUY anything back then), so I decided to build one...
Picture a flat piece of wood, at each key location is a metal thumbtack with a
bit of fine wire (salvaged from a transformer) attached. Two spacers at each
end allow another "board" to live about 1/4 inch above it. It had holes drilled
over every key (thumbtack), and in each hole was a nail pointing up, going
through a spring (springs came from an old contruction kit) into a hold drilled
into a short piece of dowling which was the "keytop" - another bit of fine wire
shoved into the hold beside the nail made the top contact.
The contacts from the "keys" went to a rather large and unsightly mess of diodes
(salvaged from an old Burroughs posting machine) and ultimately to a set of 8
transistors, which game 7-bit ASCII and a strobe. Took me most of the weekend to
build the thing, and it actually worked! Although it was not the most pleasant
thing to type on (rollover ... we don't need no steenking rollover :-)
One of the few things from my very early digital experiences that I really wish
I had saved...
[It was replaced within a couple of months with a real keyboard (scrounged) and
remapped to ASCII with a 1702]
>Unless your programming skills are perfect (and mine are not), this gets
>boring fast when you have to wait a few days for each update. In fact the
>time taken to erase and reporgram an EPROM yourself soon becomes painful,
>that's why I included an emulator in my programmer.
>...
>> I didn't program the actual firmware right away - I made a EPROM (at work)
>> with my 6809 monitor program in it, which allowed me to download code into
>
>Right... Again this assumes your monitor is debugged.
In this case, it was - I did a *LOT* of 6809 code in those days, both privately
and commercialy - I had my own debugger (still around essentually unchanged as
the MON09 debugger I list on my site), and I designed my EPROM programmer to
have the same serial port devices (6551), and RAM in the right place for the
monitor to run (ROM was at E000 of course - 8k at top in 6809 map).
Had I not had a debugged monitor, I would have written a very simple loader.
Just enough to get a "real" loader into the machine - unless I really cocked
it up, that would be all I needed, and I doubt I would have had to have the
ROM made more than once (did similar things on many other projects).
I selected the 6809 in the first place because I had recent experience with it
and suitable tools available...
>Incidentally, I've built a couple of instruments with microprocessors (as
>opossed to microcontrollers) controlling them (actually I normally used
>the 6809 -- nice chip), and I included commands to read/write/execute
>from any location in mmeory. Sure helped debugging !.
Yup - 6809 was an incredible chip - easy to multitask (and most people don't
know what DP is for!) - I always include low level debugging features/commands,
can be absolutely essential at times.
>> If I were doing the same project today, and had absolutely no access to any
>> means of programming the initial EPROM, I would first post in the local groups
>
>These days I'd either use a PIC as the controller processor (trivial to
>make a programmer for, and the programming algorithms are documented), or
>if I was using some deviec with external program memory, I'd start off
>using E2PROM or something, again easy to make a programmer for. I now
>have access to rather more computers, with rather more user I/O lines...
Yeah, OK - I would use some little flash device too - I was speaking in terms
of if I were faced with the same problem to build exactly the same type of
device with similar parts ...
>This was long before the days of the Internet in the UK. It wasn't easy to
>find places to ask about borrowing a programmer.
Not familier with UK companies etc. - this would have been somewhere in the
mid 80's, and I was reasonably well past being a student ... but these are
the kinds of things I would have tried had I still been in school:
- Local companies that were "friendly" ... might involve having a friend
who's dad worked there.
- Local shops, schools etc.
- BBS systems - lots of other "geeks" hung out there, many with good
connections... fidonet was king before the internet.
>> I guess what I am saying, is that if you are not prepared to be a little
>> creative, you are probably not well suited to designing/building your own
>> test equipment.
>
>Are you saying I'm not creative?
NO! that was a general comment, and NOT directed to you specifically.
- I know you are creative (from your postings), and you did solve the problem
- no need to defend your honor any further.
but.. especially in todays world (as you point out), having to get the "first"
ROM programmed should not be a show stopper. Even that is only an issue if the
OP decided to build my design "as is" - as discussed earlier in this message,
a little flash device could be used and then all you need is a serial or parallel
port to program it (depending on the requirements of the device). To me (primarily
a software guy), using a little controller with lots of I/O and ability to time
pulses far more accurately than winblows, it still makes sense to design a micro
based device.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
>From: "Stephane Tsacas" <stephane.tsacas(a)gmail.com>
>
>ahhhhh okay :)
>You mean if you have 23 as input (2 digits/ascii code of 2 and 3) the
>output should be the binary value 0x23 in one byte. Correct ?
>So input is ascii and output is a binary file, not ascii.
Hi Stephane
Now you got it.
Dwight
>
>awk --non-decimal-data 'BEGIN {RS=" "} {x="0x"$0; printf("%c", 0+x);}' |
>od -t x1
>0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 1F 20 FA FB FC FD FE FF
>0000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>0000020 10 11 1f 20 fa fb fc fd fe ff
>0000032
>
>I use 'od' to do the binary to ascii conversion so I can print the
>result. But you can also redirect the output in a file and load it in
>emacs (in hexl-mode) to double check.
>Massaging of the value can be done before the printf as in :
>awk --non-decimal-data 'BEGIN {RS=" "} {x=$0; x++; x="0x"x;
>printf("%c", 0+x);}'|od -t x1
>1 2 3
>0000000 02 03 04
>
>/s
>On Fri, 30 Jul 2004 19:40:51 -0700 (PDT), Dwight K. Elvey
><dwight.elvey(a)amd.com> wrote:
>>
>> >Date: Sat, 31 Jul 2004 04:16:09 +0200
>> >From: "Stephane Tsacas" <stephane.tsacas(a)gmail.com>
>> >To: "Dwight K. Elvey" <dwight.elvey(a)amd.com>, "General Discussion: On-Topic
and
>> Off-Topic Posts" <cctalk(a)classiccmp.org>
>> >Subject: Re: OT-ish - converting hex output to binary on a Unix platform
>> >
>> >awk --non-decimal-data 'BEGIN {RS=" "} {x="0x"$0; printf("%d ", x)}'
>> >0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 1F 20 FC FD FE FF
>> >0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 31 32 252 253 254 255
>> >
>> >better ?
>>
>> Hi
>> I think your still missing the point. Your printout is
>> all in ascii. If things were working as expected the
>> number '31' hex would display as '1' when printed. Many hex
>> numbers would not even display. It looks like the variable
>> is now correct but you need to write it as the byte value
>> to a file not convert it to the decimal printed
>> as ascii digits. 255 is the binary values that are 00110010
>> 00110101 00110101. This is 3 values not the one value 11111111.
>> I think you are still confusing the byte with the displayed
>> value.
>> Am I making sense?
>> Dwight
>>
>>
>>
>> >
>> >On Fri, 30 Jul 2004 18:26:12 -0700 (PDT), Dwight K. Elvey
>> ><dwight.elvey(a)amd.com>
>> >wrote:
>> >...
>> >> I'm not sure this is what he is looking for. I think
>> >> he wants the hex number converted to a byte value
>> >> not just printed in ascii as a binary value.
>> >> Dwight
>> >>
>> >>
>> >
>>
>>
>