SpritesMind.Net

When playing a rom through the UMDK it all works fine until some pcm type sound file is played and then the game hangs.
So if we take the common example of Sonic 1, as soon as the game starts you get to hear the wonderful "SEGAAA" sound clip, after which the game crashes (Illegal instruction $00071FC6 in this case).

The Lion King (a favourite of mine) gets further, but plays a clip of Timon saying "It Starts" when you select start, crashing the game.
Castle Of Illusion works fine, only your standard bleepy bloopy sounds (that's a technical term) in there.
Michael Jackson's Moonwalker works fine too until you do any action that makes him go "Aaow", which is almost everything. Playing the clip in the sound test will crash the game as well.

These games all work fine when played from their actual cartridges. I don't understand how UMDK could be causing an issue here.

Do you know which MD board revision you have?

I've been keeping a record of which MDs show this behaviour: https://docs.google.com/spreadsheets/d/ ... sp=sharing

Silkscreen says IC BD M5 PAL, checking out http://segaretro.org/Mega_Drive_PCB_revisions it looks like a VA6

Yeah they're the ones that gave me trouble, but other users have been praising them as rock solid with UMDK, so there must be another subtle difference we're missing.

Do you have any other MDs to try out?

Post your findings here and see if one of the hardware devs has any insights (I'm a software guy, sorry!): https://groups.google.com/forum/#!forum/umdkv2-dev

Tried on my other MD1 (same board, but with a different colour silkscreen) same issue

amushrow wrote:Tried on my other MD1 (same board, but with a different colour silkscreen) same issue

You are not on my list of customers, did you make this yourself?

The best thing would be to take a trace so that we can see how far it gets. Do you know how to do that?

Yeah, I've put this together myself.
Doing a trace is my plan for this evening, along with checking the expected behavior in an emulator

Just found an interesting artefact before looking into this more betterer. If i switch the console from NTSC to PAL while it's running, then it doesn't crash when playing the SFX. Or at least MJ's Moonwalker doesn't, although the game runs slow if you switch it when running.

So for today's pokes and prods I was using one of my Mega Drives which is modded with phono jacks for audio + composite so it doesn't need any special cables (the composite is pinched from the DIN so there's nothing fancy there, actually the audio jacks are currently disconnected so it makes the whole thing kind of pointless).

Using MJ's Moonwalker, when running through UMDK the colours flicker (red flickers green, some blue colours flicker magenta, green isn't used on the menu :p). Running off a regular cart is fine.

Probing EDCLK it's at the right frequencies and switches between 13.3 and 10.6 Mhz, but with the UMDK in the slot it seems to be picking up some other interference / jitter. Frequencies are still correct but there's some other much lower frequency running through as well causing the min and max voltage to vary. It's just not as clean.
Incidentaly when probing EDCLK with UMDK in the slot the picture gets worse, it also jumps up and down a few rows (I understand that the capacitance of the probe will be affecting it, but it doesn't bother the regular cart)

I'll get some screen shots of the waves tomorrow, as well as try to measure whats going on in the background.

So here's some shots of EDClk, triggered as it switched to 10.6Mhz

On a regular cart:


On UMDK:


And if you look in this pic you can see clearly that there's a repeating pattern running through, which repeats at about 251Khz


The attached zip contains a few more captures at the same point

What I can see here is that you're either loading the signal significantly or your equipment doesn't have enough bandwidth (or both).

As this clock signal is used by the VDP for video timings and DMA bus operations, when you probe it then the signal will have a slower edge delaying the DMA operations by a unspecified amount (since VDP, 68k and z80 are at play here, they need to resyncro themselves). The 68k releases the bus, and then DMA should start, although there may be a z80 access in there depending on the code.

In theory this should not affect the UMDK operation, but since it users are reporting various kinds of failures on the UMDK maybe it affects it somewhat (maybe it captures the access request too late, or doesn't capture it at all, or it's in the middle of a refresh. This is UMDK's business which I don't know how it handles things)

I don't think the 251kHz beating you're seeing on top of the EDClk is of any importance, obviosuly a higher power consuming device (specially dynamic power consuption) is gonna create bigger disturbances on the voltage rails, and consequently on the signals themselves compared to a regular cart that is just a mask rom. At any rate it's half of a vertical division so you're looking at 250mV of a peak. For instance my scope shows EDClk toggling from -0.6 to 5V normally (and I see half volt disturbances on top of it even when no cart is present).

What Mega Drive are those voltages from?
I've just checked on a Mega Drive II and I'm seeing EDClk go between 0-4.5V, is it possible that on some Mega Drives the signal is too weak?

I measured it on a european model 1 with TMSS (VA6) on the cart slot pin.
It could be that different revisions have different signal characteristics. I don't know if you noticed but there's RLC filter on the EDClk line probably to reduce signal reflections and/or EMI. This filter could have been subject to changes during the megadrive revisions.

What probe model are you using?

It's your cheap (relatively) chinese jobby - Hantek DSO5102P, but it comes under a few different names. For sure the probes won't be the best.

I meant the probe itself, it should have a model on a label/or engraved somewhere probably near the BNC plug. The scope is able to see 100MHz from the specs, but if the probe is killing it then there are no miracles.

If the probe has a 1x / 10x selection switch, then use the 10x attenuation setting as this gives much better frequency performance. (and set the scope channel to 10x too to cancel it out)