So recently there was discussion about whether or not one of byuu’s datapak dumps for Satellaview held up to scrutiny. Since I happened to pick up the exact same game while recently in Japan — because it looked cool, not because I thought it needed redumping — I thought why not redump it.
The Satellaview (BSX) cartridge and the Datapak cartridge are shown on the left. The Satellaview was an interesting peripheral (or rather console) in and of itself. It could download games and store them on re-writable Datapaks, but there were also read-only Datapaks like the Same Game packs, which would feature game-specific graphics that could be swapped with other games.
I thought dumping it would be a good exercise and pretty straightforward. The Datapak comes with a female socket for an edge connector with 62 pins at 1.27mm pitch. So I build an adapter cable from 2.54mm pitch using wires. For dumping I would just use a Teensy++2.0 (which uses 5V) and wire up all the address, data and control lines.
Character Casette Closeup
What gave a lot of trouble at first was the irregular pinout of the mask ROM. It’s a TC534003CF and it doesn’t use the JEDEC pinout. I figured out which lines were which only to later find the same info in the NESDev Wiki and even later a more complete edge connector pinout on their NESDev forums. Well, should have checked first 🙂
It didn’t help that at first I wouldn’t get any output, because the #CS line had a cold solder joint, but would magically work when I pressed down on the PCB to measure while asserting and deasserting the line. But once everything was fixed — bar a very embarrassing coding error that forced me to go only at 800 Bits/s for this dump — I got to the actual dumping:
Dumper in action!
The result can be found in DoM and the dump matches the known dump, so the internal checksum really is wrong or at least calculated differently.
I just put up a more readable MMM01 documentation on my wiki, check it out. While I implemented the mapper already in MESS, I found some small issues with it that I’ll send a pull request over soon.
If you have any idea what the unknown bit might be there for, drop me a line as my test setup is still in one piece 🙂 I’ve already tried:
- it’s not part of the #WE for the lower 5 bits of RA
- it’s not part of the mask for the lower 5 bits of RA, i.e. cannot fix RA14 and trick zero-adjust
- setting the bit does not prevent #RAM_CS (and RAM_CS) from asserting when RAMG == 0x0A
- setting the bit does not automatically make the mux bit toggle when mapped and switching MBC1 modes
- setting the bit does not allow writing to RA22..RA21, RA20..RA19, AA16..AA15 when mapped
- setting the bit does not allow changing the multiplexer bit
- setting the bit does not allow resetting the map enable bit
- setting the bit does not ‘capture’ the MBC1 mode from the first write to the MODE register after mapping
So I just had a friend of a friend find Shin Megami Tensei – Devil Children: Aka no Sho Rev A in Japan. Upon analyzing the changes made and compared them to the following game in the series, Shiro no Sho, it’s kind of safe to say that there is also a Kuro no Sho Rev A. So the search continues…
I’ll update this post when I have a more concrete list of changes, but I already noticed that the Serial Interrupt is forced on where it was just assumed to be on in several functions in Rom Bank 0x00.
Hey, so a lot has happened recently. First off, I moved cities for a new job and that’s why my coverage has been spotty to say the least. Unfortunately, I’ll only really get settled November-ish, maybe a bit sooner.
What did I do since February you ask? Well, I looked into disassembling Devil Children Black, Red and White Book. But that hasn’t really broken the off-the-ground mark yet, because I’m super picky about automating as much as possible including function call arguments and stack manipulation. I might have to scale back my expectations from unreasonable to barely doable tho *le sigh*
Then I have been dumping a small number of European Gameboy games (should all be in DoM by now) and importing some stuff from Taiwan for release in the near future or whenever, see post below. Basically, I’m not releasing because I’m unsure about the classification, but if no info turns up, I’ll just have to do it anyway and maybe recat later.
There is also MMM01 research stuff I almost completed (one bit’s functionality — if any — still eludes me) but had no time to clean up yet and put in the wiki. Code describing the functionality is in MESS though.
Then I went on to document/dump some Gowin games lent to me by various individuals, but only got so far as to fully verify one dump and document one PCB — which turned out to be the more interesting one anyway.
So right now there’s plans for Sachen, Gowin, Datel, some random Sintax games, misc Gameboy MBC research stuff, some disassembly stuff and probably some other stuff I forgot. I also want to get into Virtual Boy homebrew more and might think about dumping my WonderSwan collection or lending it to somebody who can dump them easily. It’s unfortunate that I tend to get super busy and drawn into work all the time, but then again, having a job beats living on the streets 😉
So I recently acquired more Sachen games, among them are 31B-001 (Taiwanese version), 16B-002 (2x 8B with switch), the elusive 6B-001, which I guess is now confirmed to exist and an unknown 16B variant featuring the Mahjong titles and a wide selection of other titles, meaning it’s not just two 4B/8B ROMS back-to-back.
I then went on to actually automagically split the ROMs into individual sub-ROMs and compare them for revision differences etc. This yielded some boring results, where the combined 4B ROMs have no header, an unencrypted header or a different entry-point to fool Sachen’s own simple logo-based copy protection. The most interesting thing I found is a 5-in-1 cartridge featuring Stotris and the Mahjong titles as opposed to the regular 4B-003 4-in-1 cartridge.
The menus are about the same, and Stotris has even the same entry point for both entries, so it’s likely that – Sachen being Sachen – it’s actually the same game code with just a few different arguments passed to it for Stotris 1 and Stotris 2. Still, it’s a fun little discovery, anyway 🙂
The rest of the games will be put up on DoM shortly and I’ll keep updating the other Sachen post I made below with dump dates etc. I documented the different 4B color menus and what solder options will trigger them. Of course, half the menus are broken, because why not, and both 16B menus might have a bug… fun. Still, probably going to try in MESS to see if the games load properly anyway.
I also took some time to update my WP site theme, so if anything is broken, that’s probably why 🙂
So I tried to evoke a response of my comatose Pokémon Mini again, but nothing on the supposed CN3-23 (#RD?) or CN3-29 (FR?) lines. Pictures of the patient on the left.
As I said above, CN3-23 wouldn’t budge, CN3-29 stays low the whole time. I get the feeling that maybe CN3-29 is actually an input for some LCD status signal (#DOF?; MIO?) and that’s why the MIN panics when the LCD seemingly doesn’t come out of reset? I might try to pull it up via a resistor next time when I measure stuff.
This time I used the “Nth” triggering option of my scope to look at the LCD signals some more. I used this feature to determine the sequence I got to see so far:
- 1x write to command register
- 8x the following sequence:
- 3x writes to command register
- 96x writes to data register
- 2x writes to command register
- 16x writes to command register
- 1x write to command register
The first 806 writes take roughly 9ms, while the final write occurs at 350m
s after the initial write access — which leads me to believe that’s roughly the time when the MIN gives up and enters some indeterminate state where it won’t turn off any more. So we have 8 writes of 96 bytes in the first frame, i.e. 8x (96 x 8) 1bpp pixels of data, which seems right. The three writes preceding every sequence do the setup for that row of data.
Two more pictures of my setup and the final seconds of the CN3-23 (#RD?) pad. For reset, I use tweezers to hit the two pads while holding an additional probe in place for A0 (some of the time anyway).
So I broke my Pokémon Mini (MIN) trying to solder some wire-wrap onto the LCD connector. Wire-wrap was of course as big as each pin and pitch was only 0.5mm, so yeah… That didn’t work out.
I was going to check out the display signals while actually seeing the display work. Alas, having broken something in the connector (possibly related to me melting it with my soldering iron *oops*), I took the connector off (0.5mm 29pin FFC with connection on PCB side [down, below]), soldered the darn wire-wrap onto the PCB pads — and managed to halfway rip off CN3-23 in the process *yay me* — and used my scope to make some waveform shots. This is the result:
CN3-23 – #RD?
CN3-24 – #WR
CN3-25 – A0
CN3-27 – #CS
CN3-28 – 18.7 kHz square wave (CL?)
CN3-29 – static 0 (FR?)
My scope traces only clearly show A0, #WR, #CS and CL. #RD is always 1, FR is always 0. However, the SED1565 datasheet really put things into perspective. The native LCD FFC pinout closely matches the condensed pinout found on CN3 resp the MIN LCD FFC. Since only two signals weren’t clearly identified and their default polarities match, I think this is a good fit for now. Providing an external clock and external FR might also be useful for the MIN to do cool LCD effects as well as turn the LCD off when in power down mode.
Connector and signal names as in my preliminary MIN Mainboard schmatic (which I just updated). BTW, the boost converter (StepUpConverter in schematic) works nothing like what was in the v1.0. Pin PG is an enable that will take the output voltage VOUT from ~1V to ~3V. Pin EN is actually used to turn the boost converter off again, I think (odd voltages on that pin…). I was working on a proper schematic for that sub-board itself anyway, which is why I did not bother updating the schematic for v1.1.
Incidentally, the display not being there somehow prevented the MIN from turning off. Or maybe I just wasn’t patient enough (had to press the buttons using tweezers). Or maybe I broke the #RD pin by shorting it and the MIN entered an infinite loop trying to read from the display? I’ll probably never know.
Just wanted to let everybody know that finally, all Sachen 4 in 1 Mono games were dumped and put into DoM by yours truly. I would like to point out that taizou and BigFred lent a hand in letting me borrow their games.
So I noticed I neglected to update DoM with the mono 4B games I had already dumped. I did so now. All redumps are in as well as new entries for 4B-001, 4B-004, 4B-006, 4B-008. I updated the last Sachen post as well.
Maybe a bit more info on color Sachen games. As mentioned in the earlier blog post, BigFred and I weren’t sure how to handle 4B Color games yet, so I held off putting them into DoM for the time being. BigFred being a no-intro High Council member and all 😉
In other related news: I now own three Sintax games:
- Zauberringkönig II
(A Lord of the Rings – Two Towers rip-off)
- Donkey Kong 5 – Die Reise durch die Zeit
(Donkey Kong 5 – The Journey through Time)
- The Incredible Hulk
(Graphics hack of Lao Fuzi Chuanqi)
Currently looking at the logo switch code. It’s all complicated by the fact that Sintax connected the full GEC (ok, sans PHI and AIN) to their mapper.
Judging from the information I gathered from taizou’s hhugboy (a fork of GEST with support for mappers of unlicensed games) and personal correspondence, Sintax also implemented a bizarre copyright-scheme of bit-swapping and XORing the ROM data and sure enough, the mapper has a dedicated data bus for the ROM.
My initial tests however uncovered two things:
- Sintax’s logo switching is buggy and switches logos one byte before the last logo byte is read, resulting in different logos on DMG and CGB. CGB is lucky in that the Sintax logo and Nintendo logo both have the last low nibble at 0xF. It’s the upper nibble that changes between DMG and CGB (0x3 vs 0x1).
- Sintax do seem to switch the complete logo (RA7 trick, like Sachen, more elaborate though), so they didn’t really need to keep the upper “Nintendo” part. Maybe there’s another bug where the upper part is switched back every second byte that I just haven’t uncovered yet?! Gotta get those oscilloscope traces 🙂
A gallery of popular logos follows:
Sintax LoR II CGB
Sintax LoR II DMG
So I received more Sachen carts in the mail today and finally confirmed that Sachen’s MMC1 also has 8 high address lines, as could be guessed from the zero-adjustment being performed on all 8 data bits. Probably now going to change the dumper to read RB 0x00 from 0x4000-0x7FFF by using masking instead of ROM aliasing. Anyway, I updated the wiki page accordingly.
I also received two Sintax carts. One is currently not working, though I managed to boot it up once after like a hundred tries. Not sure what’s wrong with it yet. Anyway, they feature “Deutsche Vision”, aka shoddy German translation 😛 One is “Donkey Kong 5”, the other is “Incredible Hulk” (CGB-SYS-USA, for some reason…).