mv1a not saving

[littlecharlie]

Hi, my mv1a is not saving hiscores or unibios options.

I have encountered this problem before in other boards and was able to solve it either fixing a broken trace or replacing a component.
But this time I think I have covered everything and still not working.

I've done the basics, like erasing the backup ram in the bios, and checking that the BRAMs get above 3V all the time.

I've replaced both upper and lower BRAMs with new RAMs chips, and the 74HC32 beside them as well, which sometimes is the culprit.

I've checked all traces and they all seem good. I've checked the connections between both BRAMs and the BIOS(SP1) and the 68k. All fine.

Any ideas?

 

[Neo Alec]

Have you done any battery mods?

 

[littlecharlie]

Have you done any battery mods?

I just removed the stock battery and replaced it with a socket and a LIR2430, so the charging circuit remains untouched.

 

[Neo Alec]

I just removed the stock battery and replaced it with a socket and a LIR2430, so the charging circuit remains untouched.

The replacement battery used to work? That's the part that was worked on, so it seems like the most obvious thing to double check.

 

[littlecharlie]

I didn't check when I got the board. I directly replace the old battery with a socket. The work was minimal.

I have done more checks: I've monitorized the pin Vcc of the RAMs in the Oscilloscope, and it goes from 4.8 v when on (5v power source) to 3.2 v when off (from the battery). No drop to zero in between. So the RAMs are getting enough voltage at all times.

I'm really missing what is going wrong.

 

[maki]

did you use a 161-in-1 cart?
IIRC those reset the settings/hiscores

 

[littlecharlie]

That's true, those carts erase hiscores but normally they don't reset the Unibios settings (if you set for example your board to "Console", it remains that way).
But in any case, for all the tests that I'm doing I only use original carts (just to avoid any malfunction due to the 161 cart).

The 3 saving features that are erased every time i turn off/on the board are:
1- Hiscores
2- Soft dipswitches (like blood on MS) settings
3- Unibios seetings (Console/Arcade and Region)

BTW, apart from that, the board works great (audio and video).

 

[ack]

I would try the diag bios and see if it finds anything. Backup ram is read-only by default and requires some logic for it to become writable. Perhaps there is something broken with that.

other random things

- make sure you aren't picking console mode in unibios. neo geo consoles don't have backup ram so the game wouldn't even try to save hi scores.
- any chance the backup ram is not original chips? its possible replacement chips don't support keeping their contents with only ~3V from a battery

 

[littlecharlie]

Thanks for the tips ack

The diag bios says all tests pass, and if a go to the specific BRAM test, it starts counting (not sure exactly what or up to how long), so I guess the BRAM is OK.
The second part you mention, you mean to check the signals WE/, OE/ and CS/?

Reagarding the new BRAM chips, there are not original (meaning they were not taken from another MVS), I bought them online . So it could be what you are suggesting (although I'm pretty certain I used the same brand/characteristics in another board repair).

Edit:
I added another 5v DC power supply directly to the battery circuit, so the RAMs get 5v at all times (when the board is on and also off).
Again, after an off and on, no settings are saved. So I'm ruling out that possibility.

 

[ack]

whats the model number on the chips?

 

[littlecharlie]

I've tried 2 brands, ISSI 62c256AL-45ULI and SEC KM62256CLG-7L
the orginals were UM62256DM-70LL

 

[littlecharlie]

I'm stuck with this.
The RAM chips are not the problem, I have replaced them with RAM chips working from another board, and still the same problem.

So far:
- checked both RAMs chips
- checked the 74HC32
- no errors with the diagnostic bios
- checked traces (they all seem OK)
- cleared backup RAM
- checked the battery circuit
- I have added (just to make another check) a continuous 5v independent power supply directly to the battery circuit, so the chips get 5v at all times. Still no saves after power off and on.

Any new ideas?

 

[Misos]

Hello. I had a similar problem with a mv1b and here is what I did:

-Unibios settings would not save after power off
-Used the diag bios and no errors
-Put a stock bios back and now I got a "calendar error"
-Put the diag bios back and used the main menu
-Calendar/IO test specifically
-The spected and actual numbers did not match up
-Measured the 32.7k crystal with an oscilloscope and it measured ok
-Checked the traces between 74HC32 and uPD4990
-all traces were ok
-Changed the 74hc32 and the PD4990
-The board now saves the settings


Try to use the Calendar and Backup test function in the diag bios and measure the crystal.
I also did the cr2032 battery mod.
Hope it helps.

 

[littlecharlie]

Hi Misos, good point.

In my case, no error either with stock, Unibios or diag bios.

I run nevertheless the calendar specific test and at first I though that everything was OK, because the numbers actual and expected seemed the same, until I found out that when the count reaches high values (the count is at super speed) and freeze it, the actual/expected values do not match, as you indicated.
So definetely something to look at!
The crystal is ok (strange that i's a 32,7 khz but it's labelled in the board as 32,7 Mhz), and traces are looking good.
So I'll replace the NEC chip (I ordered some but they won't arrive quick).

BTW, I have check the calendar test on another board with no problems (saving is working fine), and the differences between actual and expected also appear. Wierd stuff.

 

[maki]

I run nevertheless the calendar specific test and at first I though that everything was OK, because the numbers actual and expected seemed the same, until I found out that when the count reaches high values (the count is at super speed) and freeze it, the actual/expected values do not match, as you indicated.

If you could post the actual "high values" this could help, could be just some traces interrupted, quite easy to convert the values to Hex or Binary, so one can deduct the exact traces that are floating or not working.
If you have the decimal value that would help already IMO.

 

[littlecharlie]

So here is a little video

At first it seems there are no errors, but when you select 4096 hz and you get to higher numbers, you get some discrepancies like 5114 vs 5111 or 659F vs 659B or B7B1 vs B7AA

Still, as mentioned, I have a board that also shows this error, but the board works fine and is able to saves the settings

weird enough

so, in binary, these numbers are

0101000100010100
0101000100010001

0110010110011111
0110010110011011

1011011110110001
1011011110101010

the first two sets would seem to say that the error is in the 3rd "data"?

but the third set .... don't know how to interpret any of this

 

[ack]

There are 2 ways to get the pulse from the 4990 IC. IRQ and polling a register. The test is doing both and comparing the results.

The ACTUAL is the polling method, and the EXPECTED is the IRQ method.

My boards have a small drift on the 4096Hz method too.

 

[littlecharlie]

I'll try replacing the chip and see if it solves the issue

But I'd say I've checked everything that could go wrong

 

[littlecharlie]

I was checking another mv1a board that was saving the settings correctly, and I f*** up

My quickest way to know if a board is saving is powering off and on the board and see if the unibios settings are saved (the unibios has as default settings Europe and Arcade, so if a change to e.g. Europe and Console, if atfer power off and on the board enters in Arcade mode, then the back up system is not working).

Well, as I said, I have a mv1a board that was saving just fine (this board has the battery mod that disables the charging circuit and was working fine for months) , and (with the power off) I measured the voltage of the CR2032 battery (3,26V), and after reboot, boom, arcade mode.
So the fact that I measured the CR2032 with my multimeter (red probe to the battery itself, black probe to ground) has "destroyed" the saving capability.

How come?
Maybe my multimeter is faulty and has done some kind of short?

Can't I measure the voltage on the battery while in the board? (power was off).

 

[littlecharlie]

Out of ideas, I have removed almost every component on the back side, leaving only D4 that is supplying the power from battery.
I have even removed D3 that supplies 5v to the chips when the board is one.
And I expected that the chips will get 3 V from the battery at all times, but no, when the power is on, they get 4V (no 3V or even 5V).
¿?¿?
Where is this voltage coming from?