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.