[OpenBIOS] [Qemu-ppc] MorphOS 4.x on QEMU

[BALATON Zoltan]

On Mon, 3 Mar 2014, Mark Cave-Ayland wrote:
> Ah that's why this looks a little strange to me. Can you try with just plain 
> SVN trunk (without Olivier's patch) to make sure that doesn't have an effect 
> too?

Here it is with SVN trunk with only DEBUG_CIF and the memdump length 
changed for nextprop in debug code:

>> nextprop(0xfff517e4, "name", 0x07de7e30) =
: nextprop  ( 7de7e30 7de7e30 fff517e4 )
fff49f08: >r
3 > 7de7e30 20 dump
7de7e30  6e 61 6d 65 00 00 00 00  00 00 00 00 00 00 00 00    name............
7de7e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
  ok
3 > resume  ok
  ( 7de7e30 7de7e30 fff517e4 )
fff49f08: >r  ( 7de7e30 7de7e30 )
fff49f0c: dup  ( 7de7e30 7de7e30 7de7e30 )
fff49f10: 0=  ( 7de7e30 7de7e30 0 )
fff49f14: do?branch  ( 7de7e30 7de7e30 )
fff49f28: dup  ( 7de7e30 7de7e30 7de7e30 )
fff49f2c: cstrlen
3 > 7de7e30 20 dump
7de7e30  6e 61 6d 65 00 00 00 00  00 00 00 00 00 00 00 00    name............
7de7e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
  ok
3 > resume  ok
  ( 7de7e30 7de7e30 7de7e30 )
fff49f2c: cstrlen  ( 7de7e30 7de7e30 4 )
fff49f30: 0
3 > 7de7e30 20 dump
7de7e30  6e 61 6d 65 00 00 00 00  00 00 00 00 00 00 00 00    name............
7de7e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
  ok
3 > resume  ok
  ( 7de7e30 7de7e30 4 )
fff49f30: 0  ( 7de7e30 7de7e30 4 0 )
fff49f34: 3  ( 7de7e30 7de7e30 4 0 3 )
fff49f38: pick  ( 7de7e30 7de7e30 4 0 7de7e30 )
fff49f3c: c!
5 > 7de7e30 20 dump
7de7e30  6e 61 6d 65 00 00 00 00  00 00 00 00 00 00 00 00    name............
7de7e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
  ok
5 > resume  ok
  ( 7de7e30 7de7e30 4 0 7de7e30 )
fff49f3c: c!  ( 7de7e30 7de7e30 4 )
fff49f40: dup
3 > 7de7e30 20 dump
7de7e30  00 61 6d 65 00 00 00 00  00 00 00 00 00 00 00 00    .ame............
7de7e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
  ok
3 > resume  ok
  ( 7de7e30 7de7e30 4 )
fff49f40: dup  ( 7de7e30 7de7e30 4 4 )
fff49f44: do?branch  ( 7de7e30 7de7e30 4 )
fff49f4c: 2dup  ( 7de7e30 7de7e30 4 7de7e30 4 )
fff49f50: r@  ( 7de7e30 7de7e30 4 7de7e30 4 fff517e4 )
fff49f54: get-package-property  ( 7de7e30 7de7e30 4 ffffffff )
fff49f58: do?branch  ( 7de7e30 7de7e30 4 )
fff49f60: r>  ( 7de7e30 7de7e30 4 fff517e4 )
fff49f64: 2drop  ( 7de7e30 7de7e30 )
fff49f68: 2drop  ( Empty )
fff49f6c: -1  ( ffffffff )
fff49f70: exit -1
>> 0x07de7e30  00 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00  .ame............
>> 0x07de7e40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> child(0xfff517e4) = 0x00000000

> I wonder if the problem could be caused by the incoming property address and 
> the outgoing property address being the same? It may be that MorphOS relies 
> on an implementation-specific behaviour that means this just happens to work 
> on PPC Open Firmware.

It can be. It looks like that the buffer is cleared before it gets used by 
later code. Do you have any idea how to fix this?

Regards,
BALATON Zoltan