It is currently Sat Nov 18, 2017 3:32 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 559 posts ]  Go to page Previous  1 ... 24, 25, 26, 27, 28, 29, 30 ... 38  Next
Author Message
PostPosted: Fri Apr 01, 2016 2:30 pm 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
Werrock wrote:
OMG! Your code worked!

mirroring Charcter ROM fixed
pm.nes, mapper 36
Program ROM: size 0x010000, crc32 0x65fe1590
Charcter ROM: size 0x010000, crc32 0xf73ee39e

Game plays also :D

Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.


I compared the first level first screen between the game on NES an emulator and they use different tile placement, its not of just another page of memory or something. So not perfect yet, the enemy placement, sprite and movement is correct. But background graphics and obstacles are placed differently.


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 2:31 pm 
Offline

Joined: Sun Aug 31, 2014 9:55 am
Posts: 37
Hmm. I wonder what could be the problem then. It plays from the cartridge, just doesn't dump properly. It is a proto, however.


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 2:42 pm 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
lidnariq wrote:
Werrock wrote:
Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.
Huh. Could be a misunderstanding of how the registers at $4100-$4103 are supposed to work. Which emulator are you testing with? IIRC things that are not FCEUX are more incorrect for this specific mapper.

Also, maybe check what lines you can remove from the sequence I gave you to see what's necessary?


I can remove
Code:
cpu_write(d, 0x4101, 0);
cpu_write(d, 0x4103, 0);
cpu_write(d, 0x4103, 0xFF);

With same result.

I need either of
Code:
cpu_write(d, 0xFFA0+i, (i<<4));
or
Code:
cpu_write(d, 0x4102, (i<<4));


Code:
cpu_write(d, 0x4100, 0);
is needed and if i remove
Code:
cpu_write(d, 0xFFFF, 0xFF);
I can still readout a full image butthe CRC is different:
pm2.nes, mapper 36
Program ROM: size 0x010000, crc32 0x575d3d5a
Charcter ROM: size 0x010000, crc32 0xf73ee39e

It will also not load at all in the emulator (FCEUX 2.2.2).


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 2:43 pm 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
prototector wrote:
Hmm. I wonder what could be the problem then. It plays from the cartridge, just doesn't dump properly. It is a proto, however.

Post a screenshot of you anago gui and let me see how you set all.


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 3:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6437
Location: UK (temporarily)
Werrock wrote:
I compared the first level first screen between the game on NES an emulator and they use different tile placement, its not of just another page of memory or something. So not perfect yet, the enemy placement, sprite and movement is correct. But background graphics and obstacles are placed differently.
Seems to work correctly if I fix the nametable mirroring. (It should be Vertical, not Horizontal).

I thought that the Kazoo detected that, but who knows.

Quote:
I can still readout a full image butthe CRC is different:
... PM me the broken image?


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 3:18 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6437
Location: UK (temporarily)
Werrock wrote:
if i remove
Code:
cpu_write(d, 0xFFFF, 0xFF);
I can still readout a full image butthe CRC is different:
pm2.nes, mapper 36
Program ROM: size 0x010000, crc32 0x575d3d5a
Charcter ROM: size 0x010000, crc32 0xf73ee39e
In summary, omitting the write to 0xFFFF flips the two PRG banks around. No idea what it'd do if there were more PRG banks, as on Strike Wolf.

Ok, now for more silly questions:
Does it matter what value is in cpu_write(d, 0x4100, 0);? Currently the game writes 0; what happens if it's 0x10, 0x20, or 0x30?
Does it matter what value is written to 0xFFFF? Do the address lines matter at all, other than ≥ 0x8000?
Does it matter what the address lines are in cpu_write(d, 0xFFA0+i, (i<<4));? e.g. what if it were 0x8000 instead of 0xFFA0+i ?


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 3:25 pm 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
Its not a game I am collecting so unfortunately I cannot test it. But great work man getting the policeman working. I have not been able to find this rom anywhere online so its really nice to have it dumped. :beer:


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 3:27 pm 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
I'll get back to you tomorrow. I got to pack it in for tonight. Thanks again.


Top
 Profile  
 
PostPosted: Fri Apr 01, 2016 3:54 pm 
Offline

Joined: Sun Aug 31, 2014 9:55 am
Posts: 37
Same here, will continue with this tomorrow, not in reach of stuff.


Top
 Profile  
 
PostPosted: Sun Apr 03, 2016 1:11 am 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
lidnariq wrote:
Does it matter what value is in cpu_write(d, 0x4100, 0);? Currently the game writes 0; what happens if it's 0x10, 0x20, or 0x30?

Seems not to matter, 0x10, 0x20, 0x30, 0xFF all works.
lidnariq wrote:
Does it matter what value is written to 0xFFFF? Do the address lines matter at all, other than ≥ 0x8000?

Value seems not to matter, 0x0 is ok and so is 0x5a. All addresses >= 0x8000 seems to work. 0x7FFF or lower gives the same result as removing the line.
lidnariq wrote:
Does it matter what the address lines are in cpu_write(d, 0xFFA0+i, (i<<4));? e.g. what if it were 0x8000 instead of 0xFFA0+i ?
Also works, 0x8000 and 0x8000+i works just as good.


Top
 Profile  
 
PostPosted: Sun Apr 03, 2016 9:46 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6437
Location: UK (temporarily)
And just a few more silly questions:

Does anything happen if you have multiple cpu_write(d, 0x4100, whatever); in a row?
Does anything happen if you have multiple cpu_write(d, 0xFFFF, 0xFF); in a row?
Could you measure the voltage on 05-00002-010 pin 3 = PRG pin 1 while you're dumping the game? It should either be high then low, or low then high.

It'd be nice if there were a way to get the Kazoo to read from the ports at 0x4100-0x4103 ... oh, maybe there's a way to repurpose Kazoo's save RAM reading:
Code:
board <- {
[...]
   cpu_ram = {
      size_base = 2500, size_max = 2500, banksize = 2500
   },
[...]

function cpu_raw_access(d, pagesize, banksize) {
  for (local w4100 = 0; w4100 < 5; w4100++) {
    for (local w4101 = 0; w4101 < 5; w4101++) {
      for (local w4102 = 0; w4102 < 5; w4102++) {
        for (local w4103 = 0; w4103 < 5; w4103++) {
          if (w4100 > 0) {
            cpu_write(d, 0x4100, (w4100-1)<<4);
          }
          if (w4101 > 0) {
            cpu_write(d, 0x4101, (w4101-1)<<4);
          }
          if (w4102 > 0) {
            cpu_write(d, 0x4102, (w4102-1)<<4);
          }
          if (w4103 > 0) {
            cpu_write(d, 0x4103, (w4103-1)<<4);
          }
          cpu_read(d, 0x4100, 4);
        }
      }
    }
  }
}
But I don't know if unagi will throw a fit for having 2500 bytes here, rather than a nice power of 2?

Thanks for having the patience and/or curiosity to actually figure out what's going on, even though you already have a functioning dump!


Top
 Profile  
 
PostPosted: Sun Apr 03, 2016 11:16 am 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
lidnariq wrote:
Does anything happen if you have multiple cpu_write(d, 0x4100, whatever); in a row?

Nope, works just as good, tried up to five writes.
lidnariq wrote:
Does anything happen if you have multiple cpu_write(d, 0xFFFF, 0xFF); in a row?

Also make no difference.
lidnariq wrote:
Could you measure the voltage on 05-00002-010 pin 3 = PRG pin 1 while you're dumping the game? It should either be high then low, or low then high.

Start at 5V after reset of Kazzo, starts dumping and it switches to 0V, half way through the PRG it goes back to 5V. If I remove the cpu_write(d, 0xFFFF, 0xFF); line it will have the reverse behavior starting at 5V when you start duping and go to 0V after half the PRG.
lidnariq wrote:
Thanks for having the patience and/or curiosity to actually figure out what's going on, even though you already have a functioning dump!

No problem!


Top
 Profile  
 
PostPosted: Wed Apr 06, 2016 7:49 am 
Offline

Joined: Sun Aug 31, 2014 9:55 am
Posts: 37
Sorry for the delay, had some real serious things to handle.

http://i.imgur.com/FQhctg9.png

Not too clear, but most settings are default exactly the way they are when the program is first downloaded. The only thing gets adjusted is of course the script. the colordreams script is available in the drop-down list.


Top
 Profile  
 
PostPosted: Wed Apr 06, 2016 9:07 am 
Offline

Joined: Mon Mar 28, 2016 9:40 am
Posts: 44
Location: Sweden
Very unclear, I do not know how you made such an unreadable screen shot. Anyway, looks like you set the CHR ROm to x1, the memory is larger than that on moon ranger so try to set it to x4.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 7:16 am 
Offline

Joined: Sun Aug 31, 2014 9:55 am
Posts: 37
Thanks a lot, it worked!
Really glad there's progress on supporting mappers with this device.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 559 posts ]  Go to page Previous  1 ... 24, 25, 26, 27, 28, 29, 30 ... 38  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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