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
