Was Color A Dinosaur written in C? (No wait, it's Norton 7?)

By chance discovered some printf style string formatting in Color A Dinosaur. There's a lot of text in there that is relevant to DOS/PC implementations too, which is kind of interesting because I don't think it got a DOS release? Anyhow, just another one to add to the list of "might have been written in C".


Edit: Altaz on #nesdev clued me in that this has a TCRF entry: https://tcrf.net/Color_a_Dinosaur

Apparently it's a piece of Norton Utilities 7? O_o

I'm immediately reminded of "You can't hack me; I got Norton." I wonder if any ROM hackers are up to the challenge of putting a picture related to the "I got Norton" meme (ED; KYM) into the game.

Random garbage leftover in RAM when they assembled it maybe?

There are some other games which have pieces of random leftover data from the disk (or memory?) in their ROM. I can't name any of the top off my head, but IIRC TCRF should have a few of them (I think one of them had pieces of the game source code). I guess some old tools tried to be clever with optimizations by not clearing unused memory, or only writing disk sectors partially.

From 1989 onwards the PC Engine had a CDROM attachment, and since 650 mb was an absurd amount of space back then, the PCE CD devkit was a expensive combo of a PC9801VX with a 620 mb HDD and a 8mm master tape unit plus the Hu7 system which was a regular PC Engine with a huge hardware CD emulation board connected into it. http://i.imgur.com/pqofNGI.png (edit: video of the Hu7 unit: https://www.youtube.com/watch?v=ge9aFCnx5tw)

So what? Well apparently some developers also used the 620mb disk to act as a server for their source code or something like that, because there's an almost complete copy of the original SNK Neo-Geo source code for Art of Fighting stuffed inside the PCE port's retail CDs. Talk about "random leftover data".

Sorry to go further off-topic, but you can see how expensive it was back in the '80s here: http://www.chrismcovell.com/secret/PCE_ ... tml#pcedev ... $144,000!

Actually, if I think about an assembler that needs to output to very slow drive (e.g. tape storage), maybe not clearing unused memory could be a huge time saving on iterations, especially early on in a project when a ROM isn't very full.

An optimization like that which makes little sense now might have been essential on the hardware it was originally written for, and could easily have persisted into the next era where it was no longer necessary.

And perhaps then, Symantec wasn't quite as litigious as some companies are nowadays.

I think it's probably more to do with them not being omniscient?

When you create a file and write a single byte to say 1MB point, the stuff between first byte and the last one is filled with whatever was on the sectors on the HDD that the new file got assigned. Windows NT explicitly zero's out new memory and files, but DOS and Win9x do not.

I'm also trying to think why this junk gets into rom images.

Perhaps the tool that ultimately creates the rom image declares one large chunk of RAM, but never bothers to zero or $FF it.
The system RAM on the host computer of course contains data from other programs that were loaded into its RAM previously.
The tool creating the rom image goes from bank to bank, and just stops copying early if the source data for that bank does not completely fill it.
Ending earlier at the bank of course leaves the previous data there.

When done, the entire chunk of RAM is copied to the rom image file, that is later sent to the EPROM writer or onto a floppy disk.

Otherwise I can't fathom that one would copy raw sectors from a storage disk-- it seems like more effort to read raw sectors than read and write from the filestream.

'm gonna expect t was more a tape reuse deal.

I definitely remember writing programs in C, compiled with Borland Turbo C++ v3.0, running in x86 real mode under DOS, and allocating memory using malloc (which makes no guarantees about the contents of the memory when allocated, unlike calloc) and finding random crap in the allocated memory blocks.

To me, it feels like a safe assumption that this is the entire cause.

I thought this was a joke entry (like "Uncyclopedia" does) when I saw it recently, but that seemed out of character for TCRF. Then I opened my hex editor and had a good laugh. Wow, it's real.

I wonder if, for similar reasons to those stated above, this could be an artifact of the dumping process (random chunks of the dumper's harddrive sectors or RAM contents). Who knows what silly copying techniques people used when they first dumped this probably 20 years ago?

Well, I'm not gonna be the one to go to Ebay and play repro-roulette at $100 a cart to get a verified dump. I did ping @JayObernolte on Twitter trying to get some info.

I believe you are mistaken, BillyWM.

It's not a "bad dump", like somone making a recent copy screwed up.

In my opinion, it's a build (by the original producers) that didn't zero the contents of its memories it was using (reusing), and just left whatever contents were there. And copied it in entirety onto the original ROM.

There's no reason to believe it won't play correctly.

One thing that I think could help is a CDL from a complete playthrough.

It's not all that uncommon a phenomenon.

Here's another example:
https://tcrf.net/DynaMike

To be clear, I think the previous suggestions are most likely. I just think the bad dump scenario shouldn't be overlooked, as it's possible for e.g. badly written DOS dumping drivers from 1997 to copy random chunks of memory to the output.



I was curious and did end up doing this. It's probably RAM contents. Norton probably runs as a TSR and it got swept up in the dump.

It looks like it got two separate pieces of Norton. One chunk is this "NDOS" utility which the Internet says is a Symantec-licensed fork of 4DOS. It's a tool for a fancier command line. The other is Norton Cache, a disk accelerator.

There's actually more Norton in the first 32KB and it gets cut off exactly at the 0x8000 mark. There's a lot of empty space and only ~4KB of code. Most of the time the game doesn't read data anywhere near Norton, but 0x7C80 it reads a stray byte dangerously close to the text "SET UNINSTALL SAVE DUMP".



The data could have gotten there from a graphics utility, maybe even one Obernolte wrote himself. Maybe it saved in ROM-friendly format by just dumping a whole 16KB/32KB chunk of RAM to disk.

Definitely doesn't look like a bad dump though since the game code reads close to it at one point, in the same bank. You guys were right

NesCartDB already has a verified CRC32, and it matches that of a ROM I just downloaded that has all the Norton stuff intact. I think bad dump can be ruled out.

Woops, I didn't even notice BootGood's DB had those. Thanks!

This is incredible.

The data format used by Color A Dinosaur is really quite simple:

* 16 KiB pages 0-4 (but not 5,6, or 7) start with a bus conflict prevention table
* Each dinosaur is stored as:
** a 32×30 uncompressed nametable without an attribute table
** One byte for the number of pattern table tiles in this dinosaur
** That number of uncompressed 1bpp 8x8 tiles (i.e. 8× that number of bytes)
** A zero byte (not clear why)
** Some number of X,Y coordinates ... upper left corner of each region's bounding box? maybe?
** Two bytes
** Lower right corner X,Y coordinates maybe?
** Two bytes


Pages 0-2 each contain five coloring sheets. Page 3 contains one. Page 4 contains the copyright screen. Pages 5 and 6 are completely empty.

The entire code is only about 6 KiB, starting at the beginning ($C000) of the fixed bank. Everything else is padding or data. (Most of the ROM is padding; there's less than 64 KiB of actual contents here)

The fixed bank (7) contains two more coloring sheets—the title screen and selector screen—that mayn't be filled out.

It looks like it would be really quite easy to replace the graphics data. The only real restriction is that whatever's there has to fit in 255 tiles.