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 simple to fix. Once this has been added, I'll run the pic renderer over all QfG2 and KQ1 pics in order to check for that. [vocab stuff] > I'm not sure. IIRC, there is a further split between English/non-English > vocabularies. I'll look into it (but I can't test any patches myself). I'll have to dig deeply for the German SQ3, too... I'll check for resources if I find the guy who bought it. > > BTW, what kind of transformations did they do? Something like �->ae? > Yes. Hardcoded, or using a transformation library? > > Could you elaborate on this, please? Did the lofsa/lofss semantics change, > > or is there a bug somewhere? IIRC, we use as much heap space as they did > > while providing more memory...? > lofsa/lofss did not change, but the script loading semantics did. Some parts > of the script are relocated to hunk memory (among others, code and export > tables), and only the necessary parts remain in heap. Makes sense. This is along the lines of Magnus' original design for the VM, BTW... 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'... > 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? a) Global variables (Script 0 locals) b) Script-local variables for all scripts (while only the current script may be referenced, it's possible to pass that reference to a different script) c) Funcselector parameters d) Temp variables Frankly, everything that can be referenced to by lea. We may also need f) Global interpreter variables returned by system calls (the cwd (anything else?)) Other stuff (selectors) cannot be referenced by address, /unless this is done in two steps/, i.e. get an object's address, add n, instruct the kernel to write something there (GetTextSize() etc.). I've never seen something like this being done, but it would be possible (and that was one of the reasons for staying close to the original model). 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? Anything else that used to be on the heap (lists, nodes) can be removed from there as well. I'd really like to use a virtual memory system for this, but 16 bit pointers don't quite allow for this to be done in a sensible way. OTOH, we /could/ move to a 32 bit model, and enforce 16 bit for arithmetics, but we might end up with lots of kludgy code to fix weird hacks in the SCI code (note that unaligned reads/writes don't appear to happen- I've put in code reporting those, and, so far, the only thing it reported were a few bugs in kernel functions. This means that, at the very least, we can transform selectors into a form comfortable to the host processor, without risking massive slowdown because of unaligned access). Anyway, I think that might work... We might even use actual pointers instead of 32 bit values. This would slow down verification considerably and have the potential to cause segmentation faults and bus errors if verification is disabled, but it'd probably be faster (plus things would look a /lot/ less ugly on the C side). Thoughts/Comments? Well, looks like there's still a lot to be done here :-) llap, Christoph
