From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 05:48:33 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B45C16A41C for ; Sat, 4 Jun 2005 05:48:33 +0000 (GMT) (envelope-from malcolm.kay@internode.on.net) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id D01F543D1F for ; Sat, 4 Jun 2005 05:48:32 +0000 (GMT) (envelope-from malcolm.kay@internode.on.net) Received: from beta.home (ppp215-225.lns1.adl2.internode.on.net [203.122.215.225]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j545mKCg084110; Sat, 4 Jun 2005 15:18:28 +0930 (CST) From: Malcolm Kay Organization: at home To: Scott Long Date: Sat, 4 Jun 2005 15:18:16 +0930 User-Agent: KMail/1.5.4 References: <200505271427.13508.malcolm.kay@internode.on.net> <4296B306.9080300@samsco.org> <4296B39D.9030107@samsco.org> In-Reply-To: <4296B39D.9030107@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506041518.16541.malcolm.kay@internode.on.net> Cc: freebsd-stable@freebsd.org Subject: Re: Context sensitivity in beastie.4th? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2005 05:48:33 -0000 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