Holy Mapperel (formerly Holy Diver Batman)

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Holy Mapperel (formerly Holy Diver Batman)

Post by tepples »

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.
lidnariq
Site Admin
Posts: 11636
Joined: Sun Apr 13, 2008 11:12 am

Re: Holy Diver Batman

Post by lidnariq »

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.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

Thanks again Tepples.
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.
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
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

the .7z download link gives text gibber...
7z¼¯'�§’äã#-������#�������¦lƍ�$ɇÊç#< ò§‘­y%"6f–$É„¦
º¸Ú¼®úŽÈòa-Ž^ºüZ˜¤ßª†p%–}&×嚥q.D&Q‰åá;؝~
””Pâ 
pÙu‰kºìĵ®Éˆ1wÇz
Am I/my browser doing something wrong?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Holy Diver Batman

Post by tepples »

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.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

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
Grapeshot
Posts: 85
Joined: Thu Apr 14, 2011 9:27 pm
Contact:

Re: Holy Diver Batman

Post by Grapeshot »

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.
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Holy Diver Batman

Post by tepples »

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

EDIT: Grapeshot is right, as confirmed through

Code: Select all

wget --server-response http://pineight.com/nes/holydiverbatman-bin-0.01.7z
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.

Code: Select all

AddType application/x-7z-compressed .7z
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

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

Code: Select all

.include "src/nes.h"
.include "src/ram.h"

Code: Select all

.include "nes.h"
.include "ram.h"
fixed those up easily as I run into them while compiling.

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

Code: Select all

src/main.s(540): Error: Range error (-58 not in [0..255])
line 540 of main.s and surrounding:

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
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
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Holy Diver Batman

Post by tepples »

Code: Select all

.include "src/nes.h"
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

src/main.s(540): Error: Range error (-58 not in [0..255])

Code: Select all

adc #'A'-'9'-2-64
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

adc #<('A'-'9'-2-64)
I don't really understand the funky notation of the adc #'A'-'9'-2-64
'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.
and there's just a lonely little semi-colon on the next line???
Not a semicolon, a colon. It's an unnamed label.

Do I need to make another release targeting the new version of ca65?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

tepples wrote: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
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

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

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)
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
lidnariq
Site Admin
Posts: 11636
Joined: Sun Apr 13, 2008 11:12 am

Re: Holy Diver Batman

Post by lidnariq »

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.
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.
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Holy Diver Batman

Post by tepples »

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.
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.
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
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.
As an aside, any idea what happens when you write to $2002 PPUSTATUS?
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.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Holy Diver Batman

Post by infiniteneslives »

tepples wrote:
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.
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.
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.
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.
That'd work for me!
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.
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
Post Reply