MD hangs after playing any PCM file

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

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 1:19 pm

One thing I don't understand is if the rapid-switching of the buffer conveying the address-lines is causing /OE to also switch, that implies that /OE is not being actively driven. But if that were the case, then putting a 4K7 pull-up to +5V on /OE on the MD side would fix the problem, but when you tried that, it had no effect. I guess another thing we could try is to bypass the level-converter channel conveying /OE to the FPGA, and use a voltage-divider for it instead.

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

Re: MD hangs after playing any PCM file

Post by amushrow » Tue Apr 18, 2017 10:33 pm

So, we can use diodes to reduce the voltage to the buffer, and in my test on a breadboard it seemed like it would work fine. But it doesn't, as I suspected the current is so low it leaks through anyway.

With a 2.7v Zener diode the 5v from the Mega Drive is dropped to 3.5v (a ways off 2.7v). The 1.5v signal which seems to be causing the trouble gets dropped to a 1.3v.
The result is that the noise has been damped somewhat, but it still happens and the Mega Drive still crashes.

Possible solutions include adding a resistor to ground along with each diode, which would require the PCB to be redesigned (making space a for a teeny little diode above each address pin would have been super easy). With that you could also remove the buffers, the 5v from the MD would be dropped to safe levels for the FPGA (although I'd probably try for a lower zener voltage, at 2.7 it would only leave 0.3v above the 2.0v required to guarantee that things will see it as HIGH). The only thing I don't like about this idea is soldering 48 piddling little components, I got some SOD-523 diodes so I could squeeze them in at the top of the cart pins and I swear some of them shifted to another dimension before I got to solder them.

Or we could try to find an IC that will help us out, but I've not had any luck finding anything.

My final suggestion would be to invent a Time Machine, go back in time and get Sega to fix this issue in the original MDs instead of finally getting round to it on the MDII.

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

Re: MD hangs after playing any PCM file

Post by amushrow » Sat Apr 22, 2017 10:54 am

I'm going to make a board with diodes instead of the transceiver like I said, and see if it works out.
If the board turns out well I'll stick up a guide on making PCB's at home; with plated vias, solder mask, tinned traces / pads, and a durable coating for the cart pins. Unless it doesn't turn out that great, in which case I won't.

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 » Sat Apr 22, 2017 11:02 am

amushrow wrote:I'm going to make a board with diodes
Thank you so much for all your hard work so far on diagnostics. Thanks to you we now have a much better understanding of why some MD models suffer problems, and others don't. Also, thanks in advance for your work on this alternative bridge-board (irrespective of whether or not it yields fruit). This is exactly the kind of collaboration I hoped to see when I started the project.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Re: MD hangs after playing any PCM file

Post by Jorge Nuno » Mon Apr 24, 2017 10:41 am

I just realized what it could be a conceptual issue. UMDK uses no CE_0.
So how does it know if the TMSS binary is executing or not? If it does not and forces the bus, irrelevant of the state of A14100 then it might be the issue that 2 devices are forcing data on the bus.

CE_0 is not active when the TMSS rom is on the bus, but CAS0 is always asserted for reads under 0x800000, irrelevant if it's TMSS or Cart.

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

Re: MD hangs after playing any PCM file

Post by amushrow » Mon May 01, 2017 12:55 pm

I don't want to have to route another board ever again, at least not one with so many vias in it.
top.png
top.png (43.91 KiB) Viewed 23362 times
bottom.png
bottom.png (29.7 KiB) Viewed 23362 times
Now all I need to do is make it, and as I've managed to brew a sufficiently potent activator solution for plating the through holes, the rest should be easy. (Except for the drilling, that will be tedious and noisy).

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 May 01, 2017 1:37 pm

That is very cool. You should put your name in the copyright message instead of mine though - I don't want to take the credit[1] for it!

So forgive my ignorance but how exactly do the diodes and resistors achieve the level-conversion?

[1]Or the blame!

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Re: MD hangs after playing any PCM file

Post by Jorge Nuno » Mon May 01, 2017 1:53 pm

Sorry for hijack but I decided to take a more "drastic" approach:

Image

4K: http://img.ctrlv.in/img/17/05/01/59073d5edcab7.png

Still need a few weeks or something to finish it though

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

Re: MD hangs after playing any PCM file

Post by amushrow » Mon May 01, 2017 2:50 pm

prophet36 wrote:So forgive my ignorance but how exactly do the diodes and resistors achieve the level-conversion?
The diodes will drop the voltage in a similar manner to having just a resistor, the key difference being that a diode will need a minimum amount of voltage before current will flow through it. The idea being that it will block out the lower voltage signals that are falsely being interpreted as HIGH.

The resistors are there because very small amounts of current can still leak through the diode with a high enough voltage for them to still trigger the buffers, the resistors are basically pulling more current through the diodes so we get a predictable voltage drop across them. Though they may not be necessary depending on how much current the FPGA takes on its input pins (I reckon it'll be the same as the buffers though).

In my tests on a breadboard it should all work great, but we'll see. Maybe I'll just end up with the magic blue smoke.

@Jorge Nuno: I was thinking it would be great to have it all on one board, but decided it would be far too much effort for me and I like the idea of being able to use the lx9 board for other stuff (though it's unlikely that I ever would).

It looks like you've squeezed that into a regular sized cart too, which is awesome.

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 May 01, 2017 4:23 pm

Jorge Nuno wrote:Sorry for hijack but I decided to take a more "drastic" approach
That is awesome, great work! Please bear in mind the new information that amushrow's painstaking detective-work has brought to the table in this thread though: the instability seen during 68000/Z80 bus arbitration on a small number of machines is most likely caused by a short period of address-bus contention on the MD side feeding an intermediate voltage to the level-shifters, causing them to go kinda crazy. You might be better off waiting to see how amushrow's prototype behaves; it may well be a better design.

BTW, if it makes routing easier, I can easily swap FPGA I/Os around. Alternatively I can guide you through the process if you prefer to do it yourself. One swap in particular seems like a worthwhile idea: the SDRAM clock is currently driven by a general-purpose I/O, but if it was instead driven by a GCLK pin it would allow the SDRAM controller to operate in a different clock-domain from the main 48MHz clock, which is the only way I can think of to improve its latency.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Re: MD hangs after playing any PCM file

Post by Jorge Nuno » Mon May 01, 2017 8:30 pm

I'm pretty sure this bus abnormality is not there in normal cases. I've done a bunch of different types of MD cartridges already and never seen something like this on any HW revision.
I know the FPGA pins are all swappable but I wanted to keep the same pinout for maintanability reasons. The only difference is that I'm getting rid of AS completely and going with CE_0 in its place.

The bus buffers I'm also using another part because I don't trust those 5<->3.3V bidirectional converters. I'm stepping down the 5V signals to 3.3V, but not the other way around. Also my idea with the internal logic will be to double/triple (or somewhere inbetween) the speed it's running at but I don't know how feasable this is, proably needs heavier pipelining. Spartan6 is able to do 150MHz with some care. 120M could also cut it. Basic idea will be to take DCM from 48 and do output0 with 48x1 for USB interface stuff and output1 with 48x2.5 for megadrive/sdram/sdram statemachine (for example). I only need to know if the 48MHz clock is always present as DCMs don't like clocks that are turing off/on or changing rates.

How many slices are stil available with the current design?

Licensing is another "problem" but for later. I ditched kicad completely as I hate this program. I't a cool concept and I'm glad somebody did it and all that, but it's not for me. Files will be released, but I'm not sure how or where.

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 May 01, 2017 10:28 pm

Jorge Nuno wrote:The only difference is that I'm getting rid of AS completely
I think the only place /AS is used is to distinguish between CPU (i.e Z80 or 68000) cycles and DMA cycles in the trace log. I have a small project on the go to "replay" UMDK trace logs into a 68000 emulator (probably Musashi, which is used by MAME), thereby annotating it with a disassembly. That should prove more useful than the CPU/DMA bit, so yeah feel free to drop /AS.
Jorge Nuno wrote:Also my idea with the internal logic will be to double/triple...the speed it's running at but I don't know how feasable this is
I think it's certainly feasible, but even if you have only vague plans to do this, you should definitely swap the SDRAM clock for one of the GCK pins on the FPGA: IIRC only GCK pins can be driven by DCM outputs. Let me know which GCK you're thinking of swapping in, and I'll create a separate BSP for your board.
Jorge Nuno wrote:I only need to know if the 48MHz clock is always present
Yes, the 48MHz clock is stable well before the FPGA finishes programming itself from flash, and it remains stable thereafter.
Jorge Nuno wrote:How many slices are stil available with the current design?
The place-and-route summary looks like this:

Code: Select all

Device Utilization Summary:

Slice Logic Utilization:
  Number of Slice Registers:                   742 out of  11,440    6%
    Number used as Flip Flops:                 742
    Number used as Latches:                      0
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
  Number of Slice LUTs:                      1,091 out of   5,720   19%
    Number used as logic:                    1,078 out of   5,720   18%
      Number using O6 output only:             795
      Number using O5 output only:              55
      Number using O5 and O6:                  228
      Number used as ROM:                        0
    Number used as Memory:                       0 out of   1,440    0%
    Number used exclusively as route-thrus:     13
      Number with same-slice register load:      9
      Number with same-slice carry load:         4
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                   449 out of   1,430   31%
  Number of MUXCYs used:                       208 out of   2,860    7%
  Number of LUT Flip Flop pairs used:        1,341
    Number with an unused Flip Flop:           620 out of   1,341   46%
    Number with an unused LUT:                 250 out of   1,341   18%
    Number of fully used LUT-FF pairs:         471 out of   1,341   35%
    Number of slice register sites lost
      to control set restrictions:               0 out of  11,440    0%

  A LUT Flip Flop pair for this architecture represents one LUT paired with
  one Flip Flop within a slice.  A control set is a unique combination of
  clock, reset, set, and enable signals for a registered element.
  The Slice Logic Distribution report is not meaningful if the design is
  over-mapped for a non-slice resource or if Placement fails.

IO Utilization:
  Number of bonded IOBs:                       102 out of     102  100%
    Number of LOCed IOBs:                      102 out of     102  100%
    IOB Flip Flops:                              1

Specific Feature Utilization:
  Number of RAMB16BWERs:                        12 out of      32   37%
  Number of RAMB8BWERs:                          1 out of      64    1%
  Number of BUFIO2/BUFIO2_2CLKs:                 1 out of      32    3%
    Number used as BUFIO2s:                      1
    Number used as BUFIO2_2CLKs:                 0
  Number of BUFIO2FB/BUFIO2FB_2CLKs:             1 out of      32    3%
    Number used as BUFIO2FBs:                    1
    Number used as BUFIO2FB_2CLKs:               0
  Number of BUFG/BUFGMUXs:                       2 out of      16   12%
    Number used as BUFGs:                        2
    Number used as BUFGMUX:                      0
  Number of DCM/DCM_CLKGENs:                     1 out of       4   25%
    Number used as DCMs:                         1
    Number used as DCM_CLKGENs:                  0
  Number of ILOGIC2/ISERDES2s:                   0 out of     200    0%
  Number of IODELAY2/IODRP2/IODRP2_MCBs:         0 out of     200    0%
  Number of OLOGIC2/OSERDES2s:                   1 out of     200    1%
    Number used as OLOGIC2s:                     1
    Number used as OSERDES2s:                    0
  Number of BSCANs:                              0 out of       4    0%
  Number of BUFHs:                               0 out of     128    0%
  Number of BUFPLLs:                             0 out of       8    0%
  Number of BUFPLL_MCBs:                         0 out of       4    0%
  Number of DSP48A1s:                            0 out of      16    0%
  Number of ICAPs:                               0 out of       1    0%
  Number of MCBs:                                0 out of       2    0%
  Number of PCILOGICSEs:                         0 out of       2    0%
  Number of PLL_ADVs:                            0 out of       2    0%
  Number of PMVs:                                0 out of       1    0%
  Number of STARTUPs:                            0 out of       1    0%
  Number of SUSPEND_SYNCs:                       0 out of       1    0%
...which implies there is plenty of space. Not sure I trust these numbers 100% though; I seem to remember setting the trace-FIFO (used to smooth out the bursty nature of the USB link to ensure trace packets are not lost) size to the largest it would go to, so I'd expect the block-RAM utilization to be higher.
Jorge Nuno wrote:The bus buffers I'm also using another part because I don't trust those 5<->3.3V bidirectional converters
:
I ditched kicad completely as I hate this program
Fair enough, on both counts.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Re: MD hangs after playing any PCM file

Post by Jorge Nuno » Mon May 01, 2017 10:41 pm

From my experience with the spartan6, you can use any fpga pin for a clock OUTPUT pin, DCM'ed or not does not matter. To do it properly an ODDR-FlipFlop needs to be instatiated (or somehow inferred) where d0/d1 is 0/1, Clock1 is the positive clock, and Clock2 the negation of it (or the DCM 180º output), and Q goes directly to the pin. For clock input, yeah a GCLK pin is highly recommended.

I think those logic % numbers are adequate for what I intend to do (which is just to fix it, no feature creeping)

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

Re: MD hangs after playing any PCM file

Post by HardWareMan » Tue May 02, 2017 4:16 am

Jorge Nuno wrote:The bus buffers I'm also using another part because I don't trust those 5<->3.3V bidirectional converters. I'm stepping down the 5V signals to 3.3V, but not the other way around.
You totally right. There was another project with FC stuff and bidirectional automatic shifters created a big headache. Only unidirectional or controllable bidirectional is stable and good for our project. Unidirectional for all input signals (addresses and control) and controllable bidirectional for data lines. It can be controlled by FPGA, but you must pull up control pin for bus-off while FPGA under configuration state.

PS Adding CAS2 is a good idea too.

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 » Tue May 02, 2017 8:07 am

Jorge Nuno wrote:you can use any fpga pin for a clock OUTPUT pin, DCM'ed or not does not matter
It's been a while since I looked into this, so I don't remember the details, but it's all in this thread on the Xilinx forums. I think it'd be worthwhile to try it out before you route your board.
Jorge Nuno wrote:To do it properly an ODDR-FlipFlop needs to be instatiated (or somehow inferred) where d0/d1 is 0/1, Clock1 is the positive clock, and Clock2 the negation of it (or the DCM 180º output), and Q goes directly to the pin
Yup, that's here. IIRC doing the same thing with the output of a DCM doesn't work, hence the thread I started on the Xilinx forums.

Post Reply