Hi Jim, others,
> Mercury Thirteen means this: > https://sourceforge.net/p/freedos/bugs/212/#1b4c > I'm not sure why VirtualBox has this problem. I don't recall that we > saw this when wen tested the FreeDOS 1.2 distribution, did we? Or > did VirtualBox have some regression? I use a different VM, so I don't > know. For those without HTTPS SF compatible DOS browsers or extra time... Andrew Pennebaker wrote 2018-05-05 about freedos12: > I am trying to install FreeDOS in a virtual machine using VirtualBox, > but a few seconds after I press Enter to begin the installation > process, I get an infinite scrolling list of "Invalid Opcode" > errors. > I'm using FreeDOS 1.2, in VirtualBox 5.2.10, in macOS 10.13 High > Sierra. Jim originally suggested to use the /NOINVLPG option for JEMM386 based on http://wiki.freedos.org/wiki/index.php/VirtualBox and disabling AHCI mode and selecting legacy IDE mode in BIOS setup, but later he wrote: > An alternative solution I've seen mentioned elsewhere is adding the > raw parameter to memdisk in the boot menu. > When you boot the FreeDOS install CDROM, when you get the get the > first "Welcome to FreeDOS 1.2" boot menu, press Tab when you're on > "Install to harddisk" and add 'raw' (without quotes) to the kernel > command line, then press Enter to boot. > From this: KERNEL /boot/syslinux/memdisk > To this: KERNEL /boot/syslinux/memdisk raw According to https://www.syslinux.org/wiki/index.php?title=MEMDISK that magic "raw" parameter is about memory access and sizing: https://www.syslinux.org/wiki/index.php?title=MEMDISK#Memory_access_method > Memory access method > MEMDISK normally uses the BIOS "INT 15h mover" API to access high > memory. This is well-behaved with extended memory managers which load > later. Unfortunately, it appears that the "DOS boot disk" from WinME/XP > *deliberately* crash the system when this API is invoked. The following > command-line options tell MEMDISK to enter protected mode directly, > whenever possible: > raw Use raw access to protected mode memory. > bigraw Use raw access to protected mode memory, and leave the > CPU in "big real" mode afterwards. > int Use plain INT 15h access to protected memory. This assumes > that anything which hooks INT 15h knows what it is doing. > safeint Use INT 15h access to protected memory, but invoke > INT 15h the way it was *before* MEMDISK was loaded. > This is the default since version 3.73. So apparently VirtualBox has a problem in the int 15 memory copy API!? If that is the case, then I would expect HIMEM to have problems as well, while EMM386 should have fewer problems as it uses protected mode directly in more cases? Or is this just about some special case of reentrancy? Related to how *both* MEMDISK and LBACACHE try to use memory beyond 1 MB, one for the disk image, the other for XMS cache? In the latter case, LBACACHE should be told to not cache a MEMDISK. The best solution would probably be to improve the VirtualBox BIOS?? Another idea would be to try the MEMDISK "int" option which respects int 15 hooks, because HIMEM probably has to hook int 15 as well and the "safeint" default of avoiding new hooks might be exactly wrong? It would be cool if some VirtualBox owners could do some testing :-) Thanks! Regards, Eric PS: Do we know whether NOINVLPG actually helped in THIS situation? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
