Tesla Programmer

[SiriusHardware]

Incidentally circuitryboy, looking back at your original thread as linked by Owen in #77 above, I see that your Tesla Editor PDF has been read more than 200 times since you posted it.

[ortek_service]

Originally Posted by SiriusHardware

I agree that time / speed is not as important as getting it right first time every time.

When I programmed a set of N82S131N recently using my All-07 programmer it programmed and verified each IC literally faster than I could blink, and I initially thought I must have made some stupid mistake like forgetting to load some code in first, but no, it really was that blindingly fast. I can only imagine that programmer must use a 'smart' regime where it uses a very short programming pulse, reads and retries until the programming of the bit is successful.

I'll be more than happy if my own effort takes a minute or three to programme each chip as long as it does it perfectly every time with no risk of damaging the device. I would be interested to know how long Chris's original incarnation of his programmer takes to programme the 512 nibbles of a Tesla MH74S571. To be on the safe side, mine shouldn't try to do it any faster.

That does seem very-quick with the N82S131N. I seem to recall 74S571's - both NS and Tesla ones taking 2-3mins on the Dataman-Pro Elnec-designed one (Possibly due to amount of 'cool-down' periods), taking a similar-time to older 2716 etc 50ms per-location EPROM-Programming (Rather than more-modern larger ones, that would program much-quicker with <=1ms pulses).

Although, unlike with EPROM's, the Elnec fusible-link PROM Algorithm was a bit more intelligent, and would skip locations already programmed, and not try to always re-do these - which was rather handy with some NOS NS? ones 74S287? that Chris once got to help a friend fix their Data-IO programmer , that were failing on first attempt at virtually every byte.
So I had to keep pressing retry, which although it went back to start (so had to disable 'blank-checking', rapidly counted back up to where it previously-failed. And I had wondered if ageing in old-stocks could maybe make these harder to program / if Elnec had not used a long-enough pulse on these - I think Chris said he'd not found any issues with NOS NS ones, on his Acorn System Programmer, that he'd updated software to support the DM74S287 as well as original DM74S571.
However, if only the odd few bits need programming in a fusible-link PROM, then that should be rather-quicker if rest can be skipped.

[SiriusHardware]

These were SCIOS V2 and V3 PROMs so there was significant data in almost every address and very few zero-nibbles which could be skipped. It really is just a very, very fast programmer at least when it comes to BPROMs. It's the same with DM74S571s and AM27S13s which it can also program.

The All-07 programmer was as high-end in its day (Early nineties) as the Elnec BeeProg2 / Dataman48Pro2 is now, and cost about £800-£900 which of course would have bought a lot more then than the same amount would now. It was (and perhaps still is) the most expensive single hobby-related item I ever bought, which is probably why I have kept it going for thirty years. (I needed to get my money's worth out of it!). It's still doing good service but the DOS laptop I've always driven it with died about a week ago - luckily I had a replacement available.

If there is one thing I do wish it is that the All-07 would allow the creation of 'custom' devices with user specified parameters and I think some other programmers did do that, but not this one unfortunately.

I think the manufacturers of programmable memories and microcontrollers were nervous about the possibility of problems being caused by 'bad' programmers or programming algorithms so they tended to enter into NDAs with the manufacturers of commercial programmers to endure that their devices would always be correctly programmed as long as an 'approved' commercial programmer was used.

[ortek_service]

Yes, I had been aware of Hi-Lo Systems programmers, that seemed to be up there with Data-IO at the top-end of the market- but not encountered so much in the UK / amongst hobbyists. And there is quite a bit of info on the ALL-07, here: http://matthieu.benoit.free.fr/hilos...programmer.htm

And I see Hi-Lo Systems are still going, mainly focussing on memory devices (Although apparently their ALL-300 does support 8-300pins, but not clear from pictures how you connect to these / need a custom adaptor board for each type of package) emphasising how much faster these are - upto 3x faster than (un-named) rival ones

The original Advantech-designed Dataman 48 Programmers did at least let you change some voltage & timing parameters for EPROM's etc, so may have been able to hack an existing one to do a non-supported type.
The S(ofty) 3 / 4 was much-more versatile, and they gave you all the parameters of the devices in the pribted manual, plus info about adding your own custom one. But unfortunately-obsolete, and I doubt the USB-controlled only S6 is as versatile, so older ones are still sought-after.

EPROM's weren't generally a problem to find out how to program, with brief details usually provided in the datasheet. Microcontrollers could be more of an issue, with parallel-programming EPROM-socket adaptor circuitry sometimes getting removed from later datasheet, and usually having to need a programmer that supported the special parameters / device, as couldn't just use a standard EPROM algorithm.
But less of an issue with later uC's, having standard ISP/ICP serial interfaces, fairly-low cost PC-Interfaces and usually free PC programming / IDE software.

It seems there are people working on more-open IC Tester / programmers - based on Arduino-Mega / RPi? that would allow working with older parallel-devices wthout needing to have old programmers / parallel-port PC's and old OS's - which would be good, and should also make moves to future programming hardware easier if the programming algorithm software can separated as open-source files that can be collaboratively updated.

[ortek_service]

For Info:

I've just been reading some discussions on the DataIO IC-Programmers Group, regarding Tesla-PROM's etc. programming: https://groups.io/g/DataioEPROM/topi...ted,,,20,2,0,0
- Although I'm not sure if you can read this, without subscribing to the group.

And they linked to this webpage, where someone else has designed a programmer for these and documented it (although need to translate to English): http://blog.3b2.sk/igi/post/SBC6502-...-Part-1-4.aspx

Also attached on that group was a full 1978 1979 IC linear digital Tesla Databook - in both English & Czech - that I can't recall had previously been found. But unfortunately too large to post a copy here, at 16MB, so have uploaded to Google drive, and here's a link for now: https://drive.google.com/file/d/1XEu...ew?usp=sharing
- as original thread about Tesla PROM programming: https://www.vintage-radio.net/forum/...d.php?t=146388 with previously-found / translated documents, is now closed, so would have to get re-opened.

[SiriusHardware]

Thanks for the additional info, Owen.

My own work on hooking up a 'modern' micro device to Chris Oddy's programmer PCB has completely stalled at the moment due to (non technical) circumstances at home which are taking up a lot of my time. The offer to Realtime of some 'spare' specific parts for his, like the inductor, the SMPSU IC and the low-ESR components and 74C906 IC is still there should he have more time to spare for his than I do. I need to send my MK14 Realview back to him for a service in any case, so I should really do that and send him the parts at the same time.

[ortek_service]

Unfortunately, I later found that the Tesla 1978/79 Databook is too old for the MH74S571 etc - With only 3 Bipolar Memory devices in that one. And the 74188 256bit (32x8bit) is the only PROM in there - Only 2 pages on it, but does at least give the programming voltage and pulse width for this.
Whereas there is a much-fuller (but Czech-Only) datasheet for the 74188, at:
https://datasheetspdf.com/pdf-file/1.../ETC/MH74188/1
(Although PDF'd rather strangely as one very long page, so needs some scaling to re-print)
However, I did notice that this databook does include the 4-pin leaded MH1SS1 / MH1ST1 IC's 'for contactless switches with magnetic field control', that I recall were previously discussed (in a Triton keyboards thread?)


Whilst the 1984/85 'Databook' - now uploaded to:
https://drive.google.com/file/d/1Ipe...ew?usp=sharing
has the MH74S571 & MH74S287, only has a single page covering all Bipolar Memory PROM's / RAM, and doesn't give any programming spec's.
So the summary of the Tesla programming procedure Chris did, still seems to be the most extensive / easiest to follow: http://www.theoddys.com/acorn/replic...mer_board.html

There may have been a Tesla 'Databook' between those dates, that included the MH74S571 / MH74S287, and hadn't been cut-down so much, but a copy doesn't seem to have been found on the 'net so far.

[Slothie]

A few years ago I used online tools to translate a Czech datasheet for the MH74S571 and posted it on a thread here. i just found it so I will repost it.

Unfortunately I can't immediately find the original Czech document or where I got the original from, I seem to recall it was a website with a page on each HTML page. I also found a Tesla databook but that might have been one of the ones you found.

[Slothie]

Originally Posted by Slothie

Unfortunately I can't immediately find the original Czech document or where I got the original from, I seem to recall it was a website with a page on each HTML page. I also found a Tesla databook but that might have been one of the ones you found.

Cancel that, I just found this.

[SiriusHardware]

I think that thanks to original detective work by Slothie, circuitryboy and ChrisOddy at different times and in different ways, the questions we originally had about how to program an MH74S571 have been pretty much answered, we have timing details which are known to work, we know how the pins to be programmed should be driven and that it isn't anything like the regime used by the Nat Semi 'DM' prefix devices but on the other hand is very similar to the routine used by the Texas SN74Sxxx PROM devices.

What we still don't have is an easily reproducible MH74S571 programmer which does not depend on the user already owning a working MK14 or Acorn system, which is a bit of a Catch-22 situation because the most likely reason anyone would want to program these devices is to get an original or replica Acorn or MK14 up and running.

This is as much my fault as anyone's since I have not had the opportunity to make progress with marrying my working 'Oddy' MH74S571 programmer card to a modern microcontroller.

[Slothie]

I'm going to get on with mine asap I just need to get the tools re-installed as I have just mentioned on the Ortonview PCB thread.

The MOSFETs I self distructed my last supply of in my last attempts at testing have been replaced with a slightly different part and my recall is that they seemed to work. I worked out the problem with the PCB layout (used the wrong footprint for 4 of the devices!) My current problem is the lack of a reliable scope that I can take timing measurements off, I think I may have to rig something up with my cheapo logic analyzer because taking any measurements with my Bitscope seems to virtually impossible due to the bizarre software that comes with it. I hear rumors of an open source replacement but have yet to find a Linux download for it.

I'm just not sure how to structure the software. and how to operate it - Do I put all the functions on the Arduino and a tty interface to download the hex files, or have an application that runs on the PC that communicates at a lower level with the device? The latter allows for more elegant handling of the upper/lower nibblr issue and is less susceptible to timing problems when transferring the Hex files but would require Linux/Windows and Mac Versions. The former requires only a terminal emulator but might require frustrating fiddling with pauses to prevent data loss. I am tending towards the former route, as I feel any real user of the device would have the technical nouse to overcome these issues.

[SiriusHardware]

My approach was, hopefully still is, going to be to have a terminal driven USB serial interface where you can either type commands like 'DP' (Dump) to read and checksum the content of an already programmed device as 'viewable' tabled hex, or 'DH' (dump contents as Intel Hex) or 'BC' (Blank-Check the device in the socket), 'PL' (Programme the device in the socket with the low nibbles of the loaded hex file), 'PH' (Programme the device in the socket with the high nibbles of the loaded hex file), or send an Intel Hex file of up to 512 actual bytes in size which equates to about 1.3-1.4K as an Intel Hex file.

My experiments so far have shown that I can send a hex file to an internal RAM array on my Arduino Nano at very high speeds without any loss if I adopt the approach of download the whole file into RAM without attempting to parse it, then check the whole downloaded file line by line for integrity. 230Kbaud, no problem, which makes the download of a 1.4K file seem almost instant.

The main problem I may face is possibly running out of internal RAM before the control sketch is fully written - your hint earlier about how to put text strings destined for print statements into code memory has definitely helped but the RAM use is creeping up again and I may run out before I have a fully working sketch.

[Slothie]

TBH I was using 9600 baud and I think the timing problems I was still having were because I was recycling over-complicated code from a different project.

[SiriusHardware]

If you were to download serial Intel Hex and parse / convert it to raw binary it as it arrived that would do away with the need for a 1.4K array to download it into, but you might have to do the transfer at a much slower rate to avoid dropping characters, even if you employed an interrupt-served FIFO serial RX buffer there would be an upload speed limit beyond which the project would be unable to empty the buffer fast enough. That then gets you into the realms of XON / XOFF software handshaking, which is all very complicated.

[Slothie]

Originally Posted by SiriusHardware

If you were to download serial Intel Hex and parse / convert it to raw binary it as it arrived that would do away with the need for a 1.4K array to download it into, but you might have to do the transfer at a much slower rate to avoid dropping characters, even if you employed an interrupt-served FIFO serial RX buffer there would be an upload speed limit beyond which the project would be unable to empty the buffer fast enough. That then gets you into the realms of XON / XOFF software handshaking, which is all very complicated.

Yes, that was the code I "recycled" before I realised the terminal software I was using ignored XON/XOFF during file transfers... I think that the Arduino should be able to keep up with 9600 baud if I'm not trying to be too clever for my own good. Also I've read USB Serial adapters upset the protocol because of their extensive buffering so XON/XOFF doesn't really work well unless you use a proper hardware serial port.

The other option was to find a better terminal program, but as I mentioned I was busy testing the other hardware signals and smoking MOSFETs, which is much more fun....

[SiriusHardware]

I think we've already established that an UNO has slightly less RAM than a Micro (I said Nano above, didn't I? I meant Micro). How much user-available RAM does a MEGA have? That's the only other Arduino I have at the moment.

[SiriusHardware]

...8K SRAM, apparently, so there is always the Arduino MEGA to resort to if I manage to code myself into a corner. I'll do my best to make it work on the much cheaper 'Micro', though.

[Slothie]

The ATMEGA328 has 2k ram, The ATMEGA1280/2560 used in the MEGA arduino has 8K.
I notice on the Microchip website that the 328 is "not recommended for new designs" having been replaced by the ATMEGA328PB in a convenient leadless package. I hope they continue to produce the old part for a while....

[ortek_service]

I recall there being 'chip-shortage' issues with the ATMega328P etc, leading to a slightly-different (5 extra I/O's and a third of the price?) ATmega328PB IC now being used on some Arduinos?

But not sure if production was actually being ended on the ATmega328P, or whether it was just that most Atmel (like popular ATMega1284) / Microchip (Inc. PIC's) uC's were showing as being on a 1yr lead-time, and no stocks at the usual distributors. Although that was around a year ago, so hopefully not quite as bad by now.

[Slothie]

Originally Posted by ortek_service

I recall there being 'chip-shortage' issues with the ATMega328P etc, leading to a slightly-different (5 extra I/O's and a third of the price?) ATmega328PB IC now being used on some Arduinos?

But not sure if production was actually being ended on the ATmega328P, or whether it was just that most Atmel (like popular ATMega1284) / Microchip (Inc. PIC's) uC's were showing as being on a 1yr lead-time, and no stocks at the usual distributors. Although that was around a year ago, so hopefully not quite as bad by now.

"Not recommended for new designs" is usually the first step in obsoleting a part but that process can take decades to actually complete, and DIP packages are still selling somewhat, so I'm not concerned for the immediate future.