In order to illustrate what was involved in getting the information together for getting PR8 and Pulsar running on hardware I thought I’d document the whole process here including some pics of some of the boards I created to perform testing and some notes on some experiments that didn’t work out in the end :)
01 – How do you get a program running on the Famicom?
The most important thing you have to understand about the Famicom and the NES in general is that everything is driven by Mappers. Mappers are memory and hardware management chips which allow the Famicom to extend its bespoke capabilities to address more memory or extend graphics or sound or SRAM saving capabilities. For more on mappers in detail check here: http://en.wikipedia.org/wiki/Memory_Management_Controller
Where it gets tricky is when there are subsets of Mappers that people don’t know an awful lot about – these include strange board revisions that may have extended VRAM or WRAM capabilities – increasing the amount of addressable SRAM saving or even removing said abilities (more on that later)
In the case of NTRQ it was relatively easy to create a hardware cartridge solution for running the program as it ran on a standard SNROM layout and MMC1 mapper chip configuration, using a PRG rom and CHR memory ram to store gfx data… So creating a dev cart for this nice music tracker just involved swapping out the PRG rom data on the correct board and wiring it up following the slightly different mask rom pinout NIN used on their Famicom and NES boards, see http://hackitup.tumblr.com/post/15291113007/creating-a-ntrq-cartridge-for-the-famicom for more information.
However in the case of Pulsar and PR8 the board layout and Mapper called for the incredibly rare SXROM MMC1 variant – used only on two Famicom titles to my knowledge (Final Fantasy I+II and an obscure baseball game). SXROM further extended the MMC1 mapper layout to allow for:
1. 8kb of CHR RAM
2. 32kb of SRAM
3. 512kb of PRG ROM
The only problem was that obviously in order to get it running you would need a donor cart with the correct board layout and memory capability – the easiest way to get this going was to grab a FF1+2 cartridge of ebay…
02 – Creating a FF1+2 SXROM devcart
Once FF1+2 arrived I was able to de-solder the PRG rom and insert a socket into its place and pop PR8 into the cart and getting it running:

Also in order to get the actual cartridge into the system and be able to probe it correctly (due to the size restriction of the cart port) I had to create a dev tower out of a NES/Famicom + and Famicom/NES converter I had to hand:

However at this point it turned out that the way that real Famicom hardware behaved VS something like the Powerpack or even the NES was different.
I tested the dev cart plugged into one of the test Famicom’s out of its casing (to avoid the cart slot issue) just in case the dev-tower was causing some sort of delay/incompatibility (just in case) but it was still behaving erratically – with boot up issues.
My thoughts on this: On Powerpack the Famicom’s ram data is initialised slower than on h/w – this can create problems if you are testing things on this platform – as when moving it to real cartridge h/w you might see boot up glitches on your software that only correct themselves after reset.
On the NES itself the power button seems to supply power in a slightly different way to the console – possibly creating a smoother boot up process – the Famicom is a flipping switch whereas the NES is a pushbutton which seems to supply power more gracefully to the unit.
Both these issues were causing PR8 + Pulsar to behave erratically on bootup on the Famicom vs the NES + Powerpack, after speaking to Neil and trying out a few different test versions on the dev-cart he nailed the problem by fixing the initialisation routine and inserting various delays and we were all good :)
Once it was clear they were behaving correctly on hardware (after testing both programs to -death- on the FF1+2 based devcart) it was time to move onto trying to reverse engineer the SXROM format and layout and try and convert a SNROM (a very common boardtype – and the same type of board that NTRQ runs on) based cartridge to run the software reliably.
03 – Creating a SNROM SXROM Frankenstien Devcart
The next step was to try and get these nice programs running on cartridges that people could actually get their hands on (and frankly it felt terribly wrong butchering FF1+2 :)
I ordered a bunch of SNROM based Famicom carts off of good ole’ ebay and waited for them to arrive. Which took bloody ages – so while I was waiting I did a ridiculous amount of reading up on the various chips that sat on the FF1+2 cart.
It had a 62256 SRAM chip supplying the 32kb of SRAM to the unit, this was keyed via a hex inverter due to the MMC chip supplying a high signal to CS…
I traced out what connections were going where on the board and with some decent pinouts from nesdev on the MMC1 chip I was able to see where on earth the SXrom board was sending its SRAM data to/from etc.
I grabbed some Hyundai 62256B sram chips off ebay and some Toshiba TC51832SPL-85 skinny sram which shared the same pinout (more on that later *Grin*) as the SNROM boards actually have thru holes for skinny sram too! I also had various hex inverters and hex buffers laying around…
Once the SNROM carts finally arrived I constructed the following little beastie in stages for testing:



After wiring it all up it worked – almost – but unfortunately the SRAM saving was half working – instruments were saving but pattern data was not, I tracked this down to where I was powering the hex inverter on the board (I was grabbing power from the MMC1 chip – don’t do this – as it seems this does not yield happy results :) so moving the hex inverter power and gnd lines to the sram chip itself cured this (which I should have done from the beginning thinking about it logically *Grin*)
After it was all done I popped it in a nice cart case and printed a label:

Things that didnt work out along the way
Anyone that claims that things just work when doing this sort of project is lying :) - here’s a couple of example of some experiments that didn’t check out in the end;
1. TC51832SPL-85 skinny ‘sram’ does not work, as it is not true SRAM and requires a different sort of powering to retain data reliably - don’t use it :O) - you’ll have a working board but utterly unreliable saving and storage will disappear over time, even though its pinout is compatible with the 62256 this is a shame as it can be wonderfully cheap :)
2. NES Open Golf (and possibly Famicom Mario Open Golf) cartridge board layouts seem to differ from other MMC1 SNROM boards - presenting issues on bootup with both NTRQ and PR8… very strange + havent had time to track back what’s going on here… thanks to RG for doing a lot of testing on this board too!
More information
Read instructions on how to build one yourself here:
http://hackitup.tumblr.com/post/19201730531/turning-a-snrom-famicom-cartridge-into-sxrom-to-run
You can get a nice Famicom label for PR8 and NTRQ I made here too in pdf format for easy printing:
http://hackitup.tumblr.com/post/19368549455/pdf-famicom-labels-for-ntrq-pr8
Please note I’d like to thank the nesdev and nes cart db sites for being an invaluable resource in investigating and nailing what exactly is going on with the SNROM + SXROM board+layout types and Neil for making the ace software :), hope you enjoyed the read
\o_
Please Note: If you have enjoyed reading my ramblings or you are building or using one of these carts - please do consider making a donation to any of the following charities, many thanks <3
http://supportus.cancerresearchuk.org/donate/



< here


I got one of these ages ago for about 20quid to replace an older eraser that stopped working and it’s done a grand job dealing with all sorts of EPROMS (even 32mbit NeoGeo beasties) just make sure your EPROM windows are CLEAN so the UV light can get into the chip correctly :)