MMC5 Hacking Adventures

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

What is going on with that table `Bank register effective CPU address ranges versus PRG mode` because I don't get it (I mean the $5110/$5111/$5112 rows + the "covered" comment).

Have you tested that value written to $5110/$5111/$5112 is present on PRG-ROM-A bus for some CPU-A address?

Because I think this table is not true. If we want to make such detailed descriptions (like what address is outputted by MMC5 when accessing certain memory regions), then I think the table should look like that (for PRG_RAM_A - all rows are tested, for PRG_ROM_A it is not tested but the rows below $8000 are in my opinion just mirrors)

Code: Select all

             $0000     $2000     $4000     $6000     $8000     $a000     $c000     $e000
-- Mode 0 ---------------------------------------------------------------------------------
PRG_RAM_A |  $5113  |  $5113  |  $5113  |  $5113  |  $5113  |  $5113  |  $5113  |  $5113  |
PRG_ROM_A |               <<$5117>>               |               <<$5117>>               |
PRG       |    -    |    -    |    -    |   RAM   |                  ROM                  |
-- Mode 1 ---------------------------------------------------------------------------------
PRG_RAM_A        <$5115>      |  $5113  |  $5113  |      <$5115>      |  $5113  |  $5113  |
PRG_ROM_A |      <$5115>      |      <$5117>      |      <$5115>      |      <$5117>      |
PRG       |    -    |    -    |    -    |   RAM   |      $5115.7      |        ROM        |
-- Mode 2 ---------------------------------------------------------------------------------
PRG_RAM_A |      <$5115>      |  $5116  |  $5113  |      <$5115>      |  $5116  |  $5113  |
PRG_ROM_A        <$5115>      |  $5116  |  $5117  |      <$5115>      |  $5116  |  $5117  |
PRG       |    -    |    -    |    -    |   RAM   |      $5115.7      | $5116.7 |   ROM   |
-- Mode 3 ---------------------------------------------------------------------------------
PRG_RAM_A |  $5114  |  $5115  |  $5116  |  $5113  |  $5114  |  $5115  |  $5116  |  $5113  |
PRG_ROM_A |  $5114  |  $5115  |  $5116  |  $5117  |  $5114  |  $5115  |  $5116  |  $5117  |
PRG       |    -    |    -    |    -    |   RAM   | $5114.7 | $5115.7 | $5116.7 |   ROM   |

 < >  = ignore bottom bit (replace it with CPU_A13)
<< >> = ignore two bottom bits (replace bit 1 with CPU_A14 and bit 0 with CPU_A13)
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

krzysiobal wrote:What is going on with that table `Bank register effective CPU address ranges versus PRG mode` because I don't get it (I mean the $5110/$5111/$5112 rows + the "covered" comment).

Have you tested that value written to $5110/$5111/$5112 is present on PRG-ROM-A bus for some CPU-A address?
I definitely have not tested my table yet, and it is very possible that it is incorrect. To indicate this, I left the following message:
PRG Bank 0, 1, 2 ($5110-5112)
These registers have no known effect because they presumably point to areas outside of PRG program space.
When I am finally able to work on my setup and get PRG mode writes working correctly, I will test thoroughly and with your help, interpret the results.

I think that the main difference in my table versus your table is that I ignore any ranges where /CS would not be enabled. I think your table is considering strictly the PRG A13+ and PRG-RAM A13+ even in cases where /CS is disabled.

I consider mode 3 to be the "natural" state. We have known this information for a fact previously:

Mode 3 CPU Address Ranges affected:
$5110 n/a
$5111 n/a
$5112 n/a
$5113 -> $6000-7FFF
$5114 -> $8000-9FFF
$5115 -> $A000-BFFF
$5116 -> $C000-DFFF
$5117 -> $E000-FFFF

The pattern I observed is that each PRG bank register in mode 3 covers a complimentary range of $2000 bytes of CPU address space. My extrapolation was this, which seemed pretty reasonable to me:

Mode 3 CPU Address Ranges affected:
$5110 -> $0000-1FFF, though all /CS's would be disabled in this range
$5111 -> $2000-3FFF, though all /CS's would be disabled in this range
$5112 -> $4000-5FFF, though all /CS's would be disabled in this range
$5113 -> $6000-7FFF
$5114 -> $8000-9FFF
$5115 -> $A000-BFFF
$5116 -> $C000-DFFF
$5117 -> $E000-FFFF

Moving on to Mode 2 here is what we already knew:
$5110 n/a
$5111 n/a
$5112 n/a
$5113 -> $6000-7FFF (?)
$5114 -> $8000-BFFF
$5115 -> n/a
$5116 -> $C000-DFFF
$5117 -> $E000-FFFF

Looking at Mode 2 alongside Mode 3:
reg -> mode 3 -> mode 2
$5110 -> $0000-1FFF -> ?
$5111 -> $2000-3FFF -> ?
$5112 -> $4000-5FFF -> ?
$5113 -> $6000-7FFF -> $6000-7FFF (?)
$5114 -> $8000-9FFF -> $8000-BFFF
$5115 -> $A000-BFFF -> n/a
$5116 -> $C000-DFFF -> $C000-DFFF
$5117 -> $E000-FFFF -> $E000-FFFF

We can see that in mode 2, $5115 has no effect due to its "natural mode 3 range" being covered by $5114. that is what I meant by "covered by".

I made the same type of extrapolations going to mode 1 and mode 0.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: MMC5 Hacking Adventures

Post by NewRisingSun »

The MMC5 wiki page states that it is not yet known how the MMC5 detects the sprite size (8x8 vs. 8x16) to determine whether to use the $5128-$512B registers. Any news on that front?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

There is absolutely no reason to think that there's a physical register mapped at $5110 through $5112. As we stated earlier, because there are two separate address buses for RAM and ROM, the outputs for both bankswitching address buses should completely ignore A15.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I guess I didn't mean to specifically imply that those registers "exist", I have placed them there more to show the offset to register $5113 and why it would have skipped them. Definitely we have seen no known effect from those registers and I have not tested and found any indication of their existence myself.

I think again I have jumped the gun changing the Wiki. I have a very different way of thinking on some of these things that in some cases (this one likely included) is not always right. My mistake is updating the wiki before having enough discussion. Sorry about that. It is just too tempting sometimes. But we will get it sorted and soon the wiki will be accurate again as we continue to investigate and update. That is kind of the benefit and drawback of Wiki is that it is never really a "final" version... In a way, we are brainstorming here, and we must remember that bad ideas can turn into good ideas if we give it a chance and think about it.

It seems that krzysiobal's table works in the reverse perspective of mine. Here is my interpretation of a table built in that way:

Code: Select all

             $0000     $2000     $4000     $6000     $8000     $a000     $c000     $e000
-- Mode 3 ---------------------------------------------------------------------------------
PRG_RAM_A |   n/a   |   n/a   |   n/a   |  $5113  |  $5114  |  $5115  |  $5116  |   n/a   |
PRG_ROM_A |   n/a   |   n/a   |   n/a   |   n/a   |  $5114  |  $5115  |  $5116  |  $5117  |
PRG       |    -    |    -    |    -    |   RAM   | $5114.7 | $5115.7 | $5116.7 |   ROM   |
-- Mode 2 ---------------------------------------------------------------------------------
PRG_RAM_A |   n/a   |   n/a   |   n/a   |  $5113  |           <$5115> |  $5116  |   n/a   |
PRG_ROM_A |   n/a   |   n/a   |   n/a   |   n/a   |           <$5115> |  $5116  |  $5117  |
PRG       |    -    |    -    |    -    |   RAM   |           $5115.7 | $5116.7 |   ROM   |
-- Mode 1 ---------------------------------------------------------------------------------
PRG_RAM_A |   n/a   |   n/a   |   n/a   |  $5113  |           <$5115> |             n/a   |
PRG_ROM_A |   n/a   |   n/a   |   n/a   |   n/a   |           <$5115> |           <$5117> |
PRG       |    -    |    -    |    -    |   RAM   |           $5115.7 |             ROM   |
-- Mode 0 ---------------------------------------------------------------------------------
PRG_RAM_A |   n/a   |   n/a   |   n/a   |  $5113  |                                 n/a   |
PRG_ROM_A |   n/a   |   n/a   |   n/a   |   n/a   |                             <<$5117>> |
PRG       |    -    |    -    |    -    |   RAM   |                                 ROM   |

 < >  = ignore bottom bit (replace it with CPU_A13)
<< >> = ignore two bottom bits (replace bit 1 with CPU_A14 and bit 0 with CPU_A13)
NewRisingSun wrote:The MMC5 wiki page states that it is not yet known how the MMC5 detects the sprite size (8x8 vs. 8x16) to determine whether to use the $5128-$512B registers. Any news on that front?
I don't think we have looked at that yet NewRisingSun but it may be a future topic to investigate as we get through some of this PRG stuff.
lidnariq wrote:the outputs for both bankswitching address buses should completely ignore A15.
If this is true, why not combine registers $5113 and $5117 and use the RAM/ROM bit?

Edit:
Answer: Because both ram and rom are enabled at the same time with independent PRG banks because of that.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

I'd say what's going on looks something like this:

Code: Select all

             $0000     $2000     $4000     $6000
          or $8000     $a000     $c000     $e000
-- Mode 3 -----------------------------------------
PRG_RAM_A |  $5114  |  $5115  |  $5116  |  $5113  |
PRG_ROM_A |  $5114  |  $5115  |  $5116  |  $5117  |
-- Mode 2 -----------------------------------------
PRG_RAM_A |           <$5115> |  $5116  |  $5113  |
PRG_ROM_A |           <$5115> |  $5116  |  $5117  |
-- Mode 1 -----------------------------------------
PRG_RAM_A |           <$5115> |   ???   |  $5113  |
PRG_ROM_A |           <$5115> |           <$5117> |
-- Mode 0 -----------------------------------------
PRG_RAM_A |   ???   |   ???   |   ???   |  $5113  |
PRG_ROM_A |                             <<$5117>> |
The ???s are both unknown and due to how the chip enables work, can't be made relevant without a custom PCB. But I'd hunch that in the $8000-$DFFF range, PRG_RAM_A and PRG_ROM_A are the same value.
If this is true, why not combine registers $5113 and $5117 and use the RAM/ROM bit?

Answer: Because both ram and rom are enabled at the same time with independent pages because of that.
Bingo.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I completely agree with your table, it makes perfect sense and definitely covers all scenarios where the ROM or RAM can be enabled.

Though it won't make a functional difference, I can't feel satisfied that they wouldn't have done it like this, and this is what has been making me feel itchy about this:

Code: Select all

             $0000     $2000     $4000     $6000
          or $8000     $a000     $c000     $e000
-- Mode 3 -----------------------------------------
PRG_RAM_A |  $5110  |  $5111  |  $5112  |  $5117  |
PRG_ROM_A |  $5110  |  $5111  |  $5112  |  $5113  |
-- Mode 2 -----------------------------------------
PRG_RAM_A |           <$5111> |  $5112  |  $5117  |
PRG_ROM_A |           <$5111> |  $5112  |  $5113  |
-- Mode 1 -----------------------------------------
PRG_RAM_A |           <$5111> |   ???   |  $5117  |
PRG_ROM_A |           <$5111> |           <$5113> |
-- Mode 0 -----------------------------------------
PRG_RAM_A |   ???   |   ???   |   ???   |  $5117  |
PRG_ROM_A |                             <<$5113>> |
Edit:
It may be a trivial exercise but when I am able to set PRG mode, I think I will test and confirm 4 separate charts:
  • PRG Mode vs. CPU address - which register it gets PRG A13-19 from
  • PRG Mode vs. CPU address - which register it gets PRG /CS from
  • PRG Mode vs. CPU address - which register it gets PRG-RAM A13-16 from
  • PRG Mode vs. CPU address - which register it gets PRG-RAM /CS from
I am not expecting any surprises from this test, but at that point, we have our knowns very firmly nailed down and can reattempt merging this information into 1 table in the reverse direction:
  • PRG Bank Register vs. PRG Mode - which CPU address range does the bank register apply to
My personal goal here, with this thread in general, is to make MMC5 more accessible to software developers, possibly at the expense of making it slightly less clear to an emulator or hardware developer. Hardware and emulators will continue to get really good, but development will diminish as that gets closer to perfection. The more sustainable thing is focus support on future software, as hopeless as that may seem at the moment.

I think that a table in the reverse direction makes the most sense to a software developer -- it shows the 2 registers that they can change (mode and bank) as X and Y axis, and then plots what happens. That is why I have gone for my more obscure style of table. Unfortunately I have filled in some blanks that are potentially confusing or misleading in an attempt to capture what Nintendo was thinking when they skipped $5110-5112.

Edit 2:
I made some changes in the wiki based on our discussions here, let me know what you think. I have put both tables now for both perspectives.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

Banks for PRG-RAM that I wrote in the table are tested by looking under logic analyzer what MMC5 outputs at PRG_RAM_A[13..16] lines after switching to difrent modes, so no idea why you don't believe them ;)
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

Are you talking about the ones left as question marks? Please fill in any things that I missed, or let me know and I will do the dirty work on the wikitables (they are a bit messy behind the scenes, using rowspans and colspans). I do not disbelieve any of your findings, krzysiobal, sorry to give that impression. My understanding is on shaky ground, I can usually understand better when I run through everything to do the test myself. It never hurts to have a second independent test to verify either.

My backwards table has items filled in considering both PRG ROM/RAM address bits and /CS's. The table that you and lidnariq made has items filled in considering only the address bits, regardless of /CS's, then with footnotes explaining the /CS's. The RAM question marks in your table is where I wasn't sure what the address bus was even if /CS was disabled there. It has to be something in each of the question marks, but I wasn't sure what. To lidnariq's point, it wouldn't matter normally, it is only visible if you were to wire out a board to read it. Still interesting and worth putting into that table though I think, if for nothing other than curiosity.

My order of 5 pcs 128kbyte UPD431000ACZ from AliExpress is has not been marked as shipped yet... Not a good sign but we will see. I extended the seller's processing time by 1 month. The order total was $3.63 for 5 pcs shipped, that was probably too good to be true but you never know.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

krzysiobal wrote:Banks for PRG-RAM that I wrote in the table are tested by looking under logic analyzer what MMC5 outputs at PRG_RAM_A[13..16] lines after switching to difrent modes, so no idea why you don't believe them ;)
Sorry, sometimes I'm bad at reading :(
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

Ok, I did further researchs around how MMC5 detects 8x8/8x16 sprites and on which scanline cycles it uses $5120-$5127 and on which $5128-$512B. In order for this, I made a special test case for KrzysioKazzo that simulates CPU/PPU cycles (after each PPU cycle there is CPU cycle so MMC5 never thinks that reset state occured)

I set it into CHR 8x1k mode, write $FF to $5120-$5127 (sprites) and $00 to $5128-$512b (tiles) and observe CHR-A10 so that it is easy to distinguish, when it uses sprite/tiles banks.

1. MMC5 switches to 8x16 mode when
* $2000.5 is written with 1
AND
* at least one of those bits ($2000.3 or $2000.4) is written with 1
MMC5 sniffs writes to $2000/$2001 (it only checks for those two addresses, no mirrors are taken into account).

2. I will count the PPU reads in every scanline as #1, #2, #3, .. #170 (so that cycle 0->idle, cycles 1-2 -> #1, cycles 3-4 -> #2, .., 339-340 -> #170)

3. During the pre-render scanline it never uses sprites banks (logical, cause it needs three consecutive reads from $2000-$2fff to detect scanline)

4. During the scanline 0, it uses sprite banks for reads: #2, #3, #4 and #130-#161
For further scanlines - only #130-#161
Image
Image
Take look that CHR-A10 is changing on both edges of PPU_!RD which might reveal how the MMC5 ppu cycle counter is implemented (if I'd do that in VHDL, everything would change on the falling edge)

5. The counter is not only counting passing edge of PPU_!RD but it also looks at the addresses. So if PPU will be fetching from $0000, $0001, $0002, $0003, etc - it will not work. There must be some more logic underneath that.

6. The counter won't count passing scanlines - if the frame has even 400 scanlines, the above logic will work for all of them.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

krzysiobal wrote:* at least one of those bits ($2000.3 or $2000.4) is written with 1
Typo? $2001?



What happens if a scanline has more than 170 reads?
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

Way back on page 5, I found a clue that there is at least 1 undiscovered writable register in range $512C-512F that behaves in some way similar to $512B. Not sure what I was doing now, but here it was: https://forums.nesdev.com/viewtopic.php ... 86#p227686
Ben Boldt wrote:Changing my random address range to be $5120 to $512B, it locked up almost immediately. Reducing the range to $5120 to $512A allowed the PPU bank to keep dancing all over indefinitely. So, writing to $512B can cause the lockup of the PPU bank. Maybe it is waiting for additional PPU reads, etc - I am not familiar with this.

Then, specifically excluding $512B from address range $5000 to $52FF, it still was able to lock up. I then excluded the range $512B to $512F, and now it does not lock up. Therefore, there is at least 1 more register in that range that behaves similar to $512B.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

Typo? $2001?
Sorry, of course you are right - $2001.
What happens if a scanline has more than 170 reads?
Sprite banks are never asserted again in that scanline, so the counter does not wrap.
Way back on page 5, I found a clue that there is at least 1 undiscovered writable register in range $512C-512F that behaves in some way similar to $512B. Not sure what I was doing now, but here it was: viewtopic.php?p=227686#p227686
When MMC5 is in `in-FRAME` mode, it uses:
->when in 8x8: $5120-$5127 for both sprites/backgrounds
->when in 8x16 $5120-$5127 for sprites & $5128-$512b for backgrounds (how is that detected - written above)

When MMC5 is in `outside-FRAME` mode, it uses:
->when in 8x8: $5120-$5127
->when in 8x16 $5120-$5127 or $5128-$512b (which one - depends on which to which one you last wrote).
If you write $2000.5=0 then automatically $5120-$5127 are activated and writing to $5128-$512b no longer makes effect.

On Power-UP, MMC5 uses 8x16 mode.
So if you mistakenly wrote to any of $5128-$512b, then MMC5 ignores the contents of $5120-$5127.
Buf If you write to any of $5120-$5127, it will again use those regs.
And I wrote to any of $512c-$512f and nothing was locked and even MMC5 still used $5120-$5127 which confirms there are NO regs in $512c-$512f range.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

krzysiobal wrote:And I wrote to any of $512c-$512f and nothing was locked and even MMC5 still used $5120-$5127 which confirms there are NO regs in $512c-$512f range.
My test was very uncontrolled, but I can say a few things that did and did not happen. I will try to rerun that test Monday evening and gather more details this time.

- PPU Address bits were not changing, I believe they were all 1s.
- PPU /RD never changed
- M2 toggled super slow, always would have been triggering reset
- When I set the test to write random data to $5120-512A, CHR-ROM Address bits would dance around endlessly.
- If I included $512B in this range, the address bits would no longer dance around (I called this "locked up").
- If I wrote random data to $5120-512F, excluding $512B, it would also lock up, therefore my conclusion that whatever locked it up with 512B, something else in $512C-512F had that lock up effect as well.

We can't dismiss my observation just yet krzysiobal! You had not gotten anything to lock up yet so I have more work to do to demonstrate how to lock it up. I don't know what it means so let's investigate! :)
Post Reply