 |
Search Sci.Electronics.Basics |
|
|
|
|
|
|
 |
|
|
Sci.Electronics.Basics -> woot: ROM tradgedy revisited
There are 10 messages in this thread.
You are currently looking at messages 1 to 10.
|
Author: robbDate: 07:26 10-01-08
|
|
woot and and hardy THANKS ! to all the help,
more small problems with questions at the bottom if you want to
skip the story ....
short version:
----------------
- robb repairs non-problem on working ('85) micro-board with 32v
rampage on the 5v rail (32v rails meets 5v rail) :( bad joke,
nothing repaired, everything broken :(
- ** lots of help from "sci.electronics.*"
- many IC casualties including the MCU (SAB 8031) and ROM (NEC
D23256AC) **BIG** ROM problem
- ** lots of help from "sci.elec.*
- much searching and patience then access to good ROM *but* many
problems reading
- ** lots of help from "sci,elec.* and "rec.games.pinball" and
"alt.microcontrollers.8bit"
- woot --- ROM copied and image working
Details:
-------------
- ROM mistakenly treated as 27c256 variant. so, bad reads and no
pin play helps
- ROM turns out to be maskable, address latching. so need a slow
or latching alogortithm
- helpful advice says try 87c257
- The programmer supports it and it worked --- good ROM read
- Programming , no joy with 27c256 variant ROMs as a new ROM host
even though in theory it seems they should work
- new 87c257 arrive and work
**BUT**
Problem:
-----------
On the 87c257 (Pin 1) is (~AS, addr strobe) is the latching
signal. However, the (D23256) used falling edge of (OE) same as
(G) as the address latch ??
so 87c257 only works if i lift (Pin 1) out of socket and jumper
to a suitable/safe address latching signal
Question (s):
- both (OE) and (CE) work as surogate latch but which is better
choice ?
- what is the best/proper way to solve this problem or do this
jumpering ?? just solder a jumper wire across the pins ? should i
use resistor, diode, other ?
- how to deal with dangling (Pin 1) fold it up, clip it, etc
- Is it possible to get the 27c256 ROM without adding latching
mechanism around them
any suggestions on what pieces i would need to build a
latching mechanism
thanks again for any helpful advice,
robb
|
|
|
|
Author: Ian MalcolmDate: 18:58 10-01-08
|
|
robb wrote:
> woot and and hardy THANKS ! to all the help,
>
> more small problems with questions at the bottom if you want to
> skip the story ....
>
> short version:
> ----------------
> - robb repairs non-problem on working ('85) micro-board with 32v
> rampage on the 5v rail (32v rails meets 5v rail) :( bad joke,
> nothing repaired, everything broken :(
> - ** lots of help from "sci.electronics.*"
> - many IC casualties including the MCU (SAB 8031) and ROM (NEC
> D23256AC) **BIG** ROM problem
> - ** lots of help from "sci.elec.*
> - much searching and patience then access to good ROM *but* many
> problems reading
> - ** lots of help from "sci,elec.* and "rec.games.pinball" and
> "alt.microcontrollers.8bit"
> - woot --- ROM copied and image working
>
>
> Details:
> -------------
> - ROM mistakenly treated as 27c256 variant. so, bad reads and no
> pin play helps
> - ROM turns out to be maskable, address latching. so need a slow
> or latching alogortithm
> - helpful advice says try 87c257
> - The programmer supports it and it worked --- good ROM read
> - Programming , no joy with 27c256 variant ROMs as a new ROM host
> even though in theory it seems they should work
> - new 87c257 arrive and work
> **BUT**
>
> Problem:
> -----------
> On the 87c257 (Pin 1) is (~AS, addr strobe) is the latching
> signal. However, the (D23256) used falling edge of (OE) same as
> (G) as the address latch ??
>
> so 87c257 only works if i lift (Pin 1) out of socket and jumper
> to a suitable/safe address latching signal
>
> Question (s):
> - both (OE) and (CE) work as surogate latch but which is better
> choice ?
> - what is the best/proper way to solve this problem or do this
> jumpering ?? just solder a jumper wire across the pins ? should i
> use resistor, diode, other ?
> - how to deal with dangling (Pin 1) fold it up, clip it, etc
> - Is it possible to get the 27c256 ROM without adding latching
> mechanism around them
> any suggestions on what pieces i would need to build a
> latching mechanism
>
> thanks again for any helpful advice,
> robb
Always consider the possible need for youself or another to be able to
read the new rom in a programmer in several years time. Therefore do
*NOT* butcher the pins more than you have to. Clipping the pin will
make it more difficult to read in the future, so dont if you can get
enough clearance for safety by bending it out a bit (not dead flat, it
might break off). IIRC your board had /ALE going to pin 20 (/CS or chip
select) of the socket and PSEN to pin 22 (/OE, outpout enable). A
carefull inspection of the SGS Thomson M87C257 data sheet indicates that
it should be acceptable to tie pin 1 (bent out) to pin 20 driving both
the chip enabe and the address latch from the same /ALE signal. Thats
*ONE* wire soldered diagonally accross the top of the ROM. I've seen
worse in production equipment!
No resistors diodes etc. required. The *ONLY* time you should use a
resistor for a mod like this is if you need to tie an input to +5V
supply, then you should use a series resistor typically 1K to prevent
any risk of latchup on a supply spike.
Dont forget a bit of aluminium foil tape over the window in the EPROM.
It on1y takes a few weeks of direct sunlight to wipe an EPROM and
ambient liting can cause the EPROM to malfunction (But not actually
erase it). Some people would prefer a black paper label. Pale colours
and PVC tape can let too much light through for *long* term reliability
At this point, with pin 1 tied to pin 20, assuming it works OK, leave a
note in an envelope taped inside the cabinet for any future repair
describing the modification and for ****s sake put it back together
before the cat knocks it off the bench or anything else goes wrong :-)
As to making the ordinary 27Cxx series roms work with an 8051
equivalent, You would need that address latch, all the circuits I have
seen use an external TTL octal latch to demultiplex the Adrdress bus.
I'm not saying it could *NEVER* work without a latch as an old enough
slow enough EPROM *might* have the data valid long enough from a
transition on the address bus, but if you replaced with a different
brand of 8051 or EPROM or even changed the temperature or supply voltage
10%, I would expect it to stop working! *NOT* exactly a sane and
reliable design :-)
If the original manufacturer is no more, please consider putting the Hex
file for the ROM, with full make model and description to accompany it
on the net somewhere suitable, *somebody* may need it sometime in the
future.
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
|
|
|
|
Author: robbDate: 11:01 11-01-08
|
|
"Ian Malcolm" <valid.address.in.signature@invalid.invalid> wrote
in message news:fm6ba4$bu9$1@inews.gazeta.pl...
> robb wrote:
> > woot and and hardy THANKS ! to all the help,
> >
i guess no one cared much for my h'omage (woot) to the era this
board derived
[ trim story ....]
> > thanks again for any helpful advice,
> > robb
>
> Always consider the possible need for youself or another to be
able to
> read the new rom in a programmer in several years time.
Therefore do
> *NOT* butcher the pins more than you have to. Clipping the pin
will
> make it more difficult to read in the future, so dont if you
can get
> enough clearance for safety by bending it out a bit (not dead
flat, it
> might break off). IIRC your board had /ALE going to pin 20
(/CS or chip
> select) of the socket and PSEN to pin 22 (/OE, outpout enable).
A
> carefull inspection of the SGS Thomson M87C257 data sheet
indicates that
> it should be acceptable to tie pin 1 (bent out) to pin 20
driving both
> the chip enabe and the address latch from the same /ALE signal.
Thats
> *ONE* wire soldered diagonally accross the top of the ROM.
I've seen
> worse in production equipment!
>
great, easy enough
>
> No resistors diodes etc. required. The *ONLY* time you should
use a
> resistor for a mod like this is if you need to tie an input to
+5V
> supply, then you should use a series resistor typically 1K to
prevent
> any risk of latchup on a supply spike.
>
> Dont forget a bit of aluminium foil tape over the window in the
EPROM.
> It on1y takes a few weeks of direct sunlight to wipe an EPROM
and
> ambient liting can cause the EPROM to malfunction (But not
actually
> erase it). Some people would prefer a black paper label. Pale
colours
> and PVC tape can let too much light through for *long* term
reliability
>
> At this point, with pin 1 tied to pin 20, assuming it works OK,
leave a
> note in an envelope taped inside the cabinet for any future
repair
> describing the modification and for ****s sake put it back
together
> before the cat knocks it off the bench or anything else goes
wrong :-)
>
well the project was supposed to be a learning exercise... as
well as repair
so put it back together ? and I was just about to re-kindle the
"ringing issue" on the clock signal going to the display board
:D the one that started this mess
>
> As to making the ordinary 27Cxx series roms work with an 8051
> equivalent, You would need that address latch, all the circuits
I have
> seen use an external TTL octal latch to demultiplex the
Adrdress bus.
> I'm not saying it could *NEVER* work without a latch as an old
enough
> slow enough EPROM *might* have the data valid long enough from
a
> transition on the address bus, but if you replaced with a
different
> brand of 8051 or EPROM or even changed the temperature or
supply voltage
> 10%, I would expect it to stop working! *NOT* exactly a sane
and
> reliable design :-)
>
ok, that was my concern. i did not know if the purely timing
dependency was a hardware design issue, since the datasheets
always seem to show a very detailed timing diagram for
data/address/signals
reliability is certainly at the top of my requirements
>
> If the original manufacturer is no more, please consider
putting the Hex
> file for the ROM, with full make model and description to
accompany it
> on the net somewhere suitable, *somebody* may need it sometime
in the
> future.
>
> --
> Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
> ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
> [at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails -->
NUL:
>
lots of great advice.
Again thanks for all the help Ian ,
since you were the one to suggest the latching ROM and 87c257
trek then i guess i owe you a pint or three :)
thanks again,
robb
|
|
|
|
Author: LostgallifreyanDate: 19:25 11-01-08
|
|
rebel <me@privacy.net> wrote in
news:n93go3tg3rphsfa8d16fdfv0oo30198mvk@4ax.com:
> Ian, do you have ANY evidence to back that claim re sunlight. AFAICT it is
> urban legend, but tests we conducted - in a far sunnier climate than yours
;-) -
> revealed not a single bit had changed in 2764's after a month in the
weather.
>
> rebel
>
> 32S 116E
>
Should just be a matter of time, given photons as quanta. I couldn't do it
here, light not strong enough, but a less-than-annihilating focus with a
magnifier speeded it up enough to prove I could erase and re-write, so the
question is not whether unfiltered sunlight can do it, it's how long does it
take for a given strength.
Lostgallifreyan
51N 238W
|
|
|
|
Author: rebelDate: 19:46 11-01-08
|
|
On Thu, 10 Jan 2008 23:58:31 +0000, Ian Malcolm
<valid.address.in.signature@invalid.invalid> wrote:
(snip)
>Dont forget a bit of aluminium foil tape over the window in the EPROM.
>It on1y takes a few weeks of direct sunlight to wipe an EPROM and
>ambient liting can cause the EPROM to malfunction (But not actually
>erase it). Some people would prefer a black paper label. Pale colours
>and PVC tape can let too much light through for *long* term reliability
Ian, do you have ANY evidence to back that claim re sunlight. AFAICT it is
urban legend, but tests we conducted - in a far sunnier climate than yours ;-) -
revealed not a single bit had changed in 2764's after a month in the weather.
rebel
32S 116E
|
|
|
|
Author: Eric SmithDate: 20:40 11-01-08
|
|
robb wrote:
> - both (OE) and (CE) work as surogate latch but which is better
> choice ?
Impossible to say without knowing the relative timing. Use a dual-trace
scope, trigger on OE, and look at address lines (one at a time) on other
trace. Make sure there seems to be enough setup time from address valid
to the edge of OE. In other words, the scope trace for the address line
shouldn't show any transitions for perhaps 20 ns before the edge of OE.
(Look up the required address setup time in the data sheet.)
Then try the same experiment for CE.
If they both show sufficient set up time, it doesn't matter, but I'd
choose the one that shows more.
|
|
|
|
Author: robbDate: 21:08 11-01-08
|
|
"Eric Smith" <eric@brouhaha.com> wrote in message
news:m3wsqfq0s9.fsf@donnybrook.brouhaha.com...
> robb wrote:
> > - both (OE) and (CE) work as surogate latch but which is
better
> > choice ?
>
> Impossible to say without knowing the relative timing. Use a
dual-trace
> scope, trigger on OE, and look at address lines (one at a time)
on other
> trace. Make sure there seems to be enough setup time from
address valid
> to the edge of OE. In other words, the scope trace for the
address line
> shouldn't show any transitions for perhaps 20 ns before the
edge of OE.
> (Look up the required address setup time in the data sheet.)
>
> Then try the same experiment for CE.
>
> If they both show sufficient set up time, it doesn't matter,
but I'd
> choose the one that shows more.
hello Eric,
Thanks for reply,
OE shows the most delay before falling edge *BUT* that fall
occurs way ou ther about halfway accross/between the
Address/Data transitions which are maybe 150 ns wide.
CE drops about a fraction after the Address transition.
I will double check that to make sure i am being accurate but
that is my memory at the moment.
thanksfor help, ill double check,
robb
|
|
|
|
Author: Ian MalcolmDate: 22:40 11-01-08
|
|
robb wrote:
> "Eric Smith" <eric@brouhaha.com> wrote in message
> news:m3wsqfq0s9.fsf@donnybrook.brouhaha.com...
>
>>robb wrote:
>>
>>>- both (OE) and (CE) work as surogate latch but which is
>
> better
>
>>>choice ?
>>
>>Impossible to say without knowing the relative timing. Use a
>
> dual-trace
>
>>scope, trigger on OE, and look at address lines (one at a time)
>
> on other
>
>>trace. Make sure there seems to be enough setup time from
>
> address valid
>
>>to the edge of OE. In other words, the scope trace for the
>
> address line
>
>>shouldn't show any transitions for perhaps 20 ns before the
>
> edge of OE.
>
>>(Look up the required address setup time in the data sheet.)
>>
>>Then try the same experiment for CE.
>>
>>If they both show sufficient set up time, it doesn't matter,
>
> but I'd
>
>>choose the one that shows more.
>
>
> hello Eric,
>
> Thanks for reply,
>
> OE shows the most delay before falling edge *BUT* that fall
> occurs way ou ther about halfway accross/between the
> Address/Data transitions which are maybe 150 ns wide.
>
> CE drops about a fraction after the Address transition.
>
> I will double check that to make sure i am being accurate but
> that is my memory at the moment.
>
> thanksfor help, ill double check,
> robb
>
Dont over engineer it! You have *GOT* to latch the address off of the
/ALE signal, nothing else is guaranteed to have the right timing. It is
however usual to use a transparant latch with an 8051, so as Eric said,
you *might* be short of timing margin between the address/data bus
giving a valid address and /ale going low.
If yoy aren't happy enough that it works, you could check the timing.
With a storage scope, set a mid window Trigger on the -ve edge of /ALE
(pin 30 of the CPU IIRC) and check the address bus transition to -ve
/ALE edge timing. To measure it *without* a storage scope, you'll need
to trigger on the +ve edge of /ALE and to get a stable display you'll
need an EPROM full of NOPs (0x00) This will give you a nice steady
display on the scope as it results in the CPU address buss couting up in
binary and eventually wrapping round to zero. For this application ONLY
where the whole EPROM is full of the same value one of your 27c256 chips
should work just fine.
From the 87c257 data sheet, you only need 7 ns of margin between
address transition and -ve edge of /ALE. If you are short of timing
margin a 470R resistor inserted between pin 1 of the EPROm and /ALE on
pin 20, with a 33pF capacitor to ground from pin 1 should be enough
delay to fix it, but its a real kludge and I'd be ashamed to use it if
it wasn't needed :-)
Me, I'd just be pragmatic and try heating and cooling the 8051 and the
working 87c257. Use freezer spray and a hair drier! You need to test
all combinations of EPROM and 8051 hot and cold:
ROM CPU
hot hot
hot cold
cold hot
cold cold
For each combination check it woks OK awithout crashing. If it passes,
as a one off unit it *will* be fine for operation at room temperature.
Enjoy :-)
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
|
|
|
|
Author: Ian MalcolmDate: 22:49 11-01-08
|
|
OOPS, I dropped the other groups by mistake!
Reposted as I dont know Robb's home group. Sorry everyone!
Lostgallifreyan wrote:
> rebel <me@privacy.net> wrote in
> news:n93go3tg3rphsfa8d16fdfv0oo30198mvk@4ax.com:
>
>
>>Ian, do you have ANY evidence to back that claim re sunlight. AFAICT
it is
>>urban legend, but tests we conducted - in a far sunnier climate than
yours
>
> ;-) -
>
>>revealed not a single bit had changed in 2764's after a month in the
>
> weather.
>
>>rebel
>>
>>32S 116E
>>
>
>
> Should just be a matter of time, given photons as quanta. I couldn't
do it
> here, light not strong enough, but a less-than-annihilating focus with a
> magnifier speeded it up enough to prove I could erase and re-write,
so the
> question is not whether unfiltered sunlight can do it, it's how long
does it
> take for a given strength.
>
>
> Lostgallifreyan
>
> 51N 238W
Well I was taught many many moons ago, that an EPROM could get wiped by
sunlight and IIRC individual memory cells could be affected in a matter
of weeks of direct sunlight. Of course it would take *much* longer for
the whole EPROM to read blank - especially in our climate.
I *may* still have some of my notes from the time, but they are in dead
tree format and aren't practically searchable (not to mention lousy
handwriting). One thing to bear in mind when setting up such an
experiment is that ordinary window glass is a fairly effective UV filter
and also you need a sunlight recorder (the sort that burn trails accross
the daily paper if you want repeatable results. A lot of work for a
hobbyist for not much knowlage. ONE student engineer probably did some
research back in the early 70's and by the end of that decade, it was
commonly accepted that one *did* cover the windows. Whether later
generations of EPROMS are as vunerable to daylight as say a 1702, is
another matter. I suspect that in the interests of long term data
integrity, later chips may be effectively 'hardened'.
A 1702 datasheet gives the requirements for erasure as shortwave UV
(UVC) at 2537 angstroms with an integrated exposure of 6 watts/sec/cm^2.
UV levels at sea level (tropical) peak at about 0.13 milliwatt/cm^2 at
about 5000 angstroms. UVC is effectively totally removed by the ozone
layer. *IF* UVB was as effective as erasing eproms as UVC, then a 1702
would be totally wiped by 13 hours of direct sunlight. The intesity of
UVC at about 2500 angstrom *outside* the earth's atmosphere is of the
close order of 0.01 milliwatt/cm^2, so an EPROM in *ORBIT* protected
against UVB but *NOT* UVC would be totally erased in 600 hours of
sunlight. Add in the variable effects of cloud cover, strength of the
ozone layer, possible inadequate programming of the EPROM in the first
place, and reduced exposure to flip the first bit rather than wipe ther
whole array etc. I see no reason to doubt that the effective life of the
data in an unprotected EPROM exposed to direct sunlight is of the order
of weeks, not years. One thing is for sure, I am not digging out one of
my remaining few 1702s and breadboarding a programmer to do any tests :-)
I do know that there are confirmed reports of ordinary bench or room
lighting upsetting the operation of windowed EEPROMS and for the price
of a roll of foil tape, one has guaranteed 100% effective light barrier.
I've never experimented with the effect, decapped DRAM with a suitable
lens over it was *much* more interesting!
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
|
|
|
|
Author: Ian MalcolmDate: 22:52 11-01-08
|
|
Ian Malcolm wrote:
> I do know that there are confirmed reports of ordinary bench or room
> lighting upsetting the operation of windowed EEPROMS and for the price
> of a roll of foil tape, one has guaranteed 100% effective light barrier.
AAGH! Keyboard stutter - not my evening!
for "windowed EEPROMS" read "windowed EPROMS"
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
'Stingo' Albacore #1554 - 15' Early 60's, Uffa Fox designed,
All varnished hot moulded wooden racing dinghy.
|
|
|
|
1 |
|
|
|
|
Contact | Electronic Portal
|
|
|
