MMC5 Hacking Adventures
Moderators: B00daW, Moderators
Re: MMC5 Hacking Adventures
Okay, well I was confused because the wiki says "ignored" in a lot of areas for registers $5114-5116. I guess this refers only to PRG-ROM. I will edit the wiki to reflect that.
Another question: I have seen PRG-RAM +CE always high in all conditions. What would make this signal go low?
Another question: I have seen PRG-RAM +CE always high in all conditions. What would make this signal go low?
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
Well, no, all the rules from Wiki apply. So for example when I wroteOkay, well I was confused because the wiki says "ignored" in a lot of areas for registers $5114-5116. I guess this refers only to PRG-ROM. I will edit the wiki to reflect that.
$5100 <- $00
and then
$5114 <- $7f
$5115 <- $7f
$5116 <- $7f
$5117 <- $7f
and then read $8000, no RAM is enabled (I've just tested that on hardware). So in that case $5114-$5116 are ignored.
So your assumption of no dependence on mode register is wrong (maybe there was some bogus write to $5100 that cause the mode to revert back to 3?)
Re: MMC5 Hacking Adventures
Sorry, I misinterpreted. I need to check my setup and revert the wiki....krzysiobal wrote:Well, no, all the rules from Wiki apply. So for example when I wroteOkay, well I was confused because the wiki says "ignored" in a lot of areas for registers $5114-5116. I guess this refers only to PRG-ROM. I will edit the wiki to reflect that.
$5100 <- $00
and then
$5114 <- $7f
$5115 <- $7f
$5116 <- $7f
$5117 <- $7f
and then read $8000, no RAM is enabled (I've just tested that on hardware). So in that case $5114-$5116 are ignored.
So your assumption of no dependence on mode register is wrong (maybe there was some bogus write to $5100 that cause the mode to revert back to 3?)
I have some trouble with setup delays, I suspect the PRG Mode write was not successful due to needing to space things out a little more. In some cases I am most likely exceeding the NES CPU clock by a fair bit.
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
As I observe, +PRG-CE is 1 as long as M2 is cycling (no matter what address is present on bus). Just about 11.2us after the last falling edge of M2, it goes low, so it can be considered as a preview of MMC5's internal /RESET signalAnother question: I have seen PRG-RAM +CE always high in all conditions. What would make this signal go low?

Also, I thought that every register of MMC5 is set to ones on power-up (or during reset).
However, $5114-$5116 seems to be either set to $0 (or just the highest bit is set to 0), because without writing anything to them or to the mode register, RAM seems to be enabled at $8000-$dfff by default.
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
i was not entirely true abouts pins 73 & 93 - here are full results:
Code: Select all
pin73:
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.3=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.3=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.3=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.3=0
otherwise outputs 1
pin93:
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.2=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.2=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.2=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.2=0
otherwise outputs 1
Re: MMC5 Hacking Adventures
I think you found PRG RAM A15 and A16.
Bank register bits:
7 RAM/ROM
6 A19
5 A18
4 A17
3 A16 <- Pin 73 (PRG RAM A16)
2 A15 <- Pin 93 (PRG RAM A15)
1 A14 <- PRG RAM A14
0 A13 <- PRG RAM A13
CPU non-paged address bits:
A0-12 - 8k
Please try the same test with PRG RAM A14 (Pin 70) and see if it reacts the same to bit 1 in $5113/4/5/6.
Bank register bits:
7 RAM/ROM
6 A19
5 A18
4 A17
3 A16 <- Pin 73 (PRG RAM A16)
2 A15 <- Pin 93 (PRG RAM A15)
1 A14 <- PRG RAM A14
0 A13 <- PRG RAM A13
CPU non-paged address bits:
A0-12 - 8k
Please try the same test with PRG RAM A14 (Pin 70) and see if it reacts the same to bit 1 in $5113/4/5/6.
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
Code: Select all
I think you found PRG RAM A15 and A16.
And yes, the sentence from wiki which says that:
Code: Select all
PRG RAM bank ($5113) - select RAM bank for $6000 and $8000/$a000/$c000/$e000
bits 3-0 in $5113/$5114/$5115/$5116 are used to manipulate RAM bank in each regions:
Code: Select all
pin73 (=RAM-A16):
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.3=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.3=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.3=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.3=0
otherwise outputs 1
pin93 (=RAM-A15)
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.2=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.2=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.2=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.2=0
otherwise outputs 1
pin70 (=RAM-A14)
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.1=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.1=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.1=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.1=0
otherwise outputs 1
pin69 (=RAM-A13)
outputs 0 when cpu accesses ($6000-$7fff or $e000-$ffff) and $5113.0=0
outputs 0 when cpu accesses ($0000-$1fff or $8000-$9fff) and $5114.0=0
outputs 0 when cpu accesses ($2000-$3fff or $a000-$bfff) and $5115.0=0
outputs 0 when cpu accesses ($4000-$5fff or $c000-$dfff) and $5116.0=0
otherwise outputs 1
if bit 2 is 0 and bit 7 is 0, them RAM0 is selected (RAM0-!CE is asserted) when accessing corresponding region
if bit 2 is 1 and bit 7 is 0, them RAM1 is selected (RAM1-!CE is asserted) when accessing corresponding region
$5113.7 is always 0 (there is always one of RAMs enabled at $6000)
pin75 (=RAM-!CE = RAM1-!CE && RAM2-!CE)
Re: MMC5 Hacking Adventures
Where do you see that sentense ? For me it has always made sense that each registers bankswitches a specific region / I don't know who came up with the idea that a single register would bankswitch all regions selected on RAM but this probably comes from a misunderstanding.krzysiobal wrote: And yes, the sentence from wiki which says that:is WRONGCode: Select all
PRG RAM bank ($5113) - select RAM bank for $6000 and $8000/$a000/$c000/$e000
bits 3-0 in $5113/$5114/$5115/$5116 are used to manipulate RAM bank in each regions:
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
Probably I misunderstood the sentence:
When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.
When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.
Re: MMC5 Hacking Adventures
So how would RAM be wired if more than 64k of it were to be present ? Would there be 4 chips, or just one single very large chip ?
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
a) 1x128K:
RAM.A16 = MMC5.RAM-A16 (73),
RAM.A15 = MMC5.RAM-A15 (93),
RAM.A14 = MMC5.RAM-A14 (70),
RAM.A13 = MMC5.RAM-A13 (69),
RAM.!CS = MMC5.RAM-!CS (75)
b)2x64K
RAM0.A15 = RAM1.A15 = MMC5.RAM-A16 (73),
RAM0.A14 = RAM1.A14 = MMC5.RAM-A14 (70),
RAM0.A13 = RAMA1.A13 = MMC5.RAM-A13 (69),
RAM0.!CS = MMC5-RAM0-!CS (71)
RAM1.!CS = MMC5-RAM1-!CS (72)
RAM.A16 = MMC5.RAM-A16 (73),
RAM.A15 = MMC5.RAM-A15 (93),
RAM.A14 = MMC5.RAM-A14 (70),
RAM.A13 = MMC5.RAM-A13 (69),
RAM.!CS = MMC5.RAM-!CS (75)
b)2x64K
RAM0.A15 = RAM1.A15 = MMC5.RAM-A16 (73),
RAM0.A14 = RAM1.A14 = MMC5.RAM-A14 (70),
RAM0.A13 = RAMA1.A13 = MMC5.RAM-A13 (69),
RAM0.!CS = MMC5-RAM0-!CS (71)
RAM1.!CS = MMC5-RAM1-!CS (72)
Re: MMC5 Hacking Adventures
I'm not even sure 64k SRAM chips existed - for some reason they liked to skip power of twos, chips were 2k, 8k, 32k or 128k.
(I could be wrong, chips of other sizes might exist but they were probably rarer or more expensive than two chips of the smaller size)
(I could be wrong, chips of other sizes might exist but they were probably rarer or more expensive than two chips of the smaller size)
-
- Posts: 589
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
Re: MMC5 Hacking Adventures
64k exists and I have a few of them (62512, DIL32-3)
I even had quite rare and uncommon 62128 (16k).
Larger (128k, 256k, 512k) also exists (various names), but they are in SO32 package)
BTW. Recently I did subset of MMC5 on FPGA to support Metal Slader Glory translation. I had minor troubles with the screen shaking (this game uses scanline counter two times per frame and it disables PPU rendering also 2 times per frame).
What I've noticed is that there are 4 (not 3) nametable fetches from the same address that appear at beginning of every. No idea why MMC5 just wants 3 sequential fetches as a signal of new scanline.
I even had quite rare and uncommon 62128 (16k).
Larger (128k, 256k, 512k) also exists (various names), but they are in SO32 package)
BTW. Recently I did subset of MMC5 on FPGA to support Metal Slader Glory translation. I had minor troubles with the screen shaking (this game uses scanline counter two times per frame and it disables PPU rendering also 2 times per frame).
What I've noticed is that there are 4 (not 3) nametable fetches from the same address that appear at beginning of every. No idea why MMC5 just wants 3 sequential fetches as a signal of new scanline.
Re: MMC5 Hacking Adventures
"at beginning of every" what?
Perhaps the fourth read might be related to the extra dot inserted at the beginning of almost every scanline (except the first line of every other field on NTSC). These are the fetches at the tail end of hblank:
321: BG x=0 tile ID
323: BG x=0 attribute
325: BG x=0 pattern plane 0
327: BG x=0 pattern plane 1
329: BG x=1 tile ID
331: BG x=1 attribute
333: BG x=1 pattern plane 0
335: BG x=1 pattern plane 1
337: BG x=2 tile ID (ignored)
339: BG x=2 tile ID (ignored)
0: BG x=2 tile ID (aborted)
1: BG x=2 tile ID (for real)
3: BG x=2 attribute
5: BG x=2 pattern plane 0
7: BG x=2 pattern plane 1
Could someone show a logic analyzer trace of PPU /RD, PPU A13, and PPU /A13 across an hblank, in order to help characterize this aborted read? I seem to remember reading years ago that it might even differ between NTSC and PAL PPUs.
Perhaps the fourth read might be related to the extra dot inserted at the beginning of almost every scanline (except the first line of every other field on NTSC). These are the fetches at the tail end of hblank:
321: BG x=0 tile ID
323: BG x=0 attribute
325: BG x=0 pattern plane 0
327: BG x=0 pattern plane 1
329: BG x=1 tile ID
331: BG x=1 attribute
333: BG x=1 pattern plane 0
335: BG x=1 pattern plane 1
337: BG x=2 tile ID (ignored)
339: BG x=2 tile ID (ignored)
0: BG x=2 tile ID (aborted)
1: BG x=2 tile ID (for real)
3: BG x=2 attribute
5: BG x=2 pattern plane 0
7: BG x=2 pattern plane 1
Could someone show a logic analyzer trace of PPU /RD, PPU A13, and PPU /A13 across an hblank, in order to help characterize this aborted read? I seem to remember reading years ago that it might even differ between NTSC and PAL PPUs.
Re: MMC5 Hacking Adventures
Would anyone be against this change in the pinout:
75 / -> PRG RAM /CE (R)
72 / -> PRG RAM 1 /CE (R) (RAM/CE | !$5113.2)
71 / -> PRG RAM 0 /CE (R) (RAM/CE | $5113.2)
I base this on my observation of voltage shifts reflecting pin 75 (but still logic high) in the scope shots of 72/71 when disabled via $5113.2. It leads me to believe that the base signal is 75 and the other two have the added combinational logic. I will try to confirm this by measuring propagation delay between 75 and 72/71.
Edit:
This should consider bit 2 in $5113/4/5/6, not just $5113. I think that makes the description too long. Will leave as-is.
75 / -> PRG RAM /CE (R)
72 / -> PRG RAM 1 /CE (R) (RAM/CE | !$5113.2)
71 / -> PRG RAM 0 /CE (R) (RAM/CE | $5113.2)
I base this on my observation of voltage shifts reflecting pin 75 (but still logic high) in the scope shots of 72/71 when disabled via $5113.2. It leads me to believe that the base signal is 75 and the other two have the added combinational logic. I will try to confirm this by measuring propagation delay between 75 and 72/71.
Edit:
This should consider bit 2 in $5113/4/5/6, not just $5113. I think that makes the description too long. Will leave as-is.