Michael Devore <[EMAIL PROTECTED]> writes: > MEMDISK appears to give a great deal of printed feedback, based on > the printf()'s in the code. Is there a lot of information on the > screen from MEMDISK prior to the reboot? IF so, posting that > information here would be handy.
Yes, MEMDISK prints a bunch of information before booting from the "virtual floppy". Here it is: ====================================================================== MEMDISK 2.08 2003-12-12 Copyright 2001-2003 H. Peter Anvin e820: 0000000000000000 000000000009f800 1 e820: 000000000009f800 0000000000000800 2 e820: 00000000000e0000 0000000000020000 2 e820: 0000000000100000 000000000fef0000 1 e820: 000000000fff0000 000000000000ec00 3 e820: 000000000fffec00 0000000000001400 4 e820: 00000000fff80000 0000000000080000 2 Ramdisk at 0xfe60000, length 0x00168000 Command line: initrd=test.img keeppxe BOOT_IMAGE=memdisk Disk is floppy, 1440 K, C/H/S = 80/2/18 Total size needed = 1460 bytes, allocating 2K Old dos memory at 0x8fc00 (map says 0x9f800), loading at 0x8f400 1588: 0xffff 15E801: 0x3c00 0x0ee6 INT13 08: Success, count=1, BPT=f0000:9d36 old: int13=e1f74d1a int15=f000f859 new: int13=8f400008 int15=8f400272 Loading boot sector... booting... FreeDOS FAT Kernel [etc.] ====================================================================== Then I see the FreeDOS intro text, the option to press F5/F8, and ultimately the crash and reboot. > Also, if DOS Is loaded high and the XMS swapper shell is present, > try turning them off to eliminate potential side-effects and > reporting on the results. If I remove "DOS=HIGH", it works! Well, mostly. The keyboard eventually locks up. But it appears to work fine as long as I do not use the keyboard; the boot disk loads network drivers, maps a Windows share, runs cwsdpmi + DJGPP Perl... Unfortunately, I need DOS=HIGH because otherwise there is insufficient conventional memory to run winnt.exe (my ultimate goal). > A very preliminary look at MEMDISK seems to indicate that it > directly queries, accesses, and uses extended memory, operations > which could conflict with an extended memory manager. MEMDISK may > be fundamentally incompatible with HIMEM.EXE (the [64] part of HIMEM > is not an issue here). Of course it's hard to tell exactly what the > thing is doing just by quickly scanning the source code. So I am just getting lucky with fdxms and MS-DOS + himem.sys? Possible, I suppose. > However, if you could track down and communicate with the MEMDISK > author Peter Anvin, and he was amenable, he may be able to answer > critical questions in a matter of minutes and save a lot of work on > the part of others. HPA monitors [EMAIL PROTECTED], and at least one other reader has an interest in this. So I believe this thread is on-topic for both lists. Thank you for the reply! Let me know what else I can do. - Pat _______________________________________________ SYSLINUX mailing list Submissions to [EMAIL PROTECTED] Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
