[OpenBIOS] Increasing dictionary space size

[Programmingkid]

On Apr 25, 2016, at 2:33 PM, Mark Cave-Ayland wrote:

> On 25/04/16 14:29, Programmingkid wrote:
> 
>>> Last time I checked the MacOS 9.2 bootscript, the allot was done as a
>>> function of subtracting from a value taken from the r-stack. Given that
>>> we already know the r-stack has been corrupted at this point, I suspect
>>> that the value you get back is bogus which is why you see an attempt for
>>> such a large allot.
>> 
>> Actually I made a patch that fixes the r-stack corruption. Here it is: http://www.openfirmware.info/pipermail/openbios/2016-April/009350.html
>> 
>> The patch works by replacing all >r and r> words with other words that work on a completely different stack. 
>> 
>> The value that is allocated on a real Macintosh is pretty big also. So I am curtain the script is working as it should on OpenBIOS.
> 
> Are you able to show your worked example from the bootscript line by
> line with both the r-stack and d-stack?

Sorry but I'm not quite sure what you are asking. I did find a mistake in my last patch that has been fixed. It now boots Mac OS 9 without any problems. I will send it soon.

> From looking at the source I
> just don't see how this can work looking at the outermost r-stack
> commands from the OS 9 bootscript:
> 
> here >r
> ...
> r> here - allot
> 
> I would expect this to allocate the difference between the dictionary
> pointer at the start and end of the first section which is going to be
> very small, unless something has already gone wrong (which given the
> inner loop also uses r-stack commands is very likely at this point).

You were right. The value is very small.

I think I know what is wrong. The "here" word returns a negative number on OpenBIOS. It returns a positive number on a Macintosh. That is one big implementation difference that could cause problems. I'm not sure as to why it returns a negative number. The calculated value for "r> here - allot" is -29. 

If you enter this test program into the interpreter:

here .
-100 allot
here .

The value printed will be mathematically correct, so this negative address issue might not be a problem after all.