PALCE16V8H

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sun Mar 10 15:38:27 2002

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" <Lee.Davison_at_merlincommunications.com>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, March 10, 2002 12:56 PM
Subject: PALCE16V8H


>
> Slightly OT.
>
> Does anyone have the read/write spec for a PALCE16V8H?
>
> I want to put more memory on an 8032 SBC but can't afford
> to buy a programmer just to read the chip that does the
> decoding. I can replace it with a GAL part but I'd like to read
> the original.
>
> Ta.
> Lee.
>
>
>
> ----------------------------------------------------------------------------
> ----
> This email is intended only for the above named addressee(s). The
> information contained in this email may contain information which is
> confidential. The views expressed in this email are personal to the sender
> and do not in any way reflect the views of the company.
>
> If you have received this email and you are not a named addressee please
> delete it from your system and contact Merlin Communications International
> IT Department on +44 20 7344 5888.
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>
>
Received on Sun Mar 10 2002 - 15:38:27 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:11 BST