
Cartridge Printed Circuit Boards - sgift
https://byuu.net/cartridges/boards
======
byuu
Hi, sorry for the rapid-fire on these articles ^-^;;

I'm trying to build out the site to debut it on an upcoming AMA, as right now
it's quite new. By October, new articles will proceed at a more reasonable
pace.

I do greatly appreciate the attention here, however! I was afraid with it
being a new domain with no links, the content would end up not being found by
anyone. HN has helped me tremendously, and for that I am very grateful. It's
been a real privilege to have so many people reading and caring about this
little niche of mine.

Thank you all very much!

~~~
beagle3
Thank you for everything.

What did you do with your old website ? I remember at had quite a few articles
as well

~~~
byuu
A combination of two things: one, I redesigned my site from PHP and raw HTML
articles to C++ and Markdown articles, and didn't want to update all of them
to the new format. Two, I feel I was a bit too confrontational and opinionated
with my viewpoints in the past. I've grown and mellowed out a lot in the
20-years I've had an online presence, and I don't really stand by some of the
older pieces I've written anymore. It's always been a struggle to counter-
balance the passion/intensity of coding with that of my writing; they tend to
be a package deal ^^;

I'm open to suggestions to revise and bring back any specific articles, if
there's a technical piece you miss.

~~~
Fej
Have you considered re-opening your forums? It was a nice little corner of the
Internet.

My understanding is that you did so to purge social media interaction? but
you're back here and on reddit, so I suppose you haven't sworn it off
completely.

Thanks for all your hard work!

~~~
thristian
byuu didn't want the hassle of community management on top of emulator
development, which is understandable. Most of the old forum regulars now hang
out at [https://helmet.kafuka.org/bboard/](https://helmet.kafuka.org/bboard/)
if you want to talk about emulator development, or thread derailing.

If you prefer more technical content to social, the NESDev forums have a
"SNESDev" sub-forum, too:
[https://forums.nesdev.com/viewforum.php?f=12](https://forums.nesdev.com/viewforum.php?f=12)

------
nfriedly
I, for one, really like the idea of a single .zip file per game. Then you can
include the unmodified ROM, a separate file with configuration data, any
necessary firmware, box art, and any other information an emulator might want.
And it saves a little space to!

Also, if two different emulators want two different configuration formats, you
could just include both! (As long as the file names aren't the same.)

~~~
byuu
I very much agree. My vision was a ZIP file that when selected in an emulator,
could be extracted for instant access, and any save RAM, cheat codes, save
states, etc could be stored alongside the game in said folder. It would be
bundled with an extensible markup description of the board, and optional pack-
in content like box art and user manuals. For games stored on flash memory
that could write to themselves (BS Memory, Neo Geo Pocket), this would also
prevent the archived, pristene copy from being damaged. The folder would then
act like a physical cartridge, and all your game saves would move along with
it.

I wrote about my idea here: [https://higan.byuu.org/game-
paks](https://higan.byuu.org/game-paks)

It ... was not a popular idea, to put it mildly. I further shot myself in the
foot by trying to force the idea on people. You will never win people over
with an approach like that.

Let's avoid mentioning names for obvious reasons, but unfortunately those most
capable of adopting and promoting such a format through their database effort
are unwilling to use ZIP archives in this way. They will only allow for an
uncompressed single-file-per-game approach.

As mentioned in my article, this turns into quite the problem. When you take
the 8KB program ROM for Galaxian, and append a character ROM for graphics onto
it, but your header can only tell you the size of the program ROM in 16KB
increments, it means there's no way of specifying where the program ROM ends,
and the character ROM begins. Any emulator that supports Galaxian does it via
game-specific workarounds like checksum identification.

~~~
zamadatix
I must be missing understanding on some part of the picture of why many were
so against it. Unless I'm missing something everything but "decompress the
file and load the ROM in it" is completely optional to implement and would be
no different than how things work with raw ROMs today, what was the push back
on?

~~~
thristian
There were a few points of contention:

\- for consistency and simplicity, byuu wanted a standard naming scheme for
the files inside the archive. The main game data should be "program.rom", the
non-volatile storage should be "save.ram", etc. Unfortunately, existing
emulators all work by grabbing the first (or last?) file they find whose name
ends in .sfc, so that was an incompatibility.

\- Many people don't pick their own filenames, they use a database like No-
Intro or GoodSNES to rename and compress files automatically. Such tools would
mistakenly rip apart structured game folders every time they were run.

\- Many emulators have config settings for "where to store save games" and
"where to look for patch files". If a game folder contains a patch file,
should it be loaded instead of a patch in the "patch files" directory? If a
game folder is loaded, should save games be written to the folder instead of
the "save games" directory?

------
tenebrisalietum
The Atari 2600 is an example of a system where games didn't have headers and a
checksum/database or other heuristic has to be used to account for the
occasional hardware extension.

Z26 implements a heuristic to determine PAL or NTSC mode, which is done by
monitoring how long the software takes to begin outputting lines (PAL's vblank
is longer than NTSC's).

But this article makes me think of the problem of determining the boundary
between emulation and simulation. The reason why the original Atari Pong of
1972 is not in MAME is because Pong doesn't have a CPU, it's all implemented
as discrete hardware (and has no ROM). But you can't play any games on any
emulator if some hardware isn't simulated, like the video.

There is some project that will take a description of the Pong schematic and
render a playable game, but it's very slow. I can't recall the name of it. I
also find it interesting that the NES's video chip has been reverse engineered
to the point of accounting for every change in waveform it outputs to
composite video--even the bad ones; meaning the flickerly color fringes and
unsmooth vertical lines of real NES video are now documented and implementible
by anyone who cares.

------
leetbulb
Extremely well written. The Mega_Man_X#Copy_Protection[0] is very interesting.
I admire (total understatement) the R&D and sheer passion that goes in to
preservation / emulation.

[0]
[https://tcrf.net/Mega_Man_X#Copy_Protection](https://tcrf.net/Mega_Man_X#Copy_Protection)

------
hutattedonmyarm
I just finished my RSS queue with that article being the last, opened HN and
saw it here!

I really enjoyed it, just a minor nitpick: I’d love if you provided the full
article text in your RSS feed

~~~
sildur
Which RSS client do you use, if you don’t mind? I’m on my personal quest to
find a good RSS client, without success, for now.

~~~
hutattedonmyarm
Reeder, both on macOS and iOS. NetNewsWire is pretty good too, but doesn’t
support syncing to inoreader

------
breadandcrumbel
The end of this article is gold

'So unfortunately, I can't end this article with a solution. It's an open
problem in emulation.'

~~~
byuu
Indeed, every approach has significant trade-offs.

I've even had it non-jokingly suggested to provide netlists of the game
cartridges. But well, that's great if you don't mind your SNES emulator never
reaching 60fps. And good luck asking most emulator developers to simulate
full-on netlists and logic chips directly, instead of a single-byte in a
header that lets you turn that into a few if((address&mask)==range) checks.

Further, in practice, getting emulator developers to all agree on a solution
is like herding sheep. The NES has a long history of very strong opinions on
how this should be done, and in my earlier, more boisterous days, I did as
well.

These days, I've taken to the more pragmatic yet developer-intensive approach
of just supporting as many options as possible and letting the user decide. I
do the best I can and when things fall through the cracks due to missing
information, it just is what it is.

------
agumonkey
IIRC the NES had an analog bypass that could fetch signals to the cartridge
for processing, meaning your game is actually a full blown hardware extension.
Some youtube video talked about that regarding Japanese version of Castlevania
(it had a complete FM synth chip embedded)

~~~
byuu
That is correct. Every cartridge on every system can do this, if you don't
care about the cartridge potentially being oversized.

There is no reason you couldn't put a Raspberry Pi Zero inside of an NES
cartridge. You would just need to write a communication layer between the NES
and the Pi.

In practice, the NES, SNES and MSX had this expansion done the most. The
Genesis only really had Virtua Racing. And other systems tended to be pretty
much standard, with few exceptions.

~~~
dillonmckay
This guy did that...

[https://kotaku.com/programmer-hacks-cartridge-to-run-snes-
ga...](https://kotaku.com/programmer-hacks-cartridge-to-run-snes-games-on-the-
nes-1826434092)

~~~
LocalH
One difference - I think that guy essentially forces his signal on the various
data lines instead of having a proper NES "communication layer", which is why
it's a bit glitchy

~~~
mrob
The graphical glitches are the result of timing inaccuracies. This technique
is a just higher resolution version of what the MMC5 mapper does to get 8x8
attribute blocks. It's not "forcing" anything.

~~~
LocalH
I was under the impression that he was "just" stuffing the bus, perhaps I need
to refresh my knowledge of the project

------
userbinator
The PC industry came up with various "plug and play" standards to describe the
configuration of the hardware and make it easily understandable by software,
but as evidenced by the complexity of something like ACPI, it's a hard problem
for them too.

Memory mapping is relatively easy to describe; other peripherals on the bus
(like a second CPU), not so much.

