Re: Context sensitivity in beastie.4th?
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
Peter Jeremy wrote: On Thu, 2005-May-26 23:41:26 -0600, Scott Long wrote: 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. [Instructions deleted] I believe your instructions are worth preserving. Any chance of you adding that to (eg) /usr/src/sys/boot/README or into the ficl or forth directories? Yeah, it would be a good thing to do. We should actually go a step further and write a ficl manpage that talks about the whole environment and how to develop in it. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
On Thu, 2005-May-26 23:41:26 -0600, Scott Long wrote: >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. [Instructions deleted] I believe your instructions are worth preserving. Any chance of you adding that to (eg) /usr/src/sys/boot/README or into the ficl or forth directories? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
On Fri, 27 May 2005 03:11 pm, 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
Looks as though I may have some strange hardware problem (Groan) but
I'll push on a bit further.
> doubt have noticed that it's somewhat inconvenient to do 4th programming
> by modifying the boot scripts and then praying that the reboot works.
Yes Yes Yes ! ! !
> 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.
>
Thanks for the suggestion -- I'll give it a go.
> Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
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.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
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.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
