It is currently Tue Aug 21, 2018 1:07 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 85 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
PostPosted: Sun Mar 27, 2016 1:39 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
I'm tempted to buy a breadboard for this testing (and maybe for the future as well!). I'd need to desolder the U6 74'670 (or U7, too?) and put it in there, right?

Also, not to go offtopic too much but would that one be any good/work?

Link


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 2:10 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
I don't have a breadboard myself, but to me the link/photo looks about how those boards should look like. For the test circuit from previous post you could simply bridge all the 5V pins with a wire, that's almost easier as using a breadboard.

Didn't you already desolder the old 74670's and replaced them by new ones? When I said testing U6, I meant the chip that was originally installed as U6. Testing that chip would be best.

If you've thrown that chip away, or don't remember which chip has been the original U6, then... well, you could instead test any 74670 you want (and hope that it will behave the same as the original chip; the results would be interesting, but not 100% proof) (unless you tested if that chip works okay as U6 on a NOAC, then it should be 100% proof).


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 2:24 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Oh, bummer. I've thrown them away after desoldering but they should be in the trash and findable!
I will know from the pictures which one was U6, that's not the problem, at last. :D

Going to buy that breadboard anyway and hope I can deliver results once it arrives!

EDIT: Hopefully getting a new NOAC as well to test even more accurate!


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 4:40 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
I can dump the CHR now as well.

Kazzo Script:
Code:
board <- {
    mappernum = 246,
   cpu_rom = {
      size_base = 4 * mega, size_max = 4 * mega, banksize = 0x2000
   },
   ppu_rom = {
      size_base = 4 * mega, size_max = 4 * mega, banksize = 0x0800,
   },
   ppu_ramfind = true, vram_mirrorfind = false
};


function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6000, i);
      cpu_read(d, 0x8000, banksize);
   }
}

function ppu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6004, i);
      cpu_write(d, 0x8000, i);
      ppu_read(d, 0, banksize );
   }
}


And I noticed that one byte of CHR is also different.
BD7D8 is 07 instead of 27.

Other than, completely equal other than the reset and irq/vector at 800C-800F.


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 3:20 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Game works on the Famicom!

Appearently the SRAM was corrupted or something.

I replaced it with a new one and the game boots up fine in an original Famicom with all 4x 74
'670 + 8KB PRG RAM replaced.

Thanks for the all the help guys!


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 3:47 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
Ice Man wrote:
Game works on the Famicom! Appearently the SRAM was corrupted or something.

Okay, that's a surprise solution, almost a bit disappointing that it's been that simple, and strange that the old SRAM worked on NOAC, maybe it's somehow related to SRAM manufacturer/timing/voltages that worked better on NOAC. If the SRAM tends to boot up with different content on different consoles, then it should at least work on Famicom once when it was initialized on NOAC (provided that the battery was alive and did hold the data; did the battery still have 3V, and was the battery installed when swapping the cart between NOAC and Famicom?).
Well, probably we'll never be able to say for sure what had happened there. But we've learned a good bit about the other oddities of the cartridge's mapping logic.

Just another thing that I had noticed (when checking if the game is doing anything unusual on software side):
Code:
20:8AAB AD 72 68     mov  a,[6872]
20:8AAE D0 29        jnz  8AD9
20:8AB0 A9 01        mov  a,01
20:8AB2 8D D9 8A     mov  [8AD9],a      ;<-- rom write (try to "smash" code?)
20:8AB5 A5 1E        mov  a,[1E]
20:8AB7 C9 20        cmp  a,20
20:8AB9 D0 0C        jnz  8AC7          ;<-- true (jumps)
20:8ABB 8D 72 68     mov  [6872],a
20:8ABE A9 16        mov  a,16
20:8AC0 85 38        mov  [38],a
20:8AC2 A9 88        mov  a,88
20:8AC4 85 00        mov  [00],a
20:8AC6 60           ret
20:8AC7 A5 1E        mov  a,[1E]
20:8AC9 C9 C0        cmp  a,C0
20:8ACB D0 0C        jnz  8AD9          ;<-- true (jumps to "smashed" opcode)
20:8ACD 8D 72 68     mov  [6872],a
20:8AD0 A9 18        mov  a,18
20:8AD2 85 38        mov  [38],a
20:8AD4 A9 88        mov  a,88
20:8AD6 85 00        mov  [00],a
20:8AD8 60           ret
20:8AD9 20 21 B1     call B121          ;<-- game tries to smash this opcode
20:8ADC A9 00        mov  a,00
20:8ADE 8D 00 20     mov  [2000],a  ;ppu ctrl 1

The ROM write shouldn't cause problems on real hardware (it should be just ignored). Either the write is just a bug, or it's some copy-protection against emulators or copiers that have the ROM-image stored in write-able RAM instead of real ROM.

The different CHR byte is also odd, did you dump it 2-3 times to see if it's stable, and only that byte being different as expected in each dump? Probably hard to say what the byte is doing (could be changing a pixel color anywhere in the game), unless it's something eye-catching like changing the year/date in the title screen.


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 4:23 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Dumped the game around 5 times and it was always the same adress and byte. So I'm pretty sure it's correctly dumped and stable as well.

I'm guessing the first 2KB of SRAM might've been faulty or only initialized for NOAC? I don't know.
Either way, I'm happy the game works. Now I only need to find a proper coin cell holder for this board.

Also, the battery was changed as the old coin cell holder was broke and I couldn't fit in a battery without solder tabs. I didn't measure on the old one and threw it away.


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 10:47 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7402
Location: Seattle
nocash wrote:
Probably hard to say what the byte is doing (could be changing a pixel color anywhere in the game), unless it's something eye-catching like changing the year/date in the title screen.
It's very subtle:
Attachment:
FSB_CHR_difference.png
FSB_CHR_difference.png [ 441 Bytes | Viewed 1798 times ]


I think it looks like a correction...


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 12:04 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Looks like a correction to me, too. So I probably have a slightly newer version than the one dumped in the internet?


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 10:09 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 624
Ice Man wrote:
And I noticed that one byte of CHR is also different.
BD7D8 is 07 instead of 27.
The Jncota re-release of the game also has 07 there (using a different mapper), so regardless of whether yours is a newer version of the game (which I find doubtful) or whether the previous dumps were just bad in that one byte (which I consider more likely), 07 is the correct value.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 85 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC - 7 hours


Who is online

Users browsing this forum: Memblers 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