MD hangs after playing any PCM file
Moderators: BigEvilCorporation, prophet36
Re: MD hangs after playing any PCM file
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.
Re: MD hangs after playing any PCM file
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.
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.
Re: MD hangs after playing any PCM file
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.
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.
Re: MD hangs after playing any PCM file
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.amushrow wrote:I'm going to make a board with diodes
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Re: MD hangs after playing any PCM file
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.
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.
Re: MD hangs after playing any PCM file
I don't want to have to route another board ever again, at least not one with so many vias in it.
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).
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).
Re: MD hangs after playing any PCM file
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!
So forgive my ignorance but how exactly do the diodes and resistors achieve the level-conversion?
[1]Or the blame!
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Re: MD hangs after playing any PCM file
Sorry for hijack but I decided to take a more "drastic" approach:
4K: http://img.ctrlv.in/img/17/05/01/59073d5edcab7.png
Still need a few weeks or something to finish it though
4K: http://img.ctrlv.in/img/17/05/01/59073d5edcab7.png
Still need a few weeks or something to finish it though
Re: MD hangs after playing any PCM file
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.prophet36 wrote:So forgive my ignorance but how exactly do the diodes and resistors achieve the level-conversion?
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.
Re: MD hangs after playing any PCM file
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.Jorge Nuno wrote:Sorry for hijack but I decided to take a more "drastic" approach
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.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Re: MD hangs after playing any PCM file
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.
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.
Re: MD hangs after playing any PCM file
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:The only difference is that I'm getting rid of AS completely
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: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
Yes, the 48MHz clock is stable well before the FPGA finishes programming itself from flash, and it remains stable thereafter.Jorge Nuno wrote:I only need to know if the 48MHz clock is always present
The place-and-route summary looks like this:Jorge Nuno wrote:How many slices are stil available with the current design?
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%
Fair enough, on both counts.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
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Re: MD hangs after playing any PCM file
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)
I think those logic % numbers are adequate for what I intend to do (which is just to fix it, no feature creeping)
-
- Very interested
- Posts: 750
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: MD hangs after playing any PCM file
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.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.
PS Adding CAS2 is a good idea too.
Re: MD hangs after playing any PCM file
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:you can use any fpga pin for a clock OUTPUT pin, DCM'ed or not does not matter
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.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