UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 30th Nov 2022, 11:44 pm   #61
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

I've just dug out something I had almost forgotten about, an Arduino 'Micro' which surprisingly turns out to have 2.5KB of RAM, a little bit more than the CPU used in the UNO. I'm going to experiment with downloading the whole Intel Hex file straight into a very big array without processing it at all, then working through it to see if it is a valid Intel Hex file. If that works I may use it as the basis for the controller to drive Chris's PCB with.
SiriusHardware is online now  
Old 1st Dec 2022, 10:24 pm   #62
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Preliminary serial transfer results on the Arduino Micro are good, there is enough RAM on the Arduino Micro to create a CHAR array 'RxBuffer=[1440]' and then I read each serial byte as it comes in and as soon as I see a ':' (First character in a legitimate Intel Hex file) I just start reading each serial byte in as soon as it becomes available and stuff it into the next available slot in RxBuffer without making any attempt to parse it at that stage. I've tested this at serial speeds of up to 230400 so far (without software handshaking) and it never loses a byte.

End-Of-File is detected simply by measuring the interval since the last serial character was received - if more than 200mS has elapsed since the last received character then the host is assumed to have finished transmitting the file. If it were not for this fifth of a second delay the transfer would seem more or less instant.

The code then works through the Intel Hex file stored in RxBuffer, checksumming it and (potentially) saving the raw bytes although I'm not doing that yet.

As a RAM saving measure I intend to put the decoded raw bytes in the first 512 bytes of RxBuffer rather than in their own 512-byte array which would be pushing things a bit. This is possible because at least two bytes (ASCII characters) have to be read from the buffer to extract one raw byte of data, so it is perfectly OK to overwrite already decoded Intel Hex bytes with the raw data which will eventually fill the first 512 bytes of the RxBuffer array.

As things stand this might also work on an Uno with its 2K of RAM, I will try that when I get a chance.

I haven't (yet) done any work on the device programming side.
SiriusHardware is online now  
Old 2nd Dec 2022, 11:31 am   #63
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Tesla Programmer

I thought about this after you mentioned it and recalled that the Arduino Micro was based on the ATMEGA32U4 - the same one as in the Leonardo - that has a built in USB interface. The extra 512 bytes of RAM is used for the USB interface if the Serial Module or any other USB function is activated, so it effectively has 2k of usable RAM (Unless you don't use the USB/Serial). So this idea would work on the UNO as you say.

I thought you'd have to re-use the buffer and as far as I can see there really isn't any reason not to.
Slothie is offline  
Old 2nd Dec 2022, 11:50 am   #64
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Quote:
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.
You might wonder about the disparity between the file size quoted above and the buffer size of 1440 I mentioned the post before last - when I counted the number of characters in an Intel Hex file representing 512 bytes I counted exactly that - the number of characters. I forgot about the invisible CR/LF characters which may or may not both - depending on which OS saved the Intel Hex file - be present on the ends of the lines of hex. The actual length of the file is 1421 characters but I have allowed a small amount of wiggle room in case the Intel Hex file sent to the Arduino was acquired by cutting and pasting it from some online source, in which case there could be a few stray characters dangling off the end of it.
SiriusHardware is online now  
Old 2nd Dec 2022, 12:54 pm   #65
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Can I ask you which Arduino pins you're using to:-

-Drive the 9 PROM address pins
-Read the 4 data bits in
-Write the 4 data bits out
-Toggle the VCC supply volts to the chip
-Enable data output from the chip

Since all of these connections from mine to Chris's PCB will be by flying wires I am not committed to a particular connection scheme so it might make sense if I adopt roughly the same pin-> function scheme as you, especially if I switch to the UNO.

Where I'm driving address lines on a PROM or some such I tend to use the A0... to Ax... (analogue) pins as high as they go on the particular Arduino for the address lines before continuing on with pins 2,3,4.... (1 and 2 being tied up with the comms to the host).
SiriusHardware is online now  
Old 2nd Dec 2022, 1:58 pm   #66
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Tesla Programmer

The pin definitions are:

Code:
const int addr[]={A0,A1,A2,A3,A4,A5,2,3,4};
const int data[]={8,9,10,11};
unsigned volatile char image[512]; // Store of PROM image
:
:
#define NCE 5
#define NVPPE 6
#define NVCCE 7
#define READ 12
#define STATUS_LED 13
Pulling NVCCE to LOW turns on 5v to the PROMs Vcc, Pulling both NVCCE and NVPPE low applies 10.5v to the PROMs VCC. If NVCCE is high, then no power is applied to the PROM regardless of the setting of NVPPE.

Data pins 0,1 are reserved for serial port as normal.

READ is HIGH if you are reading the PROM contents, and addressed data appears on pins held in data[0..3] when NCE is LOW.
READ is LOW if you are writing, and the corresponding data pins are pulled low for any pins data[0..3] that are set to HIGH (which should only be one at a time as per programming spec). NCE is active low chip select as normal as specified in the programming procedure used to time the programming operation.
Slothie is offline  
Old 2nd Dec 2022, 2:57 pm   #67
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Quote:
const int addr[]={A0,A1,A2,A3,A4,A5,2,3,4};
Great minds, etc. ^^^^^^^^^^^^^^^^^^^

And yes of course, 0 and 1 are the pins tied up by comms.

As a matter of interest do you think that never-changing variables defined as 'const' are placed in program (code) memory rather than RAM? That would be my expectation (and the whole point of declaring them const) but something I read recently made me think maybe not. I've never pushed the Arduino RAM limit so hard before, so I'm only just having to think about it now.

Thanks for the info - I will try to follow your pin allocation scheme as far as possible but there may be circuit differences especially in the area of power control where I will have to deviate a bit to suit how things are done on Chris's PCB.
SiriusHardware is online now  
Old 2nd Dec 2022, 3:16 pm   #68
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Tesla Programmer

I think const arrays are copied from flash to RAM when the sketch starts (like string literals) and the compiler prevents them from being changed. Const variables are usually optimised away.

If you want to save memory you can use the PROGMEM qualifier that puts the const array in program flash, but requires use of "pgm_read_xxx" access functions to get their values (see this article or similar).

If you have string literals in Serial.print() function calls, surround them in the F() psuedo-function to put them program storage e.d.
Code:
Serial.println(F("This is my program"));
The Serial.print[ln] function does the rest for you.
Slothie is offline  
Old 1st Jan 2023, 6:05 pm   #69
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Pleased to say that the PROM programmer PCB which Chris put in the post to me early in December finally managed to flop onto the doormat just before New Year's Eve, so I should now be able to make some progress with this, as all of the more 'exotic' components which I also ordered at around the same time eventually arrived here in fits and starts.

The SOIC switch-mode regulator IC proved quite hard to find when I went to order it and I ended up ordering a small quantity from Israel - if anyone else intends to have a go at building one of Chris's PCBs I have a few of the reg ICs to spare.
SiriusHardware is online now  
Old 4th Jan 2023, 11:08 pm   #70
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

I have the Tesla programmer PCB about 60% populated now - found a reasonably priced 8255A which I hope is similar enough to the Intel version. Of course I couldn't find any of the several that I know I have. I've decided to order the specific low-ESR capacitors and inductor from the BOM to be sure that the 10V SMPSU will work as intended.

Having started with the Arduino Micro (which I will probably keep for this project as it is 5V-friendly) I got sidetracked into trying the code on a Pi Pico because the Arduino IDE does now have proper 'board' support for the Pico.

In both cases I'm having a peculiar problem which I don't think normally happens on the UNO -

If I initialise the serial port and send an initial prompt, like this:

Code:
 
Serial.begin(115200,SERIAL_8N1);
Serial.println("Ready - waiting for Intel Hex file at 115200,8,N,1");
I don't see the "Ready" prompt, yet the serial port is working beyond that point because the next thing I do is continually read from the serial port until a whole Intel Hex file has been received and then parsed / checksummed, and that works.

Whether the code is successfully received or not, the serial port is then closed at the end of the main loop.

Back at the beginning of the main loop the first thing encountered is the Serial.begin code above, and this time it DOES display the 'ready' prompt. It's as though I have to read from the serial port first to wake it up before I can send anything to it.

I have the same problem when using the Arduino Micro and the Pi Pico - no initial prompt on first connection. Does anyone know the work-around for this?

Last edited by SiriusHardware; 4th Jan 2023 at 11:20 pm.
SiriusHardware is online now  
Old 4th Jan 2023, 11:49 pm   #71
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

This seems to have done the trick - now the 'Ready' prompt is available as soon as the terminal can see the device.

Code:
  Serial.begin(115200,SERIAL_8N1);
  while (!Serial)
   {
   // Just loop until Serial becomes available
   }
  Serial.println("Ready - waiting for Intel Hex file at 115200,8,N,1");
SiriusHardware is online now  
Old 9th Jan 2023, 12:21 pm   #72
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

I now have the PCB assembled as far as it needs to be but my SMPSU for the 5V / 10.5V SMPSU regulator is not running (at either voltage). Instead, the voltage at D1 Cathode is 4.867 which is just the +5.00V supply being dropped across D1.

The first thing I have to suspect is that the reg ICs I've been supplied with for the IC5 position are not actually what they are supposed to be - on looking up the code printed on them they have 'S518' marked on them, which on a brief search comes up as a transient suppressor. Chris O, if you read this, I would be interested to know what the marking is on your IC5?

(Edit - Actually the marking on mine is 'S51B' which is indeed what it should be for the LM2731Y according to the Ti datasheet. Of course, mine could still be fakes.)

Last edited by SiriusHardware; 9th Jan 2023 at 12:28 pm.
SiriusHardware is online now  
Old 9th Jan 2023, 1:21 pm   #73
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Well, just tried a second 2731Y IC in IC5 position and I now have 4.99V / 10.3V according to the logic state of the output from 8255 pin 16. I can't imagine what I did to the first chip, all static handling procedures observed etc. The only change I have made is to replace the first chip with another one.

Onwards and upwards...
SiriusHardware is online now  
Old 17th Feb 2023, 6:20 pm   #74
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Just to give myself another shove in the back with this project, I have just ordered a number of the Tesla MH74S571s from the usual source in Poland.

Now I have to devise a way to program them.

It's never really been a high priority for me before because I didn't have any, but my supplies of 'western' 512 x 4-bit PROMs are getting a bit low, prices for 27S13 and 82S131 are way-high and Nat Semi DM74S571s are practically unobtainium now.
SiriusHardware is online now  
Old 18th Feb 2023, 3:42 am   #75
circuitryboy
Pentode
 
circuitryboy's Avatar
 
Join Date: Jun 2012
Location: Bristol, UK.
Posts: 115
Default Re: Tesla Programmer

If you read the 'TESLA Editor' listing I posted in October 2019 (did anybody ever bother?) you will see voltages-switching timings that work, in the annotation.
__________________
x^4 + x^2 + y^2 = 0
circuitryboy is offline  
Old 18th Feb 2023, 8:45 am   #76
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

Whenever I talk about the actual process of programming the Tesla devices and the knowledge we have about how to do that, I always refer to your contribution in that respect, for example in #3 and #10 of this thread. We would still appreciate it if you were able to post your Tesla-converted version of the MK14 PROM programmer software as well.

The 'difficulty' nowadays, thanks to the efforts of yourself and others, is not lack of information, but just general laziness / inertia on my part, along with a few non-technical things going on in my life which are sapping a lot more more of my time than usual.

By buying and building a kit of Chris Oddy's proven hardware along with a handful of devices I can't currently program, I'm trying to give myself as much incentive as possible to get on with it.

Last edited by SiriusHardware; 18th Feb 2023 at 9:01 am.
SiriusHardware is online now  
Old 18th Feb 2023, 1:23 pm   #77
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,392
Default Re: Tesla Programmer

I do now recall previously-seeing that circuitryboy listing, having just had a search for what seems to be that thread from back then: https://www.vintage-radio.net/forum/...=160247&page=2 And looking attachments again
(Even though I don't think I was on here that much back then, until 2020, so I must have seen a link to it in another later thread).

I see there was also some discussions there about a one-byte contents-difference between the NS Introkit PROM contents and published listings, that Chris Oddy also later looked into, after I made an adapter to read-out mine.
But as he didn't join until after then, he probably wasn't aware of this (And maybe the same for the Tesla programming algorithm, and any existing code to implement this), although he had been looking at the translated datasheets that had been previously posted on here.
He may have also wanted to keep algorithm close to that already being used for the NS DM74S ones in his Acorn PROM Programmer s/w, he was modifying.
And it seems that Elnec / Dataman Pro ones had maybe decided to do things their own way, as just had one long-pulse single attempt at a location, rather than trying to do any intelligent loops of short-pulses, before verifying it and exiting on failure.
ortek_service is offline  
Old 18th Feb 2023, 7:45 pm   #78
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

You would have thought that of all people Elnec (In Slovakia I believe) would have been able to form a relationship with Tesla (Chip manufacturer, not the auto manufacturer with the same name) and get the official algorithm from them.

Either way, the fact that circuitryboy's timing and Elnec's timing (which Chris followed) are slightly different and yet both work shows that there is some leeway allowed for getting it right.
SiriusHardware is online now  
Old 18th Feb 2023, 7:59 pm   #79
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,392
Default Re: Tesla Programmer

It's not clear whether Tesla are still in existence - And doubtful they are still making these, and most-likely the ones being sold are finite NOS ones. So maybe it was too late for Elnec to liaise with Tesla, and support for these was added in response to Elnec customer requests (Although can't be many major equipment manufacturers who would be still using these devices / you wonder what programming equipment Tesla used / recommended originally - maybe they were only used by specialised government / military in the old Eastern-Block days)

I seem to recall Chris did try some more-intelligent algorithms to start-with - Looking at TI ones, that Tesla ones had seemed most-similar to, but whose algorithm wasn't too clear.

But ended-up just going for a long-enough single fixed-length? (not sure if he used exactly the same length that Elnec were using) pulse as wasn't too concerned about getting the fastest method, not doing these that often.


I would think the programming method for fusible-link PROM's is actually even less critical than (UV-E)PROM's (where many programmers just used a rather generic programming algorithm, and only more-advanced ones implementing later intelligent pulse methods that may not have been usable on older devices)
- As no concerns about long-term retention, once fuse has (One-time) blown. But do have to ensure a sufficient cool-down delay is allowed for, between programming each bit, to avoid the IC over-heating during programming.

Last edited by ortek_service; 18th Feb 2023 at 8:07 pm.
ortek_service is offline  
Old 18th Feb 2023, 8:20 pm   #80
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Tesla Programmer

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.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 10:04 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.