Atmel AT27C020

[SiriusHardware]

I honestly just don't trust this generation of EPROM programmers for the earliest devices which they supposedly do, but Colin has his STAG for those.

[ortek_service]

Well the later EPROM's are probably lower-power (especially if CMOS), so less-likely to have the supply etc dropping under load.

More expensive programmers, like the Dataman (& Stag in its day), probably have beefier transistors in their pin-drivers - especially as they were rather-larger size than the TL866 etc.
But it might be possibly to mod the TL866 a bit, to support the older devices better - as with external board for 2532's and higher 25V Vpp voltage 27xx devices.

Although it could still be a software issue, and some incorrect / on-edge timing with slower devices of the chip selects etc. .

[ScottishColin]

I'm going for the Arduino approach. Failing that I may lean on Phil......

Colin.

Originally Posted by SiriusHardware

Are you going to try the Arduino approach or the Read Out In Chunks approach suggested by Phil? Or something else?

[ScottishColin]

Thanks Phil - that's very kind. I'll try to blunder through it with my Arduino, but if/when I fail, I'll let you know.

Colin.

Originally Posted by Phil__G

If you want to send it down to me I can read it immediately & send it back by return Colin

[SiriusHardware]

I've just been looking, in parallel, at tweaking the most recent reader sketch I have here to read out devices larger than 512K. For the readout to human-readable address+data+overall checksum it isn't too difficult but the most recently added facility to (optionally) output the code as EPROM programmer friendly 'Intel Hex' is broken straight away because original Intel Hex doesn't easily cope with addresses larger than 16 bits, or four hex digits - at least not as far as I know.

There is another well established alphanumeric text hex format which is commonly supported by EPROM programmers called Motorola 'S', and that can handle files with up to 32-bit addresses - can your STAG programmer load Motorola 'S' files? If not, no matter, because the code could be loaded into something like the HxD hex editor program and examined and modified in there instead.

[ScottishColin]

The PP39 information page below says the Motorola S-record is available on the PP39. Current problem is that I can only go to 28 pin devices; I'm looking for a 39M101 which allows for larger devices with more pins, but they're a but tricky to come by.

http://matthieu.benoit.free.fr/Stag_PP39_programmer.htm

Worst comes to the worst, I'll see who can do it as a one-off.

Colin.

Originally Posted by SiriusHardware

I've just been looking, in parallel, at tweaking the most recent reader sketch I have here to read out devices larger than 512K. For the readout to human-readable address+data+overall checksum it isn't too difficult but the most recently added facility to (optionally) output the code as EPROM programmer friendly 'Intel Hex' is broken straight away because original Intel Hex doesn't easily cope with addresses larger than 16 bits, or four hex digits - at least not as far as I know.

There is another well established alphanumeric text hex format which is commonly supported by EPROM programmers called Motorola 'S', and that can handle files with up to 32-bit addresses - can your STAG programmer load Motorola 'S' files? If not, no matter, because the code could be loaded into something like the HxD hex editor program and examined and modified in there instead.

[SiriusHardware]

San Bergmans (Author of SBASM) has quite a good information page about Intel Hex in which it states that there is a special record type which can define the upper-upper portion of a greater than 16-bit address so I might try to shoehorn that into the existing Intel-Out routine.

https://www.sbprojects.net/knowledge...s/intelhex.php

Don't let this impede or interfere with whatever you are intending to try, because for one thing I am notoriously bad at getting things done so while the intent is there, I may never actually finish what I have started.

I believe there is a Zmodem (or similar) binary transfer library for Arduino which would allow the transfer of raw binary values read straight out of the chip as a stream of binary bytes. Combining this with Hyperterminal or Teraterm on a host machine you could zmodem the code across to the host and save the code directly as a .bin file. Doing stuff like that is a little bit above my level but you with your IT background might find yourself on more familiar ground.

[SiriusHardware]

I'm making some progress on my side, I have successfully generated a test Intel Hex file which is accepted as a 2MB file by my Dataman programmer's software. I filled the file with data values starting at zero and incrementing by +1 every 0400H bytes so the last 1024 byte block in the file contains FFs, so when I swish up and down through the editor it's easy to see whether all of the 1024-byte blocks have loaded in the right places / the right order. A potential problem was that the loader might ignore the type 04 records which tell it to add a high address offset to the 16-bit addresses in the type 00 records, but that does seem to be working as it should.

One roadblock I did run into was one which you actually came across before Colin, the latest version of the Arduino IDE that I have (V2.1.1) has broken the ability to 'select all' and copy and paste from the terminal output window so I had to revert back to an older version I still had installed, V1.8.12, in order to be able to select and copy the output of the terminal window, then paste the Intel Hex file into Notepad and save it with a .hex extension from there.

I'll try updating V2.1.1 to whatever the current version is to see if the copy / paste problem is still present in that version.

[SiriusHardware]

Yes, copy / paste from the serial monitor window is still broken in Arduino IDE V2.3.2 - you can drag-select the contents of the serial output window but only the visible part of what you have selected is copied to the clipboard when you press CTRL-C. I'm going to go back to V1.x.xx which frankly was a lot nicer to use, and also worked as expected.

[SiriusHardware]

If you are stuck with Arduino V2.x.xx there is a workaround, which is to leave the built-in serial monitor in the Arduino IDE closed and instead open an independent serial terminal like Teraterm and use that to capture the serial output from the Arduino project (a connected Arduino appears as a selectable COM: port in the terminal program's port select / setup menu).

The only drawback with this is that the IDE's programmer won't co-exist with an already active connection to the independent terminal so whenever you want to send new program code to the Arduino, you have to 'disconnect' from the Arduino's serial port in the terminal program.

The upside is that virtually any standalone terminal program has better facilities for capturing received input and saving it directly out to a file.

[Station X]

One off topic post moved to a new thread here:-

https://www.vintage-radio.net/forum/...d.php?t=209175

[SiriusHardware]

One step forward, one step back. I found two programmed 2MB EPROMs at work today, both labelled so I could get the corresponding code, load it into an editor and checksum it so I knew what the checksums of the EPROMs should be. I wrote the checksums on the labels.

One is an Atmel 27C020 like Colin's but with a window so it can be erased - the other is an SGS-Thompson (ST) M27C2001.

My current version of the reader code reads the ST device out perfectly every time, always the same (correct) checksum, but I get a different checksum for the 27C020 every time I read it - nothing different, nothing changed except the actual EPROM.

For both the 27C020 and the 27C2001 I can read either of them in my Dataman programmer and I get the correct checksum every single time from both of them. I can read either of them as either type without any problems, as long as I have the ID check disabled.

The datasheet for the 27C020 states very firmly that the device needs a decoupling capacitor as close to its pins as possible - I don't currently have that so I will make up a plug-in capacitor tomorrow to suit the pin-row connectors on my 'EPROM holder' board which is connected to the Mega by 6-inch or so flying dupont leads.

The fact that the sketch consistently reads the 27C2001 correctly makes me think that at least the software side of things is working OK - just need to sort out why the 27C020 won't play nicely like the 27C2001 does.

One thing which is not really made clear in the datasheet for the 27C020 is the role played by the VPP and P pins in read mode - conventionally I would expect that these would need to be held at +5V in read mode and that works fine for the 27C2001.

[ortek_service]

Originally Posted by SiriusHardware

>>
>>
One thing which is not really made clear in the datasheet for the 27C020 is the role played by the VPP and P pins in read mode - conventionally I would expect that these would need to be held at +5V in read mode and that works fine for the 27C2001.

Well this (later as for OTP-Only versions?) Atmel 27C020 datasheet http://ww1.microchip.com/downloads/e...oc/doc0570.pdf
does state that Vpp and PGM are 'X' for don't care and can be Low or High in read mode (Although, normally they are set to be high, for some of the more-fussy EPROM's that did require this).

Despite the datasheet's decoupling advice, I wouldn't really expect that to make too much difference if not operating these at highest speeds. Although maybe having long leads could be more of an issue, with reflections / ringing / crosstalk etc, So might be worth keeping these as short as possible (maybe paralleling extra ones for the Ground and supply wires / checking with a 'scope / extending settling-time delays in the Arduino firmware.

There doesn't really seem much else in the datasheet that could be causing problems.

[SiriusHardware]

I agree, it's just that it's strange that reads from the 27C2001 are absolutely solid but reads from the 27C020 are very flaky, all with the same flying leads / potential crosstalk between leads and no supply decoupling at the EPROM end.

It seems to suggest that the problem is somehow down to some difference between the devices rather than the operating environment, which is identical in both cases.

I'll have another go at it tonight.

[SiriusHardware]

One other thing I'm not doing at the moment is using the /CE /OE pins, I just have those tied to ground so the data outputs are permanently enabled. Again, it works for the 27C2001 but maybe the 27C020 doesn't like that.

[ortek_service]

Originally Posted by SiriusHardware

One other thing I'm not doing at the moment is using the /CE /OE pins, I just have those tied to ground so the data outputs are permanently enabled. Again, it works for the 27C2001 but maybe the 27C020 doesn't like that.

Well ideally they should be sequenced as per the timing diagram, but most EPROM's are happy with them being fully-enabled for read at power-up (as used in standalone decoding applications like CB frequency conversions etc.)

[SiriusHardware]

Indeed, I'm all too familiar with their use in that way for that application, although the rate at which the address input changes in those circumstances could hardly be slower. But yes, generally speaking when used as code converters with their enable pins permanently activated, they (or most EPROMs at any rate) work fine.

I've just fitted a 0.1uF with the shortest leads possible across the EPROM power pins and it's still just as it was, reading duff data from the 27C020 - not all of it, just occasional bytes, but obviously even one byte wrong is a calamity.

I already have a reasonably generous 500nS delay between the address being presented to the EPROM and the data being read from it. I may have to get the scope out.

[Phil__G]

Maybe try one slow read, extending the 500nS delay to say 1ms before each /RD pulse and 1ms after. This would at least confirm if its a race problem if you get a good checksum. My first test with anything weird like this is to slow it down

[SiriusHardware]

I've been reluctant to do that because:

-The 27C2001 reads OK at the current speed

-It already takes MINUTES to read out the whole EPROM, the overall speed being largely determined by the fact that it is outputting the read-out data over a serial link (two ASCII characters and a space character per byte)

But you are absolutely right, I should do that.

[RogerEvans]

If you know the algorithm for the checksum you could get the Arduino to calculate it internally and just output the checksum rather than individual bytes.

Roger