Old MOS Mask-Programmed ROM forgetfulness?

[Rick Bensene]

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