Tengai Makyou Zero / Far East of Eden Zero English Repro

Does anyone here have any idea how to convert a copy of Tengai Makyou Zero (Far East of Eden Zero) cart to use the translated English rom?

I have an original TMZ donor cart, and the necessary tools to desolder the original mask rom, but apparently the translation patch expands the ROM size, so it's not as simple as just swapping out the old ROM chip. I know it's possible, there are people selling copies of the English translated cart on various places, but

1) They're charging $100
2) I don't want to BUY a repro, I would prefer to just convert my own FEoEZ cart (and this is something most translators are usually ok with).

The few tidbits of info I've found on other websites do include pictures of existing repro carts, but no other details, and they're too small/blurry to use as a guide. I'm assuming they use several address muxes or demuxes to deal with the change in ROM size, but I still don't fully understand how to integrate muxes/demuxes in a scenario like this order to figure out what kind of circuit I would need to build to this work correctly, so any information would be appreciated.

Ideally I'd like to build a translation PCB and post it somewhere like OSHpark or other locations so that other DIY-minded repro makers like myself don't have to pay exorbitant markup in order to play this game on original hardware in English.

Thanks!

This game looks like some kind of horrific romhack that I can't quite grasp. They literally say the following in the README:


To me, all of this indicates the romhack most likely uses a complete custom memory map layout of some sort. If they're requiring a unique/custom manifest XML (for higan/bsnes), and state that "it won't work on flash carts" (without any explanation) but that "it will work on real hardware" (also without any explanation), I am left to believe this romhacking effort is really not intended to be run on actual hardware.

The PCB used in the official cartridge is an SHVC-LDH3C-01, which was used by one -- and only one -- title: the one mentioned here. The SPC7110F appears to be a custom graphicsdecompression chip of some sort, tied to a "data ROM" of some kind, and has an additional chip that offers a battery-backed RTC (the R4513).

To figure out exactly how to modify your real cartridge, you'd need to study and understand the underlying manifest XML that the romhackers provided. They don't actually explain in their README what they did on a technical level, but I found this post that implies they grew the data ROM size to 5MBytes (actual mask ROMs don't work in such sizes; they're sizes of 1, 2, 4, 8, 16, etc.), and that PRG is 2MBytes (16mbit). The post states that additional wiring is needed to deal with the expanded PRG, which doesn't quite make sense to me since 16mbit is nothing to really worry about (standard mode 20 and mode 21 will work with this size just fine). So there's something else going on here.

I suspect what they did was "virtually extend" the addressing range through software by tweaking said manifest XML file, thus accomplishing their expansion needs/goal. To get this to work on hardware, I imagine a lot of additional wiring and an address decoder are needed (and possibly code patches that are used atop the patch itself).

IMO, none of this is worth destroying an original cart for, particularly since this game seems to be very unique and is the only title using this particular PCB. If you botch it, you can kiss your cart goodbye -- to me, that isn't worth it. Just play it on an emulator and be happy with that.

Good romhackers take the time (in their READMEs) to explain the changes necessary to accomplish said task. Honest. On the bright side, byuu was involved partially in this project, so he may be able to provide some insights hardware-wise on what modifications are truly needed.

Looking at the translation's bundled mainfest.bml file:


And comparing it to some old version of higan's description of the plain board:


The differences indicate:
you'll need to divide the resulting patched result into the first 1M ("Program"), middle 5M ("Data"), and last 1M ("Expansion"). The bundled "HiganFileSplitter" does this.
you'll need to find where SPC7110 A22 exists. It assuredly does, because they say it works on actual hardware.
you'll need two or three 1MB PROMs, one or two demultiplexers, and an 8 or 4MB PROM.
you'll need to either use 5V PROMs, or add voltage translation if using 3V PROMs.
you'll need to use one demultiplexer to detect the memory region where A23...A20 = 0x4, and use that to enable the "Expansion" ROM.


(this was my 8284th post, apparently the clock generator for the original IBM PC)

One reason is that the SPC7110 isn't supported by any flashcarts yet.


I have this game CIB, it wasn't expensive but it's very unique so yeah I also don't recommend destroying it for such a patch. Hopefully it will be made to work on SD2SNES when it gets support for SPC7110.

Is the game any good? I can't find much in English.

I've only played the three games on the PCE and as killer titles of the system they're all doubtlessly great (though I might not age well).
Anyway, according to some reviews most of the games (including the SFC, SS and GBA titles) are good, except III and the 3-D remake of II.

I haven't really played it yet myself as I haven't beaten the earlier games in the series yet and I want to play them in order.

Tengai Makyou series is the closest thing to being the PC-Engine's Dragon Quest series I guess. Instead of western fantasy though, it's based on old Japanese ninja legends but with a lot of humor. It takes place in the fictional world Zipang/Jipang (which is a way to say Japan in a certain Chinese language from a certain time period and which probably eventually evolved into the European name for Japan).
The team behind the series are also known for the later Sakura Taisen series.

The SFC game supposedly uses a real time clock like Pokemon and Animal Forest games for time-based events, and the main character's name is Higan.

This game: Super Famicom Momotaro Denstetsu Happy can be "converted" to also run the Far East Eden. You have to add the RTC chip to it though. It's a difficult cart to mod because 2 of the pins on the SPC chip have to be lifted and soldered to for the higher address lines for FEoE ...and... adding the RTC connections - which aren't too bad to connect. Still a difficult cart to work with.

RetroCircuits makes the conversion and this is what their board looks like.
There's nothing on the back side.

The rom does have proper down level-shifting so that's good.

According to https://rom-laboratory.000webhostapp.com/romlab/spc7110.htm there are 3 pins on the SPC7110 labeled RTC. The R4513 is the clock module itself, but I'm unclear as to how the SPC7110 factors into the RTC signal. My best guess is that the RTC signal is generated from the R4513 and then passed through the SPC7110 since it's necessary to decode the compression on the ROM, and thus is necessary for interfacing with the ROM and/or the SRAM?

Is it like the SA-1 where it has the ability to do computational functions independent of the S-CPU and thus it sort of acts like a proxy for the SNES CPU and basically keeps certain game logic running while the SNES is off, so that the game doesn't need to do a bunch of work post-boot to "catch up" on processing due to the passage of time?



I was under the impression that additional wiring was necessary because the translation's ROM expansion resulted in the shifting of location of various pieces of data within the ROM game - mostly code, and thus it also shifted the memory address that the SRAM was located at. Isn't this exactly the problem that the XML manifest solves for emulators - basically giving emulators "overrides" for certain things so that it can automatically reroute calls to memory addresses that have changed size or location?



As I said in my original post, there are pics online of existing translated carts, so it's definitely possible, and the circuit isn't that hard - it's about 3-4 memory address decoders and a handful of wires, but they are too blurry to get an accurate sense of what exactly was done, so I can't use them as a guide. Multiple address decoders are needed, yes. It's certainly not easy, but if it was, I wouldn't be here - I've already made translated carts of virtually every other type of game, even SA-1 and Super-FX games. TMZ is the only cart for which a guide on how to build a translation cart does not currently exist - hence why I'm asking for help. I know enough about hacking SNES PCBs but not enough about how the SNES memory addressing works to build the circuit I need...



I don't speak Japanese and I probably won't any time soon, but I own an original cart, so it's basically going to go unplayed forever unless I get the translation working. Also I personally enjoy playing games on original hardware and on my Super NT. Call me a purist, but there's just something about slotting a cart and booting a SNES that no emulator can replace, for me.

Yeah I think I've seen that picture before. Do you have this cart yourself? Can you provide details for me as a full wiring diagram and/or take some macro shots of the board and chips so that I can recreate it myself? I can't quite see in your pic what all is routed where.

I reached out to Retrocircuits last year asking if they would be willing to sell me just the board or the schematic so I could build my own, and they declined. IMO this is not very communal of them, since they're already selling someone else's work by selling translated carts, so I don't think they have a very strong claim to "protecting their IP", since they're simultaneously stealing and reselling the IP of the translators...

Yeah the other downside of that pic is that I can't see the underside of their add-on PCB which has a bunch of circuit traces on it showing which pins are routed where. There are obvious through-hole vias on their board so I can't really see what they're doing without someone desoldering that separate PCB and flipping it over and taking pictures of it.

I am an expert solder jockey with extensive rework tools and the knowledge and experience to safely disassemble and reassemble that cart without damaging anything. IF someone already has a working English cart and is willing to loan it to me for disassembly and examination I would return it in working order and also compensate them for their trouble, but I doubt anyone is interested in sending a $100 repro cart to some unknown dude on the internets...but it can't hurt to ask? Obviously I would pay shipping, etc.

That cart also has the RTC in the same location as TMZ - is there an unpopulated header for one on Super Famicom Momotaro Denstetsu Happy?

If that's the case then converting a TMZ cart basically just means you need to omit the step to "add" the RTC since it already has one built in and wired, and if they use the same base PCB then the signal routing is already correct.

There's only 2 headers on the PCB for ROMs, so I'm unclear what you mean about dividing the ROM like that since adding a 3rd ROM to the PCB would be a monumental undertaking (and a wiring nightmare). I was under the assumption that you just divided the ROM into 2 sections (Program + Expansion, Data) and then used address decoders to properly route the cart signaling to the expansion data when it gets requested.

I understand the theory, I just don't know how to build the circuit.

I have a partial pinout of the SPC7110 - A22 is *probably* pin 41 on the SPC7110. But I don't quite understand what you mean - is A22 where the expansion ROM data is located, so I essentially need to ensure that A22 on the SPC7110 is wired to the location where my expansion data is stored on my ROM chips?

I have a plethora of 5V and 3V (EE)PROMs, so I'm not concerned about voltage, and any circuit I built would include proper level shifting if I couldn't make this work with 5V EPROMs, though it's a moot point anyway - the Super NT has built in level shifting (thanks Kevtris!) because cheap chinese bootlegs/multicarts/repros all use 3V EEPROMs, so it can handle carts with 3V ROMs just fine. So even if I didn't build a level shift I could still play the cart without risking damage to anything...

This is not really a solution for me for multiple reasons. First, I don't have an SD2SNES and I don't intend to buy one. Second, it would be cheaper for me to buy a translated repro cart than an SD2SNES so it doesn't solve the cost issue. Third, my goal is to publicly and openly document how to do this so that others can recreate my work on their own carts for minimal cost compared to existing repro costs, so playing the game on an SD2SNES would not solve that issue either...

If your goal is to research and document how to reproduce the cartridge with all new parts I'm all for it.
But I thought the SPC7110 was a custom chip?

BTW it's actually spelled Momotarou Dentetsu which is a boardgame spin-off of Hudson's Momotarou Densetsu series (densetsu = legend, dentetsu = electric railway).

No, I meant my goal was to freely/openly document a method for using a donor cart and doing a ROM swap to the english patched ROM. I'm nowhere near able to the level that would be required to make a reproduction with new parts - that would involve an FPGA and basically would be an SD2SNES.

I just need assistance figuring out how to do the address translation of the patched ROM and how to fit that ROM into a TMZ donor cart. There aren't any guides online that I can find for how to do it, but I know it's possible, people are selling modded carts already and have been for half a year...

But you don't need to. All ROMs used originally on the SNES used standard footprints, and there's no connections between the OEM PCB and the graft other than the ones you can explicitly see. (BGAs and similar are harder to solder; if you can get away without that why would you bother?) There's even helpful silk on the graft that explains the bits that aren't original connections. (They're labeled ROM-CE, A20, SPC-CE, 21, 23, 22, 20)

The only difference from what I said and what's shown is that I assumed you needed a physically separate ROM to hold the "Expansion" that's mapped to banks $40-$4F, but it RetroCircuits instead used a single ROM that holds both the "Program" and "Expansion", and enables it when either the SPC wants it, or also when the SNES's CPU is trying to access banks $40-$4F.

Yes, I'm aware of the pinouts being standard and easy to connect, however I don't fully understand the expansion circuit that uses the address de/multiplexers (not sure which it uses, can't see them well enough), so I thought that seeing the traces on the underside of the board would help me expedite the process rather than pulling up 10 different data sheets and trying to discern what's going where.

No demultiplexers. For whatever reason, the equivalent logic is built out of a 74'00 and 74'32.

As we mentioned in the other thread about demultiplexers / selectors, a demux emits a signal that is "true" (low, in the case of 74'138 and 74'139) when the inputs are correct.

The ROMs also want a signal that is "true"=low to tell them when to emit data to the data bus.

So given the signals SNES A23,22,21,20 and SPC /PRG-CE, the 74'00 and 74'32 calculate the following:


The other parts are the ROM and 3V regulator for the 8MB flash and the three mandatory voltage translation ICs to prevent the SPC from being damaged driving a 3V ROM.

This is VERY helpful, thank you for breaking that down for me!

So just to make sure I'm understanding you correctly - the 74'00 and 74'32 should output high in every scenario except: 1) when A22 (alone) is low and 2) when /PRG-CE off the SPC7110 is low?

This leads to my next question - when you refer to /PRG-CE, do you know which pin on the SPC7110 corresponds to that signal? According to the pinout at http://www.romhacking.net/documents/%5B398%5DSPC7110F0a.txt there are 3 pins labeled "CE" on the SPC7110 - 47 (/CE), 48 (/OE), and 79 (/RTC-CE). My assumption is that when referring to /PRG-CE you're referring to pin 47 - is that not correct?

I have 5V (UV erasable) EPROMs (27CXXX of all types), so I don't actually need to build a level shift to test this out for myself. Fitting those EPROMs in the same case as the PCB will be tight, but I do know it's possible - I've done it with Star Ocean and SMRPG already, you just have to be willing to shorten the legs of the EEPROMs.

I'll see if I have a 74'00 and 74'32 kicking around in my spare parts, and start work on wiring up a test circuit to test the theory before moving on to designing an PCBs in Eagle.

If I make this work, lidnariq, I'll be happy to send you a translated cart as thanks for helping, if you'd like? I have 3 copies of TMZ in case I fry one testing this theory out. Thank you again for your help with this!

That's not what what I was trying to say... If A23 is low and A22 is high and A21 is low and A20 is low, then the output should be low.
Seems likely. Certainly "/OE" and "/RTC-CE" are clearly wrong. And the picture of Retrocircuits board showed just picking up the signal from some random via.

Do those come in 8MiB (4 Mi x 16bit)? Otherwise, you'll need to handle the 5MiB "data" ROM with multiple ROMs.

I appreciate the offer, but I just haven't been able to make myself sit down in front of the old SNES for several years now.

I see what you mean - I'll need to run wires off of A23+A22+A21+A20 so that when all 4 line up to the scenario you listed, THEN set the output to low for that chip. It looks like that's what the retrocircuits board already does for one of the logic checks.

It seems to me that there are 2 separate logic circuits of 2 chips on the Retrocircuits board - your previous post was unclear - am I going to need 2 pairs of 74LS00+74LS32? I can figure it out on my own, I just don't understand logic gate chips well enough yet to understand whether or not I'm looking at separate logic circuits or if I can handle all the logic circuits necessary with a single pair of those chips or not. I've used Logic Gates before, but that was in pre-fab repro boards where I didn't actually understand HOW they worked, just that the board said to solder a 74LS32 to a certain point in order to make it work, so I dutifully did so...and it worked.

I pulled the datasheets - the 74LS00 is a NAND gate and the 74LS39 is an OR gate, so I'll need to figure out the exact logic and how to line it up correctly, but I think I can manage - feel free to provide any suggestions or clarifications if you know off the top of your head how this works better than I do.



Ok so Pin 79 (RTC-CE) of the SPC7110 does have a jumper between one of its test points and the Retrocircuits pad labeled SPC-CE, so it does look like at least one of the logic circuits is reading for scenarios when /RTC-CE is pulled low.

There's 2 other taps on the Retrocircuits board - one says ROM-CE and one says A20 - and they're going to the 8M EEPROM - any idea how they fit in? I'm assuming that it's reading when the ROM /CE is pulled low and when /A20 is pulled low, which makes me think that I should modify your original suggestion so that instead of just reading /PRG-CE to be low it should look as follows:





Yes, the M27C800 is an 8MiB 5V EPROM that can be organized as either 1M word x 8-bit or 512K word x 16-bit - http://noel.feld.cvut.cz/hw/st/4630.pdf, so I believe it is a suitable drop-in replacement for this. I can just pad the actual ROM to 8MiB when programming it since those areas of memory just won't be called ever by the game code.

No, I don't think so. I saw only the following chips:
1 16 megabit (2 Megabyte, 2 Mi x 8b) 5V flash
3 voltage translation ICs, part number unknown, all in 20-pin TSSOPs
1 3V regulator in SOT-23
1 64 megabit (8 Megabyte, 4 Mi x 16b) 3V flash
1 74'32
1 74'00

So you understand the concept of logical OR, right?
If this OR that is true, then the result is true? because either this or that or both could be true?
This is the same idea. A 74'32 emits a signal that is high ("true") when either of its inputs are high ("true").
A 74'00 (NAND = AND followed by NOT) emits a signal that is low when both of its inputs are high ("true").

You're misreading the picture. The silkscreen labeled "SPC-CE" connects to a via, not pin 79.

Best guess: ROM-CE is the signal that tells the "program and expansion" ROM to be enabled, and is the result of the pile of logic. "A20" is probably SNES A22. Both conceptually flow from the right graft PCB (where they're generated) to the left graft PCB (where they're used)

There are only two correct tables:
One involves two ROM ("program and expansion" and "data") and for that the table I gave you is the only correct one.

If using three ROMs (one each for "program", "expansion" and "data"), then you don't need to modify "SPC-CE".

That is an 8 megabit 'PROM, not an 8 megabyte. You need 40 megabits (or more) of storage to hold the expanded "data" ROM.

I didn't realize there was such a thing as ICs for level shifting - I thought that was pretty much done exclusively via diodes/resistors/caps. Also a circuit I've never built...



Thanks for the explanation - obviously I'm familiar with OR and I've seen NAND before though I didn't know offhand how it worked since it's not something that comes up a lot in the software development world (and my programming skills are limited, I mostly write scripts and tools for my office, I'm not a "developer").



Yeah it looked kind of like it was connect to pin 79 but you are indeed correct - I checked it against an unmodified board picture and it's a via going somewhere. I'll take a look when I get home tonight as to where that via actually connects to. I could probably find out now but I'm at work and it's hard enough to find decent quality pics of the even the front of the PCB...




Ok, thanks for clarifying that for me. I was making incorrect assumptions due to my lack of knowledge regarding level shifting ICs. TIL. Knowing how the logic works is a major step here, I can kludge/learn how to build a proper logic circuit.



Yeah I wasn't paying close attention, sorry for being dense, I do actually know the difference between the two, honest! You are correct, a 5MB rom file would be 40Mbits and thus require an EPROM that was at least 64Mbit.

THAT is going to be much harder to fix. I found a few vague mentions in various places for 5V 64Mbit 4Mb x 16 EPROMs (the M27C642 / M27C640) but I could not find a single listing for one for sale ANYWHERE. I'm guessing they were pretty rare back in their day and there aren't many/any still hanging around these days. Or they never made it to production.

So that leaves me with 2 choices - I can either obtain a 64M 3V EEPROM and build a level shifting circuit, OR I can go the route you previously mentioned of splitting it into 3 ROMs.

Ok so...this is starting to make sense but still doesn't fully fit in my head. I still don't get what the logic circuit is doing, exactly. As best as I can tell, since the Expansion ROM data lives in bank $40, the code is somehow accessing the contents of $40 without lighting up A22. Via the SPC7110? Then, when the game lights up A22 it means that a piece of code is trying to access the data that originally lived at $40 (on a stock ROM), so now it's time to bankswitch the contents of $40 and $50?

In the SPC7110 schematics that I read, it indicated that decompressed data from the SPC7110 originally lived at $50-$5F. I'm not seeing anything in the memory map that indicates that data was remapped somewhere else, or is that irrelevant since a call to $50 would route "normally" and not be translated to whatever ROM banks that would otherwise correspond to $50, since technically that address isn't accessible even in an ExHiROM game and is instead handled via bankswitching between 2 32Mbit chips instead?

Am I understanding this correctly or am I still off target. I'm getting closer, I think once I get the board in front of me and can start referencing back and forth I'll have a better idea of what I'm looking at. Thanks again.

Apparently the "program" ROM doesn't go via the SPC7110 at all, and is just mapped statically (by the SPC7110) in banks $00-$0F, $80-$8F, and $C0-$CF.

Not really bankswitching? The SNES's CPU does have a concept of "bank", but it's just literally part of the address bus, not separate state. Nothing like smaller CPUs that can only natively handle 64 KiB.

Correct, with the SPC7110, banks $40-7D don't directly map to ROM. Banks $40-$4F are completely unused, banks $50-$5F are used for this decompression interface, and ... I don't know what's in $60-7D. Probably just the battery-backed RAM.

However, that's wrong. That's the only place that a mode $25 (pirates call it "exhirom") game can access the entirety of its 6th megabyte of ROM contents.