test-drb March 2000

test-drb@ccmp.vtda.org

150 participants
515 discussions

by ethan_dicks＠yahoo.com

--- Mark Gregory <mgregory(a)vantageresearch.com> wrote: > One notable emulator/clone they missed was the Amax by ReadySoft for the > Amiga. It was a slim grey box that contained sockets for the Mac 512K ROMs And available later as an internal board with the same ROM sockets, a pair of 34-pin connectors and external mini-DIN connectors. The 34-pin connectors were there to place the A-Max-II+ board between the floppy drive and the motherboard, allowing the Amiga's internal floppy to read/write 800K Mac disks. The mini-DIN connectors were for LocalTalk. I still use my A-3000 bought in 1990 to run M$ Word under A-Max and then print via LocalTalk to my HP LJ/4ML. It works great as a turbo B&W Mac. > I believe it was fairly successful - it went through at least 4 hardware > versions that I'm aware of, ending with the Amax IV. I only have the "A-Max II+". The IV had an upgraded PAL (security bit blown, unfortunately; I checked) and new software. > I was an early purchaser, and I always enjoyed showing off my Amiga with > DeluxePaint II open in one window, WordPerfect for DOS in another window (I > had an XT bridgeboard), and the Mac desktop in a third window. > The best of all worlds, almost. I had one way back, too. I used to use Mac System 3.5 with it. There's another Amiga-based Mac implementation: Shapeshifter. It is software only. I sent the author a Zilog data book so he could support the A-MaxII+ card (Z8530, just like the Mac and old Suns, a *great* serial chip if you knew about its register access time limitations). My favorite demonstration with Shapeshifter was to fire off System 7 on the Mac side, connect up to a nearby Mac server and mount a share, switch back to the Amiga side, open up AMosaic and browse the web while copying files on the Mac. For an added touch, since there is no Netscape browser for AmigaDOS, shut down the TCP/IP stack on the Amiga side, then launch Netscape for the Mac. Those who saw the demo were usually stunned. This was all on a 25Mhz 68030 w/18Mb RAM (16Mb "FAST", 2Mb "CHIP" (kinda like video RAM but more versatile)) Most recently, I took a CD of several hundred Apple QuickTake 150 pictures that I shot over several months in Antarctica. My extensive research showed that there was no way with UNIX or Windows to convert these files to any other format. They are "Quicktime Compressed PICTs". The PBM utilities can parse them, but they get to the meat of the picture and declare that there is an unknown tag and skip the picture data. Anyway, I needed a Mac running the QuickTake 150 extensions to interpret these 1200 pictures. My fastest real Mac was a Mac SE/30. Running Picture Convert, it was 20-30 seconds to load an image and save it as a compressed TIFF; fortunately, there's a batch mode. Some of the pictures had developed bit rot, 10 in all. I couldn't just fire it off and go to bed; I had to supervise the batch. I loaded the stuff all up on to a 4Gb SCSI disk, hung it off my A4000 (25Mhz 68040) and ran ShapeShifter. It was now more like 5 seconds per picture, thus, my fastest Mac was really an Amiga. Last month when I picked up the MacIIci for $5, I passed on a Quadra 605 for $25 because it had no Ethernet and was only a 25Mhz 68040. I figured I already had that much and there was no reason to clutter up with one more box. I think, eventually, when the University surpluses something faster, I'll upgrade, but for now, the Amiga reigns supreme amongst my Mac collection. For me, it wasn't just being able to run Mac programs that was great; it was running them in a networked environment that was really awesome. -ethan ===== Infinet has been sold. The domain goes away on 15 March. See http://www.infinet.com/ for details. Please update your address lists to reflect my new address: erd(a)iname.com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

24 years, 9 months

Stone Knives and Bear Skins

by CLASSICCMP＠trailing-edge.com

If anyone has a .GIF or .JPG of Spock in _The City on the Edge of Forever_ constructing a "primitive mnemonic memory device" from what he terms as "stone knives and bear skins", I'd love to have that to put on my reverse-engineering web page. None of my reverse-engineering aids yet involve a Jacob's ladder or a 3-foot-long breadboard (back when they were really wood!) filled with glowing tubes, but the idea is so appealing that I might try :-). I suspect that for many of us who grew up watching Star Trek, *nothing* is as cool as Spock or Scotty working on a circuit that's throwing sparks. -- 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

Early Mac Clones

by owad＠applefritter.com

>One interesting thing about the Outbound, IIRC, was that not only >was it introduced before the Portable came out, but it was way >better than the Portable. So much better that Apple, who >apparently hadn't quite agreed to license the rom's, gave them a >choice: either you give us your computer, or we sue the pants off of >you and we'll get it anyway. > >The Outbound then became the PowerBook. Might as well let >someone else do your R&D for you..... That story is new to me, and rather contradicts what I've heard. The Outbounds were completely legal, and I don't believe Apple ever attempted to sue them. Outbound was still around when the Powerbooks came out, and from what I've read, its the _competition_ that drove them out of business. With Apple making cost-effective laptops, it was no longer economical to buy a clone and Mac ROMs. The Outbound Notebook uses IDE hard drives and camcorder batteries and really doesn't come across at all like the Powerbook 1xx. You can find additional pictures and information at: http://www.applefritter.com/macclones/outbound/laptop/ http://www.applefritter.com/macclones/outbound/notebook/ And information on Mac clones in general at: http://www.applefritter.com/macclones/ Tom Owad ------------------------------Applefritter------------------------------ Apple Prototypes, Clones, & Hacks - The obscure, unusual, & exceptional. ---------------------<http://www.applefritter.com/>---------------------

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

>This looks like it could be quite helpful in demysifying a decoder. >However, not all devices have negative-going enables and it leaves a gap >there. In a PAL it would be just as easy to use to create a decoder that >uses positive enables, e.g. as found on 6821's and the like. This isn't >common but I've run into it just in the last couple of weeks. Thanks, the next edition of "part A" will note that if the PAL output is the other polarity, you want to invert it before using it to gate the oscillator. >On most of the "old" bipolar PALs, pin 11 was used as the global output >enable, since most of the 16 and 20 input 20 and 24-pin PALs were capable of >generating tristate outputs on every macrocell. The easy way to test for >these is to use a weak pullup, driven by a single driver, together with an >equally weak pull-down resistor array. This can be the same one if your >resistor is on the order of 20K. When your device-under-test is disabled, >it should follow the signal driving the resistors. Monitoring this requires >you use no TTL in the monitoring circuit, since its inputs source current >and will drive up an output. Tri-stated outputs will be covered in an addendum at some point. I think I've been pretty plain that *my* first priority was reverse-engineering some address decoder PAL's, so I didn't have to worry about this the first time around. >One other thing that could stand to be circumvented is that the 'LS93 is a >ripple counter which, with PAL speeds as high as they are, could generate >internal glitches long enough set or clear a latch (normally implemented as >a combinatorial loop in an 'L8 or the like). True. I've noticed no such ripple glitches in my breadboarded circuits with 5 LS93's, but I'm certain you're right and that at the nanosecond level that they're there. >That might warrant the use of a synchronous counter at least in newly built >devices. For a synchronous counter I like the 'LS590 because it's an 8-bit >counter and has an extra internal register to which the count can be Good recommendation, but the LS590 isn't quite as available as the 74LS93. Ready availability of parts is vital to the "stone knives and bearskins" mindset I'm adopting here. >Also, for newly built devices, it's about as easy as anything to use a CMOS >Schmidt trigger, e.g. 74HC132 as an oscillator. You need merely put about a >1 MEG pot in feedback across the device, with inputs tied together to form >an inverter, and hang a capacitor, say, 0.01 or 0.1, or whatever else is >handy, and then tweak he pot to set the frequency. That way you don't have >to admit you have used a 555. Again in my neck of the woods 555's are more available, certainly there are lots of other ways to make clock pulses too. Many of the deglitching concerns of yours will be addressed with Part B, which discusses a simple computer interface for scanning. The computer simply waits a few hundred nanoseconds while between sending a clock pulse and looking at the PAL output. -- 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

Update to Cipher Docs

by af-list＠wfi-inc.com

Due to a few requests, I've posted PDF (Adobe Acrobat) files along side the TIFF files for the Cipher F880 docs. Enjoy! Aaron

24 years, 9 months

Stone Knives and Bear Skins

by bill_r＠inetnebr.com

Psssst... http://kcohn.simplenet.com/alidarjarok/originalseries/thecityontheedgeoffore ver/index2.html >If anyone has a .GIF or .JPG of Spock in _The City on the Edge of >Forever_ constructing a "primitive mnemonic memory device" from what >he terms as "stone knives and bear skins", I'd love to have that >to put on my reverse-engineering web page. > >None of my reverse-engineering aids yet involve a Jacob's ladder or >a 3-foot-long breadboard (back when they were really wood!) filled with >glowing tubes, but the idea is so appealing that I might try :-). > >I suspect that for many of us who grew up watching Star Trek, *nothing* >is as cool as Spock or Scotty working on a circuit that's throwing >sparks. > >-- > 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 > > Bill Richman http://incolor.inetnebr.com/bill_r (Home of the COSMAC Elf microcomputer simulator!)

24 years, 9 months

RE Paxton - Anything heavy need to go to CA today from PDX

by Innfogra＠aol.com

Hi; I made connections. We arranging a rescue of a good IBM 3880 & 3350. They are going to CA today by truck. Does anyone in the PDX area have anything heavy that needs to go to CA. There is room on the truck. It is in Seattle at the moment. Thanks. Paxton

24 years, 9 months

teletype photos wanted

by eric＠brouhaha.com

Someone recently emailed asking me for help identifying a teletype, but unfortunately didn't supply any useful information. I thought maybe I could find some photos online, but ask.com and google didn't turn up anything. Has anyone seen an online collection of photos? I'm sure there are some good ASR-33 photos somewhere, but ideally it would be nice to find photos of other models as well. Thanks! Eric

24 years, 9 months

Early Mac Clones

by ethan_dicks＠yahoo.com

--- Aaron Christopher Finney <af-list(a)wfi-inc.com> wrote: > > > On Fri, 3 Mar 2000, Ethan Dicks wrote: > > > Last month when I picked up the MacIIci for $5... > > There's a guy at TRW sometimes with MacII's for $5...as-is, obviously. > I'd be happy to pick one up for you, if you're interested at all. I > grabbed one a few months ago that had an 8*24GC card and an Asante NIC in > it. All said and done, $20 landed me a IIfx (40mhz/68030) that does > 1280x1024 in 16bit mode. Thanks, but no need. My $5 IIci was similarly equipped. Even though it's a tad slower than a IIfx, I prefer the IIci because it uses ordinary 30-pin SIMMs (I pulled out the 8Mb and dropped in 32Mb for playing with my pictures in their native enviroment in preparation for cutting some Mac HFS CD-ROMs for long-term backup). Another bit of fun is that I'm using a Linux box as an Appleshare File Server. It even mounts and shares HFS CD-ROMs. No magic - just the netatalk package, follow the directions and share away! -ethan ===== Infinet has been sold. The domain goes away on 15 March. See http://www.infinet.com/ for details. Please update your address lists to reflect my new address: erd(a)iname.com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

24 years, 9 months

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

by edick＠idcomm.com

This looks like it could be quite helpful in demysifying a decoder. However, not all devices have negative-going enables and it leaves a gap there. In a PAL it would be just as easy to use to create a decoder that uses positive enables, e.g. as found on 6821's and the like. This isn't common but I've run into it just in the last couple of weeks. On most of the "old" bipolar PALs, pin 11 was used as the global output enable, since most of the 16 and 20 input 20 and 24-pin PALs were capable of generating tristate outputs on every macrocell. The easy way to test for these is to use a weak pullup, driven by a single driver, together with an equally weak pull-down resistor array. This can be the same one if your resistor is on the order of 20K. When your device-under-test is disabled, it should follow the signal driving the resistors. Monitoring this requires you use no TTL in the monitoring circuit, since its inputs source current and will drive up an output. One other thing that could stand to be circumvented is that the 'LS93 is a ripple counter which, with PAL speeds as high as they are, could generate internal glitches long enough set or clear a latch (normally implemented as a combinatorial loop in an 'L8 or the like). That might warrant the use of a synchronous counter at least in newly built devices. For a synchronous counter I like the 'LS590 because it's an 8-bit counter and has an extra internal register to which the count can be transferred in parallel, thereby eliminating risk of all but the shortest output glitches. If you concatenate, say, three of these, their output registers can be clocked from the complement of the counter clock. That way they are out of phase with the count clock, hence will not generate internal races which could result in incorrectly latched data. Also, for newly built devices, it's about as easy as anything to use a CMOS Schmidt trigger, e.g. 74HC132 as an oscillator. You need merely put about a 1 MEG pot in feedback across the device, with inputs tied together to form an inverter, and hang a capacitor, say, 0.01 or 0.1, or whatever else is handy, and then tweak he pot to set the frequency. That way you don't have to admit you have used a 555. These measures should result in less wiring effort for the cases where a new gadget is being built. Just my $.02's worth . . . Dick -----Original Message----- From: CLASSICCMP(a)trailing-edge.com <CLASSICCMP(a)trailing-edge.com> To: CLASSICCMP(a)classiccmp.org <CLASSICCMP(a)classiccmp.org> Date: Friday, March 03, 2000 10:12 AM Subject: How to Reverse Engineer a Non-Stated Programmable Logic Device Using Stone Knives and Bear Skins >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

← Newer
1
...
45
46
47
48
49
50
51
52
Older →

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