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

[Mark Cave-Ayland]

On 03/03/14 13:05, BALATON Zoltan wrote:

> On Sun, 2 Mar 2014, Mark Cave-Ayland wrote:
>> Now the fact that nextprop returns -1 indicates that the following
>> check has failed:
>>
>> \ verify that prev exists (overkill...)
>> dup if
>> 2dup r@ get-package-property if
>> r> 2drop 2drop -1 exit
>> else
>> 2drop
>> then
>> then
>>
>> This means that the client requested the next property after "name"
>> but OpenBIOS's get-package-property couldn't find "name" and so
>> returns -1 back to the caller as shown in your trace.
>
> If I remove this check it returns 0 and an empty string. With debug
> nextprop (and the above check removed + Olivier's patch) I get the
> following:

(cut)

> I hope the above make sense to you and helps finding why it does not work.

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?

The important part is to view the incoming parameters to the function; 
from your output you show this:

   : nextprop  ( 7de7e30 7de7e30 fff51908 )

Compare this with the stack diagram in ciface.fs which shows this:

   : nextprop ( buf prev phandle -- 1|0|-1 )

According to the IEEE1275 specification, prev should be a 
NULL-terminated string of the previous property ("name" in this case) 
while buf should be a buffer into which the next property name is copied.

During debug, you can press "f" to drop to a Forth console and then 
display memory using the dump command. For example the following will 
show you what's in the incoming buffer:

   7de7e30 20 dump

You can then type "resume" in order to return to the debugger.

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.


ATB,

Mark.