Page 1 of 3
Holy Mapperel (formerly Holy Diver Batman)
Posted: Sat Nov 02, 2013 5:58 pm
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.
Re: Holy Diver Batman
Posted: Sat Nov 02, 2013 6:36 pm
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.
Re: Holy Diver Batman
Posted: Sun Nov 03, 2013 10:47 am
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.
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 10:25 am
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?
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 10:35 am
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.
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 11:04 am
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.
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 11:13 am
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.
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 11:15 am
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
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 11:46 am
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"
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.
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 12:04 pm
by tepples
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])
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:
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?
Re: Holy Diver Batman
Posted: Sat Dec 21, 2013 12:23 pm
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.
Re: Holy Diver Batman
Posted: Sun Dec 22, 2013 1:36 pm
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.
Re: Holy Diver Batman
Posted: Sun Dec 22, 2013 3:35 pm
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.
Re: Holy Diver Batman
Posted: Sun Dec 22, 2013 3:51 pm
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.
Re: Holy Diver Batman
Posted: Mon Dec 23, 2013 11:02 pm
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.