MMC5 Hacking Adventures

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

Moderators: B00daW, Moderators

User avatar
Ben Boldt
Posts: 417
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt » Mon Nov 12, 2018 4:53 pm

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?

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Mon Nov 12, 2018 5:11 pm

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.
Well, no, all the rules from Wiki apply. So for example when I wrote
$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?)

User avatar
Ben Boldt
Posts: 417
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt » Mon Nov 12, 2018 5:15 pm

krzysiobal wrote:
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.
Well, no, all the rules from Wiki apply. So for example when I wrote
$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?)
Sorry, I misinterpreted. I need to check my setup and revert the wiki....

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Mon Nov 12, 2018 5:26 pm

Another question: I have seen PRG-RAM +CE always high in all conditions. What would make this signal go low?
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 signal :)

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Mon Nov 12, 2018 6:29 pm

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

User avatar
Ben Boldt
Posts: 417
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt » Mon Nov 12, 2018 10:28 pm

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Tue Nov 13, 2018 4:06 am

Code: Select all

I think you found PRG RAM A15 and A16.
Thank you, this is wonderful idea! Glad you could light lamp in my head, cause I firstly thought they are some kind of signals to enable external (additional) memories.
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
is WRONG

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)

User avatar
Bregalad
Posts: 7767
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: MMC5 Hacking Adventures

Post by Bregalad » Tue Nov 13, 2018 4:39 am

krzysiobal wrote: 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
is WRONG

bits 3-0 in $5113/$5114/$5115/$5116 are used to manipulate RAM bank in each regions:
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
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Tue Nov 13, 2018 5:02 am

Probably I misunderstood the sentence:
When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.

User avatar
Bregalad
Posts: 7767
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: MMC5 Hacking Adventures

Post by Bregalad » Tue Nov 13, 2018 6:04 am

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 ?

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Tue Nov 13, 2018 6:54 am

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)

User avatar
Bregalad
Posts: 7767
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: MMC5 Hacking Adventures

Post by Bregalad » Tue Nov 13, 2018 7:28 am

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)

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: MMC5 Hacking Adventures

Post by krzysiobal » Tue Nov 13, 2018 8:24 am

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.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC5 Hacking Adventures

Post by tepples » Tue Nov 13, 2018 8:59 am

"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.

User avatar
Ben Boldt
Posts: 417
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt » Tue Nov 13, 2018 10:17 am

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.

Post Reply