Holy Mapperel (formerly Holy Diver Batman)
Moderator: Moderators
Holy Mapperel (formerly Holy Diver Batman)
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.
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.
Re: Holy Diver Batman
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.
Also, the README doesn't seem to mention the "LB" or "SU" morse codes.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.lidnariq wrote: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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
the .7z download link gives text gibber...
Am I/my browser doing something wrong?7z¼¯'�§’äã#-������#�������¦lÆ�$ɇÊç#< ò§‘y%"6f–$É„¦
º¸Ú¼®úŽÈòa-Ž^ºüZ˜¤ßª†p%–}&×嚥q.D&Q‰åá;Ø~
””Pâ
pÙu‰kºìĵ®Éˆ1wÇz
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Holy Diver Batman
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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.
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
Re: Holy Diver Batman
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.
Re: Holy Diver Batman
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.
EDIT: Grapeshot is right, as confirmed through
Code: Select all
wget --server-response http://pineight.com/nes/holydiverbatman-bin-0.01.7z
EDIT 2: After I appended the following to the site's .htaccess, Wget confirmed the correct Content-type.
Code: Select all
AddType application/x-7z-compressed .7z
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.
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
Code: Select all
.include "src/nes.h"
.include "src/ram.h"
Code: Select all
.include "nes.h"
.include "ram.h"
But now I'm running into something kinda funky...
Code: Select all
src/main.s(540): Error: Range error (-58 not in [0..255])
Code: Select all
.proc puthex
pha
lsr a
lsr a
lsr a
lsr a
jsr onedig
pla
and #$0F
onedig:
ora #'0'
cmp #'0'|$0A
bcc :+
adc #'A'-'9'-2-64 ;line 540
:
sta PPUDATA
rts
.endproc
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
Re: Holy Diver Batman
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.Code: Select all
.include "src/nes.h"
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:Code: Select all
src/main.s(540): Error: Range error (-58 not in [0..255])
Code: Select all
adc #'A'-'9'-2-64
Code: Select all
adc #<('A'-'9'-2-64)
'A' means the code unit for the character LATIN CAPITAL LETTER A in ASCII encoding, which is $41.I don't really understand the funky notation of the adc #'A'-'9'-2-64
'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.and there's just a lonely little semi-colon on the next line???
Do I need to make another release targeting the new version of ca65?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.tepples wrote:Do I need to make another release targeting the new version of ca65?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.
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...
Code: Select all
;WR $5555, 0xAA unlock cycle #1
lda #$AA
sta $5555
;WR $2AAA, 0x55 unlock cycle #2
lda #$55
sta $2AAA
;WR $5555, 0x90 software ID entry command
lda #$90
sta $5555
;RD $0000, Manf ID to get /OE low, read from $8000
ldx $8000 ;Manf ID = 0xBF for SST
ldy $8001 ;Device ID = 0xB5,B6,B7 for SST39SF010A, 020A, 040 respectively
;WR $xxxx, 0xF0 software ID exit command.
lda #$F0 ;exitID flash won't work as ROM again until this command is given.
sta $5000 ;write to flash anywhere ($0000-$7FFF)
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
Re: Holy Diver Batman
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.infiniteneslives wrote: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.
Re: Holy Diver Batman
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.infiniteneslives wrote: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.
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.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
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.As an aside, any idea what happens when you write to $2002 PPUSTATUS?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Holy Diver Batman
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.tepples wrote: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.infiniteneslives wrote: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.
That'd work for me!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.
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.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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers