Bill Hacker wrote: > Oliver Fromme wrote: > > Bill Hacker wrote: > > > Oliver Fromme wrote: > > > > http://wiki.freebsd.org/OliverFromme/BootLoader > > > > > > > > I think DragonFly should be able to port it over without > > > > difficulty. Last time I looked, DF's boot loader was > > > > still pretty much the same as FreeBSD's. > > > > > > Good start. > > > > > > And 'compliments' on not going off and coding it in flavor-of-the month > > > language.... > > > > I don't understand that remark. The boot loader is written > > in C, so I don't have much choice other than to code the > > graphics support in C, too. I'm certainly not going to > > port the whole boot loader to a different language. There > > aren't many languages anyway that are suitable for such a > > rather low-level piece of software. > > Once upon a time ... soembody was going to do a bootloader in (IIRC) Lua. > > Nice enough language - but why add to the complexity and dependencies > when not much *else* is done in the core - or anywhere else - in it.
I don't like Lua, but it is better than Forth. In fact, a *lot* better. If the boot loader had embedded Lua instead of FICL, I would be much happier now. In terms of performance, size, dependencies and complexity of integrating it into a C program (such as the loader), Lua and FICL are on the same level. But when Mike Smith started to look for an embeddable language in 1997/98, Lua was not an option, for several reasons: - At that time, Lua was almost unknown in the UNIX world. - Lua is not a standard. Forth is. - At that time, Lua seemed somewhat immature because it underwent substantial changes between releases. On the other hand, FICL was quite stable, with only subtle changes between versions. - Prior to Lua 5.0, the Lua license was legally unclear. (Today it has an MIT license, which is good.) And of course, there were precedents: Forth was used in the Open Firmware (called "OpenBoot" when invented by Sun). The reason why Forth was so popular for boot loaders is simple: The core of a Forth interpreter is ridiculously simple and small. When Sun introduced OpenBoot in 1988, it fit into an 8 KByte ROM. > > > (though it is a travesty what FICL'ization has done to the sheer > > > elegance of 'real' Forth... but that wasn't your doing...) > > > > I don't like Forth. But some people decided that it should > > be embedded in the boot loader, and I can't change that, so > > I need to deal with it. > > Actually one CAN change it. The CPU won't care. Of course you _can_ change it, technically. The question is whether such a change would be accepted by the people who feel responsible for the boot loader. Mike Smith isn't an active BSD devloper anymore, AFAIK, but there are others who think that there's no sufficiently good reason to replace FICL. > But you might have liked it better if it hadn't been bastardized by > crossbreeding it with C. What exactly do you mean by that? You can't write a boot loader in 100% Forth, if you mean that. You will always need write some code for low-level things (in FreeBSD and DragonFly BSD, these are in the BTX library), some code for doing I/O, memory allocation and so on (this is in libstand), and some initialization stuff that interfaces the loader with the earlier boot stages (this part is in sys/boot/i386/loader/*). All of that is not part of FICL, so you can't implement it in Forth. > > If you create a theme for DragonFly BSD, I'd be happy to > > add it to my collection. > > I've made several attemps to modify the published DragonFly logo, but no > joy so far. > > The 4-bit color-depth is now per your earlier guidance, but the tools I > am using are doing something ELSE that is unwanted, so now that it > actually loads, I'm getting something that looks like fabric scraps from > me Mum's cleaning-rag bag. I don't know what tools you use, but I strongly recommend you use ppmtopcx (from the netpbm tools) to generate the PCX file. It will print the number of colors used, so you can easily verify that it's not more than 16 colors. My code will accept PCX files produced by ppmtopcx if they have a maximum of 16 colors. > A menu could make a good deal of that much easier to use than what the > loader prompt supplies. > > But the underlying tools need work also. AFAICS, they are no longer up > to the needs of recognizing modern hardware as well as they might do. The boot loader does not have its own hardware drivers, so it depends on the BIOS for accessing devices. For example, if a disk controller is not recognized by your BIOS, then you can't boot from it. The same goes for USB keyboards and other kinds of hardware that you might want to use in the loader. > Meanwhile - perhaps you could pick up the DragonFlyBSD logo off the site > and see about getting it slimmed-down to a 4-bit .pcx that works? I'll have a look at it if time permits. No promise though. > Or perhaps its creator could do so, given the .pcx parameters? As I wrote above, the current maximum is 640 x 480 at 4 bit depth (i.e. 16 colors). I used ppmtopcx during development and and testing, so I'm pretty sure that my code will eat any PCX file created by ppmtopcx, modulo the above maximum. By the way, GIMP always saves PCX files with 8 bit depth, even if it uses less than 256 colors. So, when using GIMP, save it as PPM first, then use ppmtopcx to convert to PCX. ppmtopcx is pretty smart: It reduces the bit depth to the smallest value required to store the number of colors that are actually used in the image. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
