I have a Punch Out cartridge :
Front :
Back :
It didn't work when I bought it
Yesterday I desoldered its PRG and CHR and took them out
I was surprised when I found out that Punch Out is a 256KB game
But as you can see in the pictures the PRG and CHR have only 28pins!
28pins EPROMs like 27C512 can only contain up to 64KB
Anyway I set my Willem EPROM programmer to 27C512 and dumped those PRG and CHR
CHR is OK to some extent and I can see the Punch Out graphic by using TLP
But PRG is severely damaged and that is why the whole cartridge didn't work
Then I noticed that there is an option for 1Mbit (128KB) EPROMs
I used two 29F040 as PRG and CHR then I tested the cartridge with a fresh Punch-Out!! (U) [!] and fortunately it worked!
You know FamiGOD demands sacrifices now and then, so here it goes, may FamiGOD accept it
:
Front :
Back :
Is it possible to convert these TTLs to FPGA or CPLD?
If so which one is better to use?
And what part number should I use?
Is it possible to add some more TTLs to make MMC4?
Interesting... sometimes we see pirate carts with discrete logic implementations of moderately complex mappers. I believe we've seen one more complex than the MMC2, but I don't remember which one.
FARID wrote:
28pins EPROMs like 27C512 can only contain up to 64KB
Nintendo has always used 28-pin 128KB mask ROMs for PRG though (128KB CHR needs more pins).
Nice find. Who'll be the first to convert this to a schematic?
FARID wrote:
It's possible, but you can probably just switch around a couple of the address outputs from the existing TTLs. Another option if you want to reproduce a Fire Emblem or Famicom Wars hack is MMC4 on CPLD from infiniteneslives.com. (Or does the embargo interfere?)
Wow, this is very cool. Only 13 chips to emulate an entire MMC2 with all it's auto-bankswitching features, that's not too bad !
Quote:
Another option if you want to reproduce a Fire Emblem or Famicom Wars hack is MMC4 on CPLD from infiniteneslives.com.
Indeed! My real goal is Fire Emblem!
But I want to make it myself because it is more fun.
Quote:
(Or does the embargo interfere?)
Yeah, we are really under pressure from it
Quote:
Only 13 chips to emulate an entire MMC2
Are you sure it is entire?!
Then where is the phi2?
As a guess, right now, somewhere on the PCB there's an OR gate (74'32) that generates the signal (CPU_A14 OR CPU_A13), which needs to become just CPU_A14. Additionally, the PRG bank register is going to be connected to PRG A13 ... A16, and for MMC4 it needs to be PRG A14 ... A17 and CPU A13 needs to connect directly to PRG A13. Finally, you'll need a 74'20 or something to add a RAM.
I'll sit down later and trace out a schematic. Right now I see a 74'75 (4 bits), a 74'175 (4 bits), two 74'670s (32 bits), and a 74'74 (2 bits), I bet the two '670s are used for the CHR banking, and the 74'74 is used for the CHR rendering side, so I guess the other two quad latches must be used for PRG banking and Mirroring control.
Finished tracing everything, but haven't yet started transcribing to a schematic. I did notice one funny thing: the left pattern table (0xxx) uses a different decision criterion for whether it should swap pattern tables. The right pattern table only switches based on PPU A12 .. A3, but the left additionally requires that it fetch from the first row of the pattern, i.e. it requires that PPU A2..A0 is 0. This means that if tile FD and FE were in the same row, when from the left pattern table it would only show a single scanline from the FD bank, but the right pattern table would show eight scanlines.
I have no idea if this is the same as the actual MMC2.
lidnariq wrote:
The right pattern table only switches based on PPU A12 .. A3, but the left additionally requires that it fetch from the first row of the pattern, i.e. it requires that PPU A2..A0 is 0.
I seem to recall seeing this same detail in the MMC2 patent, though I'm not sure if the real chip behaves the same way.
Seems that Punch Out puts sprites on the left table and backgrounds on the right.
Here you go. Eagle SCH, LBR for the split version of the 74'75, PDF, and the png here. It's possible I've made a few mistakes, but mostly the layout just kinda sucks.
The 74'75 input and 74'670 inputs that I've connected nothing to actually do float. The unused AND and OR gates' inputs float too. I was too lazy to draw the connections to the ROMs, though.
I'm not certain how applicable this is; I understand the 74'670 is not terribly easy to come across anymore.
Btw, I asked BootGod to test: the MMC2 does behave according to both the patent and the discretes implementation here. By which I mean, fetches from the left pattern table only trigger on the first row.
tokumaru wrote:
Interesting... sometimes we see pirate carts with discrete logic implementations of moderately complex mappers. I believe we've seen one more complex than the MMC2, but I don't remember which one.
FARID wrote:
28pins EPROMs like 27C512 can only contain up to 64KB
Nintendo has always used 28-pin 128KB mask ROMs for PRG though (128KB CHR needs more pins).
I have a MMC5 with only TTL chips.
nintendo2600 wrote:
I have a MMC5 with only TTL chips.
And any picture?
Pics or it didn't happen
FARID wrote:
nintendo2600 wrote:
I have a MMC5 with only TTL chips.
And any picture?
Yep, I'll get some done up and post them later. It's from a Doki Doki Panic pirate cart.
A DDP cart that used MMC5? I thought DDP was written for MMC3. I'd still like to see a discrete version of MMC3
He probably meant MMC3. MMC5 would require a dual ported 1kb SRAM chip and literally hundreds to thousand of such TTL chips to work.
DDP was for FDS. A pirate DDP would probably implement a subset of FDS functionality, in much the same way that pirates of the other Super Mario Bros. 2 (J) did.
That and there is a (current day) rom hack of DDP to MMC5 IIRC. So perhaps that's adding to the confusion.
Bregalad wrote:
MMC5 would require a dual ported 1kb SRAM chip and literally hundreds to thousands of such TTL chips to work.
Total number of bits of state of the MMC5, other than that RAM: about 240 bits. Half of that is just for CHR banking. And a sufficiently fast SRAM—probably even as slow as 70ns—can be used as a dual-ported RAM in the NES given a little support logic.
I'd bet it's closer to 50 74xx ICs, especially if we're allowed to use obsolete parts like the 74'558 (8x8 multiplier), 74'219 (16x4 RAM), and 74'670 (4x4 RAM).
That many 74xx ICs is still far too many to power off the NES's power supply, or fit in a cartridge.
lidnariq wrote:
Btw, I asked BootGod to test: the MMC2 does behave according to both the patent and the discretes implementation here. By which I mean, fetches from the left pattern table only trigger on the first row.
The question is, is the same true of the MMC4?
nintendo2600 wrote:
Yep, I'll get some done up and post them later. It's from a Doki Doki Panic pirate cart.
Doki Doki Panic on MMC5!
Does it really need that much?!
Quote:
File: Doki Doki Panic (FDS Conversion).nes
CRC: 8B692CBF
SHA-1: 64D3AB894788A9670EF4B3E3F05A45ECEF4ACC45
System: NES-NTSC
Board: BTL 2708, Mapper 103
PRG-ROM: 128k
V-RAM: 8k
W-RAM: 16k
Solder Pad: H:1 V:0
Battery: No
Quietust wrote:
The question is, is the same true of the MMC4?
Can't be. MMC4 doesn't connect to PPU A0..A2.
FARID wrote:
nintendo2600 wrote:
Yep, I'll get some done up and post them later. It's from a Doki Doki Panic pirate cart.
Doki Doki Panic on MMC5!
Does it really need that much?!
Quote:
File: Doki Doki Panic (FDS Conversion).nes
CRC: 8B692CBF
SHA-1: 64D3AB894788A9670EF4B3E3F05A45ECEF4ACC45
System: NES-NTSC
Board: BTL 2708, Mapper 103
PRG-ROM: 128k
V-RAM: 8k
W-RAM: 16k
Solder Pad: H:1 V:0
Battery: No
The reason MMC5 was used is because only MMC5 offers 32KB of PRG-RAM that can be mapped from $6000 to $DFFF. No other standard mapper does this.
infiniteneslives wrote:
That and there is a (current day) rom hack of DDP to MMC5 IIRC. So perhaps that's adding to the confusion.
correct. my bad.
Still would like to see a discretes implementation of MMC3, if it is that.
Or honestly, I'd like to see it even if it's just an FDS-emulating RAM cartridge.
Been asked to reupload the pictures of the first post
So here it isHave fun and keep up the good work!
FARID wrote:
Been asked to reupload the pictures of the first post
So here it isHave fun and keep up the good work!
Much appreciated. Thanks!
FARID wrote:
Been asked to reupload the pictures of the first post
So here it isHave fun and keep up the good work!
FARID, can you upload this to a different file host? I can't manage to download anything from 4shared without it asking me for social media logins or bundled adware fake setup.exe crap, etc.
mediafire and sendspace have less issues with bundled adware, as does mega.co.nz, and dropbox has very little either.
LN
I used bugmenot to get around the creepy creepy 4shared BS the most recent time I had to.
That said, I still have the images, as well as my traced image, so I could put them somewhere but would like Farid's OK first.
@ Lord Nightmare
I can only use 4shared, other uploading sites are censored by gov
@ lidnariq
It is ok with me for sure.
I traced it too, but I haven't tested it yet.
Here's the 3 most useful of the 4 images.
Unfortunately, the gimp XCF really doesn't compress well at all; it's still 13MB so I think I'll hold off uploading it ... unless someone tells me they want it.
The gimp .xcf file with the board tracing would indeed be very useful.
LN
When I say "trace" I meant "labelled", with unique letters at each of the vias.... like this:
Attachment:
discrete-mmc2_depop_sample.jpg [ 30.55 KiB | Viewed 3782 times ]
If that still sounds useful, I'll put it up on mega, or something.
(I'm just being hesitant because my upstream is annoyingly small, so I want to make sure it's useful/interesting)
Labelled picture is useful definitely.
But I think schematic is more useful.
And we already have three MMC2 schematics.
lidnariq: yes, that does sound useful, since it acts itself as a partial schematic.
LN
The midway would be to label nets on the PCB to match a schematic.
Thanks for sharing, Farid! I just can't see to get the file to work.
A mirror would be highly appreciated! That site never works no matter what your browser's settings. All buttons lead to malware attempts. It's gotten even worse since that was originally posted. Does anyone have a mirror, please?
Oh wait, those images work well enough. I just didn't try viewing them fullscreen. Sorry, hehe.
Restored schematics:
FARID
Can share the data in the cart?
zxbdragon wrote:
FARID
Can share the data in the cart?
The EPROM's were damaged, so I couldn't dump them.
But as I tested Punch-Out!! (U) [!].nes worked fine on the cartridge.