Context sensitivity in beastie.4th?

[Scott Long]

Malcolm Kay wrote:

> On Fri, 27 May 2005 03:13 pm, Scott Long wrote:
> 
>>Scott Long wrote:
>>
>>>Malcolm Kay wrote:
>>>
>>>>I have installed FreeBSD 5.4 RELEASE on a new machine,
>>>>Celeron + SATA drive, without and problems, include a
>>>>kernel rebuild to support a PCI serial card.
>>>>
>>>>But now I wish to change the graphic, beastie, that appears
>>>>in the boot menu. I am certainly no expert or even acolyte
>>>>in forth programming but the job appears to be simple
>>>>enough -- just change the characters in the
>>>>'beastie' constructions and if we don't exceed the
>>>>available screen space all should be well!
>>>>
>>>>Well what I got was a cycling reboot going back ech time to
>>>>the BIOS splash screen and advancing an apparently
>>>>negligable distance into the FBSD
>>>>boot sequence.
>>>>
>>>>I had actually copied /boot/beastie.4th to
>>>>/boot/phoenix.4th, edited the copy and pointed
>>>>/boot/loader.rc at phoenix.4th instead of beastie.4th.
>>>>Recovery by booting from the distribution CD and entering
>>>>"Fixit" to change
>>>>the pointer back to beastie.4th.
>>>>
>>>>Most variants on my original attempt ended up the same way,
>>>>but some crashed with a "directory full" message which
>>>>seems quite strange as my images have always been smaller
>>>>than the original 'beastie'.
>>>>
>>>>Replacing the colourised version of my 'phoenix' with a
>>>>copy of the monochrome version worked.
>>>>
>>>>At present I have a phoenix.4th file which works but does
>>>>not exhibit the full image. The differences to the original
>>>>beastie.4th file are shown here
>>>>with escape characters replaced by '{esc}' to limit mail
>>>>confusion.
>>>>
>>>>With the line:
>>>>( 2dup at-xy ."         {esc}[1m^ ^" 1+ )
>>>>uncommented the system goes back to an infinite boot loop.
>>>>
>>>>This all seems very strange and unbelievable -- I must
>>>>surely be doing something very stupid. Does anyone have any
>>>>idea what that might be?
>>>
>>>Seems to work for me with the commented lines fixed.  Btw,
>>>you by no doubt have noticed that it's somewhat inconvenient
>>>to do 4th programming by modifying the boot scripts and then
>>>praying that the reboot works. It's possible to do 90% of
>>>the testing in userland, like I did when I wrote
>>>beastie.4th.
>>>
>>>Go to /sys/boot/ficl.  Do 'make clean && make testmain'. 
>>>This will create a binary called 'testmain' either in the
>>>'.' directory or in /usr/obj/usr/src/sys/boot/ficl.  Copy
>>>this binary to your home directory.  Then copy screen.4th,
>>>frames.4th, and beastie.4th from /boot to your home
>>>directory.  Next create a file called init.4th
>>>
>>>containing the following:
>>>: boot drop exit ;
>>>: reboot drop exit ;
>>>
>>>load screen.4th
>>>load frames.4th
>>>load beastie.4th
>>>beastie-start
>>>
>>>Then run it via './testmain init.4th'.  The countdown timer
>>>won't work and most of the keys naturally won't do what they
>>>are supposed to do, but everything else in the menu should
>>>work just as it would at boot.  I tested your colorized
>>>phoenix this way just now and it worked.
>>
>>Oh, one thing I forgot to mention is that you'll need to
>>comment out the 'include' lines in beastie.4th since the
>>testmain environment doesn't implement those words.
>>
> 
> 
> I found I also needed to do something about
>  getsenv
>  setenv
> and
>  unsetenv
> The following at the start of init.4th worked:
> ----------------------------------------------
> : getenv
>   2dup s" loader_color" compare 0= if
>     2drop
>     s" NO"
>     exit
>   then
>   2dup s" beastie_disable" compare 0= if
>     2drop
>     -1
>     exit
>   then
>   2drop
>   -1
>   exit
> ;
> 
> : setenv drop drop ;
> : unsetenv drop ;
> ------------------------------------------------
> Where the fourth line might also be 
>    s" YES"
> 
> Symptoms suggested to me that I had a memory problem but 
> memtest86 ran without difficulty.
> 
> I also found much works differently at boot. Closer examination
> shows that a number of things take different paths oftem using 
> BIOS or simplified code when called at boot  --  I wonder whether
> there is some anomaly in memory allocation when run from boot 
> that raises its ugly head on my machine.
> 
> I have achieved what I want by using a empirically derived 
> context but the underlying problem persists.
> 
> Anyway thanks for your input.
> 
> Malcolm
> 
> 
> 

Look at rev 1.11 of /sys/boot/ficl/loader.c.  I guess I never merged it
back to RELENG_5.  Yes, not having a working getenv word makes some
things act different, but emulating the real functionality would require
simulating a lot more of the underlying loader environment, and that's
more work than I'm able to do right now.

Scott