HUFF Winexplorer HU Unlooper Script

The script that accompanies this document is called HUFF. It is the latest version of an INDEPENDENTLY developed script/atmel code that will allow you to unloop an HU card using a standard HU Loader!

This package contains:

1. A new Atmel Flash for your HU Loader. Also included are the .hex and .eep files.

NOTE: To avoid confusion similar to the HU7F release, the atmel code which will be released is COMPLETELY backward compatible with standard V5.0 HU code and the previous HU7F release. The HUFix7F-5C.xvb script is "locked" to the HU7F atmel code but this can be corrected with a simple edit to enable operation with the new atmel version string. The new atmel code will operate correctly for normal, everyday loading functions.

2. The script Huff.xvb to be run under Dexter's Winexplorer 4.6. This should be moved to your Winexplorer 4.6 directory. You should also place a clean, clone .bin at USW 0600 into the directory as this will become your repair .bin!

3. This document HUFF.htm.

4. A readme.txt document in .txt form.

Before you attempt to use this script and flash, read this document thoroughly and understand what you have read.

This has been thoroughly tested and is proven to work extremely well on many currently available HU Loaders.

What to expect. This Atmel code and program are pushing the 2313-10 Atmel to it's absolute limits. Results will vary greatly from loader to loader and some minor modifications to the loader are recommended for improved performance. These modifications are listed at the bottom in the "HARDWARE MODIFICATIONS" section.

Well over 98% of the 5B/6B/7B/8B cards that have been tested have been repaired using the hardware mentioned above.

A very small number of cards that were completely dead could not be repaired - these cards returned no ATR response at all even after the FF'ing sequence was run on them repeatedly.

An additional extremely small number of cards had the bootloader successfully loaded, but after writing the BIN file, certain EEPROM cells remained at 00 (usually in blocks of 32) indicating EEPROM failure.

This code was tested on a Kit Central KIT-04 and clones (CyberV Super CRS, MPiK Loader), Kpyro, Vector Fusion (with daughterboard), NASTI, and a UL Pro (old) all with good results.

It was tried on a Triton AI, Mikobu, Barracuda (dss-islands/white viper style loader) and SD Logic (USCT) units with very poor to no results. It did work just fine on an original WT unlooper, however, when a Daughter Board circuit was added. It was tried on two JT-Tek Clones with/without daughter board with no results.  It was tried on a KitsPlus clone (CyberV Ultra CRS) with/without daughterboard and got zero ATR success. It was also tried on a Bear CRS (lil red one) with no success.

The reason for this not working at all or not very well on some of the high end units is that there is not enough delay in the 4053 vs. daughter board clock glitch circuit to make it respond correctly. From what is understood, the original one and only unlooper also had this particular problem when attempts were made to replicate it.

An additional hint. It was found that in some cases, paralleling (not series), 2 daughter board inverter gates made a difference in the timing that was useful. This may work better in some cases to vary the timing.

Basic Program Operation

Place the HUFF.xvb script in your Winexplorer 4.6 directory.

Copy a clean BIN in this directory, also. This will become your repair BIN file although you can choose any BIN when prompted.

Select from your desktop and bring up Winexplorer 4.6 

Select the folder option on the toolbar. Your selection window will come up.

Select the HUFF.xvb script and click on open. The script will be loaded into Winex.

You can insert a card into your loader at this point. The script will take care of setting up WinExplorer 4.6 for unlooper settings.

Select the run script option on the tool bar. This script performs an initial ATR check and will give multiple warning screens if an ATR is present on the card. If the card exhibits a bad ATR, the script will continue.

Above is the valid program response to the ATR check for an FF card. A 00 card will give the response 05 01 00.

A selection of glitches screen will appear. This is the most important part of the program.

The glitches are listed in no particular order. The #1 glitch was the first glitch found and it works well with a variety of loaders. Glitch #2 was the second found and the optimized glitches followed. Glitches 25-30 were the last ones found to work on 4B cards. These are very loader dependent.

Make your glitch selection.

After selecting your glitch, allow the program to run. The program will search within the script parameters for a DAC setting that will yield an ATR. Once found, the range will be optimized for maximum ATR response. In some cases, the bootloader will load during this process. In others, it will seek the sweet spot, and then begin to sequence through the ATR DAC range until the bootloader is active.

At that point, a dialog box will come up and you can select your repair BIN to be written to the card. Select the BIN and it will be written to the card.

Some glitches were included that worked best with a Vector Fusion and are labeled as such.

Once you have found the glitches that work best for the unit you have, note them and use them on all cards. This had to be done this way, due to the great variation between loaders!

Basic Unlooping Sequence

Initial ATR Search 

The ATR glitch selected will be attempted "InitialATRDACTries" times per DAC1/DAC2 combo in descending sequence skipping by a value of 2 for both DAC1 and DAC2. If a single ATR is received, then if "InitialMinATRs" out of "InitialMinATRRetries" good ATR responses are detected at that same DAC1/DAC2 combo, ATR range optimization begins. 

The various ATR glitches are setup in no particular order. The added 4B glitches are near the end of the list. These were the last one's worked on as most of the other glitches did not work at all or did not work well on 4B's.

Glitch 1 was the first glitch that was discovered to work. Glitch 2 was the improvement. Glitches 3-10 were the last discovered and usually one or two of those work very well.

Some glitches were included that worked best with a Vector Fusion and are labeled as such.

Once you have found the glitches that work best for the unit you have, note them and use them on all cards.

ATR DAC combo Optimization 

Optimization involves narrowing the Min and Max DAC1/DAC2 ranges by "OptimizationRange" around the DAC1/DAC2 used when "InitialMinATRs" was reached. If a single ATR is received, then if "OptimizationMinATRs" out of "OptimizationATRDACReTries" good ATR responses are detected at that DAC1/DAC2 combo, then those values are locked in and used for the duration of the session. 

The DAC1 and DAC2 ranges are controlled by "MinDAC1"/"MaxDAC1" and "MinDAC2"/"MaxDAC2" 

It should be noted that every time a good ATR response is detected during the Initial ATR search or Optimization ATR search sequences, an attempt to load the bootloader is made. Many times one of these attempts will succeed and the bootloader will become active during the ATR search portion of the session. 

Attempt to load Bootloader 

The bootloader glitch sequence has a variable delay range controlled by "MinRTSGlitchDelay" and "MaxRTSGlitchDelay" and a variable DAC value controlled by "InitialRTSDAC" and "MaxRTSDAC". "MaxRTSTriesPerDAC" tries will be made at a single RTS DAC/Delay combo. Then, the RTS Delay will be incremented and "MaxRTSTriesPerDAC" will be made again at that Delay value. Once "MaxRTSGlitchDelay" is reached, the RTS DAC is incremented by 2 and the Delay is reset to "MinRTSGlitchDelay". This sequence is repeated until "MaxRTSGlitchDelay" and "MaxRTSDAC" are reached. At this time, the session is aborted, all values reset, and the process is restarted. 

If, during the RTS glitch Delay/DAC progression, the card stops producing good ATR responses, two values control the actions taken. "NoATRPauseInterval" determines how many unsuccessful attempts at the optimized ATR DAC1/DAC2 values are made before pausing for "ATRPause" milliseconds. This pause seems to allow the card to "rest" and may often start producing ATRs again when the ATR glitching resumes. If "ATRTriesBeforeFF" is reached through consecutive unsuccesful ATR glitches, then the FF'ing sequence is executed to make sure necessary EEPROM values are all FF. 

The program works well with an overall delay of 30. On most units, this is sufficient. It was found, that on some difficult cards, delays of 2A and even 27 worked when nothing else did.

For most loaders, the preset values of 66 to 78 work OK. The software extends these ranges, somewhat, if no ATR is acquired.

In some cases, an RTS_DAC range of 60-88 may be useful, especially for use on 4b cards. The range may even be extended to as low as 50 in some instances but little is gained by going higher than a value of 88.

Bootloader successfully loaded 

Once the bootloader is loaded and the program has control of the card, "PromptToReadBINBefore" is checked. If "True", then the entire EEPROM is read and saved to a BIN file. NOTE: since the process requires FF'ing the entire EEPROM, this serves little value and will not produce any information about what was on the card. Next, if "DefaultBINFile" contains the path to a valid HU BIN file, that BIN is written to the card from 2000-3FFF. Finally, if "PromptToReadBINAfter" is "True" then the entire EEPROM is read and saved to a BIN file. This can be useful to see if there are damaged EEPROM cells that wouldn't take a write. 

Test for valid ATR 

Finally, a standard reset is done and an ATR received. If the correct # of bytes are returned by the card, the session is considered successful. If the ATR is still FF, a failed session is reported. Sometimes the BIN file gets locked open and the program needs to be restarted for a successful write to occur. 

Program Parameters

DELAY:

The program works well with an overall delay of 30. On most units, this is sufficient. It was found, that on some difficult cards, delays of 2A and even 27 worked when nothing else did.

RTS_DAC:

For most loaders, the preset values of 66 to 78 work OK. The software extends these ranges, somewhat, if no ATR is acquired.

In some cases, an RTS_DAC range of 60-88 may be useful, especially for use on 4b cards. The range may even be extended to as low as 50 in some instances but little is gained by going higher than a value of 88. Lowering it to 50 was found useful for 4b cards and certain chip combinations.

ABOVE PROGRAM VARIABLES

All of the values listed above are included and annotated at the beginning of the script. This made the script more involved, however, it makes the editing of the values easier as they are all in one place. These are on lines 6 to 29 of the script and are fully commented. This will make alterations to the program parameters easy as you will not have to search through the program to make changes.

Since 4B's are the worst problem, the following is also added here. If you have little or no results on a 4b, glitch 30 can be altered by changing the value in hex of the 63 up or down. You can go about as low a 5A on this. The response will indicate whether the glitch is too soon or too late.
 

This glitch can be replaced by another one:
"12 0E 02 10 01 20 04 AE 09 0D DAC2 06 20 00 5D 0C 12 86 00"

DAC settings.. 

MinDAC1 = &h62 
MaxDAC1 = &h72 
MinDAC2 = &h74 
MaxDAC2 = &hB0 
InitialRTSDAC = &h66 
MaxRTSDAC = &hBB 

The above glitch was found to work on some units for 4B's on some units when the 4053 chips were played with. If this helps, you can save this altered script under another name and use it for your 4B problems.

 

Hardware Modifications

This script and Atmel Code was designed to be run on a standard HU loader. However, several loader modifications can be made to improve performance/success.

1. C3 or the flash cap used in most loaders must be changed for this to work correctly. If this circuit has a .0022uf cap. in it this will work but anything higher in value than this such as .0047uf is too high for this to work properly. This cap. should be changed to a .001uf capacitor for best results. REMEMBER, ONCE THIS CAP. IS CHANGED, THE LOADER WILL NO LONGER FLASH!

2. Variation of voltage was found not to be necessary or even desirable in this application, provided the following is done to the LM358 circuit. This circuit uses a .1uf capacitor from Vcc (usually 8-12 volts on pin 8) to ground. This is fine. The other capacitor in the circuit is often a .0022uf. (This may work, but the RTS_DAC values will be on the high end of the range). It is connected to pin 5 (usually) of the LM358. This must be changed to either a .047uf or .05uf capacitor. The other component in this circuit is a resistor. Ranges vary from 4.7K, 5.6K, to 47K and in one case 56K. This resistor must be changed to a 47K 1/4 watt. variety. This modification has a lot to do with where in the program range, the RTS_DAC falls.

The above basic modifications are very necessary for this to work correctly. In addition, this Atmel/software combination is very loader dependent. The components used for the gate chips make a great deal of difference in performance. The problem in releasing just a flash and the software is that it should have been properly tweaked to work with a specific loader. This was judged to be impossible due to the variety of loaders and modified Unloopers that are out there.

Below is a list of what worked best:

1. Overall, using all Philip's chips, especially for the 74HC4053's works the best, overall.

1a. Fairchild and ST 74HC4053 chips also work. Next in line, the Japanese ones gave some results. TI, Motorola, Signetics, and MAX chips did nothing. 
1b. The brand of LM358 and which MAX chip was used in the RS-232 circuit made no difference.

2. ST chips also work well in the rest of the circuit as do Fairchild ones. For the gates, the Japanese varieties will also work. If the clock uses a 74HC04 chip, all gates (74HC74, 74HC04, and 74HC00) should be the same type. If the clock is of the HCT variety, all gates should be HCT, including the daughter board circuit chips.

2a. It was found that tweaking the Daughter board circuit chips can make a great difference in unlooper performance. By changing the 74xx04 gate from HC to HCT to F to AHC made a great deal of difference. Also HC and HCT swapping of the 74xx74 in the DB circuit makes a difference.

2b. The circuit chips cause variance in the way the program operates. An ATR acquired at say RTS_DAC 6E using Philip's 74HC4053 chips may be at RTS_DAC BE with a pair of Fairchild ones on the same card. Most of the variation is a result of the U7 74HC4053 which controls the circuit clock to the card.

2c. The gating of the 74xx00 chip also varies the results quite a bit. In some cases, changing the HC version to an HCT made a great deal of difference.

2d. The gating of the 74HC00 is also very critical. The changing of this chip to another variety may make all the difference in the world. As an example, changing the chip from a Philip's to Hitachi, allowed the use of the MAX4619 chips that would not work with a Philip's at all!

 

Troubleshooting

If no partial ATRs are received, try a different glitch, different voltage or different loader. Check the ATR that is displayed when the script is first run. Run the script, let it FF the card, then abort and run again. See if "FF" is returned. If nothing is returned at all after repeated runs through the "FFing the card" sequence, the card is probably damaged or dead.

If lots of ATRs are received but the bootloader won't load, try a different ATR glitch, change the MaxULResponseTime parameter if it's a faster PC, or try changing the caps or swapping brands of chips as outlined in HARDWARE MODIFICATIONS.

If the bootloader loads, the BIN gets written, but ATR is still not valid, try restarting WinExplorer. Also turn on the PromptToReadBINAfter option and compare the read BIN with the written BIN - they should be the same. If not, there could be damaged EEPROM cells.

The slight delay in the release of this Atmel/software combination was caused by an attempt to make it work on the largest number of loaders out there, rather than confining it to a particular loader design. This could have been made more exacting, if only one specific loader design was used to design this software. A great deal of study was required from hardware experts for this to become a reality. -unatester-
 

Overall Performance

"MaxULResponseTime" is set to 25000 by default and works well on a P2-400M. On faster computers, higher values are necessary to achieve a proper software timeout. A value of 50000 was necessary on a P4-1.4G machine

It could have been done better, if one specific loader was tweaked to fit the software. Since this was not practical, the most important variations were listed in the beginning to help you along. In hardware tweaking, after many hours of chip swapping and capacitor changing, a unit was created that will fix most 5B and 6B cards in under 2 minutes! Many would fix when an ATR was achieved. It was not a high tech design, it was a Kpyro/WT original design with only a daughter board circuit added. It was also extensively tested on an MPiK loader with some chip adjustment and the capacitor changes. The Repair station as talked about on the Den and the Kit Central KIT-04 design also worked very well with the capacitor changes.

Any complaints on this not working, are all hardware problems and not a problem with the Atmel code and or the software included. The glitch points are based on the specific timing of specific card instructions and cannot be changed! The only variation is in the timing of the hardware used.
 

Just another milestone for freeware.

-unatester-