It is currently Tue Jul 16, 2019 5:01 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Thu Jul 11, 2019 11:12 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
lidnariq wrote:
Does the Unagi output window say anything about "mirroring Program ROM fixed" or "mirroring Charcter ROM fixed" ?

Yes, yes it does

mirroring Program ROM fixed
mirroring Charcter ROM fixed
C:\Documents and Settings\_________\Desktop\Cheetahboys.nes, mapper 11
Program ROM: size 0x008000, crc32 0xd11bfeb8
Charcter ROM: size 0x002000, crc32 0xc29016c2
Cheetahboys is just what I named the rom to test it :P


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 1:03 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
I don't know anything about how these scripts work (would have to learn), but 40KBytes probably means 32KB PRG + 8KB CHR (so probably per NES header, 2x PRG banks and 1x CHR banks).

From this it looks like pagesize is being calculated wrong for both PRG and CHR. I suspect PRG count should be more like 4x16KB (i.e. 64KB total) and CHR count should be more like 4x (i.e. 32KB total).

Mapper 11 apparently uses 32KB PRG banks for swapping, so I suspect pagesize for PRG is 1, and also 1 for CHR, hence erroneous 40KB result.

Otherwise there is something different about this PCB wiring vs. classic Color Dreams boards, which is certainly possible too.


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 1:21 am 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
How do we go about this then? Are we going to have to write a totally new script for this cartridge, do I have to do more with the multimeter?


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 7:53 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21501
Location: NE Indiana, USA (NTSC)
Try starting with the GNROM script and swapping the cpu_write() lines at line 21 (in cpu_dump()) and line 28 (in ppu_dump()).

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 3:13 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
It's not surprisingly, the same result as before.


Attachments:
Cheetah_001.png
Cheetah_001.png [ 705 Bytes | Viewed 117 times ]
Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 3:39 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8476
Location: Seattle
Just for curiosity's sake, what happens if you try using the "anrom.ad", "anrom_.ad", or "aorom.ad" scripts bundled with the kazzo source? Is the result 32KB, or does it become 64KB?

*edit* oh, and another thought: PM me the broken dump you have? Maybe the PRG ROM's output drivers are so strong that they meaningfully compete with the Atmega IC on the Kazzo, and we have to use different addresses to avoid a bus conflict?


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 4:30 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
lidnariq wrote:
*edit* oh, and another thought: PM me the broken dump you have? Maybe the PRG ROM's output drivers are so strong that they meaningfully compete with the Atmega IC on the Kazzo, and we have to use different addresses to avoid a bus conflict?

Ref:
Quote:
Some variations of this board/mapper (e.g the one used in the prototype game "Free Fall") appear to be free of bus conflicts and will not work properly if bus conflicts are emulated.


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 5:11 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
lidnariq wrote:
Just for curiosity's sake, what happens if you try using the "anrom.ad", "anrom_.ad", or "aorom.ad" scripts bundled with the kazzo source? Is the result 32KB, or does it become 64KB?


AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]

CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [22]

LOCALS
[ppuarea_memory] NULL
[vram] 0
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 7
[script] "anrom.ad"
[d] USERPOINTER
[this] TABLE


AN ERROR HAS OCCURED [script logical error]

CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [47]

LOCALS
[ppu_dumpsize] 0
[cpu_dumpsize] 131072
[ppuarea_memory] 1
[vram] 1
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 7
[script] "anrom_.ad"
[d] USERPOINTER
[this] TABLE


AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]

CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [22]

LOCALS
[ppuarea_memory] NULL
[vram] 0
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 7
[script] "aorom.ad"
[d] USERPOINTER
[this] TABLE


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 5:30 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8476
Location: Seattle
Try this:

Code:
board <- {
  mappernum = 11,
  cpu_rom = {
    size_base = 0x10000, size_max = 1 * mega, banksize = 0x8000
  },
  ppu_rom = {
    size_base = 0x8000, size_max = 1 * mega, banksize = 0x2000
  },
  ppu_ramfind = false, vram_mirrorfind = true
};

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

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


There is a bus conflict prevention table, but it's not monotonic:
Attachment:
cheetah-histogram.png
cheetah-histogram.png [ 475 Bytes | Viewed 95 times ]
so I just elected to use other coincidental sequences instead.


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 5:34 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
The filename of the image sums it up perfectly.


Attachments:
Ah shit... here we go again_001.png
Ah shit... here we go again_001.png [ 705 Bytes | Viewed 93 times ]
Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 6:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8476
Location: Seattle
At this point, I have no idea why it's not working. The hardware is probably Color Dreams, but your continuity tests were inconclusive. There's no obvious way that the hardware could know if it were in a dumper instead of a console (the CIC isn't connected to anything else, M2 is unused), your dump of CHR looks plausible, and your dump of PRG gets as far as drawing a title screen.

The last time someone tried to dump a Color Dreams game they had very similar problems.

For whatever reason, the latch is clearly not getting the value that the Kazzo is writing. I don't know why.

Do you have any random electrical components? LEDs, resistors, wires, alligator clips, headphones?


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 6:08 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
lidnariq wrote:
At this point, I have no idea why it's not working. The hardware is probably Color Dreams, but your continuity tests were inconclusive. There's no obvious way that the hardware could know if it were in a dumper instead of a console (the CIC isn't connected to anything else, M2 is unused), your dump of CHR looks plausible, and your dump of PRG gets as far as drawing a title screen.

The last time someone tried to dump a Color Dreams game they had very similar problems.

For whatever reason, the latch is clearly not getting the value that the Kazzo is writing. I don't know why.

Do you have any random electrical components? LEDs, resistors, wires, alligator clips, headphones?


What do you mean by this?

I need to clarify that the game despite the graphics being corrupted, the game itself runs fine.

I tested this game several times in my NES hardware, the graphics are fine.


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 6:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8476
Location: Seattle
ShadowMan44 wrote:
What do you mean by this?
I said too many different things for me to be able to usefully answer that question. You'll have to point at each specific thing you'd like me to re-explain.

ShadowMan44 wrote:
I need to clarify that the game despite the graphics being corrupted, the game itself runs fine.
Some games can run for a surprisingly long amount of time with only part of the PRG ROM. We can see that that's a 64KB ROM for PRG there, but you only have 32KB of it. At some point, part-way through the game, it's extremely likely it'll crash.


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 6:27 pm 
Offline

Joined: Wed Jul 10, 2019 8:17 pm
Posts: 30
lidnariq wrote:
ShadowMan44 wrote:
What do you mean by this?
I said too many different things for me to be able to usefully answer that question. You'll have to point at each specific thing you'd like me to re-explain.

"Do you have any random electrical components? LEDs, resistors, wires, alligator clips, headphones?"
What do I need these for?


Top
 Profile  
 
PostPosted: Fri Jul 12, 2019 6:34 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21501
Location: NE Indiana, USA (NTSC)
I believe the random electrical parts are meant for building a makeshift continuity testing rig. Quoting previous posts:
lidnariq wrote:
If ShadowMan44 is willing to use a multimeter (or a cheapo homebrew continuity meter) to determine which pins from the 74LS377 go to what pins on the ROMs

koitsu wrote:
The instructions are pretty simple: you use your multimetre's continuity test to figure out what the cartridge edge connectors (pins) connect to on the front and back of the PCB
[...]
The ones that are particularly important to us are the traces that go underneath an IC (like PRG or CHR) -- we can't tell where they go visually, and you probably can't either, but your MM continuity test can.

_________________
Pin Eight | Twitter | GitHub | Patreon


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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