DOS ain't dead

> I am just guessing here - I used ST for the screen capture - and if there
> was a "glitch" in the process during the actual screen capture (of the text
> DOS screen), of ONE BYTE for the ascii attribute (i.e. the "9" was misread
> say) - then ...

Seems pretty unlikely. But then, that time is unlikely, too.

> How many times would you like me to re-run the whole set and how many times
> just only for 9.bat?

Once (with rt) should be enough, since it's only a relative test. The real question is why it's so slow (the RAM drive in particular).

> I did a general enquiry on
> this thread earlier ( I think to Tom) on how/where to source alternatives
> to FreeDOS so that I could on a case by case basis select between FREEDOS
> and alternatives - but no one has replied on that yet.

Maybe it would help if we knew what you were actually wanting to do? 64-bit Linux might be the better choice...


I've updated RDRVSX32 (remember that? :) ) to search the parent environment for DL=? and replace the ? with the first assigned drive letter. If there's no problems with that I'll update the SHSU programs to use it.

>
>
> Smartdrv is a disk-cache and no "drive" - and its max is 32MB. I use it
> with 8MB. Smartdrv does speed up doslfn significantly. Be sure to load it
> AFTER doslfn.
>
>


Question - when running in a continuous DOS session (no re-boots) and I have hundreds of install/uninstall doslfn(MS) - do I have to reload smartdrv again with each doslfn. That is, once smartdrv is installed after the first doslfn install, will it continue to work with all subsequent doslfn installs?

> The real question is why it's so slow (the RAM drive in particular).

Perhaps it's not related to doslfn at all. It might be a BIOS bug, setting up memory beyond 4GB as "uncachable" via MTRRs. I remember that, when HimemSX was introduced, another member of this forum (Zyzzle?) had such problems.

---
MS-DOS forever!

> Question - when running in a continuous DOS session (no re-boots) and I
> have hundreds of install/uninstall doslfn(MS) - do I have to reload
> smartdrv again with each doslfn. That is, once smartdrv is installed after
> the first doslfn install, will it continue to work with all subsequent
> doslfn installs?

I'm pretty sure that you can't unload doslfn after smartdrv has been loaded.

---
MS-DOS forever!

> > The real question is why it's so slow (the RAM drive in particular).
>
> Perhaps it's not related to doslfn at all. It might be a BIOS bug, setting
> up memory beyond 4GB as "uncachable" via MTRRs. I remember that, when
> HimemSX was introduced, another member of this forum (Zyzzle?) had such
> problems.

he should start without CONFIG.SYS and AUTOEXEC.BAT (and the guarantee that no offenders are lurking in his system)

compare apples to apples.
have a batchfile to *consistently* create a directory with known size(see below) and known content. size, because a directory that once held Japhets 10000 files and at least 20000 directories will never shrink again.
huge directories are a problem for the way COMMAND generates long filenames.
when iterating over short filenames DOS knows where exactly to look for the next filename, and the sector is most often already in a buffer. to translate this short name into a long name it always starts at the beginning of the directory, and iterates on average half of the entire directory (which is clearly suboptimal).




now see what the times are for the USB drive, and if they are significantly different from WITH config/autoexec. if so, find the culprit.

then compare himemX (4 GB only) and himemsx (but also 4 GB).
are there significant differences? there shouldn't, but it's possible.

compare doslfn and doslfnMS. there shouldn't be a difference.

last, but not least: why is this interesting at all? in all cases, real people are looking longer at the directory listing than it took to print it. even on a IBM PC with 360K floppies.

>
>
> Smartdrv is a disk-cache and no "drive" - and its max is 32MB. I use it
> with 8MB. Smartdrv does speed up doslfn significantly. Be sure to load it
> AFTER doslfn.
>
>

> he should start without CONFIG.SYS and AUTOEXEC.BAT (and the guarantee that no > offenders are lurking in his system)


Well, based on Tom's important suggestion that start without CONFIG.SYS/AUTOEXEC.BAT - in my case FDCONFIG.SYS/FDAUTO.BAT because I am using FreeDOS - I am building up, step by step, a workable minimal system.


To even just DEVLOAD HIMEMSX, in fact without the extension .exe I get an error message, I had to overcome the new error message

Error: free drive letter not found, increase LASTDRIVE

Apparently at the DOS PROMPT it seems, I cannot set up last drive - so I created a "new"


config.sys

!LASTDRIVE = Z
DEVLOAD himemSX.exe ' version 6,653 bytes 10 April



So I also created a "new" autoexec.bat (to save a lot of future typing) with code lines:-

RDRVSX32.exe 4 'latest version 4,016 bytes 12 April for 4 GB SXMS RAM Drive
SMARTDRV.exe A B C D E F G 32768 4096 512 '45,379 bytes 12 April (7 bytes)
doslfnMS.com ' -c variant 21,799 bytes 10 April


No matter which sequence doslfnMS/Smartdrv I have, and if doslfnMS before/after RDRVSX32 - I do not get LFN's with DIR

My smartdrv (32M) does "see" drives "A to G" and my USB stick has drives C,D and E.




Edit -Q for HIMEMSX.exe does not work

> > The real question is why it's so slow (the RAM drive in particular).
>
> Perhaps it's not related to doslfn at all. It might be a BIOS bug, setting
> up memory beyond 4GB as "uncachable" via MTRRs. I remember that, when
> HimemSX was introduced, another member of this forum (Zyzzle?) had such
> problems.

Yes, that is correct. Some of the memory beyond 4GB is "uncacheable" via MTRRs and only showing a 50 mb/sec transfer speed on an i5-8250 system. That system doesn't enable MTRRs for some reason, and it slowed memory transfers down by a factor of about 500x. No system that I've tested above a 5th Gen core i5 system has successfully cached memory in MTRRs. Limitation of Intel's? BIOS limitation? I can't figure why this feature has been disabled or crippled.

When HimemSX was tested on a system which does cache memory > 4GB via MTRRs, the memory speed was something around 10 GB / sec or greater on an core i5 5600 laptop. This laptop would also properly cache MTRRs via RayeR's MTRRLFBE utility while my core i5-8250 more recent laptop doesn't (executing MTRRLFBE wc lfb freezes the system).

> DEVLOAD himemSX.exe ' version 6,653 bytes 10 April

If it's in config.sys using DEVICE= would be better.

> RDRVSX32.exe 4 'latest version 4,016 bytes 12 April for 4 GB SXMS RAM Drive
> SMARTDRV.exe A B C D E F G 32768 4096 512 '45,379 bytes 12 April (7 bytes)

No point caching a RAM drive.

> No matter which sequence doslfnMS/Smartdrv I have, and if doslfnMS
> before/after RDRVSX32 - I do not get LFN's with DIR

Did you remember to add /LFN?

> Edit -Q for HIMEMSX.exe does not work

Since the help makes no mention of it, why did you think it would?

> > DEVLOAD himemSX.exe ' version 6,653 bytes 10 April

>
> No point caching a RAM drive.
>
> > No matter which sequence doslfnMS/Smartdrv I have, and if doslfnMS
> > before/after RDRVSX32 - I do not get LFN's with DIR
>
> Did you remember to add /LFN?
>
> > Edit -Q for HIMEMSX.exe does not work
>
> Since the help makes no mention of it, why did you think it would?



I just tried putting in the lines

SET DIRCMD=/lfn
lfnFOR on
lfnFOR complete on



and now doslfnMS DOES SHOW LFN's with sequence RDRVSX32, SMARTDRV, DOSlfnMS(with SET DIRCMD=/lfn etc). I could not edit my post in time before your reply. SORRY.


Yes I did have to insert those three lines before (ONCE only) and because of maybe a thousand install/uninstall doslfn(MS) that did not have it directly (but was in the FDauto.bat) I forgot about it in my "new" autoexec.bat.




> No point caching a RAM drive.
>

In my retesting of (doslfn vs doslfnMS) I should be able to verify your point.




Any pointers on how much to have for elementsize (how large can I go) and similarly for buffersize?

When I do a DIR of C:\ say, with a large enough buffer size, would smartdrive load up ALL directories/subdirectories tables even if I am only doing DIR C:\?

> > > The real question is why it's so slow (the RAM drive in particular).
> >
> > Perhaps it's not related to doslfn at all. It might be a BIOS bug,
> setting
> > up memory beyond 4GB as "uncachable" via MTRRs. I remember that, when
> > HimemSX was introduced, another member of this forum (Zyzzle?) had such
> > problems.
>
> Yes, that is correct. Some of the memory beyond 4GB is "uncacheable" via
> MTRRs and only showing a 50 mb/sec transfer speed on an i5-8250 system.
> That system doesn't enable MTRRs for some reason, and it slowed memory
> transfers down by a factor of about 500x. No system that I've tested above
> a 5th Gen core i5 system has successfully cached memory in MTRRs.
> Limitation of Intel's? BIOS limitation? I can't figure why this feature has
> been disabled or crippled.
>
> When HimemSX was tested on a system which does cache memory > 4GB via
> MTRRs, the memory speed was something around 10 GB / sec or greater on an
> core i5 5600 laptop. This laptop would also properly cache MTRRs via
> RayeR's MTRRLFBE utility while my core i5-8250 more recent laptop doesn't
> (executing MTRRLFBE wc lfb freezes the system).



I am willing to try same on my HP laptop with i7-4810MQ 32GB RAM (laptop manufactured 2015 and latest BIOS updates installed).

Where to get, how to use MTRRLFBE?

>
>
> I've updated
> RDRVSX32
> (remember that? :) ) to search the parent environment for DL=?
> and replace the ? with the first assigned drive letter. If
> there's no problems with that I'll update the SHSU programs to use it.



It may be the wrong reply to respond to, but...


Although I should really be testing in a "bare-bones" CONFIG.SYS/AUTOEXEC.BAT (as per Tom's suggestion) - I was eager to apply SMARTDRV to my "real life" (???) testing and so temporarily swapped back to FDCONFIG.sys/FDAUTO.BAT.

Once the SMARTDRV cache was preloaded from the same DIR command, on the second time when displayed a folder of some ~500 items, the display lines "whizzed by" - it seemed to only take about 2 secs. When on third DIR but with > NUL, it was practically instantaneous. ALL THIS for doslfnMS (-c variant) and the LFN's shown.


HOWEVER, on running 1.bat, get error message (after successfully displaying doslfnMS timings)


Invalid opcode at 252f 32b0 0002 0462 0075 e02b 008c 53f1 36f6 0007 32b06680 0a44



On investigating further, when ever I have doslfnMS enabled and I do doslfnMS u, get the message

Another TSR grabbed Int 21 and/or Int 2F

I wonder if my screen capture programs are responsible.

The system is still responsive, but it appears the uninstall worked as no more LFN with DIR.



HOWEVER, when I now doslfn (latest -c variant) (note all these steps in sequence are in 1.bat which is for 1st level sub-directory on USB D:\ Fat 32), the output is...


DOSLFN 0.41f (....):enabled
Last error:94 - inDOS bayra ...kullanimini SIFIRLA
Invalid Opcode at 1f7e 32b0 0287 0000 01ce fff8 ff67 0002 df8d 0001 ea93 0002 eaa9
Cannot terminate permanent FreeCOM instance
System halted ... reboot or power off now


That error message (:94) is the same as per post (09.04.2022 01:11 ServerTime + 0)



Apart from the error messages/lockups - without yet doing timing comparisons - using SMARTDRV made a noticeable improvement in speed (it even looked like as if a 4x speed improvement for a 128Mbyte file - but made a 4 GiB file transfer (USB --> SXMS FAT32) much worse than before. I might have to experiment with element/buffer sizes (going for multi KB sizes may not be optimal for my system).

Still yet to try out RT.






EDIT Above results with doslfnMS then SMARTDRV - will also try order swapped

>
> Well, I use DOS 7, HimemSX, Doslfnms and Smartdrv and have no speed
> problems at all.



I did not see a switch to allow me to unload SMARTDRV - I do not think /R (clears the cache and restarts SMARTdrive) is the same thing.


The reason why I want to uninstall SMARTDRV is that I think I will have to try hundreds of combinations for element/buffer size (which would only be valid for my system) to attempt to get near optimal settings.

I would prefer to uninstall rather than reboot hundreds of times.


Is it possible to add in code to uninstall? I had used a HEX editor to change the required 7 bytes as per updates.


I came across the GitHub FDOS site - and there are a number of cache programs. I thought I saw one that can be uninstalled. Even maybe not as good as the MS version - but if I assume that the element/buffer size codes are similar, this might help me with that optimization. I even saw one that can cache size go larger than 32M.

I am assuming that running cache at 32M has no detrimental effects on file transfer speedswhen compared to say 8M.

> I would prefer to uninstall rather than reboot hundreds of times.

AFAIK smartdrv cannot be uninstalled.

> I came across the GitHub FDOS site - and there are a number of cache
> programs. I thought I saw one that can be uninstalled. Even maybe not as
> good as the MS version - but if I assume that the element/buffer size codes
> are similar, this might help me with that optimization. I even saw one that
> can cache size go larger than 32M.

Bigger is not always better. Smartdrv caches write accesses, something that the simpler comrades won't do.

---
MS-DOS forever!

> I am assuming that running cache at 32M has no detrimental effects on file
> transfer speedswhen compared to say 8M.

if you want a system with fast file transfer, you should measure file tranfer with hundreds of different settings.

currently you are mostly measuring the performance of "translate SFN to LFN".

sure, if you want the best possible performance of

C:>DIR G:\ > NUL

continue with your efforts. but otherwise, your efforts are kind of wasted time...

> On investigating further, when ever I have doslfnMS enabled and I do
> doslfnMS u, get the message
>
> Another TSR grabbed Int 21 and/or Int 2F
> ...
> HOWEVER, when I now doslfn (latest -c variant) (note all these steps in
> sequence are in 1.bat which is for 1st level sub-directory on USB D:\ Fat
> 32), the output is...
>
>
> DOSLFN 0.41f (....):enabled
> Last error:94 - inDOS bayra ...kullanimini SIFIRLA

Released DOSLFN 0.41f, which includes a basic version check (doslfn will install, not try and control doslfnms; I should probably have made it say another version was installed, but I didn't).

>
>
> Released DOSLFN 0.41f, which
> includes a basic version check (doslfn will install, not try
> and control doslfnms; I should probably have made it say
> another version was installed, but I didn't).
>



Using the latest doslfn(MS) (14 April 2022), re-ran comparison of

without/with doslfn(MS)
USBFAT16/USBFAT32
XMSFAT16/XMSFAT32
SMSFAT16/SMSFAT32

for file set (10 files + 4 directories)

note SMARTDRV NOT USED in these tests and I think all relevant programs (himemSX, rdrvSX32, etc) are the latest updates.

As before (same sequence)...




1





2





3





4





5





6





7





8





9





A





B





C








I made a mistake that I did not doslfnMS -u before I started my series of .bat files (first part doslfnMS) (FDauto.bat doslsfnMS, SET COMDIR=lfn ...) and ended up with many duplicates from a sub-folder in C:\ being inserted into the C:\ ROOT. Because of all the @echo OFF (to make the screen captures look nice), if there were any error messages, I could not see them.


Will now very shortly repeat above but with much larger file set.




Is RT giving me the blank line before "Elapsed time: ...) - if so, option to not have blank line?

Okay, those times are a bit more reasonable (although 18s is still a lot, but a cache would help with that). Of course, that's assuming RT is right and the prompt is wrong. Or if they're both right, where's the extra time coming from? Accessing the programs from the slow USB? If you're not going to use a cache, perhaps create a small RAM drive (SHSURDRV), copy the programs to that and run from there.


> Is RT giving me the blank line before "Elapsed time: ...) - if so, option
> to not have blank line?

It is, to separate its output from the program it runs. I noticed that myself after doing the release. Removing the blank automatically is probably too much trouble, but adding another option would be simple enough.

> Okay, those times are a bit more reasonable (although 18s is still a lot,
> but a cache would help with that). Of course, that's assuming RT is right
> and the prompt is wrong. Or if they're both right, where's the extra time
> coming from? Accessing the programs from the slow USB? If you're not going
> to use a cache, perhaps create a small RAM drive (SHSURDRV), copy the
> programs to that and run from there.
>

I "on purpose" did not have a cache installed (SMARTDRV) or utilize RAMdrive for programs to get the "worst case " timings for comparisons.

Yes, all programs still running from USB FAT32 sub-sub-directory (C:\freedos\bin\). It is a fairly cheap 16GB verbatim (C:\,D:\ and E:\) bought from "K-mart" (10 or so years ago) and may be USB2 or even USB1 speed (on the USB2 port of the computer). I have noticed that "more expensive", "recent", "USB3" sticks from Verbatim seem to be much better, especially when multi-level sub-directories are involved (I suppose you get what you paid for).

With DOS tests, I always seem to notice that working off a sub-directory from (C:\ ROOT) seems to be noticeably slower than ROOT. C:\, my main working drive is FAT32 - and C:\ is only ~512 MB and was automatically created by (RUFUS + FreeBASIC RC5 full USB version), I had no control no control over that it had to be FAT32. Meanwhile, FreeDOS allowed me to have additional partitions (D:\ and E:\) on my USB stick (16 GB) and I allocated 12 GB to D:\ (as FAT32) and the remaining 2 GB to E:\ (as FAT16 just for fun). It is only very recently that I really did any testing etc with E:\. When I have "worn-out" my cheap USB stick, I plan to install on a brand new, higher quality (perhaps still verbatum) USB3 stick and plug into USB3 port.


The long term goal is to work "off memory" (either CACHE or most likely a RAMdrive - for all programs - where is best (assuming RAM drive) - XMSFAT16, XMSFAT32, SXMSFAT16, SXMSFAT32 - or doesn't it matter? I think I could spare some bytes off a RAMdrive for the whole DOS operating system + programs! :)

So, on reboot, probably xcopy the whole C:\ drive ( > NUL), then setup smartdrive, and make sure all paths refer only to RAMdrives.


Talking about xCOPY, on all possibilities of xCOPY C:\ --> RAMdrive, ie XMSFAT16 (~740 MB), XMSFAT32 (~740 MB), SXMSFAT16 (4 GB), SXMSFAT32 (~26 G) - the computer locks up (~~ half way through). According to Windows, C:\ drive contains 6986 items (6602 files + 385 folders) size 463 MB (size on disk 471 MB). There may be an upper limit for xCOPY which I don't know. My work around is to do it in say 5 stages (C:\ROOT then individually the four 1st sub-level-directories). Of course, over 99% on C:\ I do not really need to be there at all.







>
> > Is RT giving me the blank line before "Elapsed time: ...) - if so,
> option
> > to not have blank line?
>
> It is, to separate its output from the program it runs. I noticed that
> myself after doing the release. Removing the blank automatically is
> probably too much trouble, but adding another option would be simple
> enough.


For the next rerun of doslfn(MS) possibilities - I plan to simultaneously on screen captures, show timings w/o SMARTdrv installed, then on same capture, install SMARTdrv (won't be optimal element/buffer size values just yet), and run comparisons. Hence why I was so interested in removing the blank line before "Elapsed time:..."


EDIT each .bat run is to be with its own reboot per .bat






One thing I suppose I should really do, is to rerun exactly the same BUT change the order - eg c.bat, b.bat, a.bat, 9.bat ... 1.bat. And see if 1.bat still gives me the 18 seconds timings.

> The long term goal is to work "off memory" (either CACHE or most likely a
> RAMdrive - for all programs - where is best (assuming RAM drive) -
> XMSFAT16, XMSFAT32, SXMSFAT16, SXMSFAT32 - or doesn't it matter?

SX would let you keep 4Gi for normal usage. FAT32 would be better for drives over 512Mi. Otherwise I don't think it much matters.

> Talking about xCOPY...
> - the computer locks up (~~ half way through). According to Windows, C:\
> drive contains 6986 items (6602 files + 385 folders) size 463 MB (size on
> disk 471 MB).

Is that your FreeDOS install? Curious, according to dir/s/a mine is 9642 files, 1842 dirs, 439M total (1.3 installed on top of 1.2, I think it was). Worked fine under VirtualBox, to a 500Mi FAT32 drive. I'll try it in real DOS tomorrow.

> For the next rerun of doslfn(MS) possibilities - I plan to simultaneously
> on screen captures, show timings w/o SMARTdrv installed, then on same
> capture, install SMARTdrv (won't be optimal element/buffer size values just
> yet), and run comparisons. Hence why I was so interested in removing the
> blank line before "Elapsed time:..."

Released RT 1.02, which adds -c to remove the blank line. You could just redirect the entire batch: command /c 1.bat > 1.txt; vecho will still write to the screen.

> Okay, those times are a bit more reasonable (although 18s is still a lot,
> but a cache would help with that). Of course, that's assuming RT is right
> and the prompt is wrong. Or if they're both right, where's the extra time
> coming from?

it might be cool to have an option -Z (time) to also display the DOS time:

Elapsed time: 04:02:09.88-04.02.10.22: 0.336 seconds

where the former is the 'official' DosGetTime time, and the latter your (more precise?) time.

in addition, RT has a couple of different ways to time things.
it would be cool to know if the times behave consistently or not

'-1', 'use the standard timer tick (55ms, 24 hours; default)', NL
'-[1]+', ' as above, but can time across days', NL
'-2', 'use the CMOS timer (1ms, 48« days)', NL
'-2+', ' as above, but restarts the timer if BIOS turns it off', NL
'-3', 'use the hi-res timer (1æs, 1 hour)', NL
'-t', 'display only the time', NL
'-r', 'display only the ticks (raw)', NL
'-w', 'write timing information to stderr', NL
'-c', 'compact, no blank line before output', NL
'-e', 'execute the program directly, rather than loading first', NL

> > The long term goal is to work "off memory" (either CACHE or most likely
> a
> > RAMdrive - for all programs - where is best (assuming RAM drive) -
> > XMSFAT16, XMSFAT32, SXMSFAT16, SXMSFAT32 - or doesn't it matter?
>
> SX would let you keep 4Gi for normal usage. FAT32 would be better for
> drives over 512Mi. Otherwise I don't think it much matters.
>
>
> > For the next rerun of doslfn(MS) possibilities - I plan to
> simultaneously
> > on screen captures, show timings w/o SMARTdrv installed, then on same
> > capture, install SMARTdrv (won't be optimal element/buffer size values
> just
> > yet)
>
> Released RT 1.02, which adds -c to remove the blank line. You
> could just redirect the entire batch: command /c 1.bat >
> 1.txt; vecho will still write to the screen.


Your RT -c option seems to work perfectly for me (so far). Thanks.


So I was preparing code for SMARTDRV vs nonSMARTDRV and I came across the error


There is insufficient XMS memory to load SMARTDRV


OK so I reduced my XMS RAM drives (FAT16 + FAT32) from the approximately 741M each down to ~500M each and still gives the same error message.

My FDauto.bat has the lines


xmsdsk.exe 500000 I: /y
rdrvx32.exe 500M

and 1.bat etc has

SMARTDRV C D E 8192 1024 1024


Is my SMARTDRV (attempt) as above too big? (I would have thought reducing both XMS RAMdrives down by ~ 240M each should have been plenty to cover for SMARTDRV).

Maybe I am over looking something - the only changes to my program is "tacking" the SMARTDRV setup at the end of in 1.bat etc and "repeating the code set for without SMARTDRV.

> > The long term goal is to work "off memory" (either CACHE or most likely
> a
> > RAMdrive - for all programs - where is best (assuming RAM drive) -
> > XMSFAT16, XMSFAT32, SXMSFAT16, SXMSFAT32 - or doesn't it matter?

>
> > For the next rerun of doslfn(MS) possibilities - I plan to
> simultaneously
> > on screen captures, show timings w/o SMARTdrv installed, then on same
> > capture, install SMARTdrv (won't be optimal element/buffer size values
> just
> > yet), and run comparisons.



I had some success with SMARTDRV and XMS drive (I changed the order when the SMARTDRV is installed - NOW BEFORE any RAM drives being created).


HOWEVER, with SMARTDRV and SXMS FAT16 drive, I get the error


Invalid Drive J: (J: my chosen name)


without SMARTDRV, the exact same creation of J:\ of a SXMS FAT16 is no problem (done it a hundred times).

Below is the relevant FDAUTO.BAT code which does not seem to work for me to create a SXMS FAT16 RAMdrive 4G,


devload himemSX.exe
SMARTDRV C D E 8192 1024 1024
SHSURDRV.exe 4094M,J:

which would otherwise given me a 4G SXMS FAT16 drive and a SMARTDRV of 8M

>
>
> > For the next rerun of doslfn(MS) possibilities - I plan to
> simultaneously
> > on screen captures, show timings w/o SMARTdrv installed, then on same
> > capture, install SMARTdrv (won't be optimal element/buffer size values
> just
> > yet), and run comparisons.



Note, last two runs b.bat and c.bat (j:\ SXMS FAT16 drives) are in error - refer previous reply.

Some minor "cosmetic" errors on screen captures (but still usable).


So, with a "colorful Easter Egg Theme", as per other posts - the screen captures are...

> it might be cool to have an option -Z (time) to also display the DOS time:

Added -v (verbose) to show the command and start & finish times.

> it would be cool to know if the times behave consistently or not

Perhaps you could measure the timeout of choice? If you have it, you could use int (from RBIL) to run the BIOS wait function (int -q ah=0x86 cx=0xf dx=0x4240 for one second).

> Perhaps you could measure the timeout of choice? If you have
> it, you could use int (from RBIL) to run the BIOS wait
> function (int -q ah=0x86 cx=0xf dx=0x4240 for one second).

the question was intended for Richard with his strange machine where sometimes
the time differences between his prompt and the times reported by rt seem to be different.

> >
> >
> > > For the next rerun of doslfn(MS) possibilities - I plan to
> > simultaneously
> > > on screen captures, show timings w/o SMARTdrv installed, then on same
> > > capture, install SMARTdrv (won't be optimal element/buffer size values
> > just
> > > yet), and run comparisons.
>
>
>
> Note, last two runs b.bat and c.bat (j:\ SXMS FAT16 drives) are in error -
> refer previous reply.
>
> Some minor "cosmetic" errors on screen captures (but still usable).
>
>
> So, with a "colorful Easter Egg Theme", as per other posts - the
> screen captures are...
>
>
>
>



The set above created with "112 version" of FDauto.bat and the relevant code lines (in sequence) are...

doslfnMS
devload himemSX
smartdrv C D E 8192 1024 1024
RdrvX32 --> G:\
RdrvSX32 --> H:\
SHSURDRV --> J:\
XMSDSK --> *** invalid drive I:\ (i.e. for b.bat and c.bat test)


Changed order
113 version

doslfnMS
devload himemSX
smartdrv C D E 8192 1024 1024
SHSURDRV --> J:\
rdrvX32 --> G:\
rdrvSX32 --> *** invalid drive H:\ (i.e for 5.bat and 6.bat test)
xmsdsk --> I:\


Interestingly, somewhere along the line, my c.bat file (for version 112 test) did not exist

> > Used Trace_2.01.com. In some cases cluster size of 0 bytes is reported
>
> Fixed.
>
> > Is it possible to add a feature to TRACE to have displayed:-
> >
> > - Total bytes (i.e. free bytes + used bytes)?
>
> Added (total bytes of the drive, i.e. including reserved & FAT sectors).
>
> Trace 2.02.




I am confused!


Using trace.com 5,679 bytes (2022-APR-02) and whichfat.com 508 bytes (2003-NOV-24) - do not agree!






Trying to create a FAT12 RAM drive.

> Using trace.com 5,679 bytes (2022-APR-02) and whichfat.com 508 bytes
> (2003-NOV-24) - do not agree!

SHSURDRV thinks it's creating a FAT12 drive, but the DPB begs to differ.

> Trying to create a FAT12 RAM drive.

Until I fix it just make it a little smaller, so the last cluster is FF5.

> > Using trace.com 5,679 bytes (2022-APR-02) and whichfat.com 508 bytes
> > (2003-NOV-24) - do not agree!
>
> SHSURDRV thinks it's creating a FAT12 drive, but the DPB begs to differ.
>
> > Trying to create a FAT12 RAM drive.
>
> Until I fix it just make it a little smaller, so the last cluster is FF5.



Reduced size slightly of FAT12 drive.

Below are the (doslfnMS vs doslfn) timings for FAT12 USB, XMS and SMS drives for both ROOT and 1st level directories.

Note tried to make all FOLDER sets (files + directories) equal, however for the USB FAT12 drive, strange results occurred (as if 2 files are hidden from DIR - but if I recopy them to make up the "10 set of files", I get the message "do you want to overwrite...).


Hopefully all the drives below are actually FAT12.


A few minor "cosmetic" issues with the screen captures - but still usable.


























Who can I suggest some minor changes to XMSSTAT.exe to?

> > Using trace.com 5,679 bytes (2022-APR-02) and whichfat.com 508 bytes
> > (2003-NOV-24) - do not agree!
>
> SHSURDRV thinks it's creating a FAT12 drive, but the DPB begs to differ.
>
> > Trying to create a FAT12 RAM drive.
>
> Until I fix it just make it a little smaller, so the last cluster is FF5.



I think I have a serious problem with SHSURDRV.exe ...


Reduced slightly size of FAT12 drive.

Essentially, the only changes to my testing of (doslfnMS vs doslfn) is to enlarge the tested FOLDER set - from 10 files (+4 directories) - to 100 files (+4 directories). The change involved having another folder with 90 files and just copying them to ALL FOLDER sets being tested (namely ROOT/1st_Level_sub-directory, USB/XMS/SMS memory, FAT12/FAT16/FAT32 --- ALL possible combinations).


Referring to ".bat" runs (as shown in the middle of the small overlay box at the Top Right Hand Corner of each screen capture) - c.bat and g.bat show that for SHSURDRV.exe (and only it), the copying of 90 files to the respective FOLDER set was not successful. When I BOOT up, where all the RAM drive setup occurs in FDauto.bat, I get the following error...


DOSLFN 0.41f (... 4/2022):disabled
(Another TSR grabbed Int21 and/or Int2F)
Last error:2 - couldn't expand FAT directory



Though with this error, I proceeded to run 1.bat, 2.bat, ...h.bat, i.bat and the results are below







































































Note the enlarged drive set for SMARTDRV is just for me to convince myself there is not point in smartdriving RAM drives - I am not even sure now that a smartdrv makes any sense for DIR. Beginning to think that the smartdrv cache is only designed for file copying, etc (not for DIR listing) - I could be wrong though.

well. Any conclusions about your efforts?

> well. Any conclusions about your efforts?

They were worth it - among other things, they brought to my attention this "screen thief" utility. It works, even if I set very uncommon text modes.

For example:
- setting VESA graphics mode 0x102, 800x600 pixels
- changing graphics to text, 37x100 chars
- changing font to 8x14, gives 43x100 chars
- changing vertical display to 602 pixel (makes the last row to be seen fully )
- changing horizontal display to 80 chars

and I get screenshots in a very nice 80x43 text mode.

---
MS-DOS forever!

> well. Any conclusions about your efforts?



Preliminary discussion and conclusions.


The original aim of the exercise was to test out RDRVSX32 in the creation of FAT32 RAM drives - a required aspect was the creation of RAM drives larger than 4 GByte (which automatically meant to be created in SuperXtendedMemorySpace (Abbreviated to SMS in my notes).

Previously, before March, DOS users only had access to RAM drives no larger than 4 GByte due to FAT 16 limitation.


Initially, in the development process there were problems that the FAT32 RAM drive could be created on AMD machines but not my INTEL machine - which resulted in this thread being on BTTR in the first place. Eventually I overcame this INTEL/AMD difference by simply reconfiguring FDconfig.sys (I used FreeDOS RC5 at the time, now known as v1.3). Apparently non-FreeDOS systems, both INTEL and AMD, were never affected.

At present I can only do testing in FreeDOS on a bare metal setup - I have not been successful to obtain MS DOS 7.1 to install beside FreeDOS. At this stage I did not do any Virtual Machine setup testing.


From a limited number of tests, I successfully achieved RAM drives of about 28 GByte and worked with file sizes up to 4 GByte(minus 1 byte) on all trials. My hardware is limited to 32 GByte RAM and since the first 4 GByte is reserved for (XMS + 1 MByte conventional memory) - at this stage I cannot confirm/deny on whether it is possible to have RAM drives > 32 GByte.

The speed of the FAT32 RAM drive is impressive - without using timer routines to measure - to copy from say a 1 GByte file in XMS and transform, by way of binary DOS file addition, to a 4 GByte file (in SMS) took only about 1 second. On the contrary, to copy a 4 GByte file to/from RAM to/from my USB stick takes over 2 hours (using FreeDOS).

So from a very limited set of testing conditions it appeared that RDRVSX32 is highly efficient and accurate in the creation of FAT32 RAM drives (in SMS).



Early on in this thread, Japheth indicated problems when working with LFN (my tests were only with 8.3 format) - and a number of RDRVSX32 iterations were written by the author (Jadoxa).

At this point I went off in a slight "tangent" - so instead of aiming for further RDRVSX32 testing in a variety of situations, I was involved in independent testing of LFN in FAT32 RAM drive, which led me into LFN testing of FAT32 RAM drive in XMS, FAT16 (XMS/SMS) and FAT12 (XMS/SMS) and USB stick equivalents of FAT 12/16/32. No tests were done on a Hard Drive or SATA SSD and similarly no tests for my 3.5 inch USB floppy drive (which seems to be broken).

A further "tangent" occurred with using a more reliable timing method (Jadoxa's RT program) than examining time differences via DOS prompt time stamps. Also another tangent resulted from Jadoxa supplying two versons for LFN - namely doslfn and doslfnMS.

So, to try to maintain "fairness" in various testing "environments", I attempted to automate measurements via ".bat files" for all possibilities for an extremely small sample set (10 files + 4 directories). The sole intention was to determine if the two doslfn{MS} were significantly different is speed. The timing resolution I adopted was milli-seconds ( RT program can offer micro-seconds resolution). It was inconclusive with only 10 files+ - so lastly bumped up to 100+ files. Apart from the problem (mentioned below):-

Conclusion To a resolution of 0.02 seconds there appears to be no timing differences between doslfn and doslfnMS for a sample size of 100+ files - however a more realistic (for me) size
set should be a minimum of 500 files + 500 1st level sub-directories AND NOT YET TESTED at a very deep level (say 10 levels down) also. This last addition may be interesting since my experience with Windows 10 is that serious problems (in Windows) occurs when working with >6 levels down, e.g. in searches.

Problems I have observed...

SHSURdrv cannot support 100+ files in the ROOT directory of FAT12 and FAT16 - so cannot test doslfn{MS} for larger file sets.

It appears that doslfn{MS} cannot support LONG FOLDER NAMES (whereas Windows can).

When using the TIME STAMP as part of the DOS Prompt - strange timing errors occur (as if time going backwards on occassions) - the best explanation I can give for this is that my machine is INTEL (i7) with 4 cores and each core acts as 2 logical processors. Even though, as I understand, DOS in bare metal mode only is working on one core at any one time, it may not be working on only one logical processor - so, any (exe/com/sys/bat) may be simultaneously processed by two logical processors (but by the one physical core). Two important factors are involved - pipelining (which came with the advent of 486 processors) and the way instruction codes are presented (c/f 8-byte boundaries for 64 bit machines). So, with "look ahead" techniques, a code stream split over two logical processors may get "unsynchronized" slightly - so the DOS prompt executed by logical processor #1 is finished AFTER RT.exe has finished on logical processor #2. However, under otherwise identical conditions, with an AMD quad core processor - there are only as many logical processors as physical cores (hence no pipelining I think) and there is only one process execution code stream running in DOS.

Hopefully, issues with SHSURDRV ROOT tables limit and Long FOLDER Names (once verified independently to see if the problem still exists) will be fixed in the near future. However, if I am the only one to be using FAT12 and Long FOLDER Names, I can imagine it will be a very long time, if ever, before being fixed.

Another "tangent" occurred with the using of SMARTDRV (to help speed things up).

Conclusion using SMARTDRV has no observed significant speed gains when doing DIR on various media/formats.

By using SMARTDRV many things were "broken" with RAM drives - resolved by re-arranging setup sequence of all combinations of RAM drive for FAT12/16/32 + XMS/SMS.



Summary

From limited testing on a 32 Gbyte INTEL computer, it is possible to achieve a 28 GByte FAT32 RAM drive. Speed is very good - > ~1 GByte per second for file transfers (RAM to RAM). Cannot confirm/deny if >32 GByte RAM drive is possible.

doslfn and doslfnMS appear to be the same speed for up to 100+ files (restricting to 0.02 second timing resolution).

No apparent advantage in using SMARTdrv for DIR on any media/format - and consideration when simultaneously having RAM drives as FAT 12/16/32 + XMS/SMS (i.e. 6 different kinds of RAM drives).

Apparent limitations with SHSURDRV for FAT 12/16 ROOT directories (only) (literature mentions can be as low as 64 entries - USB stick (via Windows allows 100+))

doslfn{MS} does not appear to work with long FOLDER Names (need independent confirmation)

My testing limited to FreeDOS 1.3 platform - not able to test via other platform (e.g. MS DOS 7.1)

RDRVSX32 does work with both INTEL and AMD - need consideration when using FreeDOS FDconfig.sys/FDauto.bat

There appears to be timing "racing" conflicts with Time Stamps as part of DOS Prompt comparing running programs (such as RT.exe) - attributed to on only INTEL > 486 processors with more than one logical processor for each physical core (so does not exist maybe for AMD).

"Screen Thief" and "RT.exe" and "Trace.com" utilities very useful for recording of events.

Further, more rigorous testing needed, but RDRVSX32 may be good enough "as-is" for over 99.99% of applications (my guess).

> SHSURdrv cannot support 100+ files in the ROOT directory of FAT12 and FAT16
> - so cannot test doslfn{MS} for larger file sets.

FAT12 and FAT16 root entries are fixed at the time the drive is formatted or - for RAM drives - initialized.

> When using the TIME STAMP as part of the DOS Prompt - strange timing errors
> occur (as if time going backwards on occassions)

as far as I can see this happened exactly 2x. (on 09.04.2022, 4:01.26.40)



> - the best explanation I
> can give for this is that my machine is INTEL (i7) with 4 cores and each
> core acts as 2 logical processors. Even though, as I understand, DOS in
> bare metal mode only is working on one core at any one time

to my understanding BIOS only initializes the 1'st thread on the 1'st core.

> it may not be
> working on only one logical processor
this would be VERY unusual.

> So, with "look ahead" techniques, a
> code stream split over two logical processors may get "unsynchronized"
> slightly - so the DOS prompt executed by logical processor #1 is finished
this is nonsense, even on a multitasking system. first the time for a prompt is taken, then some command is executed, then the time for the prompt is taken again.

as the time is directly the BIOS timer tick (converted to seconds and centiseconds), I would rather suggest the kernel code to convert ticks into seconds is somehow broken (although I couldn't find a possible bug).

other than this, the BIOS timer tick count counting backward is extremely unlikely, no matter how many threads are running.

> as the time is directly the BIOS timer tick (converted to seconds and
> centiseconds), I would rather suggest the kernel code to convert ticks into
> seconds is somehow broken (although I couldn't find a possible bug).

converting the suspicious kernel code from kernel\sysclk.c into a test routine as below 'proves' that the kernel code is correct; i.e. an increase in the BIOS tick count results in a greater converted DOS time.

I have no idea how this could happen.

#else                             // #ifdef TEST   

#undef SEEK_SET
#undef SEEK_CUR
#undef SEEK_END


#include "stdio.h"

/* compile with

        set PATH=%WATCOM%\binnt
        set INCLUDE=%WATCOM%\h
        wcl sysclk.c /DTEST /i..\hdr -q
*/     
       


main()
{     
        ticks_t ticks, bios_ticks;
    struct ClockRecord clk, oclk;
    int tmp;


        for (bios_ticks = 0; bios_ticks < 0xffff0000l; bios_ticks++)
                {   
   
        /* The scaling factor is now
           6553600/1193180 = 327680/59659 = 65536*5/59659 */

        ticks = 5 * bios_ticks;
        ticks = ((ticks / 59659u) << 16) + ((ticks % 59659u) << 16) / 59659u;

        tmp = (int)(ticks / 6000);
        clk.clkHours = tmp / 60;
        clk.clkMinutes = tmp % 60;

        tmp = (int)(ticks % 6000);
        clk.clkSeconds = tmp / 100;
        clk.clkHundredths = tmp % 100;

                if (bios_ticks < 20)
                        printf("%2d:%02d:%02d.%02d\n", clk.clkHours, clk.clkMinutes,
                                                                                clk.clkSeconds, clk.clkHundredths);
       
        if (clk.clkHours   <= oclk.clkHours &&
            clk.clkMinutes <= oclk.clkMinutes &&
            clk.clkSeconds <= oclk.clkSeconds &&
            clk.clkHundredths <= oclk.clkHundredths)
            {       
            printf("ticks %lu\n", bios_ticks);
                        printf("old %2d:%02d:%02d.%02d\n", oclk.clkHours, oclk.clkMinutes,
                                                                                oclk.clkSeconds, oclk.clkHundredths);
                        printf("now %2d:%02d:%02d.%02d\n", clk.clkHours, clk.clkMinutes,
                                                                                clk.clkSeconds, clk.clkHundredths);
            }
           
                oclk = clk; 
               
                if (clk.clkHours >= 24)
                        {
                        printf("midnight at %lu = 0x%lx\n", bios_ticks, bios_ticks);
                        break;
                        }
                }
               
        return 0;

}
#endif

> SHSURdrv cannot support 100+ files in the ROOT directory of FAT12 and FAT16

The default is 64, you must specify the D setting for more.

> It appears that doslfn{MS} cannot support LONG FOLDER NAMES

C:\>f:doslfn
DOSLFN 0.41f (haftmann#software & jmh 4/2022): loaded consuming 12512 bytes.
C:\>md "a long directory name"
C:\>copy nul "a long directory name\a long file name"
nul =>> a long directory name\a long file name
C:\>dir/lfn alongd~1
 Volume in drive C is FREEDOS2012
 Volume Serial Number is 124A-13F0

 Directory of C:\ALONGD~1

.                    <DIR>  22-05-2022  5:17p a long directory name
..                   <DIR>  22-05-2022  5:17p .
ALONGF~1                 0  22-05-2022  5:17p a long file name
         1 file(s)              0 bytes
         2 dir(s)     577,912,832 bytes free


> > SHSURDRV cannot support 100+ files in the ROOT directory of FAT12 and
> FAT16
>
> The default is 64, you must specify the D setting for more.
>

Thanks for "reminding me" re "D" setting - I think it was about 2 months since I last read the readme file for SHSURDRV and so I completely forgot about the sectors etc configuration side of things. The "excitement" with working in one project with the simultaneous testing of 18 possible RAM/Physical drive/folder combinations "clouded" my programming approach to the situation.







> > It appears that doslfn{MS} cannot support LONG FOLDER NAMES
>
> C:\>f:doslfn
> DOSLFN 0.41f (haftmann#software & jmh 4/2022): loaded consuming 12512
> bytes.
> C:\>md "a long directory name"
> C:\>copy nul "a long directory name\a long file name"
> nul =>> a long directory name\a long file name
> C:\>dir/lfn alongd~1
> Volume in drive C is FREEDOS2012
> Volume Serial Number is 124A-13F0
>
> Directory of C:\ALONGD~1
>
> .                    <DIR>  22-05-2022  5:17p a long directory name
> ..                   <DIR>  22-05-2022  5:17p .
> ALONGF~1                 0  22-05-2022  5:17p a long file name
> 1 file(s)              0 bytes
> 2 dir(s)     577,912,832 bytes free
>


Have not had a chance yet to look at Long FOLDER Names (in my setup). Thanks for independently verifying that it does work. What I think might have happened to me was that with the "hundreds" of DOSLFN{MS} install-uninstall steps and coupled with SMARTDRV (which in itself caused "problems" - but workaround eventually done) I was taking - I might have copied LFN FOLDERS when the CPU was in 8.3 mode - and of course once anything is "forced" into 8.3 mode, working in LFN mode later on does not regain the "lost" name detail.

It may be about 2 weeks before I will do another comparison run, re doslfn{MS} with a very much larger file/folder set. I am going to do on another usb stick, this time on a 256 GByte one (instead of 16 GByte) - I may have issues with sizes of partitions being > 32 GByte say (soon will find out).






----------------------------------------------------------------------------

I am preparing my response to Tom's reply (which no doubt he will "critically analyze" and point errors in my ways). I do really appreciate feedback (a very powerful way to learn things, than just only spending time forever reading only). It may be a few days before I can reply to him.

@jadoxa , is http://adoxa.altervista.org/shsufdrv/rdrvsx32.zip still the latest link for this driver? I want to play with this on a couple machines. Thanks!

Yep, haven't done anything since.

> Yep, haven't done anything since.

Thanks for confirming.