On Apr 25, 2016, at 2:33 PM, Mark Cave-Ayland wrote:
On 25/04/16 14:29, Programmingkid wrote:
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:
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
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:
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.