General program timings and hardware requirements.
============================================


The adaptation of some I/O circuits to faster demands.


Hardware requirements for the programmer?? The slower, the better..........

On a very slow XT-PC machine in "read master" mode the /CE (chip select or "read") pulse for a EW904B comes at 50 to up to more than 100 usec after an address change. This is the /OE read pulse for a EW904BN. On a 386SX-16 this is already decreased to 14 to 30 usec. On a 386SX-33 this is about 7 to 15 usec. On a 386DX-40 delays are getting smaller than 5 to 10 u-sec, and on a 486 ... 2 to 5 usec. A0 timings smaller than 15 to 20 usec: not all goes well.
You see we have a problem. Real timings via timer interrupts (the programming pulses) are always OK, but as normal program execution goes high with newer machines, the "normal" delays necessary for (address) voltage changes to stabilise before the next action takes place (read!) are getting a problem. Those "address cycles" are probably NOT programmed timer interrupts or fixed programmed delays in the main program loop, but only runtime delays. A lack of only a few statements in the software. This is to my opinion the problem with the cards I got in hand. At 1000H the A13 line comes "alive"; a typical address that causes serious problems. Not only A13 has much too high delay (40 - 60 usec), also the Vpp to Vcc switching is just too slow on the 904B, 20 usec or even more. See the "rebuild" story for pin 26 - the A13 line. With the reduction of the settling delays the programmer may work on much faster machines as original was possible, but even an old pentium still looks too fast. See the measured timings further down.

I was testing some timings on a 386DX-40 and used an old AMI-bios trick to switch to old PC/XT speed (4.77 MHz). Use ALT+CTRL+(grey minus key) utter right. To my astonishment speed dropped more than 10 times on the oscilloscope. Switch back = ALT+CTRL+(grey plus key). All timing problems were solved in PC-XT speed mode .......... Only hit a key to come out of turbo speed and your programmer works!! Or use the turbo button at your desktop. So: if your 486 has no turbo (off) button, probably the keyboard trick works. Or: a slow motion program (TSR) for an old game could be a solution to slow things down a bit.

Real world timings:

A lot of old scrap machines from the shed have come alive again for the following tests (luckily I still had them!!). Below is the timing table for address bit A0 in "read master" mode. It is the total time duration for a "0" or a "1" during successive address increments. During programming timings are much longer, much more action takes place. Somewhere in this A0 window is the /CE or /OE pulse for a data fetch. See the next table following the first.

ALL values are in microseconds (usec).
   A0 cycle   8088 XT-8MHz   386DX40 in XT-mode   286-16     386SX-16      386SX-33     386DX-40     486DX2-66  
904B
210
190
52
51
34
21
18
904BN
170
170
46
48
28
18
11

The next following table is the start of /CE (904B) or /OE (904BN) after the A0 change for a data fetch. In the 904B there are two /CE pulses, a narrow one as a start (false??) and a wider one (real??) a bit later. The false (?) /CE can overlap Vpp to Vcc switching delays during programming (to be exactly: at verify between programming pulses). A cause for errors I think??

ALL values are in microseconds (usec).
/CE or /OE after A0 8088 XT 8MHz
   1st --- 2nd  
  386DX40  
  in XT mode
  1st --- 2nd  
  286-16  
  1st --- 2nd  
  386SX-16  
  1st --- 2nd
  386SX-33  
  1st --- 2nd
  386DX-40  
  1st --- 2nd
  486DX2-66  
  1st --- 2nd
904B 78 --- 116 65 --- 100 17.5 --- 27 18 --- 28 12 --- 18 6 --- 10.5 5 --- 8
904BN 58 50 14 14 7.5 5.5 2

If you look at the decrease in possible settling time for address changes you see why things are getting tricky on a 486DX2 or even a 386DX machine. Even more if you would know what the delays really are for pin 26 - A13 and other points. At my place a EW904B is working OK in a 486DX2-66 ...... How did I do that???

I rebuild/ adapted all the I/O points with a too high delay. They were:

1) Address pins combined with Vpp: rise: < 2 usec (=OK) , fall 15 - 20 usec. (NOT OK, discharge problem)

2) The circuit for A13 - Vcc2 on pin 26 was the greatest problem: rise : 40 usec, fall 60 (to 80) usec!! compare this with the A0 cycle time!! 1000H errors on a bit faster machine than an XT are due to a design imperfection!!

This A13 problem needed the most attention, but it was not easy to cope with. I had to place a special buffer chip to solve that problem: a powermosfet driver. See a separate story with more explanation. Also in the redesigned 904BN the A13 circuit is NOT perfect at all. (If you take into account that there are decouple C's connected to it in the ZIF unit). Fall = OK: 5 usec, rise 300 usec!! (measured NOT with the original ZIF unit). This ZIF unit (from the 904B) has 4x 10nF decouple C's on Vcc-2 / A13. I don't know how it was on the original unit, probably not much different.

After changing my EW904B with lower (Vpp) discharge R's: address delays on Vpp pins now: rise time 2 usec or smaller, fall 5 usec or smaller. A13 - pin 26 with extra chip: rise and fall both now smaller than 1 usec!! My A13 idea could also be used for the 904BN. With a different buffer chip.

Vpp to Vcc (25 to 5 Volt) switching falltime during repetitive program/ verify pulses has to be completed before a /CE takes place. You could ruin your eproms.... I reduced those delays to more than half of it. At the same pins are address bits, so they are much faster too now. If voltage was to much reduced to the heavier loading, a pull-up was added on the right place. After the rebuild of the TL497 circuit the extra load on Vpp was no problem.

See the diagrams for where some resistors were changed or added in the Vpp circuit. See all the other stories for much more info....


Walter Geeraert
Vlissingen
The Netherlands

Copyright© 1990 - 2020 Walter Geeraert - All Rights Reserved


sunshine PE1ABR Back to main EPROM page