Date: Sat, 04 Jun 2005 00:33:11 -0600 From: Scott Long <scottl@samsco.org> To: Malcolm Kay <malcolm.kay@internode.on.net> Cc: freebsd-stable@freebsd.org Subject: Re: Context sensitivity in beastie.4th? Message-ID: <42A14B27.5020207@samsco.org> In-Reply-To: <200506041518.16541.malcolm.kay@internode.on.net> References: <200505271427.13508.malcolm.kay@internode.on.net> <4296B306.9080300@samsco.org> <4296B39D.9030107@samsco.org> <200506041518.16541.malcolm.kay@internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A14B27.5020207>