SCP100@psuvm.psu.edu (STEPHEN POLKOWSKI) (04/17/91)
Hi all,
I would like to develop my own eprom programmer using a 68000 family pro
cessor. My question is: where does one find the specs for programming memory c
hips? Do the manufactures publish specs on how to program their chips? Any
information would be appreciated.
Thanks,
Stevemcmahan@netcom.COM (Dave Mc Mahan) (04/27/91)
In a previous article, SCP100@psuvm.psu.edu (STEPHEN POLKOWSKI) writes: >Hi all, > > I would like to develop my own eprom programmer using a 68000 family pro >cessor. My question is: where does one find the specs for programming memory c >hips? Do the manufactures publish specs on how to program their chips? Any >information would be appreciated. As far as I know, they only definative place to find the techno-info you seek is in the data book from each manufacturer. I know that Intel algorithms for writing are different than Hitachi, for instance. Programmers like Data I/O use different algorithms for each type of EPROM, as some EPROMs burn faster than others. I would suggest you order the data book or data sheet on each part you are interested in supporting from the maker. Although this is a pain to do, it is usually free. Data I/O has literally hundreds (if not thousands) of supported part numbers listed in their books. It would be especially nice of you to just read the EPROM ID code from a chip and select the appropriate alogorithm. I don't know why Data I/O doesn't do this automatically, but they don't. It KNOWS the proper ROM ID code for the chip in the socket, why don't they just use the right algorithm? I guess it could be difficult to even select the proper socket (the Data I/O 29B programmer has 6 or 8 sockets, all different sizes) and read the ID code without risking damage to the chip, but it would be nice if they could. >Thanks, >Steve -dave -- Dave McMahan mcmahan@netcom.com {apple,amdahl,claris}!netcom!mcmahan
andreww@uniwa.uwa.oz (Andrew John Williams) (04/29/91)
mcmahan@netcom.COM (Dave Mc Mahan) writes: >the appropriate alogorithm. I don't know why Data I/O doesn't do this >automatically, but they don't. It KNOWS the proper ROM ID code for the >chip in the socket, why don't they just use the right algorithm? I guess >it could be difficult to even select the proper socket (the Data I/O 29B >programmer has 6 or 8 sockets, all different sizes) and read the ID code >without risking damage to the chip, but it would be nice if they could. Could it have anything to do with not knowing where A9 is (or even if the chip has a signature mode) until you know what the chip is? I've seen A9 move around quite a lot. John West (stealing Andrew's account) Why is a fish?
bevis@en.ecn.purdue.edu (Jeff Bevis) (04/30/91)
In article <1991Apr27.060346.25929@netcom.COM> mcmahan@netcom.COM (Dave Mc Mahan) writes: > > In a previous article, SCP100@psuvm.psu.edu (STEPHEN POLKOWSKI) writes: >>Hi all, >> >> I would like to develop my own eprom programmer using a 68000 family pro >>cessor. My question is: where does one find the specs for programming memory >>chips? Do the manufactures publish specs on how to program their chips? Any >>information would be appreciated. > >As far as I know, they only definative place to find the techno-info you seek >is in the data book from each manufacturer. I know that Intel algorithms for While I hate to prolong a thread which is probably inappropriate to this group, I have to take the opportunity to ask... Why is it that manufacturers don't like to include device programming data for GALs/PALs/etc in their databooks? In the National "Programmable Logic Devices Databook and Design Guide," the following phrase is frequently repeated: "This section alone, however, does not contain sufficient information to implement the GAL programming algorithm." The book goes on to suggest that the user contact the National Programmable Device Support department. Why not just put it in the book? AMD's books are just as mysterious. How can they expect a poverty-stricken college student like me to build a GAL programmer if the data is not readily available? Well, anyway, I might just end up making some phone calls to National on this. But, if anyone knows of any good reference material I should be reading, please let me know! -- +---------------------------+-------------------------------------------------+ |Jeff Bevis / Purdue EE | Three is never equal to four, except | |bevis@ecn.purdue.edu | for very large values of three... | +---------------------------+-------------------------------------------------+
mcmahan@netcom.COM (Dave Mc Mahan) (05/01/91)
In a previous article, mcmahan@netcom.COM (Dave Mc Mahan) writes: [ Discussion about wanting to build a EPROM programmer and needing chip specs deleted. ] >Data I/O has literally hundreds (if not >thousands) of supported part numbers listed in their books. It would be >especially nice of you to just read the EPROM ID code from a chip and select >the appropriate alogorithm. I don't know why Data I/O doesn't do this >automatically, but they don't. It KNOWS the proper ROM ID code for the >chip in the socket, why don't they just use the right algorithm? I guess >it could be difficult to even select the proper socket (the Data I/O 29B >programmer has 6 or 8 sockets, all different sizes) and read the ID code >without risking damage to the chip, but it would be nice if they could. Well, sports fans, this is another time when I have the honor of following up my own posting. I did a little research on the above paragraph, and found that a Data I/O programmer does indeed have the intelligence to properly program an EPROM if you just stick it in the socket. You don't _HAVE_ to enter the family and pinout code for a new part, which can save you some time looking up the desired value. It turns out that if you enter the family/pinout code of 'FFFF' when asked, the Model 29B programmer (from Data I/O) will correctly find the right socket, figure out what part type is in there, and program it. Just thought you might want to know. > -dave -dave -- Dave McMahan mcmahan@netcom.com {apple,amdahl,claris}!netcom!mcmahan
jclark@sdcc6.ucsd.edu (John Clark) (05/02/91)
In article <1991Apr30.074218.3023@en.ecn.purdue.edu> bevis@en.ecn.purdue.edu (Jeff Bevis) writes:
+
+The book goes on to suggest that the user contact the National Programmable
+Device Support department. Why not just put it in the book? AMD's books
+are just as mysterious. How can they expect a poverty-stricken college
+student like me to build a GAL programmer if the data is not readily
They don't. They have grown use to the type of 'engineer' who after
a minimum number of engineering classes, and a two year stint in the
'technical' side, graduates to an MBA with marketing emphasis. These
types of 'engineers' don't want to know anything more than the
absolute minimum as in where's the stock options, benefit plans and
investment programs, and oh by the way where's the PAL book, the
Boolean Language interpreter, and the programmer,
If I sound cynical it's because I am.
--
John Clark
jclark@ucsd.edujcallen@Encore.COM (Jerry Callen) (05/04/91)
Regarding why PAL/GAL/EPROM programming info isn't in the data books: I suspect it's because a LOT of people want to USE these devices, and only a FEW people want to know how to build PROGRAMMERS for them. My guess is that the programming information is pretty bulky, and it doesn't make sense to increase the size of the manual with information most user's don't want. I'm cynical, too, but in this case I think there is a reasonable explanation. -- Jerry Callen jcallen@encore.com
andreww@uniwa.uwa.oz (Andrew John Williams) (05/04/91)
My Cypress book seems to have enough details to do things with PALs. Or at least their PALs (which are reprogrammable - EPAL?) John West (stealing Andrew's account) How many fish in my modem?