Re: [Freedos-devel] FDISK: how to handle sector size != 512?
> the kernel *should* work with sector sizes != 512 (as MSDOS > reportedly does), but it simply doesn't. I Think PerditionC tried to > make this work, and was successful for 256, 512, 1024 and 2048. > unfortunately he didn't succeed for 4096 (I don't know the reason) > so the FreeDOS kernel is stuck at 512 byte. no need to support > anything else (in the context of freedos). I would disagree about "no need to support", if for no other reason than MS-DOS does it (I've tested) and did it even in VERY early versions (not sure exactly which version it started -- it may have been there from the very beginning). The way MS-DOS works is that there is one word in the List of Lists which is the maximum supported sector size for _any_ disk in the system. The default value is set to 32 bytes, but this is changed while booting to match the largest sector size of any disk mounted (whether directly by the kernel or by a driver in CONFIG.SYS). The MS-DOS kernel consistently uses the value stored in the LOL for calculations after booting, and never just assumes 512 bytes. I'm not sure whether the MS-DOS utilities (like FORMAT and FDISK) can handle anything other than 512, but I know for sure the kernel can. You can modify the LOL word in MSDOS.SYS to make a permanent change to the kernel, and a small "tutorial' on how to do that with DEBUG is included in the comments near the top of the source code for my USBDRIVE program. You can also install a device driver for something that includes sectors larger than 512. What I usually do is install TurboDisk (TDsk.Exe) which is a RAM drive that supports sector sizes up to 2048 bytes. I tell Turbo Disk to install a RAM drive with a 2K sector size and then I can use, for example, a DVD-RAM (which has 2K sectors) formatted with FAT32 as a sort of "giant floppy". Of course, that only works with MS-DOS (and probably PC-DOS) since most other DOS's (including FreeDOS) don't work with sector sizes other than 512. In terms of the FreeDOS kernel supporting sector sizes other than 512, there would probably need to be a LOT of changes. One major thing I can think of are the BUFFERS, since the BUFFERS would either need to be compatible with different sector sizes (and not just assume 512) or the BUFFERS couldn't be used for disks that aren't 512. > there *are* 4096 byte sector disk out in the wild: > (a) 4kn (4knative) disk export their 4k sector size to the OS and > don't emulate 512 byte sectors. > > (b) some external USB disks export 4K sector size even when the > internal disk has 512 byte sectors. I think they do this to be able > to have 16 TB external disks, even with MBR partitioning. I haven't seen a USB disk that does that, but don't doubt that they exist. The specific example I can think of which has been around even longer than USB are DVD-RAM disks which have a 2k sector size. DVD-RAM's have gone way out of fashion and the media is pretty scarce these days, but a lot of modern CD/DVD/BD players still support DVD-RAM. You can format DVD-RAMs as either UDF or FAT32, and if they are formatted as FAT you can read them directly with an MS-DOS kernel. One of the things I'm doing is modifying my USBDRIVE program to support CD/DVD/BD USB players. If the disk inserted in the player is formatted as something other than FAT, the disk is presented as a "CD" and expects MSCDEX or SHSUCDX or something like that to handle the format interpretation. If the media is formatted as FAT (usually FAT32) it is presented directly to the DOS kernel as a "removable hard drive" similar to how USBDRIVE presents a flash drive to DOS and lets the kernel do the format interpretation. I'm not in a position to test right now, and I don't remember if Windows formats a FAT32 DVD-RAM as a hard drive (with an MBR and only one partition) or formats it as an un-partitioned "super-floppy". A DVD-RAM is big enough that being able to divide it into multiple partitions seems like it would be a handy feature. I'm also going to experiment with FAT formats on rewritable CD/DVD/BD media, but I'm not sure how well that will work. I don't think FAT formats on rewritable CD/DVD/BD media (other than DVD-RAM) are supported by Windows (but they may be supported by Linux?), and rewritable media has a _much_ shorter lifespan than DVD-RAM. With all the writing needed to the same area of the disk (the FAT) to store files "randomly", it's probably not going to be very reliable. But I'm going to test and see. > there is no point in this; CHS addresses the exact same sectors as > LBA. I think I agree. CHS isn't going to give you any advantage over LBA. I think I would make LBA the 'default" and only use CHS when there is no choice. And, I think you should support sector sizes other than 512 right away even though you don't see a lot of practical use right now. Having the capability already there certainly isn't going to hurt anything and will keep you (or
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
> ... > So four cores? But only one core is running under DOS (albeit at max > clock speed). > ... Several somewhat interesting factoids (specific CPU instructions, levels and sizes of caches, USB speed, pipelining, ips, etc.) but mostly irrelevant to the discussion at hand. > So what instructions are you testing? You can download the source code for SLOWDOWN if you want. But the basic routine that is being tested essentially performs every CPU instruction available on an 8086/8088 CPU. Nothing that requires a 286+ CPU is performed (at least not in that part of the program). SLOWDOWN is compatible with even an 8088, though you normally wouldn't want to slow down an 8088 CPU any more than it already is. > ... > I suspect you may not believe my results, but they are nonetheless > real. > > Sometimes regressions happen. It's a tradeoff. This is something much more serious than a "tradeoff" or a "regression". My new i5 CPU appears to be spending _at least_ 99% of its resources NOT processing OpCodes and NOT accessing the cache (because there isn't one). And the problem is blamed on "sub-optimal code". I don't know what the CPU is doing with all those resources it has, but I do know what it's NOT doing. I do know that what's going on inside a CPU is very complicated. Call me naive, but I always thought the primary purpose of a CPU was to process OpCodes. Silly me. > ... > AMD's Ryzen just turned six years old last week... I just read an article on Ryzen CPU's the other day that talked about the reason they were "better" than an Intel was because of something called a 3D cache. I'm not sure if the 3D cache is a different cache hardware architecture or a different relationship between the different caching "levels" or a different caching algorithm or some combination (or something else than any of those), but for the discussion here it is still a "cache trick" that has nothing to do with actual CPU speed. The same article said that the 3D cache makes certain applications slower, so to really take full advantage the software must be "optimized" to meet the special characteristics of that specific cache. > IA-32 is dead. Nobody wants it anymore. Maybe they're only > optimizing cpus for 64-bit... If nobody wants it anymore then why do Virtual Machines that emulate IA-32 (and even lesser CPUs like 8088) even exist? They said DOS was dead a LONG time ago and yet here we are on a FreeDOS forum. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
> Am 17.03.2023 um 19:25 schrieb tom ehlert : > > in that case: WHAT REGRESSIONS? To name one: The text editor segfaulted right after start. Can happen if you are using a development snapshot. It is fixed by now because the current maintainer is very committed to solving the bugs and tracks them thoroughly at https://github.com/open-watcom/open-watcom-v2/issues The software is in flux and a „stable“ build has not been released. A development snapshot may be shipped as the main C compiler, but one should be prepared for surprises. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
> IDLEHALT=1 works for my machines and reduces the CPU load under > VirtualBox to nearly zero at the command prompt. :-))) FDAPM whatever should be REMified. OTOH this seems to be a problem between FDAPM, VirtualBOX and Watcom Installer. Whoever wants to develop ON FreeDOS ... >> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net: >> >> On a side note… Why run the watcom installer at all? Installing the FreeDOS >> WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded >> takes about 1 minute inside VirtualBox. We could most likely just provide a >> WATCOM2C package and avoid the whole issue completely. +1 > If v2 is packaged would it be possible to continue shipping the 1.9 > branch in parallel? NO. Anyone who hasn't installed watcom so far won't be able to answer this question. and anyone able to answer this question will be able to download the other version. and, of course, developing ON FreeDOS is self flaggelation ... > My impression is that the v2 fork focusses on > adding new stuff: Linux support, 64-bit and so forth… And from time > to time they seem to break older stuff. I at least under Win9x encountered > some regressions. in that case: WHAT REGRESSIONS? Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
IDLEHALT=1 works for my machines and reduces the CPU load under VirtualBox to nearly zero at the command prompt. > Am 17.03.2023 um 15:25 schrieb jer...@shidel.net: > > On a side note… Why run the watcom installer at all? Installing the FreeDOS > WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded takes > about 1 minute inside VirtualBox. We could most likely just provide a > WATCOM2C package and avoid the whole issue completely. Yes, was only for testing purposes :-) If v2 is packaged would it be possible to continue shipping the 1.9 branch in parallel? My impression is that the v2 fork focusses on adding new stuff: Linux support, 64-bit and so forth… And from time to time they seem to break older stuff. I at least under Win9x encountered some regressions. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
I ran a test with idlehalt=0 / -1 / 1 and put fdapm to rem in virtualbox Fast speed with 0 and 1! idlehalt=-1 gave slow speed. After this I removed idlehalt and activated fdapm again - and then ran fdapm off : fast speed. Willi Am 2023-03-17 15:34, schrieb jer...@shidel.net: > On Mar 17, 2023, at 10:07 AM, Rugxulo wrote: > > Hi, > > On Fri, Mar 17, 2023 at 5:32 AM wrote: > At present, the FreeDOS installed system and installer boot media load FDAPM > on many hardware configurations and virtual machines. > > As most are aware, there has recently discussed issue that the watcom > installer was taking an excessively long time to install. The problem only > occurred when FDAPM was loaded. This was regardless of which power saving > options were used. Should we cut back on when it is loaded? > I almost forgot that the Borland IDE tools were also slowed down when > FDAPM was loaded. That is a known issue. > > What I'm thinking is we more or less keep things as they are. But, add an > exception to the various AUTOEXEC files that skips loading it as a driver > when the OS is running under a known VM like VirtualBox, VMware, etc. > > Any thoughts? > Yeah, just turn it off if under a VM (and document why with a REM > comment). Oh, and turn on IDLEHALT like Tom suggests. Sorry, I forgot about it effecting other things as well. So, just making a WATCOM2 package would not solve any other slowdown issues. Assuming, there is no large slowdown in the watcom installer with IDLEHALT. Tom's suggestion of using IDLEHALT is most likely the best solution. As you suggest, Using IDLEHALT for VM's and FDAPM for real hardware on installed systems will be easy to do. Since such decisions cannot be made automatically during boot in the CONFIG at present, probably just switch to using IDLEHALT on the LiveCD as well. :-) Jerome > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
> On Mar 17, 2023, at 10:07 AM, Rugxulo wrote: > > Hi, > > On Fri, Mar 17, 2023 at 5:32 AM wrote: >> >> At present, the FreeDOS installed system and installer boot media load FDAPM >> on many hardware configurations and virtual machines. >> >> As most are aware, there has recently discussed issue that the watcom >> installer was taking an excessively long time to install. The problem only >> occurred when FDAPM was loaded. This was regardless of which power saving >> options were used. Should we cut back on when it is loaded? > > I almost forgot that the Borland IDE tools were also slowed down when > FDAPM was loaded. That is a known issue. > >> What I’m thinking is we more or less keep things as they are. But, add an >> exception to the various AUTOEXEC files that skips loading it as a driver >> when the OS is running under a known VM like VirtualBox, VMware, etc. >> >> Any thoughts? > > Yeah, just turn it off if under a VM (and document why with a REM > comment). Oh, and turn on IDLEHALT like Tom suggests. Sorry, I forgot about it effecting other things as well. So, just making a WATCOM2 package would not solve any other slowdown issues. Assuming, there is no large slowdown in the watcom installer with IDLEHALT. Tom’s suggestion of using IDLEHALT is most likely the best solution. As you suggest, Using IDLEHALT for VM’s and FDAPM for real hardware on installed systems will be easy to do. Since such decisions cannot be made automatically during boot in the CONFIG at present, probably just switch to using IDLEHALT on the LiveCD as well. :-) Jerome > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
Hi, > On Mar 17, 2023, at 7:58 AM, tom ehlert wrote: > > Hallo Herr Bernd Boeckmann via Freedos-devel, > > am Freitag, 17. März 2023 um 12:52 schrieben Sie: > > >>> Any thoughts? > >> I have some additional data: > >> 1) Pentium MMX 166, T2303 default installation: > >> Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes. >> After FDAPM OFF: 4:30 Minuten. > >> 2) VirtualBox, activated APM: aborted after 2 minutes @ 10% > >> 3) VirtualBox with LH FDAPM ADV:REG same as 2) > >> 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-) > >> BUT! > >> Disabling FDAPM under VirtualBox significantly increases the CPU >> load on the host system! It essentially maxes out one CPU core. > > could you test also > > CONFIG.SYS: > > IDLEHALT 1 > > > which might be still fast, but saves most of the energy. > Tom Having the system decide wether to us FDAPM, IDLEHALT or nothing inside the CONFIG.SYS at boot time is not practical at present. However during installation process, the installer can make adjustments or install different config files based on hardware or virtual platform. So, using IDLEHALT instead of FDAPM when booting an installed system inside a VM would be easy to do. Also… I’m not sure if during testing anyone tried to boot with things as they are now. Then, simply turn it off before running the watcom installer. By running: FDAPM APMoff On a side note… Why run the watcom installer at all? Installing the FreeDOS WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded takes about 1 minute inside VirtualBox. We could most likely just provide a WATCOM2C package and avoid the whole issue completely. :-) Jerome > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
Hi, On Fri, Mar 17, 2023 at 5:32 AM wrote: > > At present, the FreeDOS installed system and installer boot media load FDAPM > on many hardware configurations and virtual machines. > > As most are aware, there has recently discussed issue that the watcom > installer was taking an excessively long time to install. The problem only > occurred when FDAPM was loaded. This was regardless of which power saving > options were used. Should we cut back on when it is loaded? I almost forgot that the Borland IDE tools were also slowed down when FDAPM was loaded. That is a known issue. > What I’m thinking is we more or less keep things as they are. But, add an > exception to the various AUTOEXEC files that skips loading it as a driver > when the OS is running under a known VM like VirtualBox, VMware, etc. > > Any thoughts? Yeah, just turn it off if under a VM (and document why with a REM comment). Oh, and turn on IDLEHALT like Tom suggests. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
Hallo Herr Bernd Boeckmann via Freedos-devel, am Freitag, 17. März 2023 um 12:52 schrieben Sie: >> Any thoughts? > I have some additional data: > 1) Pentium MMX 166, T2303 default installation: > Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes. > After FDAPM OFF: 4:30 Minuten. > 2) VirtualBox, activated APM: aborted after 2 minutes @ 10% > 3) VirtualBox with LH FDAPM ADV:REG same as 2) > 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-) > BUT! > Disabling FDAPM under VirtualBox significantly increases the CPU > load on the host system! It essentially maxes out one CPU core. could you test also CONFIG.SYS: IDLEHALT 1 which might be still fast, but saves most of the energy. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
> Any thoughts? I have some additional data: 1) Pentium MMX 166, T2303 default installation: Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes. After FDAPM OFF: 4:30 Minuten. 2) VirtualBox, activated APM: aborted after 2 minutes @ 10% 3) VirtualBox with LH FDAPM ADV:REG same as 2) 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-) BUT! Disabling FDAPM under VirtualBox significantly increases the CPU load on the host system! It essentially maxes out one CPU core. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Booting and FDAPM
Hi All, At present, the FreeDOS installed system and installer boot media load FDAPM on many hardware configurations and virtual machines. As most are aware, there has recently discussed issue that the watcom installer was taking an excessively long time to install. The problem only occurred when FDAPM was loaded. This was regardless of which power saving options were used. Should we cut back on when it is loaded? There have been comments in the past similar to (paraphrased) “my 486 sounds like a vacuum cleaner when just sitting here idle”. So, I don’t think we should just REM it out under all situations. However, I don’t think there is much benefit to loading FDAPM when running inside a Virtual Machine. What I’m thinking is we more or less keep things as they are. But, add an exception to the various AUTOEXEC files that skips loading it as a driver when the OS is running under a known VM like VirtualBox, VMware, etc. Any thoughts? Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
