93lc66 Eeprom

[Eri Pfaff]

Hieveryone. I recently acquired this beat up GUS PnP and I'm wondering if it can be brought back to life. I've had trouble finding relevant information about the hardware, so I thought I'd ask here for help.

1. yep

2. decoupling capacitors, so your guess is likely good

3. ? no idea, might be another decoupling cap on a lower voltage line

4. this eeprom normally contains the PnP info, if i'm not mistaken. No idea if it will work without it.

For the "broken" latch, it looks to me like the spring metal latch is just bent. You should be able to bend that back into place very easily. The tiny bit of broken plastic makes no difference whatsoever.

On the original card, U6 is a 93LC66/P, but any appropriate replacement should work (see Thermalwrong's post, linked previously). This contains the Plug and Play resource map, as described. It is possible to get the card to a functional state without it, but it isn't usually a good idea to try running it that way. Furthermore, the original part is still available and inexpensive, and it is easy to write the contents while it is installed on the card. Once that is done and you have the full Gravis software package installed under DOS, you may want to use PNPCFG to disable features that you will not be using, as they consume resources, and generally cause more trouble than they are worth.

From the photo, it doesn't look like it was intentionally mistreated, just stored in a careless way, until someone realised that it could fetch a good price on the used market. I offer C48 as evidence. Unless that capacitor blew up so spectacularly that that is all that's left, it looks like it was physically smashed from the board while it was carelessly thrown in a box (or someone who didn't know what they were doing attempted "repairs"); there is still a little piece left.

Thank you so much for all the quick replies! This info is super helpful, and you strengthened my hope that I might get it working again. I owned this card in the '90s and have regretted getting rid of it, so I'd be thrilled to save this one and be able to enjoy it again.

Yes, it was probably stored carelessly. What you cannot see in the photo is that the board is also slightly bent.

Anyway, if it were only the yanked C48 and SIMM socket, I would totally agree that someone just mistakenly stepped on it or something. But I cannot explain the missing C11 and especially the EEPROM chip which seem to have been extracted. Maybe they knew that the GUS was dead and took the chip for reuse. But I'm remaining hopeful and will definitely update you after I get the parts and attempt the repair.

I had another look at the photo, and I am now firmly convinced that somebody made an attempt at repairing this specimen, then eventually gave up. The burning question now is: what led them to need to "repair" it in the first place? Add another critical question: did they try to test it after "fixing" it?

The LS244 (U13) looks like it might not be original, as well (Chinese-market re-marked "NOS"? Chip borrowed from somewhere else?). It clearly doesn't resemble the other discrete ICs, and the soldering job also doesn't look quite the same.

Definitely, unless I am stupidly mistaken, the ROM will have to be corrected. Then, look at each and every electrolytic capacitor, and make sure they haven't been damaged (there are a few that look strange, but it could just be a reflection from when you took the picture).

Using this photo as reference, it looks like everything that is present on my card is in the right place and orientation. And just like on mine, the LS244 on this photo also has lighter lettering than other ICs. It's honestly very similar to my card, even to the detail of the mic connector being a little askew towards the line-in one. So maybe it's not all that bad and it's just how these were originally produced.

The picture you are showing has the notch of the ROM at the top. This aligns with the silkscreen of the DIP package outline of the alternate ROM. I would guess that the silkscreen for the SMD ROM is the same, so the ROM is correctly oriented. The earlier picture has no visible notch, so I am unsure which way it should face.

Couldn't resist verifying it right away, VCC and GND for the IW78C21M1 seem to be in the correct spots on my card - so it's probably just another coincidence that my Interwave seems to have an issue there.

That means: both the Hi-res picture and the picture in the first post show the ROM in an apparently wrong orientation (since at a first glance, also the routing on the card seems similar).

Wow, this is so weird. You're right, all images of the card online have the ROM in the opposite direction. Except the one that I posted as reference! And the notch is there, just not very well visible in the lighting of that picture. Just check the top view of the card on the page from which I took the image: _id=2938

How is this even possible? The only reasonable thing I can think of is that the chip on my card and the one of the ref. picture share the exact same signage. The other cards out there have different ones. Maybe the one that I have has reversed internals for some reason?

If we ignore the ROM IC itself and pay attention to the board, we see that the traces are exactly the same as all of the other Version 1.0 boards of this type that have been shown. Based on that, we know how the ROM should be oriented (pin-1 notch at the top, as indicated by the silk-screen layer). So, unless we are to assume that there was a batch that left the Macronix production line with everything as it should be, except that the plastic top cover was fitted the wrong way around, orientation notch and all, and that the contract assembly company for Gravis compensated and installed them anyway, then there is no way it isn't backwards. I suppose it's possible, but I would be surprised.

OK I finally managed to obtain and fit the missing parts (C11, C48, and 93LC66/P). I haven't touched the ROM yet. When I insert the card into the PC (which normally works), it doesn't even POST. Sadly I don't have a speaker attached to hear any error beeps, but I do see all of the keyboard lights being turned on indefinitely.

Just had another look at your photo and besides the rom being reversed (pretty sure that removing it will still allow the card to work if it was working to begin with, ofcourse without synthesizer music) , it looks like the pins of the 7905 are loose.

Fixing the 7905 solder joints likely will not solve your current problem

The fact that it is stopping your computer from booting, will imply that it is somehow messing some signals on the ISA bus up. this could be as simple as one of the logic/buffer ic's or worst case the interwave chip itself.

This is a virgin memory dump for the Saab's 93 & 95 CIM modules. You must write it to the eeprom 93LC66 inside the CIM and then you will be able to program the CIM using a tech2 device with new keys (or even original keys of the car)

So I tried correcting mileage first Odo. Read 126494. Drove but no odo change. Then changed VIN, odo jumped to 126497 but froze there and set internal memory codes. I then installed original dump and just changed VIN. Odo jumped to 126500 and set internal memory code. I did not drive vehicle after last modification. Should I change mileage to all hex Os or Fs

Tried to write VIN as written in BCM. Tried including the bytes before VIN that are in BCM. Tried not including them. tried including them and writing the VIN from the decoded way of cluster. I will replay with update and bin files for anyone curious.

Well. There we go. So maybe I was writing it in 16(which is 93LC66) and the chip is a 93LC66A. I hope he gives me the chance to try again one I get his LEDs in stock! I have this gut feeling its a 93LC66A.

thank you thank you. The 93LC66 can be 8 or 16 bit while the 66B is 16. Tried to rush and install the org file under 93LC66 and then read and program under 93LC66B. No difference in Hex. When the customers LEDs arrive I'll have him come back and I'll take a crack at his file again.

I was just going through some of my AR32 documentation and they mention that the mileage (GM) is usually stored in 3 different locations in the eeprom for redundancy. If 1 gets corrupted the processor will rewrite it based on the values in the other 2 locations. When you edited the vin did you edit ALL the instances of the mileage in the file?

3a8082e126