On May 21, 2005, at 12:17 AM, Dan LaBell wrote:

> 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?

To my knowledge the only place to stick something that is persistent  
is in NVRAM or PRAM. Apple's nvram command in OS X doesn't show  
anything out of the ordinary.

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

Sun has an OpenFirmware tokenizer that may/may not save some space,  
but their macro definitions probably do better than what the  
tokenizer could do. I never messed with it.

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

Depends on the model. My Beige G3 can get into OF no problem, my  
PowerBook G3 on the other hand is super picky about when you press  
command-option-o-f and it is impossible to get into OF on a warm  
reboot because of some kind of timing bug.

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

Never tried it.

> 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?

I know on OF 1.0.5 machines it was really small, not sure about 2.x

> !DSPAM:428eb648247297506790993!