Cart Design Questions

[cero]

The Saleae logic16 clones are very cheap and work well, if the specs are enough for you (16 channels etc). IIRC I paid under 20$ from ali.

[themrcul]

Hi cero, thanks for your reply.
But wouldn't I need more than 16 lines? I'd need 5x control lines, 22 address and 16 data lines alone to see accurately what's going on.
Or am I missing something?

[cero]

Surely you can repeat the test with recording different lines? If the ROM does the same thing, and only one thing, you can first record these lines, then those lines... Saves money vs a big scope.

edit: Or if you really need simultaneous channels, buy several and have them record at once If you have all of them record one channel that can sync them, then you could combine the recordings.

[Charles MacDonald]

About TMSS I think I'd need to see the entire cartridge "rom" (the fake one baked in to the CPLD) that you're using to answer that. Can you provide a binary dump of the first 256 bytes of the ROM data that you're presenting to the 68K so we can see what it's doing -- like using your cart dumper with your dev cart would be perfect for this.

I don't have a TMSS console handy to check but I think the idea is that if the cartridge header looks good you see that "Under license by" screen (white text on black background). Are you seeing that, or does it not get that far?

[themrcul]

Hi Charles and cero,
Thanks to you both for your posts. Sorry for the length of my reply but I want to get everything down in case that helps me get to a solution!

About the TMSS, I'm not even getting that far. When I load the Sonic the Hedgehog ROM onto my SDRAM cart plugged into my Mega Drive 2 and then hit the on button on the Mega Drive, I get a very quick small flash of white bars but then just a black screen.

If I put a retail cartridge into the Mega Drive and turn it on I get the same instant white bars flash (I guess that happens when any device connected to a CRT turns on) but then I get the TMSS "Produced by or under license from Sega Enterprises" and the game boots.

As a note, I have fixed the ROM size calculation on my retail cartridge reader/writer - I suspected that it wasn't using the header to determine ROM size but a manual 'read address near edge of 256KB, 512KB, 1MB, 2MB", etc and see if the data changes, then determine the ROM size that way.

So what I did was hack my CPLD code to mask all SDRAM addresses to a max of 512KB, like this:

Code: Select all

			STATE_SDRAM_ReadForMD_ReadWord: begin
				sdramAddress <= { 2'b0, mdAddress_sync & 22'h3FFFF };
			end

Obviously if I get the rest of the cart working I will program a more intelligent masking algorithm but I'm just trying to get Sonic working for now, and Sonic 1 is 512KB.

Well my suspicions were correct, putting the mask in there made the retail cartridge reader correctly determine the size of the ROM to be 512KB. I can read the ROM written to the SDRAM of my cartridge using this retail cart reader and it is byte for byte a match with the ROM loaded from a retail Sonic 1 cartridge read from the same retail cart reader.
So just to be clear, I put a genuine Sonic retail cart into the cart reader, and read that ROM to a file, 512KB.
Then I use that file and send it to my cartridge - it writes it to the SDRAM onboard.
Then I plug my cartridge into the reader and read that ROM, 512KB to a file.
The files are byte for byte the same.

So thanks Charles for your offer to check the header for me, but the whole ROM is readable now and is correct so that answers that question.

What is interesting is that if I involve the CE0 signal at all in my CPLD code, the retail reader fails to get any correct data off my cart.
It only works if I only use CAS0. With CE0, the reader says it is an unknown cartridge with no name, 0MB of size and 0KB of SRAM size.

There are 3 places in my code where I can use CAS0 and/or CE0: (and as a note, mdPresence_sync is simply 3.3V for when the cart is plugged into a running Mega Drive, 0V for when it is not plugged into a running Mega Drive):

1) Output Enable/Disable the data transceiver for 5V <-> 3.3V translation. Output disable puts the output of the transceiver to be high Z.
Code is:

Code: Select all

assign mdDataDisable = ~mdPresence_sync | mdReadCAS0_sync;

If I involve CE0 at all the retail cart reader fails.
Eg:

Code: Select all

assign mdDataDisable = ~mdPresence_sync | mdReadCAS0_sync | mdCartRangeCE_0_sync;

And

Code: Select all

assign mdDataDisable = ~mdPresence_sync | mdCartRangeCE_0_sync;

Fails.

2)
The second place is in the main state loop, to see if the Mega Drive is requesting a read. This works on the retail reader:

Code: Select all

STATE_CPLD_Idle: begin
			if (mdPresence_sync & ~mdReadCAS0_sync) begin
				// we need to read data for the MD
				cpld_state_next = STATE_SDRAM_ReadForMD_WaitUntilReady;
			end

Again, CE0 breaks it. I would think it would need to be this:

Code: Select all

STATE_CPLD_Idle: begin
			if (mdPresence_sync & ~mdReadCAS0_sync & ~mdCartRangeCE_0_sync) begin
				// we need to read data for the MD
				cpld_state_next = STATE_SDRAM_ReadForMD_WaitUntilReady;
			end

But that breaks it.
This fails too:

Code: Select all

STATE_CPLD_Idle: begin
			if (mdPresence_sync & ~mdCartRangeCE_0_sync) begin
				// we need to read data for the MD
				cpld_state_next = STATE_SDRAM_ReadForMD_WaitUntilReady;
			end

3)
The last spot is to determine the finish of a read:

Code: Select all

STATE_SDRAM_ReadForMD_WaitForReadToFinish: begin
			cpld_state_next = (~mdPresence_sync | mdReadCAS0_sync) ? STATE_CPLD_Idle : STATE_SDRAM_ReadForMD_WaitForReadToFinish;
		end

Again CE0 stuffs things up.

Maybe this is impacting the Mega Drive too? Sadly any combination of using CE0 and not doesn't work on the Mega Drive either. Without any measurement tools I don't know for sure what is happening either.

I thought, maybe there is something faulty with the CE0 line to the CPLD? Perhaps it isn't connected or there is a solder bridge somewhere along the line stuffing things up?
So I tested the CE0 line alongside all adjacent PCB lines as well, in case there is a bridge somewhere impacting the line, but CE0 functions fine - I can set it to 1 or 0 and all adjacent lines too and they are all functioning independently and correctly...

My other thought is that it is just not getting the data to the Mega Drive fast enough - when I first designed and built this PCB I never knew that CPLDs/FPGAs without PLLs would halve incoming clock lines that are output to other ICs - so my CPLD running at 100MHz is actually running the SDRAM at 50MHz.
My SAM4S micro disables DAC sound output if running higher than 100MHz but can run up to 120MHz if DAC output is not needed, so as a test I put the clock up to 120MHz and tightened up the SDRAM timings to the absolute fastest they can be while still returning reliable data.
Of course it still doesn't work on the Mega Drive, but it is still possible that it still isn't fast enough - the SDRAM I have can run up to 133MHz, but I am currently nowhere near that, at 60MHz.

So, unless a new idea comes to me I'm at the point now where I have to choose from 2 options:
1) Bite the bullet and redesign the PCB around SRAM rather than SDRAM, purchase the parts and solder up another board, or:
2) Make a simple PCB that sits between the Mega Drive and a cartridge plugged in that exposes test points for each address, control and data line, and also purchase a logic analyzer to measure what is happening.

With option 2, there is no guarantee that I will be able to solve what is wrong, but I will at least see what is happening, hopefully?
With option 1, it will cost me time to redesign and then time to solder everything again. But there is the chance that it will "just work", saving the cost of purchasing a logic analyzer - I can't find any affordable 32-channel ones. There are some 16 channel ones that could work...

But I wonder why involving the CE0 line at all breaks reading? Anyway thanks to all in advance for any ideas.

[Mask of Destiny]

What is interesting is that if I involve the CE0 signal at all in my CPLD code, the retail reader fails to get any correct data off my cart.
It only works if I only use CAS0. With CE0, the reader says it is an unknown cartridge with no name, 0MB of size and 0KB of SRAM size.

I'm not sure why your cart reader is failing when you use CE0, but using CE0 is absolutely required for compatibility with TMSS. Without it you have no way to distinguish a TMSS access from a cartridge access and you will get into a bus fight.

FWIW, I think a logic analyzer would be a good investment, even if it's a relatively cheap one that doesn't have very many channels. Being able to capture the control signals and a few data lines would go a long way towards verifying your device is behaving as you expect in the console. You don't necessarily need a special board in between the cart and console for this, though I will say that attaching individual probes can get fairly tedious (especially with the crappy cheap ones that came with my logic analyzer).

I would be kind of surprised if your timing wasn't good enough to at least service the 68K. Timing on that is fairly relaxed. DMA is trickier though.

[themrcul]

Thanks guys,
I just missed out on an Amazon sale for a 32 channel LA, but have found a 16 channel one that looks ok.
Without the sale the 32 channel one is just too expensive, at ~$400AUD.

But before I hit the buy it now button on the 16 channel one, I just wanted to check, if this logic analyser can only sample at 16MHz for 16 channels at once, would that be fast enough for analysing the Mega Drive cartridge bus?
If I drop down to 8 channels max I can sample at 32MHz, but it would be great to be able to do 16 channels at once if possible!

This is the one I'm thinking of btw:
https://a.aliexpress.com/_mMdelkQ

Alternatively I could get the basic model for this one, which may be an upgrade from the one above:
https://a.aliexpress.com/_mrGYemQ

Thanks guys!

[Mask of Destiny]

But before I hit the buy it now button on the 16 channel one, I just wanted to check, if this logic analyser can only sample at 16MHz for 16 channels at once, would that be fast enough for analysing the Mega Drive cartridge bus?

In general, you need your sample rate to be at least twice as fast as the fastest signal you want to sample. So for instance, if you wanted to get the 68K clock (not strictly necessary for capturing cart signals, but I find it useful to be able to look at how signals are changing in relation to the relevant clock sometimes), 16MHz would be just barely sufficient. I think if you want to be able to debug DMA you would want something that can go higher.

[themrcul]

Ok thanks Mask,
I see with a quick Google that the DMA controller runs at ~13MHz - so I will need ~30MHz to get a reading of what is going on there.
That means if I'm debugging DMA I'll only be able to do a max of 9 channels to ensure I'm running at 32MHz.

Other Logic Analyzers with guaranteed ~100MHz for 16 channels run at twice the price. I'll have to have a think about which one I get.

Hopefully stitching up multiple logic readings isn't too difficult!

[themrcul]

Hi guys,
I've knocked up a test PCB to sit between a Mega Drive and any cartridge that I plug in.

Life is busy (as I assume it is for everyone here!), and I've done it in a way that orders the address and data lines in a easy way for me to plug a logic analyzer into.

But before I do the finishing touches and make an order to get it fabricated I wanted to post it here and ask, is "untangling" the address and data lines like I have done not a good idea, electrically or for any other reason?

The easy way is of course to just connect everything in the order it is in the cart edge. However actually using the test PCB in that case would be more difficult as I would need to look all over the board to find the next address or data line.

Anyway, is what I've done ok or should I just scrap it and connect everything up in the order they come out from the cart edge?

Thanks in advance to anyone who posts back for me.

MD Test Cart Render.png (67.66 KiB) Viewed 25388 times

[themrcul]

Hey fellas,
Just letting y'all know I've trimmed up some bits and pieces of the PCB and made an order for it, along with a 16bit logic analyzer from Aliexpress.
I hope this combination will help me track down what is going wrong with my original design. It will be a few weeks before delivery and I'll have to learn how to use the logic analyzer, but I'm hopeful at least!

[themrcul]

Hi everyone,
After a long hiatus, I am gearing up to make my third version of the PCB, hopefully this one will work correctly.

I have one question before I commit to getting it fabricated that I wanted to ask, and that is about inducing a soft reset from my cart.

I know that the Mega Drive exposes two reset signals to the cart, /MRES and /VRES, and previously I had /VRES connected to my 5V->3.3V voltage translation transceiver and then to my CPLD, but that won't work for pulling the signal low to reset the Mega Drive.

Am I correct in just thinking that to induce a soft reset, I can hook the /VRES line up to a GPIO pin on my ARM micro via a resistor divider (instead of through the voltage level transceiver).
And then, by default and also if I want to check for reset events, I have the ARM GPIO pin configured to an INPUT and check for 0V vs 3V, and then if I want to pull the signal low, I change the GPIO pin to be an OUTPUT and set the level to be 0V (false)?

Or does it need to be more complicated than that? Do I need to include a MOFSET and somehow use that as a "switch" to pull the /VRES signal low?

Thanks for any help you can advise me with and best regards to you all.

[themrcul]

Ok so I did some experimenting with a MOFSET, specifically an N-type enhancement mode MOFSET, the 2N7002.
I have done some researching about how MOFSETs work, but this is the first time I am attempting to implement one, so I am just checking here to see if I am doing something wrong!

I connected the SOURCE of the MOFSET to GND, as is normal.

The DRAIN is connected to /VRES via a resistor divider. In between the resistor divider and the CART /VRES line I am also connecting a GPIO pin of my ARM microcontroller, set to INPUT mode, to be able to capture RESET events.

I then connected the GATE of the MOFSET and a GPIO pin on the ARM that will be used to turn the MOFSET on/off. As per advice I have read on the internet, I put a resistor in between the GATE and the ARM GPIO pin to protect the ARM micro from any damage the MOFSET may cause in adverse situations.
This GPIO pin will be set to OUTPUT mode. Setting the output to TRUE will turn the MOFSET ON and will drain the /VRES circuit, thus inducing a RESET event.
Leaving it set to FALSE (0V) or INPUT mode will turn the MOFSET OFF and /VRES will naturally float high during normal gameplay.

Since this is the first time I have used a MOFSET, I just wanted to check to see if I have gotten something completely wrong.

Please see below screenshots of the circuit I put together to check my design.
As you can see below, when the output of the GPIO pin connected to the MOFSET GATE is TRUE, the voltage at the probe is 0V, indicating to me that the /VRES line will be pulled to 0V, inducing a RESET event.

circuit-20240607-0119 (1).png (100.24 KiB) Viewed 2219 times

With the GPIO pin set to INPUT or OUTPUT FALSE, the MOFSET will be disabled and /VRES will be allowed to float high, allowing normal operation:

circuit-20240607-0119.png (99.79 KiB) Viewed 2219 times

[TmEE co.(TM)]

This is the right way to do it, there shouldn't be any problems at all.

[themrcul]

Thank you very much for the confirmation TmEE, that means a lot.
I'm almost ready to get the 3rd revision of my cart fabricated by JLCPCB after a long hiatus on this project.
Hopefully my fixes will mean it works this time!