Help to dump rare 82 in 1 Chinese cartridge.

Hi, I bought the Kazzo cartridge "INL Retro" Dumper-Programmer to dump a 82 in 1 Chinese cart but I'm having trouble,
all the scripts I tested with Anago did not work, sorry for the lack of knowledge about it, it goes on Attach the photo of
the cartridge and the board. Thank you.


Game selection menu: ( youtube )

https://www.youtube.com/watch?v=uOhE7UNCNXk

Cart Photos :

What exactly makes this cartridge "rare"? Just curious.

I played it in my childhood and spent a long time looking for a rom to download or get a cartridge, after two years I managed to find one on e-bay.

To dump the cartridge, we need to know the same information one would need to emulate it.

Pictures of the front and back of PCB would be a good starting point. For the side with the ICs, multiple angles such that we can see what traces go to what pins would be nice. Depending, the pictures may not be good enough, and you may need to sit down with a continuity meter and figure out which pins on the small ICs in the corner go to what pins on the cartridge connector and/or large ICs.

With the parts on that board— Two 74LS174s, a 74LS139, a 74LS153, and a 74LS32—we can be assured that this is yet another one of the multicarts that support 16K/32K games and switchable mirroring.

like mapper 63.

I did not find this script to download, could give me instructions on how to do it. thank you.

You read first 32K data and upload.

Unfortunately, too many traces are hidden under the ICs for me to be able to deduce the function of that board from just pictures.

What I can tell:
* Only ten of the twelve bits of storage in the latches are connected
* The latches are cleared on reset
* The 74'153 is used to select between 16K/32K games and between H/V nametable layout.

If both ROMs are 1 MiB, and only ten bits are present in the banking register, then seven bits select which 16K PRG bank, one selects PRG bank size, one selects H/V nametable layout, and the one remaining one ... who knows. Possibly UNROM layout, given the 74'32.

Odds are good that you could just use a Kazoo script that was shaped something like
and then just have to figure out how to re-shuffle the resultant 16MiB dump to extract the actual 2 MiB of data.


Alternatively, use a continuity meter to figure out which address pins on the ICs labeled "NCN-82" connect to which pins on the small ICs.

I'm sorry but I do not know how to do it, and which script to use. thank you.

cnrom.ad

Thanks for the answer, according to the image, I mapped the connections between the NCN ICs for the smaller ICs, I do not know how to edit the scripts, if you can send me, I'll be grateful. (Sorry for the ugly connection lines).

I took the test and the message appeared:




Apparently the kazoo driver is installed correctly:

You'll need to flash the original kazzo firmware onto the device as explained in the readme. You've got my firmware installed which is focused on flashing operations.

Easy things first:

What you've traced shows this functionality:


The remaining functions must exist in the remaining four bits:
1- one bit must select between H/V nametable layout. This will be which of the pins on the two GD74LS174s connects to "pin 2" on the 74LS153.
2- one bit must disable writes to the HY6264 RAM. This will be which of the pins on the two GDLS174s connect to ... some of the pins on the 74LS32.
3- one bit must select between 16K and 32K PRG. This will be which of the pins on the two GD74LS174s connects to "pin 14" on the 74LS153.
4- one bit must select between the upper and lower half when in 16K PRG mode. This will be two of pins 3-6 on the 74LS153.

Either way, one of these two kazoo fragments should give you a valid dump:

OR

みなさんが積極的な発言をしてくれていて作者だった私はとてもうれしい.

First of all thanks to all who helped, I changed the firmware and was able to do the dump by creating a script with the above codes,
a 2Mb file was generated but when trying to emulate it the following error appeared:



Ps.
I tried the mapper 63 and it did not work too

Following is the files generated with the two passages of code "Cpu write"

What do you think about it? Just wild guess.

82in1_.nes [2 MiB] is ok. change mapper 100 to mapper 63 ,working nestopia,same game not working ,60.64...

For me it looks like a professional job !

Thank you.

It worked perfectly with nestopia 1.40, thanks to all who have helped and forgive my lack of knowledge.
This rom is not available on the internet, if it is convenient we can divulge it.

Thank you.

It worked perfectly with nestopia 1.40, thanks to all who have helped and forgive my lack of knowledge.
This rom is not available on the internet, if it is convenient we can divulge it.

Thank you.[/quote]

perfectly? nono,try 60,64 game.ninja?

perfectly? nono,try 60,64 game.ninja?[/quote]


I did the dump with mapper 60,64 and it appeared "CPU Jam" in the nestopia,
the only mapper that showed the menu of the game was 63.



Thanks.

He meant that you should try to play game #60 or #64 and see if they boot up or softlock.

Really, 60,64 does not start, is there anything we can do?


Thanks.

Krzysiobal: I suspect that this cart uses A0 in the reset detection circuit...

—
Cart's menu is first 16 KiB. If registers are cleared on power-up, then whichever bit that is must go 0:16K NROM and 1:32K NROM
Found a stub (at ROM offset 0x0127) that copies CHR from PRG to PPU.
Found a table at ROM offset 0x306 that appears to be the lower 8 bits of what's written to get the bank that contains CHR. (Bottom 2 bits always 0) Upper 8 bits are always $F1. Writes to $F000 to switch back to the menu.
Found a table at ROM offset 0x0358 that is the upper 8 bits of the CPU address to copy CHR from.
Found a table at offset 0x03AA that is the series of 16-bit (big-endian) words written to the banking register to switch into game ... except that the loader adds 0x200 to the address.

Both $F01A and $F01B appear in the table, implying to me that the A0 bit (&1) becomes PRG A14 and the A2 bit (&4) A1 controls 16K vs 32K. Leaving A1 A2 for mirroring control.
—

flaviocaste: We'll probably need to allocate a new (UNIF/NES2) mapper for it.

I've just added mapper63 definition to FCEUX in the way I described it and all games works, so maybe your mapper 63 in nestopia is invalid.


BTW. It's first time I add mapper in FCEUX and I am not familiar with this SDK, for example I don't know how to add CHR-RAM protection.



I just think that the diode is to make quick discharge of capacitor after power switch.

No, no, this cart isn't mapper 63. That's just another mapper that zxbdragon observed is extremely similar.

—

Why would it need the diode at all in that case? The overvoltage protection diodes in the various parts will discharge the capacitor on power failure quite quickly.

Maybe LS series (74LS174) does not have clamp diodes or maybe not to risk high current flow over internal chip protecting diodes (it's electrolite cap so it can store quite lot of energy).

I know one famous famiclone multicart (5-in-1 Codemasters's BIC) which has similar reset circuit but without diode installed (there is place for diode to be soldered) and it does not start properly on every console power up.

---

I think there are only clamp diodes to the ground, but not to VCC in LS chips - one guy decapped a lot of 74 chips from different families and rev-ed schematics. Only in CMOS (HC) there are clamp diodes to VCC and GND.
https://project5474.org/index.php?title=02

Well, then, why is it electrolytic? There's no need for the >1ms time constant if it's just to make sure that the pin is low on first power-up.

... Actually, though, the right answer is to just ask flaviocaste whether the multicart goes back to the menu when he hits the reset button.

I think refactoring mapper 63(nestopia),thank you !

Unfortunately I do not have the console, as I remember, at 25 years ago the reset returned in the selection menu, so I understand I need a new mapper to run all the games?

Ps. If you are interested, in the end I can send the cartridge so that they can test it.

Thanks.

Well, if you'd rather, you could just check for continuity on the other pins. I strongly suspect A0 connects to one side of the diode.

But I think I'm comfortable with "memory of going back to the menu on reset AND presence of diode-capacitor AND no connection to M2 implies reset detection circuit on A0"

The only points that have connection to the diode are the two small ICs (red dots)

merge code,now mapper 63,working two pcb.
todo test;

Uh.
What.
Not to any of the large ICs?

What does the other side of the diode connect to?

Mapper is very similar, but different

1.PRG logic same.
2.mirr logic different.（hardware runing Some games mirr are not correct)
3.menu logic different.
4.prg mask different.(0x7F or 0xFF)

Can be combined into a MAPPER, of course, if some precision, is defined as MAPPER 63.1

Yes, I tested the connection with all the pins on the board

Anyway, the correct place to put this code in FCEUX is as part of addrlatch.cpp. Perhaps:
Plus a little help in ines.cpp.

FCEUX has no implementations of submappers yet; it looks like the Whatever_Init routine has to inspect the CartInfo structure to decide how to initialize the board.

FCEUX also doesn't seem to have any way to write-protect CHR-RAM either; the best it has is the PPUCHRRAM 8-bit bitmask which specifies whether any given 1024 B CHR bank is writeable or not. It's not directly addressable; instead the setchr8r(r,A,V) function consults the CHRram array to determine whether any given IC is always RAM (and writeable) or always ROM. If this matters, we'll either have to add new "setchrNx" functions to support the abstraction or break the abstraction with something like this:


—

I see now that the $F01A and $F01B banking writes are slightly trollish. "04 SUPER MARIO" and "74 FANCY MARIO" are the same PRG and CHR, just with different nametable layout. I don't suppose flaviocaste remembers whether the last nine games on the cart were "real"?

and the `addrlatch` with 0x1FF to clear the CHR-write protection bit.


Maybe that's how it was supposed to work. Anyway, don't forget to set amount of CHRRAM in ines 2.0 header, otherwise FCEUX crashes during quitting.

I really do not remember this detail, about the above information, I do not understand the technical terms, do I need to do something else to run it well or just wait for a new version of FCEUX? Today I tested the rom in the Recalbox for raspberryPI3 and it did not work, there appeared a white screen, I changed the emulation core and run most games, except those that were reported here.




Thanks.

nestopia working this rom! and other pcb rom.

For reference, what is the filename of the other Mapper 63 cart?

255-in-1 (as)