80-Bus News |
March–April 1984 · Volume 3 · Issue 2 |
Page 33 of 51 |
---|
4 – | Edit the contents of the buffer. Allows simple editing of the contents of the buffer. |
5 – | Display the buffer. Displays the buffer contents on the screen using the conventional Hex/ASCII display format (as in Gemdebug, Nas-Sys etc). |
6 – | Write the buffer to a disk file. (A prompt for a file name will appear. If the file name you give already exists you will be asked for confirmation that it is to be overwritten.) |
7 – | Write the buffer to an EPROM. (i.e. Program the EPROM.) |
8 – | Verify the EPROM is erased. Prints out any locations within the EPROM that are not 0FFh. |
9 – | Verify an EPROM against the buffer. The two are compared and any differences are listed to the screen. |
The heading also displays three things of interest. i) Whether the memory buffer contains any data. ii) The type of EPROM currently selected. iii) The name of the last file read/written to/from the memory buffer. Items (ii) and (iii) I find quite useful, especially if you’re trying to program multiple files into multiple EPROMs.
The software implements the “Inteligent programming algorithm” (IPA) for the larger EPROMs (2764 and upwards). For those of you that haven’t met this, this is a technique for vastly speeding up the programming of the latest EPROMs.
In general EPROMs are programmed by presenting the appropriate address and data to the EPROM along with a suitable write pulse. (Certain ‘programming’ voltage levels have to be present on other pins.) The write pulse duration is specified at 50mS. This figure of 50mS has to cover the worst case, and in fact most data cells within an EPROM program in a fraction of this time (Intel claim 16% of the time i.e. 8mS), and the difficulty lies is determining when a cell is adequately programmed. With devices such as the 2716 the resultant programming time of about 100 seconds was not a burden, but 14 minutes for a 27128 is another matter entirely, (let alone 28 minutes for a 27256!). The latest EPROMs have been designed and tested so that a (faster) modified programming technique can be used, which still results in the same guaranteed long term data retention characteristics. A simplified version of this algorithm is as follows:
1) | Set up the programming conditions and set Vcc=6v (rather than the usual 5v) |
2) | Apply address & data and set a software counter N=0. |
3) | Apply a 1mS write pulse. Set N=N+1. |
4) | Read back the data (with Vcc still at 6v) and compare with the original. If it has not programmed go to 3 (unless N=15). |
5) | Apply a pulse of 4NmS to complete the programming. |
6) | Verify & move on to next address. |
i.e. You try in stages until the byte is programmed, then you give it a final big ‘bash’ (4 x what you’ve given it so far) to ensure that the cells are well and truly past the threshold. The 6v Vcc level also ensures that the internal threshold level that determines whether it is a ‘1’ or a ‘0’ that you are reading is back is higher than normal. This gives an increased programming margin that leads to increased reliability.
In practice I found that 2764s I was using programmed in about 90 seconds using this algorithm.
Page 33 of 51 |
---|