About the game
Donkey Kong 3: Dai Gyakushuu (ドンキーコング３ 大逆襲 ) or DKDG, for short, was released in October ’84 for the NEC PC-8801, PC-6601, and Sharp X1 computers by Hudson Soft. Not unlike other Nintendo spin-offs developed by Hudson in the mid 80s, DKDG was created as sort of a sequel to the Donkey Kong 3 arcade game. There are 20 unique stages, which loop around upon completion until game over. The game has no well-defined storyline. Apparently, according to the manual, Hudson was interested in hearing the players’ interpretations about the progression of the stages, and wanted them to send in their own stories. In other words, the story is totally subjective! The game’s mechanics are somewhat simpler than the original DK3 arcade game; Stanley no longer has the ability to jump and is free from the responsibility of defending his plants. This game is all about fighting off DK. The point is to clear the waves of incoming enemies, like any typical shoot ’em up. You still have to make sure the parachuting DK doesn’t make it to the ground, or else!
Similarly to the the other Hudson-Nintendo games, the X1 version of DKDG runs really smoothly and does so with a coherent palette, likely making it the definitive version. Prior to this endeavor, the game has been unavailable to the public on all platforms it was released for, and there has been no footage online of any levels for the Sharp X1 version past level 7. A possible reason for the game’s rarity may be that it was poorly advertised. It was first mentioned in the April ’84 issue of Micom Basic Magazine and a few other magazines, but the ad didn’t include any screenshots, and the logo strongly resembled the arcade game’s logo, causing readers to overlook the ad.
The story of this project
I heard about this game from a FamicomWorld forum post made by user aitsu124, who first issued the rallying cry on several sites to preserve the game and make it available to the public. After learning of the game, I remembered the past times I’d seen photos of the cover without even looking twice. I thought it was just a plain old DK3 port. How could I have missed that? After some back and forth, we agreed that I would bid on the game.
Aitsu124 had already started gathering money for the dump, and, after winning the auction, I was able to obtain a substantial sum from contributors to help pay for it. As a result of the publicity, the auction ended for a whopping 44.5k yen, about 5 times more expensive than the previous listing. Oh well. Now that the game was secured, it was time to think about dumping it.
Looking first at the basics, I started reading about floppy drives and how the disks were set up. I was able to figure out that the 3” disks in question were Maxell CF-2D type disks with a 320KB capacity, similar to the X1’s 2D format 5.25” disks. Each of these disks is typically split into 0–39 cylinders for a total of 80 tracks, with 8 sectors per track and 512 bytes per sector. Note that these aren’t your typical 3.5” 1.44MB disks. They’re not nearly as well-documented, and the equipment necessary to read them is much harder to find. The reason 3” disks are such a pain to deal with is because of how quickly they became obsolete: the casings were very expensive to produce, pushing major companies to adopt the 3.5” diskettes, thus making them the de facto standard. Not only are these disks non-standard, the file formatting is also proprietary to the X1. In conclusion, reading the disk contents might require some serious reverse-engineering if there was no existing code or documentation.
Shortly after purchasing the disk from Yahoo auctions, I managed to find a listing for a standalone 3” floppy drive made for the Sharp X1D computer and purchased it in the hopes that I could somehow fit it to my Turbo Z II. Both the game and the disk drive were shipped to me within a few weeks. As an aside, one has to note that older floppy drives came with DIP switches on their logic boards so that their drive numbers could be set manually. “Modern” floppy drives didn’t come with switches so users wouldn’t have to worry about it. Instead, the two-drive 34-pin cable known today eliminated this problem by including a “twist” in the wires between the two connectors, so that Drive A and Drive B would be set based on where they were plugged in. The X1 didn’t use this technology. So, I had to figure out how to configure the dip switches before using the drive. Luckily, the Neo Kobe team had preserved a specific page from the CZ-300F service manual with DIP switch settings.
Upon examining the PCB, it looked like the pinout on the 3” drive was identical to the 5.25” drive. Optimistically, I configured the 3” drive as drive 0 and connected it the computer internally to the 5.25” drive’s connector. I managed to run the game directly from the X1’s IPL as a 2D disk. Watching the title screen load was a mixture of relief and excitement. There is hope! I closed up my X1 and attached the drive externally, setting it as drive 2.* The X1 treated the 3” drive as a 5.25” drive without issues. Awesome. The drive works, and the disk runs, too! Dumping the game should be trivial from here.
My first thought was to load a blank disk image on my HxC floppy drive emulator and use a tried and true copy utility to simply write the disk data straight to an SD card. It’d be just as easy as duplicating any floppy disk, right? No low-level knowledge needed. The computer wouldn’t even know the difference! Unfortunately, it seemed to me like the copy utilities I was able to get my hands on only supported a specific list of games or could only handle disks with the HuBASIC file system. After being unable to find further documentation for the copy tools (in English or Japanese) and setting up an emulator environment to try and brute force an understanding, I decided to try a different approach.
The second idea was to try a program called MakeD88. The program essentially reads a disk’s contents on the Sharp X1 and streams each byte through the computer’s RS-232C serial port at 9800bps. A Windows computer on the other end of the cable can then capture the stream as a text file, and a Windows program can then convert the received .txt file to a D88 disk image, which is compatible with X1 emulators as well as HxC floppy drive emulators. This seemed like a great idea, but how could I get the program onto the X1? I tried copying the files directly to a CZ-8FB03 Hu-Basic disk image using X1DiskExplorer from this page, but they would not show up as executables in the disk image. Apparently, all I had was the source code in Hu-Basic, a language I could not learn easily due to all of the documentation being in Japanese. Thankfully, I was able to convert the files to binary using the HuConverter program located conveniently on the same webpage (woops). Once I had the program on the X1, I managed to dump a few of the 3” disks straight to my win98 machine, which was fun to watch. The thing is, I could not get a good dump of Donkey Kong… Either the program was not able to recognize the proprietary formatting of the disk, or there were errors in copying the binary file to the disk image using X1DiskExplorer… I did manage to gather that the DKDG disk had some weird stuff going on. The way the disk is formatted, each track has only six sectors, and tracks 36–39 are, as far as I can tell, empty. Maybe the program wasn’t expecting that? Rather than mess with Hu-Basic source code**, I thought of one last way to get around this.
I decided to try hooking up the 3” disk drive to my Win98 machine directly. Since the X1 couldn’t tell it was any different from a 5.25” drive, why should the other computer? It was thanks to a wonderful blog post that I was able to connect the drive to a more modern computer. With some additional clues from another floppy enthusiast, I connected the drive directly to my Win98 PC on the B drive port, set the dip switches as drive 1, and configured it in the BIOS as a 360kb 5.25” drive. To my surprise, I heard the pleasant sound of a floppy drive coming to life as my PC booted up, and I was feeling even more hopeful than before.
I decided to use a program called DITT to interface with the floppy drive. DITT is a command line tool from the 16-bit era that reads/writes to the floppy drive directly and supports the .d88 format. I couldn’t find consistent info about how to use it, and there was no readme in the archive, so I set up a Japanese environment in DOSBox just to make sure I was using the commands properly. After some final testing, with fingers crossed, I stuck in DK3, typed out the magic words, and out came a disk image.
The final, working dump is the result of what DITT spat out after reading the contents of the DKDG disk. The disk image runs on emulator and on real hardware, and I haven’t encountered any problems with it yet.
Thank you for reading. I hope you can enjoy the game.
- Contributors who donated money for the preservation of this game
- aitsu124, who spearheaded this effort and gathered information about the game
- Retrospectives, who has been very helpful with translations and providing information throughout the dumping process
- All others whose works and websites have been mentioned here
*: since the HxC emulates drive 0 and drive 1 simultaneously, I kept getting conflicts when trying to use the drive internally as drive 1, so I made myself an external setup by building a cable, thinking the external cable was necessary to use drive numbers 2 and 3. I learned later that the bus lines for internal and external drives on the X1 are the same, so setting the drive number as 2 and using it internally would have worked just as well.
**:I did have to change some source code to set the drive number for the MakeD88 program