15 Feb
2016
15 Feb
'16
10:25 a.m.
Hi, all,
I have a question about old Mask-Programmed ROMs
The part in question is the National Semiconductor MM5231. This part is
a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but
also can be organized (via a MODE pin)as 512x4 bits. In this particular
application, the parts are used as 256x8.
I'm wondering if anyone knows if these particular ROMs (from the '72
timeframe) have a tendency for bit rot over the years?
I know some of the early MOS ROMs had issues with metallization creep
that would cause data loss/corruption.
I have an old calculator that uses these ROMs as the micro and macrocode
stores.
The machine is catatonic, though the power supplies, master clock
oscillator and divider circuitry, and the other obvious stuff are OK.
I suspect it is probably stuck in some kind of microcode loop, just
cycling around doing nothing. I have not yet put logic analyzer on the
microcode latches yet, but that's probably my next experiment.
Sadly, if one or more of these ROMs (there are 18 of them!) has failed,
it likely means that the machine can't be restored to operation, as this
is quite a rare machine, and there just aren't many of them left around.
I have three different EPROM programmers, but sadly, none of them have
the capability to read these parts. I was I had a Data I/O programmer,
but alas, haven't come across one with all the Unipak modules I'd need
at a price I can afford.
Thanks,
-Rick
---
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
15 Feb
15 Feb
11:09 a.m.
The ones you have to watch out for as a rule are those made by Mostek. Not
sure of the date when they changed to recipe.
If your still in/near PDX I will be getting my Unisite+ back in March and I
may have a working Model 29 that you can borrow.
-pete
On Mon, Feb 15, 2016 at 10:25 AM, Rick Bensene <rickb at bensene.com> wrote:
Hi, all,
I have a question about old Mask-Programmed ROMs
The part in question is the National Semiconductor MM5231. This part is
a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but
also can be organized (via a MODE pin)as 512x4 bits. In this particular
application, the parts are used as 256x8.
I'm wondering if anyone knows if these particular ROMs (from the '72
timeframe) have a tendency for bit rot over the years?
I know some of the early MOS ROMs had issues with metallization creep
that would cause data loss/corruption.
I have an old calculator that uses these ROMs as the micro and macrocode
stores.
The machine is catatonic, though the power supplies, master clock
oscillator and divider circuitry, and the other obvious stuff are OK.
I suspect it is probably stuck in some kind of microcode loop, just
cycling around doing nothing. I have not yet put logic analyzer on the
microcode latches yet, but that's probably my next experiment.
Sadly, if one or more of these ROMs (there are 18 of them!) has failed,
it likely means that the machine can't be restored to operation, as this
is quite a rare machine, and there just aren't many of them left around.
I have three different EPROM programmers, but sadly, none of them have
the capability to read these parts. I was I had a Data I/O programmer,
but alas, haven't come across one with all the Unipak modules I'd need
at a price I can afford.
Thanks,
-Rick
---
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
12:52 p.m.
On Mon, Feb 15, 2016 at 11:25 AM, Rick Bensene <rickb at bensene.com> wrote:
I know some of the early MOS ROMs had issues with
metallization creep
that would cause data loss/corruption.
That would certainly do it, but it's the first time I've heard of it
with regard to masked ROMs.
I have three different EPROM programmers, but sadly,
none of them have
the capability to read these parts. I was I had a Data I/O programmer,
but alas, haven't come across one with all the Unipak modules I'd need
at a price I can afford.
It's not obvious that even a Data I/O would read them. With at least
"recent" Data I/O models, they often won't read masked-ROM
microcontrollers because they detect that the supply current is out of
range for EPROM parts.
If I were going to read those, I'd wire them up to the pins of a
microcontroller. I've been doing that lately for other non-standard
ROMs, such as the Western Digital microcode ROMs used in the LSI-11,
Alpha Micro AM100, and Pascal Microengine.
Obviously you should try to read them by electrical means first.
However, if you eventually become completely convinced that you
haven't (or can't) get the correct data out of them in that way, it
will be time to start thinking about decap. It seems fairly likely
that it will be possible to optically distinguish the intended states
of the bits, as opposed to the actual electrical connectivity. This
has been done successfully with NiCr bipolar PROMs suffering from fuse
regrowth, though the problem for masked ROMs isn't completely the
same.
10:31 p.m.
On 02/15/2016 10:25 AM, Rick Bensene wrote:
Hi, all,
I have a question about old Mask-Programmed ROMs
The part in question is the National Semiconductor MM5231. This part is
a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but
also can be organized (via a MODE pin)as 512x4 bits. In this particular
application, the parts are used as 256x8.
I'm wondering if anyone knows if these particular ROMs (from the '72
timeframe) have a tendency for bit rot over the years?
I know some of the early MOS ROMs had issues with metallization creep
that would cause data loss/corruption.
I have an old calculator that uses these ROMs as the micro and macrocode
stores.
The machine is catatonic, though the power supplies, master clock
oscillator and divider circuitry, and the other obvious stuff are OK.
I suspect it is probably stuck in some kind of microcode loop, just
cycling around doing nothing. I have not yet put logic analyzer on the
microcode latches yet, but that's probably my next experiment.
Sadly, if one or more of these ROMs (there are 18 of them!) has failed,
it likely means that the machine can't be restored to operation, as this
is quite a rare machine, and there just aren't many of them left around.
I have three different EPROM programmers, but sadly, none of them have
the capability to read these parts. I was I had a Data I/O programmer,
but alas, haven't come across one with all the Unipak modules I'd need
at a price I can afford.
Thanks,
-Rick
---
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
Rick, if you want to archive these PROMs (highly recommended) you should
be able to find a Data I/O 29B and get one of the programming packs that
supports NS chips. I may have such a combination in my collection, but
that PROM is not listed in my DATA I/O library of readable parts. Part
of the problem with the early PROMs is they needed a Sync or Clock
signal to be able to be read.
If I think of it tomorrow I will go through my sets, but the best place
right now is for you to post this request on the Data I/O mail list on
Yahoo...."Data_IO_EPROM" and see if someone there can give you better
advice.
John :-#)#
--
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
www.flippers.com
"Old pinballers never die, they just flip out"
11:25 p.m.
On Mon, Feb 15, 2016 at 11:31 PM, John Robertson <jrr at flippers.com> wrote:
Rick, if you want to archive these PROMs (highly
recommended) you should be
able to find a Data I/O 29B and get one of the programming packs that
supports NS chips. I may have such a combination in my collection, but that
PROM is not listed in my DATA I/O library of readable parts.
They're not PROMs, they are masked ROMs, and there is *NO* equivalent
PROM, so it's unlikely that there's any support for reading them on
any PROM programmer.
Part of the
problem with the early PROMs is they needed a Sync or Clock signal to be
able to be read.
The MM4221/5221 is fully static, so it doesn't have that particular problem.
It's PMOS, and needs +5V and -12V supplies. The outputs are
TTL-compatible, but the inputs technically are not, due to Vih min of
3.0V. Could be driven by TTL with a pullup resistor, or by CMOS.
16 Feb
16 Feb
12:04 a.m.
On 02/15/2016 11:25 PM, Eric Smith wrote:
On Mon, Feb 15, 2016 at 11:31 PM, John Robertson
<jrr at flippers.com> wrote:
Does it share the same pinout as the 1702 MOS Eprom? I can read and
program those EPROMs in my shop. The 1705 has a Vcc of +5, and a Vdd of
-9 to a maximum of -20VDC, it is a 24 pin device though.
John :-#)#
--
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
www.flippers.com
"Old pinballers never die, they just flip out"
Rick, if you want to archive these PROMs (highly
recommended) you should be
able to find a Data I/O 29B and get one of the programming packs that
supports NS chips. I may have such a combination in my collection, but that
PROM is not listed in my DATA I/O library of readable parts.
They're not
PROMs, they are masked ROMs, and there is *NO* equivalent
PROM, so it's unlikely that there's any support for reading them on
any PROM programmer.
Part of the
problem with the early PROMs is they needed a Sync or Clock signal to be
able to be read.
The MM4221/5221 is fully static, so it doesn't have that
particular problem.
It's PMOS, and needs +5V and -12V supplies. The outputs are
TTL-compatible, but the inputs technically are not, due to Vih min of
3.0V. Could be driven by TTL with a pullup resistor, or by CMOS.
11:06 a.m.
On 2016-Feb-15, at 11:25 PM, Eric Smith wrote:
On Mon, Feb 15, 2016 at 11:31 PM, John Robertson
<jrr at flippers.com> wrote:
Apparently there actually is an equivalent EPROM, according to this
datasheet for the MM4203/MM5203 EPROM:
http://www.datasheetarchive.com/dl/Scans-006/Scans-00137265.pdf
It states they are pin-compatible to the MM5213/MM5231 mask ROMs.
The EPROM even has the selectable configuration mentioned by Rick.
(This is the only mention I've found of the 5231, I haven't come across this Nat
Semi ROM series before.)
Similar pinout to the 1702 (quite different than the industry standard of the
2708,2716,2732,etc.)
I expect they're too early and too uncommon to be covered by anything other than a
specifically-targeted programmer from the period.
It shouldn't be difficult to read them either way - adapter for an EPROM reader or
microcontroller, with additional power supplies as necessary, might have to consider
power-sequencing issues though.
Rick, what calculator are they in?, I'd be interested in looking it up on your site.
Rick, if you want to archive these PROMs (highly
recommended) you should be
able to find a Data I/O 29B and get one of the programming packs that
supports NS chips. I may have such a combination in my collection, but that
PROM is not listed in my DATA I/O library of readable parts.
They're not PROMs, they are masked ROMs, and there is *NO* equivalent
PROM, so it's unlikely that there's any support for reading them on
any PROM programmer. 
12:43 p.m.
It is interesting, I have 1702As that were programmed in 1973 sometime
and they still have their data ( used on my SIM4-01 ).
And yes, I have them backed up.
It is interesting that Data I/O has added supply current
checks. I've used many home made pin adapters over the
years to read old ROMs, as John probably knows, as some
were from pin ball machines.
Some of the earlier ROM also had address latches built in,
making reading tough.
Anyway, making pin adapters is not that hard. I usually stack
a three solder pin, machine pin sockets.
In place I don't want any connection, like Vpp, I pop the pin
out. In other places where I need to rewire, I break the
solder pin off and file it down a little so it won't short.
I do connections and sometimes vector side boards with
soldered wire wrap wire. Often I need switches or sometimes
logic off to the side.
It only takes 15 or so minute to put a typical adapter
together.
Dwight
________________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Brent Hilpert
<hilpert at cs.ubc.ca>
Sent: Tuesday, February 16, 2016 11:06 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Old MOS Mask-Programmed ROM forgetfulness?
On 2016-Feb-15, at 11:25 PM, Eric Smith wrote:
On Mon, Feb 15, 2016 at 11:31 PM, John Robertson
<jrr at flippers.com> wrote:
Apparently there actually is an equivalent EPROM, according to this
datasheet for the MM4203/MM5203 EPROM:
http://www.datasheetarchive.com/dl/Scans-006/Scans-00137265.pdf
It states they are pin-compatible to the MM5213/MM5231 mask ROMs.
The EPROM even has the selectable configuration mentioned by Rick.
(This is the only mention I've found of the 5231, I haven't come across this Nat
Semi ROM series before.)
Similar pinout to the 1702 (quite different than the industry standard of the
2708,2716,2732,etc.)
I expect they're too early and too uncommon to be covered by anything other than a
specifically-targeted programmer from the period.
It shouldn't be difficult to read them either way - adapter for an EPROM reader or
microcontroller, with additional power supplies as necessary, might have to consider
power-sequencing issues though.
Rick, what calculator are they in?, I'd be interested in looking it up on your site.
Rick, if you want to archive these PROMs (highly
recommended) you should be
able to find a Data I/O 29B and get one of the programming packs that
supports NS chips. I may have such a combination in my collection, but that
PROM is not listed in my DATA I/O library of readable parts.
They're not PROMs, they are masked ROMs, and there is *NO* equivalent
PROM, so it's unlikely that there's any support for reading them on
any PROM programmer.
1:50 p.m.
On 02/16/2016 12:43 PM, dwight wrote:
It is interesting, I have 1702As that were programmed
in 1973 sometime
and they still have their data ( used on my SIM4-01 ).
And yes, I have them backed up.
It is interesting that Data I/O has added supply current
checks. I've used many home made pin adapters over the
years to read old ROMs, as John probably knows, as some
were from pin ball machines.
Some of the earlier ROM also had address latches built in,
making reading tough.
Anyway, making pin adapters is not that hard. I usually stack
a three solder pin, machine pin sockets.
In place I don't want any connection, like Vpp, I pop the pin
out. In other places where I need to rewire, I break the
solder pin off and file it down a little so it won't short.
I do connections and sometimes vector side boards with
soldered wire wrap wire. Often I need switches or sometimes
logic off to the side.
It only takes 15 or so minute to put a typical adapter
together.
Dwight
And one could use a 9-Volt battery for the -9 on one of these home-made
adapters...
John :-#)#
2:22 p.m.
On Tue, Feb 16, 2016 at 12:06 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Apparently there actually is an equivalent EPROM,
according to this
datasheet for the MM4203/MM5203 EPROM:
http://www.datasheetarchive.com/dl/Scans-006/Scans-00137265.pdf
It states they are pin-compatible to the MM5213/MM5231 mask ROMs.
Interesting. I checked the MM5204, but not the MM5203. The MM5203
requires wiring for pins 22 and 23 that the MM5231 doesn't, but other
than that it does appear the same.
17 Feb
17 Feb
5:52 p.m.
Brent Hilpert wrote:
Apparently there actually is an equivalent EPROM,
according to this
datasheet for the MM4203/MM5203 EPROM:
http://www.datasheetarchive.com/dl/Scans-006/Scans-
00137265.pdf
It states they are pin-compatible to the MM5213/MM5231 mask ROMs.
The EPROM even has the selectable configuration mentioned by Rick.
(This is the only mention I've found of the 5231, I haven't come
across
this
Nat Semi ROM series before.)
A great find! Sadly, though, I can't find that even the Data I/O 29B
Unipak supports programming this device.
My other ROM programmers don't support the MM5203, either. I suspect
that this was a fairly obscure device.
Similar pinout to the 1702 (quite different than the industry standard
of the
2708,2716,2732,etc.)
Yes, but there are enough differences that building an adapter, and
getting it to work is probably not worth the effort.
I expect they're too early and too uncommon to be covered by anything
other than a specifically-targeted programmer from the period.
I suspect that National probably offered some kind of programmer for
these devices, but, as Brent said, it was probably very targeted to the
specific device family. Finding something like this today is probably
like finding Hen's Teeth.
It shouldn't be difficult to read them either way
- adapter for an
EPROM
reader or microcontroller, with additional power
supplies as
necessary,
might have to consider power-sequencing issues though.
I think that this is the approach that I'm going to have to take. I
have a little microprocessor development system that has a bunch of
programmable TTL I/Os (probably need some pullups on the outputs to
drive the address lines), and perhaps some kind of switching on the -12V
supply to keep the power levels appropriate, and write a little code to
cycle through the address lines and grab the data, and spit it out in
serial form to a PC.
Rick, what calculator are they in?, I'd be interested in looking it up
on your
site.
I don't have it documented on the Old Calculator Museum site yet,
because I generally only put calculators up on the online exhibits page
that are fully operational. I've got a slew of machines that aren't on
the website because they require repair. Sadly, repair on these old
machines can chew up a huge amount of time, so it's slow going. Maybe I
have to change my policy on this, but it's a tough call.
The calculator in question is a Singer/Friden 1155A.
It is a desktop printing scientific programmable calculator. It is
quite sophisticated, but, by the time it came to market (mid-1972),
Singer had pretty much decided that the calculator biz was a bust, and
has pretty much killed off what was left of Friden's calculator
development team. Along with that, Hewlett Packard, Computer Design
Corp., and Wang pretty much owned the high-end calculator market, making
it tough for anyone else to compete.
The machine is rather uncommon, because of the factors about, and also
because simply didn't sell very well, mostly due to a lack of desire or
understanding on the part of Singer's salesforce to figure out what
markets to sell it into.
The introduced machine used a modified version of the serial printer
used in earlier 115x-series calculators.
It uses three TI(TMS3414LC) or Signetics equivalent 1K-bit MOS shift
registers for program storage, and four Intel 1101A MOS SRAM chips for
microcode internal working registers and memory register storage. The
machine has 20 memory registers accessible to the user.
A later version of the 1155, called the 1155A, switched from four
1101A's to eight 2102 SRAM chips, and upped the memory register capacity
to 100 registers. Of course, some firmware changes were made to
accommodate the additional RAM.
The machine uses SSI and MSI DTL and TTL logic for the ALU, Data
Routing, and the timing and control logic.
I do have microcode ROM listings for the 1555, but since the machine I
have is the 1155A, there are likely to be some changes, both in terms of
fixes from the original firmware, as well as the modifications needed to
make it work with the additional RAM. So, if a ROM that contains
changes from the original code is bad...well, it's not terribly likely
that I'll be able to fix it unless I can reverse-engineer the microcode.
Yet more time that I probably won't ever have.
-Rick Bensene
7:05 p.m.
I was about ready to recommend the same approach. Speed is not the issue.
Then when if the time ever comes to replace the part one could if have to
build a board to do any level/timing shifts.
A solution I've used before.
On Wed, Feb 17, 2016 at 5:52 PM, Rick Bensene <rickb at bensene.com> wrote:
Brent Hilpert wrote:
Apparently there actually is an equivalent EPROM,
according to this
datasheet for the MM4203/MM5203 EPROM:
http://www.datasheetarchive.com/dl/Scans-006/Scans-
00137265.pdf
It states they are pin-compatible to the MM5213/MM5231 mask ROMs.
The EPROM even has the selectable configuration mentioned by Rick.
(This is the only mention I've found of the 5231, I haven't come
across
this
Nat Semi ROM series before.)
A great find! Sadly, though, I can't find that even the Data I/O 29B
Unipak supports programming this device.
My other ROM programmers don't support the MM5203, either. I suspect
that this was a fairly obscure device.
Similar pinout to the 1702 (quite different than the industry standard
of the
2708,2716,2732,etc.)
Yes, but there are enough differences that building an adapter, and
getting it to work is probably not worth the effort.
I expect they're too early and too uncommon to be covered by anything
other than a specifically-targeted programmer from the period.
I suspect that National probably offered some kind of programmer for
these devices, but, as Brent said, it was probably very targeted to the
specific device family. Finding something like this today is probably
like finding Hen's Teeth.
It shouldn't be difficult to read them either
way - adapter for an
EPROM
reader or microcontroller, with additional power
supplies as
necessary,
might have to consider power-sequencing issues
though.
I think that this is the approach that I'm going to have to take. I
have a little microprocessor development system that has a bunch of
programmable TTL I/Os (probably need some pullups on the outputs to
drive the address lines), and perhaps some kind of switching on the -12V
supply to keep the power levels appropriate, and write a little code to
cycle through the address lines and grab the data, and spit it out in
serial form to a PC.
Rick, what calculator are they in?, I'd be interested in looking it up
on
your
site.
I don't have it documented on the Old Calculator Museum site yet,
because I generally only put calculators up on the online exhibits page
that are fully operational. I've got a slew of machines that aren't on
the website because they require repair. Sadly, repair on these old
machines can chew up a huge amount of time, so it's slow going. Maybe I
have to change my policy on this, but it's a tough call.
The calculator in question is a Singer/Friden 1155A.
It is a desktop printing scientific programmable calculator. It is
quite sophisticated, but, by the time it came to market (mid-1972),
Singer had pretty much decided that the calculator biz was a bust, and
has pretty much killed off what was left of Friden's calculator
development team. Along with that, Hewlett Packard, Computer Design
Corp., and Wang pretty much owned the high-end calculator market, making
it tough for anyone else to compete.
The machine is rather uncommon, because of the factors about, and also
because simply didn't sell very well, mostly due to a lack of desire or
understanding on the part of Singer's salesforce to figure out what
markets to sell it into.
The introduced machine used a modified version of the serial printer
used in earlier 115x-series calculators.
It uses three TI(TMS3414LC) or Signetics equivalent 1K-bit MOS shift
registers for program storage, and four Intel 1101A MOS SRAM chips for
microcode internal working registers and memory register storage. The
machine has 20 memory registers accessible to the user.
A later version of the 1155, called the 1155A, switched from four
1101A's to eight 2102 SRAM chips, and upped the memory register capacity
to 100 registers. Of course, some firmware changes were made to
accommodate the additional RAM.
The machine uses SSI and MSI DTL and TTL logic for the ALU, Data
Routing, and the timing and control logic.
I do have microcode ROM listings for the 1555, but since the machine I
have is the 1155A, there are likely to be some changes, both in terms of
fixes from the original firmware, as well as the modifications needed to
make it work with the additional RAM. So, if a ROM that contains
changes from the original code is bad...well, it's not terribly likely
that I'll be able to fix it unless I can reverse-engineer the microcode.
Yet more time that I probably won't ever have.
-Rick Bensene
16 Feb
16 Feb
4:51 a.m.
Rick Bensene wrote:
Hi, all,
I have a question about old Mask-Programmed ROMs
The part in question is the National Semiconductor MM5231. This part is
a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but
also can be organized (via a MODE pin)as 512x4 bits. In this particular
application, the parts are used as 256x8.
I'm wondering if anyone knows if these particular ROMs (from the '72
timeframe) have a tendency for bit rot over the years?
I know some of the early MOS ROMs had issues with metallization creep
that would cause data loss/corruption.
I have an old calculator that uses these ROMs as the micro and macrocode
stores.
The machine is catatonic, though the power supplies, master clock
oscillator and divider circuitry, and the other obvious stuff are OK.
I suspect it is probably stuck in some kind of microcode loop, just
cycling around doing nothing. I have not yet put logic analyzer on the
microcode latches yet, but that's probably my next experiment.
Sadly, if one or more of these ROMs (there are 18 of them!) has failed,
it likely means that the machine can't be restored to operation, as this
is quite a rare machine, and there just aren't many of them left around.
I have three different EPROM programmers, but sadly, none of them have
the capability to read these parts. I was I had a Data I/O programmer,
but alas, haven't come across one with all the Unipak modules I'd need
at a price I can afford.
Thanks,
-Rick
---
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
I can only speak for similar east german made ROMs, both 256x8 and 1024x8.
The 256x8 (U501) part was pin compatible to the 1702A and the other one (U505)
to the 2708 and both of them (1st PMOS, 2nd NMOS) where much less reliable than
the compatible Eproms. In fact if I get a bad PCB with such ROMs I've
expect a failed ROM first.
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
3230
days inactive
3233
days old
12 comments
7 participants
participants (7)
-
dkelvey＠hotmail.com -
hilpert＠cs.ubc.ca -
holm＠freibergnet.de -
jrr＠flippers.com -
pete＠petelancashire.com -
rickb＠bensene.com -
spacewar＠gmail.com