Context sensitivity in beastie.4th?

[Malcolm Kay]

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