Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Hi, On Mon, May 21, 2012 at 11:52 PM, Jack gykazequ...@earthlink.net wrote: 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!! I wouldn't be that harsh, it's a complex processor family, pun intended. ;-) But I do take issue with the idea that it's open source, fix it yourself. Seriously, anybody who's ever tried to build most free/libre software has seen how ungodly it often is. (Though closed source is presumably just as bad, maybe worse.) Why coders are so ... mind-numbingly opaque is beyond me. https://www.virtualbox.org/wiki/Build_instructions VirtualBox seems no different. Though of course I'm only peering at the Windows portion, so I'm a bit biased, but you gotta start somewhere. Without even downloading a lick of code, I'm confronted with a *TON* of dependencies: https://www.virtualbox.org/wiki/Windows%20build%20instructions Red flags that make me want to scream: * kBuild (modified GNU make) that has currently 0.5 people on the planet that fully understand it * MinGW (old GCC 3.3.1, not 3.4.[25] which won't work) * rare build issues on various Windows (2k, Vista) for obscure reasons, e.g. requiring Cygwin Ash shell explicitly (and no support at all for Jack's favorite NT 4) * Qt 3.3.x (not 4.x) needed for frontend Granted, I know some of this is unavoidable: things change, regressions happen and new versions are released, different devs prefer different build tools, but I just really hate the complexity in building things. It's no wonder that more platforms aren't supported or that more people don't contribute ... it won't freakin' build! IT'S TOO VOLATILE! (Yeah yeah, welcome to the world, software has always been like that. Though I don't have to enjoy it.) -- 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, How does DOS ever detect that any hardware is unreliable?? I do not know, but earlier in this thread, somebody said that the numbering of FAT filesystem exists, among other reasons, to help DOS detect floppy changes even if there is no change line available. The FAT file system is defined by DOS, and I want UIDE/UIDE2 to have NO run-time dependencies on the DOS system. As you know, int 13.15 can even report that a floppy has no change line at all ... I did not know this, but no-matter. UIDE/UIDE2 check the BIOS data table for diskette change-line availability, and they also check the table for diskette media change status prior to any diskette read/write. In my opinion, this is the same as doing an Int 13h request addressed to a diskette. BUT, this AVOIDS re-entrant Int 13h calls, as UIDE/UIDE2 have already been entered due to the I-O request! I believe such calls are DANGEROUS, and that is a big reason why my drivers do NO such calls (Int 13h, Int 21h, etc.) at run-time! They also do NOT permit re-entrant I-O requests, i.e. one more I-O before the current I-O has completed! Helps to keep UIDE/UIDE2 safe! Int 13.16 which actually queries the change line can return invalid command, drive not ready / not present, no change or change line active or not supported. NOTE that calling the check also clears the status, so only ONE caller will notice each change and only ONCE! Lbacache takes special care here. UIDE/UIDE2 do also, in fact by NOT issuing any Int 13h diskette requests at run-time! They check the BIOS data table instead! As you see, a very long chain of events exists around all DOS block device related things ... Too complex, TOO MUCH for a 7K-byte driver like UIDE2 (7.5K for UIDE), and rather irrelevant, to me. I have noted before that UIDE/UIDE2 process only Int 13h I-O requests and so are NOT, in fact, either a block device driver or an actual DOS driver. At run-time, they work as BIOS drivers and are absolutely NOT concerned re: DOS, only with Int 13h I-O calls, or subroutine calls from SHSUCDX and/or external drivers that desire caching. I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable ... What do you mean maybe?? You and others are the kernel experts for FreeDOS, not me, as I still run V6.22 MS-DOS!! As you see above, handling of floppies and their changes is a complicated thing which is not easy to walk through, even for me :-) You should find out exactly what the FreeDOS kernel does, if it does anything special at all, when handling a diskette media- change. If it does NOTHING special, then you may understand exactly why I tend to AVOID any DOS functions, except during my drivers' initialization. As far as I can tell, you could make int 13.0 (disk reset) and reads of the boot sector flush events ... Never heard of boot-sector flush events, and in any case what you ask here would demand re-entrancy in UIDE/UIDE2. Like I note above, I want to AVOID re-entrant calls to the BIOS or any run-time calls at ALL to DOS. UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes See above - if you ACTIVELY call int 13.16, you could hide the floppy change from DOS because int 13.16 returns changed status only for the first call after a disk change even with working change lines ... NO re-entrant calls!, I say again! Having UIDE/UIDE2 issue an Int 13h of their own WOULD require re-entrancy! Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS system calls and I also want to keep THAT I agree that it is good to not call DOS in a DISK cache and actually it should not be necessary to call DOS either :-) You can bet your [rear-end] on THAT issue! ;-) Note that things might be different for block device based caches instead of BIOS / hardware based caches like ours... No argument there, since anyone can note the memory usage of UIDE/UIDE2/LBAcache versus SMARTDRV/NCACHC2/etc.! 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... If I understand your code correctly, you scan all 256 bus, 32 device and 8 function locations which can be expressed, using the BIOS ... NO, I do NOT scan busses!! I scan PCI class, subclass, and function codes, as I would rather NOT have to determine WHAT actual busses are present. A class-code scan is a lot more generic and will TELL me what PCI bus a device is using! 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... Not by iterating over locations, you mean? Certainly NOT, as only the PCI BIOS can tell me where it has assigned each I-O device to run!! Doesn't matter. A
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Eric, Do try to understand, as my damn ex-wife never did [part of why she BECAME my ex- 32 years ago!!], that I have a REASON for everything I say and do, same as for everything in UIDE Just making suggestions for universally faster and more fool-proof UIDE, as I dislike the idea that people have to manually disable floppy caches or tweak their (virtual) hardware to properly load UIDE ... To make a long story short, after my one and your two long posts today, I see NO reason for any further changes in UIDE or UIDE2. Its PCI-bus scan is now virtually instantaneous, and its diskette media-change logic works, without problems. So I will obey our other U.S. engineering joke (along with our K.I.S.S. Principle), which is Don't MESS with SUCCESS! (and mess is the polite word!). With good hardware, UIDE/UIDE2 have run just fine from about late 2006 onward. With imperfect hardware, or any dumb emulator program, UIDE/UIDE2 users are now able to -- (A) Call the BIOS for disk I-O and so avoid disk PCI scans with /E, which still caches disk data after the calls. (B) Ignore hard-disks completely [no caching] with /N1. (C) Run unusual CD/DVD drives via PIO mode [no UltraDMA] with /UX. CD/DVD drives still demand a PCI scan, since they are not declared to me by the BIOS during init. (D) Ignore CD/DVD drives completely [no caching] with /N2. (E) Ignore diskettes completely [no caching] with /N5. I think that is ENOUGH to include in UIDE/UIDE2! Those who use VirtualBox or other imperfect garbage, who do not like having to forego some UIDE drive caching by using the above, should damned-well INSIST that VirtualBox etc. gets FIXED! I am VERY TIRED of having to add Band Aids into my drivers to deal with the FOOLISH errors of OTHERS!! 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
Op 22-5-2012 6:21, Rugxulo schreef: Is anybody working on FD 1.2? I haven't heard anything (and don't think we need it just yet anyways). Switching things around is, I guess, that person's ultimate decision (Bernd??). I'm indeed working on a FreeDOS 1.2 as 1.0 and 1.1 didn't meet up to my own expectations ( 1.0, despite Blair and Jeremy's awesome work, lacks some features I'd like, and 1.1 lacks lots of things present in the full 1.0 ISO). I hate to open up a can of worms (so tedious ...), but did Bernd or Jeremy ever publish any scripts to build the .ISOs? Meh, just the idea sounds difficult. Bah. But we can still dream, can't we? ;-) I'm doing stuff manually mostly, in Windows. No source code management system, no compilers, build environments, packing scripts and building scripts. Jeremy's FDOS (FreeDOS Distribution Of Sorts) has more automation behind it, and I guess Blair had lots of automation as well. It already shows the difference between structured approach by programmers versus my own ad-hoc approach. PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to one of the default driver sets in FreeDOS 1.1 config / autoexec. 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. :-/ I've seen some slower performance when FDAPM is active so I'm a bit cautious at installation time. At runtime it's great though. I'm not ready to disclose anything about 1.2 yet as there's still lots of structural stuff to integrate and rewrite. Bernd -- 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
Op 22-5-2012 16:05, Jack schreef: PCI V2.0C and later versions have all worked just FINE, until the rather poor emulator know as VirtualBox appeared, using its MISERABLE emulation logic for the Intel PIIX3 chipset!! If they DO NOT have such long delay trouble with their ICH9 emulation logic, do you REALLY expect we should believe the PCI BIOS logic is now at fault, after almost 20 years?? The VirtualBox brats should take a long-hard look at their ICH9 v.s. PIIX3 routines, and CORRECT those for the PIIX3!! The easiest case is to have a bootdisk with UIDE on it, and present it to the VirtualBox people as hey this completes in under 7 seconds on all hardware platforms and every popular emulator, except yours. Actually, an autoexec.bat like this should do fine: @ECHO OFF RUNTIME DEVLOAD UIDE.SYS /S5 /H /D:CDROMDRV with a corresponding config.sys of: DEVICE=XMGR.SYS /PA (the /PA is optional but seems to be more stable for A20 on anything Syslinux/Memdisk related, especially in VMs) Simply run the bootdisk under various hardware environments and write down the reported time. -- 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
