[COFF] Some Famicom/NES Utilities in the UNIX Tradition

[segaloco via COFF]

For those whom this sort of thing may interest, I wanted to take
an opportunity to share some tools I've been tinkering on lately
as well as a little background about them.  The two main sets are
at:

https://gitlab.com/segaloco/misc/-/tree/master/fc_tools

and

https://gitlab.com/segaloco/smb3/-/tree/master/tools

With the former being tools general to the Famicom/NES and the
latter being tools more specific to Super Mario Bros. 3, my
disassembly of which has served as the testbed for developing
these and other tools.

I share these not only due to their general concern of fitting a
number of different needs relevant to both development and
reverse engineering of NES games, but also due to the influence
that the UNIX philosophy has had on the design patterns and
decisions I've made.

The bulk of these tools act as filters, specifically so that they
can be strung together into pipelines as is tradition.
Furthermore, where a concern matched close enough with an
existing UNIX utility, I used that utility as the interface model
for my own.  For instance, my ddnes(1) utility derives its
argument syntax directly from dd(1) and, similar to how dd(1)
abstracts disk blocks and has some basic conversions like ASCII
to EBCDIC, allows for specifying the abstract mapping scheme of
iNES images being dumped from.  This sort of replication of
familiar UNIX interfaces as significantly lowered the cognitive
load not only of remembering flags and options, but also
contemplating the logical structure of pipelined operations. I
simply need to do the same thing I would do for a more generic
data operation, except I swap in my tools where necessary.

In some ways I owe it to TUHS and the larger community
surrounding these UNIX history efforts that these tools exist at
all.  The field of video game reverse engineering is what I cut
my teeth on as a tech person, and that field has for such a long
time been dominated by the Windows world, graphical applications,
complexity and closed-source solutions, and so on.  In other
words, being a ROM hacker on weird UNIX platforms is a lonely,
relatively DIY situation compared with the same in the Microsoft
Windows ecosystem.  Learning more about UNIX and more importantly
the UNIX philosophy through discussions here, historical
preservation, studying old manuals and source code, etc. has had
an outsize influence then on my desire to produce what, in my
obviously biased opinion, is a quite comfortable development and
reverse engineering environment for the NES on UNIX.  In many
ways I was inspired by the same motivation UNIX was developed
under, to create a simpler, more intuitive technical environment
that avoids the needless complexity of many of the more
established toolkits and workflows.

Only time will tell if my tools see uptake in the niche
communities they concern, but I felt some appreciation was in
order for the fact that UNIX impacted my development of this
toolkit on so many levels.

- Matt G.

P.S. If you're someone who tinkers with this sort of stuff and
have questions or suggestions, I'm always happy to discuss the
finer points.  Licenses are provided with the usual disclaimers,
know that there isn't much error checking, so don't feed these
bad data and redirect output into a precious file without a
backup plan.  You have been warned these are not hardened for
production workloads.