Path: chuka.playstation.co.uk!news
From: Craig Graham <c_graham@hinge.mistral.co.uk>
Newsgroups: scee.yaroze.programming.codewarrior
Subject: Re: MWDebugIO
Date: Wed, 01 Jul 1998 16:20:30 +0100
Organization: Intelligent Research
Lines: 45
Message-ID: <359A53BE.2F04B837@hinge.mistral.co.uk>
References: <359A3B82.2267A83D@easynet.co.uk> <359A43E3.CD8101E3@hinge.mistral.co.uk> <359A4F13.6927AD1A@easynet.co.uk>
NNTP-Posting-Host: 194.131.235.3
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.03 [en] (Win95; I)

Philip Gooch wrote:

> Thanks Craig. And if storing my TIM as static data in an array (using Steve
> Dunn's bin2hex program), how can I free up the memory taken up by the array
> afterwards?

Tricky. Probably not possible without some fine control over the linker.
It's possible the other way because the TIM's were positioned beyond the end
of the area that the linker has layed out for compiler generated data.
Putting the TIM's in as C structs would embed them into the .data section of the
linked program. Ordering is:

    program start address
    .text            :program code
    .rodata
    .data            :initilised data (the TIM's would link into this section)
    .sdata
    .sbss            :uninitialised data
    .bss             :uninitialised data
    rest of memory, the TIM's would've loaded up here before....

Problem is that the other way, you can simply tell the PSX that the heap starts
at the end of BSS and goes on to the base of the stack (heap must be linear).
If you do it with the TIM's in the data section, you have the bss block inbetween

them and the rest of the memory (and bss is where a lot of your global vars
will link to).

> Thanks in advance

Sorry, no joy here :(Of course...
You could be cunning and allocate the memory yourself explicitly
- say you've got an array of objects that you know takes up less space
than the TIM, overlay the array onto the TIM's memory after loading
it to VRAM. I (and I suppose most people) do a similar thing with the
scratchpad memory for doing fast calculations on blocks of data - allocate
areas of it by hand, making sure that they don't interfere, or if they do
that the data that's messed isn't needed any more.

> Phil

Craig.