Was Color A Dinosaur written in C? (No wait, it's Norton 7?)
Moderator: Moderators
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
One thing that I think could help is a CDL from a complete playthrough.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
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.
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
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.tepples wrote:One thing that I think could help is a CDL from a complete playthrough.
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".
Code: Select all
Omit option EXP or upgrade your Expanded$s01Memory Manager..Norton Cache canno
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
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
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.BillyWM wrote: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.
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
Woops, I didn't even notice BootGood's DB had those. Thanks!NovaSquirrel wrote: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.BillyWM wrote: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.
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
This is incredible.rainwarrior wrote:It's not all that uncommon a phenomenon.
Here's another example:
https://tcrf.net/DynaMike
Re: Was Color A Dinosaur written in C? (No wait, it's Norton
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.
* 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.