Williams joust PCB: cmos RAM error or write protect failure

[YellowDog]

The cmos is a 5114, not a 5116. 6116 won't work...

5114 is 1kx4, like a 2114, in an 18-pin dip.
6116 is 2kx8 in a 24-pin dip.

6514 will work if you can find it...

Good thing people sell adapter boards to put NVRAM or BRAM in place of 5114s in williams games

Thanks Mark. You are correct. I had just finished answering a question about the differences between the 4116 and 4164 RAM chips so I had 16 on the brain.

Thanks HudsonArcade for the advice

Yesterday i had the idea (i have not a logic probe ATM, so iam trying to debug the machine with some common sense ) to leave the machine turned on for 10 minutes... after something like 15-20 reboot, i had a messy "daily buzzards" image, then the joust logo appeared O_O... the image was not 100% ok because instead of the "presented by williams electronics inc" blu string, i had something like "GGGGGGGGGFFFFFFFFFFFFFFFHHHHHHHHHH"... could this be of any help to face the prob? I wanna remind that my EPROM reader reported all good ROM images... could it be that one of those is NOT so good?

Notice that i tryied to switch off the machine, but when i turned it on i had again the reboots and, again, i was able to play after lots of reboots... so, not something related to juicing and then heating up the PCB, i suppose.

Ah, and when i ended the game (that had some issue on collecting points and was givin random extra lives), on the daily buzzards screen i had again reboots.

Making some step further every day here

All of the gibberish you are seeing on the high score screen is the result of the CPU reading garbage out of the CMOS RAM. That is probably why you are getting reboots when the game starts and when it goes to the high score table. The CPU expects certain values in the CMOS and if they are not, it can lock the CPU up and cause reboots. Part of this is a side effect of the book keeping. The Williams classic games automatically update the book keeping totals after every game. One of those values is the time per game. If the value in the number of games is zero, you get a divide by zero error which trips the NMI and the game resets. There can be other math errors that will cause the same thing. Pretty much all of the classics suffere from this because nobody wanted to write new routines so everybody stole the ones that were written to either Stargate or Robotron and just made minor cosmetic changes to them. That is why the famous "more than 5 in the high score table" fix works. All the games stole the same code, so you just need to find it in the ROMS, patch it and adjust the checksum.

ken

 

[baritonomarc]

That is why the famous "more than 5 in the high score table" fix works. All the games stole the same code, so you just need to find it in the ROMS, patch it and adjust the checksum.

Thanks Ken, you are a guru for me

So, would it suffice to insert this patch to the ROMs to face my reboots? Where do i can find those (i suppose it's not sufficient to open the ROM files and modify them)? Do you think my CMOS needs to be substituted (with a 6514 or another compatible ROM)?

Thanks so much, it was exiting playing my joust even if garbaged , so i can only imagine the pleasure playing it full working!!

 

[YellowDog]

In this case, fixing the CMOS write issues will fix a lot (if not all) of the reboot issues. It comes down to a blind spot most programmers share, coding for success. The issues you are seeing stem from part of the code assuming that the CMOS has been successfully initialized. During the POST, part of the code examines the CMOS and determines if the high scores, bookkeeping or games settings needs to be reset. If it does, then those sections of the CMOS are set and life is good. Later the code that updates the bookkeeping runs and assumes that the CMOS is good, after all it was reset during power up if it was needed, right. Well, in your case, there is an issue with the data being saved so that the data in the CMOS is not correct. When it goes to use the data, strange things happen.

The solution is to find out if it is the CMOS that is bad and replace it. Or if the chips that control the write enable on the CMOS that are bad.

ken

 

[baritonomarc]

The solution is to find out if it is the CMOS that is bad and replace it. Or if the chips that control the write enable on the CMOS that are bad.

ken

Good, i can see the way now

I need some help to figure how to check the CMOS. Referring to the "DEFENDER theory of operation, later system boards" (but please remember that the PCB here is a Joust), the CMOS RAM is a 22 pins chip. It also reports that the chip is the "1E" and that it's a 5101 (fig. 3-16 on page 26), but i suppose it's a typo error: the CMOS RAM is 1C, 5114 or 6514 in Joust (and also in defender considering that that part of the PCB is exactly the same from the images i can see on the net). Now, referring to the 3-16 figure, how can i certify that my chip is 100% working? I suppose the voltage that it receives must be measured on pins 8-22 (GND-Vcc... the correct value should be from 4.80 to 5.00 V, right?), but what other pins should be tested? Could it be that (with the power on) i must see a low signal on pin 18 (read), than an high signal (write)? Would this chip be declared "dead" without a signal or an intermediate signal on this pin?

A logic probe is in it's way to my house

Sorry for all the questions, but i have only a little "light" on this charming matter and i need to direct it right

 

[YellowDog]

The CMOS in Defender was a 5101. It was changed in the Stargate and later boards to a 5114 and the position on the board changed.

The supply voltage is actually on pin 18 & pin 9 is the ground on the 5114 chips, IIRC, check the schematic to make sure.

ken

 

[baritonomarc]

Thanks Ken. Is measuring the voltage sufficient to determine that the chip works? Should i check some pin in particular?

Much appreciated

 

[YellowDog]

Measuring the voltage is just sufficent to show that it is getting enough voltage to work. It really does not say anything about the innner workings of the chip. It is useful as a diagnostic tool because if the voltage is bad, then there is no point in testing the chip further until the voltage issue has been resolved. If the voltage is good, then the next step would be to use a logic robe to determine if there is pulsing on all the address and data lines. If there is, then it is time to try pulling the chip, socketing it and putting a new chip in.

I tend to be somewhat conservative about yanking chips out. Every time you do, you run the possibility of damaging the traces on the circuit board. Then you have even more stuff to replace. So unless you have an expensive solder rework station and you do circuit board rework all the time, it is safer to eliminate all of the other possibilities and leave chip replacement as a last resort.

ken

 

[baritonomarc]

Again, thanks for this course . So, if i have a pulsing signal something is wrong?

If the voltage is good, then the next step would be to use a logic robe to determine if there is pulsing on all the address and data lines. If there is, then it is time to try pulling the chip, socketing it and putting a new chip in.

 

[YellowDog]

It is one of those chicken and egg issues. You should see pulsing on a logic probe (a multimeter will probably not be fast enough to see the states change) on all the data and address lines. This indicates that the other chips and may indicate that the CMOS chips is bad. On the other hand, if any of the address lines or data lines are not pulsing it may indicate that one of the other chips is not functioning correctly. There is always a possibility that it is the CMOS chip that is bad and holding the address or data line or in the first case, it may be ignoring the data writes and responding to the data reads with gibberish.

In a lot of cases, you have to play the odds and pick the best place to start. That is assuming a single chip failure. There is not always a single clearcut right answer, but there are always plenty of wrong answers. Ultimately, you have to pick one and see if it makes things better or worse, or does nothing at all. Hopefully, if you didn't hit the right one, it will give clues to allow you to try something else to get closer to fixing it.

ken

 

[baritonomarc]

Thanks

So, going to the bone and reassuming all the gold you are donating to this post : in general, to check A GENERIC IC chip the procedure could be:

- visual inspection to see if legs are corroded/oxidized. A cure could be to reseat it if socketed.

- check the voltage going to the chip (value reported in the chip datasheet). If the voltage is not the right one, the chip cannot work correctly, so this is the first thing to do.

- check the other pins. Signals can be of two types: High/low or pulsing.
A typical pulsing signal comes from address/data lines. if some address/data pin is not pulsing the chip could be bad (holding the address or data line) or some "surrounding" chip could be bad (not giving the signal to be processed and addressed).
A typical High/low signal comes from Read/Write (R/W) pins. These pins give a high or low signal depending on the logic state. Studying the circuit can help inducing a high-to-low or low-to-high signal. If the signal is intermediate/indefinite or there's no signal at all, the chip could be bad.

Just a question: are address/data pins ALL used or is it possible that some circuit ignores some pin thatn givin no pulsing at all on that pin?

Please add and correct these basic concepts and feel free to add any additional info, sorry if this can considered as off-topic but i think i am not the only one trying to learn somehing more on this argument

PS: today i had some spare time to spend on the study of the Joust schematics. I had no probs finding out datasheets for the components of the memory protection circuit, but it looks like not datasheetsarchive, nor google can be of help finding out the datasheet for 5114 or 6514 1K X 4 CMOS static RAM... could someone please upload it or give me a link?

 

[HudsonArcade]

Just check the voltage... the blocking diodes for the +5 are right near the battery, and quite often they get corroded away... that's the #1 failure I've seen (other than blown chips).

 

[delroy666]

PS: today i had some spare time to spend on the study of the Joust schematics. I had no probs finding out datasheets for the components of the memory protection circuit, but it looks like not datasheetsarchive, nor google can be of help finding out the datasheet for 5114 or 6514 1K X 4 CMOS static RAM... could someone please upload it or give me a link?

http://www.jrok.com/datasheet/mws5114.pdf

 

[baritonomarc]

SOLVED!

I finally had the time for remove the CMOS and substitute it with a brand new 6114 CMOS: now the game pass the POST without rebooting!

Not checked if it doesn't reboot after long periods of gaming, but i am confident with it

Thanks for all your suggestions and help getting this great PCB play again dudes!

 

[RobMcRaf]

I know this is a thread-ressurrection, but just wanted to add one little tidbit to the CMOS corruption error problem.

A friend asked me to take a look at his REV B MPU board. Was giving some indications of corrupted CMOS, etc. Asked if I could take the CMOS out and put in another one. Sure.

So, I test it and yep it seems corrupted. Can't reset it, change it, etc.. Look up getting the replacement parts and if I can even use 2114 in place temporarily.

Then it dawns on me: How about removing the batteries on the PCB?

Did that, ran through the resetting, and then put the batteries back in while it was running.

Works like a champ.