"Daniel C. Sobral" wrote:
> : Short-Appplication ." Hello World!" cr ;
> might even work... :-)
I've been waiting for a FORTH-geek to pop his head up; I
have most of "nextboot" reimplemented... I've added "fwrite"
and "flseek" verbs. I've thought about kidnapping an
The current problem is that the biosdisk.c doesn't contain
"write" code, and that the libstand code wouldn't call it
if it did.
I'm not really interested in creating or extending files,
and with those restrictions, it seems possible to do the
Is anyone interested in helping out with the code?
The basic plan is to take a file that has:
"A A A B B B\n"
and rewrite it as:
"A A B B B A\n"
(a rotor; slightly different than the original nextboot,
but acceptable, given the constraint of keeping the file
exactly the same length), and then use the first string
"A" (might be "disk1s1a:/kernel") to set curr_dev to the
"disk1s1a:" part, and then try to boot the "/kernel" part.
I'll write the user space utility, and I'm willing to do
the UFS code as well, but it's been 15 years since I've
done FORTH, and I'm not too confident of the VM86 calls
in biosboot.c for writing, either.
We could guard the code against extending the file, and
that's enough to ignore the allocation problems without
damaging any FS to which it is applied, since we would
only rewrite existing disk blocks.
The "fread" verb already returns the exact length of the
file, so that's not a problem, either.
So do we have a BIOS write hacker and a FORTH hacker in
Worse comes to worse, I can find a sacrificial disk and
do the BIOS write stuff myself, if I have to.
Modified code for libstand to go back to CMU Mach, per
the request, of course...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message