Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - MITEC Reverse engineer logic?

Reply to topic
Author Message
  • Joined: 10 Oct 2022
  • Posts: 9
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Sat Nov 12, 2022 6:38 am
Hi All,

Just wondering if anyone has been successful in reverse engineering the SEGA MITEC chip logic?

I have a person who has got most of the way reverse engineering and his replacement IC for the MITEC works with all carts s=execpt the BASIC III cart because of the onboard RAM.

He's very close to having it cracked but needs help with the final bit of logic. Anyone here able to assist or have the solution?

Thanks

macsonny
  View user's profile Send private message
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Sat Nov 12, 2022 10:47 am
Hi I don’t have one but I think I can help. I did something very similar for a chip on the mega cd

https://www.obscuregamers.com/threads/reverse-engineering-the-sega-mega-cd-315-5...
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Thu Nov 17, 2022 10:29 am
Hey folks! I'm the guy that's most of the way to getting the MITEC-2 reverse engineered and in need of some help!

I've thrown what I've currently got up on GitHub (can't post link, it's at github dot com/silvervest/mitec2), it has a Kicad project with the final schematic and PCB design, and Verilog project that contains the partially working logic, somewhat commented.

There's also a couple of logic analyser captures during the initialisation and first few seconds of BASIC-IIIB and Lode Runner games. I only have a DIY sigrok-pico so it's not the greatest capture, but coupled with the info in the datasheet I was able to at least get it generally booting and playing carts.

The biggest issues I've had are the signals that are related to controlling external RAM on carts (CAS, RAS, MUX) as the timing charts in the datasheet aren't super clear, and I can't find reliable patterns in any of the logic captures I've got.

Any help or tips would be appreciated! Thanks in advance :)
  View user's profile Send private message
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Thu Nov 17, 2022 8:30 pm
Can you find the part number of any cart with DRAM on it? The datasheet for that DRAM should tell you the timing for RAS and CAS
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Thu Nov 17, 2022 9:17 pm
silvervest wrote
Hey folks! I'm the guy that's most of the way to getting the MITEC-2 reverse engineered and in need of some help!

I've thrown what I've currently got up on GitHub (can't post link, it's at github dot com/silvervest/mitec2), it has a Kicad project with the final schematic and PCB design, and Verilog project that contains the partially working logic, somewhat commented.

There's also a couple of logic analyser captures during the initialisation and first few seconds of BASIC-IIIB and Lode Runner games. I only have a DIY sigrok-pico so it's not the greatest capture, but coupled with the info in the datasheet I was able to at least get it generally booting and playing carts.

The biggest issues I've had are the signals that are related to controlling external RAM on carts (CAS, RAS, MUX) as the timing charts in the datasheet aren't super clear, and I can't find reliable patterns in any of the logic captures I've got.

Any help or tips would be appreciated! Thanks in advance :)

I can dump the chip and reverse equations here.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Thu Nov 17, 2022 10:29 pm
lidnariq wrote
Can you find the part number of any cart with DRAM on it? The datasheet for that DRAM should tell you the timing for RAS and CAS


From Enri's site, the DRAM are MB81416-12 and the datasheet does indeed have good timing info, but I more meant what part of the inputs to the MITEC is triggering each RAS/CAS cycle, and how the multiplexing is handled.

Apocalypse wrote
I can dump the chip and reverse equations here.


How exactly? I like to learn by doing!
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Fri Nov 18, 2022 1:11 am
silvervest wrote
How exactly? I like to learn by doing!

I have a custom dumper I had initially built to dump registered (and obviously protected) PLDs from arcade boards (PEEL1xCV8, PAL16Rx, PALCE16V8, GAL16V8, GAL20V8, GAL22V10, etc.), coupled with a home developped analysing piece of software.
It is a similar approach to dumping combinatorial only devices, generating all possible input combinations, reading resulting outputs and reducing equations, except it works also for registered ones.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Fri Nov 18, 2022 1:21 am
Apocalypse wrote
It is a similar approach to dumping combinatorial only devices, generating all possible input combinations, reading resulting outputs and reducing equations, except it works also for registered ones.


Interesting... this was my initial approach - I built a very basic interface on perfboard to connect up to an ATmega2560, and wrote a program that generated the inputs and captured the outputs, but was not able to learn much. I figured I was just doing something wrong.
There's actually a Logic Friday file in my repo that has the captured outputs in the truth table, if you care to take a look. I might add the arduino program into the repo as well, if it's still useful...

As it stands, I'm not super keen on sending my only good MITEC IC away at the moment, so would rather any help possible to be able to complete the work myself
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Fri Nov 18, 2022 2:19 am
silvervest wrote
I figured I was just doing something wrong.
There's actually a Logic Friday file in my repo that has the captured outputs in the truth table, if you care to take a look. I might add the arduino program into the repo as well, if it's still useful...

Well, the thing is we're not even sure the dump is valid. Maybe the wiring is wrong, or the program in the arduino.
Have you implemented a way to detect 3 state, open collector or latched (registered) outputs?

I understand not wanting to send your only working chip, there's always a risk it's lost in the mail or even damaged by my homemade piece of equipement.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Fri Nov 18, 2022 2:29 am
Apocalypse wrote
Well, the thing is we're not even sure the dump is valid. Maybe the wiring was wrong, or the program in the arduino.
Have you implemented a way to detect 3 state, open collector or latched (registered) outputs?


Agreed, it was very rudimentary. All the program really did was brute force setting high/low on each input pin in every combination, wait a bit, read the state of every output pin, wait a bit, rinse and repeat. It wouldn't have taken any "special" states or outputs into account.

I might dig out the code and verify, as it was very early on in my project so it likely has a lot of mistakes that I can rectify now.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Fri Nov 18, 2022 3:39 am
Is you rig also measuring delay lines? Because /CAS1 and /CAS2 and /MUX will probably be delayed copies of /RAS1 and /RAS2. Maybe 20nS. Maybe more.
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Fri Nov 18, 2022 6:36 am
asynchronous wrote
Is you rig also measuring delay lines? Because /CAS1 and /CAS2 and /MUX will probably be delayed copies of /RAS1 and /RAS2. Maybe 20nS. Maybe more.


It's not, but I agree based on what I've seen. The /MUX is more interesting though, as based on the schematics on Enri's site (if I'm reading it right) it's used to multiplex the address lines to the cart, and also along with CAS1/2 multiplexing the four DRAM ICs as well.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Fri Nov 18, 2022 9:09 am
AFAIK, the /MUX signal just indicates when the column address is available. The row address is latched by DRAM on the falling edge of /RAS. The /MUX line would go low to drive any address multiplexing logic present. The column address is then latched by DRAM on the falling edge of /CAS.
  View user's profile Send private message
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Fri Nov 18, 2022 12:15 pm
The important part is sampling. As you were told above, a logic gate has a delay of 15-20 ns. You need a logic analyzer that can measure at least once every 5ns. Then you can program the arduino as loosely as you like. As long as you capture input output pairs, you do not need to worry of anything else. Have a look at zeroplus lapc series. They are good bang for the buck, especially if you mod them with the extra channels.
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Fri Nov 18, 2022 8:41 pm
Not so fast guys, only bad designs rely on gate delays (which vary with temperature), good practice is to have everything synced (to the master clock for instance or any other "predictible" signal), so I doubt Sega went that route.

Here's my method: I just dump the chip without any oversampling.
If several outputs appear to have the same equation (which doesn't make sense unless you maxed out the fanout, which again is bad design), then I do a second dump with oversampling to learn which outputs are cascaded to other ones.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Sat Nov 19, 2022 3:11 am
Nobody is questioning your mad skills apocalyptic kiwi dude.

Not all designs are synchronous to a clock. FYI The MITEC chip doesn’t have a CLK pin. We’re talking about an intentional delay line that is designed to be as precise as possible. See the 75LS31 for example. Even predictable signals can have not so great specs that need to be taken into account in designs. Take the timing of the falling edge of the Z80 /MREQ strobe for instance.

There’s not much to work with for generating the required, sequential /RAS, /MUX and /CAS lines. For a memory read cycle, the Z80 drops /MREQ and /RD lines together. With no CLK, or separation between the strobes, I'm not sure how you could generate /RAS, /MUX and /CAS without using delay lines.

Either way, I think I’ve worked out logic for the DRAM signals, but it would be good, as kamillebidan-san said, to sample the lines and get the precise timing down to 5nS:

/RAS1,/RAS2 follow /MREQ.

/MUX follows /RAS1,/RAS2 when /RFRSH is high with a 70nS delay. If /RFRSH goes low (i.e. for a refresh cycle) then /MUX will remain high.

/CAS1,/CAS2 go low when /RAS1,/RAS2 and (/RD or /WR) and (delayed) /MUX go low after a 70nS delay, only when /RFRSH is high. If /RFRSH goes low (i.e. for a refresh cycle) then /CAS1,CAS2 will remain high.

Pending verification.
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sat Nov 19, 2022 3:35 am
That all sounds logical to me (excuse the pun)

I'll get to work on the verilog and let you know, thanks!

The sigrok captures in the repo were taken at the maximum the pico thing could muster, which was (supposedly) 20MHz so that's sampling at 50ns max I think?
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sat Nov 19, 2022 3:48 am
Actually just revisiting the sigrok dumps, even with the lack of clarity it clearly shows /CAS1 and /CAS2 being addressed completely separately, and [s]it appears to be controlled by A6 being high or low[/s] actually I have no idea what's controlling that looking even closer...
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Sat Nov 19, 2022 5:07 am
asynchronous wrote
Not all designs are synchronous to a clock.

Apocalypse wrote
or any other "predictible" signal

I know too well yes, would be the first custom chip from Sega to use delays but there's a first to everything.
I didn't look into the details of that MITEC2 chip, it seems you have studied it well so you're probably right.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Sat Nov 19, 2022 5:54 am
Apocalypse wrote
Not so fast guys, only bad designs rely on gate delays (which vary with temperature), good practice is to have everything synced (to the master clock for instance or any other "predictible" signal), so I doubt Sega went that route.

They totally went with it on the megacd. They even use what in a standard design we’d call a glitch to generate a pulse! (And yeah I totally agree with you, that is an awful way to design)
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Sat Nov 19, 2022 6:09 am
kamillebidan wrote
They totally went with it on the megacd. They even use what in a standard design we’d call a glitch to generate a pulse! (And yeah I totally agree with you, that is an awful way to design)

That's good to know, I couldn't think of any example in consoles or on arcade boards from Sega. Forgot the Mega-CD was a console. :D
That SC-3000 computer is also an odd one.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sat Nov 19, 2022 8:22 am
Well excellent news, I have it now booting and showing the correct amount of RAM on the BASIC-IIIB cart!



I need to do some further testing, like trying to actually use the RAM, but previously it refused to boot 3B entirely - the cart does a RAM test at power up, so I'm going to assume that if it boots and shows free RAM it should just work(tm)

asynchronous wrote

/RAS1,/RAS2 follow /MREQ.

/MUX follows /RAS1,/RAS2 when /RFRSH is high with a 70nS delay. If /RFRSH goes low (i.e. for a refresh cycle) then /MUX will remain high.

/CAS1,/CAS2 go low when /RAS1,/RAS2 and (/RD or /WR) and (delayed) /MUX go low after a 70nS delay, only when /RFRSH is high. If /RFRSH goes low (i.e. for a refresh cycle) then /CAS1,CAS2 will remain high.

This was super useful and very very close. It looks like /RAS1/2 and /CAS1/2 are selected by A14/A15, and /MUX is separate to /RAS. I've committed the working verilog so you can see the equations I have working, with delays etc.

I was able to get the sigrok-pico actually capturing at 60MHz which helped with the delays a lot.
  View user's profile Send private message
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Sat Nov 19, 2022 9:19 am
silvervest wrote
Well excellent news, I have it now booting and showing the correct amount of RAM on the BASIC-IIIB cart!


I was able to get the sigrok-pico actually capturing at 60MHz which helped with the delays a lot.


Great! How many channels can you sample at that speed? If you can share the waveforms I’d love to have a look at them
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Sat Nov 19, 2022 9:27 am
Nice work.

You would be doing a service if you posted your findings and workings of the chip and DRAM signals in this forum.

After all, you came in stuck and looking for help, and with discussion and contribution from a few people, you were able to find the solution.
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Sat Nov 19, 2022 6:02 pm
silvervest wrote
Well excellent news, I have it now booting and showing the correct amount of RAM on the BASIC-IIIB cart!

Great work, well done. An other custom chip preserved.
So it's purely combinatorial after all?
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 508
Reply with quote
Post Posted: Sat Nov 19, 2022 10:21 pm
kamillebidan wrote

They totally went with it on the megacd. They even use what in a standard design we’d call a glitch to generate a pulse! (And yeah I totally agree with you, that is an awful way to design)

And that was the basic for one of the most famous marketing memes ever?
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sat Nov 19, 2022 11:08 pm
asynchronous wrote
You would be doing a service if you posted your findings and workings of the chip and DRAM signals in this forum.

Yep will be doing a full write up and my Github repo (incl PCB design) will stay public and under an OSI license

Apocalypse wrote
Great work, well done. An other custom chip preserved.
So it's purely combinatorial after all?

Well, I'm not gonna claim 'preserved" maybe "reproduced" ... It just seems to work, I don't know if it's exact ;)
It did appear to be pure logic in the end, although it seems I can't celebrate just yet as I went to play Zaxxon last night and have no sound, but sound is working fine via BASIC and in Lode Runner, so will need to investigate!
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
MITEC Reverse engineer logic?
Post Posted: Sun Nov 20, 2022 12:29 am
I can see a few errors in your logic equations that may be causing the sound issue and other issues.

See my comments below.


// asynch: hdl coding by silvervest

assign NMI = NMIN;
// asynch: will this achieve the intended debounce?

assign MEMR = !(!RD && WR && !MREQ && IORQ && RFSH);
assign MEMW = !(RD && !WR && !MREQ && IORQ && RFSH);
// asynch: this, and others, contains irrelevant pins in the equation, but should still work ok.

assign IOR = !(!RD && WR && MREQ && !IORQ && A7);
assign IOW = !(RD && !WR && MREQ && !IORQ && A7);
// asynch: should include A6 in equation.  Could cause clash between 8255 with VDP.

assign CSR = !(!RD && WR && MREQ && RFSH && !A6 && A7);
assign CSW = !(RD && !WR && MREQ && RFSH && !A6 && A7);
// asynch: equation should include /IORQ.

assign CE89 = !(RD && !WR && MREQ && !A7);
// asynch: equation should include /IORQ for the PSG.

assign CSSRAM = !(A14 && A15);
// asynch: should include /MREQ. Probably works due to /MEMx on SRAM.

assign CEROM2 = !(A14 && A15);
// asynch: should include /MREQ. May cause issues with some cartridges.

assign #10 RAS1 = !((!MREQ && !RFSH) || (!MREQ && (!RD || !WR) && !A14 && A15));
// asynch: 10nS delay.

assign #10 RAS2 = !((!MREQ && !RFSH) || (!MREQ && (!RD || !WR) && A14 && A15));
// asynch: 10nS delay.

assign #50 MUX = !(RFSH && ((!MREQ && !RD) || (!MREQ && !WR)));
// asynch: 50nS delay.

assign #50 CAS1 = !(!MUX && !RAS1);
assign #50 CAS2 = !(!MUX && !RAS2);
// asynch: 50nS delay.

assign #30 RAMA7 = A7 && RFSH;
// asynch: 30nS delay.


Hope that helps.
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sun Nov 20, 2022 8:28 am
asynchronous wrote
I can see a few errors in your logic equations that may be causing the sound issue and other issues.

Thanks, I've cleaned up a lot of them now. Broken sound was just because Zaxxon has no sound during the demo............. Anyway, I've also added some comments that dumps out most of what's in my brain at the moment.

Regarding NMI debouncing, I can't think of a nice way to do this without a clock source which I don't really want to add, and it doesn't seem to matter in my testing so far, so I'm okay without it for now. If you have thoughts on this, I'd love to hear them.

asynchronous wrote
Hope that helps.

Everything helps! Thank you for all of the assists :-)
  View user's profile Send private message
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Sun Nov 20, 2022 10:43 am
It would be be better to see how it is working on the real chip,anyway a dirty quick way would be using rd as the clock signal for debouncing.
  View user's profile Send private message
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sun Nov 20, 2022 11:13 am
kamillebidan wrote
It would be be better to see how it is working on the real chip,anyway a dirty quick way would be using rd as the clock signal for debouncing.

That was so easy, I'm bummed I didn't think of it. Works a treat, so NMI is now debounced! Thanks :)

Everything I can test is now working excellently, so now I just need to do the full write up. Thanks everyone for all your help!
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Sun Nov 20, 2022 6:53 pm
Hey silvervest.

I'm still very curious about the delays. Have they been proved necessary? How does the chip achieve those? You mention the default clock was 1MHz you reduced to 300kHz. You would need a much faster clock to generate a 10nS delay. Or does the compiler simply cascade multiple unused gates to the signals based on the theorical gate delay?
  View user's profile Send private message Visit poster's website
  • Joined: 14 Nov 2022
  • Posts: 14
Reply with quote
Post Posted: Sun Nov 20, 2022 10:22 pm
The 1MHz to 300kHz speed reduction is during programming only for JTAG operations. The gate delays in the verilog are actually ignored at synthesis time because I haven't included an external clock source.

The CPLDs I'm using (xc9536xl) have a 10ns pin-to-pin propagation delay, which I guess ends up being good enough and the actual delays (~50ns) aren't necessary. I could add some duplicate wires and propagate the final value 3-4 times to get a fake delay but it works as is so didn't bother, but I left the delay values there for reference
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 158
Reply with quote
Post Posted: Mon Nov 21, 2022 1:24 am
Thanks for the details, it confirms what I initially thought.
Now that you have a replacement option and if you ever want to have your equations confirmed I'm still happy to dump the chip. I'll also do a pass with oversampling to check for eventual delays.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Oct 2022
  • Posts: 9
Reply with quote
Post Posted: Mon Nov 21, 2022 10:25 am
Being the owner of the original Sega that presented all these issues I have to say it's an awesome read to see a community working together and solve a problem!!!!

I hope these was lots of video captured during the solving of this problem by #silvervest because it is going to make for some great viewing!
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!