AES failing VRAM DATA test on Neo Diagnostic BIOS

[kazuo]

Been messing with an AES off and on for... a while. Finally got it to boot with the Neo Diagnostic BIOS, and I'm getting this error:

VRAM DATA 0000
ADDRESS: 008000
ACTUAL: 4000
EXPECTED: 0000

My initial guess was "cool, time to swap the VRAM out", but the documentation seems to suggest it is unlikely to be the VRAM:

RAM address errors​

RAM errors which appear to be caused by bad address line traces are reported as address errors. Refer to the pinout for the type of chip used by the given RAM and ensure that the given group of 8 traces are all good. It's possible but unlikely for an address error to be a faulty RAM.

Anyone have any ideas on the next best steps here? I'm buzzing out the VRAM vias to the 68K, and so far so good... leaning toward socketing & replacing unless anyone has better ideas. I assume this would be the Sony CXK5814P chips.

Thanks!

 

[Kujako]

I'd swap the VRAM and see if the issue goes away. While I get what the documentation is saying, changing out the VRAM is a fairly easy thing if you have a hot air station. If the problem persists it's clearly an issue elsewhere, but if it goes away...

 

[Ryoandr]

It's a data error. The quote you posted is for address error.
Bad ram chip is very likely in your case

Also it's at 008000 which is the start of 4k / Fast vram, which are usually in DIP form (the CXK5814 in your case as with most AES I believe)

 

[kazuo]

Thanks both! I think I suspected I misunderstood that bit on the page at some point, but I glossed over it and decided to swap the VRAM anyway… it was a pain since I don’t have a desoldering gun right now, but I managed to get it done. I swapped the upper chip since I saw a diagram that indicated the associated address space was on that particular chip.

Still have the same error! Frustrating. I can only assume I swapped the wrong one, unless something else is wrong. I read that it’s possible to short pins 13 & 14 to test which one is bad, so I might do that to try and see if I did in fact switch the wrong one. If the error doesn’t change, I guess I’ll try buzzing out the LSPC2 again.

 

[kazuo]

Quick update: I decided to just socket the upper VRAM before going any further; got the exact same error regardless of which chip I was using (original vs replacement). Booting it with no VRAM in the socket throws a "Dead upper VRAM output" error, so I'm certain I'm working on the upper chip.

Would love a sanity check from those with more experience than me to ensure I'm not goofing on this and working on the wrong chip. Will also try buzzing everything out again over the next few days and see what happens.

 

[ack]

I would hold A+B+C+D down when you boot to bypass automatic checks. Then manually pick testing 32K vram (2k vram test runs before 32k in automatic testing). If you get the same bit error on 32k vram test it would be an indication that data line is bad between the CPU and the LSPC, which is then propagating to the 2k/32k vram. I suspect this is not the case since text on screen would likely be busted.

Use a multi-meter and check continuity between the LSPC fast vram data (F0-F15) and the 2k ram chips. Based on your original error, F14 is the one having issues. Also just check of the associated F pins on the LSPC aren't loose.

 

[kazuo]

Thanks! No errors on 32K, passes endlessly. I had also checked all the pins on the LSPC32 (Barring any missed cause they’re so tiny!) and nothing loose.

You’re a wizard, cause I checked the trace coming off F14 and I found the teeniest tiniest bit of corrosion right before it disappears below the lower VRAM. Scraped the mask, no continuity. Jumped it, restored continuity, ran the test again and now it seems like there’s an issue tied to the lower VRAM LOL

ADDRESS: 008201
ACTUAL: 0001
EXPECTED: 0000

I’m gonna try to buzz out the lower VRAM next I guess. Guessing I can use this to verify? I’ll just buzz on both ends and only try to follow the trace if there’s no continuity since I don’t have magnification to follow them all end to end.

Appreciate the help!

 

[ack]

Since the address (0x8201) isn't at the start of the 2k region (0x8000) I think its more likely the lower 2k ram chip is just bad. If it were a bad trace it should have triggered at the 0x8000 address like your original error. However I would still do the continuity check first just to rule it out.

That schematic page should work. There is also this one which is more readable

https://github.com/Board-Folk/NeoGeoAES-3.5/blob/main/NeoGeoAES3_5-Schematics.pdf

 

[kazuo]

Oh wow, thanks for that link! I found the factory (?) schematics to be nigh impossible to figure out (I'm not the most seasoned vet at making sense of this stuff), but I tried anyway. This will definitely be useful since I am planning to swap the BIOS shortly.

Speaking of which - it works! I think. Here's what happened...

I decided to just buzz out every single pin between the VRAM and the LSPC2 on both VRAM chips, and I found that there was a pin on the lower VRAM that didn't have continuity with the LSPC2 (I believe it was C8 ). I couldn't really make sense of the VRAM pin layout from the factory schematic and I didn't want to guess, so I reverse engineered it by verifying the surrounding pins (since all of those worked), and then I ran a jumper wire between the LSPC2 and the VRAM pin. Booted up, ran the diagnostic, and everything passed. Graphics look perfect now. I really wanted to repair the trace without running a jumper, but I followed it from the LSPC2 all the way to the via, then on the bottom of the board to another via, then I couldn't figure out where it was going anymore and I decided to just jump it.

One other interesting thing to note: The system seems to inconsistently boot games; I will randomly get a bunch of distorted signal garbage, or a solid grey screen from time to time. Eventually, it boots, and once I've gotten it to boot, it will boot consistently even if I change the cart out. I currently have the board decased and laid out on a table, and I did notice that nudging the cart a little seems to help, so maybe it's not really a problem once I get it back into the shell. I also blasted the cart slot with Deoxit (but I had done that already previously), so maybe that'll help if it's dirty or oxidized. The carts have been painstakingly cleaned prior to use.

 

[kazuo]

You know how they say "no news is good news"? Well...

After cleaning the cart slot with deoxit and a light reflow of the cartridge slot, I'm back to getting VRAM errors.

VRAM DATA (5555)
ADDRESS: 8000
ACTUAL: 1555
EXPECTED: 5555

I also got 1755/5555 at one point.

This seems to suggest it's an issue with the upper VRAM again, but after buzzing out every leg of the upper VRAM against the LSPC2... everything is continuous. Running the 32K VRAM test passes without issue. At one point, I also got a random "DRAM DEAD OUTPUT (UPPER)" (????), but I couldn't reproduce that. I also have to power cycle the console even more than I did before in order to get the diagnostic to start running.

Any pointers appreciated, I might just give up on this thing if I can't make any progress.

 

[leonk]

I recently fixed bad VRAM on an Neo Geo AES with similar issue. Here's what I suggest you do:

- socket both VRAM chips
- swap the 2 position. You seem to have an issue with the upper bits of the VRAM chip, but the lower passes. Lower is tested first. Swapping chips will confirm the issue is with the chip and not connection between chips and LSPC2.
- get a new chip **

** - get this from a reputable source. My customer provided a set he got from AliExpress. While they all passed on my Retro Chip Tester, they failed in the system. I suspect they're too slow (VRAM has to be 35ns or faster) I ended finding a good VRAM chip in a spare NES board I had kicking around.

 

[kazuo]

Thanks, Leon! I had actually tried a new-to-me VRAM chip I sourced from buyicnow, got the exact same problem. That said... it's fixed now!

What was the problem? Who knows. I know, anticlimactic... I doused the board in IPA and cleaned it up, and while I was doing so, I noticed a few small solder spatters floating around, as well as a few rogue pieces of copper strands (probably from when I was running jumpers to test things). After that, I hit the cart slot with deoxit again, dried it all up, problems went away. Ran a soak test for a few hours with SamSho 3 on a loop, didn't crash, no glitches. Diagnostic passed repeatedly before I switched it to a UniBIOS.

Thanks to everyone who helped! Now I'm on to trying to fix yet another busted AES I stumbled upon...