Neo Geo MVS not booting, any ideas?

Update:

Well i got bored waiting on the parts arriving from the USA so i moseyed on down to a local electronics suppliers just on the off chance they might have what i needed

and it just so happens they did.

grabbed 2x 74LS05 and a 74HC32

the 244 had already arrived, so soldered them in, fixed the lifted trace from the HC32 that was stubborn. made sure all the traces were ok no shorts etc.

And now i get: "Backup RAM Error: Address 00D00000 Write 5555 Read B240" - no more nasty random squares perfect black screen with perfect text.

this is with all the dip switches down, if they are up, i get the green screen rebooting loop.

so from some digging (not much lol) seems that HC32 is hooked up to a transisor C1815 which funnily enough is right beside the battery (there's two, different transistors there)

so hopefully once that is replaced they board should spring to glorious life, all be it depending on the top board and cart slots etc.

but Progress non the less!

 

The 74HC32 control chip enables for the clock chip and backup RAM. So no wonder it's having trouble to boot.

If you want to try games in it burn a UNIVERSE BIOS and play. You might want to fix it properly though as you cannot save settings without the backup ram being working right.

Razoola did an excellent job making this up:
http://unibios.free.fr/

Take the free version and burn on a chip then until your parts arrive you should be able to use your neogeo at least as if it was an AES.

Edit:

The transistor, I belive being a 2SC1815 (it's a Toshiba transistor as common in Japan as the BC548 is here and in Europe or that 2N2222 in the USA lol) is in a circuit which does detect when the NEO GEO has power, sending a signal to the 74HC32 to allow access to the backup RAM. That's called "SRAM WATCHDOG" and is meant to keep the data saved in it safe during power cycles.

 

i plan on getting a unibios but will wait as i currently have no rom chips or programmer(although have been looking into this the past few days)

i've ordered up some 2SC1815 from where i normally get my components, their shipping is fast so i should have it within the next few days.

Have also got a 4 slot board on it's way, which will need some work next

 

update: although not much of one, it now boots as far as "Backup Ram Error" 00D0000 5555 B240

after replacing the C1815 with a nice new one, although it was not faulty i just didn't like the corrosion on the legs
i've check the continuity with pins 20, 22 and 27 of the backup ram chips and and with the 74HC32, also that they're getting 5v ok.

today i'll order up some new sram chips as currently that is all i can think it could be if not i'm crap out of ideas.

 

That means the 68000 wrote 5555 and read back B240. That could mean the RAMs are not receiving the read strobe as the bus is open at the moment the 68000 read back.

Google for the pinout of the 62256 chip then watch the pins /CS (Chip Select) /OE (output Enable) and /WE (Write Enable) for where they go, if their traces are not cut.

I am sure the two /WE and /OE enables go to the NEO-C1 chip (the /WE ones first pay a little visit to the 74HC32 as it controls the rams when the main power is out) so check that out. Remember, the backup and real time clock do not work correctly if the 74HC32 isn't working right.

 

There is no NEO-C1 chip on the board, Chips are all there is a "PRO-C0" and "PRO-B0" "PRO-CT0" and "LSPC-A0"

data sheet fro the SRAM chips that are on the board:

http://pdf1.alldatasheet.com/datasheet-pdf/view/101826/TOSHIBA/TC55257BFL-10.html

all traces seem to be fine

 

A0/B0/C0 is 1st gen chipset. Rare so I assumed it was 2nd gen which is a lot more common.

 

looks to be the case, the 74HC32 was also replaced along with the LS05s and a 244 which got me from the non booting blocky squarey screen to this.

Still, Next on the list is the SRAM chips themselves and a Universal bios

 

Sorry for digging up this old thread...
I have an MV1FZ on the table with the very same reset-on-boot-loop symptom and I could really use some help.
No visible bad traces or corrosion on the board so far.
I installed the diagnostic bios including the m1 for z80-testing, it passes without errors.
The bios is ok, putting a unibios into the socket the symptom remains the same.
Switching all DIPs to "on" doesn't change anything.
When I install a bridge on J2 to disable watchdog the reset-loop stops but it stucks at the garbled screen.

I have an oscilloscope but I don't know how to tell if any of the LS/HC etc ICs is faulty.
Next thing on my todo-list is continuity-testing with the schematic between all ICs that are directly connected.

Any tips on how to approach this is very much appreciated. Thanks!

 

Check continuity on the 68k's data lines and lower address lines to the WRAM and BIOS, that's the most probable cause. It has to be in the 68k system, so if all those signals check out you're left with address decoding, BIOS vector-bankswitching logic, the 259 latch or the LSPC.

Normally with an oscilloscope you'd verify that each pin is toggling. From there you could make a reasonable assumption that chip inputs have continuity and that outputs are performing their logical function. Since the CPU is immediately crashing it might not be a reliable test in this case. You could try probing each WRAM/BIOS pin and manually resetting to watch for any activity I guess.

 

Thanks! Is manual resetting an MVS just grounding the reset-pin of the bios to trigger a soft-reset or do you mean turning the psu off and on?

 

The reset line is open-collector so you can ground it. I doubt it will save you much time to use a scope, I'd just check continuity myself. First I'd check (address lines) between the WRAM chips, then (address/data) between the WRAM and the BIOS, then either of them back to the 68k. If you don't want to work between two pinouts you can just use one and swipe the probe.

 

Thanks again!
To be honest the schematic that's available for the mv1.. on wiki.neogeodev is not very readable... I'm having a hard time figuring out what's interconnected to make the right measurements.
Here are some scans of the board, maybe you see something that I have overlooked:
https://www.dropbox.com/sh/pyr699vktgkhfwa/AABO_80HB9QqddIFnVQCiDiHa?dl=0

note: there are some spots that may look like broken traces but it's only dirt. Anyways, if you see something suspicious please let me know.

 

No need to use a schematic yet, all Neo Geos are conveniently wired with A0 to A0, D15 to D15 etc.

Just use the 68000, 62256 and 27C1024 pinouts:

http://www.jlr-blog.com/upload/1673020728.jpg
http://www.elecfans.com/article/UploadPic/2008-4/200841172657788.gif
http://circuits.datasheetdir.com/257/M27C1024-pinout.jpg

If you're not familiar with the 68k since it's byte-oriented but has a 16-bit aligned bus you must shift the address bits right 1 bit ie 68k A1-17 goes to SRAM/BIOS A0-16.

 

I managed to make a list of all connected pins I had to test.
They ALL tested positive.
Also I did some random scope-probing since I'm running out of ideas, the 68K, SP1 and Work- and Backup-Ram pretty much don't do anything.
I've ordered some of these to replace the work-ram and backup-ram: http://www.ebay.de/itm/190781435737
Also I've been looking for bad traces real hard with a magnifier but still I can't find any.

If anybody has a faulty mv1fz for sale I'd love to get it, disassemble it and make a continuity-checklist.
Thanks again!

 

Did you probe the 68k's control signals for activity? You can systematically work backwards to determine what's wrong from them. If you have a quiet bus immediately from a reset then make sure the 68k's clock is toggling and the 68k's actual /reset input is deasserted. I'd guess the 68k will continue to assert /AS even if it crashes, so checking that would be useful.

 

yes, if i remember correctly all the control lines were stuck high.

 

What does "to assert/deassert" mean? (sorry, not a native english-speaker)

Here's a rough overview where lines are pulsing and where nothing happens.

 

"Assert" means the signal's function is driven "true", so an active-low signal like control signals are pulsed to 0. "Deassert" means returned to inactive state, so returned to 1 for active-low or 0 for active-high. It's a useful term since saying low/high without respect to the active level is confusing in many situations.

When you say "nothing happens", what do you mean? What is the 68k doing?

Did you verify the control signal's continuity?

I don't think the battery backed RAM operation is necessary for the console to start, so focus on the 68k, WRAM and BIOS/SP1.. Now you must check SP1's /OE and the WRAM's /OE and /WE back to the address decoder C1.

WRAM (WRU, WRL, WWU, WWL) directly to C1
SP1 (SROMOE) to NEO-IO then to C1

SP1 is a 16-bit ROM and the C1 only provides 8-bit address-decoded OE strobes (SROMOEL, SROMOEU) so 8-bit ROMs could be used originally, the signals go to an AND gate within the NEO-IO to generate the single 16-bit /OE. Check the NEO-IO's inputs "ROMOEH, ROMOEL" and output ROMOE back to the SP1 /OE.

 

I got a bunch of 62256 SRAMs in the mail today, since I already desoldered the work-ram I had to take a break yesterday. But I successfully brought another AES back to life with what I've learned so THANK YOU for that!
Since the AES schematic is much more readable than what is available for the MVS the signal-lines-testing was much more comfortable. Which makes me wonder how different is the AES from an MVS anyway? Do the basic connections between bios, ram and custom ICs apply over different systems?
I'll get back to work on the mvs as soon as I replaced the ram this evening. Thanks again! This is so very much appreciated!