Syslinux - Aug 2005 - SYSLINUX 3.11-pre3 -- release candidate

This is a minor tweak on 3.11-pre2.  If nothing new comes up, I will 
release this as 3.11 probably early next week.

	-hpa

H. Peter Anvin schreef:
> This is a minor tweak on 3.11-pre2.  If nothing new comes up, I will 
> release this as 3.11 probably early next week.
(oops, reply-to isn't set to 'mailinglist' but to 'person who
sent the
mail')


OK :)

*is Memdisk's adhoc 'floppyb' parameter official now? or discarded?
*any way to compress MEMDISK and still be able to load it?
  Saves a nice 10KB on diskette.
  Probably (G)ZIP has no use (requires decompression algorytm in syslinux
  itself?) but UPX for example also cannot handle MEMDISK.
  An additional memdisk-like program/module which decompresses a file,
  then runs it, would also be fine.

label mt86
kernel unzip.c32
append initrd=memtest.gz

where memtest.gz is obtained by:
gzip memtest.bin

 >     -hpa


Bernd Blaauw

(and why's my Mozilla Thunderbird using UTF8 unicode on a text-only 
mailinglist?)

H. Peter Anvin schreef:
> Discarded, replaced with "floppy=1".
I finally read up on documentation, and indeed 'floppy=N' parameter is 
mentioned there. Any valid numbers aren't mentioned, but as MEMDISK is 
usually only meant for DOS, valid numbers are 0 and 1.
I don't know if it depends on my VMware 5.5 bios, but when using 
'floppy=1', Memdisk reports the 360KB image I load as
'harddrive' ,
while 'floppy' (same for 'floppy=0') reports 'disk image is
a floppy'

Perhaps I should be testing with MSDOS instead of FreeDOS, as the 
bootsector of the disk image is involved?
> MEMDISK itself?  No.
So there's a decompression engine for disk images, but none for 
compressed files you want to run?
That would mean the program you want to run itself would have to support 
(de)compression.

> UTF-8 Unicode *is* text only.
Always nice to learn new things :)

Bernd

Correct. 

FYI (if anybody else is interested in this config), here is what we are
using (short version):

Syslinux boots from HDD, loads memdisk + floppy A: image from HDD.
Syslinux then chainloads to the floppy A: image.

Inside the floppy A: image, we again have syslinux+memdisk. This next
memdisk takes over floppy B: and chainloads the boot sector in floppy
B:.

This is a pretty cool and elegant solution to our problem. :-)
--
Michael
> -----Original Message-----
> From: syslinux-bounces at zytor.com 
> [mailto:syslinux-bounces at zytor.com] On Behalf Of H. Peter Anvin
> Sent: Friday, August 26, 2005 4:06 PM
> To: Bernd Blaauw
> Cc: syslinux at zytor.com
> Subject: Re: [syslinux] SYSLINUX 3.11-pre3 -- release candidate
> 
> 
> Bernd Blaauw wrote:
> > 
> > after that FreeDOS bootsector boots but hangs, probably expects A:..
> > 
> 
> That is most likely.  The reason it was added was to support 
> Dell's need 
> to have recursive memdisk loads.
> 
> 	-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.
>

Michael_E_Brown at Dell.com schreef:
> FYI (if anybody else is interested in this config), here is what we are
> using (short version):
> 
> Syslinux boots from HDD, loads memdisk + floppy A: image from HDD.
> Syslinux then chainloads to the floppy A: image.
> 
> Inside the floppy A: image, we again have syslinux+memdisk. This next
> memdisk takes over floppy B: and chainloads the boot sector in floppy
> B:.
> 
> This is a pretty cool and elegant solution to our problem. :-)
This seems like a horrible solution :)
But if it works, great!

Would MEMDISK be able to integrate the chain.c32 code?

Syslinux.cfg would have to specify:
-which imagefile(s) make up Memdisk floppydrive0, if any
-which imagefile(s) make up Memdisk floppydrive1, if any
-which imagefile(s) make up Disk emulation, if any
-which drive to boot :
  chain.c32 for physical floppies and for memdiskA and memdiskB

This way you could load an imagefile into RAM from Syslinux, and access 
it despite booting from another medium.

To be honest I have no idea how this would be implemented:

# Memdisk floppy A:, Memdisk floppy B:, Real C:, Memdisk harddisk D:
# boot from 0x80 instead of 1 of the emulated disks.
Label MDISK
kernel memdisk
append initrd=floppyA1.img,floppyA2.img c=XX h=YY s=ZZ floppy floppy=0
append initrd1=floppyB.img c=XX h=YY s=ZZ floppy floppy=1 ro raw
append initrd2=harddisk.img c=XX h=YY s=ZZ harddisk harddisk=0x80
append localboot 0x80

ok, this also looks horrible :)

Bernd