Christoph Reichenbach wrote:
> Hi,
>
> On Mon, 25 Sep 2000, Lars Skovlund wrote:
> > I haven't seen the embedded cel command in actual use. OTOH, KQ1/SCI breaks
> > because the current FreeSCI does not handle Set Priority Table yet.
>
> That's the same reason QfG2 usually breaks, and it should be relatively
??? Mine dies when I get to the character attributes screen (a failing call to
Clone()).
> > > BTW, what kind of transformations did they do? Something like �->ae?
> > Yes.
>
> Hardcoded, or using a transformation library?
There is a table in VOCAB.913 - the one with the Katakana (?) mappings in QfG2.
I put a #define in vocabulary.h for it already.
[VM/Heap stuff]
> I guess those were the changes Corey Cole was talking about when he
> referred to the memory problem in QfG2 being solved 'on both sides'...
That's probably it, though I can't see the meaning of "on both sides" - I haven't
seen your correspondence with him.
> > So no, we don't have as
> > much free heap as Sierra SCI. Later on, SCI1.1 performed this split at
> > compile time (creating two files, *.SCR and *.HEP).
>
> You're right, this will need some work in the Interpreter to be done
> correctly. OTOH, it might make things somewhat cleaner...
> So, what has to remain in the heap?
Closer scrutiny will have to take place to be certain, but the *.HEP and *.SCR
files of SCI1.1 may be a good indicator. I recall that the script objects were
lobotomized, such that selector numbers and selector values were stored in
separate places (hunk and heap, respectively). OTOH, the class/object headers
(which were a separate structure in SCI0) now consists of selectors with
well-defined numbers in a well-defined order (with numbers starting at 0x1000).
> What about string constants? IIRC, that's where lofsa/lofss come into play
> (local calls have relative addresses). Do you happen to know if we have to
> map all string segments into the heap all of the time?
Since they are part of *.HEP files in SCI1.1, and the script code may
unpredictably address them, I would say yes.
> Anything else that used to be on the heap (lists, nodes) can be removed
> from there as well.
I am not sure that we should randomly move things out of the heap. In any case,
the scripts are the major consumer of heap space here, and we should at least
begin with that.
[snip discussion of virtual memory etc.]
> llap,
> Christoph
Lars
