Increasing dictionary space size

[Programmingkid]

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

[Mark Cave-Ayland]

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.

[Programmingkid]

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?

[Mark Cave-Ayland]

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.

[Programmingkid]

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.

[Mark Cave-Ayland]

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.

[Programmingkid]

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.

[Mark Cave-Ayland]

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.

[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.