Thread: Re: AW: [Etherboot-developers] Splashimage / Bootlogo
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Michael B. <mb...@fe...> - 2002-06-09 11:59:51
|
On Sat, 8 Jun 2002, devzero wrote: > Hello Michal, > this is good news, thank you ! > unfortunately the SRPMs link you supplied doesnt work - can you send me the right one ? www.fensystems.co.uk/SRPMS.fensys for SRPMS www.fensystems.co.uk/RPMS.fensys for RPMS Looks as though Ken's external bootmenu method will do what you want as well, and is more elegant than using bootmenu code inside the EPROM. You still might be interested in the etherboot.m4 file from jumpwire; it provides a nice, easy way to generate ANSI sequences and DHCP option files (that can be loaded via TFTP using the extensions-path option). > >Dual-Head Range > >We understand that some schools do not have excessively large budgets for computers, whilst at the same >time needing to meet the > National Curriculum requirements to teach children computing. That is why we > >developed the Dual-Head workstation. > >In simple terms, a Dual-Head workstation is a single computer that allows two people to use it > >simultaneously with separate monitors, keyboards and mice. This has obvious effects on the cost of a > >system, as rather than needing 30 workstations for 30 students working simultaneously, you would only > >require 15. And although each Dual-Head workstation in itself is slightly more expensive than a > >standard workstation, the per head price is much lower (?195 as opposed to ?320). > >Prices for our Dual-Head workstations start at ?195 per head (?390 per Dual-Head workstation). > WOW ! You did it and have it for "production" usage ? i.e. you are running new linuxconsole stuff > and miguel freitas "DUAL-X Hack" successfull? I don't see too much light with this after reading the mailinglists of linuxconsole > and thought it needs some more time to be done "well" .... Not quite. We know it is possible. For a long time, we had it marked as "under development" on the site and no-one expressed an interest. Even now that it is not explicitly marked as "under development", we still haven't had anyone actually wanting to buy one. When they do, we'll get it working. :-) For our uses, we only need dual X; it doesn't matter if only one of the "heads" can be used outside of X since our customers will never use them in this way. Michael Brown http://www.fensystems.co.uk -- Fen Systems: Linux made easy for schools |
|
From: <ke...@us...> - 2002-06-09 14:16:37
|
>Since tftp'ing is relatively slow and most boot/splashscreens are not >very complex graphics, i'd like to append, that boot/splashcreen-images >should/could be compressed. I should also add that I don't intend to develop this version of the external menu program very far. I will just make it resemble the internal menuing as far as possible and then any improvements are up to you hackers. My goal here is to remove crud from Etherboot. The external program chaining mechanism is general and has been in Etherboot for over a year. It's documented in the developers guide and there are comments in the sample program. So you could start from scratch and create any fancy program you like. Lots of possibilities, use the mouse for input, animation, fractals, etc. etc. |
|
From: devzero <de...@we...> - 2002-06-09 14:52:26
|
Ken, shure, i didn`t expect that YOU would do so. But for me, it will be VERY difficult to do because I have not very good experience in programming - so why not ask for that feature, make people "think" about and perhaps find someone with better skills who says: mhh, bootlogo? wait a minute.... :) regards Roland PS: gonna search for some demoscene-guys, they will go laughing and make an mindblowing 3d boot-menu for us...... ;) You really should give ftp://ftp.jp.scene.org/pub/demos/demos/1997/s/snc_omni.zip a try. (The first level of well known game "descent" - squeezed into 4 KILOBYTES :))) -----Ursprüngliche Nachricht----- Von: eth...@li... [mailto:eth...@li...]Im Auftrag von Ken Yap Gesendet: Sonntag, 9. Juni 2002 16:17 An: Etherboot developers list Betreff: Re: AW: [Etherboot-developers] Splashimage / Bootlogo >Since tftp'ing is relatively slow and most boot/splashscreens are not >very complex graphics, i'd like to append, that boot/splashcreen-images >should/could be compressed. I should also add that I don't intend to develop this version of the external menu program very far. I will just make it resemble the internal menuing as far as possible and then any improvements are up to you hackers. My goal here is to remove crud from Etherboot. The external program chaining mechanism is general and has been in Etherboot for over a year. It's documented in the developers guide and there are comments in the sample program. So you could start from scratch and create any fancy program you like. Lots of possibilities, use the mouse for input, animation, fractals, etc. etc. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Etherboot-developers mailing list Eth...@li... https://lists.sourceforge.net/lists/listinfo/etherboot-developers |
|
From: <ebi...@ln...> - 2002-06-09 18:50:45
|
ke...@us... (Ken Yap) writes: > >Since tftp'ing is relatively slow and most boot/splashscreens are not > >very complex graphics, i'd like to append, that boot/splashcreen-images > >should/could be compressed. > > I should also add that I don't intend to develop this version of the > external menu program very far. I will just make it resemble the > internal menuing as far as possible and then any improvements are up to > you hackers. My goal here is to remove crud from Etherboot. > > The external program chaining mechanism is general and has been in > Etherboot for over a year. It's documented in the developers guide and > there are comments in the sample program. So you could start from > scratch and create any fancy program you like. Lots of possibilities, > use the mouse for input, animation, fractals, etc. etc. Sounds sane. One thing I would like to do in conjunction with this is to figure out what we need to do to relocate etherboot. Allowing arbitrary to be down loaded. If you don't have to support callbacks this is trivial, with callbacks this becomes a more interesting challenge. Mostly I think etherboot can be moved to the highest available address below 4G, with just a touch of care. The challenges are keeping the overhead down, and still allowing dos BIOS calls. Because that needs a small chunk below 1MB. Eric |
|
From: <ke...@us...> - 2002-06-10 00:18:14
|
>Sounds sane. One thing I would like to do in conjunction with this >is to figure out what we need to do to relocate etherboot. Allowing >arbitrary to be down loaded. If you don't have to support callbacks >this is trivial, with callbacks this becomes a more interesting >challenge. Nope, no callbacks are involved, only a return address and a returned long in EAX. >Mostly I think etherboot can be moved to the highest available address >below 4G, with just a touch of care. The challenges are keeping the >overhead down, and still allowing dos BIOS calls. Because that needs >a small chunk below 1MB. That'll be great. |
|
From: <ebi...@ln...> - 2002-06-10 06:18:10
|
ke...@us... (Ken Yap) writes: > >Sounds sane. One thing I would like to do in conjunction with this > >is to figure out what we need to do to relocate etherboot. Allowing > >arbitrary to be down loaded. If you don't have to support callbacks > >this is trivial, with callbacks this becomes a more interesting > >challenge. > > Nope, no callbacks are involved, only a return address and a returned > long in EAX. Which is almost a callback, but it easier to deal with. The PXEEMU case definitely requires callbacks :( How is the boot filename specified? > >Mostly I think etherboot can be moved to the highest available address > >below 4G, with just a touch of care. The challenges are keeping the > >overhead down, and still allowing dos BIOS calls. Because that needs > >a small chunk below 1MB. > > That'll be great. Right that is ideal. But I keep looking for something a little easier to code up. Eric |
|
From: <ke...@us...> - 2002-06-10 06:27:59
|
>> Nope, no callbacks are involved, only a return address and a returned The return address is just a normal return from subroutine. >> long in EAX. > >Which is almost a callback, but it easier to deal with. The PXEEMU >case definitely requires callbacks :( How is the boot filename specified? The menu program alters the DHCP structure. |