It is currently Wed Nov 14, 2018 11:07 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 157 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 11  Next
Author Message
PostPosted: Sun Oct 14, 2018 2:26 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 420
Location: Poland
Quote:
What happens if you read register $5209? Is there a different flag to show that it is running?

It read backs as $00. After the X-th edge it read backs as $80 (and reading it clears pending interrupt).
Interrupt is reported around 41ns after rising edge of M2 and it is cleared also around 41ns after falling edge of M2 of the "read $5209" cycle.
If the X-th cycle is "read $5209" then the interrupt is reported only for the period of time between rising and falling edge (as below).
Image
And it counts M2 cycles (no matter if this is read or write cycle)


Quote:
How about reading register $5208 while it is running? Is it still reporting $C0?

Yes, before/on/after X-th edge it is still $C0

Quote:
What happens if you write value $01 - will it reload the counter and have the IRQ next rising edge of M2, or continue counting from the original value you wrote?

IRQ will be triggered on the next rising edge of M2

Quote:
What happens if you write value $00 - does it cancel the timer and never generate the IRQ?

Yes. But if the IRQ is already pending, writing $00 to $5209 does not cause it to acknowledge.


And yes, $520A is used to write upper 8 bits of the counter.
And no, $520B is not upper 16-23 bits (counter is only 16 bits wide) ;)


Last edited by krzysiobal on Sun Oct 14, 2018 2:42 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Oct 14, 2018 2:42 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
krzysiobal wrote:
And yes, $520A is used to write upper 8 bits of the counter.
Do writes to $5209 start the counter, then? Or does it just count while nonzero, and certain values are harder to request?


Top
 Profile  
 
PostPosted: Sun Oct 14, 2018 2:51 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
krzysiobal wrote:
And yes, $520A is used to write upper 8 bits of the counter.
And no, $520B is not upper 16-23 bits (counter is only 16 bits wide) ;)

Great work!! :beer: :beer: :beer: 8-)


Top
 Profile  
 
PostPosted: Sun Oct 14, 2018 2:52 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1440
krzysiobal wrote:
And yes, $520A is used to write upper 8 bits of the counter.
And no, $520B is not upper 16-23 bits (counter is only 16 bits wide) ;)


Presumably, writing $01 to $520A and then $00 to $5209 will generate an IRQ after exactly 256 cycles.

Next things to figure out:
1. Does it matter in what order you write the values to $5209-$520A? (i.e. will the sequence $01 -> $520A, $80 -> $5209, $02 -> $520A trigger an IRQ after 384 cycles or after 640 cycles?)
2. What exactly, then, is at $5207-$5208?

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Sun Oct 14, 2018 2:53 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 420
Location: Poland
lidnariq wrote:
krzysiobal wrote:
And yes, $520A is used to write upper 8 bits of the counter.
Do writes to $5209 start the counter, then? Or does it just count while nonzero, and certain values are harder to request?



It seems that only writing to $5209 starts the counter. That is, the following sequence:
write($5209, 0)
write($520A, 0)
write($520A, 1)

will not start counter, but the one below will:
write($5209, 0)
write($520A, 0)
write($520A, 1)
write($5209, 0)

Also, when the counter is ticking, writing to $520A will cause its value to be modified so there are no temporary registers:

write($5209, $5)
write($520A, $1)
write($520A, $ff) <- it will immediatelly update counter high byte


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 9:20 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
I did a not-so-exciting test on $5207 / $5208 last night. I wrote all possible combinations of data to registers $5207 and $5208 and I didn't read anything other than $C0 from $5208 from the entire test.

It went like this:
Code:
Init:
R/W = 1 (read from MMC5)
M2 = 1 (allow reading and loading new data)

for( int i = 0x0000, i <= 0xFFFF, i++ )
{
   // Write low byte of i to $5207
   Record low byte of i to spreadsheet
   CPU address = $5207
   R/W = 0 (write to MMC5)
   Set logic analyzer to output to CPU data bus
   Set data bus to low byte of i
   M2 = 0 (register the data)
   M2 = 1 (allow reading and loading new data)
   
   // Read back register $5208
   Set logic analyzer to input from CPU data bus
   R/W = 1 (read from MMC5)
   Record data bus value to spreadsheet

   // Write high byte of i to $5208
   Record high byte of i to spreadsheet
   CPU address already = $5208, no action
   R/W = 0 (write to MMC5)
   Set logic analyzer to output to CPU data bus
   Set data bus to high byte of i
   M2 = 0 (register the data)
   M2 = 1 (allow reading and loading new data)

   // Read back register $5208
   Set logic analyzer to input from CPU data bus
   R/W = 1 (read from MMC5)
   Record data bus value to spreadsheet
}


Edit:
Running the same test again but now reading register $5206 each time. If any combination of values written to $5207 / 5208 should turn the multiply into a signed multiply, $5206 should become $00 instead of $FE.

$FF(unsigned: 255) * $FF(unsigned: 255) = $FE01(unsigned: 65025)
$FF(signed: -1) * $FF(signed: -1) = $0001(signed: 1)

Seems doubtful but worth a try.

Edit 2:
Result: $5206 was always $FE during every step of that test. We can probably say that no combination of inputs to the multiplier affect the readback value of $5208, and no combination of inputs written to registers $5207 or 5208 affect the result of the multiplier.


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 11:52 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
Out of curiosity, have you tried just generically fuzzing the MMC5? Write random values randomly all over the $5000-$52FF range and see if $5208 changes?


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 11:54 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 420
Location: Poland
I don't know why but I have a premonition that $5208's value might be in connection to some hardware aspect of chip:
* How MMC5 is wired (SL/CL mode)
* Voltage of the battery (pin 57)
* Revision


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 2:10 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
lidnariq wrote:
Out of curiosity, have you tried just generically fuzzing the MMC5? Write random values randomly all over the $5000-$52FF range and see if $5208 changes?

Great idea, I will try it.

krzysiobal wrote:
I don't know why but I have a premonition that $5208's value might be in connection to some hardware aspect of chip:
* How MMC5 is wired (SL/CL mode)
* Voltage of the battery (pin 57)
* Revision

Cool theories. For the idea of revision, it seems that both of us have chips marked MMC5A. Do you have any other MMC5 carts that might have the non-A version? I will dig a bit but I am almost sure I do not have any others.

My setup has battery removed. Do you still have the battery installed in yours?

My setup has SL/CL disconnected. Are yours connected?


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 2:29 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
I have an MMC5letterless cart, but no testing apparatus.


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 4:02 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
Do you have a ROM dumper? $5208 should be easily dumpable.

In other news, it seems there is some sort of locking function. At the beginning of my test, bankswitching of CHR was occurring quite frequently with random writes to random addresses in the range $5000-$52FF, then all of a sudden it got stuck and has remained stuck for a long time now. I think I will let it go and see if it will unstick itself by morning - could be interesting. Maybe the MMC5A "crashed" somehow, that would have interesting implications to consider if it is crashable. Hopefully it doesn't have firmware in there that I just wiped out. That seems pretty doubtful for the mid 1990s I guess but you never know.

I plan to review the data between the last successful bankswitch and the next time that it should have done a bankswitch, and see what happened between there. As of yet, I have seen no changes to the unknown pins or to register $5208.

Edit:
I gave in and power cycled the MMC5 and restarted the test. It functions normally again, but it does seem to lock up quite quickly from this test. I might try playing with the random address range written to and see if I can narrow down any particular addresses that cause this locking. In both lock-ups, it ended up with CHR address pointing thusly: CHR A19 and A18 = 0. CHR A17 to A10, A2 to A0, CL3, SL3, all equal 1. PRG A19 to A13 all equal 1 (not sure they ever changed though to begin with though). Definitely no changes to the unknown pins in this test. They all remained either driven high or hi-z (can't currently tell the difference).

Edit 2:
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. The test is now set up to run all night, avoiding this address range. I should have a million or so random writes and dumps of all pins by morning.

Edit 3:
Lidnariq: I went ahead and ordered up 2 cheap Famicom L'Empereurs, hopefully one of them will have a non-'A' MMC5.


Top
 Profile  
 
PostPosted: Thu Oct 18, 2018 3:53 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 420
Location: Poland
You should make all addres line / RnW changeswhen M2 is 0 and put M2 to 0 after end of cycle, otherwise you are risking doing extra read/write cycles. Unfortunatelly from the code example, you are doing the opposite.

Maybe when M2 stops cycling, also all of its banking settings does to default?

---

All the test were done without battery, but when I plug battry into the socket, nothing changed concerning $5208.

---

BINGO! I still does not know the role of pin 98 and 97 (if that switches between CL and SL mode, why there is just not one input pin that connects between VCC and GND?).
Nevermind, I cut the CL3 jumper (which connected MMC5.98 with MMC5.97). Now both of them are not connected to anything. Reads of $5208 still returns C0.

But both of the pins seems to be inputs (with pullups to VCC). When both of them are not connected to anything, there is 5V on them, but after shorting any of them to GND (with even weak serial 4.7k resistor, the voltage drops to ~0.2V, so they must be inputs)

Shorting any of them to GND alters the value returned by $5208:

Code:
[AB00 0000] $5208 (reading)
 ||
 |+---------- value of MMC5.97 pin
 +----------- value of MMC5.98 pin


Now there need to be figured out:
* Does changing vale of those pins alters any MMC5 behaviour or
* are just they some kind of DIP swithes that game can readback (like in MAPPER90 games)

Wiki says that:
Quote:
In other words, CL mode passes the lowest PPU address bits straight to CHR ROM, while SL mode runs them through MMC5. SL mode allows the MMC5 to perform smooth vertical scrolling in split mode, while CL mode does not. Nearly all MMC5 cartridges use CL mode - it is not known why SL mode was not used instead: possibly ROM speed issues.

But I analyzed all the MMC5 PCBs from botgod and no single one uses SL mode.


Top
 Profile  
 
PostPosted: Thu Oct 18, 2018 6:30 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
Oh cool - I am glad you were able to figure that out, and thanks for sacrificing your CL3 jumper.

I genuinely did not know that the right time to make address changes was when M2 is 0. I will do that from now on.

It looks like the CHR banking is not reset from stopping M2 toggling. Since my PPU address bus is just floating, which ends up all 1s, I am not getting a very good representation of the actual banking that is going on, but the extended CHR address bits do flip one way, stay for a while, flip the other way, stay for a while, during this test. If it was resetting, I think it would mostly stay the same, and show little glitches as it changed and reset back right away.

I never did witness the PRG banking change (haven't checked the results this morning yet), so it makes sense that one is reset by delay in M2. I would probably not have seen the said glitches on the extended PRG bits unless I had my scope hooked to them or something.

Edit:
krzysiobal wrote:
Wiki says that:
Quote:
In other words, CL mode passes the lowest PPU address bits straight to CHR ROM, while SL mode runs them through MMC5. SL mode allows the MMC5 to perform smooth vertical scrolling in split mode, while CL mode does not. Nearly all MMC5 cartridges use CL mode - it is not known why SL mode was not used instead: possibly ROM speed issues.

But I analyzed all the MMC5 PCBs from botgod and no single one uses SL mode.

The wiki also said that there are 2 versions of MMC5: "MMC5" and "MMC5B". I think we have some work to do on the wiki. As we find things that seem somewhat conclusive, I have been (and I will continue to) add them on there as we go.

I will play around with CHR address ranges and see if I can affect either of these pins. They could be bi-directional pins. It seems quite odd to connect together 2 inputs, and not connecting them to gnd or vcc. There must be something more to that.

Edit 2:
In summary of the test, the only pins that ever changed after over 1,000,000 writes were the bankswitched CHR address bits. None of the unknown pins, and none of the PRG address bits. I had all PPU address bits = 1 the whole time.

The CPU address bits were being controlled to do the writes and reads, and at the time of sampling these bits, the CPU address would always have been $5208.

Looking at the writes in the range $5120 to $512A that caused a CHR bankswitch:
Code:
Range $5120 - 5127:
A19      A10  SL3 CL3  A2 A0
|          |    | |     | |
0011 1111 11    1 1     111

Range $5128 - 512A
A19      A10  SL3 CL3  A2 A0
|          |    | |     | |
0000 0000 00    1 1     111


I got a reasonably even distribution of writes that triggered the change of A17 through A10, also really even distribution of the value that was written. I did observe one single write of $00 that triggered a bankswitch, but my test observed no write of value $FF that triggered it. It is completely possible that the random test just never hit that combination.

5120: 31
5121: 21
5122: 28
5123: 25
5124: 23
5125: 17
5126: 19
5127: 21

5128: 70
5129: 58
512A: 56


Last edited by Ben Boldt on Thu Oct 18, 2018 10:49 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Oct 18, 2018 10:00 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
Ben Boldt wrote:
krzysiobal wrote:
But I analyzed all the MMC5 PCBs from botgod and no single one uses SL mode.
The wiki also said that there are 2 versions of MMC5: "MMC5" and "MMC5B".
Nah, we know that there are a very finite number of PCBs that used the MMC5 and all four of them per region left it in CL mode.

If there were dedicated prototyping boards made for the MMC5 (ETPROM?) maybe those support it. But we haven't found any yet.


Top
 Profile  
 
PostPosted: Thu Oct 18, 2018 11:04 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 116
Location: Minnesota, USA
The CL/SL mode stuff has been on the MMC5 pinout wiki page since its creation by user Banshaku in 2009. Are you around for comment Banshaku?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 157 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 11  Next

All times are UTC - 7 hours


Who is online

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