It is currently Sat Oct 21, 2017 5:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sat Nov 02, 2013 5:58 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Nov 02, 2013 6:36 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sun Nov 03, 2013 10:47 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 10:25 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
the .7z download link gives text gibber...
Quote:
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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 10:35 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 11:04 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 11:13 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 11:15 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
What browser are you using? Both Firefox for Linux and Chrome for Linux start a download.

EDIT: Grapeshot is right, as confirmed through
Code:
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:
AddType application/x-7z-compressed .7z


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 11:46 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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:
.include "src/nes.h"
.include "src/ram.h"


Code:
.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:
src/main.s(540): Error: Range error (-58 not in [0..255])

line 540 of main.s and surrounding:
Code:
.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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 12:04 pm 
Offline

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

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

Code:
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:
adc #<('A'-'9'-2-64)


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

Quote:
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?


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sat Dec 21, 2013 12:23 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sun Dec 22, 2013 1:36 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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:
   ;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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sun Dec 22, 2013 3:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Sun Dec 22, 2013 3:51 pm 
Offline

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

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

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


Top
 Profile  
 
 Post subject: Re: Holy Diver Batman
PostPosted: Mon Dec 23, 2013 11:02 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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.

Quote:
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!

Quote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group