Glover N64 - Community Dump

I know with EPROMs they can suffer bit rot but that typically isn't seen with anything that isn't as old as a 2600 prototype or maybe some older NES writes. Flash, supposedly, can die in terms of being unwritable but I've been told that it can be read long after that point. Though I usually see something catastrophic such as the chip being physically damaged beyond either before the read/write cycle count is up. Bit flipping is also possible when highly energetic particles nail flash, extremely rare but it can and does happen. Happened recently to the Voyager 2 probe actually.

I'd also like to see olivieryuyu stop with the high school girl level of drama unless some valid and solid evidence can be provided that it is a bad dump. So far I'm seeing nothing but bollocks.

 

I will not continue arguing, it is pretty useless ...

 

The only way to confirm the CRC would be to load the original game and view it under a ram editor or display the CRC directly to screen. However, that said the in-game calculated value is 25414DCA FD553293 and there's no region-specifier. Of course, there's nothing saying that the on-cart CIC in the device isn't calculating based off a different base value. Only the original owner can confirm it, either way.

One very real possibility is that the original cart has suffered data corruption over the years. We all know very well that these EEPROM carts are nowhere near as stable as PROM. If that's the case then we owe a huge thanks to the collector for ensuring this proto's preservation ad infinum. Thankfully nothing especially important was corrupted. Maybe they just changed the name or something. That would throw it off for sure.

Thanks for the public dump! Awesome to see a nifty proto like this.

 

Added to N64 Sound tool (thanks Zoink for finding offsets) Interestingly it has 3 banks, while retail has 2!

 

Thank you.

 

Whilst, like you APE, I'm not too fussed about the dump - I do think Olivieryuyu has a point. He also speaks from experience dumping N64 roms so he isn't pulling this shit out of his ass (so to speak) But more importantly, Olivieryuyu also paid a very large sum of actual money towards this release.

Curiously, you yourself state on page 1 of this thread:"I might contribute IF it has already been properly dumped and this has been given the OK by the upper management."What do you mean by 'dumped properly'? Like I said, it works - and I don't really care - but attacking the very person who made this release possible (with some pretty mean insults) is way out of line.

Oh, and while I'm here Brandon - any chance of an apology for making this one of the worst fund raisers in history? (re-read the thread, if you have just arrived here)

You know, the part where you "spent the donators money before the target had even been reached..." and then pretty much ignored the thread (even though you were visiting the forum quite regularly...) when people had questions that needed answering?

Seriously, it's a fucking miracle Olivieryuyu came along and shelled out the difference - an apology wouldn't hurt.

I also think the mods should take serious note of what happened here - threads like this do NOT inspire confidence in any sort of fund raiser.

 

If Brandon affirms that the cartridge works on hardware, it wouldn't hurt to post photos of the PCB so that donators could see markings on the CIC and whatever else is there.

 

The X-Men prototype released by drx doesn't work on anything but real hardware - didn't see anyone making any accusations towards him. Then again he fronted his own cash and asked $0 for donations so I suppose they don't apply entirely.

My point is that not every situation is identical and experience with dumping doesn't make you an expert on everything dumping. Knowledgeable sure but when the accusations of hiding something that Brandon likely had 0 knowledge of I get a bit defensive as I have been in the same exact situation. Hell, I was there the other week when something I sold someone didn't work. Turned out shipping was harsh on the package and a ribbon came loose but it SUCKS to be accused of something that you have no control over. I appreciate his donation and found it uncharacteristically generous of someone who doesn't post here often though I now see that olivieryuyu is a diehard N64 and prototype fan. I didn't intend to make any insults and you have no idea how many times I reword posts before hitting submit to help ensure I don't insult anyone directly while still making my point. For that I must apologize.

I donated $10 as noted and I still have yet to play this dump. As a college student who has many expenses (gotta move ~250mi by August) $10 is a lot to me, I didn't take the donation lightly and 99% of it was to see it released for preservation purposes.

By 'properly dumped' I mean that it is representative of what is on the actual cartridge. If it is corrupt on the cartridge then we get a dump of that and fix the dump. If this really has a bad checksum on the cartridge itself but plays anyway something must be going on that allows it to play on real hardware. I don't count emulators as real hardware as they use HLE for their purposes and are not anywhere near 100% accurate.

Obviously Brandon didn't handle it as well as he could have but in the end the dump is available, it appears to be functional and we got what we paid for. A bad checksum can easily mean one byte was flipping during dumping and without having a different GameShark using a different version of the firmware using different cables on different computers with different chipsets using different operating systems (or simply using a dedicated backup unit) I'm not too sure how we are going to get a second dump to compare with. I'd personally like to know for posterity that we have the best we are going to get here even if it is corrupt somewhere that we can't see or even tell. That is how the cookie crumbles with prototypes - look at Geist Force and the fact it crashses on the first level right before the boss. We can fix that but even if we can't I wouldn't write the entire project off as a loss.

 

All I know is when I'm on my death bed I won't be thinking about that dreadful CRC that wasn't correct for a game that regardless was still perfectly playable.

It may be exaggerated, but when you put into perspective like that you realize crap like this isn't anything to worry about. A prototype got released, and I'd be so glad. Hell, if Shenmue for Saturn was out and god forbid there were a couple of letters in the game that weren't the 100% original for historical purposes, I'd still be so damn glad the actual game is out.

I love playing games, not looking deep into them for their numbers that will never have an affect on my life :x

 

Well, I'd expect many of you like myself do have multiple and differing backup devices.
If it does operate fine with the original media despite having an invalid checksum, that would be something really interesting to look into.

You have a very good point though. Emulation means squat. Sub and I have written plenty of ROMs that don't work on hardware for obscure reasons ;*)
Just as a case for argument, that first word in ROM sets the PI so it can properly read the media. If it happens to differ from the usual, not only will it not work on backup devices but most emulators won't accept it either. In actual fact, the value would be right but would require being changed only to operate on existing hardware. If changed, the checksum requires recalculation. Does that mean the 'fixed' ROM is inaccurate to the original? Not really. Headers are the absolute least important part of the whole ROM for preservation, though relatively important to get the buggers running.

Just narrowing down where an error would be, obviously the bootstrap is fine. Bootcode initializing the game is comparable to retail (address offsets generally offset), and none of the standard libraries seem erroneous. So, all the uncompressed ASM should be okay. From there are floats and strings for resources contained elsewhere in the ROM. None seem wildly erroneous compared to retail, and a damaged float outside the first five bits wouldn't matter anyway. There aren't any wild deviations between included resources in proto vs final. Obviously no pointer arrays are corrupted or some kind of error would occur. The calculated region ends with compressed files, these being LZSS-derivatives. An error in files would be very noticable. A written byte would be the least terrifying error, but any error in a copy pair or heaven forbid command byte would pretty much fry the file. You'd either have garbage or an error/crash.

Since no actual serious errors have been reported it might as well be assumed a good-ish dump with a weird checksum.

Oh, incidentally, the files are in triplicate. That seems to happen a lot with demo carts. Actual end is 0x67C000.

 

Sure, it's inaccurate to the original, it's been modified to run on not-so-accurate backup devices/emulators. The latter should have been fixed instead.
By the way, has this situation ever happened? Were there any cartridges that had unusual PI timings set by the 1st 32-bit value in the rom header?

 

The credits list is pretty short, but it says Darren Wood is the team leader and he's listed on pretty much every section of the credits. I tried to find him on twitter or something to ask him questions but I couldn't, lol.

 

Guys, just a thought, being on a devcart, is it not possible that the cart is designed to correct crc errors itself for the purposes of testing?

 

Guys, just a thought, being on a devcart, is it not possible that the cart is designed to correct crc errors itself for the purposes of testing?