Tesla Programmer

[SiriusHardware]

My current focus is getting something to work when used with care so I can produce a PROM once in a blue moon.

That's good for anything you intend to keep in-house and not distribute to the wider world, but (as with software) if you mean to distribute it to a wider audience then it probably has to be more idiot-proof.

Even arranging things so that the programmer power only comes on when the Arduino turns on has a potential flaw - what if you forget to turn on the auxiliary supply before powering on the Arduino? Then, you have strong output drive signals on the control lines of the unpowered programmer interface ICs and those drive signals will probably power the programmer interface ICs through the clamp diodes on the IC inputs, causing unwanted / undefined activity.

I actually quite like your idea of a standalone board into which you place an AVR chip which has been programmed in the usual way in an UNO.

Pros:
-No longer has the size / space limitation imposed by trying to keep it inside the outline of an Arduino shield. You can make it physically bigger.

-Power applied to the programmer PCB applies power to everything simultaneously, power removed from the board removes power from everything.

Cons: Need to own an Arduino UNO just to programme the chip, although the chip can be put straight back in the Arduino and re-used again one you've done your PROM programming job. Could maybe put a programming connector on the programmer PCB to allow the micro to be programmed via AVRDUDE or some such, to avoid the need to own an Arduino.

[Slothie]

Originally Posted by SiriusHardware

I actually quite like your idea of a standalone board into which you place an AVR chip which has been programmed in the usual way in an UNO.

Pros:
-No longer has the size / space limitation imposed by trying to keep it inside the outline of an Arduino shield. You can make it physically bigger.

-Power applied to the programmer PCB applies power to everything simultaneously, power removed from the board removes power from everything.

Cons: Need to own an Arduino UNO just to programme the chip, although the chip can be put straight back in the Arduino and re-used again one you've done your PROM programming job. Could maybe put a programming connector on the programmer PCB to allow the micro to be programmed via AVRDUDE or some such, to avoid the need to own an Arduino.

To be honest, if I get it working it would be relatively trivial (a days work or so) to add the ATMEGA to the schematic and lay out a new board. There would be no software changes required on the ATMEGA or the PC software unless I moved pins around. You could use a cheap USB-serial module soldered to the board to actually program the device using the boot loader, and to communicate with the programmer, and the USB power would be isolated. Although DIP ATMEGA328's pre-programmed with the boot loader are stupid prices at the moment they will come down in price to the cost of an UNO clone or less at some time so that would be an option. To add in the usual SPI programming port to allow an AVRISP, "Arduino as ISP" or USBISP to program a blank chip would involve moving around some of the I/O pins but that in itself wouldn't be a huge issue since the 10 address + CE pins are completely isolated if there is no PROM in the socket so there's room to get isolated pins on PORTB for programming.

This is work I would probably do, as I am more interested in there being a usable open source design out there to program these chips than the (few) highly expensive obsolete commercial designs out there, and realistically I am not in a position to make and sell them myself. Just need to get on with it!

[SiriusHardware]

Making a simple to make, simple to use MH74S571 programmer available to all may have unintended consequences. You want to be able to program them because they are cheap, but of course they are cheap because hardly anyone can programme them.

The moment you make an 'MH74S571 programmer for the people' available, that is when the prices of the Tesla devices will finally start to catch up with the extortionate prices of the other more widely programmable devices.

I'm not saying don't do it: But I am saying make sure you buy all the MH74S571s you are ever likely to need for yourself... first.

[Slothie]

Originally Posted by SiriusHardware

I'm not saying don't do it: But I am saying make sure you buy all the MH74S571s you are ever likely to need for yourself... first.

Well I have 4 here and 20 in storage... is that enough?

I don't know how practical it would be to open up the design to other PROM chips, I know that programming specs vary wildly for different devices and I'm stretching the number of IO lines I'm using, so a more versatile device would require a bigger ATMEGA....

[ortek_service]

Originally Posted by Slothie

>>
This is work I would probably do, as I am more interested in there being a usable open source design out there to program these chips than the (few) highly expensive obsolete commercial designs out there, and realistically I am not in a position to make and sell them myself. Just need to get on with it!

I don't think there's many old obsolete commercial programmers (like Data-I/O ones) that actually support the Tesla PROM's. And even many / most (expensive) commercial programmers
- Including the original (Advantech-designed) Dataman 48(LV/(U)XP), which they still sell despite updates not being that often / they have moved to a subscription licence model to have software that actually runs on > WinXP -Although you can still get for free the years-old last <=WinXP etc version)
do not seem to support these either.

It's only the Elnec-designed programmers (Sold as Re-badged as Dataman 48Pro(+/2) in many countries) - and a bit cheaper than original Dataman-48 design still being sold - that seems to support the Tesla PROM's.
Whilst their latest free-download software has dropped support for the oldest 48Pro (and more recently the 48Pro+ as well) - so free 'lifetime' updates are only for as long as they deem the lifetime of the programmer to be, before they want to sell you their later models - they do still provide the last versions that did support each of those models (And still do support most of the vintage-IC's we're likely to require / I doubt they'll add obsolete types to future updates on later programmers) as free downloads.

And Elnec/Dataman don't seem to ever remove support for older devices from their latest version (unlike Data I/O & Altera etc, so requiring keeping past versions of their software).
However, they have started to introduce 'credit boxes' for some newer devices, where you have to pay a fee to be able to program a fixed number of these - Not sure if there's also time limits (that some CAD etc software providers have annoyingly moved-to, with yearly subscription costs model rather than ever permanently owning the particular version you bought).

As virtually all new programmed devices are in-system programmable, often with manufacturer provided free software and usually fairly low-cost / standard USB etc. ISP adaptors, then the market for new IC programmers will be shrinking and could eventually almost-cease (especially free-updates) if not economic. Some have already introduced coded PIC-uC etc. protected adaptors, to ensure they get income from one required for new device and stop you making your own.
So having something that can be kept updated by an open-source community, like with KiCAD, would be rather advantageous.
- However, many IC-manufacturers have been rather reluctant to release the details to program these yourself (only providing these to major IC-programmer manufacturers, no doubt with NDA's), compared to decades ago I've also seen Hitachi / Renesas remove schematics of Parallel-EPROM adaptors for their uC's, from updated datasheets.

[ortek_service]

Originally Posted by Slothie

Well I have 4 here and 20 in storage... is that enough?

I don't know how practical it would be to open up the design to other PROM chips, I know that programming specs vary wildly for different devices and I'm stretching the number of IO lines I'm using, so a more versatile device would require a bigger ATMEGA....

The problem is that it gets rather over-complicated with fully electronic switching, to support other makes due to them using rather different programming methods - As Chris found out, when he originally wanted to just update the original Acorn NS 74S471 type design (Including just adding an adaptor board between the device and original socket), to also support the Tesla version
You start to end up with lots of pin-driver circuits, that universal programmers have on each pin.

It seems that ones other than Tesla-types are now getting very difficult to obtain, with no significant stocks still left so the odd few someone has can now fetch quite a lot. And so probably not worth putting much effort into creating a new programmer for those.

The same thing will eventually happen to Tesla-ones - it might just happen even-quicker, once more people are able to use these.
And getting information on when these were last-made (No standard date-codes on them) / how many are still left at TV-Sat in Poland etc, would no doubt be quite tricky (At least Rockby in Australia told you how many they had left with 8154's etc)

Ultimately, emulation of this obsolete fuse-blowing technology will be required. And if parallel FLASH etc. won't be small enough, then might have to look at a small FPGA (or even a fast uC), in a small SM package that will fit on an original IC-size adaptor PCB (But BGA / CSP packages would then prevent it being able to be assembled by most people)

[SiriusHardware]

Well I have 4 here and 20 in storage... is that enough?

It depends on how many you have to wade through to arrive at a working setup

I can only admire Chris who only had to sacrifice one device to get to the point where he was confident of being able to programme further devices without any problems, although I understand he took the precaution of first only programming one bit at a time before progressing to whole nibbles, and so on.

[SiriusHardware]

Speaking of which, I think Chris has a few 'used' MH74S571s for sale - useless for any normal purpose obviously, but a good 'practice target' for any Tesla programmer...

[Slothie]

Originally Posted by SiriusHardware

It depends on how many you have to wade through to arrive at a working setup

I can only admire Chris who only had to sacrifice one device to get to the point where he was confident of being able to programme further devices without any problems, although I understand he took the precaution of first only programming one bit at a time before progressing to whole nibbles, and so on.

I seem to recall telling you that was what I was planning too a few of years ago when I first started thinking about it... In a 512x4 PROM you have 2048 test attempts. Even a used PROM has approx 50% zeroes that can be used for testing!

[SiriusHardware]

I seem to recall telling you that was what I was planning

And that was several years ago now. (I know, I know, real life really did get in the way in your case).

I suppose the fundamental first block of any code to support such a programmer will be a function to read bit (x) of address (y). The next function will be one which programmes bit (x) of address (y). You can do a lot of testing with just those two blocks by manually editing the values of (x) and (y) before then going on to add further code to programme all 512 nibbles of a chip, at which point the project needs some way of acquiring the code to be programmed either via a USB serial link or from an SD card.

What sort of UI do you envisage, command line via terminal, or an LCD display and a few buttons?

In its most primitive form there could be no actual UI and a specific .ino sketch to programme each likely target with the binary file INCLUDEd in the source. So there'd be a Prog_MK14_U2.ino and a Prog_MK14_U3.ino, or maybe in the MK14 specific case the binaries for both ICs INCLUDEd in the source and a simple pair of pushbuttons: Push one, it programmes the U2 code, push the other, it programmes the U3 code. Maybe expand this to more INCLUDEd files and more pushbuttons to choose those, or a rotary 'code select' switch and a single 'programme' button. Three quick LED flashes for success, continuous slow LED flashes for fail.

Anyone who wanted to programme unique code could just INCLUDE their own code in the sketch instead of the codes supplied with the project.

[SiriusHardware]

Looking through the order confirmations in my inbox it looks as though the switching regulator for Chris's PCB is being hand couriered from Israel because it isn't projected to arrive until mid January.

[Slothie]

I've currently got some "debug mode" code in there that allows me to switch the various signals on and off, and read or program bits - so far I've just been monitoring the signals with my bitscope and logic analyser to check them, I haven't risked a chip on it yet given the number of faults I've been uncovering.

I was originally going to just connect to a terminal program as all the I/O is currently occupied and there's be nothing for LCD displays or SD cards. One of the problems is that when trying to upload an intel hex file to memory characters are being lost, although one answer would be to slow the baud rate to below 9600, its not like we're going to need a high speed.

The other idea is to write a python or C application to connect to the low level API across the serial link and drive the programmer without having to upload anything.

A custom sketch that just calls a library to do the programming functions would also be another option as you suggest. This would require the user to have a higher level of knowledge, although I doubt a rank amateur would be fiddling with bipolar PROMS.

Of course, on a redesigned device with a different ATMEGA or an I/O expander there would be plenty of I/O for LCD displays, SD cards and buttons on a standalone unit but we are hitting feature creep on a device for programming an obsolete device...

[SiriusHardware]

The other idea is to write a python or C application to connect to the low level API across the serial link and drive the programmer without having to upload anything.

That brings with it the problem of having to support at a minimum Windows, MacOS and ideally Linux versions of the 'support software'. I can appreciate that Python in particular is very portable and will even run on a Raspberry Pi, so quite a good choice if you were going to go that way. I think you would have to have some way for the program / script to know which OS it was being run under so that for example it could use the correct terminology for serial ports (TTYsx for Linux, COMx: for Windows etc).

When I made my version of the Arduino keypad injection loader which does take in Intel Hex files sent from a terminal I wanted a highish baud rate so that two or three K of Intel Hex would seem to transfer almost instantly but to achieve that I had to add a cheap SPI SRAM as a serial RAM buffer and I also had to use block write mode when writing received bytes to the SRAM because writing individual bytes (write command, address high, address low, data) each time was slowing things down too much.

I could have done it without the SRAM if I had been prepared to drop the baud rate right down and for this project where the maximum file size is 512 nibbles (although rather more if an ASCII hex format is used to represent those nibbles) it may be acceptable for it to send the code over more slowly.

An LCD display need not take up too many resources, you could use the same 9 bits being used to drive the PROM address lines to drive the 8 * display data lines plus the display R/S line, with only one uP I/O pin dedicated to the display EN pin, R/W being assumed to be tied low so that the display operates in Write-Only mode.

[ChrisOddy]

I've just programmed a few more Tesla PROM's whilst monitoring the data lines.

For most of the time the lines do not exceed 5V, for a short time around 15uS, there is a pulse up to 5.5V but it never goes higher than that.

I've now programmed quite a few chips on this programmer and haven't seen any ill effects (to the 8255).

Chris

[SiriusHardware]

Thanks for letting us know about that, Chris.

[SiriusHardware]

For the question of whether it would be feasible to serially receive 512 items of data as Intel Hex at high speed on an Arduino Uno, the answer would seem to be maybe.

I've just put a 512 byte binary file through a binary to Intel Hex conversion and the resulting Intel Hex file came out at 1,387 characters. According to various sources the UNO has 2K of RAM but of course that is shared out amongst everything on the Uno that wants some RAM such as run time variables, arrays, etc.

It does seem that it might be possible to download the whole Intel Hex file into RAM at high speed and then shift it out at whatever slower speed the programming process imposes.

If it was possible to convert the Intel Hex back to raw data during the serial load process rather than afterwards, then the buffered raw data would take up considerably less internal RAM, especially if it was 'packed' as two PROM data nibbles in every byte of Arduino RAM although I think that last step would be an unnecessary complication. Not packing the data would allow for the possibility of byte-wide data to be loaded, at which point you could let the user choose to program the PROM with bits 0-3 of the data or bits 4-7 of the data.

[Mark1960]

Originally Posted by ChrisOddy

I've just programmed a few more Tesla PROM's whilst monitoring the data lines.

For most of the time the lines do not exceed 5V, for a short time around 15uS, there is a pulse up to 5.5V but it never goes higher than that.

I've now programmed quite a few chips on this programmer and haven't seen any ill effects (to the 8255).

Chris

Hi Chris,
Is this because the esd diodes in the 8255 are clamping the voltage down to 5v?

The 8255 spec doesn’t specify a current limit for voltages avove the supply voltage. Just that the max input voltage is Vcc. So I’m not certain the 8255 has internal diodes.

Mark

[ortek_service]

Yes, I had meant to mention to Chris, when I saw him earlier, that it might be best to have the 8255 removed in case it clamps these. But that makes testing for this more difficult, when it control the programmer and might be easier to just make an inline adaper to isolate the 4 data lines inputs to the 8255 (or carefully bend the relevant 8255 Input pins up, and re-insert IC into its socket).

However, I've just done a simple diode-check on an 8255, and there doesn't seem to be any forward-biased diodes / junction from port I/O lines to Vcc.
Although there is a reverse-biased diode / junction from Vcc to each of the port I/O's, reading around 0.6V - Which may be a consequence of TTL inputs, and these could have a reverse-breakdown (typically 7V for Vbe junction of silicon transistors?)
And there are also a slight reverse-biased diodes / junctions from the port lines pins to Gnd, measuring around 1.0V on DMM diode-test. - I don't think it's just internal resistance to ground, as you don't get any reading / > 2M on resistance range, reversing the probes.

So it doesn't seem that the 8255 would clamp these at 5V.
Although, if you tried an 82C55, you might well get different results, as I'd expect those to have clamp diodes on I/O pins for ESD protection etc.

[ortek_service]

Originally Posted by SiriusHardware

>>
I can only admire Chris who only had to sacrifice one device to get to the point where he was confident of being able to programme further devices without any problems, although I understand he took the precaution of first only programming one bit at a time before progressing to whole nibbles, and so on.

Originally Posted by SiriusHardware

Speaking of which, I think Chris has a few 'used' MH74S571s for sale - useless for any normal purpose obviously, but a good 'practice target' for any Tesla programmer...

I spoke to Chris earlier today about this. And he said he didn't actually waste any Tesla devices at all- As he only programmed locations that needed to be fuse-blown, when programmed (With intended code for Acorn system ?)
- Although I believe to start with, he could get it to blow fuses, as the initial transistors weren't saturating at low-enough voltage to gnd (may have been using ULN2003 etc darlington-drivers on first prototype)

He did, however, get a few National Semi casualties, whilst previously extending the original Acorn system programmer software to support the DM74S287 (as well as the original DM74S571) - But that was a software bug (I think it's all 6502 assembly-language) rather than a hardware issue.
So the only part-used (with no working code but still some unfused bits) for programmer testing he has for sale are some National Semi ones. But it may no longer be worth developing a programmer for these, as all previous main stockists no longer have any left, unless you already happen to have a number of blank ones.

[Slothie]

Originally Posted by SiriusHardware

For the question of whether it would be feasible to serially receive 512 items of data as Intel Hex at high speed on an Arduino Uno, the answer would seem to be maybe.

I've just put a 512 byte binary file through a binary to Intel Hex conversion and the resulting Intel Hex file came out at 1,387 characters. According to various sources the UNO has 2K of RAM but of course that is shared out amongst everything on the Uno that wants some RAM such as run time variables, arrays, etc.

It does seem that it might be possible to download the whole Intel Hex file into RAM at high speed and then shift it out at whatever slower speed the programming process imposes.

If it was possible to convert the Intel Hex back to raw data during the serial load process rather than afterwards, then the buffered raw data would take up considerably less internal RAM, especially if it was 'packed' as two PROM data nibbles in every byte of Arduino RAM although I think that last step would be an unnecessary complication. Not packing the data would allow for the possibility of byte-wide data to be loaded, at which point you could let the user choose to program the PROM with bits 0-3 of the data or bits 4-7 of the data.

Well I was reusing code I had laying around from other projects, so the code wasn't optimal. I was decoding the hex bytes to binary and storing it in the memory in binary because that is what I would prefer - there is no reason that hex to binary shouldn't be able to keep up with the serial port even at high speeds. I could make a more efficient hex-binary decoder than the Arduino library function if required, however the code I was using was trying to buffer the input stream through an interrupt driven routine into a largeish circular buffer so I could use software flow control (which the file upload on my terminal program ignored!) and I think I was over-thinking it and making it more complex than necessary - the arduino's built in 16 byte buffer should be more than necessary. I'm going to cut out all that complexity and just make the simplest loop possible and if necessary slow down the baud rate.

The firmware has a flag for high or low nibble which tells it which half of the stored bytes to use for read/write operations between memory and PROM.

Everything is very much in an experimental stage!