Intel 2708 EPROM

[Phil__G]

Horrible things, my Nascom-1 was full of them
thankfully we were rescued by the 2716

https://www.allaboutcircuits.com/news/intel-2708-the-eprom-that-made-microcomputers-programmable/

I recall those both well. A pity though that so many manufacturers fitted them as permanent issue, rather than a solid ROM. There must be quite a bit of kit from the period now useless, as the EPROM content has vapourised.

[TonyDuell]

Other than needing 3 power rails (which the Texas TMS2716 did also), what's 'horrible' about the 2708? I've not found them particularly troublesome.

Last time I came across said chip was about a month ago when I was repairing a couple of RS232-interfaced tape drives. I've attached photos of the processor boards, the first is SC/MP based, the second uses an 1802.

The 2708 is considerably nicer to program and use than the 1702A (256 byte EPROM) which I've also come across in devices I've worked on in the last year.

[Phil__G]

That was tongue-in-cheek Tony But in some late 70s early 80s boards their 2708s were the only reason for three-rail supplies with correct power-up sequencing... yes at the time they were great, but when the 2716 arrived you then realised how much easier life had become on a single-rail supply
I stlll have cases of 2708s with Nascom T1, T2, B-Bug, three Nas-sys's, revas, tiny basic, zeap, RTTY etc - all have been dumped so will probably remain there until mortal coils are shed

[ortek_service]

Yes, there were worse EPROM's to have to use - like the original 1702, where it took 20mins to program, despite small size, as you had to let it cool-down for much-of the time between programming each Byte.

And the NS MM5204 was a little bit of an oddity, needing two-rails (As original PMOS SC/MP CPU, these were mostly used-with, had). Although some early-NMOS devices like the 8080 had also needed an extra supply-rail (whereas 6800 had included an on-chip charge-pump to generated this). With not too many IC-programmers for the MM5204.

Later Computers went on to need the 3 supply-rails for DRAM's - with maybe the 4116 being the equivalent in DRAM''s to the 2708. Although the single-rail 4816 never got widely-used, outside of the BBC Computer (Maybe as it seemed only Hitachi made them, whereas there were loads of manufacturers of 4116's)
The same for the 2758, single-rail version of the 2708, where it seems half-dead 2716 dies were often used: https://www.reddit.com/r/hardware/comments/1oih61q/chip_binning_is_probably_older_than_you_think_in/
(Like Spectrum's using TMS4532's that were half-dead 4164's)

Although the 1KB 2708 was often replaced with actual 2KB 2716's, in old arcade machine etc. for better availability / reliability.
Probably the same for the more-rarely encountered only 512Byte 2704's.

It is the TMS2716 3 supply-rail version, that's harder to see why anyone would have used unless they available earlier / cheaper than other manufacturer's 2716's. And led to TI having to produce TMS2516 single-rail versions. Also then leading to 2532 and rarer 2564, with slightly-different pinout to 27xx versions.


The retention period of all EPROM's was usually spec'd as 10yrs min. And I don't think 2708's were any-worse than most-others (But may have been less-reliable than single-rail ones, like with 4116's DRAM's), with many EPROM's still luckily retaining their contents after 40+ years!.
It's the same with more-modern FLASH devices, which could still lose contents after 10yrs. And SSD's are apparently class as worn-out when retention drops to only 2yrs, so HDD's can be rather-better.

[SiriusHardware]

In 1979 I was building myself a synthesised radio transceiver based on the PCB (only) of a commercially made set and one of the problems I had was a lack of a channel selection switch, a highly specialised part which generated not only the binary PLL codes but the LED channel display segment codes.

A microcontroller would have been the obvious solution but these were unknown to me and several years into my future at the time.

I hit on the idea of using a TTL BCD up / down counter followed by two 7447 BCD to 7-segment displays for channel up / down selection and channel display, and then taking the BCD output from the up / down counter to the address inputs on an EPROM which would then output the corresponding binary codes to the PLL. This eventually became a widely used method for changing one set of PLL codes to another but at the time, there was no internet, no books on this subject, so it was something I was quite proud of having thought of.

On my next visit to my local electronics emporium I asked them if they had any EPROMs and I don't remember what the alternatives were but I came away with... a 2708.

Again, remember this is all pre-internet, any information that there was was contained in paper data books. When I eventually did get hold of the data I was appalled to discover its exotic supply requirements, as I had assumed that it was a single-rail device.

I also hadn't given any thought to the possible need to erase it or how I was going to programme it - the only 'computer' of any sort that I had at the time was my SoC MK14 which I had already used to generate, supply and verify the correct channel codes for the PLL. I had had a vague idea that I would use the MK14 as the basis for a single use EPROM programmer - all of which was possible and on the digital side, within my then capabilities, but the exotic supply requirement for the EPROM effectively sidelined it for me and in the end I ended up using a huge diode matrix in place of the EPROM.

Thinking about it now, the more obvious approach, given that I did have an MK14, was to buy the optional DM74S571 PROM programmer for it and programme the channel codes into PROMs which were widely available and quite cheap at the time - but for some reason that never occurred to me.

Two or three years later I built a ZX Spectrum driven EPROM programmer by which time 2716, 2732, etc were very much mainstream and, faced with these much more convenient single rail alternatives, I came across the 2708, thought 'why on earth would I ever use that now?' and discarded it.

Even to this day, although I have several 'legacy' programmers which in theory do support the 2708, none of them actually do because I don't have the required optional adaptors. They really were just more trouble than they were worth, although I can understand them having been used during that short period when they were just about the only programmable / erasable memory ICs available.

Originally Posted by ortek_service

The retention period of all EPROM's was usually spec'd as 10yrs min. And I don't think 2708's were any-worse than most-others (But may have been less-reliable than single-rail ones, like with 4116's DRAM's), with many EPROM's still luckily retaining their contents after 40+ years!.
It's the same with more-modern FLASH devices, which could still lose contents after 10yrs. And SSD's are apparently class as worn-out when retention drops to only 2yrs, so HDD's can be rather-better.

Which raises the point: What is the best current medium for long term safe storage? The "cloud" can vanish at any time. We are told that the retention of CD/DVDs is not all that good. It makes me think that good old magnetic tape might be favourite, except that it is no longer available. Back to paper perhaps...

[SiriusHardware]

It is absolutely the case that if you have still-working equipment from the 1970s or 1980s which has EPROMs in you should first read and save their current contents and distribute the saved files as widely as you reasonably can, even to the point of also printing out a hex dump of the code and placing it in a light proof envelope - you should also then reprogramme / refresh the EPROMs, if you have the means to do so, to reset the 'data fade' clock back to zero.

[bluepilot]

Originally Posted by lesmw0sec

The "cloud" can vanish at any time.

Now that everyone from software companies to the NSA have realised how useful the cloud is for everything from making people pay subscriptions for using software to spying on everyone's data, I can't image that it will disappear. It may get more expensive but too many people have vested interests in it to let it disappear. Maybe WW3 would obliterate it but then I think we would have more serious problems than keeping an old Commodore Pet running. However paper probably keeps longest although not much use for printing out TB of data.

[Mark1960]

I think the point was not that all clouds might disappear, but the one you have your data stored in might, or the operator decides to increase your costs or cancels the service. Similar with devices dependent on cloud services if the operator decides its no longer in their interest to continue supporting those devices. Always best to have multiple backup copies stored in separate places and avoid devices dependent on remote services.

[ortek_service]

Someone apparently once said that something is only truly backed-up if stored in at least three places.
But it's probably also important to have at least one off-site in a different physical location, in case the worst happens. And do need to store it on media with an appropriate data-retention spec.
- Although, maybe with modern FLASH memory, re-writing it every few years will refresh it enough
Or copy it to a newer (usually much-larger) one.
And avoid using older less-universal interfaces, as like with Magnetic tape backup systems formats, you might struggle to find hardware that still supports older less common standards formats.

Putting everything solely in one cloud location, whilst you might need to worry about data retention periods does rely on them not suddenly disappearing - Even Amazon's Web Services, had a recent outage that affected many organisations that relied on it.
But having the cloud as a just copy, of several, does mean you can re-copy to another if you suddenly lose access to one.

It seems datacentres just use lots of HDD's (Maybe now SSSD's?), and rely on RAID (even across multiple datacentre locations?) to ensure data can't be lost. With backing-up to tape not feasible with such large amounts of constantly-changing data.
So having multiple HDD's, with one in another location, is usually sufficient as HDD's generally have quite good data-retention. However, the mechanism could possibly crash / controller electronics fail at any moment, especially with age so always need several.

Paper, (Ideally acid-free that's no-longer available / even better Velum still being used for acts of Parliament!) is probably one of the longest retention periods.
And most valuable data / artefacts are now being stored in special storage vault facilities in remote cold places of the world (Presumably away from fault-lines, in case of Earthquakes)


So having a backup of an EPROM, on another similar EPROM programmed at the same time, probably isn't that good a backup-strategy if they will eventually start to lose their data. And even Fusible-link PROM's / ROM's, like all IC's, can be prone to failure with metals migration issues etc, so should also be backed-up. With IC design-lifetimes (MTBF's) often not actually being as long as you might expect (Rather a problem for deep-space probes!) with older technologies sometimes being more-robust.

And it does also mean needing to have hardware you can still use / adaptors that supports all of the types you require.

But, realistically, you probably only need to be able to personally retain copies for a few-decades to still have access to it in your remaining lifetime. And if shared-out to others on the 'net, then they too can do similar for the future, beyond that.

[Phil__G]

How about a raid array of eproms?

[SiriusHardware]

I think putting files on the public internet is a great way to ensure that they are scattered far and wide and squirrelled away in as many places as possible.

There are hex files and bits of source code etc which we've attached to posts here which have been 'read' hundreds of times - of course many of those 'reads' may have been by bots but even if just a dozen or so of the downloads were by humans that's going to increase your chances of finding / retrieving a copy from somewhere online if something wipes out your own copies.

If doing this as a deliberate strategy then it is a good idea to give the files unique and meaningful names - calling a file 'EPROM.BIN' would not be a good strategy if you were ever hoping to find that exact same file again as you'd have to work through hundreds of same-named files which happen to have the same name but no other connection to your original version.

Obviously, as soon as you put something online you have no control over what happens to it and no absolute right to get it back if every single person who downloads it just puts in an offline folder against the day when they might need it. But the odds are that at least one copy will end up in an online repository somewhere.

[ortek_service]

Originally Posted by Phil__G

How about a raid array of eproms?

That would be a RAIE then!
And not really any-different from just having backup copies of every EPROM (Image) you use, if just using an appropriate-size EPROM for the code.
So if all programmed at the same time, could in theory all lose their contents at the same time in as little a time as 10yrs worst-case
And with RAID, you've still typically only got one backup copy in the array, with nothing to guard against total failure of the system.

You could use much-larger EPROM's, to store multiple images, but then require a filing system to index them all. And even the largest EPROM's are relatively-small capacity compared to more-modern, less-obsolete media.

And this would also be effectively WORM-storage, without having to UV- erase them. So would really want to use EEPROM (that too isn't normally that large) or the more-modern FLASH version of that. Where you probably might as well use more-robust managed-FLASH with wear-levelling included.
So really then back to more-conventional SSD's, which you could make a more-conventional RAID array with. Or USB Memory stocks / SD-Cards.

You've still got the issue of possibly having not that relatively-long data-retention times/ But I think you probably just end-up refreshing the storage date every few years, when bury later generally much-higher capacity drives and migrating your existing data to that.
You could still keep the old media as backups, but might not want to rely on that that one it starts to get > 10yrs old. So would also want to have an appropriate modern-media backup.
Maybe, for personal-use with not that massive amounts of data, you could also supplement this with tape-cartridge backups. Using a system that you can still buy new cartridges for - So can periodically buy new ones to guard against the tape material disintegrating with age. But the tape-drives for these could be quite expensive / required SCSI etc / and may now be difficult to find new ones still being sold.

So I don't think EPROM's are too-appropriate. However, it's not a bad idea to program a spare-duplicate EPROM (Or EEPROM / FLASH), whilst digging out a suitable programmer / adaptor, to also guard against total IC failure - Always good to have at least one spare for every type of IC in a Computer system you're working on as they could now fail at any time (Although spare could also be a similar age), and tend to get harder to obtain once discontinued.

[nlpe1goo]

Originally Posted by ortek_service

So I don't think EPROM's are too-appropriate. However, it's not a bad idea to program a spare-duplicate EPROM (Or EEPROM / FLASH), whilst digging out a suitable programmer / adaptor, to also guard against total IC failure - Always good to have at least one spare for every type of IC in a Computer system you're working on as they could now fail at any time (Although spare could also be a similar age), and tend to get harder to obtain once discontinued.

I have back-ups of all my Scrumpel and SC/MP source-code on my NAS. Before that I copied the data on the newer HD of my newer Linux computer. The cross-assembler I use is still maintained so I compile the newest version then. If the E(E)PROM dies I get a always a copy of the original software on that PROM. Of course I've a correct programmer to program the proms. In worst case I have to re-assembler the source-code. so far as minicom is still available I can get access to my Scrumpels and SC/MP. If no source-code available then I save the Intel-hexdump of the prom on my NAS.

[Realtime]

Originally Posted by TonyDuell

.... I was repairing a couple of RS232-interfaced tape drives. I've attached photos of the processor boards, the first is SC/MP based .....

It would be really interesting to see / hear more on the SC/MP board (perhaps in a new thread?), being another example of a commercial product using SC/MP

[ortek_service]

Originally Posted by Realtime

It would be really interesting to see / hear more on the SC/MP board (perhaps in a new thread?), being another example of a commercial product using SC/MP

Yes - Relatively-rare to see these in a commercial product, that wasn't for Development use
And I see from those photos, that they used the later NMOS SC/MP(-II), along with quite a bit of TTL logic.
- But they still used rather-old 3 supply-rail EPROM's!

With this product now having a dedicated thread at: https://www.vintage-radio.net/forum/showthread.php?t=223645

[circuitryboy]

Am out of UK. Now need VPN to access!
Coming in late and at a tangent:
That SC/MP board has a 7907 '8060N with a stamp "SM62534".
This was also on many original MK14s.
Anyone know what it means?

You also see "A+", which denotes NS has pre-tested the IC.

I have pics (back at base) of other boards with SC/MPs.
If there's an interest I will post 'em.

[ortek_service]

Well many people on this forum are based around the World - So it shouldn't be restricted to UK only.
And must be some issue with where you currently are or what ISP / network you're accessing it via?

I presume you're no-doubt aware that '7907' is date-code - So 7th week of 1979.

I'd not heard about "A+", denoting NS has 'pre-tested the IC'. - And I'm not quite sure what 'pre-tested' is?
Is it any-different from just functionally-testing the IC, before despatch?
(Which you'd hope they would do on every IC, to ensure process quality, rather than having end-user solder these into products only to find they didn't work).
Maybe it's an extra 'qualification-testing' where it is operated at design-extremes to ensure it is not 'on-edge'

When I got my first SC/MP-II, it too had that "SM62534" number, which I'd originally thought had been put on afterwards and had some doubts about whether the IC was genuine (As other markings weren't straight, and it had come from China).
But I've seen many SC/MP-II's marked like that since then.

There was a thought it may be an in-house number, used by an OEM.
But it does seem to appear on so many of these, in a variety of equipment.
And Google doesn't really find anything of use about SM62534 - Not even 'AI'

[Realtime]

You find INS8060's right up to 1980 with the SM62534 marking, including this very rare ceramic INS8060D hosted on an MK14 (not mine unfortunately ). We already know the INS8060 had 2 other part numbers - ISP-8A/600 and MM47104 - so maybe this is a third one?

Would definately be interested to see pics of other examples of PCBs with 8060s when you have time.