Path: chuka.playstation.co.uk!news
From: James Russell <James_Russell@scee.sony.co.uk>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: I can't stand it anymore!
Date: Wed, 03 Jun 1998 11:46:29 +0100
Organization: Sony Computer Entertainment Europe
Lines: 43
Message-ID: <35752985.950BC4E8@scee.sony.co.uk>
References: <35736e0f.13097051@news.scea.sony.com>
NNTP-Posting-Host: camfw01.millennium.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.05 [en] (Win95; I)

Antony Arciuolo wrote:
> 
> Now I'm trying to put other code back in, and I finally think I
> figured out what was wrong... It seems that the allocation of all
> those ordering tables is OVERWRITING the data of the TIM files! I
> can't come up with any other explanation!
> 

When you make an executable, it consists of at least 3 sections:
The text section is the machine code.
The data section is initialised data.
The bss section is uninitialised data. Since it is uninitialised (ie,
zero),
the executable file format just stores the length of the bss section
rather
than all those zeros, to save space in the file. But when you load the
file
into memory, the OS 'expands' the bss section into its full size.

So even though your program on disk may be 10,000 bytes, in reality
it could be 100,000. The way to find out how big the different sections
are, generate a MAP file (the compiler can do this) when you compile
your code. The MAP file details what is in each section, and how big
each section is.

If you're loading your TIM is 0x800A0000 and then your program to
0x80090000, and your program is over 0x10000 bytes long, then it will
wipe over the start of the TIM. The solution is to load the TIM to
a higher address.

> How do you load files into main memory
> and prevent them from being overwritten by the code allocating memory?

When I'm developing, I convert all my source files to C (using a little
program I wrote myself). This C file looks something like
"char myRawTIM[] = { 0x50, 0x33,...".
I can either #include it or compile it as an object file and link it
in. Then I don't have to worry about the program wiping over it, because
it's now part of the program.

Cheers,

James