PALCE16V8H

You'll need to know whether the part was protected or not. I'm very confused by what you say you want to do here. The 8032 has a 64K code space and a 64K data space. The code space is accessed using the nPSEN signal, while the data space is accessed via nRD and nWR. How you decode the individual chips (if you use more than one) is pretty arbitrary. I normally use a 64Kx8 SRAM for each, having copied the 64Kx8 EPROM in to the SRAM that occupies code space. This simply means you read from the EPROM and write back to it, which is convenient enough if, on reset, you've enabled the code EPROM in code space and the code SRAM in data space. You then simply MOVC/MOVX the data into corresponding locations from bottom to top, in the SRAM. On completing the task, which I decode in programmable hardware with what's essentially a 74F133 and an 'F138 that decodes the top 8 locations for external I/O, the rising edge of the MS I/O strobe (output n8 from the '138) clocks the '74ACT74 that selects the EPROM, which, now is disabled in favor of the SRAM each time the nPSEN goes active. The same flip-flop enables the OTHER SRAM, which, now, appears in data space. All this is really done in a pair of GAL22V10's, which decode the address space and produce the outputs that are needed for I/O functions not supported on the MCU. My only issue so far has been with speed, since I'm running a very fast version of the part. Small CPLD's, unfortunately, don't readily offer the very fast (<2 ns) input-to-ouput propagation delays I need. If you opt to use 32Kx8 or 8kx8 SRAMs, you still don't need any fancy decoding, since you simply get multiple instances of whatever memory you do place in the map. I'd be happy to discuss this with you off-list, if you like. The PALCE16V8H, BTW, is pretty much the same thing as the GAL16V8 in its various versions. It's just AMD's version (now LATTICE, as AMD spun off their programmable logic into Vantis, which was acquired by Lattice). AMD didn't make the programming spec's available to the public at large. If you have protected part and need to read it, you should probably give up on trying to read the device and, instead, devise your own decoder based on your system requirements. If you become really desperate, I do have some of the very earliest spec's on the Lattice version, which you might examine for your own benefit, and it might suggest a way to read the fuse map. I seriously doubt the AMD and Lattice parts are very different. That doesn't mean you'll easily be programming a device not supported by whatever programming hardware you have, however. Dick ----- Original Message ----- From: "Davison, Lee" &lt;Lee.Davison(a)merlincommunications.com&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Sunday, March 10, 2002 12:56 PM Subject: PALCE16V8H