[OpenBIOS] Increasing dictionary space size
programmingkidx at gmail.com
Tue Apr 26 05:16:54 CEST 2016
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:
The value printed will be mathematically correct, so this negative address issue might not be a problem after all.
More information about the OpenBIOS