MD hangs after playing any PCM file

[amushrow]

I'm pretty sure this bus abnormality is not there in normal cases.

I have observed the address lines holding at 1.5v on a regular cart too. The MDII doesn't display the same behavior.

[Jorge Nuno]

I'm sending this out during this week to a PCB fab, just need to do second review.

RevisedUMDK_S.jpg (157.14 KiB) Viewed 27138 times

4K Res: http://img.ctrlv.in/img/17/05/29/592b6f95c932d.png

Board is 2-Layer and all components are on top side. Passives are 0402 which could be tricky for hand soldering (I'm able to do it fine)
SD Card was changed to micro due to space constraints.

I'll report again soon

[prophet36]

Great work!

[amushrow]

So whenever I get near the end of a project (or video game, or most things) I get distracted by something else and then it's an age before I get back into it.

But I finally have an update.

The pcb I designed with zener diodes to limit the voltages going to the fpga works a treat, signals are much less noisy without the bus switching rapidly when the address lines are left floating.
The bad news is that it didn't fix the issue when playing PCM files.
The good news is I've fixed it in the firmware.
The bad news is I don't know why it's fixed, I was trying to eliminate some other noise I'd seen and while everything seems to work properly on the MD Mk1 (VA6 I think) the noise is still there.

I'll look into it more betterer tomorrow and see if I can find what I've managed to accidentally fix. I'll also have to assemble another bridge board using the original layout and see if it works with that too.

Also, Happy New Year!

[prophet36]

Which firmware are you talking about?

Happy new year to you too!

[amushrow]

In the main UMDK firmware, in the memory arbiter.

I've looked into it a little more this evening, it seems that waiting an extra cycle after

Code: Select all

 mdAddr_sync(22) = '0'

before driving the bus keeps the Mega Drive happy.

In my case the final minimalist change was to replace add an extra state into the S_READ_OWNED_WAIT flow, like this:

Code: Select all

when S_READ_OWNED_WAIT =>
	mdData_io <= (others => 'Z');
	mdDriveBus_out <= '0';
	state_next <= S_READ_OWNED_WAIT_OHMY;
				
when S_READ_OWNED_WAIT_OHMY =>
	mdData_io <= mcData_in;
	mdDriveBus_out <= '1';
	if ( mcRDV_in = '1' ) then
		state_next <= S_READ_OWNED_NOP1;
		if ( regMapRam_in = '1' ) then
			dataReg_next <= mcData_in;
			traceData_out <= TR_RD & std_logic_vector(tsCount) & addrReg & mdAS & mcData_in;
		else
			dataReg_next <= bootInsn;
			traceData_out <= TR_RD & std_logic_vector(tsCount) & addrReg & mdAS & bootInsn;
		end if;
		traceValid_out <= traceEnable_in;
		hbCount_next <= (others => '0');  -- reset heartbeat
	end if;

Setting mdDriveBus_out = '1' doesn't make any difference, just so long as the data output pins don't come out of their high impedance state for a moment.
This give the MD an extra 20ns to do... something. I'm not going to attempt a guess at what.

[prophet36]

Excellent, well done! I'll try your VHDL change on my hardware when I have a minute (which won't be for a few weeks).

[amushrow]

I checked on a regular Sonic 1 cart, there's a 190ns delay between that address line going low and the data lines being driven.
With the change the UMDK has 135ns before driving the lines (before it was 105ns).
I'd guess that something on the original MD isn't as quick as the UMDK and it wasn't ready. I also feel less bad about introducing a delay.

[prophet36]

Do you have Super Street Fighter II (The New Challengers)? That has some quite tight timing on the DMA. It was my go-to test ROM for timing issues.

[amushrow]

I put together an original bridge board and the fix works on that too, hooray! (and also boo, it took ages to route that board in whatever program I used)

I just tried SSF2:TNC and it seems to work fine.