MD hangs after playing any PCM file

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Tue Apr 11, 2017 11:51 pm

I'll have to check any FPGA changes tomorrow, for now it's another dump of interesting information, which somebody somewhere may be able to make sense of.

So, I've seen the noise on CAS0 but it's a very thin lonely slice of what's going on. So I've plugged in my super cheap logic analyser, and while it's at its limit here it still manages.

Just after the noise CAS0 completely loses it's groove before staying high for what seems to be an extraordinary amount of time, and the pattern is always exactly the same. Let's take a peek at some expertly put together screen shots of some logic traces for the opening of Sonic 1, I'll attach the Sigrok sessions so you can play along at home (I've been using PulseView)

Top trace is CAS0, the next is BR (handy for seeing when stuff starts to go down)
UMDK_NoiseLoc.png
UMDK_NoiseLoc.png (21.97 KiB) Viewed 1800 times
From top to bottom, we have a wide shot of whats going on where's I've marked the start of the "SEGAAA" sfx, then we zoom in and see a large gap in CAS0, zoom in to where BR asserts just before it, and you get to see our extra blip in CAS0 (my logic analyser isn't good enough to catch the smaller bits of noise).

This blip, and the following gap aren't always in the exact same place, sometimes it's on the 3rd assert of BR after the SFX, and other's it holds on a little longer like this trace.

But now for a game of spot the difference:
SpotTheDifference.png
SpotTheDifference.png (49.41 KiB) Viewed 1800 times
Why does the 68K start giving in the beans on R/W at the start of the sound effect, when this is supposed to be the Z80's party?
It does look like it starts going wrong at the same time as the noise but, eh, I don't know.

Sigrok Sessions of the traces:
Sonic1.sr
Sonic1_UMDK.sr

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Wed Apr 12, 2017 2:04 pm

If you correlate the logic analyzer output with an instruction-trace from the UMDK, you'll get a better idea of where the R/W foo is coming from:

Code: Select all

$ loader -w $HOME/sonic1.bin:0 -x 2 -t trace.bin:1024
UMDKv2 Loader Copyright (C) 2014 Chris McClelland

Putting MD in reset...
Writing SDRAM...
Releasing MD from reset...
Dumping execution trace to trace.bin:1024
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Finished!
$ logread trace.bin | grep -v HEARTBEAT | less
If you use "/" in less to search for "RD 079688", and hit "n" to get the second such read from that address, you'll see the first PCM word being read. On my PAL MegaDrive it is at timestamp 155,154,044ns in the trace (i.e, about 155ms after reset):

Code: Select all

155153899 C RD 071FC4 4E71
155153924 C RD 071FC6 51C8
155153949 C RD 071FC8 FFFC
155153987 C RD 071FC4 4E71
155154013 C RD 071FC6 51C8
155154044 C RD 079688 9496  <-- Here
155154107 C RD 071FC8 FFFC
155154158 C RD 071FC4 4E71
155154183 C RD 071FC6 51C8
155154208 C RD 071FC8 FFFC
155154246 C RD 071FC4 4E71

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Wed Apr 12, 2017 6:57 pm

The noise is identical with the test FPGA gubbins. We still have the extra deassert that shouldn't be there, which doesn't look like noise (not to me anyway):
Bonus Deassert.png
Bonus Deassert.png (3.65 KiB) Viewed 1769 times
80ns/division

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Wed Apr 12, 2017 9:29 pm

I've finally found another sign of something going wrong apart from CAS0, some of the address lines are showing something. A few of them are switching to ~1.5v during the problem.
I repeatedly saw A15 drop from 5v (to ~1.5v) and A08 & A11 rise up to ~1.5v

A08 MegaDrive Side:
A08_MD.png
A08_MD.png (6.1 KiB) Viewed 1761 times
A08 FPGA Side:
A08_UMDK.png
A08_UMDK.png (6.89 KiB) Viewed 1761 times
I don't know if these signals occasionally sit at this level during normal operation (it's not something I can trigger on), but I've not seen it.

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Wed Apr 12, 2017 9:46 pm

How consistent is the time between the /OE assert and the rising-edge of the first spurious spike? I'm thinking of putting an output (maybe on the spare unused output currently labelled mdDTACK_out) to identify the Sonic1 PCM range, so we can see that alongside /OE.

Regarding the address-line drift, digital signals don't do that unless there's contention (i.e multiple drivers) or it's floating (i.e zero drivers). I don't know enough about the MD hardware to hazard a guess.

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Wed Apr 12, 2017 10:27 pm

prophet36 wrote:How consistent is the time between the /OE assert and the rising-edge of the first spurious spike?
From a sample size of about 10, the address lines always rise up (or drop off) at the same time at the unwanted deassert of of CAS0, and they pick a very unfortunate level to sit at which tickles the buffer's triggering voltage. Spikes on the address lines FPGA side roughly match the what we see on CAS0, but there are a few address lines doing this.

Also, my oscilloscope has the option to persist wave-forms on the screen after they whizz by. This does seem to be normal behaviour for them. Looks like the address lines left to do their own thing for periods (where they very slowly rise towards 5v), and they also sometimes do what I've shown here where they jump to 1.5v for a bit (multiple drivers possibly, like you said).

User avatar
HardWareMan
Very interested
Posts: 715
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: MD hangs after playing any PCM file

Post by HardWareMan » Thu Apr 13, 2017 5:46 am

Pity that I haven't UMDK, but maybe somehow my records from IC BD M5 VA1 with running the Sonic 1 on FLASH card will help. The legend:
Yellow - CE0
Cyan - VA15
Purple - DTACK
Blue - CAS2
Here the moment of ending "SEGA":
Image
Image
Image
Image
Indeed, there is bus floating. But in my case it always in CE0 passive state. Note that DTACK has pull up, but it still too slow (but works OK).
Image
Image
Image
Image
Your case with VA4 board can has two reasons: there is chipset problem or there is UMDK problem.

If it chipset side, I see it like combinational logic from VA23:VA22 without any syncing to M68K's AS and some gating signal from VDP's DMA. That can cause false CE0 assretion, that acceptable to ROM or SRAM, since it don't make bus contention but it breaks UMDK's state machine logic, that goes out of sync and can't give true data when it needs. Thus we can't fix it, only make some workaround. Using CAS2 is better idea, but we already discussed here.

If it UMDK side, I have some questions. Is UMDK has abilities to drive VAxx bus (can create bus contention)? Maybe not designed but accidentally? How really controls VDxx bus? Is it strobed by CE0 and CAS0 instead of CAS0 only? Output buffers must be gated with this two signal together, because not matter is them wrong or glitchy but system waits that is simple memory device.

I hope I'm was clear enough.

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Thu Apr 13, 2017 9:46 pm

HardWareMan wrote:How really controls VDxx bus?
It's controlled by the state-machine in the bus-arbiter. It's the std_logic_vector "mdData_io". Normally it's tri-stated, but several states drive it with a signal registered from the last word read from the SDRAM controller.
HardWareMan wrote:If it UMDK side, I have some questions. Is UMDK has abilities to drive VAxx bus (can create bus contention)? Maybe not designed but accidentally?
The FPGA has the address-bus declared as inputs. The bridge-board has three 16-bit buffers. Two of them are hard-wired in the MD->FPGA direction, and the third (for the data-bus) is bidirectional. So I don't see how the UMDK can possibly be contending on the address-but. However, the address lines in the 'scope traces above look like they're floating to me, not contending. So it looks to me like the address lines float, causing sharp spikes in the bridge-board buffers, which cause crosstalk with the (also floating) /OE (or CAS0, whatever you want to call it) signal.

What about the idea of adding a pull-up on /OE, on the MD side? A 4K7 would mean an extra 1mA from the regulator during assert periods. Or a 10K would be 0.5mA. It would prevent its buffer channel from picking up interference from the thrashing address lines, thus preventing the FPGA from thinking there's a new bus-cycle beginning.

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Thu Apr 13, 2017 11:13 pm

Not had much time to check anything today, but:

Pull Up on CAS0 - no effect
Pull Down on an address line - At the point of our error you can see that when it reaches 5v it slowly falls off instead of holding there, but the 1.5v period still remains. So something is keeping it there.

Also, if there is something we can detect in the UMDK for when this stuff happens would it be possible (with a change to the bridge board) to drive the Buffers' OE pins to disable all input during these periods?

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Fri Apr 14, 2017 3:46 pm

OK, try this new FPGA binary. It stops driving the data bus soon after /OE deasserts, and it refuses to return the state-machine to the idle state until /OE has been deasserted for four consecutive cycles.

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Mon Apr 17, 2017 12:00 am

prophet36 wrote:OK, try this new FPGA binary. It stops driving the data bus soon after /OE deasserts, and it refuses to return the state-machine to the idle state until /OE has been deasserted for four consecutive cycles.
Still no better.

I feel the issue is with those address lines sitting at 1.5v, a whole bunch go to 1.5v at the same point (well, roughly). This behaviour of the buffer is undefined at this voltage and it seems to flip between high and low, and I reckon that's whats causing the noise on CAS0.
I've yet to check to see if the MDII ever puts the address lines at this voltage.

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Mon Apr 17, 2017 9:14 am

amushrow wrote:Still no better. [...] This behaviour of the buffer is undefined at this voltage and it seems to flip between high and low, and I reckon that's whats causing the noise on CAS0.
I agree. Unfortunately, if this is the case, then the problem cannot be fixed properly without significant changes to the hardware. The aim of the new FPGA binary was not to fix the noisy-CAS0 problem, the aim was to (hopefully) ignore the noise on CAS0. So the question is, with the new FPGA binary, does your MD1 still actually crash when playing PCM samples?

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Mon Apr 17, 2017 10:53 am

Yes, it does still crash. I'll look a little more in depth to see if it's still doing exactly the same thing

We'd have to drop the voltage coming in to the bridge board for the address lines, it may be possible to just use a diode but there's very little current flowing (basically none, less than a microamp by my calculation) so it may leak through and you wouldn't see a drop in the voltage. If that where the case you could then put a resistor to ground after each diode, like a voltage divider.
Or just use a resistor to try to drop the voltage, but it may be difficult to knock enough of the 1.5v without taking too much out the the 5v signal.

It'd be very tedious to stick on on extra 23 (or 46) components to the bridge board though. Unfortunately I can find any IC's that could be dropped in place that have a LOW voltage of higher than 0.8

Info on the address lines
The Mega Drive will supply ~50mA to the address lines (that being a hard limit, not whats actually safe) but you only need to pull through around 50uA to get a diode to work properly (depending on which one you get).
It looks like it tops up a capacitor to keep them at 5v, so if you take too much current it will droop.

User avatar
prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: MD hangs after playing any PCM file

Post by prophet36 » Mon Apr 17, 2017 11:36 am

This is getting way out of my depth (as I said before, I'm no electronic engineer; I deal in 1s and 0s, not voltages and currents).

Is it possible to check to see whether or not this address-line contention happens during Z80 arbitration even with a regular (i.e non-UMDK) cart?

What about replacing the buffers for the address-lines altogether, and replacing them with simple voltage-dividers? Or would that make the address-line rise and fall times too slow? The other thing is that if a ~1.5V input to the level-converters causes havoc, it's possible that a similarly-ambiguous input to the FPGA itself will cause similar havoc.

amushrow
Interested
Posts: 42
Joined: Mon Jan 02, 2017 12:56 pm

Re: MD hangs after playing any PCM file

Post by amushrow » Mon Apr 17, 2017 12:41 pm

I can't trigger on the event specifically, but by upping the persistence on the scope (so traces stay on screen for longer) I've seen it on a regular cart.

This ain't my thing either really, I'm just learning things as I go here.
I can string together some resistors and see how the MD behaves with a voltage divider attached to one of the address pins.

So long as the voltages are <0.8 when low and >2.0 when high (and not higher than what, 3.3, 3.6v? for the FPGA), everything should be great.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest