nesdev.com

Holy Mapperel
NES cartridge PCB manufacturing test

Source code is on GitHub: pinobatch/holy-mapperel
____________________

Paul Molloy (infiniteneslives) is selling INL-ROM circuit boards for making NES game cartridges. These boards are configured at manufacturing time to support the mapper circuits required by several games. Among them are Holy Diver by IREM (#78.3) and Batman: Return of the Joker by Sunsoft (#69). Putting those titles together results in something Burt Ward as Dick "Robin" Grayson might say: "Holy diver, Batman!"

To make testing easier before he ships the product, he has commissioned a test ROM that automatically detects the mapper, PRG ROM size, PRG RAM size and battery backup, and CHR ROM/RAM and size. It tests every byte of RAM on the cart and basic functionality of the mapper, though nowhere near as thoroughly as blargg's tests. If something is seriously wrong, it beeps out 2 or 3 letters of Morse code describing the error; your local ham can interpret these for you. Otherwise, it displays the results on the screen and beeps them through the speaker.

It's also useful for people learning to make NES reproductions. If you can successfully make a Holy Diver Batman cart on a given board, you can reproduce most games that use the same board.

Supported mappers: SxROM (1), UxROM (2), TxROM (4), AxROM (7), PNROM (9), FxROM (10), INL-ROM Action 53 (28), BNROM (34), NROM/CNROM/GNROM (66), JxROM (69), IF-12 (78.3), TxSROM (118), UxROM (180)

Try Holy Diver Batman 0.01 on your devcart.

To avoid trademark problems, the project is renamed to Holy Mapperel as of version 0.02.

One thought that occurred to me: for battery-backing detection, you should be able to detect if the user hit RESET instead of power cycling by using a fingerprint in NES-internal RAM. If it wasn't enough time to fade from internal RAM, it wouldn't have been enough time to fade from cartridge RAM either.

Also, the README doesn't seem to mention the "LB" or "SU" morse codes.

Thanks again Tepples.



That's an interesting thought. I think it'd work for detecting TSROM vs TKROM well, although a faulty TKROM (eg no battery) Would probably still pass as TKROM because of the diodes and caps protecting that supply from being drained by the NES. It takes a few mins for a TKROM with missing battery to discharge the cap and corrupt data.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

the .7z download link gives text gibber...

Am I/my browser doing something wrong?

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

The .7z file should be opened in 7-Zip. If you're already using 7-Zip, then perhaps p7zip (the command-line version of 7-Zip used by the archive manager in my OS) has a bug. Or did you accidentally download it as .7z.txt? If so, I might need to figure out how to add 7-Zip's MIME type to my web hosting.

There's no means to download it in the traditional sense (the .zip downloads just fine in my browser)

But the .7z just opens a new page (address: http://pineight.com/nes/holydiverbatman-bin-0.01.7z) in my brower with all that gibber. I suppose I could copy paste it into a .7z file I create myself or boot up my linux machine and wget it quick. But I don't get the impression that's the desired means of download.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

The file is being served with MIME type text/plain for some reason, and so your browser ignores the extension and tries to render it as text. You can right click on the link and select "Save As" and the file will save properly.

What browser are you using? Both Firefox for Linux and Chrome for Linux start a download.

EDIT: Grapeshot is right, as confirmed through

I'm looking up how to set MIME types through my web host.

EDIT 2: After I appended the following to the site's .htaccess, Wget confirmed the correct Content-type.

save as worked. I also refreshed and was able to download it by normal means, guessing you fixed it, or it was a fluke? Anyways, I'm using firefox and it's working fine now.

Got MinGW and MSYS installed and working through building things for myself on my windows7 64-bit machine.

First thing I noticed is all the src directory names for files including files which are also in the src directory.

Changing things like



fixed those up easily as I run into them while compiling.

But now I'm running into something kinda funky...

line 540 of main.s and surrounding:


I don't really understand the funky notation of the adc #'A'-'9'-2-64 and there's just a lonely little semi-colon on the next line??? Commenting that line out and continuing on for the moment...

Looks like I got through all that to the point of where I need to get python up and running.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Include paths changed from older ca65, where they were relative to the current directory, to newer ca65, where they are relative to the directory containing the source code file.


This also changed from older ca65 to newer ca65. Newer ca65 requires constants used as immediate values to be positive integers, not negative integers. Change it to the following:



'A' means the code unit for the character LATIN CAPITAL LETTER A in ASCII encoding, which is $41.
'9' means the code unit for the character DIGIT NINE in ASCII encoding, which is $39.
'A'-'9' means the difference between these code units, which is $41 - $39 = $08.
The minus 2 includes one for the fact that 'A' and '9' are one apart, and one for the fact that the carry is set on entry to this line.
The minus 64 compensates for the fact that the glyphs for characters with ASCII encodings $20-$3F and $40-$5F are stored at tiles $20-$3F and $00-$1F.

I should add these as comments to the next version.


Not a semicolon, a colon. It's an unnamed label.

Do I need to make another release targeting the new version of ca65?

Understand all, thanks for the info. Fixed up with your suggestion and compiling assembly files just fine now. No need for another release, I'd rather just stick with my current build anyways. Hopefully after I can get some of this flash identifying code written up in the near future. That might be a good time to release for new ca65.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

I've successfully modified drivers.s in order to read flash manf/device ID's from PRG flash and CHR flash on NROM flash cart.

Some things should probably be moved around to a more appropriate location as my understanding is only mapper specific code belongs in the driver. I'm proposing a new file flash.s which would provide code in the prg-rom that doesn't get copied to RAM with the driver. With that setup the only code in the drivers would be prg flash sensing which is the only code that NEEDS to run from RAM.

I've pretty well settled on my hardware design for flashable discrete mapper boards. I discussed it over here which turned out to be pretty accurate. I've confirmed that there is indeed not enough address setup time before PRG R/W goes low. Driving /CE with ~M2 works great for my NROM board, I'll try BNROM next, but all signs point to success with this method.

PRG flash ROM
/OE -> PRG /CE
/CE -> ~M2
/WE -> PRG R/W

Here is code where I read the manf & device ID from a NROM, which has been tested and working on hardware. Reading CHR flash ID's works too, but isn't as interesting...


I'm sticking with my idea (or at least would like to support) to use NOR gates on a UNROM board which gives a free inverter. Only difference there is that PRG A14 gets inverted in that case. Which moves $5555->$1555, and $2AAA->6AAA. So $1555 conflicts with RAM mirrored down to $0555. That's pretty much smack dab in the middle of RAM. Shouldn't be too much of an issue so long as the driver isn't there, I'm guessing it is though... Chances are as long as I clean up after myself and temporarily store the value (code) in $0555 and then restore it I'll be safe. If those few (~8) instructions happen to land in the same exact spot you'd stomp over yourself though. What's the best way to avoid that with the driver code?

As an aside, any idea what happens when you write to $2002 PPUSTATUS? Guessing/hoping nothing, or at most resets the latch just like a read does. It'd be a bummer if it didn't decode the difference between R/W and caused a bus conflict when writting to $2002 and it's mirrors.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Nothing happens. The 2C02 has a lookup table that decodes the 5-bit input (A0,A1,A2,R/W,loopy_w), and only 12 of the 32 are decoded: w2000, w2001, r2002, w2003, w2004, r2004, w2005a, w2005b, w2006a, w2006b, w2007, r2007.

The CHR flash detection code could be put there as well, relying on the mapper driver's implementation of set_chr_8k to set the upper bits of the CHR ROM address.


Right now the driver is $0300-$04FF or thereabouts IIRC, but we planned to extend it to 3 pages. I could do that by changing the link script to move the mapper driver's run address down to $0200 and moving OAM up to $0700.


Ignored in an authentic NES, as lidnariq mentioned. You could verify it in Visual 2C02 if you want. But some famiclones that support enhanced graphics modes might be using w2002 for something.

Yeah that's what I was thinking. It might be easier to keep all the chr flash detecting in one location though. Assuming the flash detection was called after all other testing/sensing was complete, the chr flash detection could do everything from flash.s since it would know the mapper and board config. Either way would work though, doesn't make much difference either way.

That'd work for me!

Good to know it won't be an issue on the NES, if it is an issue on clones that choice could be for the developer to decide how to handle. Similar to whether one would choose to use 4 screen mirroring. There are options to keep the unlock registers from conflicting with RAM. For one, most homebrews appear to be 256KB these days which means there is no free inverter to be had on UOROM. For UOROM you could use standard OR gates and then a single inverter to generate ~M2 keeping commands at $2AAA/$5555.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers