Hello!
I've got a very cheap Batman cartridge to try to make an MMC3 repro on it.
When I opened it, instead of MMC3 clone I found this 23c269 and some more chips (glue logic?).
Could this be a pirate Sunsoft 5a clone?
The stage 1 and 2 music are swapped, just as said happens on the japanese game.
I found that the game slows down a lot more than I remember.
Does this happen on the original Batman J?
Does someone have information about this clone?
Could I do a repro of Batman 2 or Mr Gimmick with this board?
Thanks in advance!!
Dump the ROMs and try to load them on a emulator. If they work as a mapper 69 .nes file then you might have it work for what you want.
But considering it's a NTDEC cartridge it could be a "customized" mapper and your game is hacked to run on a different mapper. If you try what I suggested above and it doesn't work that's the likely cause.
Looks like it's a custom mapper
This explains the slowdown!!
Could be possible to hack the games to use it?
I think not, I have no idea where are the SRAM control pins and PRG/CHR A17...
I have compared both PRG files, first half is almost identical, but the second half is almost all different.
I'm putting the ROMs here, just if someone is interested.
Should I disassemble the board, scan it and share the scans?
Thanks in advance.
Fisher wrote:
I have compared both PRG files, first half is almost identical, but the second half is almost all different.
I'm putting the ROMs here, just if someone is interested.
These are bad dumps! It looks like A16 wasn't connected properly.
Fisher wrote:
Should I disassemble the board, scan it and share the scans?
Good documentation is always appreciated. Of course, it's up to you - you're the one who would have to put it back together to re-use it!
I'll redump it later... Thanks to pointing this!
Looks like A16 is in /OE, I thought my "dumper" would notice this...
I think will be better to wire the pin to the top of the slot, or is better to dump it twice, once with A16 low and after with A16 high?
If a scan of the board will help the community to better understand the mapper (or the new mapper), count on it!! It's a little effort to help make emulation better!!
Redumped!
Have pulled a wire to pin2 from /OE on both ROMs at the 32 pin socket, got very different results!!
CHR's md5sum is the same as the original. I'll assume they're the same. Not posting here.
PRG is very different. Still no luck running them on an emulator
Nestopia only gives me a noise. Both FCEUltra and Mednafen just quit!
Maybe I messed up and fried the PRG? Is it still a bad dump?
I'm thinking in flashing the original PRG on a FlashROM and test if it works.
Have scanned both sides of the board. Hope it helps someone, specially me
It's 600dpi. Although only 8bpp... Is this enough?
Looking quickly I saw 4 unused pins... maybe they're the SRAM control pins and PRG/CHR A17, just have no idea of how to find who is who
Again, many thanks!! I'm learning a ton and having lots of fun too!!
The chip on your cart is a VRC2 clone.
The game plays fine as mapper 23.
edit: Well, not so fine due to the extra logic chips on the board as it uses them to extend the mapper capabilities. Graphics glitch slightly without the extra chips.
Cool!!
So, I can do a Contra J repro with this Batman!!
Any idea of what to do with the added logic??
What about the mapper pinout?? Is it similar to the VRC2?
Many thanks!!
You likely will have to mod the board heavily...
I can't really help you with that part.
But I am sure you will learn a lot about this from doing it.
Took a quick look at the the pinouts, seems just like this one:
http://wiki.nesdev.com/w/index.php/VRC2_pinoutGotta check all the pins to have sure, if it's consistent, I'll have the guidelines to mod.
Now I need to leave, real life is calling!!
Many thanks!! That was great!!
Fisher wrote:
CHR's md5sum is the same as the original. I'll assume they're the same. Not posting here.
That means the CHR is still a bad dump...
Now that I have a good dump of the PRG and very nice scans of the PCB, I can start to analyze the mapper.
Joe wrote:
Fisher wrote:
CHR's md5sum is the same as the original. I'll assume they're the same. Not posting here.
That means the CHR is still a bad dump...
Now that I have a good dump of the PRG and very nice scans of the PCB, I can start to analyze the mapper.
VRC4,MAPPER25
but F000-F003 is IRQ change.
Real machine, Is the blood flashing?
The mapper is your standard pirate VRC2-with-IRQ board, using VRC2b wiring.
The IRQ circuit uses two counters, one that counts 2048(?) cycles of M2, and another that counts a programmable multiple, up to 16(?), of that 2048 cycles and generates an IRQ. The control registers are mapped to $F000, $F001, and $F003 (mask $F003). Writes to $F000 halt and clear the 2048-step counter, halt the 16-step counter, and acknowledge the IRQ. Writes to $F001 start both counters. The high four bits of writes to $F003 will be loaded into the 16-step counter.
I'm not sure if it's just the pictures, but I don't see anything connected to 74191 pin 5. The connection to that pin controls the direction of the 16-step counter, but I'm not sure what it will do if it's not connected at all...
I'll see if I can draw some schematics for this, so others can more easily follow the IRQ circuit.
Done!
I wonder if there's already a mapper number assigned for this configuration.
Joe wrote:
Done!
I wonder if there's already a mapper number assigned for this configuration.
emu src ? you have?
Joe wrote:
I don't see anything connected to 74191 pin 5. The connection to that pin controls the direction of the 16-step counter, but I'm not sure what it will do if it's not connected at all...
The various BJT-based 74xx technologies (instead of FET-based) signal using current instead of voltage, so an open input is usually equivalent to a +5V input.
(e.g. datasheet for DM74LS14 says I
H = 20µA; I
L = -400µA )
I confirm this.
Pin 5 of 74191 is connected to noting. I took a look at the board right now.
Looking at the pinout of the mapper, seems to be exactly the same as this one
http://wiki.nesdev.com/w/index.php/VRC2_pinoutExcept that pin 13 is connected to VRAM /A10 instead of PA10, pins 16-17-18-19-39 and 28 are connected to nothing, but may have the same function as described on the wiki.
Does the external IRQ circuit explains the slowdowns on this game?
Should I try to redump the CHR?
I'll try to assemble a Contra J repro with this parts, any other game recommendation? I think Crisis Force won't work in this mapper, will it??
Again, many thanks for everybody!!
VRC2 and VRC4 are *almost* the same thing. But they aren't the same thing. You won't get VRC4 games work on VRC2.
The inverse surely is possible (with ROM hacking) as I've done it myself.
VRC4 has the IRQ timer and is capable of using bigger PRG/CHR ROMs.
l_oliveira wrote:
VRC2 and VRC4 are *almost* the same thing. But they aren't the same thing. You won't get VRC4 games work on VRC2.
Yeah, I have thought this, but asked anyway... you never know...
Will stay with Contra as this game marked my childhood, and this is the prime objective of my small collection.
Think I'll start tomorrow, because it's raining hard now, the perfect weather to take a nap!!
lidnariq wrote:
The various BJT-based 74xx technologies (instead of FET-based) signal using current instead of voltage, so an open input is usually equivalent to a +5V input.
(e.g. datasheet for DM74LS14 says IH = 20µA; IL = -400µA )
That would make it behave like the FME-7 IRQ counter, if the FME-7 only let you set the highest four bits of the counter. (In fact, the hacked ROM uses the original counter values. It writes the high 8 bits to $F003, and the low 8 bits to $F002.)
Fisher wrote:
Looking at the pinout of the mapper, seems to be exactly the same as this one
http://wiki.nesdev.com/w/index.php/VRC2_pinoutExcept that pin 13 is connected to VRAM /A10 instead of PA10, pins 16-17-18-19-39 and 28 are connected to nothing, but may have the same function as described on the wiki.
That pinout has some mistakes.
Fisher wrote:
Does the external IRQ circuit explains the slowdowns on this game?
The hacks they used to convert it from FME-7 to VRC2 added some code, so that could be why it slows down. It's hard to check if the IRQ could cause slowdown without an emulator that implements this mapper.
Fisher wrote:
Should I try to redump the CHR?
Yes. It's probably the same as the original, but it's good to know for sure.
That pinout is just confusing to read because it covers both VRC2 and VRC4.
Fisher,Cassette, Is there such a phenomenon?
untitled.av.
zxbdragon wrote:
Fisher,Cassette, Is there such a phenomenon?
Yeah! It plays almost like this!!
Although it don't have the hearth color glitch.
The energy glitch is present, and looks much worse on TV.
You see the slowdown on this first level!!
On the sewers and cavern it gets much worse!!
A lot of parts on stage 4-3 seems to be in slow motion!! I thought the game was going to lock out!!
Is the current Nestopia that can play it almost perfect or is it a modded version?
What do you mean with cassette?? I didn't get it!
Looks like I won't need a CHR redump!!
"Cassette" is another term that's used to mean "cartridge" or "game pak".
Cool!!
I've already seem it on some carts, but didn't understand the context.
In my native language cassette may refer to an audio tape, and there's even a word (a bad word) that some people say when they're surprised that sounds almost the same thing.
I thought it was kind of a joke
, but nevermind...
カセット (pronounced "kasetto") is often used for a game cartridge in Japanese, possibly because of its lack of complex consonant clusters compared to "cartridge". For example, Sunsoft's Nantettatte Baseball had a "double cassette system" that took option ROMs for roster updates. But in other languages, I agree that it's more likely to refer to a Philips Compact Cassette or a video cassette. Then you get to grandmas who call them "Nintendo tapes" because they slide into a front-loading NES the same way video cassettes slide into a VCR.
"Cassette" as a swear word when surprised, now that's new to me.
Cassette == cartridge == cart
I am sorry,My English is not very well.
real machine Like flashing?
tepples wrote:
カセット (pronounced "kasetto") is often used for a game cartridge in Japanese, possibly because of its lack of complex consonant clusters compared to "cartridge". For example, Sunsoft's Nantettatte Baseball had a "double cassette system" that took option ROMs for roster updates. But in other languages, I agree that it's more likely to refer to a Philips Compact Cassette or a video cassette. Then you get to grandmas who call them "Nintendo tapes" because they slide into a front-loading NES the same way video cassettes slide into a VCR.
"Cassette" as a swear word when surprised, now that's new to me.
In Portuguese (and maybe in Spanish too) "cacete" is the word for wooden club.The blunt weapon cavemen used.
Due to it's shape people use it's name as slang for the male reproductive organ or it can also be used in a context meaning the person got beaten up. That word is actually over 200 hundred years old pre-dating Compact Cassettes by a long margin. lol
To be fair, in spoken Portuguese the sound for both words are very similar. Maybe because of that here nobody write "Cassette". "K7" is used instead.
Hopefully this was enlightening.
Edit:
More explanation is due. My bad.
K7 meaning "ka" (how Portuguese speaking people pronounce "k") + "sete" (seven in Portuguese)
In China:
Attachment:
20150921133506.jpg [ 51.67 KiB | Viewed 9350 times ]
zxbdragon wrote:
In China:
Attachment:
20150921133506.jpg
Yes, because the Famicom in Japan also called the cartridges as "Cassettes". By the way, Master System, Mega Drive, MSX and Famicom cartridges have the exact size as a Compact Cassette case.
zxbdragon wrote:
untitled.av.
Which mapper is this?
Joe wrote:
zxbdragon wrote:
untitled.av.
Which mapper is this?
not have ines mapper number.
this game using unif
UNL-TH2131-1
Vrc2/4 + IRQ
Which emulators can run UNL-TH2131-1?
Joe wrote:
Which emulators can run UNL-TH2131-1?
Nice!! TH2131-1 is written on the PCB!!
Fisher wrote:
Joe wrote:
Which emulators can run UNL-TH2131-1?
Nice!! TH2131-1 is written on the PCB!!
CG Real machine like?
Attachment:
Batman (J) [p1]_002.png [ 4.26 KiB | Viewed 9312 times ]
Fisher wrote:
Joe wrote:
Which emulators can run UNL-TH2131-1?
Nice!! TH2131-1 is written on the PCB!!
Not yet,MAPPER information confirmation......
future:
virtuanes ex
virtuanes plus
fceux
nestopia plus!
zxbdragon wrote:
CG Real machine like?
It gets a little bugged on the top of the text, but not this much.
I should have made a video of the real thing before disassemble...
Maybe I should reassemble and make a video before the flash rom transplant.
zxbdragon wrote:
Not yet,MAPPER information confirmation......
What questions do you have? I think I can answer.
Registers: $F000, $F001, $F003 (mask: $F003)
$F000: Disables IRQ, halts counters, clears low counter.
$F001: Enables IRQ, starts counters. If the high counter contains 0, an IRQ will trigger immediately.
$F003: Loads high counter with a new value.
Code:
7 bit 0
---------
CCCC ....
||||
++++------ New value of high counter
The IRQ is generated by two counters, a low counter and a high counter. The low counter is 12 bits (counts from 0 to 4095) and counts M2 cycles. When the low counter is between 0 and 2047 and the high counter is 0, the IRQ line is pulled low. When the low counter reaches 2048, the high counter will count down.
That means that the interrupts generated by this will fire 2048 to 4095 cycles earlier than the corresponding FME-7 IRQ would have?
If I'm understanding everything correctly, using this IRQ the easy way (setting the counter while it's disabled and then enabling it) will trigger the IRQ between 1 and 4096 cycles sooner than a FME-7 would. It will act like a FME-7 that only lets you set the highest four bits, and triggers when it reaches 0 instead of when it wraps around.
The IRQ won't trigger immediately when the high counter reaches 0; the IRQ line is only pulled low when the high counter is 0 and the low counter has a value from 0 to 2047.
Hey zxbdragon, should I ask where did you get this ROM?
I would like to get it too and take a look, to make sure my dumping process is error free.
If you're interested, I can try to reassemble the cartridge and make some videos, maybe this can help document a little more this mapper.
By the way, I think I found a small bug on Nes Cart db search function: If I search chip type VRC2, I get only 2 results, but I know there are more than these already on the site's db. Wai wai world and Goemon 2 are some examples. Should they appear on the search for VRC2?
Thanks again for everybody!!
Fisher wrote:
Hey zxbdragon, should I ask where did you get this ROM?
I would like to get it too and take a look, to make sure my dumping process is error free.
If you're interested, I can try to reassemble the cartridge and make some videos, maybe this can help document a little more this mapper.
By the way, I think I found a small bug on Nes Cart db search function: If I search chip type VRC2, I get only 2 results, but I know there are more than these already on the site's db. Wai wai world and Goemon 2 are some examples. Should they appear on the search for VRC2?
Thanks again for everybody!!
try "KONAMI-VRC-2" at "PCB, Class, Mapper" instead.
Attachment:
virtuanes by temryu.rar [476.7 KiB]
Downloaded 505 times
zxbdragon wrote:
virtuanes by temryu.rar
Can I see the source code?
Fisher wrote:
Hey zxbdragon, should I ask where did you get this ROM?
I would like to get it too and take a look, to make sure my dumping process is error free.
Batman (j) [p1].unf wrote:
Dump by Fisher,Emu by temryu
...This is the ROM you dumped. (At least, the PRG is. I think you haven't gotten a good dump of the CHR yet.)
Joe wrote:
zxbdragon wrote:
virtuanes by temryu.rar
Can I see the source code?
Fisher wrote:
Hey zxbdragon, should I ask where did you get this ROM?
I would like to get it too and take a look, to make sure my dumping process is error free.
Batman (j) [p1].unf wrote:
Dump by Fisher,Emu by temryu
...This is the ROM you dumped. (At least, the PRG is. I think you haven't gotten a good dump of the CHR yet.)
?
dump Fisher
zxbdragon wrote:
Joe wrote:
zxbdragon wrote:
virtuanes by temryu.rar
Can I see the source code?
Sorry about the big delay. There's no source.
I use an old pc motherboard with UniFlash:
www.rainbow-software.org/uniflash/ Well... UniFlash's source is in the above site, but I have not changed it, I'm using its default latest version.
The motherboard is a PCChips M748.
I start DOS, hotswap the ROM and do a BIOS backup.
I asked the rom because it's using 28 pins chips, and I would like to have a reference to compare my results.
To flash a my repros I use a similar approach, most of the time works like a charm
To dump the PRG I lifted the IC pin 22 and wired it to the socket's pin 2. The socket is 32 pin.
Just wanted to be sure it was the correct thing I should do in this case.
I think there's been a bit of a misunderstanding. Let me try to clear that up...
zxbdragon: Where is the VirtuaNESex source? I would like to check the mapper code.
Fisher: The PRG portion of the ROM provided by zxbdragon is the PRG ROM you dumped. I'm not sure where the CHR came from, since your dump was bad. It's not useful as a check of your dumping process, but I've examined the ROM and it appears to be a good dump. There are no unexplained differences between your dump of the (pirate) PRG ROM and the original (not pirate) PRG ROM. All that's missing now is the CHR ROM. I don't expect it to be different from the original, but I'd like to verify.
Using a motherboard to dump ROMs is a pretty neat trick, and it sounds like you've done everything correctly. I'm guessing the connection between IC pin 22 and socket pin 2 isn't always very good, which is why your attempt at redumping the CHR ROM didn't work out. I'm sure if you try one or two more times you'll be able to get a good dump.
Joe: Sorry to have misunderstood, and even confused you with zxbdragon... that was not my intention.
As soon as I have a little more spare time I'll redump it a couple of more times to be sure it's correct.
The motherboard trick, although a bit limited, seemed to me easier than build some kind of complicated dumper
I just used what I had laying around
l_oliveira: that search tip worked like a charm on Nes Cart db!! Thanks!!
Game MAPPER information is not confirmed. Waiting for Fisher video
zxbdragon wrote:
Game MAPPER information is not confirmed.
I have reverse-engineered the mapper circuit. I can confirm any questions you have. That is why I would like to see the source.
Joe wrote:
zxbdragon wrote:
Game MAPPER information is not confirmed.
I have reverse-engineered the mapper circuit. I can confirm any questions you have. That is why I would like to see the source.
update code to GitHub
https://github.com/dragon2snow/fceux-dump-project
th2131-1.cpp wrote:
Code:
static int32 IRQCount;
case 0xF000: IRQa = 0; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF001: IRQa = 1; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF002: IRQCount &= 0xFF00; IRQCount |= V; break;
case 0xF003: IRQCount &= 0x00FF; IRQCount |= V << 8; break;
void UNLTh21311IRQHook(int a) {
if (IRQa) {
IRQCount -= a;
if (IRQCount <= 0) {
X6502_IRQBegin(FCEU_IQEXT); IRQa = 0; IRQCount = 0xFFFF;
}
}
}
That code is wrong. Please try this:
Code:
static uint16 IRQCountLow;
static uint8 IRQCountHigh;
case 0xF000: IRQa = 0; IRQCountLow = 0; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF001: IRQa = 1; if (IRQCountHigh == 0 && IRQCountLow < 2048) X6502_IRQBegin(FCEU_IQEXT); break;
// 0xF002 does not exist
case 0xF003: IRQCountHigh = V >> 4; break;
void UNLTh21311IRQHook(int a) {
if (IRQa) {
if(IRQCountLow < 2048 && IRQCountLow + a >= 2048) {
IRQCountHigh = (IRQCountHigh - 1) & 0xF;
X6502_IRQEnd(FCEU_IQEXT);
}
IRQCountLow += a;
if (IRQCountLow >= 4096) {
IRQCountLow -= 4096;
if (IRQCountHigh == 0) {
X6502_IRQBegin(FCEU_IQEXT);
}
}
}
}
I'm not 100% certain how IRQ timing works in fceux, so this might be off by one.
Joe wrote:
th2131-1.cpp wrote:
Code:
static int32 IRQCount;
case 0xF000: IRQa = 0; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF001: IRQa = 1; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF002: IRQCount &= 0xFF00; IRQCount |= V; break;
case 0xF003: IRQCount &= 0x00FF; IRQCount |= V << 8; break;
void UNLTh21311IRQHook(int a) {
if (IRQa) {
IRQCount -= a;
if (IRQCount <= 0) {
X6502_IRQBegin(FCEU_IQEXT); IRQa = 0; IRQCount = 0xFFFF;
}
}
}
That code is wrong. Please try this:
Code:
static uint16 IRQCountLow;
static uint8 IRQCountHigh;
case 0xF000: IRQa = 0; IRQCountLow = 0; X6502_IRQEnd(FCEU_IQEXT); break;
case 0xF001: IRQa = 1; if (IRQCountHigh == 0 && IRQCountLow < 2048) X6502_IRQBegin(FCEU_IQEXT); break;
// 0xF002 does not exist
case 0xF003: IRQCountHigh = V >> 4; break;
void UNLTh21311IRQHook(int a) {
if (IRQa) {
if(IRQCountLow < 2048 && IRQCountLow + a >= 2048) {
IRQCountHigh = (IRQCountHigh - 1) & 0xF;
X6502_IRQEnd(FCEU_IQEXT);
}
IRQCountLow += a;
if (IRQCountLow >= 4096) {
IRQCountLow -= 4096;
if (IRQCountHigh == 0) {
X6502_IRQBegin(FCEU_IQEXT);
}
}
}
}
I'm not 100% certain how IRQ timing works in fceux, so this might be off by one.
You know, why would you want me to be wrong? Humiliate me?
I don't want you to be wrong. I want the emulator to be right.
Sorry for the long delayed answer.
I managed to redump Batman J's CHR.
Since I have done 3 times and got the same results, I'll assume it's a good dump.
I choose to name the ROM as the chip, to avoid confusion (at last to me
).
The video is going to be delayed a bit more, since I'm having a huge fight with my capture card!! :-b
I have found another pirate game board. It was in very bad condition.
I disassembled, cleaned and dumped it, but it didn't work on any emulator I have tried. Mostly because the PRG ROM is bad, but it can be another modified mapper.
The original game is a MMC1 game. It's using a supposedly clone, labelled 9121, but it has some weird connections to the NES' CIC.
I'll reassemble it. If it works, probably it's a custom or modified mapper, or I did another bad dump
Think it's better to create a new thread to discuss it...
Again, thanks to everybody, I'm having fun and learning a lot in the process!!
Thanks for the redump! It looks like the pirates didn't modify the CHR at all. I wasn't expecting to see any differences, but it's nice to have confirmation.
I can't wait to see the next pirate board.
I have just created a new thread.
Just this time I created in "NES Hardware and Flash Equipment".
I thought it would be in a more correct place, since I'm just "resurrecting" that old cart!!
viewtopic.php?f=9&t=13331
Fisher wrote:
I have just created a new thread.
Just this time I created in "NES Hardware and Flash Equipment".
I thought it would be in a more correct place, since I'm just "resurrecting" that old cart!!
viewtopic.php?f=9&t=13331I can't wait to see the next have 4020b pirate board
I guess we call this the 23C269 or TH2131 mapper? Since it's not strictly VRC 2/4. :/
As I have promised some time ago, here's a video of this game's opening:
https://www.youtube.com/watch?v=JAafMRzZFfsI'm still fighting this crap capture card, since I'm getting no sound at all.
But this should be no problem, I guess...
I can try to do some game play videos, if needed.
I just have some little questions:
Is there a way to eliminate the slowdown on this game? Preferably without writing another ROM with a modified PRG.
What options I would have to make a repro on this board?
I was thinking originally in doing a Batman ROTJ, since I like this game and, as many old games, it's ridiculously expensive here!! But maybe I could do some other games, like Contra J, or even Crisis Force. Stay with this game as is is a good option too, but I really would like to eliminate the slowdown, if possible.
Fisher wrote:
Is there a way to eliminate the slowdown on this game? Preferably without writing another ROM with a modified PRG.
The mapper hack added by the pirates adds a lot of cycles to the processing time. The only way to fix that is by modifying the ROM.
Fisher wrote:
What options I would have to make a repro on this board?
Remove the IRQ circuit and you've got a fairly standard VRC2b board. Most games using a VRC2 should be pretty easy to get on this board, although some VRC2 variants will need a couple things rewired.
Fisher wrote:
I was thinking originally in doing a Batman ROTJ, since I like this game and, as many old games, it's ridiculously expensive here!!
This game does not use a VRC2, so it won't work unless you add a mapper hack like the pirates did.
Fisher wrote:
But maybe I could do some other games, like Contra J, or even Crisis Force.
Contra will require a small modification to the board (or possibly the ROM?) in order to work, since it relies on the microwire interface.
Crisis Force uses a VRC4, which means it won't work if it relies on any VRC4-specific features. Additionally, it needs PRG-RAM, so you'll need to add components to handle that (and prevent conflicts with the VRC2).
As I have thought.
Looks like the best idea is to stick with the game as-is.
I've seem a Batman ROTJ hack, but it's VRC4.
Looks like the best thing to do.
Maybe I mess up a little and put a socket on PRG ROM to try some hacks... who knows?
Up to now, the ROMs I have got/used seemed almost undestructible!!
But I really know it's not true!! I think I've been very lucky to have not killed any good cartridge yet.
Although I'm very cautious, I don't know if this lucky will last very long, so... better stay as-is.
Many thanks for everybody!!
Let me know if some more videos would be needed.
I'm really learning alot here!! Many thanks for sharing your knowledge!!
Edit: Just out of curiosity, I tested some Gamegenie codes with this game.
To my surprise, they worked as they should!
I tried the US version codes. Interesting, huh?
Sorry about my absence, I've been really busy lately...
As promised some time ago, I'm posting some gameplay videos:
Stage 3-1 and 3-2
https://youtu.be/mtGUVVPaSugStage 4
https://youtu.be/H8md_xgnp-sI have other weird pirate game to dissassemble, dump, scan and ask for help to try to fix a glitch.
But this will have to wait a little more.
Many thanks for the help!!
See you guys later!!
Some evolution of subj bootleg cart. PAL16 instead of 3xTTL.
That's cool!
Does it suffer from slowdowns?
Mine unfortunately does, but I think there's a version with this bug corrected.
I'm not sure if they're compatible.
Fisher wrote:
That's cool!
Does it suffer from slowdowns?
Mine unfortunately does, but I think there's a version with this bug corrected.
I'm not sure if they're compatible.
I haven't this cart yet but seller warned me about slowdowns.
onimush wrote:
Some evolution of subj bootleg cart. PAL16 instead of 3xTTL.
I found this cart,The data on the cart are exactly the same as Fisher's cart.