7 ms·

Cartridge Printed Circuit Boards

187 points by sgift 7y ago

agumonkey 7y ago
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 7y ago
  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 7y ago
    This guy did that... https://kotaku.com/programmer-hacks-cartridge-to-run-snes-games-on-the-nes-1826434092 https://kotaku.com/programmer-hacks-cartridge-to-run-snes-ga...
    - LocalH 7y ago
      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 7y ago
        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 7y ago
        I was under the impression that he was "just" stuffing the bus, perhaps I need to refresh my knowledge of the project
  - agumonkey 7y ago
    I planned to do that with a hp48 + an esp32 as grafted coprocessor. (and an eink display and a lithium battery)
    - dillonmckay 7y ago
      Are you replacing the HP48’s display w/e-ink? I have used quite a few cd-rom drive audio cables to make serial cables for those calculators. Such a great calculator.
      - agumonkey 7y ago
        That's just bedroom fantasy at this point. I was just thinking about a 2019 variant of the hp48 classic. Even though a good li-ion battery would probably suffice to run the original LCD for a long time.
        dillonmckay 7y ago
        I see there is a MAME emulation for the 48G, but I have not been able to find any projects using e-ink for MAME yet.
  - djmips 7y ago
    In the Vectrex dev community, they are putting a Raspberry Pi zero in a cart to also do “reverse emulation.” The cartridge port provides HLT which puts the internal 6809 CPU to idle and off the bus. Meanwhile the Pi can control the hardware to produce sounds and vectors. It's called PiTrex. http://computernerdkev.heliohost.org/pitrex/wiki/index.php http://computernerdkev.heliohost.org/pitrex/wiki/index.php (alternate web archive) https://web.archive.org/web/20190802005407/http://computernerdkev.heliohost.org/pitrex/wiki/index.php https://web.archive.org/web/20190802005407/http://computerne...
breadandcrumbel 7y ago
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 7y ago
  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.
byuu 7y ago
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!
- tomashubelbauer 7y ago
  This is the first time I've seen someone apologize for producing too much good content too fast. It's okay, don't worry! :)
- andrepd 7y ago
  On the contrary, thanks for the rapid-fire on these articles :)
- beagle3 7y ago
  Thank you for everything. What did you do with your old website ? I remember at had quite a few articles as well
  - byuu 7y ago
    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.
    - Sniffnoy 7y ago
nfriedly 7y ago
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 7y ago
  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.
  - bane 7y ago
    I remember when Nesticle and some of the other viable Nintendo Entertainment System emulators first started showing up. It took a while but eventually everybody just ended up settling on the iNES format by Marat Fayzullin. This was a very useful thing. I've always found it extremely frustrating that later systems had so many competing formats for the roms as you inevitably end up with lots of duplicate games just so different emulators can handle them. It gets even worse for optical media with all the .cue file stuff and distributions that provide the audio tracks outside of the iso in half a dozen different formats. It's almost impossible to assemble a good collection for those kinds of systems. I honestly think a .zip based distribution makes a lot of sense since most emulators of cartridge based systems can open zipped archives and run the first compatible file they find in them. But all the rest of the information for the game could be "built in" to the zip. If you look at the Gamebase projects, there's plenty of hobbyists who are willing to pour thousands of hours into assembling games, metadata, manual scans and other such things into those kinds of projects...but they lack the ability to unify all that ephemera into a single archive per game. If such a thing were to become standard, I'm certain people/groups outside of the "established" database groups would begin to publish collections. I for one would definitely welcome a format with built-in cheats, patches and so on and would love to download a collection of say, Japanese RPGs that come with scanned manuals, translated manuals and can run the game in the original and patched versions....or to try out all the weird and wacky Mario/Sonic patched game variants. I just can't be bothered to go download each patch myself to try it out, but if they were already present in the .zip :) I think even support soundtracks would be awesome and could see people firing up collections of games just to listen to the music, without having to keep track of a separate soundtrack archive. I think this would be an even bigger benefit for modern optical media. The .bin/.cue stuff is honestly terrible. More than half the time I've ended up with a .bin or some kind of .something that I need to convert for some reason, or mount and extract stuff and then handbuild .cue files which don't work half the time. I don't even know if the problem is what I've downloaded, the .cue I made or the emulation compatibility. A standard distribution "format" that just solved all that would be incredibly useful.
leetbulb 7y ago
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
mritunjoy 7y ago
Yahooo
hutattedonmyarm 7y ago
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 7y ago
  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 7y ago
    Reeder, both on macOS and iOS. NetNewsWire is pretty good too, but doesn’t support syncing to inoreader
tenebrisalietum 7y ago
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.
userbinator 7y ago
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.

187 points by sgift 7y ago

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 7y ago
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 7y ago
  This guy did that... https://kotaku.com/programmer-hacks-cartridge-to-run-snes-games-on-the-nes-1826434092 https://kotaku.com/programmer-hacks-cartridge-to-run-snes-ga...
  - LocalH 7y ago
    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 7y ago
      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 7y ago
        I was under the impression that he was "just" stuffing the bus, perhaps I need to refresh my knowledge of the project
- agumonkey 7y ago
  I planned to do that with a hp48 + an esp32 as grafted coprocessor. (and an eink display and a lithium battery)
  - dillonmckay 7y ago
    Are you replacing the HP48’s display w/e-ink? I have used quite a few cd-rom drive audio cables to make serial cables for those calculators. Such a great calculator.
    - agumonkey 7y ago
      That's just bedroom fantasy at this point. I was just thinking about a 2019 variant of the hp48 classic. Even though a good li-ion battery would probably suffice to run the original LCD for a long time.
      - dillonmckay 7y ago
        I see there is a MAME emulation for the 48G, but I have not been able to find any projects using e-ink for MAME yet.
- djmips 7y ago
  In the Vectrex dev community, they are putting a Raspberry Pi zero in a cart to also do “reverse emulation.” The cartridge port provides HLT which puts the internal 6809 CPU to idle and off the bus. Meanwhile the Pi can control the hardware to produce sounds and vectors. It's called PiTrex. http://computernerdkev.heliohost.org/pitrex/wiki/index.php http://computernerdkev.heliohost.org/pitrex/wiki/index.php (alternate web archive) https://web.archive.org/web/20190802005407/http://computernerdkev.heliohost.org/pitrex/wiki/index.php https://web.archive.org/web/20190802005407/http://computerne...

breadandcrumbel 7y ago

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 7y ago
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.

byuu 7y ago

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!

tomashubelbauer 7y ago
This is the first time I've seen someone apologize for producing too much good content too fast. It's okay, don't worry! :)
andrepd 7y ago
On the contrary, thanks for the rapid-fire on these articles :)
beagle3 7y ago
Thank you for everything. What did you do with your old website ? I remember at had quite a few articles as well
- byuu 7y ago
  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.
  - Sniffnoy 7y ago

nfriedly 7y ago

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 7y ago
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.
- bane 7y ago
  I remember when Nesticle and some of the other viable Nintendo Entertainment System emulators first started showing up. It took a while but eventually everybody just ended up settling on the iNES format by Marat Fayzullin. This was a very useful thing. I've always found it extremely frustrating that later systems had so many competing formats for the roms as you inevitably end up with lots of duplicate games just so different emulators can handle them. It gets even worse for optical media with all the .cue file stuff and distributions that provide the audio tracks outside of the iso in half a dozen different formats. It's almost impossible to assemble a good collection for those kinds of systems. I honestly think a .zip based distribution makes a lot of sense since most emulators of cartridge based systems can open zipped archives and run the first compatible file they find in them. But all the rest of the information for the game could be "built in" to the zip. If you look at the Gamebase projects, there's plenty of hobbyists who are willing to pour thousands of hours into assembling games, metadata, manual scans and other such things into those kinds of projects...but they lack the ability to unify all that ephemera into a single archive per game. If such a thing were to become standard, I'm certain people/groups outside of the "established" database groups would begin to publish collections. I for one would definitely welcome a format with built-in cheats, patches and so on and would love to download a collection of say, Japanese RPGs that come with scanned manuals, translated manuals and can run the game in the original and patched versions....or to try out all the weird and wacky Mario/Sonic patched game variants. I just can't be bothered to go download each patch myself to try it out, but if they were already present in the .zip :) I think even support soundtracks would be awesome and could see people firing up collections of games just to listen to the music, without having to keep track of a separate soundtrack archive. I think this would be an even bigger benefit for modern optical media. The .bin/.cue stuff is honestly terrible. More than half the time I've ended up with a .bin or some kind of .something that I need to convert for some reason, or mount and extract stuff and then handbuild .cue files which don't work half the time. I don't even know if the problem is what I've downloaded, the .cue I made or the emulation compatibility. A standard distribution "format" that just solved all that would be incredibly useful.

leetbulb 7y ago

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

mritunjoy 7y ago

Yahooo

hutattedonmyarm 7y ago

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 7y ago
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 7y ago
  Reeder, both on macOS and iOS. NetNewsWire is pretty good too, but doesn’t support syncing to inoreader

tenebrisalietum 7y ago

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.

userbinator 7y ago

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.