Anyone has a real NTSC Incredible Crash Test Dummies cart?

Might as well try here too (viewtopic.php?f=3&t=10340&start=15#p116021).

If anyone has one and can display all of the screen horizontally, it would be interesting to know if you get a flickering glitch on the right side of the title screen. I know it appears on PowerPak, but I'm not sure if that's correct.

If no one who has this cart responds within the next few days, I'll get the actual cart and test things out myself. I can adjust H-size on my TV/CRT as well to rule out any possibility of glitching being hidden by plastic borders.

Thanks in advance.

And since this is general stuff, Incredible Crash Test Dummies is probably one of the better LJN games - which is to say, very mediocre, but not terrible at least . The music's pretty nice too.

I wonder what the best game LJN made is...

LJN never made anything. Their games were made by Atlus, Rare, Beam Software, Sculptured software, and Software Creations. Software Creations was the cooler company because they employed Tim and Geoff Follin.
Software Creations made Incredible Crash Test Dummies.

Oh, didn't know they weren't their own development house. Most of those studios were probably pretty crap then.

Atlus, Rare and Software Creations made pretty good games I think. So I'd guess the people behind the crappy games are Beam Software and Sculpured Software ?

Beam made the SNES Shadowrun and JVC's Star Wars. Sculptured didn't produce anything I recognize as noteworthy, though.

Sculptured did a good version of Monopoly. Even though the AI behaves so consistently. They have trade dollar values for every situation, such as two properties with third unowned, getting or giving a monopoly, etc. They can also be exploited in a one-on-one game, sell all your properties to the AI so they have no money, then auction all property really cheap.

Sculptured Software's music engine also ended up in Action 52.

Where does "Test" appear in the title of The Incredible Crash Dummies? Do you have a prototype or something that had "test" on the label?

I hear "Crash Test Dummies" and think of "Mmm Mmm Mmm Mmm". But actually I think of "Headline News" by "Weird Al" Yankovic.

I think I lumped them together. But yeah, no 'test'.

I've always thought Test was in there. I remember the TV show too! I always called it Crash Test Dummies back then. Weird.

That's what I call being supportive. <Good guy koitsu>

Sometimes you just gotta take one for the team. ;P In this case it's not much effort though, considering 1) I have both original (unmodded) top-loader and front-loader NES consoles, 2) I have an adjustable CRT (yay service technician mode), and 3) I just bought the cart off eBay for US$4.67 (and that includes S/H). Plus, if someone in the US wants to do further analysis of it, I can always mail 'em the cart for cheap. :-)

Ah... taking one for the team.
Like that time I disassembled my Miracle Piano, then had a hell of a time putting it back together. Damn volume LEDs having to fit into such small holes at a slanted angle.

Ahh, just realized something... This cart (atleast the NTSC version) isn't actually Nintendo's MMC3. It's acclaim's copy cat: bootgod... The Scandiavian version is accliam's copy cat, but the German The PAL versions are TLROM original Nintendo mapper though. Both of those pal versions are the same rom too (checksum)

EDIT: The way bootgod's flags flip around threw me for a loop when I was clicking.

The acclaim copy cat may very well have a slight difference in the scanline counter...

My original mmc3 dev board does appear broken ... I was going to test it out in the official mmc3 and see how it does. I probed around looking for broke traces and couldn't find anything either. I probably fried the thing.

I did test it on my hardware implementation of the mmc3 and the words on the bottom of the title screen were jumpy similar to what it sounds like the everdrive is doing. But even if the acclaim mmc3 doesn't do this I don't feel so bad, since it may be acclaim's variant that's behaving differently. I might make another original mmc3 devcart though to see how the official mmc3 behaves.

EDIT: I do own WWF steel cage which is the same chip, but different board. If there isn't any glitching with koitsu's cart I can break out my logic analyzer and/or oscope to try and see if I can measure any difference between the MC-ACC and MMC3's IRQ's.

What are you talking about ? Both the swedish and german versions use a genuine MMC3.
No PAL carts were ever released with 3rd party PCBs in them, nor 3rd party chips EXEPT two FME-7 games which still uses PCBs made by Nintendo instead of Sunsoft.

PS : It's good to see bootgod's database is up again. It has been down for a couple of days.
PPS : Err no... it appears it's blocked at my work I don't know why...

My bad, the flags were moving around different that I realized...

Yes, the PAL versions are official Nintendo MMC3 TLROM.

Some more IRQ delay would make the jumpiness go away I think, so would be interesting. Do you get flickering on the right side of the screen btw (provided you can see all of it)?

I didn't notice any flickering on the right side of the screen, but perhaps it's cut off?

All I really see is the bottom half of the screen jumps up and down a scanline every couple frames or so. Just to be clear, this is my 'replica' of the MMC3 that I've created so take my data with that test with a grain of salt. Although if I got real curious I could modify my mmc3 to delay the IRQ by a CPU cycle and see what happens.

Tengen's RAMBO-1 has a very similar counter mode to the MMC3. There is a slight difference in timing of the IRQ assertion. Disch claims ~5 PPU dots (1-2 CPU cycles) Perhaps Acclaim's has some similar delay but perhaps not as long. Not giving the RAMBO-1 the proper delay in IRQ firing causes jumping as noted by Disch.

Yeah, I get the same thing in my emulator, along with the top of the scrolling text being messed up while it jumps. Introducing >= ~3 PPU ticks of delay before the IRQ fires fixes it. I've implemented (what I think is) the correct polling points for interrupts, so it shouldn't be that (though it's possible that I've messed up somewhere of course).

Got the cart today. Didn't work in either my top-loader or my front-loader until I cleaned the cart contacts (talk about dirty!).

I don't see any lines or oddities on the right edge of the screen during the intro, title screen, or during gameplay. I tested on both consoles. I also adjusted the HPOS and HSIZ params on my Sony KV-13FS100 so that I could see as much as possible on the right edge -- nada. All looks clear/good, no lines or gobbledegook.

I did take a video of it all (roughly 7.5 minutes) in case that's needed for verification -- quality is not very good (sharp) since my camera doesn't allow for focus adjustment during video recording. Let me know if I should upload it (Youtube).

If you think my CRT might not be displaying part of the video signal, review the Service Manual (Section 4) and tell me what params I should adjust/change.

P.S. -- I do own a PowerPak if you'd like me to try the ROM out on that. I believe mine has loopy's mapper set/code.

Neat, thanks a lot!

For reference, the image below is what it looked like when Pasky tried it out on PowerPak. You could check if you get the same thing to see if you're displaying enough of the screen I guess. On other screens you get an even bigger gray flashing thing on the right.

In my emu, on Everdrive, and on infiniteneslives' MMC3 implementation you get jumpiness and (I'm guessing, since that's what I get) some minor flashing on the right, which would make sense with what's going on. So either those three are broken (not sure what's going on with PowerPak - it's weird) or there's something different about Acclaim's MMC3 chip. The IRQ firing slightly later would make sense, since that seems to fix it.

Anyone with an Acclaim MMC3 chip (http://bootgod.dyndns.org:7777/search.p ... AIM-MC-ACC) willing to do some measurements? Mickey's Safari in Letterland is another game with the same chip that has jumpiness (in Nestopia and my emu - and hopefully not on the real thing).

Can/will do. What mapper set is being used on your Powerpak (stock ones from Bunnyboy vs. loopy's) matters here, I'm fairly certain, so we should disclose what we're using exactly.

I appreciate what you uploaded -- that really helps me to know what to look for. Nope, wasn't seeing anything like that. That almost looks like the gobbledegook seen in The Guardian Legend (where the screen splits), which I think is related to sprite #0 (going off memory here, could be wrong).

Also, just for shits and giggles, I uploaded the full video to Youtube. It's about 7:40 long, since I adjust the CRT and show all of what I'm doing. Parts that you'll be interested in (shots relevant to what you uploaded) are at 1:05, 2:05, and 5:50. The rest is more or less just me futzing around. Again sorry for the video quality, my camera is just a simple point-and-shoot.

I'll bust out the PowerPak and report back. I'll try to figure out what exact mapper set (zip, etc.) I'm using as well (certain it's loopy's, just not sure what "revision" (if there is one)).

Looks like what happens when you write to the palette in the middle of the screen. You can see the overscan color change as you write to the palette. You can even see it in The Nerd's review of Back to the Future.

Here's my follow-up:

I do see issues when running this game under a PowerPak.

I tested 3 mapper sets, each with 5 Crash Dummies ROMs, so a total of 15 tests. All 3 mapper sets had the same issue with the same ROMs, so effectively there's no functional difference between the mapper sets WRT this game. The mapper sets I tested:

- POWERPAK134105.zip -- "Base/stock" RetroUSB PowerPak set, v1.34
- powerpak_loopy.zip -- circa 2010 sometime -- definitely differs from the below
- powerpak_loopy.zip -- 2011-11-17 (according to loopy's site), i.e. the most recent set as of this writing

And the ROMs w/ their results:

- Incredible Crash Dummies, The (U) [!p].nes -- issue described below
- Incredible Crash Dummies, The (U) [b1].nes -- issue described below
- Incredible Crash Dummies, The (U) [b2].nes -- issue described below
- Incredible Crash Dummies, The (U) [b3].nes -- issue described below + bad graphics/audio
- Incredible Crash Dummies, The (U) [o1].nes -- issue described below

Note that none of the ROMs have (!) in their name, which according to the GoodNES docs indicates a ROM that is absolutely correct/confirmed not to have any dumping-related errors.

Now, the issue I see is this:

- Screens with a text scroller have a 1-pixel-height line of gobbledegook that flashes right above the scrolling text. Width of the line is about 2/3rds of the screen
- Screens with "static text" (text beneath an image), including those which also have the text scroller, will have the entire block of static text "jostle" or "jiggle". The text appears to shift upwards 1 horizontal row
- Gobbledegook above scroller and jiggling text happens "most" of the time, but not always -- sometimes after a "full screen transition" it won't happen. It isn't specific to any particular screen, it really is like it's random
- Still graphics at the top of the screen (the dummies, logo, etc.) do not ever jostle or have issues
- I do not see a "blotch" on the centre-right of the screen, or anywhere else

Two videos I made in the process showing the behaviour -- again, sorry for the quality, not much I can do about it given the wonderful design of my camera...

- http://www.youtube.com/watch?v=lL-e_HP7qTc
- http://www.youtube.com/watch?v=eyi-lQP1vRM

Too bad I don't own a capture card.

My gut feeling is that the game is either doing mid-screen PPU writes and either taking too long at some points, or (more likely) botching the address that the internal part of the PPU needs to have to "properly" (i.e. no glitching) resume where it was drawing. I think the "blotch" you're seeing is probably the same thing.

Dwedit's explanation seems most likely, but it could also be something like what I said. Mid-screen PPU updates are always tricky. What I can't explain (because I'm not an EE guy or fully understand the hardware) is why this would happen only on a PowerPak.

And I can't dump the mask ROMs because my programmer/dumper is from the late 90s thus parallel-based. *grumbles* :P

Can you check Mickey's Safari in Letterland on the PowerPak? Any status bar glitches (look for shaking, shaking while jumping, or skipped lines)?

If I recall correctly, I was able to fix these issues by implementing cycle-accurate IRQ handling, so I'm curious to see how it looks with the PowerPak's MMC3 implementation.

Thanks

I can try, maybe poke about in the game a bit, it helps if I know areas which are known to use the IRQ counter though. Else I'm just like "Looks fine to me! {never played this before, WTF am I doing}" :D

Thanks for those videos. Shows it clearly enough.

The glitching on PowerPak is just what I get in my emulator. Might be a generic MMC3 timing issue, but the only games that act up so far are Crash Dummies and that Mickey game, which both use use the Acclaim chip (granted, I haven't tried out hundreds of different MMC3 games yet). The glitch is timing-dependent, and caused by the game disabling/enabling rendering right around dot 256 on certain scanlines, where the vertical nametable position is bumped if rendering is enabled. If rendering is disabled too late or enabled too early, you get an extra vertical bump, which causes the graphics below that point to move up one scanline and messes up the top line of the text (since it no longer appears where the game thinks it will).

Re. River City Ransom, I think the composite PPU draws thin borders around the picture. Those would be the "left border" and "right border" in http://wiki.nesdev.com/w/index.php/NTSC_video.

So either something is different about the Acclaim MMC3, or the timing is just so tight that lots of different things get it wrong. I have implemented what I think are the proper IRQ polling points in my emulator (which fixed shaking in Magician), though bugs are possible of course.

In Mickey's Safari in Letterland the status bar only shakes while the screen moves vertically. Where it "settles" seems to depend on the current vertical scroll as well (same thing in Nestopia).

"Du kan dricka" means "you can drink" in Swedish btw, just in case you weren't aware of that.

Is the source code for the PowerPak mappers available anywhere btw?

If I had to guess I'd say it'd be timing-related and not so much related to MMC3 or Acclaim's variant (unless these games are using the IRQ counter and basing their timing/behaviour off that), else I don't know how the mapper chip could somehow "affect timing" in the way we're discussing.

Your theory about the thin borders makes sense.

And yeah, I know what du kan dricka means. I got it from watching Jönssonligan. :D

Not sure about the PowerPak mapper source code; loopy may have insights into that.

So I tested out Mickey's Safari in Letterland -- specifically these two ROMs:

- Mickey's Safari in Letterland (U) [!p].nes
- Mickey's Safari in Letterland (U) [o1].nes

The behaviour on the PowerPak (testing with loopy's 2011-11-17 mapper set) is as ulfalizer described above:


I see no other anomalies.

The games are most certainly doing that, and the mapper can most certainly affect the IRQ timing.

The only other thing the mapper controls is bankswitching/mirroring. There isn't much room for bankswitching/mirroring to control issues like this.

IRQ's are the only plausible issue, especially since ulfalizer's emulator fixes the issue by delaying IRQs...

Then in that case the only way I know that someone can figure this out is to get their hands on actual carts and use an oscilloscope in some way (beyond my skill set) to determine the timing. I'm happy to send the Crash Dummies cart I have off to someone here in the States if they take up the task.

I wouldn't mind taking this on. I've been looking for an excuse to do some hardware analysis/experimentation.

Nintendulator shows the junk at the right side of the title screen, as well as the junk at the right side before the text appears.

Yeah, got the same thing on Pasky's PowerPak for some reason (not sure what mapper set it's using). Any shaking? Could you compare against Nestopia (which doesn't shake) and see if the text and in-game status bar are shifted by one pixel relative to Nintendulator? I don't have a Windows install atm.

Jönssonligan... nostalgia... didn't think anyone outside of Sweden had seen those movies.

I used to have pirate Letterland and I recall it shaking on some clones and not on others, I did not have real hardware at that time. I may have the cartridge somewhere...

IRQ is being asserted on the falling edge of A12 instead of the rising edge, so it occurs 4 PPU cycles later compared to MMC3.



I've implemented this behavior in my emulator and the game is working correctly now. Oh, and I did see the garbage on the right hand side of the screen while testing.

Yay!!! Nice work James and Koitsu for prying this guy open and figuring out what makes him tick!

Question is how one would go about documenting this and communicating it to an emu. I suppose iNES 2.0 MMC3 variant is the way to go?

I actually didn't do anything (meaning I didn't send James my cart -- nobody actually told me to, nor gave me an address, thus I did nothing. :-) ).

Nice find. Now the problem -- and it is a problem -- of documenting this behaviour comes into play.

http://wiki.nesdev.com/w/index.php/MMC3
- Needs to have its Hardware section updated (states there is no difference in the Acclaim chip (we now know that's wrong), and the paragraph after that is also wrong WRT that chip)

http://wiki.nesdev.com/w/index.php/INES_Mapper_004
- I'm not sure what should go here. Something probably should. I really do not like how the mapper documentation is "spread all over the place" like this, i.e. MMC3 wiki page has some info, INES_Mapper_004 page has other info, etc..***

http://wiki.nesdev.com/w/index.php/RAMBO-1
http://wiki.nesdev.com/w/index.php/INES_Mapper_064
- Probably needs reinvestigation to see what its timing behaviour is like
- Be sure to see the "IRQ counter operation" section, note the "blah blah 5 pixels later" part -- like I said, needs investigation

http://wiki.nesdev.com/w/index.php/INES_Mapper_076
- Same situation as RAMBO-1 and INES_Mapper_064

And no need for Mapper 206 stuff to get updated, as supposedly those chips (Tengen MIMIC-1 and Namcot 118) lack IRQ.

I have not the slightest idea how to solve this from an emulator perspective. I imagine a ROM hash database and so on is really the only way, similar to how people differentiate between MMC3A and MMC3B and other chips. If you ask me, this warrants a separate mapper number; ex. "for the Acclaim MC-ACC chip, the behaviour is almost identical to that of a real MMC3, except for the following: * scanline IRQ generation happens on the falling edge of A12 (real MMC3 keys off rising edge), so IRQ generation happens 4 cycles later than on a real MMC3".

*** -- I imagine this confuses the hell out of a lot of people. People update one but not the other, blah blah blah. All the Disch mapper docs stuff should really just be put into a single page and section-ised, where notes can be added within each section (outside of the <pre> content). Likewise I should probably spend some time looking at the Infobox wiki template so that each chip could have an Infobox that lists off the relevant iNES mapper numbers that use the chip. (If you don't know what an Infobox is, it's the little box on the right side of pages that lists off some summarised info; example (Developer, Publisher, Designer, etc.)).

Funny that you should mention this, because I've already bought a Klax cart off of ebay to investigate

Nice work James and others.

I also agree that some of the mapper docs are a bit of a maze with copy paste and scattered information (looked at MMC2 and MMC4 today for exmaple, and imo those should be on the same page, just pointing out the slight differences between them). Judging from viewtopic.php?f=3&t=10275, Disch wouldn't have any problem with information from his docs being changed or integrated into other pages btw.

You can thank me for militating against the separate pages for TLROM, TSROM, TNROM, ... and mapper info replicated on all of them.

I am reviving this old thread because I am wondering whether Incredible Crash Test Dummies really should have jumpy opening text or not with an accurate MMC3C scanline counter. I have tested the NTSC ROM, modified to replace one FF byte in a long series of FF bytes at the end of a bank with FE to foil any potential CRC-based adjustments and thus force normal MMC3C behavior, with several emulators as well as the Everdrive N8 v16 firmware, and while it is jumpy in a few of them (Mesen, BizHawk), it is not jumpy in puNES, Nestopia and on the Everdrive N8 v16.

My interest is actually the effect of delaying the change of rendering status via $2001 write --- if I apply the change of rendering status in NintendulatorNRS immediately, then the text is jumpy, while if I delay it by one PPU cycle, as several games such as Micro Machines require, it no longer is. I am not disputing that the ACC-MCC also triggers IRQs later, as found out, but am wondering what exactly the effects will be with this NTSC version of the game when run on a normal MMC3C. Ideally, somebody would run the game on a real MMC3C devcart, to avoid any inaccuracies from ever-so-slightly off flashcart MMC3C scanline counters.

Sorry for drifting this away a bit, but as the subject line is now truncated to:
Re: Anyone has a real NTSC Incredible Crash Test Dummies car
I had hard time figuring out what this thread was about. How can a car be NTSC? Is there a PAL or SECAM car?
(Considering the fact that 'car' matches Crash Dummies a lot I initially didn't realise it was a truncated word.)
Had a smile after realising what happened.

i have a mmc3c socketed cart for testing. the text on the opening screens is jumpy. here's a test run:

https://twitter.com/FrankWDoom/status/1 ... 9824610309

(sorry, don't know a better way to post a video here)

recorded on a crt on an original nes (has a copynes installed but i don't think that matters)

Thank-you very much for that video. That means that the Everdrive N8's MMC3 scanline counter is not completely accurate.

Now the challenge for me will be to implement the delayed rendering change in a way that gets its desired effect of preventing glitches in Micro Machines while keeping the jumpy text in Crash Dummies when emulated with MMC3C instead of MC-ACC.

This video https://www.youtube.com/watch?v=8x5IHXsJ2js was almost certainly taken with a real cartridge and shows "some jumpiness", but not as much as in FrankWDoom's video.

I'm sorry that I couldn't help more on this issue (considering it's 5 years old) -- I've since sold all of my NES carts. Also, the YouTube videos in questions were lost during some clean-up I did. Again, sorry that I couldn't help more or re-do the tests (especially since I now have a 1080p 60fps digital camera).

This is because you can't force N8 to use regular MMC by changing byte in the end of rom. Full rom CRC calculation is too slow for handling on system CPU, instead N8 used few bytes checks in certain rom area for specific rom detection. With regular MMC3 screen shakes will back.

Ah, interesting. I had no way of knowing.

Would it be possible to add NES 2.0 Submappers to properly differentiate between mapper variants, and limit such checks to ROMs with no NES 2.0 header?

Actually i thinking about including nes 2.0 support

I did a small research around acclaim mapper. Seems like besides of neg edge triggering it ignores a12 if rendering turning off, also it expects a12 to be in low state more than two cpu cycles. As we know problems with Crash Dummies on regular MMC3 related to edge of a12 triggering, but with Mickey's Safari in Letterland is another story. It also shakes menu bar on regular mmc3, but not due the triggering edge of a12 , it happens if a12 clocking hits to the mement when PPU turn off the rendering. On attached screenshots shown such moment. Red color shown when ppu turned off and yelow dots shown false triggering which counted by MMC3 logic and ignored by MC-ACC.
However, i not sure how exactly MC-ACC ignores those cycles during turned off PPU, because it does not have enough connected address lines to decode PPU registers addresses and intercept writes to $2001, may be it require specific timings between A12 clocking or something

EDIT:
Ok, seems like i figure out how it working. Acclaim mapper counts every A12 pulse instead of waiting for long phase in low state. Counter clocking happens once per 8 A12 cycles at first cycle. Writing to $C001 resets pulse counter. On attached screenshot shown how real acclaim chip triggers IRQ not at first A12 pulse. Also i looked at few emulators and they all emulate this behavior incorrectly. In Mickey emulators fires second IRQ too early. It easy to check: With proper timings in bottom bar should be two lines between "in" and "letterland", but emulators have only one line. Also those 3 black boxes in right side of bar should have size 8x8 pixels, but emulators likely will render them 8x7

This recording, which I believe to be from real hardware based on the line on the left and the buzzing sound in the audio, although none too clear, seems to show only one line between "in" and "letterland".

"Unfiltered PA12 rise (or fall) with prescaler" would mean that the AC-MCC's scanline counter acts more like the J.Y. Company ASIC's.

This video for sure recorded not from MC-ACC cart. Besides of lost line, bottom bar shakes time to time. I have real Mickey cartridge and it shows two lines and no shakes

What did the author of that video record it from, in 2007? The console seems to be real, but maybe the cartridge is not. Was the PowerPak available back then?

Anyway, this video shows two scanlines, also ostensibly from real hardware.

Which chip do you mean by `AC-MCC`?
The DIP40-60 with non-standard pinout, called "AX5202P #2 (NTDEC?)" there?:
http://wiki.nesdev.com/w/index.php/MMC3_pinout

Just curious, because I loved to use the game `Doki Doki Yuuenchi` (which uses this chip) for testing consoles. It uses scanline counter twice on title screen, when the curtain drops. And this cartridge never caused any trouble on any console, but implementing this particular game to work correctly on hardware was tricky.

-

Second game that always bothered my mind was pirate japan Panic Restaurant (Wanpaku Kokkun no Gourmet World). On real hardware, when entering the Bonus Stage, there is weird split in half of screen that makes finishing impossible:
https://www.youtube.com/watch?v=D27STQYSigQ

However, when dumped and played in emulator, it works:
https://www.youtube.com/watch?v=LK-xnARVnLI

Except that, game works fine. I've already soldered 220pf between PPU-A12 and GND thinking it might help, but nope.

The Acclaim MMC3 clone, used on licensed U.S. cartridges. Nothing to do with any AX5202 chips.