Re: [Freedos-user] Virtual floppy change problem
Reply to Ralf A. Quint (2012-05-21 00:45) Bertho Grandpied wrote: Raises the question of what a Ramdisk should do in order to properly identify itself to smartdrv... impersonate MS-RAMDRIVE, maybe ;=) For starters, use a media descriptor byte value of 0xFA in the BPB... This may be a good recommendation to make to someone who would write yet another ram drive for DOS systems. However an 'FA' media byte is *not* how MS-Sartdrive, aka Wincache, aka Bambino... would tell a ramdrive from a hard disk partition. Misc notes: - 1. MS-Ramdrive sets its media = F8 2 : contrary to popular belief, a media descriptor = FA *was* used by (some obscure) *real disk gear* known to (MS-)DOS. I suspect a mix of bad faith and lazy coding on behalf of MS, but - whose fault ever it may be, the problem - once recognised! - was easily worked around by explicitly excluding the RD on smartdrive's command line. yeah, that good old Microsoft bashing without hard facts trick, never gets old... :-( A great classic indeed;=) -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Prevent boot from Floppy?
Sun, May 20, 2012 at 5:10 PM, Wolfgang Schechinger hubah...@gmx.de wrote: Der experts, may I ask another question: Is there a way to make FreeDos ignore that there is a floppy present upon boot, i.e. force a boot from the harddrive? Again only a problem when running it in a VM, I think, as on a hard PC, you may set the boot options in the BIOS. Hi. The best option here is not to do this at the operating system level, but at the BIOS level. You mentioned in your email that you can set the BIOS options when booting on a hardware PC. That same BIOS option exists in true virtual machine emulators. If you are using VMWare, VirtualPC, Bochs, or some similar virtual machine emulator, you will have a BIOS present in the virtual machine. When the VM boots, you should see a message to press a key combination (usually f11 or f12) that will bring up the BIOS setup. If you are using a different virtual machine emulator that does not provide a BIOS (such as DOSEmu) then I'm not sure what you can do to ensure FreeDOS boots from hard drive instead of floppy drive, other than not mounting a floppy image on the emulator when you boot it. I hope that helps you. -jh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Prevent boot from Floppy?
On Mon, May 21, 2012 at 4:06 PM, Wolfgang Schechinger hubah...@gmx.de wrote: Hi Jim, your suggestion helped: The boot screen (when booting FreeDos in VirtualBox) normally disappears so quickly, that it actually doesn't show up (visibly) unless you press F12 while launching the VM. This made me realize that I actually need to find a solution to (force to) drop any mounted floppy image before the VM is booted, to prevent that the floppy's boot sector is executed. That's what I actually need. Best reagrds, Wo Glad that helped! You might consider simply removing the floppy image from the virtual machine definition in VirtualBox when you don't need to boot from floppy. Or, you may want to adjust your BIOS boot order, so that floppy appears after hard drive. When I've worked with virtual machines, that's usually one of the first things I do: set the VM BIOS to boot from hard drive first, then CDROM, then floppy. That way, when I boot my fresh virtual machine using a mounted CD image of FreeDOS or Linux, it boots the CD first (because the hard drive doesn't have anything on it yet, no boot loader.) After the installation is done, if I've forgotten to unmount the CD image from the virtual machine, it doesn't matter because the VM will boot from hard drive anyway (because it now is a valid bootable medium.) -jh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why DOS shouldn't be emulated...
On Wed, May 16, 2012 at 4:52 PM, Michael Robinson plu...@robinson-west.com wrote: There has been a fair amount of just run it under emulation being said. One of the advantages of DOS is that it isn't a modern operating system. An easy way to install Freedos safely to a desktop computer involves the following: [...] Now on a 64 bit computer, Freedos may have to be run under emulation. A variant of these instructions is to get a PIII or P4 32 bit computer and dedicate that to Freedos. The problem with emulation is that you are throwing the simplicity of DOS away and introducing compatibility issues. Emulation is getting better and if you are constantly rebooting between Freedos and Linux or Freedos and Windows, emulation may be a necessity. Still, a good KVM switch and a dedicated DOS computer also solves the reboot issue. Freedos will work fine on anything from an 8086 up to a Pentium 4. Don't underestimate the utility of dedicating a computer to DOS. A thought that comes to mind is that you don't want to worry about your kids who are interested in playing video games screwing up your computer. A dedicated DOS machine makes a lot of sense for that. Hardware is sometimes better for running DOS, and sometimes a virtual machine is better for running DOS. It really depends on what you are doing. For example, when I'm writing code for FreeDOS, I'll have a copy of FreeDOS booted in DOSemu. I run Linux, with lots of nifty developer tools and editors, and I just find it's easier for me to do my FreeDOS work there (say, in GNU emacs) while I also have a web browser open for email, or Facebook, or whatever. When it's time to compile, I just bring up the DOSemu window and compile under FreeDOS. Doing this in DOSemu is great for my coding because DOSemu can boot an instance of FreeDOS from a directory on Linux. So when I edit files under Linux, I'm saving them to a directory under Linux, and they are immediately visible to the FreeDOS session in DOSemu. However, let's say I wanted to play DOS games. I might do that under an emulator like DOSemu (and I have) but in certain cases the emulator might just get in the way, not emulate the hardware as well as the DOS game would like. So in that case, it would be better to set up a dedicated PC to play those games. I've helped several friends to do this, set up an older machine (which would otherwise be tossed out) to play DOS games. That old PC may not run the latest version of Windows very well, but it does a great job of playing DOS games. Similarly, there are lots of cases where dedicated hardware is better. Controllers, embedded systems, etc. all require actual hardware to do the job. You wouldn't set up a Linux box just to run DOSemu + FreeDOS, to support an embedded application. You can do a multiboot system with FreeDOS on it, no problem. What you've described would work. I used to use a program called PC Commander (I think that was the name) that was a great multiple operating system loader, and we used this at my work when we first moved to Windows 95, long ago. GRUB, XaoS, and other free boot loaders will do the same job. My personal preference is: if I'm going to set up a hardware system with FreeDOS on it, I'd rather it be a dedicated system. Nothing wrong with doing a multiboot system, just my preference. Simpler that way, less to go wrong. -jh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Jack, kernel experts, On REAL (old) PC hardware, the existence of floppy disk changelines is not guaranteed; even if the line is present AND properly connected it MIGHT be flaky or not work at all; or the BIOS might not update the bits you expect. MS-DOS (and, I presume, good DOS clones as well) will use alternate means and kluges to check for media change in the absence of a (credible) change line. Your DOS drivers could have been relying on DOS for checking media change, not on the BIOS or direct HW interrogation in the 1st place! When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software. Maybe FreeDOS does this, maybe not? Is a change in label / ID always a trigger for a change event, or only in context of having detected hardware reliability troubles before? Offering the user an option to switch diskette caching off is much better. As you are aware, SMARTDRV allows a user to select... I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an int 13h drive reset command which in turn can be caught by the UIDE2 driver and treated as a flush cache for THAT drive event? Depending on other factors, even flushing the caches for all drives or all floppies would still be better than a situation where the cache still contains data from old disks which are no longer inserted in the drives: Rather be SAFE, have some performance loss (due to extra flushes, less cache efficiency is reached and the flush itself also takes time) than SORRY (data loss due to mismatch in cache / real data). If the kernel issues eg. int 13.0 after detecting a floppy change - which it should be able to do even if the change line is unreliable - and UIDE2 reacts to that with a flush, DOS can take care of the reliability while UIDE2 still only has to care about int 13 calls :-) Also this makes it safer to use UIDE2, as is does not need manual /N safety options. -- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! Thanks :-) By the way, any chance to work around the VirtualBox huge-delay problem? Apart from configuring VirtualBox to use a different virtual chipset, I mean. It seems that UIDE2 code, in particular I_ScnC, I_PCIC and I_PCID uses BIOS calls (not fast? raw I/O) to scan ALL possible bus/device/function numbers, thus ignoring the last used bus number returned by int 1a.b101.0? If you prefer the BIOS way, would int 1a.b103 be an option? It scans by PCI class so you do not have to loop over bus/device. Just some ideas, of course, but might also help to make UIDE2 more robust with other flawed hardware or BIOS versions :-) Note that for example PCISLEEP only uses raw I/O in getpci and skips looping over functions if function 0 of a bus and device number pair return PCI ID -1. So you scan only 1 out of 8 in such cases. Each bus has 32 device numbers to scan. Also, often you have far less than 256 bus numbers in use, saves much time. By the way, PCISLEEP only supports the newer mechanism 1, the ancient mechanism 2 for I/O is not supported but rarely used. See also: http://wiki.osdev.org/PCI and also note that SYSLINUX 3.05 calls mechanism #2 a hideous old hack yet supports it: http://www.syslinux.org/old/history.php As you see in PCISLEEP source code, mechanism #1 is easy and compact to implement :-) Regards, Eric PS: The UIDE issue is described in Ulrich's wiki page which also is a good GENERAL how to install FreeDOS 1.1 on empty harddisk document :-) I would also suggest to make /NOHI the KEYB default! The KEYB thing might be due to rawer-than-EMS-style UMB attempts? http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8 http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9 PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to one of the default driver sets in FreeDOS 1.1 config / autoexec. http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_7#Possible_Solutions:_2._Use_DOS_Power_Management -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Eric, When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software ... How does DOS ever detect that any hardware is unreliable?? I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an Int 13h drive reset command which in turn can be caught by the UIDE2 driver and treated as a flush cache for THAT drive event? ... What do you mean maybe?? You and others are the kernel experts for FreeDOS, not me, as I still run V6.22 MS-DOS!! Also, I say again that I am NOT interested in any specific logic from the MS-DOS kernel, or the FreeDOS kernel, or in fact ANY kernel, for detecting diskette changes. My worry is that such logic may NOT be generic, and I want UIDE or UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes (despite Bertho's worries about flaky change lines!), and so I will leave my drivers that way. Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS system calls and I also want to keep THAT generic feature in my drivers, as well! -- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! Thanks :-) By the way, any chance to work around the VirtualBox huge-delay problem? Not without knowing WHY they take such a huge delay! In any case, UIDE and UIDE2 must scan for PCI-bus devices, so they can relate the PCI device-addresses to the addresses posted via Int 48h requests. That way, I know the UltraDMA address to use for every controller, since UltraDMA addresses are NOT part of Int 48h -- BAD error by the EDD BIOS people, in 1995! If the VirtualBox people cannot fix the huge delay in their PIIX3 logic, UIDE or UIDE2 still have their /E switch and can still do disk caching, after the BIOS handles disk I-O. If you prefer the BIOS way, would int 1a.b103 be an option? It scans by PCI class so you do not have to loop over bus/device. My drivers are ALREADY doing a PCI scan by class-code, so the huge-delay problem is not related to this. Note that for example PCISLEEP only uses raw I/O in getpci and skips looping over functions if function 0 of a bus and device number pair return PCI ID -1. So you scan only 1 out of 8 in such cases. Each bus has 32 device numbers to scan. Also, often you have far less than 256 bus numbers in use, saves much time. Doesn't matter. A scan for devices by PCI class-code returns only devices that match the requested class/subclass/function, so I lose no time by checking unnecessary busses/devices. In any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running VirtualBox! Also, better if you refer to UIDE in general, since UIDE and UIDE2 assemble from the same UIDE.ASM source and do nearly all the same initialization functions. A few differences re: how they allocate XMS memory and where they load, but their device scanning and setup is 100% the same. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
-- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! I've never looked at UIDE closely, but there's always room for space improvement in assembly!! ;-) Maybe you should look again at the UIDE.ASM source file! I have boiled down its logic so many times that finding any MORE spare bytes is REALLY becoming difficult, even for me!! VBox lets you choose how much % of processor to use, so it doesn't have to use 100% all the time. I just wonder whether their bugs are due to their tweaked BIOS or some hidden instruction incompatibility or what. :-/ My own personal guess is that their bugs are more likely due to incompetent BRATS messing around with hardware about which they really are NOT qualified to mess with!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
