VOGONS


Reply 40 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Reply from TL866IIplus distributor:

TL866II can support VPP 18V and VCC 1.8V-6.5V, You don't have to worry about 12 volts. You can test it yourself with a blank chip.if it can not work,Please send me the screenshot of the error message,I'll report your problem to the manufacturer

He doesn't seem to understand that I'm wanting to know about 12 V to RP#, not Vpp. Perhaps my question wasn't clear enough, his English isn't good enough, the automated eBay English to Chinese translation isn't sufficient, or his knowledge is too limited. My message to him was:

Intel E28F002BC and Micron MT28F002C1 both require that 12 V be passed to the RP# pin to unlock the boot block.  Is the TL866IIplus able to supply 12 V to RP# to unlock the boot block?  If not, the TL866IIplus cannot properly program these EEPROM chips.  On the other hand, Intel E28F002BV and Micron MT28F002B1 chips (which are on the TL866IIplus support list) do not require 12 V to RP#. These EEPROMs can unlock the boot block with only 5 V to RP#.  Please confirm if TL866IIplus can supply 12 V to RP# on the TSOP40 pinout (E28F002BC and MT28F002C1)? 

Plan your life wisely, you'll be dead before you know it.

Reply 41 of 80, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:

For the Batman board, FMUP is the supplied utility. So you think I need to follow the blind manual procedure I outlined previously? Or perhaps it automatically looks for _.BIO? That would be surprising since the newer VS440FX board needs to be directed to it with the /p flag.

I'm not entirely sure, but for the old motherboards, that's probably the only way, on the other hand, VS440FX maybe could pick up files in recovery mode automatically. This is what I found, regarding BIOS recovery for motherboards that were relevant in 1998:

 BIOS Recovery

Note: Not all standard Intel products support the Flash BIOS recovery feature. If your motherboard (for example, the Advanced/AS) does not have the recovery feature, ensure that you do not power down your system during a BIOS upgrade. This could corrupt the BIOS code. If your BIOS is left in an unusable and unrecoverable state, it will be necessary to contact the place of purchase.

In the unlikely event that a FLASH upgrade is interrupted catastrophically, it is possible the BIOS may be left in an unusable state. Recovering from this condition requires the following steps (be sure a power supply and speaker have been attached to the board, and a floppy drive is connected as drive A):

1. Change Flash Recovery jumper to the recovery mode position (see note above; not all products have this feature)
2. Install the bootable upgrade diskette into drive A:
3. Reboot the system.
4. Because of the small amount of code available in the non-erasable boot block area, no video is available to direct the procedure. The procedure can be monitored by listening to the speaker and looking at the floppy drive LED. When the system beeps and the floppy drive LED is lit, the system is copying the recovery code into the FLASH device. As soon as the drive LED goes off, the recovery is complete.
5. Turn the system off
6. Change the Flash Recovery jumper back to the default position.
7. Leave the upgrade floppy in drive A: and turn the system on.
8. Continue with the original upgrade.

Jumper locations can be found in the Technical Product Specification or on the "jumpers" page for each individual product.

Updated: Monday, November 16, 1998

Recovery instructions implies, that no additional steps are required to start the BIOS recovery. Link

feipoa wrote:

I've attached the two BIOSes from user kixs. the NSSI created BIOS is only 64K, while the UNIFLASH created BIOS is only 128K. Does this make sense to you? Shouldn't it be closer to 256K? According to the UNIFLASH documentation, the boot block is automatically recorded starting with v1.33. I sent kixs version v1.40.

I had inspected both images. Image made using NSSI is just a decompressed BIOS copy from the shadow RAM and it's not entire, while image made using UNIFLASH seems legit, but its size is twice as small. From NSSI image I'd gathered, that kixs's motherboard is using 1.00.17.CS1 BIOS version. I tried to look for BIOS update utility of that particular version, so that I could compare image's structure with separate *.BIx files directly, but could not find it anywhere (file name for the update util. reqd. - 10017CS1.EXE). Still, compared 128KB image with 1.00.18.CS1 BIOS update files and its structure goes in this order: *.BI3 (most resembling)+boot block(dated 96-12-06)+*.BI2(most resembling), *.BI1 is absent completely and *.BIO is filled with FFs anyway.

Boot block in UNIFLASH's image is located at C000-10000 HEX address range (basically in the middle), I would not trust this image and I doubt that kixs's motherboard uses a 128KB FLASH chip.

Sedrosken mentioned, that he also has the VS440FX, you should ask him for help too, maybe he knows a way how to dump a 256KB image?

feipoa wrote:
He doesn't seem to understand that I'm wanting to know about 12 V to RP#, not Vpp. Perhaps my question wasn't clear enough, his […]
Show full quote

He doesn't seem to understand that I'm wanting to know about 12 V to RP#, not Vpp. Perhaps my question wasn't clear enough, his English isn't good enough, the automated eBay English to Chinese translation isn't sufficient, or his knowledge is too limited. My message to him was:

Intel E28F002BC and Micron MT28F002C1 both require that 12 V be passed to the RP# pin to unlock the boot block.  Is the TL866IIplus able to supply 12 V to RP# to unlock the boot block?  If not, the TL866IIplus cannot properly program these EEPROM chips.  On the other hand, Intel E28F002BV and Micron MT28F002B1 chips (which are on the TL866IIplus support list) do not require 12 V to RP#. These EEPROMs can unlock the boot block with only 5 V to RP#.  Please confirm if TL866IIplus can supply 12 V to RP# on the TSOP40 pinout (E28F002BC and MT28F002C1)? 

Stop torturing the distributors 🤣

Reply 42 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I'm not entirely sure, but for the old motherboards, that's probably the only way, on the other hand, VS440FX maybe could pick up files in recovery mode automatically. This is what I found, regarding BIOS recovery for motherboards that were relevant in 1998:

I've decided to hold off on the Batman's Revenge recovery procedure. If I have success with the VS440FX, I might reconsider. I'm generally not very lucky.

Stop torturing the distributors

lol, yeah, I'm done with this bloke. The manufacturer never returned my email inquiry, so I figured this was as close as I could get. The guys at Wellon tech support always returned my emails and added chips to the support list on request.

I had inspected both images....

Thank you! I've asked kixs which BIOS version is on his MB and he confirmed 1.00.17.CS1. I also sent Sedrosken a PM. Is there any value in requesting that kixs update the BIOS to 1.00.18.CS1?

Sounds like the code in the boot block doesn't update with the various BIOS updates? From your analysis of 1.00.18.CS1, it sounds like the bulk of the BIOS only needs 128 KB? Could one then correct the issue by adding FF paddings in the appropriate locations, re-positioning the address of the boot block code, and updating the checksum? Do you think Uniflash is altering the address of code based on FF's? I don't understand why the boot block would be moved. I assume the EEPROM itself has a specfic address where the boot block must be, so perhaps Uniflash doesn't support the particular EEPROM and is moving the boot block based on where the boot block is for a 1 Mbit chip?

EDIT: Unfortunately, the Intel E28F002BV chips didn't arrive today. Perhaps sometime this week then - tracking now says Aug 15.

EDIT2: At this stage, do you think it preferred to try flash your bootblock file, or the Uniflash kixs file?

EDIT3: Sedrosken is using 1.00.18.CS1 on his Gateway VS440FX board. This EEPROM is the same as my original, E28F002BCT80

You should also inspect Vpp and RP# pads on motherboard, maybe they constantly receive 12V.

At least in the off-state, Vpp and RP# do not receive 12 V. No other pad on the TSOP40A received 12 V.

Plan your life wisely, you'll be dead before you know it.

Reply 43 of 80, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:

Is there any value in requesting that kixs update the BIOS to 1.00.18.CS1?

There's no point if UF returns 128KB images. According to UF1.40 documentation file, the 28F002 chip was never tested, nor 28F020, 28F004 was tested and it didn't work as it should, most likely 28F002 doesn't either.

3.0            What flash chips are supported by UniFlash ?
-----------------------------------------------------------

UniFlash supports the following flash chips:
* means tested and functional,
# means tested, but doesn't work the way it should,
unmarked chips are not tested (note that a lot of chips are very similar to
one another though, so if one of them works then the rest should work fine
too)

,----------------------------------------------------------------------------,
| Flash ROM | Size |
`---------------------------------|------------------------------------------'
Intel |
----- |
28F256(A) | 32KB
28F512 | 64KB
*28F010 | 128KB
28F020 | 256KB
*28F001BX/BN-T | 128KB
28F001BX/BN-B | 128KB
28F002-T series | 256KB
28F002-B series | 256KB
#28F004-T series | 512KB
28F004-B series | 512KB
28F008-T series | 1024KB
28F008-B series | 1024KB
28F008SA | 1024KB
28F004Sx series | 512KB
28F008Sx series | 1024KB
28F016Sx series | 2048KB
28F016S5 | 2048KB
28F004B3-T | 512KB
28F004B3-B | 512KB
28F008B3-T | 1024KB
28F008B3-B | 1024KB
28F016B3-T | 2048KB
28F016B3-B | 2048KB
28F320J5 | 4096KB
28F320J3A | 4096KB
28F640J5 | 8192KB
28F640J3A | 8192KB
28F128J3A | 16384KB
*82802AB (Firmware Hub) | 512KB
*82802AC (Firmware Hub) | 1024KB
----------------------------------|-------------------------------------------
feipoa wrote:

Sounds like the code in the boot block doesn't update with the various BIOS updates?

That, or there was no necessity to update boot block untill the 18.CS1 version showed up.

feipoa wrote:

From your analysis of 1.00.18.CS1, it sounds like the bulk of the BIOS only needs 128 KB? Could one then correct the issue by adding FF paddings in the appropriate locations, re-positioning the address of the boot block code, and updating the checksum?

No, no, no, no, it would make more sense to guess the right order in which divided BIOS image from update util. should go and then try to stick them together. This is how a proper mem map should look like for that BIOS image (T prefix).

mem_map.png
Filename
mem_map.png
File size
46.66 KiB
Views
1537 views
File license
Fair use/fair dealing exception
feipoa wrote:

EDIT2: At this stage, do you think it preferred to try flash your bootblock file, or the Uniflash kixs file?

It's better to use image that I've provided, it meets datasheet's requirements.

feipoa wrote:

At least in the off-state, Vpp and RP# do not receive 12 V. No other pad on the TSOP40A received 12 V.

Just don't try to probe pads directly when the MB will operate (no matter how sharp/thin your MM probes are), use according vias instead.

Reply 44 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Sedrosken has BIOS version 1.00.18.CS1 on his VS440FX. Is there any value in having him attach the Uniflash created binary for his system?

Agreed - I wouldn't be probing the EEPROM pads with MM probes while powered up. If there wasn't a via, I'd solder a wire to the pad. Do you think knowing the voltage of Vpp and RP# while powered is important?

The EEPROM's arrived today!

E28F002BVT60.jpg
Filename
E28F002BVT60.jpg
File size
202.84 KiB
Views
1525 views
File license
Fair use/fair dealing exception

Plan your life wisely, you'll be dead before you know it.

Reply 45 of 80, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:

Sedrosken has BIOS version 1.00.18.CS1 on his VS440FX. Is there any value in having him attach the Uniflash created binary for his system?

No need.

feipoa wrote:

Do you think knowing the voltage of Vpp and RP# while powered is important?

RP# should be at 5V~, Vpp - anything but 12V~.

feipoa wrote:

The EEPROM's arrived today!

Hurry up with the boot block flashing, I want to see that MB POST 😁

By the way, that 16KB image is 100% a boot block. Check the last 16 bytes of that image, it has the far jump instruction (EA) with the segment and offset address of F000:C05B.

Reply 46 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++
SSTV2 wrote:

that 16KB image is 100% a boot block. Check the last 16 bytes of that image, it has the far jump instruction (EA) with the segment and offset address of F000:C05B.

Not sure what you want me to check? I'm not very familiar with BIOS binary code.

Sedrosken already sent me the Uniflash file of 1.00.18, so I've attached it for completeness.

I'll try to get to the EEPROMs tonight. With school out, my kids seem to stay awake forever. They didn't stop screaming until 2:30 AM last night; it was horrible.

Attachments

Plan your life wisely, you'll be dead before you know it.

Reply 47 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

1) write the bootblock bin you attached to E28F002BVT60 using TL866IIplus using TSOP40A adapter
2) solder E28F002BVT60 to motherboard
3) set recovery jumper on VS440FX and power on
4) ensure that the 1.00.18 recovery diskette is inserted
5) wait until no more diskette activity, wait 2 more minutes, power down, put recovery jumper back to normal, reboot
6) voila?

Or is there any benefit to powering up the system without the recovery jumper set once the EEPROM is soldered on? Perhaps the power LED will stop flashing?

Plan your life wisely, you'll be dead before you know it.

Reply 48 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Wait a minute... I measured Vpp in the off-state again today and it is connected to 12 V. RP# is not connected to 12 V, nor 5 V. Either I was mistaken the last time I measured Vpp, or there is an intermittent short. Does this new found knowledge alter the next course of action?

EDIT: power-on test, Vpp is 12.33 V. I went to measure RP# and the board (or power supply) started making a hissing sound, then the system shut down. I unplugged everything, waited 5 minutes, plugged the PSU back and hit power, the CPU fan spun up, but after a few seconds, there was this hissing sound. I thought it was the CPU fan, so I unplugged it, but the hissing sound was still there. It got louder, and fearing that I might get a cap blown in my face, I turned it off. Again, I'm not sure if it is the PSU, or the MB, but considering the issues, I'm guessing the MB. I checked for shorts on those electrolytic surface mount caps, but didn't find any shorts.

EDIT2: The capacitor just below the CPU socket measures only 30 ohms across its terminals. I'm guessing this is the source of the hiss? Perhaps I'll remove the cap and measure the resistance on the solder pads... EDIT3: the solder pads without the cap are also 30 ohms. EDIT4: swapped the PSU, don't hear a hiss so far. I'm going to let it run for a few minutes. Still not sure what to do about 12 V on Vpp. Perhaps a default response when no BIOS detected? EDIT5: I followed the traces for Vpp and it is intentionally hard-wired direct to 12 V, and not through a pull-up resistor. I guess I will continue with programming the *BV chip now.

EDIT6: Another user with the board also confirms 30 ohms across the resistor I removed and that Vpp on the EEPROM is wired to 12 V.

Plan your life wisely, you'll be dead before you know it.

Reply 49 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Here's the programmer with the double adapter sandwitch.

E28F002BVT60_in_programmer.jpg
Filename
E28F002BVT60_in_programmer.jpg
File size
420.94 KiB
Views
1494 views
File license
Fair use/fair dealing exception

I decided to read what was on the NOS E28F002BVT60. They don't come blanked?

E28F002BVT60_Screenshot_unprogrammed.jpg
Filename
E28F002BVT60_Screenshot_unprogrammed.jpg
File size
517.17 KiB
Views
1494 views
File license
Fair use/fair dealing exception

I decided to save the code that came on the unprogrammed E28F002BVT60

Filename
E28F002BVT60_insert_to_programmer_and_read_then_save.zip
File size
89.54 KiB
Downloads
72 downloads
File license
Fair use/fair dealing exception

SSTV2's code imported. It put FF's on all other locations.

E28F002BVT60_Screenshot_SSTV2.jpg
Filename
E28F002BVT60_Screenshot_SSTV2.jpg
File size
521.24 KiB
Views
1494 views
File license
Fair use/fair dealing exception

Programming successful.

Boot_block_programming_success.jpg
Filename
Boot_block_programming_success.jpg
File size
423.62 KiB
Views
1494 views
File license
Fair use/fair dealing exception

Plan your life wisely, you'll be dead before you know it.

Reply 50 of 80, by Sedrosken

User metadata
Rank Member
Rank
Member
feipoa wrote:

Here's the programmer with the double adapter sandwitch.

That's almost intimidating...

feipoa wrote:

Programming successful.

Excellent! Here's hoping you get it to POST first-try. I also hope that's the only issue you'll have with your board.

Nanto: H61H2-AM3, 4GB, GTS250 1GB, SB0730, 512GB SSD, XP USP4
Rithwic: EP-61BXM-A, Celeron 300A@450, 768MB, GF2MX400/V2, YMF744, 128GB SD2IDE, 98SE (Kex)
Cragstone: Alaris Cougar, 486BL2-66, 16MB, GD5428 VLB, CT2800, 16GB SD2IDE, 95CNOIE

Reply 51 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I inserted the VS440FX's original BIOS, the E28F002BCT80 into the TL866IIplus programmer. Attached is an image of "missing pins". The programmer doesn't have chip support for the E28F002BCT, but rather the E28F002BVT. Not surprising that the programmer software says that pin 12, which is N/C on the *BC chip and WP# on the *BV chip, is not connected. Also curious though is that it says pin 11, which is Vpp is a non-connect. Did the Vpp pin get burned out? Or is it connected internally on the *BC chip compared to the *BV chip, which is causing the programmer not to detect it? I had hoped to make a copy of whatever BIOS was on the original *BC chip, but this isn't going to happen.

I tried pushing my finger on the EEPROM while it was in the adapter, and that didn't help for these two pins. It helped for when pin 7 showed a disconnect, but not for pins 10 & 11. Too much flux on the pin to make contact? Probably not.

I also tried the Micron MT28F002B1 setting, but the outcome was the same.

Attachments

Plan your life wisely, you'll be dead before you know it.

Reply 52 of 80, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie

So the FLASH chip is set permanently to be in write/erase mode? How odd... Hissing noise usually indicates, that PSU is overloaded. Did resistances change between GND and the rest of PSU lines on MB, compared to those on the 1st post?

Reply 53 of 80, by SSTV2

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:

I decided to read what was on the NOS E28F002BVT60. They don't come blanked?

Interesting, those FLASH chips that you've bought are NOS, no doubt, but they are preprogrammed for production. According to the image, those chips were supposed to be used in the Ericsson DCT1900 comunications system. I bet those things cost huge sum of money back in the 90's.

Attaching boot blocks from kixs's and Sedrosken's VS440FX MB BIOSes, for archiving purposes:

Filename
kixs's_VS440FX_boot_block_96-06-12.zip
File size
8.53 KiB
Downloads
80 downloads
File license
Fair use/fair dealing exception
Filename
Sedrosken's_VS440FX_boot_block_96-05-21.zip
File size
6.88 KiB
Downloads
81 downloads
File license
Fair use/fair dealing exception
Filename
1.00.18.CS1_98-08-28.zip
File size
10.02 KiB
Downloads
65 downloads
File license
Fair use/fair dealing exception

I wonder, what difference does BB's version make.

Reply 54 of 80, by Sedrosken

User metadata
Rank Member
Rank
Member
SSTV2 wrote:
Interesting, those FLASH chips that you've bought are NOS, no doubt, but they are preprogrammed for production. According to the […]
Show full quote
feipoa wrote:

I decided to read what was on the NOS E28F002BVT60. They don't come blanked?

Interesting, those FLASH chips that you've bought are NOS, no doubt, but they are preprogrammed for production. According to the image, those chips were supposed to be used in the Ericsson DCT1900 comunications system. I bet those things cost huge sum of money back in the 90's.

Attaching boot blocks from kixs's and Sedrosken's VS440FX MB BIOSes, for archiving purposes:

kixs's_VS440FX_boot_block_96-06-12.zip
Sedrosken's_VS440FX_boot_block_96-05-21.zip

[/b][Emphasis mine]

1.00.18.CS1_98-08-28.zip

I wonder, what difference does BB's version make.

I find it interesting that despite my having the newest BIOS installed, I have the oldest boot block of the three. It works just fine, I can boot from CD natively even. Something had to have been updated because with the older BIOS, I couldn't do that.

Nanto: H61H2-AM3, 4GB, GTS250 1GB, SB0730, 512GB SSD, XP USP4
Rithwic: EP-61BXM-A, Celeron 300A@450, 768MB, GF2MX400/V2, YMF744, 128GB SD2IDE, 98SE (Kex)
Cragstone: Alaris Cougar, 486BL2-66, 16MB, GD5428 VLB, CT2800, 16GB SD2IDE, 95CNOIE

Reply 55 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++
SSTV2 wrote:

So the FLASH chip is set permanently to be in write/erase mode? How odd... Hissing noise usually indicates, that PSU is overloaded. Did resistances change between GND and the rest of PSU lines on MB, compared to those on the 1st post?

Is that so it can write ESCD configuration data? Where is ESCD stored in that BIOS block diagram you attached?

I didn't check this systematically yesterday. I will check this evening when the the owls and raccoons roam.

Looks like flashing the motherboard never changes the boot block. This is part of its protection mechanism. But makes me wonder, though, why does Intel update the boot block code between revisions if it doesn't get implemented? Must only be for new motherboards being pushed out. Intel must have some software/programmer combination which combines their BIOS fragments before writing the EEPROM.

Is there any value in aligning the boot block code to the appropriate addresses on those backups you made so that one could easily program them? I can imagine if I fail with the .18 boot block, that I'd probably try another.

Plan your life wisely, you'll be dead before you know it.

Reply 56 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I should note that when I had the original BIOS soldered on that -5 V to GND was a short, but now it is an open circuit (or greater than the 50 M-ohm limit of my multi-meter). Recall that 5 V to GND was 60 ohms with the old BIOS, then became 1.4 K-ohm once removed. -5 V to GND is now OC instead of SC.

Plan your life wisely, you'll be dead before you know it.

Reply 57 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I have soldered on the boot block programmed E28F002BV EEPROM. Unfortunately, I ripped off part of the pin (arrow in photos) and had to run an external patch wire. I don't have much experience soldering on such tight spacing - perhaps my smallest tip isn't quite small enough, so I had some issues with solder blobs. Using a spring loaded, hand held solder socker simply provides too much kickback and uplifted a few pads. I was able to get them back in place, but one of the pads broke of half-way.

Nonetheless, the best approach to get this IC back on was to pre-coat all the pins with a just the right amount of solder, then align and hold the EEPROM in place with masking tape. Then bring the soldering iron to each pin and let it reflow onto the EEPROM pins. On my first attempt, I didn't have any solder on the TSOP40 pads and tried to add solder to each pin as I went a long. After about 8 chips in, I started getting fat solder bridges, and this is when I brought out the spring-loaded solder sucker (ooops!).

Anyway, I'll try to fire this up tomorrow. I assume I'm to go right into recovery mode?

Solder_Job_1.jpg
Filename
Solder_Job_1.jpg
File size
775.83 KiB
Views
1407 views
File license
Fair use/fair dealing exception
Solder_Job_2.jpg
Filename
Solder_Job_2.jpg
File size
1.28 MiB
Views
1407 views
File license
Fair use/fair dealing exception
Solder_Job_3.jpg
Filename
Solder_Job_3.jpg
File size
1.34 MiB
Views
1407 views
File license
Fair use/fair dealing exception
Solder_Job_4.jpg
Filename
Solder_Job_4.jpg
File size
958.46 KiB
Views
1407 views
File license
Fair use/fair dealing exception

EDIT: If I get it working, I'll probably take the tape off and tack the wire down with a dab of epoxy. Also, I had to use these 10x magnifier glasses to solder the TSOP40 leads. I noticed only one burn scab on my nose this morning, though I swear I burned myself twice.

Plan your life wisely, you'll be dead before you know it.

Reply 58 of 80, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Success!

I was really skeptical when I powered it up in recovery mode because there was no diskette activity for about 40 seconds. I was about to turn it off, then all of a sudden the diskette started reading. Once diskette activity ceased, the diskette light was on solid for what felt like 2 minutes, then it finally went off. I placed the BIOS normal jumper back on, then rebooted. System asked me for a password, so you also must set the disable password jumper, turn on, then off, then on again with the password jumper back to default. I'm attaching some photo proof that it works.

VS440FX_startup.jpg
Filename
VS440FX_startup.jpg
File size
215.51 KiB
Views
1378 views
File license
Fair use/fair dealing exception
VS440FX_BIOS.jpg
Filename
VS440FX_BIOS.jpg
File size
160.26 KiB
Views
1378 views
File license
Fair use/fair dealing exception

I also removed the tape on the jumper wire as the fix looks less obvious this way. I should get some of that green 32 AWG wire that I see some manufactures use on motherboard for fixes. It is really inconspicuous. At least I think it is 32 AWG. The white kynar cladded wire shown in the photos is 30 AWG and the wire on MB fixes I've seen appears smaller.

VS440FX_jumper_wire_no_tape.jpg
Filename
VS440FX_jumper_wire_no_tape.jpg
File size
1.07 MiB
Views
1378 views
File license
Fair use/fair dealing exception

Many thanks to sedrosken and kixs for copying their BIOSes and especially to SSTV2 for his invaluable insight and resolve.

For the record, I contacted the the eBay distributor about not being able to use the *BC EEPROM on the TL866IIplus programmer - he was in fact the one who claimed the *BC EEPROM was supported prior to purchase. He did get back to me what a somewhat dubious solution, to uncheck "pin detect" and "check ID" on the programmer software. Unfortunately, I do not have a working *BC EEPROM to confirm if this method actually works, but I've attached a screenshot of the result with my faulty *BC EEPROM. Overcurrent protection! External Short!

Uncheck_pin_detect.jpg
Filename
Uncheck_pin_detect.jpg
File size
448.01 KiB
Views
1378 views
File license
Fair use/fair dealing exception

Plan your life wisely, you'll be dead before you know it.

Reply 59 of 80, by danijelm

User metadata
Rank Newbie
Rank
Newbie

SVAKA ČAST!

The closest literal translation in English would be every honor. It's used as an exclamation when congratulating someone or expressing amazement over someone's accomplishments.

😀

I speak sarcasm as a 2nd language