Date: Wed, 6 Feb 2008 10:14:30 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-chat@FreeBSD.ORG, des@des.no Subject: Re: why is it called /boot/beastie.4th ? Message-ID: <200802060914.m169EUAL056100@lurza.secnetix.de> In-Reply-To: <8663x3wbm3.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smørgrav wrote:
> Oliver Fromme <olli@lurza.secnetix.de> writes:
> > I don't think it can be done currently, but it would be possible to
> > implement. I haven't looked at the syscons code in a long time,
> > though. Right now my focus is on the loader.
>
> If you say the magic words (something like "I'm willing to work on
> syscons once I'm done with the loader"), I'll have your application in
> core@'s inbox in a New York minute :)
I'm afraid I can't make any promises because I have a real
job and other duties. I can certainly have a look at the
syscons code. But it depends on the amount of my free time
what I can do.
It also depends on the current state of the code. Actually
I was quite familiar with the syscons code in 4-current
about 10 years ago (see PR kern/15436, for example).
However, I think the code has undergone some significant
changes in the meantime.
So I can say that I'm willing to look at the syscons code,
but right now I can't promise to actually do any useful
work. :-)
> > In fact my PCX decoder supports that; runs crossing planes (standard)
> > as well as runs crossing scan line boundaries (non-standard). In fact
> > I have to admit that it currently doesn't support padding at all.
> > Well, ppmtopcx never generates any padding, so I didn't care. I'll
> > try to fix that, though.
>
> Hmm, the spec calls for padding each scan line to the nearest multiple
> of 16 bits IIRC, but it's been a long time.
The spec is a little vague in several places. I think it
says that padding is allowed but not required. Certainly
the ppmtopcx tool never generates any padding:
$ ppmmake black 1 1 | ppmtopcx | wc -c
129
That's 128 bytes for the header and 1 byte for the actual
bitmap. Gimp is the same, it doesn't generate padding,
but it's not able to create 16 color PCX files; it always
creates files with a 256 color palette or truecolor, so
you have to cycle the file through pcxtoppm|ppmtopcx if
you want to use the image in a 16 color mode.
The smallest PCX file gimp can produce is 898 bytes:
128 for the header, 1 byte for the bitmap, 1 marker byte
(0x0c) for the extended palette, and 768 bytes for the
256-color palette (256 * 3 bytes RGB).
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
(On the statement print "42 monkeys" + "1 snake":) By the way,
both perl and Python get this wrong. Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake". -- Jim Fulton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802060914.m169EUAL056100>