Increasing dictionary space size
How do we increase the size of the dictionary? I thought it would be as simple as increasing the DICTIONARY_SIZE constant, but that causes this error: ppc-elf-ld: section .romentry [00000000fffffffc -> 00000000ffffffff] overlaps section .data [00000000fff3c000 -> 000000010013c1d7] ppc-elf-ld: openbios-qemu.elf.nostrip: section .romentry vma 0xfffffffc overlaps previous sections
On 23/04/16 17:03, Programmingkid wrote:
How do we increase the size of the dictionary? I thought it would be as simple as increasing the DICTIONARY_SIZE constant, but that causes this error:
ppc-elf-ld: section .romentry [00000000fffffffc -> 00000000ffffffff] overlaps section .data [00000000fff3c000 -> 000000010013c1d7] ppc-elf-ld: openbios-qemu.elf.nostrip: section .romentry vma 0xfffffffc overlaps previous sections
That looks correct, however you've increased DICTIONARY_SIZE so much that the final address goes beyond 0xfffffffc which is the maximum limit of the PROM area for PPC. ATB, Mark.
On Apr 24, 2016, at 8:36 AM, Mark Cave-Ayland wrote:
On 23/04/16 17:03, Programmingkid wrote:
How do we increase the size of the dictionary? I thought it would be as simple as increasing the DICTIONARY_SIZE constant, but that causes this error:
ppc-elf-ld: section .romentry [00000000fffffffc -> 00000000ffffffff] overlaps section .data [00000000fff3c000 -> 000000010013c1d7] ppc-elf-ld: openbios-qemu.elf.nostrip: section .romentry vma 0xfffffffc overlaps previous sections
That looks correct, however you've increased DICTIONARY_SIZE so much that the final address goes beyond 0xfffffffc which is the maximum limit of the PROM area for PPC.
Thanks for this info. Would you know a way to allocate around 700k from the dictionary?
On 24/04/16 17:23, Programmingkid wrote:
On Apr 24, 2016, at 8:36 AM, Mark Cave-Ayland wrote:
On 23/04/16 17:03, Programmingkid wrote:
How do we increase the size of the dictionary? I thought it would be as simple as increasing the DICTIONARY_SIZE constant, but that causes this error:
ppc-elf-ld: section .romentry [00000000fffffffc -> 00000000ffffffff] overlaps section .data [00000000fff3c000 -> 000000010013c1d7] ppc-elf-ld: openbios-qemu.elf.nostrip: section .romentry vma 0xfffffffc overlaps previous sections
That looks correct, however you've increased DICTIONARY_SIZE so much that the final address goes beyond 0xfffffffc which is the maximum limit of the PROM area for PPC.
Thanks for this info. Would you know a way to allocate around 700k from the dictionary?
Sadly most PROMs are limited in the amount of memory mapped for them on real hardware, so this is likely impossible. What is the current dictionary size for your PPC image and why do you need to increase it? 700K is starting to sound almost too big. ATB, Mark.
On Apr 24, 2016, at 1:16 PM, Mark Cave-Ayland wrote:
On 24/04/16 17:23, Programmingkid wrote:
On Apr 24, 2016, at 8:36 AM, Mark Cave-Ayland wrote:
On 23/04/16 17:03, Programmingkid wrote:
How do we increase the size of the dictionary? I thought it would be as simple as increasing the DICTIONARY_SIZE constant, but that causes this error:
ppc-elf-ld: section .romentry [00000000fffffffc -> 00000000ffffffff] overlaps section .data [00000000fff3c000 -> 000000010013c1d7] ppc-elf-ld: openbios-qemu.elf.nostrip: section .romentry vma 0xfffffffc overlaps previous sections
That looks correct, however you've increased DICTIONARY_SIZE so much that the final address goes beyond 0xfffffffc which is the maximum limit of the PROM area for PPC.
Thanks for this info. Would you know a way to allocate around 700k from the dictionary?
Sadly most PROMs are limited in the amount of memory mapped for them on real hardware, so this is likely impossible. What is the current dictionary size for your PPC image and why do you need to increase it? 700K is starting to sound almost too big.
I haven't been able to increase the dictionary size. It is currently at the default of 512K. Apple's bootscript does attempt to allocate 672,751 bytes. That is why we see the Dictionary Space overflow messages. Tests done on a Macintosh show Apple's allot word can allocate a lot more than 700k.
On 24/04/16 18:24, Programmingkid wrote:
Sadly most PROMs are limited in the amount of memory mapped for them on real hardware, so this is likely impossible. What is the current dictionary size for your PPC image and why do you need to increase it? 700K is starting to sound almost too big.
I haven't been able to increase the dictionary size. It is currently at the default of 512K. Apple's bootscript does attempt to allocate 672,751 bytes. That is why we see the Dictionary Space overflow messages. Tests done on a Macintosh show Apple's allot word can allocate a lot more than 700k.
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. ATB, Mark.
On Apr 25, 2016, at 3:02 AM, Mark Cave-Ayland wrote:
On 24/04/16 18:24, Programmingkid wrote:
Sadly most PROMs are limited in the amount of memory mapped for them on real hardware, so this is likely impossible. What is the current dictionary size for your PPC image and why do you need to increase it? 700K is starting to sound almost too big.
I haven't been able to increase the dictionary size. It is currently at the default of 512K. Apple's bootscript does attempt to allocate 672,751 bytes. That is why we see the Dictionary Space overflow messages. Tests done on a Macintosh show Apple's allot word can allocate a lot more than 700k.
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.
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? 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). ATB, Mark.
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.
participants (2)
-
Mark Cave-Ayland -
Programmingkid