DIY_EFI Digest Monday, 25 January 1999 Volume 04 : Number 058 In this issue: Re: PROMs and Copyrights... Re: Resolution. Re: DFI, Batch Fire, and other myths Re: PROMs and Copyrights... Re: PROMs and Copyrights... Re: Resolution. Re: EFI questions Delco calibration Re: PROMs and Copyrights... Wireing advice RE: PROMs and Copyrights... Some more Holden Memcals Re: PROMs and Copyrights... Re: DFI, Batch Fire, and other myths RE: dual spray injectors See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- From: bearbvd@xxx.net (Greg Hermann) Date: Sun, 24 Jan 1999 20:18:16 -0700 Subject: Re: PROMs and Copyrights... >> >>As far as copyright is concerned, my guess (IANAL etc.) is that >>it is technically illegal to sell a chip containing modified GM >>code - it would be a derivative work. Just changing a few bytes >>or tables isn't sufficient... Somewhere in a memory bank is the number 10%--if you change that much, it's considered yours. Can't remember where that came from, tho. > >But I've looked at an ADS chip for an '88 Z24 (P4) compared to the ATZA OEM >chip and they really did not change a whole lot of stuff yet they sell >(sold?) the thing for quite a tidy sum. Apparently, GM saw no reason to >intercede... > >>However, GM would be hard pressed to prove any actual damages. After all, >>you need their hardware to run the code! BINGO! No damages=No money=No lawyers! And yes, that summarizes my opinion of MOST lawyers. Our British colleagues have their collective character pretty well nailed what with calling a bunch of them "Solicitors"!!! Plus--if you wanna talk about the ultimate case of theft of intellectual property, and how far it got in court, take a look at Apple v. Macrosquish over Windoze. And this is one where the court or jurors could actually understand what they were looking at--not a bunch of 1's and 0's!! >>> >>Now if someone was to sell their own hardware with GM code, I >>would expect GM to stop them. >> > >Looking at traditional GM code, I'd say that for that hardware to work with >GM PROMs, it'd have to be designed pretty-much trace-for-trace the same as >the GM ECM since the code is so deeply integrated with the hardware, which >certainly would be grounds for an "Ahem...what do you think you're doing?" >letter. A bunch of folks tried a similar approach with proprietary hardware, code, communications protocols, etc. in the digital building controls industry. There was some outright robbery going on in terms of parts, system expansion, and service pricing once a building owner/property manager got committed to one control hardware mfgr. Through trade organizations (like BOMA) and with the help of design professionals, who learned to write smarter specs, this general practice is nearly whipped into submission at this time--open protocols, etc. are becoming the norm very rapidly in the building controls industry. What it is gonna take to straighten this $#% out in the auto industry is a few big fleet buyers (hertz-Avis-Budget-Penske-etc.) getting collectively smart and saying "ENOUGH OF THIS #$&*$#% !!!! We insist on open protocols, etc.!! First one to do it is the one who will sell us all of our vehicles!!" OBDII is likely , in no small part, the direct result of these kinda folks collectively lobbying in DC, and reaching a compromise with the GEEKS so as to continue to foil the hot rodders!! > > Regards, Greg ------------------------------ From: bearbvd@xxx.net (Greg Hermann) Date: Sun, 24 Jan 1999 20:44:04 -0700 Subject: Re: Resolution. >Hi ! >Seeking a good solution to high powered streetable engines......some >questions pops up.... >Where is the weak link in the Efi system when it comes to resolution? >MAP SENSOR: Going from 1 to 2bar halfs the resolution....3bar even worse. >Is staging map sensors a posibility? >0 to 5 volts : how acurate can the ecm measure the input from the >sensors? >Is 0 to 10 v better? or frequensy? >ECM: Computers ability . There are plenty of instrument grade pressure transducers available, Ashcroft, for one, with 0.25% full scale accuracy and better repeatability than that, All you gotta do is know which counter to ask for them at, and be prepared to pay for them. Your choice of 0-5V, 0-10V, or 4-20 ma output signal. 4-20 ma is most popular signal output for industrial instrumentation because of wiring open/short failures being so easily detected with it. Similar accuracy/quality/choice is readily available in any of the other sensors commonly used in an efi system. Cost/performance ratio is the only question as to sensors. No question that a high horsepower engine needs more "turndown ratio" than a stocker to be decently streetable, and that higher turndown ratios require more accurate input data, and that the auto mfgrs are not bloody likely to spend the money required to be any more accurate than they need to be in order to meet emissions regs with an average HP engine!! Real questions here are :"How many bits wide are the A/D converters in the ecu?" and "How many mapping points does the load/rpm matrix need to contain?" and "How many bits wide is the fuel rate calculation (and tables) in the ecu?" and ""What is the minimum time increment to injector pw which the ecu will implement?" and "How many bits wide does everything need to be in order to obtain the desired level of turndown to give your high HP engine decent street manners?" Staging injectors, and rising rate fuel pressure control are certainly a help, particularly if there are fuel rail pressure and temp inputs to the ecu for fuel rate corrections on the fly! Regards, Greg ------------------------------ From: bearbvd@xxx.net (Greg Hermann) Date: Sun, 24 Jan 1999 20:50:06 -0700 Subject: Re: DFI, Batch Fire, and other myths > >Was just thinking yesterday that the switch pitch converter should be >connected to tcc control , and detent solenoid should remain manual >control. BTW, 350 Buick HEI works, but must use drive gear from 455 >points dizzy. Ahh--dangerous thoughts, and hardware that gets forgotten--Anybody know of any experience racing with switch pitch TH-400's???? Or whether such an idea ever got tried with turbo motors??? :-) (Like switching the pitch to let it rev up into the boost QUICKLY???) Regards, Greg > >Shannen ------------------------------ From: bearbvd@xxx.net (Greg Hermann) Date: Sun, 24 Jan 1999 20:54:51 -0700 Subject: Re: PROMs and Copyrights... >On Sun, 24 Jan 1999, Dave Williams wrote: > >> >> By US law copying, modifying, and reselling code is a Federal crime. >> Several states also have anti-hacking and anti-piracy laws that cover >> this. >> >> Hypertech and others get away with their practices because the OEMs >> have chosen, for whatever reasons, not to take them to court. There >> aren't any Copyright Police looking around for violations; GM or Ford or >> whoever has to set the ball rolling. >> >> Just because Hypertech and others are not being prosecuted doesn't make >> what they're doing legal - all any OEM would have to do is file, and it >> would an open-and-shut rubber stamp trial. There are ample precedents >> on the subject of piracy of ROM code - IBM, Apple, and Phoenix BIOS all >> filed suit against code pirates and won. >> > >There is a additional issue here. IBM, Apple, and all of them the >others were copying and putting someone elses prom with their own >hardware. I don't think IBM or Apple would have messed with someone >taking one of their proms changing it and reselling it so long as 1 >IBM or Apple prom was bought for each one sold, ie a license for the >original code. And each piece of GM hardware you would suppose would >have one license to run the GM code included with it. Now if one of >the aftermarket companies made their own computer (or copyied someone >elses) and were making those and selling them with GM (or someome >elses code) then things would be pretty clear. The derivative work >works so long as the person making the derivative has the proper >number of licesnes for all of his derivatives sold. In most of the >aftermarket prom business that is the case. > Yep--what the chip makers are doing is a much closer analogy to what the writer of a system extension or patch is doing than to theft. Simply changing the way something runs from the original. Regards, Greg ------------------------------ From: Orin Eman Date: Sun, 24 Jan 1999 20:00:29 -0800 (PST) Subject: Re: PROMs and Copyrights... > Mike wrote: > The bigger question on copying and modifying the OEM code is who out > here does emissions testing on the final results? The OEM's spend huge > $$$ on testing and I suspect are on the hook for any changes that effect > emissions. Do any aftermarket tuners who make PROM changes recertify > the cars or even test for emissions? Well, Intended Acceleration has CARB approval for some of their 'modifications'. What this actually involves is a different matter... Orin. ------------------------------ From: "Bruce Plecan" Date: Sun, 24 Jan 1999 23:18:29 -0500 Subject: Re: Resolution. But, but, what about the filtering?. Doesn't that fly in the face of needing absolutely accurate MAP sensing?. **Notice the question mark, I'm asking. This "filtering" is a funny animal, in so far as using larger ID/ loner sensor lines can make a vast difference on some applications, and I've always had better response with smaller shorter lines. Bruce more accurate input >data, and that the auto mfgrs are not bloody likely to spend the money >required to be any more accurate than they need to be in order to meet >emissions regs with an average HP engine!! > >Real questions here are :"How many bits wide are the A/D converters in the >ecu?" and "How many mapping points does the load/rpm matrix need to >contain?" and "How many bits wide is the fuel rate calculation (and tables) >in the ecu?" and ""What is the minimum time increment to injector pw which >the ecu will implement?" and "How many bits wide does everything need to be >in order to obtain the desired level of turndown to give your high HP >engine decent street manners?" > >Staging injectors, and rising rate fuel pressure control are certainly a >help, particularly if there are fuel rail pressure and temp inputs to the >ecu for fuel rate corrections on the fly! > >Regards, Greg > > ------------------------------ From: "Bruce Plecan" Date: Sun, 24 Jan 1999 23:29:24 -0500 Subject: Re: EFI questions - -----Original Message----- From: dzorde To: diy_efi@xxx.edu> Date: Sunday, January 24, 1999 10:15 PM Subject: EFI questions When in doubt read the spark plugs. AV can look lean, but the signs of detonation are always present, from what I've seen. Now, I'll fully admit, it's been years since doing much AV gas reading. Try a load of good racing gas if you have trouble reading the AV stuff. And I've got zero time reading australian AV Gas. Pipe coloring is dead in my book. Bruce >Hi everyone, > >Been a while since I've had any questions so here goes. Finally got around >to fitting an O2 sensor to my car (can say that on avgas it still works >after 20+ hrs of operation). This car has a Wolf 3D running the engine >using MAP, TPS and associated temp sensors. > >Anyway my car has always been running with bright white tail pipes, hence I >figured it was lean. With the O2 I have found something I can't explain. >The O2 is always around 0.82V going to 0.9V+ when accelerating (seems very >rich), however car runs beautifully. If you lean of the fuel maps to reduce >the O2 readings the car just won't run, seems like complete fuel starvation >as soon as you touch the accelerator (even tried hardwiring the heated O2 >shell to the -ve battery terminal to ensure the voltage wasn't floating or >anything stupid). Why can the car only run when rich (had it on a real gas >analyser and it said very rich as well) ? Is it the high compression 12.8:1 >(or so) ? > >Another question, because the system is speed density, when you back of the >accelerator the engine unloads and picks fuel delivery for its new suited >map point (lower load range) causing the O2 to read almost 0V (very lean). >Is this normal for a speed density system ? It seems correct to me as the >injection is based on looking up a base value in the map, but it doesn't >seem very healthy for the engine to lean of everytime you back of. I have >been thinking this could be why I have white tailpipes as the car is >spending most of its time on and off the gas when racing. > >Lots of questions, but this one has me puzzled. > >rgds > >Dan dzorde@xxx.au > ------------------------------ From: "Thomas Matthews" Date: Sun, 24 Jan 1999 23:36:23 -0500 Subject: Delco calibration Can anyone look up the calibration APYU out of an 89 Formula 350? I'm wondering if it's current, and does anyone have a PN so I could order another CALPAC from GM? Anyone know what the 89 305 5 speed CALPAC GM part number is? TIA, Tom ------------------------------ From: trinity@xxx.net (Mike) Date: Sun, 24 Jan 1999 23:41:45 -0500 Subject: Re: PROMs and Copyrights... <*snip*> >>Looking at traditional GM code, I'd say that for that hardware to work with >>GM PROMs, it'd have to be designed pretty-much trace-for-trace the same as >>the GM ECM since the code is so deeply integrated with the hardware, which >>certainly would be grounds for an "Ahem...what do you think you're doing?" >>letter. > >A bunch of folks tried a similar approach with proprietary hardware, code, >communications protocols, etc. in the digital building controls industry. >There was some outright robbery going on in terms of parts, system >expansion, and service pricing once a building owner/property manager got >committed to one control hardware mfgr. > >Through trade organizations (like BOMA) and with the help of design >professionals, who learned to write smarter specs, this general practice is >nearly whipped into submission at this time--open protocols, etc. are >becoming the norm very rapidly in the building controls industry. > >What it is gonna take to straighten this $#% out in the auto industry is a >few big fleet buyers (hertz-Avis-Budget-Penske-etc.) getting collectively >smart and saying "ENOUGH OF THIS #$&*$#% !!!! We insist on open protocols, >etc.!! First one to do it is the one who will sell us all of our >vehicles!!" > "Open protocols" in what sense? OBD-II went a long way toward standardization of extra-vehicular communication but even then they couldn't get their shit together enough to give us a true "standard": we're stuck with 16-pin OBD-II plugs with no less than 3 possible types of communications interface (ISO, VPW and PWM at two possible rates fercrissakes...) An OBD-II scanner that works on GM cars may not work on Ford cars. I suppose it's not a true OBD-II scanner then... I think I sense the thread drifting slightly off course from the spirit of my original query so I'll restate it now that I've seen several learned responses that gave me a bit of insight and direction: How does copyright law affect us, as geeks, nerds, white-hat-hackers, hobbiests and general gear-heads (or whatever you want to call us) insofar as: - - making a copy of a PROM image in ones own car or from a PCM/ECM in ones possession - - uploading said PROM image to, say, the imcoming directory - - downloading any image from the incoming directory - - reverse engineering an image obtained either by reading a PROM or downloading it - - publishing in the public domain, free of charge, findings of that reverse engineering (for example, "Change byte at 81F4 to remove the speed limiter" or "The byte at 81F4 describes the maximum TPS voltage before such and such a code is set") For now, I'll assume we as list members are in it for the "educational" or otherwise "personal" uses and not for profit. I've seen arguments on both sides (i.e. both "It's all okay" and "It's all illegal"), all of which are convincing in their own way. So I'm guessing it's safe to assume that there's some level of illegality involved in what 99% of us are doing but that since we aren't making money at it, we are generally doing it for personal and/or educational purposes and we are, after all, pretty small potatoes when it comes to threatening the industrial complexes of Ford, GM, Nippon-Denso, Mazda et al, we are probably at zero risk of raising the ire of the manufacturers. Sounds reasonable right? - -- Mike ------------------------------ From: ChvyRs92@xxx.com Date: Sun, 24 Jan 1999 23:52:31 EST Subject: Wireing advice Quick question. Does anyone know if there are any companies out there that would re-pin a bulkhead connector for one 92 chevy to another? I have the schematics for both cars, but I have only been able to figure out about 2/3 of it and I really can't say that I am absolutely certain that what I think I have is right? Thanks, Jeff ------------------------------ From: "Jennifer and Brock Fraser" Date: Sun, 24 Jan 1999 23:19:19 -0600 Subject: RE: PROMs and Copyrights... > By US law copying, modifying, and reselling code is a Federal crime. >Several states also have anti-hacking and anti-piracy laws that cover >this. > > Hypertech and others get away with their practices because the OEMs >have chosen, for whatever reasons, not to take them to court. There >aren't any Copyright Police looking around for violations; GM or Ford or >whoever has to set the ball rolling. > > Just because Hypertech and others are not being prosecuted doesn't make >what they're doing legal - all any OEM would have to do is file, and it >would an open-and-shut rubber stamp trial. There are ample precedents >on the subject of piracy of ROM code - IBM, Apple, and Phoenix BIOS all >filed suit against code pirates and won. > > I've discussed this subject with several chip vendors, who all seem to >engage in the same kind of wishful thinking as Hypertech. Interesting viewpoint. I'm not still in contact with the Hypertech owner, so I can't confirm further, but I'm just repeating what he told me a few years ago when I asked these very same questions. Who knows, maybe he's paying the lawyer $250 an hour just to tell him what he WANTS to hear. haha Considering the millions he has invested in the business, I'd say that he has a pretty good handle on what his liability is. I don't have any more confirmation, but this was a revisited issue when the Power Programmers were designed for the reprogrammable applications... Maybe the IBM, Apple, and Phoenix "hacking" examples are issues of lost revenues? GM doesn't lose any business when Hypertech sells a chip, and maybe that's the key destinction. I think we are digressing a bit from the original question. The point is, legal or not, if Hypertech can stay open for business for 12+ years, it's safe to assume that the average Joe can post binary data and interpretations on his web site. >The bigger question on copying and modifying the OEM code is who out >here does emissions testing on the final results? The OEM's spend huge >$$$ on testing and I suspect are on the hook for any changes that effect >emissions. Do any aftermarket tuners who make PROM changes recertify >the cars or even test for emissions? Hypertech does annual "spot checks" at certified labs covering a sampling of the offered applications. CARB (and EPA follows along) reviews the results (an A-B-A test) and also checks the other applications to make sure that they are of the same "flavor". Assuming all the applications follow the same general patterns for the parameters that are modified, all the applications are grandfathered in under one CARB E.O. number. Exceptions (such as the GM and Ford Diesels) are tested individually. This makes all Hypertech products legal for sale in both the Federal and California markets even though not every chip (far from it) has been tested. I'm not sure if other non-chip companies play by the same rules or not -- camshafts, for instance. I don't think the other "chip" companies (at least the ones servicing domestic cars and trucks- don't know about Dinan and Autothority, etc...) are quite as compliant. ------------------------------ From: "Ross Myers" Date: Mon, 25 Jan 1999 17:51:39 +1100 Subject: Some more Holden Memcals Hi All, I've just uploaded the 'corrected' Bin's from some more Holden stuff. BWFU0810.BIN is from a 95/96 5L V8 Auto, using #16176424 PCM BWCS9976.BIN is from a 94 Police car, possible PCM is #16195699 (The PCM lists on the case a BKDA Memcal, but it is a Police PCM!!). These 2 replace the incorrect versions of these I uploaded the otherday, the checksum works for these so I assume we are on a winner. Regards Ross Myers ------------------------------ From: Chris Conlon Date: Mon, 25 Jan 1999 02:23:39 -0500 Subject: Re: PROMs and Copyrights... I'm not a lawyer either, but this is what I recall from my days as part of a small software house. At 02:05 PM 1/24/99 -0800, Orin Eman wrote: >As far as copyright is concerned, my guess (IANAL etc.) is that >it is technically illegal to sell a chip containing modified GM >code - it would be a derivative work. Just changing a few bytes >or tables isn't sufficient... Greg says 10% changed, the number I recall is 25%, but this had been devised to cover books, movies, etc. I'm not sure how it tested out in the courts for binary code, especially as opposed to source code. A lot of desktop software is "licensed" to you and part of the license is an agreement that you won't reverse engineer it, etc. I'm not sure how enforcable this is, but I am sure that Microsoft has more money than you do (unless maybe Ross Perot is on this list, in which case I apologize) and IMHO that's mostly all that matters - how much court time can you afford? >However, GM would be hard pressed to prove any actual damages. After >all, you need their hardware to run the code! They don't have to prove any damages at all, IIRC. $25,000 per instance of violation was the number I recall. Giving the software away I think counts as selling it for $0, so you're still pinched. OTOH with ECU PROMs, reverse engineering it should be ok unless it says somewhere in the pile of papers you sign that it's not. (Which I doubt.) Posting info you got from reverse engineering I *think* is ok, as long as you're not posting big chunks of the original binary too. Think of it as literary criticism, there's a de facto tradition of "fair use" of small snippets of the original work. But info you got from reverse engineering ("change $3acc from $00 to $ff to disable blah blah blah") should be fine, as long as you aren't under a non- disclosure agreement from GM or anything like that. Anyway this is interesting enough for me to send to one of my lawyers and seek a real answer. Chris C. ------------------------------ From: Chris Conlon Date: Mon, 25 Jan 1999 03:23:53 -0500 Subject: Re: DFI, Batch Fire, and other myths Hi again, At 08:46 PM 1/21/99 -0600, Tom Sharpe wrote: >Boy I started something. I want to add IMHO that vaporization helps >economy/efficiency under cruse conditions but decreases effective intake >charge at WOT. Atomization helps cruse and WOT conditions as well as not >hindering WOT. Tom Ok, first I agree with all of this. Designing for big WOT power, *and* for low BSFC at cruise is not the easiest combination in the world. One thing that might work would be to have a 2 or 4 injector TBI setup, with those injectors sized to get you up to maybe 25% of max power, and relatively huge TPI injectors in each port. This way you can have really big TPI injectors without worrying about idle quality. And, as an added bonus, you probably will get a higher % of the fuel from the TBI injectors to evaporate, which is probably a *good* thing for BSFC at cruise. (Actually I don't know how the pumping work vs. compression work numbers pan out... Greg?) As for resolution of various ECU subsystems, this is a subject near and dear to my heart. So I'll try to keep it short from boring y'all! (Plus I don't have hard numbers to show, yet.) Bruce wrote: >But, but, what about the filtering?. Doesn't that fly in the face >of needing absolutely accurate MAP sensing?. > **Notice the question mark, I'm asking. > This "filtering" is a funny animal, in so far as using larger ID/ >loner sensor lines can make a vast difference on some >applications, and I've always had better response with smaller >shorter lines. MAP filtering is an important issue IMHO, and I'm curious how OEs handle it. The MAP signal spectrum has strong components based on the RPM, which can vary over a 10:1 range, and components based on the fixed lengths of intake elements. (And variable intakes, in some cars.) As far as I'm concerned you need dynamic filtering, which changes with RPM, if you want good throttle response over a wide range. (The possible exception being a good accelerator pump algorithm, which would essentially use the TPS to fill in the data you miss by over-filtering the MAP signal.) As far as the whole turndown ratio issue, are OE apps using a regulated injector drive voltage (or current-sensing drive circuits, better still), or is there still a low-battery injector pulse width correction? (As with some really old stuff.) One more good reason to go to peak and hold, IMHO, is that you can use a 5-6v regulated supply, which should be doable under almost all battery conditions, and current-sense drivers which automatically compensate for the change in injector resistance with temperature. If you're trying to get accurate, short pulses from big injectors, you need all the hardware assist you can get. (Note this mainly applies to boosted engines which have a wider dynamic power range. But boosted engines are mostly what interest me.) ... Someone asked a bit ago about low-pressure sensors. I'm gonna come off sounding like a damn Motorola ad here, but I really like their pressure sensors. They have a couple designed specifically as MAP sensors, and some others in lower and higher pressure ranges. The ones I use are mostly temperature-compensated, and have a conditioned 0-5v output. The bandwidth is reasonably high, though you can get better accuracy if you filter it down some. (They don't spec it as -3dB bandwidth, they spec it as 1msec response time from 10%-90% given a full-scale pressure pulse. I'm too tired to do the math but think 500Hz or more.) Accuracy is conservatively spec'ed at ~1%-1.5%, you can do better if you're willing to limit the temperature extremes, filter down to lower bandwith, and do some math on the output signal. (Also the lower pressure range units have more error.) Not instrument-grade but damn good. More importantly short term drift is low. Best of all they're cheap, the last set of 2.5 bar absolute units I got were ~$16 each in onesies. Anyways sorry for sounding like a damn ad, I don't get a kickback, honest! I just like the damn things. http://mot-sps.com/senseon/pressure.html Whew, ok, hope this interests someone. Chris C. ------------------------------ From: Wayne Macdonald Date: Sat, 23 Jan 1999 11:52:20 +1100 Subject: RE: dual spray injectors - ------ =_NextPart_000_01BE48A6.B9A56D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sagem have injectors with angled spray from two points. the number on the injectors is 01D004A these are in injected Triumph motorcycles. I am not sure what the flow rate is. Wayne. - ---------- From: Ord Millar Sent: Saturday, January 23, 1999 2:06 AM To: Diy_Efi (E-mail) Subject: dual spray injectors Hi - I am just returning to the list; I was previously a lurker here but other interests got in the way for a while. Does anyone know where I can find some injectors that spray two cones? Alternately, how about an injector where the spray is at a small (15 degree) angle relative to the body? Or, in a perfect world, one that does both? (Two cones, at an angle). Worst case, I can try to work with some sort of deflector. I am working on a project to deliver fuel at both valves on a multi-valve head. Thanks, Ord - ------ =_NextPart_000_01BE48A6.B9A56D70 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiAKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAYAEAAAEAAAAMAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAYQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGRpeV9lZmlAZWZpMzMy LmVuZy5vaGlvLXN0YXRlLmVkdQBTTVRQAGRpeV9lZmlAZWZpMzMyLmVuZy5vaGlvLXN0YXRlLmVk dQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAIgAAAGRpeV9lZmlAZWZpMzMyLmVuZy5v aGlvLXN0YXRlLmVkdQAAAAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAACQAAAAnZGl5X2VmaUBlZmkz MzIuZW5nLm9oaW8tc3RhdGUuZWR1JwACAQswAQAAACcAAABTTVRQOkRJWV9FRklARUZJMzMyLkVO Ry5PSElPLVNUQVRFLkVEVQAAAwAAOQAAAAALAEA6AQAAAAIB9g8BAAAABAAAAAAAAAKcSAEEgAEA GQAAAFJFOiBkdWFsIHNwcmF5IGluamVjdG9ycwDXCAEFgAMADgAAAM8HAQAXAAsANAAUAAYARwEB IIADAA4AAADPBwEAFwALADEANwAGAGcBAQmAAQAhAAAANzQ1OEJCQ0EyOEE5RDIxMTgwQTIwMDEw NEI2NEQ1ODUA/gYBA5AGABAFAAAUAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAAD ADYAAAAAAEAAOQDgYYihaka+AR4AcAABAAAAGQAAAFJFOiBkdWFsIHNwcmF5IGluamVjdG9ycwAA AAACAXEAAQAAABYAAAABvkZqoYbKu1h1qSgR0oCiABBLZNWFAAAeAB4MAQAAAAUAAABTTVRQAAAA AB4AHwwBAAAAFgAAAHdtY2RvbmFsQGh1dGNoLmNvbS5hdQAAAAMABhBhfHBIAwAHEJACAAAeAAgQ AQAAAGUAAABTQUdFTUhBVkVJTkpFQ1RPUlNXSVRIQU5HTEVEU1BSQVlGUk9NVFdPUE9JTlRTVEhF TlVNQkVST05USEVJTkpFQ1RPUlNJUzAxRDAwNEFUSEVTRUFSRUlOSU5KRUNURURUUklVAAAAAAIB CRABAAAAfgMAAHoDAAAeBgAATFpGdUe5OmD/AAoBDwIVAqQD5AXrAoMAUBMDVAIAY2gKwHNldO4y BgAGwwKDMgPGBxMCgyIzD3poZWwDIERs6mcCgzQTDX0KgAjPCdniOxefMjU1AoAKgQ2xwQtgbmcx MDMUIAsKGxLyDAFjAEAGAWdlbaIgEcB2ZSALgGoFkI50BbAEIAPwdGggGpECbAmAIHNwcmF5AiAD UiB0d28gcOJvC4B0cy4KhR3wHRDsbnUG0ASQIAIgIFMdOAEEACAwMUQwMDT+QSBSEfAeEBegHSEd JR5hdlQFECCwcB4ABGAdgWPMeWMeUB/QIEkeEBzA3m4kwB6ACHAdEHcRwAVA+yBiGnBvB+AesCPw IhEf5mUKhVcewG5lJ70K9GwYaTE4IoACAGktMTw0NA3wDNAq4wtZMTbPCqADYCPwHXAgLS0HCofX K7sMMCyGRgNhOi4OLIZ5DIIgTwsgBdADEAtgcn8try69BmACMC/vMPsGEHRFCHBkHsAsIEoAcHWT CsAe0DIzNwAxOTfw0TeQOjA2E3BNMm8uvQxUbzSvMPtEaXlfwkUqsCAoRS0AwAMQ5ik4rzN+dWId UjrPMPt+ZDdQAyAelB03KQ8qEzNeNiuHFcIMASyGSD0ALfEldGp1cwVAF6A2oQMAvxqgHzAfYCBi KkBG8DslcYx3YQQgHqBldmkIYLRzbB7QYUggCHBrIOHzFPAjQWJ1BUAkwEoxHSHvI/AXoEbwBCBn JeEjcSBif0iwHtEFsUmgJmADECjuRLZvB5EAcHkCIB0QayXQbwfgJmBKQiWAYwORKrBu/x5xA3Ad Gh3wJoEelB9CBaBJKNBzPwqFQWxLQW73J1FJcDcAaCcRAaAIYAVA/wORHTZPVSBiQkVOgVRxHoCj AMAVESgxNUHgZQnCzikeFEcRC2B0aR0BR8X5BuBkeVKmMcA3ACNxSaAacASQZizCH1BybGR3NwBO 0lFjZE5iBuAd8D/6ID0QVFImNwBWglphHjL6KR/mVx2RBUBP4BHwNwDdT8R0N3FHwVshax3EUHP3 UHAAICEAZldhGnAdYye9/yWDYHJHgiERWoEDYB1SR7LvDbAqQB0ABcBmClADICaBeVxyIHYHQB0A BCBkM22edVMwKsBmg0ohYWQnvfJUEcBua11wJ8wxwSfMv0OvK4cb1SyGCoUWwQBu0AAAAwAQEAAA AAADABEQAAAAAEAABzBAbVVLaka+AUAACDBAbVVLaka+AR4APQABAAAABQAAAFJFOiAAAAAAAwAN NP03AAB0cA== - ------ =_NextPart_000_01BE48A6.B9A56D70-- ------------------------------ End of DIY_EFI Digest V4 #58 **************************** To subscribe to DIY_EFI-Digest, send the command: subscribe diy_efi-digest in the body of a message to "Majordomo@xxx. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace "diy_efi-digest" in the command above with "diy_efi".