test-drb March 2000

test-drb@ccmp.vtda.org

150 participants
515 discussions

by chris＠mainecoon.com

[Sorry for blasting the list with this, but I've got a logistical nightmare that I'm trying to solve in the next few hours] If anyone knows how to contact Paxton in an expedient fashion (i.e., on the phone) I'd appreciate it if they could do so and tell him to check his mail -- I've just received a call from the trucking company that's supposed to be collecting the 3880 and 3350 that he dug up; their some four hours away and looking for information on where they're supposed to collect the stuff. Again, my apologies for broadcasting this, but I'm kinda desperate just now... -- Chris Kennedy chris(a)mainecoon.com http://www.mainecoon.com PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97

24 years, 9 months

How to Reverse Engineer a Non-Stated Programmable Logic Device Using Stone Knives and Bear Skins

by CLASSICCMP＠trailing-edge.com

Here's part A of my promised document on reverse engineering programmable logic devices. I suspect that it's too technically complex for about 49% of the audience, too technically simplistic for 50% of the audience, and right on target for only about 1% of the audience. Well, that's how the dice fall! I'm sure that my circuit-design techniques will be viciously attacked here too. My emphasis was on using commonly available parts, and even though I happened to use my time-tested favorites, I'm sure some folks will despise me because I happened to stoop as low as using a 555 in a circuit. Please take into account that I know that the hardware I'm using here is primitive (thus the "stone knives and bear skins" in the title) and that I'm very much aiming at circuits that others will learn from and adapt for their own uses. Soon I'll publish part B, computer-assisted scanning, after I get that written up. That will be followed by part C, determining logic equations, and part D, reconstructing an equivalent fuse map. These documents, as they're revised, will be available over the web at http://www.trailing-edge.com/www/reverse-engineer/ -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 How to Reverse Engineer a Non-Stated Programmable Logic Device Using Nothing but Stone Knives and Bear Skins. Revision 0.1 / 3-Mar-2000 Tim Shoppa, shoppa(a)trailing-edge.com INTRODUCTION Computer collectors often come across programmable logic devices (bipolar PROMs, PALs, GALs, etc.) in their hardware. They may want knowledge of the device to improve, customize, or modify it, they may want to know what it is doing purely out of curiosity, or they might want to simply be able to replace device in the future in case of hardware failure. As the original manufacturer of the equipment has almost always disavowed all support and knowledge of the programmed devices, here I tell how you can determine the function of the device, even if it has had (for example) a security fuse blown. ASSUMPTIONS Here I assume the following: 1. The reader of this document has at least a little bit of familiarity with electronics - enough to wire up simple logic circuits on solderless breadboards, and use a logic probe or multimeter, and find pin 1 on an IC. Those who aren't familiar with electronics should start elsewhere for the very basics - I strongly recommend Don Lancaster's _TTL Cookbook_ and Horowitz and Hill's _The Art of Electronics_. 2. The device to be reverse-engineered is easily removed from its circuit for testing. Very often, bipolar PROM's and many PAL's are already socketed for easy removal. While it is undoubtedly possible to apply the techniques I describe here to in-circuit testing, there are complications of in-circuit testing that I'm not ready to discuss in general. 3. The device to be reverse-engineered doesn't have any internal "state". Again, the principles discussed here can also be used with, for example, registered PAL's, but interpreting the results and ensuring that all internal states are exercised is not discussed here. 4. Here I also assume that device being reverse-engineered doesn't have any tri-stated outputs. The techniques discussed here *do* allow for devices which have pins that are fuse-programmable for input only or output only. STEP 1: DETERMININING DEVICE POWER CONNECTIONS For many programmable devices (especially PALs and GALs, and many bipolar PROMs) the Vcc and Ground power connections follow the "standard" TTL conventions - i.e. for a 14 pin device, Vcc is at pin 14, ground is at pin 7. For a 20 pin device, Vcc is at pin 20, ground is at pin 10. usw. Not all programmable devices follow these conventions. Usually some simple testing with an ohmmeter, checking for connection to +5V and Ground at some known IC or connector on the circuit board, will reveal the actual connections. It's vitally important that you are sure about the Vcc and ground connections. IC's don't like having power applied backwards across them. Seeing as how you've already decided that the part in question is worth reverse engineering - probably because it's irreplacable - it's wise to be very careful about this phase. OK, now that we know which pins are Vcc and ground, put the device on your favorite solderless breadboard and apply power. Be sure to bypass Vcc to ground near the device with an appropriate bypass capacitor (say, 0.001 to 0.01 uF). STEP 2: DETERMINING INS AND OUTS If you've got a good logic probe - one that can distinguish a high >from a low from an open circuit - this stage is easy. Just use the logic probe to test each unknown pin - if it's definitely high or low, then it's an output. If it's open circuit or high impedance, it's probably an input. My logic probe is a $7.99 device I bought at a local electronics store many years ago. It detects high, low, and open circuits, and also has a pulse stretcher for making very brief output pulses visible. I recommend that anyone doing anything even remotely related to digital electronics have such a tool. But for those who don't have such a tool, you can use a milliameter to do the equivalent thing. Attach one end of a milliameter to Vcc through a 1K resistor, and scan through all the unknown pins on the device with the other end of the milliameter. If you see a current of 3-5 mA, you've found an output which is low. Now attach one end of the milliameter to ground with a 1K resistor, and scan through the remaining unknown pins with the other end of the milliameter. If you see a current of 2-5 mA on any pin, you've found an output which is high. Any remaining pins that didn't show appreciable current flow through either pass with the milliameter is now known to be an input. STEP 3: SCAN THROUGH ALL THE INPUTS OK, now we fall back on one of my favorite methods of all: Brute Force. Say we started out with a 24-pin device, and found two of the pins to be Vcc and Ground, and found three other pins which tested to be outputs. That leaves 19 pins as inputs. There are 2^19, or about half a million, possible input patterns to this device. That might sound like a lot, but it really isn't - by using our friend, the 74LS93, to scan through the inputs we can scan through this in under a second if we want. The 74LS93 is a 4-bit binary counter. We're going to chain as many as necessary together (in the example above, 5 74LS93's gives us a 20-bit counter, enough to scan through 2^20 or a million input states) to scan our device under test. I bought 5 74LS93's at a local electronic store in a 5-unit "Jim-Pak" for under $3.00. Each 74LS93 stage is wired together according to the following schematic: Qa Qd Clk Qc Qd Out Out Out Out Out ^ ^ ^ ^ ^ | | | | | | | | | | /----------------* *----/ | | | | | | | | Clk | | | | | in | | Gnd | | | ^ | | ^ | | | | | | | | | | | | | | | | | --------------------------------------- | | 14 13 12 11 10 9 8 | | | | | | | | | | | | | | ) 74LS93 | | | | | | | | | | | | | | | | | | 1 2 3 4 5 6 7 | | --------------------------------------- | | | | | | | | | | \------/ \----* v | Vcc v RESET IN Note that the 74LS93 doesn't follow the TTL convention of putting ground in the lower right and Vcc on the upper left! Again, we're dealing with clocked logic here, so to prevent output changes from making power supply glitches that feed into nearby stages it's good practice to bypass Vcc to ground near each IC with a bypass capacitor. To chain the above counters together, run clock out from the first 74LS93 to clock in on the second 74LS93, clock out from the second 74LS93 to clock in on the third 74LS93, etc. The "RESET IN" connection to each counting stage should be tied low for normal counting, and momentarily tied high to reset all the counters. I tied all the reset ins together on my solderless breadboard and hooked them to ground for normal operation. To reset the counters, I move the wire to Vcc briefly and back. STEP 4: NON-COMPUTER ASSISTED SCANNING OK, now we tie Qa-Qd from each counting stage to "input" pins on the device to be scanned. I also like to watch the most significant counting bit cycle, so I hook it (through a 1K or so resistor) to a LED whose anode is hooked to +5V. And we also need a clock to step the counters through all the possible patterns. I used a 555 (again, a part that ought to be available everywhere) to make a simple oscillator: Gnd ^ | | C1 Vcc _____ ^ _____ | | *-- /-- *-----------------\ | \ | \ | Gnd | | /R | /R | ^ | | \1 | \2 | | C2 | | / | / | _____ | | ---* ---* _____ | | | | | | | | | | | /-----------------------------\ | | 8 7 6 5 | | | | | | | | | | | | | | ) 555 | | | | | | | | | | | | | | | | | | 1 2 3 4 | | \-----------------------------/ | | | | | | | | | | | v | | v | Gnd | v Vcc | | Clk | | Out | | | \-----------------------/ C2 is a 0.01 uF capacitor to bypass the threshold divider to ground. It's non-critical, and the circuit will probably work without it. The resistor and capacitor values are noncritical; I happened to use R1=R2=220 ohms, and C1=0.047 uF, to get a clock rate of somewhere around 30 kHz for initial testing. Making C ten times smaller will up the clock rate by a factor of ten; making it ten times larger will slow down the clock rate by a factor of ten. The clock rate you choose will depend on how large of a space you have to scan. OK, now feed Clk Out from the 555 to Clk In on the first 74LS93 stage. With a logic probe, you'll see high-frequency pulses coming out of the first stages of the counter, and on the last stages you'll see the pulse rate divided down by however many stages of divide-by-2 you have wired in. If you've wired a LED to the most significant bit, you'll see it cycle on-off-on as you go through all the possible binary output patterns. Now move the logic probe to an output of the programmable device. With any luck, you'll see output pulses here flashing in a repeating cycle that coincides with the MSB LED hooked to the last counter stage. STEP 5: DETERMINING WHICH INPUTS GIVE INTERESTING OUTPUTS OK, now suppose that our logic probe has told us that the output from our PAL under test is "high" almost all the time, but goes low only a few times per input cycle. If the PAL was used as an address decoder - as many of the ones I deal with are used - then this is a very likely case. So to find the input that causes the output to go low, we gate the clock signal from the 555 with the PAL output through a NAND gate. When the PAL output goes low, the clock pulses will no longer be applied to the counter, and the counters will stop at the input which caused the PAL output to go low. (1/4 of a 74LS00 NAND) |------- Clk out from 555 ---------------| ) | )O------- Clk in to first 74LS93 Out from PAL ---------------| ) |------- When the counters stop, just use a logic probe to read off the logic states that produce the interesting "input" state. To continue scanning, momentarily lift the "out from PAL" signal from the 74LS00. This input will float high, and the counters will start scanning again. If you suspect that there might be other "PAL output low" combinations, it may be worthwhile to slow down or stop the 555 clock signal while you momentarily lift the "out from PAL" signal. For this purpose, I keep a largish electrolytic around to plug in parallel across the the capacitor that sets the 555 time constant. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

24 years, 9 months

PDP-11/55s avail

by oliv555＠arrl.net

Got a message at work about four 11/55s available due to an upgrade. These are not freebies, in fact they are asking some big $$$ and come with the expensive Fastbus bipolar memory. I did not get permission to repost so if your site has need for these contact me off-list and I will provide the contact info. Nick

24 years, 9 months

Early Mac Clones

by healyzh＠aracnet.com

While trying to dig up some info on some Mac hardware, I ran across the following web page of early mac clones (over 10 years old). Some interesting stuff there. http://lowendmac.net/firstclones.shtml Unitron Mac512, circa 1985 McMobile, 1986-89 Outbound Laptop, Portable, 1989-91 Atari ST & Magic Sac Colby WalkMac, circa 1989 Dynamac, 1988-89 Zane | Zane H. Healy | UNIX Systems Adminstrator | | healyzh(a)aracnet.com (primary) | Linux Enthusiast | | healyzh(a)holonet.net (alternate) | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

24 years, 9 months

decayed capstan in Archive QIC

by edick＠idcomm.com

Tough it can require some disassembly, another trick might be to apply 'SILASTIC' to the metal post which supports the roller and to which it's fastened. It takes a bit more patience, but less force, and, once cured, the 'SILASTIC' can be worked with a DREMEL tool to reduce its diameter or to shape it as needed. I made a couple of these in a lathe and ground them true and flat with a toolpost grinder. You can even make a capstan that way, since the stuff is really quite hard when cured, yet more forgiving than other materials often used in these drives. Silastic is not particularly prone to creep or abrade and it's quite inert, chemically. If the temperature varies much, there will be a bit of dimensional change, so try to measure it when it's at nominally room temperature. Dick -----Original Message----- From: Technoid(a)cheta.net <Technoid(a)cheta.net> To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org> Date: Wednesday, March 01, 2000 7:15 PM Subject: Re: decayed capstan in Archive QIC >I fixed my qic tape drive this way: > >Open the drive and scrape away the goo that used to be what I called the >drive bogy from the shaft it is on. > >Find a roller from a printer. I used an output roller from my Epson >Actionprinter 3250. The inside diameter is MUCH smaller than the drive's >driveshaft. Don't worry. Cut the length of the replacement roller to the >correct length or it will cause the drive to bind and that is not good. > >Take a ballpoint pen of the kind you can remove the business end from. I >used a cheap, non retractable bic. I streached the roller over the body >of the pen using the nose of the pen as a starter beacuse the diameter of >the roller is so tiny. Once you get the roller past the removable end and >it is fully on the body of the pen, remove the nose from the pen. > >Clean the drive's driveshaft with alcohol or fingernail polish remover to >remove any traces of the old gooey roller. Fingernail polish remover is >great stuff for dissolving the rubber goo but remember that they put stuff >in it to make it 'good for you' like vitamin E. Clean the shaft >thoroughly with alcohol after useing the remover or if you are more >organized than I am, you will have some ACETONE around which is the same >thing without the gook added. > >Place the now blunt end of the pen against the face of the driveshaft and >slide the streached roller onto the shaft. Once it is on, check to make >sure it is of the correct width so as not to contact the case of the tape >or the tape its'self. it should only contact the drive bogey on the tape >when the tape is inserted in the drive. > >You are done and the roller will last at least months as mine has if not >for years. > >Good luck. This took me about two hours to conceive of and accomplish and >my Data General 6311 tape drive has had many many happy hours of >shoeshining tapes without fail since. My drive is a bit larger than most >of the little qic (DC2000 type) drives but I was scoping those drives for >a replacement roller and noticed that the bogeys are about the same size >on all of them. > >Technoid Mutant at your service > >-- >----------------------------------------------------------- >Jeffrey S. Worley >Technical Services >Bits & Bytes Computer Services Inc. >1979B Hendersonville Road >Asheville, NC 28803 >828-684-8953 - voice 0900-1700 five days >828-687-9284 - 24hr fax >Who is General Failure and why is he reading my hard disk? >Technoid(a)Cheta.net >----------------------------------------------------------- >

24 years, 9 months

All Cipher F880 Docs online

by af-list＠wfi-inc.com

Ok, I got the rest of these done today (schematics and engineering drawings). I experimented with many combos of resolution/bit-depth, and the best quality with a managable size ended up being 300dpi/8-bit greyscale/PDF format/JPEG compression. I think they average around 3megs each for 11" x 17" pages. This was the only format that would pick up things like component numbers on schematics/etc. Everything is available at www.retrobytes.org. BTW, if anyone has any suggestions on a better format for these, I'd be happy to try something else! But until then, the quality looks great to me... Cheers, Aaron

24 years, 9 months

Reverse-engineering for the computer collector

by pete＠dunnington.u-net.com

On Mar 2, 16:19, Tim Shoppa wrote: > I've recently put some effort into reverse engineering several > PAL's and other (slightly) more complex programmable logic devices > that have had their security fuse blown. Would folks here be > interested in a general summary of the methods, pointers to > tools and hardware, etc? I certainly would -- I have a couple of small PALs to make backups of, and whilst I could design some gubbins to read them, this would save me some time and effort. And of course give me the incentive to get off my butt and do something about them :-) -- Pete Peter Turnbull Dept. of Computer Science University of York

24 years, 9 months

Reverse-engineering for the computer collector

by CLASSICCMP＠trailing-edge.com

I've recently put some effort into reverse engineering several PAL's and other (slightly) more complex programmable logic devices that have had their security fuse blown. Would folks here be interested in a general summary of the methods, pointers to tools and hardware, etc? This *isn't* rocket science, and it isn't putting the device in the output end of a particle accelerator either :-). What I've done here so far involves simple scanning circuits constructed from common-as-dirt parts, and software to process the results of the scans. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

24 years, 9 months

teletype photos wanted

by CLASSICCMP＠trailing-edge.com

>ASCII models (realize that hams weren't allowed to use ASCII over the >air until sometime in the 1980's). Before anyone corrects me, I now realize that I should've said "US hams" :-) Tim.

24 years, 9 months

teletype photos wanted

by CLASSICCMP＠trailing-edge.com

>But it would still be nice to find a collection of photos of teletypes. >And for that matter, Flexowriters, Creeds, DECwriters, etc. The ARRL used to have a book that dealt with RTTY equipment. I believe the title was something along the lines of "Special Communications Techniques for the Radio Amateur". The 1960's and 1970's editions of this book had good info on the various Teletype and Creed machines, specifically on the Baudot models, and also some information on the ASCII models (realize that hams weren't allowed to use ASCII over the air until sometime in the 1980's). The pictures weren't top-notch (they were generally pretty poor halftones) but there were some. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

24 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb March 2000