This version contains a fix to mbr.asm, plus a version of Murali's menu system, but ported to gcc. Although gcc produces much bigger 16-bit code (since it's really 32-bit code with prefixes) I figured it would be much easier for people to deal with since it requires the configuration to be compiled in. That being said, it's a *very* powerful menu system, partially *because* it's fully programmable. I really recommend people check it out! -hpa
> > This version contains a fix to mbr.asm, plus a version of Murali's menu > system, but ported to gcc. Although gcc produces much bigger 16-bit > code (since it's really 32-bit code with prefixes) I figured it would be > much easier for people to deal with since it requires the configuration > to be compiled in. > > That being said, it's a *very* powerful menu system, partially *because* > it's fully programmable. I really recommend people check it out! > > -hpa >I had some problems building it. First gcc 3.3.2 complained: biosio.c: In function `getdisppage': biosio.c:71: error: asm-specifier for variable `page' conflicts with \ asm clobber list Removing ebx from the clobber list seems to fix it, at least he generated code looks right. I have binutils 2.14.90.0.4 and ld didn't like com16.ld, complaining about ONLY_IF_RO among others. I guess you need a more generic script. I got aroudn it with: ld --verbose|sed -n '/^=/,$p' \ |sed -e '/^=/d' -e 's/.*SIZEOF_HEADERS.*$/ . = 0x100/' >com16.ld but that seems a little hackish. The .com files work quite nicely although the blinking gets really irritating. :-) Thanks. -- Venus 2004-02-02 17:30:01.345 UTC (JD 2453038.229182) X = 0.431921720, Y = 0.537613372, Z = 0.214729609 X' = -0.016341670, Y' = 0.010494719, Z' = 0.005755735
TenThumbs wrote: The .com files work quite nicely although the blinking gets really irritating. :-) Thanks. If you got the .com files from the code in my webpage, then there was a bug which Peter found. That is possibly the cause for all the ugly look. I will be changing the code in a few minutes. You can try it again now. - Murali
I'm having troubles compiling /menu I'm sure I'm overlooking something, but alas I cant figure out what. [tftp at service /mnt/ghost/sys/menu]# make gcc -m32 -funsigned-char -g -W -Wall -march=i386 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -Os -S -o simple.s simple.c echo '.code16gcc' | cat - simple.s > simple.s16 as -o simple.o16 simple.s16 as -o startup.o16 startup.s16 ld -m elf_i386 -T com16.ld -o simple.elf startup.o16 simple.o16 libmenu.a ld:com16.ld:69: parse error make: *** [simple.elf] Error 1 rm simple.o16 simple.s startup.o16 simple.s16 These are the results I get on my RH8 box from the unmodified -pre2 trunk. -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of ganapathy murali krishnan Sent: Tuesday, February 03, 2004 4:55 AM To: syslinux at zytor.com Subject: Re: [syslinux] SYSLINUX 2.09-pre2 TenThumbs wrote: The .com files work quite nicely although the blinking gets really irritating. :-) Thanks. If you got the .com files from the code in my webpage, then there was a bug which Peter found. That is possibly the cause for all the ugly look. I will be changing the code in a few minutes. You can try it again now. - Murali _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
I'm having troubles compiling /menu I'm sure I'm overlooking something, but alas I cant figure out what. [tftp at service /mnt/ghost/sys/menu]# make gcc -m32 -funsigned-char -g -W -Wall -march=i386 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -Os -S -o simple.s simple.c echo '.code16gcc' | cat - simple.s > simple.s16 as -o simple.o16 simple.s16 as -o startup.o16 startup.s16 ld -m elf_i386 -T com16.ld -o simple.elf startup.o16 simple.o16 libmenu.a ld:com16.ld:69: parse error make: *** [simple.elf] Error 1 rm simple.o16 simple.s startup.o16 simple.s16 These are the results I get on my RH8 box from the unmodified -pre2 trunk. -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of ganapathy murali krishnan Sent: Tuesday, February 03, 2004 4:55 AM To: syslinux at zytor.com Subject: Re: [syslinux] SYSLINUX 2.09-pre2 TenThumbs wrote: The .com files work quite nicely although the blinking gets really irritating. :-) Thanks. If you got the .com files from the code in my webpage, then there was a bug which Peter found. That is possibly the cause for all the ugly look. I will be changing the code in a few minutes. You can try it again now. - Murali _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
I just released SYSLINUX 2.09-pre3; it should hopefully be less binutils- or gcc-version specific. -hpa
TenThumbs wrote:> ganapathy murali krishnan wrote: > > >> OK. I have removed all the bright/flashing parts in the attr. I had in >> sometime ago for some test, I forgot to remove them. >> >> - Murali >> >> > > > I hope I didn't offend you. I didn't mean to disparage your > achievement. It's > wonderful. > > Some suggestions if you don't mind. > I'm using gcc on Linux and gcc does not pack items in a structure by > default. > It might be a good idea to rearrange the structures so that larger > objects > come before smaller ones, i.e. 4 byte objects before 2 byte one before > singel > ones like chars. > >Good idea. I will do that today / tomorrow.> I also noticed that a t_menusystem object is 21260 bytes because it > has 10 > t_menu items which each have t_menuitem objects wich are 208 bytes. > That's a > lot of space in a com file. Is 10x10 necessary? Perhaps 8x8. > >This size is determined by how much space you want for your menu. All these are controlled through #defines in menu.h. Feel free to reduce them as to your liking. I just picked those defaults, since in my example complex.c (which uses some call back functions and stuff) I needed it that long.> I also see that you've assumed a 80x25 screen. Maybe in a future > version you > shouldn't although that's probably hard without some kind of malloc. > >My next step is to move all the 80 and 25 in the code as a parameter into the menusystem object, which gets initialised at startup. After that it should work in any text mode without any problem. Ofcourse I am assuming that the text mode is not so large that you dont have two display pages, which will be the case with any machine today. One thing should be pointed out is that all this will probably fail horribly if you are using a serial console. Having a malloc will eliminate the need to hard code all the limits (MENULEN, MAXMENUS,....). On the other hand, I will have a tough time casting pointers back and forth from far * to near *. A question for Peter. It should not be difficult to implement a memory manager which uses the memory inbetween the text segment and the stack? In which case, the memory allocation routine will only need to return near pointers. Since we have 64K of memory, and the code size is 4K and the stack should not grow more than a few K (all pointers passed around), there should be more than enough space to allocate space for the menusystem (current max about 20K). - Murali
Murali Krishnan Ganapathy wrote:> > A question for Peter. It should not be difficult to implement a memory > manager which uses the memory inbetween the text segment and the stack? > In which case, the memory allocation routine will only need to return > near pointers. Since we have 64K of memory, and the code size is 4K and > the stack should not grow more than a few K (all pointers passed > around), there should be more than enough space to allocate space for > the menusystem (current max about 20K).> Should be trivial. -hpa
That would surely be a better solution. - Murali H. Peter Anvin wrote:> Murali Krishnan Ganapathy wrote: > >> >> I know this is a big change in thinking, but if one has something like >> this, then comboot code can be modularised, and maintainance will also >> be easy. >> > > I think a better way to accomplish the above would be to consider how to > librarize subroutines. > > -hpa >
ganapathy murali krishnan wrote:> That would surely be a better solution. > > - Murali >Well, what you were proposing was basically a mechanism for shared libraries. Before we make them shared we should establish things as libraries :) -hpa
-pre9 works :) -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of H. Peter Anvin Sent: Wednesday, February 04, 2004 3:09 PM To: Geoffrey Huntley Cc: syslinux at zytor.com Subject: Re: [syslinux] Patch to comboot menu Geoffrey Huntley wrote:> I got a chance to test it more > > -pre5 works > -pre6 works > -pre7 broken > -pre8 broken >How embarrassing... it was all a one-character typo in startup.S16. Anyway, I have fixed it and released it as 2.09-pre9. -hpa _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.