Got another iron in the fire: https://gitlab.com/segaloco/smb
I started working up a disassembly of plain old Super Mario Bros. so I'd have code to compare for my real goal: a code-flow analysis between Super Mario Bros. and Doki Doki Panic (and SMB3 if I get to it).
After seeing some chit chat concerning All Night Nippon Super Mario Bros. and some other stuff, I decided to take what I had kinda half-assedly clobbered together and put some polish on it, producing the start of a repository containing one code-base that builds into all four Super Mario Bros. variants: the Famicom title, the FDS reissue, Super Mario Bros. 2, and All Night Nippon. The process isn't too different from what I've been doing with other stuff, although it technically started as straight Famicom only, so the other three streams have a bit of catchup to do. In any case, it's mostly just looking at the PRG bank for each title side by side, seeing where the few differences are. Of course, I'm not sussing everything out with a magnifying glass, a quick pass like that and then through the assembler, some diffing, and anything that gets missed gets picked up in that pass. In any case, it's proving to have a nice flow to it just like working with a single binary file.
Some advice if you truly want to play around with this (there ain't much there yet...I've been focused on the logistics of a 4-way build system that isn't a nightmare...):
First, extracting assets requires using the various scripts provided. There's one for each title, and they all expect "headered" images, so iNES for the Famicom title and "FDS" for the Famicom Disk System images. I've seen FDS games distributed both with and without headers. In the latter situation (indicated by the first 16 bytes of the image including something like NINTENDO-HVC) you really just need to pad the beginning with 16 bytes before shooting it through an extraction script, the script doesn't care about the header, just the padding. Each script is geared towards a particular title, as such, running them all may present some redundancy, as for instance the CHR between the Famicom and FDS versions of Super Mario Bros. are identical.
The Makefile expects to build the Famicom version by default. As such, it provides the necessary ASFLAGS for this version. I have not settled on precisely how I want to handle this in the Makefile, nothing portable has presented itself thus far and manually adjusting the added ASFLAGS when testing other builds isn't a hastle, much less than producing something that won't work when I inevitably switch back to FreeBSD or give illumos another spin or whatever. Maybe the subset of make(1)s between them support a common ifdef system...but meh it ain't in POSIX. Anywho, to get the other builds, replace the ASFLAGS_FC inclusion near the top of the makefile with the appropriate set, all four should already be present there. In addition, be sure to issue the name of the correct output, currently the iNES ROM is the default make rule.
So basically, to build All Night Nippon Super Mario Bros. with this repository:
- Run the necessary extraction script on a 16-byte-headered ANN FDS image
- Replace ASFLAGS_FC with ASFLAGS_ANN in the ASFLAGS assignment in the Makefile
- Issue "make ann.fds"
The preprocessor defintions serve a few purposes. Some section off code particular to a given title. Others section off platform or revision specific code, the latter mostly referring to the dichotomy between the two issues of Super Mario Bros. vs ANN and 2. The latter two are on the later version of the engine while the former are largely identical save for FDS differences required in the transportation to the disk system.
This project is not my top priority right now, and I am uploading it quite early in the process. As such, it probably won't be useful for quite a while, but I wanted to both get it up online so I don't lose it in some tragic accident and get an example of this sort of thing up that I can point to when explaining some of the variations between straight Famicom and Disk System stuff, different bank-based building approaches, shared code stuff, etc. Ultimately though, my personal use for this is to have a source of comparison with Doki Doki Panic. Being able to trace key design and code elements between the two is my central goal here.
I started working up a disassembly of plain old Super Mario Bros. so I'd have code to compare for my real goal: a code-flow analysis between Super Mario Bros. and Doki Doki Panic (and SMB3 if I get to it).
After seeing some chit chat concerning All Night Nippon Super Mario Bros. and some other stuff, I decided to take what I had kinda half-assedly clobbered together and put some polish on it, producing the start of a repository containing one code-base that builds into all four Super Mario Bros. variants: the Famicom title, the FDS reissue, Super Mario Bros. 2, and All Night Nippon. The process isn't too different from what I've been doing with other stuff, although it technically started as straight Famicom only, so the other three streams have a bit of catchup to do. In any case, it's mostly just looking at the PRG bank for each title side by side, seeing where the few differences are. Of course, I'm not sussing everything out with a magnifying glass, a quick pass like that and then through the assembler, some diffing, and anything that gets missed gets picked up in that pass. In any case, it's proving to have a nice flow to it just like working with a single binary file.
Some advice if you truly want to play around with this (there ain't much there yet...I've been focused on the logistics of a 4-way build system that isn't a nightmare...):
First, extracting assets requires using the various scripts provided. There's one for each title, and they all expect "headered" images, so iNES for the Famicom title and "FDS" for the Famicom Disk System images. I've seen FDS games distributed both with and without headers. In the latter situation (indicated by the first 16 bytes of the image including something like NINTENDO-HVC) you really just need to pad the beginning with 16 bytes before shooting it through an extraction script, the script doesn't care about the header, just the padding. Each script is geared towards a particular title, as such, running them all may present some redundancy, as for instance the CHR between the Famicom and FDS versions of Super Mario Bros. are identical.
The Makefile expects to build the Famicom version by default. As such, it provides the necessary ASFLAGS for this version. I have not settled on precisely how I want to handle this in the Makefile, nothing portable has presented itself thus far and manually adjusting the added ASFLAGS when testing other builds isn't a hastle, much less than producing something that won't work when I inevitably switch back to FreeBSD or give illumos another spin or whatever. Maybe the subset of make(1)s between them support a common ifdef system...but meh it ain't in POSIX. Anywho, to get the other builds, replace the ASFLAGS_FC inclusion near the top of the makefile with the appropriate set, all four should already be present there. In addition, be sure to issue the name of the correct output, currently the iNES ROM is the default make rule.
So basically, to build All Night Nippon Super Mario Bros. with this repository:
- Run the necessary extraction script on a 16-byte-headered ANN FDS image
- Replace ASFLAGS_FC with ASFLAGS_ANN in the ASFLAGS assignment in the Makefile
- Issue "make ann.fds"
The preprocessor defintions serve a few purposes. Some section off code particular to a given title. Others section off platform or revision specific code, the latter mostly referring to the dichotomy between the two issues of Super Mario Bros. vs ANN and 2. The latter two are on the later version of the engine while the former are largely identical save for FDS differences required in the transportation to the disk system.
This project is not my top priority right now, and I am uploading it quite early in the process. As such, it probably won't be useful for quite a while, but I wanted to both get it up online so I don't lose it in some tragic accident and get an example of this sort of thing up that I can point to when explaining some of the variations between straight Famicom and Disk System stuff, different bank-based building approaches, shared code stuff, etc. Ultimately though, my personal use for this is to have a source of comparison with Doki Doki Panic. Being able to trace key design and code elements between the two is my central goal here.
Statistics: Posted by segaloco — Tue Jan 02, 2024 11:28 pm — Replies 0 — Views 76