From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5582 invoked from network); 17 Oct 2023 22:41:55 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 17 Oct 2023 22:41:55 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C1B8F4296D; Wed, 18 Oct 2023 08:41:53 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1697582513; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=xnnvs9aYMPA2zRgenLjarRIlRlCCwV2L/tODodE8wHY=; b=ShniKV9j6v2tLMq1TOhZ1Riv/fleTMxdh3dfL7OylUO7uDajFQXxeT0KI9VQBEER2RR8zD jMjomAdxNmEvAkK2n6HoUg4V7oUPfEt+Ks0QTnJWIMr/nHf7A2MgN7F5q5Jx5nGmyYspca ZhzcLQrfZyVtqnH+mpojRwVigHHVG4w= Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by minnie.tuhs.org (Postfix) with ESMTPS id AA68D4296B for ; Wed, 18 Oct 2023 08:41:47 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1697582505; x=1697841705; bh=xnnvs9aYMPA2zRgenLjarRIlRlCCwV2L/tODodE8wHY=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=xRcW80D7t0mmR4sUMilZPEnPhwg9lrkD5/8bLoA/Bzfq1UavL/dB8o3aCp90ILsUc br9g/K2CbqL8/1VhyZOBkfOvL6FTVGOL0vp1GZYR4Cd380CXEBvH4x3pS6Xv4NEfrO e4YrN7R5UrIuXX9XR2rWWvwvuf5ioBNIOTa6wpalfZyUh7QjPRWdoD5BTRd4Cs6nOM IF5Fw3BYy6g4AIyvhb4m1rz8ph/wUg54ltP1NnI5E2AG4PiJ9j3PGaXPI5R6wr9O07 Zjl0qgNLZCteDfaIT8URsM1j7VxU+KOUvUwE/mP83xfYlSeedF7fNRSNrRCC2pzj1L w8cX4mM2XidLg== Date: Tue, 17 Oct 2023 22:41:36 +0000 To: COFF Message-ID: Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 5EHMFBK7ENVQ5KV5LLQUE7NNDP3OJBY4 X-Message-ID-Hash: 5EHMFBK7ENVQ5KV5LLQUE7NNDP3OJBY4 X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Famicom Disk System Software Disassembly (Doki Doki Panic) List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via COFF Reply-To: segaloco Good day everyone, I thought I'd share a new project I've been working on s= ince it is somewhat relevant to old and obscure computing stuff that hasn't= gotten a lot of light shed on it. https://gitlab.com/segaloco/doki After the link is an in-progress disassembly of Yume Kojo: Doki Doki Panic = for the Famicom Disk System, known better in the west as the engine basis f= or Super Mario Bros. 2 for the NES (the one with 4 playable characters, pic= k-and-throw radishes, etc.) What inspired me to start on this project is the Famicom Disk System is pai= nfully under-documented, and what is out there is pretty patchy. Unlike wi= th its parent console, no 1st party development documentation has been arch= ived concerning the Disk System, so all that is known about its programming= interfaces have been determined from disassemblies of boot ROMs and bits a= nd pieces of titles over the years. The system is just that, a disk drive = that connects to the Famicom via a special adapter that provides some RAM, = additional sound functionality, and some handling for matters typically con= trolled by the cartridge (background scroll-plane mirroring and saving part= icularly.) The physical disk format is based on Mitsumi's QuickDisk format= , albeit with the casing extended in one dimension as to provide physical s= ecurity grooves that, if not present, will prevent the inserted disk from b= ooting. The hardware includes a permanently-resident boot ROM which maps t= o 0xE000-0xFFFF (and therefore provides the 6502 vectors). This boot ROM i= n turn loads any files from the disk that match a specified pattern in the = header to header-defined memory ranges and then acts on a secondary vector = table at 0xDFFA (really 0xDFF6, the disk system allows three separate NMI v= ectors which are selected from by a device register.) The whole of the sta= ndard Famicom programming environment applies, although the Disk System add= s an additional bank of device registers in a reserved memory area and expo= ses a number of "syscalls" (really just endpoints in the 0xE000-0xFFFF rang= e, it's unknown at present to what degree these entries/addresses were docu= mented to developers.) I had to solve a few interesting challenges in this process since this part= icular area gets so little attention. First, I put together a utility and = supporting library to extrapolate info from the disk format. Luckily the h= eader has been (mostly) documented, and I was able to document a few consis= tencies between disks to fill in a few of the parts that weren't as well do= cumented. In any case, the results of that exercise are here: https://gitl= ab.com/segaloco/fdschunk. One of the more interesting matters is that the = disk creation and write dates are stored not only in BCD, but the year is n= ot always Gregorian. Rather, many titles reflect instead the Japanese peri= od at the time the title was released. For instance, the Doki Doki Panic i= mage I'm using as a reference is dated (YY/MM/DD) "61/11/26" which is prepo= sterous, the Famicom was launched in 1983, but applying this knowledge of t= he Showa period, the date is really "86/11/26" which makes much more sense.= This is one of those things I run into studying Japanese computing histor= y time to time, I'm sure the same applies to earlier computing in other non= -western countries. We're actually headed for a "2025-problem" with this t= ime-keeping as that is when the Showa calendar rolls over. No ROMs have be= en recovered from disk writer kiosks employed by Nintendo in the 80s, so it= is unknown what official hardware which applies these timestamps does when= that counter rolls over. I've just made the assumption that it should rol= l back to 00, but there is no present way to prove this. The 6502 implemen= tation in the Famicom (the Ricoh 2A03) omitted the 6502 BCD mode, so this w= as likely handled either in software or perhaps a microcontroller ROM down = inside the disk drives themselves. I then had to solve the complementary problem, how do I put a disk image ba= ck together according to specs that aren't currently accessible. Well, to = do that, I first chopped the headers off of every first-party Nintendo imag= e I had in my archive and compared them in a table. I diverted them into t= wo groups: pristine images that represent original pressings in a Nintendo = facility and "dirty" images that represent a rewrite of a disk at one of th= e disk kiosks (mind you, Nintendo distributed games both ways, you could bu= y a packaged copy or you could bring a rewritable disk to a kiosk and "down= load" a new game.) My criterion for categorization was whether the disk cr= eate and modify times were equal or not. This allowed me to get a pretty g= ood picture of what headers getting pumped out of the factory look like, an= d how they change when the disk is touched by a writer kiosk. I then took = the former configuration and wrote a couple tools to consume a very spartan= description of the variable pieces and produce the necessary images: https= ://gitlab.com/segaloco/misc/-/tree/master/fds. These tools, bintofdf and f= dtc, apply a single file header to a disk file and create a "superblock" fo= r a disk side respectively. I don't know what the formal terms are, they m= ay be lost to time, but superblock hopefully gets the point across, albeit = it's not an exact analog to UNIX filesystems. Frankly I can't find anythin= g regarding what filesystem this might be based on, if at all, or if it is = an entirely Nintendo-derived format. In any case, luckily the header descr= ibing a file is self-contained on that file, and then the superblock only n= eeds to know how many files are present, so the two steps can be done indep= endently. The result is a disk image, stamped with the current Showa BCD d= ate, that is capable of booting on the system. The only thing I don't add = that "pure" disks contain are CRCs of the files. On a physical disk, these= header blocks also contain CRCs of the data they describe, these, by conve= ntion, are omitted from disk dumps. I'm actually not entirely sure why, bu= t I imagine emulator writers just omit the CRC check as well, so it doesn't= matter to folks just looking to play a game. Finally, there's the matter of disparate files which may or may not necessa= rily be sitting in memory at runtime. Luckily the linker script setup in c= c65 (the compiler suite I'm using) is pretty robust, and just like my Drago= n Quest disassembly (which is made up of swappable banks) I was able to use= the linker system to produce all of the necessary files in isolation, rath= er than having to get creative with orgs and compilation order to clobber s= omething together that worked. This allows the code to be broken down into= its logical structure rather than just treating a whole disk side as if it= was one big binary with .org commands all over the place. Anywho, I don't intend on a rolling update to this email or anything, but i= f this is something that piques anyone's interest and you'd like to know mo= re, feel free to shoot me a direct reply. I'd be especially interested in = any stories or info regarding Mitsumi QuickDisk, as one possibility is that= Nintendo's format is derived from something of their own, with reserved/un= defined fields redefined for Nintendo's purposes. That said, it's just a m= agnetic disk, I would be surprised if a single filesystem was enforced in a= ll implementations. Thanks for following along! - Matt G. P.S. As always contributions to anything I'm working on are welcome and enc= ouraged, so if you have any input and have a GitLab account, feel free to o= pen an issue, fork and raise a PR, etc.