#doscember 

With the original MS-Dos 7.1 it is not possible, that is why we have Ultimate MS-Dos :D The patches were taken from the China DOS Union version, their edition can do it to. But I had difficulty running their version of harddrives / floppy drives, and its not going to be as small.

Put a lot of passion in this project so I am glad you found it :D

and a great selection of tools on top

@@mk2k685 And it actually fits on a single floppy without ramdisks, that was the most challenging part :D

@@Henk717 oh yes, I can imagine. I also like the UDBS collection, too - because floppy drives are a dying breed these days and some of us juggle with Compact Flash drives where size actually doesn't matter all too much :)

Thanks! Used every trick I could to get the memory management down. Especially if doskey isn't loaded it has a lot available since doskey takes up 10k. It goes both ways where it also makes sure there isn't to much ram available for the ram sensitive applications.

In my emulation tests it runs great with a 486, if you end up posting something about it i'd love to see.

@@Henk717 Probably on Vogons. I have a M912.

What is something you could do on 6.22 but not on 7.1? I am still looking for use cases Ultimate MS-DOS can't do.

I don't use git for this, when I want to make a new version I grab the latest .img file and edit it with WinImage. Most of my work on this was done using the same method. I also don't neccesarily go for the newest utilities, they are often larger and every kilobyte counts with this. So sometimes you will see me use an older version of a program simply because its smaller.

What kind of incompatibilities did you run in to?

@@Henk717 win 3.1 would try to start up and then go to the DOS prompt. Ctmouse would hang the system if it was in the startup files.(but not if started manually for some reason). Some of the DOS utilities would tell me off saying I had the incorrect version of DOS etc. I was trying to Frankenstein ibm-dos with aspects of MS-DOS

I looked in to that when I made it but its much to large to fit on the single floppy. This version of QBASIC was a good middle ground. You can of course get the full one yourself, it works fine.

@@Henk717 Makes me wonder if you have tried executable packing utilities like kkrunch available from the demoscene (check out kkrieger, and the toolchain used is open source including kkrunch) works on MSDOS PE executables to save some KB, but may break some things depending on the application as it removes unnecessary code paths and introduces an ELT (execution lookup table) to lighten up machine code spaghetti. Depends how original you'd like to go? If you're looking at distributing unmodified, original executables, maybe not your target but can work to fit more on a floppy. The set of utilities was written in and released at a german demoscene conference in 2004, I think you'd definitely benefit from it if you want more from your OS distribution on a floppy. It also has a Windows 98 compatibility mode so they thought ahead. Whips the llamas ass so to speak, very smart team over there.

@@nightwintertooth9502 I recall having tested the tool in the past but dismissing it for some reason, I recall it working well for the demoscene but being more limited than UPX for the other stuff. Everything already has been UPX'd to the max if I was able to. aPack I may also try in the future if I need more space again. Usually software like QBASIC already comes pre-compressed. So if its for example a megabyte in size there is no way I can get it down enough to fit with the other software. I can usually take a few kilobytes off by recompressing.

@@Henk717 Its good to see that you've put in the effort! Thanks for the updates!

i believe you're thinking of QuickBasic (which has a compiler), it's not the same as qbasic. qbasic cannot produce executables. if memory serves, PDS has the QB 7.1, compiler, linker, library manager, codeview (maybe), libraries, code samples etc. i think it was rather big, i dunno 10 floppies maybe?

Should be fully compatible if not more compatible (In its native mode, in w98 integration mode its the usual limitations) The options defaults are not stored but you could easily customize the autoexec file to your preferences

I also released the raw .ima files, those should be extractable with programs like 7-zip

Awesome! I assume you went for FAT32?

@@Henk717 yep

Every action is prefixed by the popup choice so if you look at the autoexec file it should be reasonably easy to remove the dialogue option and keep what it does.

WBAT, that whole routine is in the autoexec file

Never noticed, but you are right by default its very wasteful. I judge tools by their size value, so with only 6KB its worth fitting it in. I don't have that space on the floppy but I should be able to save enough space to make it fit by recompressing a few things. If I get to it ill let you know.

Uploaded an updated version which has it.

@@Henk717 Perfect 👌👌

Modified io.sys, compressed everything I could with UPX on the strongest settings and a very careful selection of software to begin with. Your reaction was exactly my design goal when I made it, I wanted it to be unbelievably feature rich for a single floppy.

xmsdsk is included on the floppy for easy ram disk creation

@@Henk717 Thats cool. Thx.

If its genuinely my image i'd love to see that, but mine I only released last year so I doubt its mine.

@@Henk717 Image? I meant andamiro used DOS in their early Pump It Up machines until going to CDs and later to HDDs and SSDs. Sorry for the mix up.

rdtsc can take several microseconds depending on the existance of HAL APIC and on the original IBM PC latency is any where between 848ns and several microseconds as its accessed over standard IO port on 386/486. The tickrate of the standard IBM timer is 1.193mhz, it simply cannot provide enough precision at machine level for clock drivers. Accurately detecting cpu type and stuffing nop instructions into the pipeline to delay program counter and avoid interrupt calls with variable standard traditional i/o access times is the most efficient way to do so, and is done on purpose due to both the precision limitation of the mainboard clock, its tickrate and the way that its accessed over traditional i/o being an interrupt call. vsync happens at 60hz, definitely not enough precision needed to time a program counter running faster at 133mhz or operating range 12mhz to 40mhz on the 386 or 20mhz to 40mhz to accurately emulate clock rate of 486. the way its done may sound like a hack but trust us, its done on purpose to keep traditional i/o bus free as many memory resident drivers hook and depend on this. also keep in mind you're going to be in protected mode the majority of the time so getting an ack back from a standard int's to load ebx with the current tick's going to take ??? (variable) time, its the nature of the beast and simply won't tame it. rdtsc is available on the 486 but does the same thing internally. thank you for your suggestions i definitely would suggest a deeper dive into the how/why your suggestions can't work, though.

I don't own one, what do they require?

@@Henk717 they generally were supported out the getgo for internal ATAPI versions of the drivesin 98 , but prior to that , you had to use drivers made for the SCSI (ZIP)/Paralell port (ZIP & LS120) versions. ( no native dos drivers for any version of LS120 were made AFAIK prior to 98 and built in support. (then again it might be just a effect of formatting one from 98 and letting it copy system files. n booting from a LS120 Disk)

@@CaelThunderwing The original boot disk has a lot of aspi files for scsi controllers taking up space that I left out. So if it is those that make it work mine probably won't out of the box. If its inside the io.sys it should still work.

I am surpriced the UDBD version works with that setup, UDBS should be the most suitable one since it includes more stuff. Definately a nice way to easily get DOS booted on a variety of systems. It may even work on some more modern systems that normally struggle to run DOS well since I included memory managers that usually work better on modern PC's. So with your setup you could have any PC that supports MBR running dos in notime with just PXE, very neat!

Give part a try instead for the partition managing. Alternatively use the floppy that works for you to format the C: drive and then use mine with the setup command.

@@Henk717 thanks; tried the W98 floppy (which is what let me install W98 on my drive), and it works fine, until I boot your floppy. When I do that, everything is fine until I try to install. At that point I get the errors on the C drive no matter what, either if I formatted the drive already, if I just created the partitions or if I use fdisk and reboot. Can't be the drive; so it must be something loaded by the floppy I guess? I will give a try to Part. Thanks

@@fcf8269 Thata odd, maybe its the default memory manager that your system does not like. The vanilla option disables everything. If that works try some of the other memory managers. My much newer thinkpad had quirks to but liked the memory managers lower on the list.

@@Henk717 Tried other memory managers but it seems that the issue is the disk manager I guess. When in Part, it show the 22 GB disk as 8 GB; cannot partition it bigger than 8 GB. Instead with Fdisk it does see it as 22 GB but when I create a primary partition (say 4 GB) and a secondary partition for the reminder (18 GB); when I create logic partitions inside the extended partition, it say that the max space is 8 mb. I am not sure what is going on here to be honest; how big did you create the drive? I am using a standard IDE to M-sata; works fine in other context so can't say what is wrong here. As is I can't even install it on an existing W98 installation basically, as I tried to install W98 first and then install this dos version and didn't work either

@@Henk717 I am experiencing the exact same issue here. I have a 16GB Sandisk Ultra SD card that is exhibiting exactly the same problem where FDISK shows the full capacity of the drive but then part is showing 8GB and says the partition is inconsistent and that the file system cannot be managed.

The point of the floppy is indeed to have an easy out of the box setup that covers pretty much all of it, so that people do not have to configure their systems from scratch. I find this approach easier to use than configuring MS-Dos 6.22 yourself, and its more complete than stuff like MS-Dos Starter Pack. GRUB is definately not overkill for what I use this floppy for, I like to play with real DOS inside Dosbox a lot, so having the GRUB bootmanager there the moment I add the floppy image to the DOSBox configuration is incredibly useful. Since now I can easily switch between Ultimate DOS and whatever is installed on the harddrive at the time, as well as CD-Booting where normally DOSBox does not support this. On real hardware it might indeed be more redundant with native CD-Rom booting support in many cases and the ability to easily take the floppy out but with little downsides I find the value it adds to be bigger than the space requirements. Setver is a small addition that consumes very little ram but allows you to natively be able to use Windows 1.0 and Windows 2.0 while also increasing compatibility with old software. So it made sense to have that included out of the box. It was a very late addition though, but I had the space to make it fit and did so after reading about MS-Dos compatibility differences on vogons, with most of them being resolvable with setver and FAT16. I agree memory managers are a bugfest, which is why I have so many of them included. EMM is needed for many soundcard drivers of later sound cards such as the Yamaha's and Soundblasters. On some systems it works better than on others, but its easy to boot into the HIMEM only option. But then you run into cases like a "modern" Lenovo Thinkpad E540 which hangs when HIMEM is used with no way to get that resolved. On that particular laptop HIMEMX works fine and acts stable, which is why I decided to keep both despite the space requirements. On old systems it does little, but its a great boost in system compatibility if HIMEM fails. Cutemouse is the best choice for this project because its such a light driver with wide compatibility, not only on ram but also in file size. I have yet to run into breaking limitations (Keep in mind there are a few different versions of cutemouse out there that do not share the same compatibility, I made sure to pick the one that was regarded as the most compatible). Sure, you can't have things like mouse trails and some of the customization options that something like a logitech driver would have had. But the logitech one would not have fit on the floppy. You are absolutely incorrect about the burnmem stability, its by far the most stable solution I have found because it eats up all the RAM until the defined RAM amount is left. That is why Aladdin works in the video, and why I can run Windows 98 SE stable on my 4GB of RAM multibooting retro PC. Patchmem I never had much stability from, but its handy to have for Windows ME installations or people who rather have more ram inside Windows 98 versus better stability. If you know a tweak that I don't feel free to share it, the NUMHANDLES is already configured. For compatibility its essential that games and programs do not see the bigger ram, so merely streamlining handling high amounts of ram is not going to be sufficient. DOSLFN is for nicer compatibility with the windows file naming structure but I have it disabled by default for this reason. It does work fine with the apps I tested though, edit being an example where it works fine. NTFS support is infact included, but the driver I picked was one that is read only. I did try multiple, but found that the most stable solution since I kept reading things about poor compatibility on the other ones. That way you can get the file you need, but you can't screw things up. I tried it in my real systems and yes, my retro PC doesn't allow much in upper memory at all, thats all swallowed up by the hardware so I don't get the high amount of conventional memory free as was shown in the emulated system in the video (It was a full emulation however complete with Voodoo GPU, Trio64 and AWE32 so to me it was representative). The largest executable program size is 587KB for me which is still plenty but not always enough. But easily resolved by choosing the No option during the initial load on the things I don't need at the time. There has never been a program I could not use or a game I could not play because of memory shortcomings because everything it loads is optional. So by default on that 2005 era system only 54KB is used in the conventional memory because of my driver choices. The worst possible case would be 79KB if all the defaults are loaded, but can be easily cut further down since DOSKey uses 10KB. Skipping DOSKEY during startup you would already have 69KB at the absolute worst which you say you would be very glad about. Glad it inspired you though, looking forward to the video.

The tweaks necessary are in a script from china dos union I don't think I have anymore, its in the io.sys file. The easiest way to get it on your own system is either using my floppy, or copying the io.sys from it. Update: Tried looking the zip up with no success, but apparently rleow also has a patch that can do this to an existing io.sys file if you want to do this yourself without using mine. Vogons has some topics about it. I can't remember which one I eventually used, but my io.sys should serve you well regardless :D

@@Henk717 i put the CDU IO.SYS on a floppy disk image to copy to any Windows 95 OSR2, 98, etc. or any DOS 7.1 install. just installed DOS 7.1 CDU onto a VM and copied the IO.SYS onto a floppy disk image.

@@pentiummmx2294 Mine has the additional benefit of being even smaller than theirs. I don't know how stable it will keep working on a Windows 98 system though, its really meant for its own partition if you use 3.1.