Super Magic Drive research thread

[tcdev]

Thanks for the bug report, I'll fix it. Cut and paste error.

Not your bug - it's on original PCB!!!

Is the reset input instead connected to the MRES# or VRES# signals from the Genesis cartridge port? (well probably MRES# would make sense)

I'll have to trace it...

Is there any kind of limitation on cartridge size dumping in the BIOS?

The code to dump the cartridge copies the cartridge size (@$DFF1) at $DC00, then jumps to the dump routine that checks the size is <= 1MB. Note that this is the v3 BIOS, and my unit only has 1MB DRAM...

I wonder now that we know the DRAM interface fairly well, if there's some way would could make a SRAM board or something to replace those old faulty chips.

Exactly what I was thinking!

[KanedaFr]

but if I select 'Run IC Cart', I have a green screen then nothing...

Does it always stay at a green screen after 'Run IC Cart', or does it turn black?

it's stay green for ever...
perhaps it's waiting, like tcdev said : "spins in a tight loop waiting for the 68k software to take over"

I know you have no LPT anymore, but if you can somehow, does running SMS ROMs using my smdutil program work? (you'd need the DRAM board installed)

won't be able to make further test this week...
can you tell me what it could prove ?

Does the DRAM test it has also at least load, even if it fails the test?

DRAM test ?
I have the 3.1g bios, where is the DRAM test ?

[KanedaFr]

Yes, I can run a cart without the DRAM installed.

very bad news....

but I found a guy who wasn't able to play cart with its SMD because the DRAM board was corroded....
perhaps the SMD got some short or strange data error and so bug on everything ? (in fact, I REALLY hope it's the reason!)

time to find a way to clean the acid....

[KanedaFr]

Is there any kind of limitation on cartridge size dumping in the BIOS?

The code to dump the cartridge copies the cartridge size (@$DFF1) at $DC00, then jumps to the dump routine that checks the size is <= 1MB. Note that this is the v3 BIOS, and my unit only has 1MB DRAM...

for info, got a 3.1g bios which support (at least) 16M

More info on the several models in this thread :
http://www.tototek.com/phpBB2/viewtopic ... 2090#12090

Charles, they talk about upgrading the DRAM...and problem with the EPLD

[tcdev]

very bad news....

perhaps the SMD got some short or strange data error and so bug on everything ? (in fact, I REALLY hope it's the reason!)

time to find a way to clean the acid....

There are other parts of the circuit near the battery that may be affected by the corrosion. You need to check the continuity as Charles suggested for each of the tracks.

I'm hoping my problem is simply faulty DRAM. The problem is working out how to verify that. And then how to replace it? I doubt I have ready access to those devices...

[tcdev]

for info, got a 3.1g bios which support (at least) 16M

BTW I assume you know 16M is 16Mbits or 2MBytes.

Looks like the larger memory boards require a MUX on the daughterboard. Which is why Charles' schematic differs from mine. Would be nice to build a replacement using SRAM...

[tcdev]

Still wading through the disassembly. I'd estimate 85% complete now. It's all the difficult and boring bits left - FAT filesystem routines - which aren't very nice in Z80 assembler. But since I'm so close to done I want to finish for completeness...

I won't bother posting any more updates since I don't think there's anything interesting that remains undiscovered. When it's done I'll post a link for those interested.

[Charles MacDonald]

it's stay green for ever...

OK, that means it is never switching out of Mark-III mode. I wonder if it isn't physically driving the M3# pin high.

The switch is pretty much instant, the BIOS enters a loop but really as soon as the write is done the machine automatically resets and restarts in Genesis mode.

Maybe there's damage on the trace from the EPLD to the pin. If you have a multimeter, you could do continuity tests to see which traces are bad.

won't be able to make further test this week...
can you tell me what it could prove ?

It would prove the DRAM works within Mark-III mode at least.

I have the 3.1g bios, where is the DRAM test ?

It's a feature of my smdutil program, it uploads a little program that does a DRAM test and prints the results.

[KanedaFr]

thanks Charles...
from your schema, I won't be surprised to see a probelm in VD14 or VD15..

may I ask you how you were able to trace all of these lines ?
there is a lot of them start or end below a chip or a connector..
for ex, I wasn't able to find the start and end point of the two corroded lines in bottom left....they starts below a 745 and finish(?) below the DMA connector....

anyway, got to buy some white vinegar

[Charles MacDonald]

EDIT: I don't have U5,U7 (7408) or U6 (74HCT157) on my DRAM board. It only contains 8x DRAM chips (KM44C256BP-7) and caps.

I know it would be really boring and time consuming, but is there any chance you could map the connections between the unknown eight DRAM signals from the connector (DCA-DCH) to the DRAM OE,WE inputs?

EDIT:

So I think the EPLD takes VA19,VA18 and uses it to generate OE and WE strobes for each pair of eight DRAMs.

On my DRAM board they AND together the strobes of each pair so they cover a 512K chunk instead of 256K. So far so good.

But I don't see how the multiplexing for A9 works. When outputting the column VA20 is passed through as A9, which I guess makes sense. But for the row it passes the WE and OE strobes ANDed together, such that DRAM A9 is '1' when both strobes are idle, '0' for anything else.

Maybe the WE,OE strobes output other data when RAS is active?

[Charles MacDonald]

thanks Charles...
may I ask you how you were able to trace all of these lines ?
there is a lot of them start or end below a chip or a connector..

A multimeter has a feature called a continuity test where you can place a probe on one pin, and the other probe on another, and if they are connected it beeps. This way you can find where traces go even if you can't see them. If it doesn't beep they aren't connected, or something like a resistor is between the two points.

Generally it's a foolproof system. I've turned complete arcade boards into schematics in just a few days using it. Very handy to have and even the cheapest multimeters tend to have this feature.

[tcdev]

I know it would be really boring and time consuming, but is there any chance you could map the connections between the unknown eight DRAM signals from the connector (DCA-DCH) to the DRAM OE,WE inputs?

I assume DA9 is not used because the DRAMs only need an 8-bit column and row?

If we had that information, we could give more meaningful names to the eight DRAM control lines coming out of the EPLD.

I started on the schematic for the DRAM daughterboard this morning. Haven't got very far yet (ran out of time before I had to start work proper) but from what little I've done it looks like the EPLD is going to be different. The RAS#,CAS# lines marked as such on your schematic on the connector only run to half of the chips. So there's going to be a 2nd set of lines on that connector... unless of course your daughterboard manages to munge the same lines out of the EPLD... I haven't had time to digest the operation of the circuit...

[KanedaFr]

thanks Charles...
may I ask you how you were able to trace all of these lines ?
there is a lot of them start or end below a chip or a connector..

A multimeter has a feature called a continuity test where you can place a probe on one pin, and the other probe on another, and if they are connected it beeps. This way you can find where traces go even if you can't see them. If it doesn't beep they aren't connected, or something like a resistor is between the two points.

Generally it's a foolproof system. I've turned complete arcade boards into schematics in just a few days using it. Very handy to have and even the cheapest multimeters tend to have this feature.

ok, I have this feature (but w/o the beep...would be a lot easier!) : it's a diod icon on my multimeter.
There is no secret weapon to avoid this (boring and time consuming) method then...
I see how to trace a WORKING board, but not how to fix a broken one w/o a schematic then....

[Charles MacDonald]

I see how to trace a WORKING board, but not how to fix a broken one w/o a schematic then....

Yeah but now you have a schematic.

Let's say you want to verify the DRAM data pins on either side of the corroded tracks on your board:

On the DRAM connector you can see sixteen data pins, VD0-7 and VD8-15.

If you follow the corroded traces upwards, you see the buffers U4 and U6. These are convenient to check because the pins are in order; one side of U6 from pin 18 down to 11 is VD0 through VD7, and one side of U4 from pin 18 down to 11 is VD8 through VD15.

So you can touch these 16 pins, touch the other ones on the DRAM board connector, and see if they beep. if they don't, that trace in particular is bad.

Some of the corroded traces may not be used for data, but from memory the ones that run near the battery are. So there will be other things to check too.

[tcdev]

Here's the completed schematic traced from my 1MB/8Mb DRAM Daughterboard...
http://members.iinet.net.au/~msmcdoug/c ... ematic.pdf

I used Charles' signal naming convention on the connector, except for the previously unknown control signals.

The connector signals appear compatible with Charles' schematic. I didn't take enough notice earlier, thinking there was only one RAS#/CAS# pair on the schematic. As a result I feared there may be a different EPLD between revisions. It's obvious now that the DCA-DCH signals are simply WE#/OE# pairs for each byte in a 32-bit DWORD.