It is currently Fri Sep 22, 2017 10:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Sun Mar 12, 2017 12:03 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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".
Attachment:
File comment: printf style formatting of strings in Color A Dinosaur
color_a_dinosaur_c.png
color_a_dinosaur_c.png [ 23.57 KiB | Viewed 1478 times ]


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


Last edited by rainwarrior on Sun Mar 12, 2017 1:15 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 12:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19003
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 12:49 pm 
Offline

Joined: Fri May 13, 2011 7:36 pm
Posts: 143
Random garbage leftover in RAM when they assembled it maybe?


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 12:50 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2945
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 3:47 pm 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 218
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".

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 4:35 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 909
Location: Japan
Punch wrote:
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.

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!

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 6:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
thefox wrote:
I guess some old tools tried to be clever with optimizations by not clearing unused memory, or only writing disk sectors partially.

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.


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 7:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19003
Location: NE Indiana, USA (NTSC)
And perhaps then, Symantec wasn't quite as litigious as some companies are nowadays.


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 8:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
tepples wrote:
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?


Top
 Profile  
 
PostPosted: Mon Mar 13, 2017 9:18 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 571
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Thu Mar 16, 2017 8:47 pm 
Offline
User avatar

Joined: Sun Dec 13, 2009 11:37 am
Posts: 207
Location: Wisconsin
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.


Top
 Profile  
 
PostPosted: Fri Mar 17, 2017 4:03 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
'm gonna expect t was more a tape reuse deal.


Top
 Profile  
 
PostPosted: Fri Mar 17, 2017 10:27 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6178
Location: Seattle
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group