It is currently Tue Oct 16, 2018 9:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sat Sep 29, 2018 12:01 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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


Top
 Profile  
 
PostPosted: Sat Sep 29, 2018 3:40 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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.


Top
 Profile  
 
PostPosted: Sat Sep 29, 2018 3:50 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 394
Location: Poland
Quote:
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.

Check what I wrote at end of this topic:
https://forums.nesdev.com/viewtopic.php ... 89#p209443


Top
 Profile  
 
PostPosted: Sat Sep 29, 2018 5:45 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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.


Attachments:
IMG_1543[1].JPG
IMG_1543[1].JPG [ 1.43 MiB | Viewed 290 times ]
Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 2:30 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 394
Location: Poland
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?


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 10:17 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
krzysiobal wrote:
why RAM'S VCC is not connected straight to battery.
Because all the switchover circuitry is inside the MMC5? They integrated a MM1026 or something similar inside the package.


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 10:32 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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:
  • 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

GND pins 80 and 99:
Measures 52 ohms or 0.04V diode test, same in both directions.


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 10:51 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
quickly throwing that in a table:

Code:
     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


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.


Last edited by lidnariq on Sun Sep 30, 2018 11:05 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 10:57 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 394
Location: Poland
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.


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 12:28 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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.

Exactly my theory as well.

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.


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 1:03 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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.


Top
 Profile  
 
PostPosted: Sun Sep 30, 2018 1:25 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 394
Location: Poland
Quote:
I need to go back and read your findings better krzysiobal. It looks like you figured all of this out already.


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.


Top
 Profile  
 
PostPosted: Mon Oct 01, 2018 3:00 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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:

  • 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.)

In addition, when I trigger the status bit to set with falling edge of PPU /RD, if I just leave PPU /RD low after that, I am still able to clear the status by reading $FFFA/B with PPU /RD remaining low the whole time.

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?


Top
 Profile  
 
PostPosted: Mon Oct 01, 2018 3:23 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 75
Location: Minnesota
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.


Top
 Profile  
 
PostPosted: Mon Oct 01, 2018 3:46 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 394
Location: Poland
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)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 10 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