MMC5 Hacking Adventures
Moderator: Moderators
Re: MMC5 Hacking Adventures
Update:
None of the readable registers changed value reported when reading from all PPU address. I elected to skip reading the multiplier registers for this test.
All remained with these values:
$5010: $01 PCM Mode/IRQ (bit 0 = 1: read mode, bit 7 = 0: PCM IRQ not enabled)
$5015: $00 APU Status
$5204: $40 IRQ Status ($40 means it thinks I'm "in frame" for this test, and no IRQ pending.)
$5208: $C0 ? (unknown)
$5209: $00 ? IRQ-related per krzysiobal
None of the readable registers changed value reported when reading from all PPU address. I elected to skip reading the multiplier registers for this test.
All remained with these values:
$5010: $01 PCM Mode/IRQ (bit 0 = 1: read mode, bit 7 = 0: PCM IRQ not enabled)
$5015: $00 APU Status
$5204: $40 IRQ Status ($40 means it thinks I'm "in frame" for this test, and no IRQ pending.)
$5208: $C0 ? (unknown)
$5209: $00 ? IRQ-related per krzysiobal
Re: MMC5 Hacking Adventures
I looked at Register $5204 (IRQ Status) bit 6 ("In Frame").
- At power-up of the MMC5, this status bit = 0.
- The bit goes high whenever PPU /RD goes low.
- The bit stays latched high even when PPU /RD goes back high
- PPU /WR seems to have no effect on this bit, whether the bit = 0 or 1.
- I tried all sequences of /RD and /WR and nothing would cause the status bit to return to 0.
- I tried toggling /RD 1000 times and the status bit still stayed 1 the whole time.
- Also tried toggling /WR 1000 times, no luck.
Does anyone know how "in frame" is cleared? I think that understanding this might be a good step towards understanding how the scanline counter works.
- At power-up of the MMC5, this status bit = 0.
- The bit goes high whenever PPU /RD goes low.
- The bit stays latched high even when PPU /RD goes back high
- PPU /WR seems to have no effect on this bit, whether the bit = 0 or 1.
- I tried all sequences of /RD and /WR and nothing would cause the status bit to return to 0.
- I tried toggling /RD 1000 times and the status bit still stayed 1 the whole time.
- Also tried toggling /WR 1000 times, no luck.
Does anyone know how "in frame" is cleared? I think that understanding this might be a good step towards understanding how the scanline counter works.
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: MMC5 Hacking Adventures
Check what I wrote at end of this topic:Does anyone know how "in frame" is cleared? I think that understanding this might be a good step towards understanding how the scanline counter works.
https://forums.nesdev.com/viewtopic.php ... 89#p209443
Re: MMC5 Hacking Adventures
Thanks krzysiobal, I read your thread and now I am able to get the status bit to clear by toggling M2. With my setup, I was able to determine that the MMC5 is very likely to be counting falling edges of M2 for this purpose. I attached a photo explaining how I came to this conclusion, also described below.
I ran the exact same test, once with M2 being high when "in frame" gets asserted, and another time with M2 being low when "in frame" gets asserted, all the while with the CPU address bus pointing to $5204, R/W = 1, /ROMSEL = 1. I then inverted M2 repeatedly until I was able to read "in frame" status bit cleared.
With M2 initially high, I observed that the status must clear either after 2 falling edges or 2 rising edges of M2 (can't tell because you can't read the status with M2 low). With M2 initially low, I observed that it must clear in either 2 falling edges or 3 rising edges. Therefore, common denominator, it must clear in 2 falling edges.
Tomorrow, I will try to recreate the other observations you made, including reading from CPU addresses $FFFA/B and also the other 2 interrupt vectors.
I ran the exact same test, once with M2 being high when "in frame" gets asserted, and another time with M2 being low when "in frame" gets asserted, all the while with the CPU address bus pointing to $5204, R/W = 1, /ROMSEL = 1. I then inverted M2 repeatedly until I was able to read "in frame" status bit cleared.
With M2 initially high, I observed that the status must clear either after 2 falling edges or 2 rising edges of M2 (can't tell because you can't read the status with M2 low). With M2 initially low, I observed that it must clear in either 2 falling edges or 3 rising edges. Therefore, common denominator, it must clear in 2 falling edges.
Tomorrow, I will try to recreate the other observations you made, including reading from CPU addresses $FFFA/B and also the other 2 interrupt vectors.
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: MMC5 Hacking Adventures
If you have desoldered the MMC5, could you please check if pins 99 & 80 (GND) are internally connected, and same for pins 44 & 4 (VCC)
Also the behaviour of pin 56 (to RAM's VCC) should be examined - why RAM'S VCC is not connected straight to battery. Maybe there is some kind of brown-out detection, when battery's voltage (MMC5 pin 57) drops below certain level, MMC5 drives pin 56 to ground?
Also the behaviour of pin 56 (to RAM's VCC) should be examined - why RAM'S VCC is not connected straight to battery. Maybe there is some kind of brown-out detection, when battery's voltage (MMC5 pin 57) drops below certain level, MMC5 drives pin 56 to ground?
Re: MMC5 Hacking Adventures
Because all the switchover circuitry is inside the MMC5? They integrated a MM1026 or something similar inside the package.krzysiobal wrote:why RAM'S VCC is not connected straight to battery.
Re: MMC5 Hacking Adventures
I used a diode tester on the pins you mentioned. I am using this format:
Pin A -> Pin B
Where A is anode(+) and B is cathode(-) of the test.
VCC pins:
Measures 52 ohms or 0.04V diode test, same in both directions.
Pin A -> Pin B
Where A is anode(+) and B is cathode(-) of the test.
VCC pins:
- 44 -> 4: 1.00V
- 4 -> 44: 0.99V
- 4 -> 56: 1.57V
- 56 -> 4: open
- 4 -> 57: 1.98V
- 57 -> 4: open
- 56 -> 57: 2.31V
- 57 -> 56: 1.41V
- 44 -> 57: 2.23V
- 57 -> 44: open
- 44 -> 56: 0.98V
- 56 -> 44: open
Measures 52 ohms or 0.04V diode test, same in both directions.
Re: MMC5 Hacking Adventures
quickly throwing that in a table:
Have to admit I'm surprised by many of these.
I quickly broke out my NES-ELROM-01 (4-44 shorted by PCB) board and measured a few things:
4+44 → 56 : 0.854V / 1.258V
4+44 → 57 : high / high
56 → 4+44 : high / 1.777V
56 → 57 : high / high
57 → 4+44 : 0.437V / 0.470V
57 → 56 : 0.559V / 0.618V
Two different voltmeters: the left one can't measure diode drops above 1V; the right can't measure diode drops above 2V.
Code: Select all
vcc4 v44 prgv batt <- to
vcc4 ---- 0.99 1.57 1.98
v44 1.00 ---- 0.98 2.23
prgv hi hi ---- 2.31
batt hi hi 1.41 ----
^from
I quickly broke out my NES-ELROM-01 (4-44 shorted by PCB) board and measured a few things:
4+44 → 56 : 0.854V / 1.258V
4+44 → 57 : high / high
56 → 4+44 : high / 1.777V
56 → 57 : high / high
57 → 4+44 : 0.437V / 0.470V
57 → 56 : 0.559V / 0.618V
Two different voltmeters: the left one can't measure diode drops above 1V; the right can't measure diode drops above 2V.
Last edited by lidnariq on Sun Sep 30, 2018 11:05 am, edited 1 time in total.
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: MMC5 Hacking Adventures
Maybe pins 44/80 are digital vcc/gnd and 4/99 are analog vcc/gnd (used by the amplifier), cause they're all placed together.
Re: MMC5 Hacking Adventures
Exactly my theory as well.krzysiobal wrote:Maybe pins 44/80 are digital vcc/gnd and 4/99 are analog vcc/gnd (used by the amplifier), cause they're all placed together.
I am doing some testing today on setting and clearing the "in frame" status bit. I have not yet tested reading from the vectors on the CPU bus. I have found results that confirm PPU /A13 involvement in setting this status bit. If /A13 = 1 (tested address 0x1FFF), it can set the status, and if /A13 = 0 (tested address 0x3FFF), it can't, except for the initial run with my setup. The status bit does get set with PPU /RD falling edge when /A13 = 0 for the first run for me, so I am exploring that for an explanation. It would be easy to say "who cares" because it is just the first frame, but it could possibly shed some more clues.
I had suspected that PPU /A13 was latched somehow, as if the MMC5 is using the latched value for PPU /RD falling edge handling. The way my test was written, /A13 would actually start high and I would set M2 low before setting /A13 low. To test if M2 triggered /A13 to latch, I tried setting M2 low after setting /A13 low. The status bit still got set first time, test fail.
Next, I tried toggling M2 before /RD falling edge. M2 initially high, then low - high - low. Status still got set. M2 high-low-high-low-high-low-high-low. STILL got set. Probably not M2's fault.
Next, I tried putting a 1k pull-down on /A13 so that it was never high from power on, and throughout the test, verified with oscilloscope that it stayed low. The status bit also still got set. This excludes the possibility that /A13 itself triggers its latch. Conclusion thus far: Whatever can latch /A13 apparently has not occurred yet before the first run of the test, and the default latch value is 1.
Next I tried adding a read of $5204, including toggles to M2, before doing the initial PPU /RD falling edge with /A13 low. Status bit still got set. So, the act of reading $5204 is not the trigger for this theoretical latch, and that kind of blows the whole latch theory because I don't do anything else for this test.
As best as I can tell so far, the initial falling edge of PPU/RD ignores /A13. Period.
Re: MMC5 Hacking Adventures
I am not able to reproduce what I was saying with /A13 now -- I think I goofed something up. What I am seeing now is that the status bit initially gets set when PPU /RD goes low the first time, regardless of /A13. Then once cleared with M2 toggles, I can not get the status bit to set again after that no matter what the value of /A13. Sorry for the confusion on this -- my assumption was that I could set it again, depending on /A13, and wondering why the initial behavior was different. That seems to not be true now.
I need to go back and read your findings better krzysiobal. It looks like you figured all of this out already.
I need to go back and read your findings better krzysiobal. It looks like you figured all of this out already.
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: MMC5 Hacking Adventures
There must be three PPU read cycles, all of them from the same address and and the address must be any from range $2000-$3fff.I need to go back and read your findings better krzysiobal. It looks like you figured all of this out already.
Re: MMC5 Hacking Adventures
I looked at how reading from CPU address $FFFA and $FFFB can clear the status. I verified it clearing with my setup. I found that the clearing of the bit is asynchronous. At any time that all of the following are true, it immediately clears the status bit:
It does not clear status when reading the other vectors from $FFFC - FFFF.
I don't know what the problem is, but I am not ever able to get the status bit to set again once I have cleared it. I hold the same PPU address and toggle PPU /RD a bunch of times, and the bit never gets set again. I tried with /A13 both high and low. I tried after clearing with $FFFA/B, and tried after clearing with M2 toggles. I only can get it to set 1 time after power up, which coincides with the first falling edge of PPU /RD, regardless of PPU /A13. I verified with my scope that /A13 is being driven as intended. I am very confused!! Any ideas what I need to do to get the status bit to set a second time?
- M2 = 1 (does not wait for an edge)
- /ROMSEL = 0
- CPU A14 through A3 = 1
- CPU A2 = 0
- CPU A1 = 1
- (CPU A0 = don't care.)
It does not clear status when reading the other vectors from $FFFC - FFFF.
I don't know what the problem is, but I am not ever able to get the status bit to set again once I have cleared it. I hold the same PPU address and toggle PPU /RD a bunch of times, and the bit never gets set again. I tried with /A13 both high and low. I tried after clearing with $FFFA/B, and tried after clearing with M2 toggles. I only can get it to set 1 time after power up, which coincides with the first falling edge of PPU /RD, regardless of PPU /A13. I verified with my scope that /A13 is being driven as intended. I am very confused!! Any ideas what I need to do to get the status bit to set a second time?
Re: MMC5 Hacking Adventures
Well, right after I posted that I had a breakthrough on this.
I was using PPU addresses $1FFF and $3FFF. Both of those are not able to set the status bit. I tried $0000 and $2000, and $2000 IS able to set the bit again. I will continue this to figure out the exact address ranges that are able to set the bit.
I was using PPU addresses $1FFF and $3FFF. Both of those are not able to set the status bit. I tried $0000 and $2000, and $2000 IS able to set the bit again. I will continue this to figure out the exact address ranges that are able to set the bit.
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: MMC5 Hacking Adventures
I don't know why but just after power up, there need to be the following sequence:
ppu_read from address xxxx
ppu_read from address xxxx
ppu_read from address xxxx
cpu read 5204 <- it will return the in frame bit clear
ppu_read from any address
cpu read 5204 <- it will now set the in frame bit
After that, it status bit gets cleared, 3 ppu reads and then cpu read from $5204 will normally return in frame bit set (and now I checked that xxxx can be any from range $0000-$3fff, probably last time I misschecked something)
ppu_read from address xxxx
ppu_read from address xxxx
ppu_read from address xxxx
cpu read 5204 <- it will return the in frame bit clear
ppu_read from any address
cpu read 5204 <- it will now set the in frame bit
After that, it status bit gets cleared, 3 ppu reads and then cpu read from $5204 will normally return in frame bit set (and now I checked that xxxx can be any from range $0000-$3fff, probably last time I misschecked something)