Region of system flickers in 240P Test Suite, Gentest Test Rom, and Version Register flickers between A1 (81 if Sega CD is attached), D5, and FF

[noobguy57]

When using 240P Test Suite on the Neptune, in the bottom right corner you will notice the region of the system flicker between North America and Europe. Further investigating this, on the Gentest Test Rom, the region also flickers back and forth rapidly, and the version register flickers rapidly from A1 to D5 and even FF (which shouldn't be possible).

This seems like a minor issue, and the Neptune passes the MARS Check ROM repeatedly, as well as passing all memory tests in the Gentest Test Rom for the 68000, Z80, and VDP, however in some games there is visual artifacting on the screen. The best demonstration of this is in Streets of Rage 2. The artifacting appears in NTSC mode, but goes away in PAL mode (however the version register and region still flicker in PAL mode).

This also seems to affect Sega CD reliably booting, although the full extent we have not troubleshooted, and a few resets eventually allow this to boot.

Video of the region flicker and register (happens in 240P Test Suite too, and DOES NOT happen with same ROM and same Everdrive on a Tower of Power).

Video of the artifacting in Streets of Rage 2 in NTSC mode (possibly other games too, once again DOES NOT occur on Tower of Power)

This issue occurs on 8 people's Neptunes (as of what we know) with everyone in the Dubesinhower discord having this issue.
This issue also occurs across installs that were both pre-populated birdseed and hand installed birdseed, as well as different PCB manufacturers.

Here is what has been done to troubleshoot:
Verify clock signal with oscilloscope, change crystal, and install Dual Frequency Oscillator (no change)
Verify no shorts on VDP, 68000, Z80, and their respective RAM
Removed PIC and hardwired NTSC or PAL mode to test (no change)
Ensured proper NTSC components installed, and PAL components removed
Ensured proper instructions followed for the diode or SCA chips
Lifted the NTSC pin on the Genesis VDP and tied directly to 5 volts (no change)
Tied a 4.7k resistor between NTSC and 5V at PIC location (no change)
Verified connection of all CLK related lines on board
Verify NTSC line from Genesis VDP is held high all the time via scope (it is held high)

And finally, here is Streets of Rage 2 on my tower of power, not showing these symptoms, as well as the same Gentest Test Rom showing a stable region and version register.

We are all out of ideas for what could cause this. At first, when it was one person, it seemed like a short. But then every single person without fail? Now we aren't sure where to go or what to look for next. Any ideas or possible remedies to try?

[SteveMaddison]

This is a real conundrum. The register containing the region information read by the game can only be in the VDP. Presumably the only input affecting it is a pin that, even when tied directly to a power rail, doesn't affect the issue. I can only image there is something very strange going on inside the VDP itself. It could feasibly be damaged during removal from the board but it seems unlikely that this would happen to so many. It could be down to decoupling or other passives that are meant to be on the VDP but I don't see any missing. I suppose the acid test would be to install a "suspect" VDP back into an original console and see if the issue follows. I do not at all suspect issues with the replacement power circuit although bypassing this would be a valid test to rule this out.

[noobguy57]

Your comment reminded me, we had a few people try swapping VDPs and the same issue occurs. People also opted to use low-melt solder to remove the chips to attempt to mitigate any damage possibly from too much heat.

The VDPs that the error is the exact same on are the 5660, 5708 and the 5487-01. This also happens with or without C11 installed, in both PAL and NTSC (on the EDCLK line).

I suspect the artifacting seen in Streets of Rage 2 is timing related, hence possibly a similar issue (does not occur on PAL mode for anyone, but NTSC the artifacting reappears) even though in both modes the version register and region still flicker. Could this possibly be an issue with the clock signal? Not too sure, we did scope out the clock and it seemed to be at the correct megahertz, voltage looked ok (but also depended on where exactly the clock was tested, therefore voltage was different in different locations), the only thing we noticed was that the duty cycle of the clock on an original system is 50/50, but the Neptune is 55/45. I have seen online and from others that this shouldn't matter, but just wanted to throw this out there for transparency.

We also recently tried adding in C9, C10, and C11 just as another point of data. No change with or without them in all region modes.

I am only a hobbyist, so my knowledge could be lacking and I may be wrong on this. The only thing we noticed in the original tower of power is that the region circuits are separate. We saw on the 32x that based on the region, the NTSC/PAL line on the 32X VDP had a pull up 1k resistor (NTSC) or a pull down 1k resistor (PAL) presumably to keep the line high and this is what causes the region lock. However, we also theorized maybe it has something to do with impedance? Not 100% sure, but just wanted to include all information and trains of thought we have stumbled upon.

[SteveMaddison]

Just adding an extra source of information on the different ASICs we might come across and their known limitations.

https://consolemods.org/wiki/Genesis:ASIC_Information

It would be interesting to see how similar these all are internally but I don't know of anyone decapping any of these chips.

[noobguy57]

I know some of them contain block diagrams that were from Sega, but not all of them. In the case of the 5660, the NTSC/PAL line is visible on there. Looks like a basic buffer going into the IC, then heads to some bus related lines. Some of the others don't have the block diagram which is annoying. I also don't unfortunately know if anyone has decapped one as well.

Is your build a pure PAL build? Does the region also flicker in 240p Test Suite?

So far we are out of ideas. We also tried with and without the cap array on the data lines from the 68000 going into the VDP, but no change in behavior there either.

[noobguy57]

Wanted to add some follow ups to better help context clues.

First, it is unknown exactly how the region register is written to. I do know some folks who work on BlastEm, so I can ask around there.
EDIT: Supposedly it's only determined by the JAP NTSC DISK signals. Which we have checked and tied to 5V to test.
I did check the 5660 block diagram and traced the bus line for NTSC and stuff goes into it. Noticed M3 all over. We tried lifting M3 right before the SMS Fix and tying it high with a resistor, no change. Figured maybe noise from the M3 pin but probably not.

I do have an idea for anyone that knows how to use a logic analyzer or who owns one:

The I/O chip can be easily found on Model 1's (or really any board revision before the large ASIC was used), so I would think someone would be able to probe it or use a logic analyzer to see what is written to that register. A simple assembly program could be written (if needed I could assist) that could only read to that register when you hit a button to help make a test case. That way, you might be able to determine normal behavior, and possibly correlate the I/O chip pins to the 5660's I/O chip pins and compare logic, or compare via an oscilloscope. The main issue is that we all know what is read FROM that register, but nobody seems to know what is actually written there, and it's seemingly not included in any of the official Sega manuals that are archived on the web. Tying NTSC pin, which supposedly "writes" to it, has no difference, so not sure there.

Also wanted to add another thing. Someone had some lifted pins on the 315-5818, and this was causing on MARS the SH-2 Master and Slave timeout error. So, before fixing these pins, we gave it a test in 240P Test Suite and Gentest. Same error occurred! This one is harder to draw conclusions from due to all the outside noise regarding variables at play, such as maybe the lifted pins were still semi-connected to the SH-2s/maybe the 32x side of the circuit was still alive despite this, but I wanted to share another data point in order to further help with this issue. Could possibly lead to the issue being on the Genesis/MD side of things.

Here's the block diagram I traced for anyone who wants to look or maybe point out a mistake I made.

[dr-goobur]

@noobguy57 would you mind re-uploading/posting your videos? I'm not seeing any obvious signs of the region switching you're mentioning in the 240p test suite -- all of my 5 units show no sign of this problem (I think, but I'd like to be sure).

EDIT: Nevermind, I'm seeing this in the gentest rom, and I'm seeing what I assume to be the artifacts in streets of rage. It'd be nice to have a fix for this, let me know if there's any way I can help.

Just thinking out loud: It's strange that the values roll between A1, D5 and FF; I've actually seen it also hit BF and 95, but I don't think this is helpful information. The only values we should be seeing on a build like this are 81, A1, 21, 01, E1 or C1, anything outside of that is sorta non-sense.

The error isn't a single bit being flipped in the register, so it's unlikely that the problem is interference on the NTSC line. However, I don't want to dismiss the impedance mis-match idea (although, I'm not an EE so I don't know if that's what the problem would technically be). @noobguy57 have you tried lifting the pins on the video encoder and 5781, then pulling them up as in the 32x schematic?

Additionally, does anyone have any inkling of how these registers are implemented? I.e. are they backed by DRAM or SRAM? If these were SRAM registers, then I assume they'd simply latch the DISK, NTSC and JAP signals (plus some constants for version) on /some/ clock (I actually would have guessed that these were latched on reset, because why would you need to change region on the fly).

Maybe it makes more sense that this register is backed by DRAM. That's probably why it's constantly refreshed (like I said, it seems strange to refresh this register at all). So perhaps the region issue is indeed a timing issue?

This is both an interesting and frustrating issue.

[v00dooperson]

Is there anything to be said for using the 32x bypass flexes, and testing this with only the Mega Drive components to try narrow things down?

[noobguy57]

This would be great to try. We believe its on the Genesis side, but it would eliminate 32x bus noise which would give a clue. If you have the means to do this, give it a go!

[noobguy57]

@noobguy57 would you mind re-uploading/posting your videos? I'm not seeing any obvious signs of the region switching you're mentioning in the 240p test suite -- all of my 5 units show no sign of this problem (I think, but I'd like to be sure).

EDIT: Nevermind, I'm seeing this in the gentest rom, and I'm seeing what I assume to be the artifacts in streets of rage. It'd be nice to have a fix for this, let me know if there's any way I can help.

Just thinking out loud: It's strange that the values roll between A1, D5 and FF; I've actually seen it also hit BF and 95, but I don't think this is helpful information. The only values we should be seeing on a build like this are 81, A1, 21, 01, E1 or C1, anything outside of that is sorta non-sense.

The error isn't a single bit being flipped in the register, so it's unlikely that the problem is interference on the NTSC line. However, I don't want to dismiss the impedance mis-match idea (although, I'm not an EE so I don't know if that's what the problem would technically be). @noobguy57 have you tried lifting the pins on the video encoder and 5781, then pulling them up as in the 32x schematic?

Additionally, does anyone have any inkling of how these registers are implemented? I.e. are they backed by DRAM or SRAM? If these were SRAM registers, then I assume they'd simply latch the DISK, NTSC and JAP signals (plus some constants for version) on /some/ clock (I actually would have guessed that these were latched on reset, because why would you need to change region on the fly).

Maybe it makes more sense that this register is backed by DRAM. That's probably why it's constantly refreshed (like I said, it seems strange to refresh this register at all). So perhaps the region issue is indeed a timing issue?

This is both an interesting and frustrating issue.

The register isn't actually a physical register. When you read from that register, the NTSC, JAP, and DISC lines gets put to the data bus, which therefore outputs its value. Originally I thought it was a physical register too, but that address simply allows for those lines to be pulled to the data bus and output. So it may be an issue with that bus or noise/impedance on those lines, but we haven't had any huge evidence towards it. As for pulling the 32x VDP high on that line, I don't believe anyone has tried or on the encoder side. People have mainly tried on the Genesis side. Worth a shot!

[dr-goobur]

The register isn't actually a physical register. When you read from that register, the NTSC, JAP, and DISC lines gets put to the data bus, which therefore outputs its value. Originally I thought it was a physical register too, but that address simply allows for those lines to be pulled to the data bus and output. So it may be an issue with that bus or noise/impedance on those lines, but we haven't had any huge evidence towards it. As for pulling the 32x VDP high on that line, I don't believe anyone has tried or on the encoder side. People have mainly tried on the Genesis side. Worth a shot!

That makes sense. A physical register (regardless of it being DRAM or SRAM) would be wasteful, and you could very well just multiplex (NTSC, JAP, DISC, 0, 0, 0, 0 ,1) on to the bus.

I lifted the NTSC pin on the video IC; the console boots (IIRC from the service manual, this is pulled high internally) but there's no change.

I'll lift the pin on the 32x VDP (and pull up if necessary) and see if that changes anything.

Although if there's no physical register in the VDP, then I suspect the problem to be on/with the 68k bus. We should try removing the 32x components as @v00dooperson suggests. I don't have the bypass flex cables, but I can remove the 5781, 5818 and 5805 and boot into gentest via a SegaCD (I've tried something similar when debugging my builds, the 5788 still partially works with this configuration, so you get some video out)

I just need to wrangle a windows PC to build the gentest diagnostic iso (and find my stack of blank CDs)

[noobguy57]

Yeah I am feeling that we are looking at bus noise, I wouldn't count out the Z80 since the 68k accesses Z80 memory starting at $A00000

[dr-goobur]

I did a bit of troubleshooting. I did exactly what I outlined above: Built gentest for sega cd (it built v1.1, but it's fine because the problem still persists with 1.1, albeit it doesn't flicker as much.) I removed the following (in order), then tested the system.

1. the SMS mod (74241); no difference.
2. the address selector (315-5805); no difference
3. the main control chip (315-5818A); no difference
4. the super vdp (315-5781A); no difference

The rest of 32x ICs don't touch the 68k bus, they're effectively just dangling on the board with some power applied. To me, this almost conclusively rules out any issues with the 32x side of things.

I'm not really sure what to suspect now. It can't be any of the 32x hardware contending or messing with the 68k bus. Maybe the z80 is suspect, now. What happens when you remove the z80, can the system still boot?

[noobguy57]

No the system will probably crash. A lot of games use the Z80 even if it's just to simply clear its memory on startup, which is a very standard practice. Or they use it as a DAC driver for channel 6 on the 2612. However it's good to know that it is probably on the Genesis side of things. We could however still be looking at a Z80 or 68k bus issue. There could be impedance issues still or possibly a need for a passive component on some of the lines. It does absolutely rule out the 32x though.

[dr-goobur]

I can confirm that the Sega CD will not boot without a Z80 -- it was worth trying. The Z80 is easy to get off (and back on) the board. A thought tho, is it possible to boot without the Z80 if the 5660 never touches the Z80 bus?

I don't see anything in the TMSS that would prevent us from booting without a Z80 (can I get another pair of eyes on that to validate this, thought?), and I do see a TMSS screen without a Z80. If we use a specialized build of GenTest without any Z80 init, it might be enough to get some code running without a Z80 and see if we can observe the issue. I can burn that to a ROM and build a test cart (to eliminate any chance of a flash cart doing some Z80 init when the menu loads).

I'm really running out of ideas, and I'd like to validate anything we possibly can.

One other line of thought I've been having, is that the caps on the Neptune board are not exactly 1-1 with their counterparts on the original VA1 board. For example, take C52 on my original VA1 board. It's is populated with a 28nF cap (I took it off and measured, should be 22nF according to the VA1 schematic, but I guess that's in spec enough).

C52 looks like it's additional filtering for CE30. The closest equivalent I can find on the Neptune board is C32 (there's no C52). This isn't a problem per se, but it suggests that there could be other labelling issues on the Neptune board. If there was a mistake in the VA1 schematic that @SteveMaddison used as reference for the genesis side of the Neptune, then a naming error could mean that the equivalent component on the Neptune is out of spec (which would affect builds that take all components from the Genesis).

Has anyone transcribed the VA1 schematic into KiCad and laid out a replacement VA1 board? That'd be a good reference to have.

We should probably cross reference the caps/resistors on a VA1 board with their respective locations (not names) on the Neptune boards.

I also have a cheap 8 channel logic analyzer I could hook up, but I don't really know what I should be probing (8 channels is sorta limited, I could probably get a few lines on the address/data bus). I'd like a more specific test-rom before diving into that (i.e. one that reads A10001 over and over in quick succession, just so that I have a high chance of seeing reads from that address). I'm not opposed to buying a 32 channel logic analyzer, but that'd take some time for delivery.

[noobguy57]

You should be able to ensure that the GenTest ROM does not contain any code that accesses the Z80. However, the 5660 does have direct connection to the Z80. The Z80 address and data lines head straight into the 5660. My guess is that it still wouldn't boot. I do have the GenTest source code if we need to make modifications for it. However yes you are right, it would be absolutely best to burn onto a ROM chip since the Everdrive has a very high chance of initializing the Z80.

I don't think anyone has transcribed the schematic, I think that is a good idea though. My guess is @SteveMaddison would have more context on some of those components. When I talked to some of the folks that help develop Genesis emulators, they suggested simply looking at the address and data bus of the 68k and Z80 with an oscilloscope and to make sure all the edges look very clean, things like that. Logic analyzer you might be able to get the entire Z80 data bus with just those 8 channels, which is what we are looking at anyways. Could help rule in or out the Z80.

In the TMSS source code, the lea into SetupValues is important to note. You can see it loads the Z80 bus request and uses that address in a1 to do some simple and cycle saving math to get to the version register and find the console version. Since you did say you got a TMSS screen without a Z80, we could try to modify the ROM and see. I might heavily modify the ROM so that it only goes to the status screen and shows the version register/region.