Hello everyone!
Long time since I last posted... a few years, actually. But I need some help, want to see if there is something more to check before condemning this MV4.
So, recovered a MV4 at a flea market, thought it would have been a decent replacement for my MV2, so took it home and did the usual check/cleanup before powering the board:
Which went decently good, discounting the Z80 that I did not initially test, I had an intermittent issue with palette addressing:
Notice that it is at the very start of the memory range, but also notice the read value: 0x1010, which is very interesting. If we check how the test is performed, here at line 187 in the check_palette_ram_address routine, we see that the content of each sequent bank is incremented of 0x101. This means that in the first bank we are finding what should go in bank 16, not random garbage, greatly reducing the chance of the issue being a bad RAM.
I investigated who takes care of handling those address lines for the pal memory, and it is the PRO-B0 in this board, handling PA4-PA11. I investigated PA4, as it's the first line that, if having an issue with being stuck high, would cause exactly the issue shown by the test.
Indeed, when the issue appears, PA4 remains stuck high.
This is when I found the following on the IC
That looks like a rupture crack, which does not bode well. Still, I wondered if that line was the only problematic part of the IC. In that case, address decoding of this type is a rather simple matter that could be bypassed with a properly programmed GAL. That is what I did: lifted PA4 from the board, and bypassed it with a signal generated with the following equation:
PA4 = A5 * A22 * /A23 (which means pass along A5 from the 68K to PA4 when A22 is high and A23 is low)
This worked, and I had the addressing test passing every time.
Now onto the Z80: I reinstalled the top board, inserted a test cart and performed the test. Or tried to. Unexpected SM1 response, the slot switch command was being ignored, and garbage returned.
I started to get really worried here, as the PRO-B0 also handles Z80 comms, but I found out that it actually was the 6116 RAM of the Z80: dead.
Replaced it, and now all tests passed, Z80 included.
I decided to test a game (using unibios) on slot 1, which worked, but with heavy graphical corruption:
I started checking for communication issues between the two boards, probing signals, but, at some point, things started to go bad:
unibios started crashing with an exception at every boot, inserting the diagnostic bios had all the tests passing (Z80 included), also repeated vram/work ram/palette ram test loops.
All fine, except that the screen was not outputting color anymore: colored bars appear solid white, the garbage shown during vram test is b/n only, except for a few rare cases where I get (wrongly) colored text at boot.
I tried undoing my mod for the address line bypass. No change, not that I was expecting it.
My opinion is that, given the PRO-B0 handles the palette part in the line buffers, its internal ram decided to finally give up the ghost and this is the result.
But I'd be very glad to be proven wrong, anyone has any ideas on what else I could check that could cause a similar issue?
Also, alternatively, if someone here has some PRO-B0s to sell (that have a chance of being functional) or a scrap board where I can pull one off, and is willing to ship to Italy (with me paying for both device/board and shipping, of course) let me know!
Long time since I last posted... a few years, actually. But I need some help, want to see if there is something more to check before condemning this MV4.
So, recovered a MV4 at a flea market, thought it would have been a decent replacement for my MV2, so took it home and did the usual check/cleanup before powering the board:
- Removed the battery
- Cleaned up the corrosion with vinegar/brush/isopropyl
- Noted there were quite a few traces clearly eaten around CN10, and lots of blackened vias
Which went decently good, discounting the Z80 that I did not initially test, I had an intermittent issue with palette addressing:
Notice that it is at the very start of the memory range, but also notice the read value: 0x1010, which is very interesting. If we check how the test is performed, here at line 187 in the check_palette_ram_address routine, we see that the content of each sequent bank is incremented of 0x101. This means that in the first bank we are finding what should go in bank 16, not random garbage, greatly reducing the chance of the issue being a bad RAM.
I investigated who takes care of handling those address lines for the pal memory, and it is the PRO-B0 in this board, handling PA4-PA11. I investigated PA4, as it's the first line that, if having an issue with being stuck high, would cause exactly the issue shown by the test.
Indeed, when the issue appears, PA4 remains stuck high.
This is when I found the following on the IC
That looks like a rupture crack, which does not bode well. Still, I wondered if that line was the only problematic part of the IC. In that case, address decoding of this type is a rather simple matter that could be bypassed with a properly programmed GAL. That is what I did: lifted PA4 from the board, and bypassed it with a signal generated with the following equation:
PA4 = A5 * A22 * /A23 (which means pass along A5 from the 68K to PA4 when A22 is high and A23 is low)
This worked, and I had the addressing test passing every time.
Now onto the Z80: I reinstalled the top board, inserted a test cart and performed the test. Or tried to. Unexpected SM1 response, the slot switch command was being ignored, and garbage returned.
I started to get really worried here, as the PRO-B0 also handles Z80 comms, but I found out that it actually was the 6116 RAM of the Z80: dead.
Replaced it, and now all tests passed, Z80 included.
I decided to test a game (using unibios) on slot 1, which worked, but with heavy graphical corruption:
I started checking for communication issues between the two boards, probing signals, but, at some point, things started to go bad:
unibios started crashing with an exception at every boot, inserting the diagnostic bios had all the tests passing (Z80 included), also repeated vram/work ram/palette ram test loops.
All fine, except that the screen was not outputting color anymore: colored bars appear solid white, the garbage shown during vram test is b/n only, except for a few rare cases where I get (wrongly) colored text at boot.
I tried undoing my mod for the address line bypass. No change, not that I was expecting it.
My opinion is that, given the PRO-B0 handles the palette part in the line buffers, its internal ram decided to finally give up the ghost and this is the result.
But I'd be very glad to be proven wrong, anyone has any ideas on what else I could check that could cause a similar issue?
Also, alternatively, if someone here has some PRO-B0s to sell (that have a chance of being functional) or a scrap board where I can pull one off, and is willing to ship to Italy (with me paying for both device/board and shipping, of course) let me know!
