nesdev.com

The higher the frequency, the smaller inductor you can use. Check what inductor you have and use frequency adequate for it. Many DC step-ups work at 100 kHz, but it requires at least 100uH inductor in your case. The frequency cannot be too low (below 20 kHz), because you will hear `buzz` from inductor.


V ripple is desired oscillation of voltage at output, check datasheet of memory in what range the voltage can be (100mV ripple should be OK).

Long time ago I built step up for my Willem LPT programmer (because the original was not able to generate 25V). By using jumpers, I was able to force my step up to produce one of four most common voltages for programming eproms: 12.75V, 16V, 21V, 25V. Here is schematics with values:

Assuming 10% or 5% permissible ripple is a standard rule-of-thumb. Specifically in the case of the 6.5V Vcc during programming, however, the part has a 7V absolute maximum, so 10% is too big there. The examples given in the MC34063 datasheet use much lower tolerances; as little as 1.2‰.

The available sizes of inductor and capacitor usually put some limits on fmin, as does the boost converter. The lower the frequency, the bigger the capacitor, inductor, and lower permissible series resistance of the inductor. The higher the frequency, the greater the losses in the inductor. See this article: http://www.eetimes.com/document.asp?doc_id=1272335

I made some modification to the schematic :
VCC is only 5v USB (no 6.5v at all)
Using a 47uF on VCC line made the read process more stable
VPP 13v is generated by using MC34063
Instead of 33K pull down resistors I used 10K pull up resistors (same as Willem Programmer)

But unfortunately Writing EPROM doesn't work.
Nothing is written to the first 36 bytes.
Then it starts to write a byte and fails the next one, and so on.
Here is my code for write process :



Any idea how to fix it?

With UVEPROM programming, you have to

* Write the byte
* See if the byte is programmed
* Repeat until either it succeeds or you time out.

You can't just blindly write values to it, because you will either overprogram (and prematurely age the part) or underprogram (and the programmed values won't show up). Each individual bit has its own threshold for the amount of time needed to shove the correct amount of charge into it, and it gets longer the more time that bit is programmed and erased.

The amount of time you're supposed to use per bit varies by the specific part being programmed. ST's M27C801's datasheet says "50µs for each byte, repeat up to 25 times per byte". Older parts are often even slower.

I applied a 6.5v to VCC of EPROM and write was successful!

A rapid programming algorithm is suggested in AT27C080 datasheet :



Why is it needed to verify every byte up to 10 times after programming?
Isn't it enough to read the whole eprom data and compare it with the original data?
So that the whole process will be easier.

Is it possible to use LPT-Pin17 to generate a 50uS for /CE?

It's not "verify" a byte 10 times.

It's "see if you've successfully programmed it yet", and after verification fails 10 times, the part is assumed too damaged to ever be programmed.

Like I said, every byte will require a different amount of time spent attempting to shove electrons into the floating gate of the UVEPROM. This is an analog effect, and is affected by the specific floating gate's history. So when they say "50µs, up to 10 times", they mean "any given byte will require a maximum of 25 microcoulombs to be programmed and if that isn't enough the bit will never work"

If I want to use burn-verify-reburn-compare method I have to change the whole logic of the programmer, in that case even EPP handshake may become unusable.

So how about this method : burn-compare
At the start of the programming I ask the user about the condition of the EPROM which can be one of these : new, used, weary
According to the condition of the EPROM I can adjust the width of the burn pulse :
new : 100us
used : 500us
weary : 1000us
After burning I can read the whole EPROM and compare it with the original data to check if the burn process was successful.

Is this possible?

That will damage your parts. Asking the user isn't good enough. Both because of user error, and also because different parts of the ROM age at different rates, so different amounts of time will be required on a byte-by-byte basis.

The reason that EEPROMs often say

Embedded algorithms for completely self-timed write/erase operations

is exactly because of this annoyance that you're dealing with.

Do you really have to do it? No, you're free to destroy your parts by whatever method you choose. Will it instantly destroy parts? No, I'd guess that most of them would survive one or two reprogrammings in this blind way.


It's definitely worth pointing out that you are already not using the EPP handshake. You are faking it by having the computer manually drive the WAIT line high and then low, which tricks the EPP hardware into thinking it's getting a handshake.

There's also no reason that your 4040s have to be clocked by the same /DSTROBE signal that reads or writes from the ROM.

Are you referring to this part of the code? :


D_strobe causes a clock on 4040
Q0 of 4040 goes high which is used as wait signal
So an EPP handshake happens
But after handshaking Q0 stays high, on the other hand to start another EPP handshake wait must be low, so by generating a manual clock on 4040, Q0 goes low
So I think I use EPP handshake at least alternatively



Let's say the worst scenario happens :
user choose weary option and burn the EPROM with 1000us pulse, while the condition of the EPROM is new and it actually require 50us pulse to be successfully programed.
It seems that the whole life of the EPROM becomes 1/20, no?
While most of the times an EPROM is programmed a few times and then is used for years, so I feel that cutting their life even with 1:20 ratio is not that much critical, or is it?
Or maybe this makes the problem?! : 20 times * 50 us burn pulse != 1 time * 1000 us burn pulse

Also here is an approximate calculation which shows the current code works (by sheer chance?!) very close to the appropriate burn pulse (neither overprogram nor underprogram) :
With my code burn process takes 60 sec = 60000000 us
Total bytes of 27C080 : 100000 hex = 1048576 dec
60000000 / 1048576 = 57 us
So each byte receives about 57 us burning pulse which seems good, no?

Fair enough.

Specifically, what happens is:
* EPP data write
** R/W is brought low
** /DSTROBE goes low. Programming cycle #1
** 4040 increments, bringing WAIT high
** ROM drives value onto data bus
** /DSTROBE goes high
* manual Centronics port drive /DSTROBE low. Increments '4040, which brings WAIT low and changes the address seen by the ROM. Programming cycle #2 with ... hopefully $FF on the data bus? Therefore not actually a problem?
* manual Centronics port drive /DSTROBE high. Programming cycle #2 ends.
* repeat

What I'm suggesting is:
* Use a NAND gate to combine /DSTROBE and /ASTROBE and drive +WAIT
* Use /ASTROBE to increment the '4040

This provides two big advantages:
* Increment behavior is not tied to programming or reading, so bytes can be re-read, re-programmed, or skipped altogether.
* No need to manually toggle /DSTROBE an extra time; API is simpler.

At some point in the past I was going to suggest using a CD4060, because it includes an integral oscillator (i.e. inverter) ... but it also has a ÷8 divider on its outputs, so that isn't tremendously useful.

That is probably correct, but I'm not confident.

While it does seem likely to me that there are some transition times such that those two numbers don't work out to be equal, instead I suspect that overburning a pristine EPROM will damage it more than had it gradually gotten there.

You're probably right.

I suspect that much less than 50% of the time is spent with /DSTROBE asserted. You're probably underburning the EPROM, which won't harm anything—bits may just fall out too early. It'll be hard to tell by how much unless you get access to an oscilloscope to watch the /DSTROBE signal during programming. And certainly you can't be meaningfully overburning the EPROM if you're only spending 60µs per bit, when it's rated to a minimum of 50µs.

So a bus conflict? Maybe it explains the strange writing behavior that I had when I used only 5v (not 6.5v) for writing.


Awesome idea thanks

So what do you think about this design by using 4053 :

Init state :
write (Pin1) : high ==> A + B : 4053 {5V ==> EPROM VCC , GND ==> /GVPP}
D_Strobe (Pin14) : high ==> C + /CE : 4053 { GND ==> Wait (Pin11) } : EPROM is disabled
Reset (Pin16) : high ==> 4040 Reset
A_Strobe (Pin17) : high ==> 4040 Clock

Setup 4040 :
Reset goes low : 4040 is ready to count

Read operation :
Read from EPP data register
Write is high : 5v ==> EPROM VCC, GND ==> /GVPP
D_Strobe goes low
EPROM /CE goes low : EPROM becomes enabled
Wait goes high : EPP Reading handshake starts
Data is read from Parallel Port Pins
D_Strobe goes high
EPROM /CE goes high : EPROM becomes disabled
Wait goes low : EPP Reading handshake ends
Manually force A_Strobe low then high to generate a clock for 4040
Repeat from beginning to deal with the next byte

Write operation :
Write to EPP data register
Halt the program for 50us
Write goes low : 6.5v ==> EPROM VCC, 13v ==> /GVPP
D_Strobe goes low
EPROM /CE goes low : EPROM becomes enabled
Wait goes high : EPP Writing handshake starts
Data is written to EPROM
D_Strobe goes high
EPROM /CE goes high : EPROM becomes disabled
Wait goes low : EPP Writing handshake ends
Write goes high : 5v ==> EPROM VCC, GND ==> /GVPP

{
To verify a loop of Reading handshake can be started here.
If verify doesn't pass start reprogramming the same byte again
If verify pass continue
}

Manually force A_Strobe low then high to generate a clock for 4040
Repeat from beginning to deal with the next byte

No, I don't think so. For almost all UVEPROMs, programming $FF is the same as skipping the programming cycle altogether.

Of course, if the data pins don't have a weak pull-up and instead just float, then you're spending a few moments programming a bad value in instead.

I don't think the 4053 can pass voltages outside of its supply rails. If you instead try to supply it with the output of the boost converter, then the 3.3V logic from the parallel port is no longer high enough to control the multiplexers.

I'd probably just switch to using bare BJTs at this point, even though it's bigger.

I was thinking you'd use the NAND gate so that the hardware would automatically acknowledge both /DSTROBE and /ASTROBE. The only thing that you lose by manually toggling the pins is speed.

I worry whether the setup time is long enough? The M27C801 datasheet I keep referring to wants 2µs during which 13V is presented on Vpp before /E drops.

That won't make /Dstrobe stay low for a whole 50µs.

On the other hand, I'm pretty certain you can also get away with shorter programming. The only important thing is measuring how much shorter it is.

—

I think it's worth pointing out that you don't need to do the verification step immediately after programming. You can do something like
1) read ROM to blank check ROM (make sure that all bits that are desired to remain 1 are currently 1; it doesn't actually need to be blank)
** if any bits that should be 1are 0, then the ROM needs to be erased and programming cannot continue.
2) program bytes that need to be changed
3) reread ROM to see what bits are still 1 that need to become 0
4a) if any bits that should be 1 are 0, something bad happened, and programming cannot continue
4b) if any bits that should be 0 are 1, then increment pass counter, and if we haven't done too many passes, go to step 2. If we've done too many passes, the ROM is probably used up.
4c) if all bits that should be 0 are 0, programming is done.

You were right 4053 doesn't work.



I try to keep the hardware as simple as possible, even if I costs a little speed.

So here is a new design with BJTs.
But I don't know what is the best value for R11, R13, R14, can you help me with them please?

BJTs have a few relevant behaviors here.

The first one is called "β" or "h_FE". When allowed, a BJT in the "forward active" region will permit current flowing through the collector I_C equal to β times the current through the base I_B.

The second one is what happens when the BJT tries to draw more current through the collector (according to β) than is available. Then the BJT is in "saturation". Saturation has both a useful property: the voltage between the collector and emitter becomes very small ("V_CEsat"); and a bad one: exiting saturation takes extra time.

In a situation like the inverter (R13, R14, Q4) it's often desirable to set R13/R14 so that it just barely enters saturation, so that it exits saturation a little more readily. The other important thing is that the WAIT pin probably has a pull-up inside your parallel port, and you might be able to elide R13 altogether.

Finally, for R11, the situation is similar, but now the voltage of the BJT's emitter will rise proportionate to the amount of current flowing through the resistor R12. Once again, you want the BJT to just go into saturation when READ//WRITE is high.

So:
* look up hFE for the BJTs you are using
* measure what pullup is on the WAIT pin, if any (If none, use 4.7kΩ for R13)
* calculate R14 such that the BJT Q4 will just go into saturation when /DSTROBE is high.
* calculate the amount of current through R9/R10 and the amount of current that should be flowing through R12 when it's conducting
* calculate R11 such that the BJT Q3 will (again) just go into saturation when READ//WRITE is high.

One concern:

When the device is not plugged in to the parallel port, current can "shoot through" from 13V via Q1+R6 through Q2 and R8 to R11, Q3, and R12. You might need to add an extra stage of buffering to prevent that.

I calculated R11 manually and its value is 430K
But Transistor Base Resistor Calculator gives different value.
Where is my mistake?