On May 15, 2005, at 7:36 PM, John wrote:

> Are the open firmware patches machine specific or open firmware version
> specific?
>
> -John
>

Been following this thread for a while...

If its all pure forth, and the virtual machines are equivalent, I'd 
tend to think firmware specific.  I just have a nagging doubt that 
maybe the system disk patches
could do more than what's visible in forth.  If they say, used forth to 
wedge in
a some machine code, to modify maybe the forth kernel itself, how could 
one tell?

If every system disk patch, is pure forth, then it should be simple 
enough to get the patch into the form of a the script.  setenv to set 
variables, and maybe do something like >>nvramrc that would allow 
nvramrc, to be built up line by line, it would be similiar to existing 
nvalias command, but simpler. Also it might be possible to make a 
composite auto-patch, 1 file for multiple machines.

2.  With these unpatched OF2 machines, it is difficult to get to Forth 
Console in the   first place, correct?

3.  Has it been determined whether one can netboot a plain forth file?

4.  How limited is the memory of the machines involved?  Note the macro 
like definitions:
>>      : $D find-device ;
>>      : $E device-end ;
>>      : $L BLpatch ; : $R BRpatch ;
>>      : $X execute ;
>>      : $P 0 to my-self property ;
>>      : &a " /chosen" $D $P $E ;
>>      : &c " ata-enable" $call-parent ;

There's a tradeoff for doing this, and it seems like they're especially 
trying to save space in nvramrc itself, to the point of wasting it 
elsewhere (based on $D, $E, and $X )
wondering what the hard limit is -- how close are these machines to 
hitting it?