DOS ain't dead

Hi!

Some days ago I remembered Datalight ROM-DOS.
Looks like since I last used ROM-DOS you now have to pay (US$55) even for the single-user version (SUV). Digging in my archive revealed a file named suv1594.zip.

Included Readme.txt says to use SYS A: to create a bootable floppy and then do XCOPY *.* A:. Okay, fine.
But what about people, who want to play with ROM-DOS in a virtual machine, don't have access to a physical floppy disk drive and can't use something like Virtual Floppy Drive?

For those people, I created the following two batch files.
Batch files rely on my X and IMGINIT/IMGCPY (part of MTOOLS.ZIP or fat-2006-12-03.zip).

Usage:
1) Get and extract suv1594.zip.
2) Put X.EXE, IMGINIT.EXE, IMGCPY.EXE, MKVFD622.BAT, and MKVFD71.BAT to the same directory.
3) Run MKVFD622.BAT and MKVFD71.BAT.

Then you get DLDOS622.VFD and DLDOS71.VFD for use in virtual machines.

`MKVFD622.BAT' for ROM-DOS 6.22:

@ECHO OFF
REM ***************************************************************************
REM Get parts.
X.EXE .\622\SYS.COM BOOTSECT.512 $2E67 512
X.EXE .\622\SYS.COM IBMBIO.512   $3067 512
REM ***************************************************************************
REM Prepare floppy image.
COPY /B IBMBIO.512+.\622\ROM-DOS.SYS IBMBIO.COM
ECHO ROM-DOS v6.22 (Revision 4.20.1594SU)> IBMDOS.COM
ECHO Copyright (c) 1989-2008 Datalight, Inc.>> IBMDOS.COM
REM FIXME: File attributes are ignored by IMGCPY.
REM ATTRIB +R +A +S +H IBMBIO.COM
REM ATTRIB +R +A +S +H IBMDOS.COM
REM ***************************************************************************
REM Create floppy image.
DEL DLDOS622.VFD
IMGINIT.EXE -fat12 DLDOS622.VFD BOOTSECT.512
IMGCPY.EXE IBMBIO.COM DLDOS622.VFD=A:\IBMBIO.COM
IMGCPY.EXE IBMDOS.COM DLDOS622.VFD=A:\IBMDOS.COM
IMGCPY.EXE .\622\COMMAND.COM DLDOS622.VFD=A:\COMMAND.COM
REM ***************************************************************************
REM Some cleanup.
DEL BOOTSECT.512
DEL IBMBIO.512
REM FIXME: File attributes are ignored by IMGCPY.
REM ATTRIB -R -A -S -H IBMBIO.COM
REM ATTRIB -R -A -S -H IBMDOS.COM
DEL IBMBIO.COM
DEL IBMDOS.COM
REM ***************************************************************************
REM Put the rest of the bunch.
IMGCPY.EXE .\622\ANSI.SYS DLDOS622.VFD=A:\ANSI.SYS
IMGCPY.EXE .\622\ATA.SYS DLDOS622.VFD=A:\ATA.SYS
IMGCPY.EXE .\622\ATTRIB.EXE DLDOS622.VFD=A:\ATTRIB.EXE
IMGCPY.EXE .\622\BACKUP.EXE DLDOS622.VFD=A:\BACKUP.EXE
IMGCPY.EXE .\622\CHKDSK.EXE DLDOS622.VFD=A:\CHKDSK.EXE
IMGCPY.EXE .\622\CHOICE.COM DLDOS622.VFD=A:\CHOICE.COM
IMGCPY.EXE .\622\COMM.EXE DLDOS622.VFD=A:\COMM.EXE
REM Skip next, because it's already there.
REM IMGCPY.EXE .\622\COMMAND.COM DLDOS622.VFD=A:\COMMAND.COM
IMGCPY.EXE .\622\COMMAND.HLP DLDOS622.VFD=A:\COMMAND.HLP
IMGCPY.EXE .\622\COUNTRY.SYS DLDOS622.VFD=A:\COUNTRY.SYS
IMGCPY.EXE .\622\DELTREE.EXE DLDOS622.VFD=A:\DELTREE.EXE
IMGCPY.EXE .\622\DISK2IMG.EXE DLDOS622.VFD=A:\DISK2IMG.EXE
IMGCPY.EXE .\622\DISKCOMP.COM DLDOS622.VFD=A:\DISKCOMP.COM
IMGCPY.EXE .\622\DISKCOPY.COM DLDOS622.VFD=A:\DISKCOPY.COM
IMGCPY.EXE .\622\DISPLAY.SYS DLDOS622.VFD=A:\DISPLAY.SYS
IMGCPY.EXE .\622\DUMP.EXE DLDOS622.VFD=A:\DUMP.EXE
IMGCPY.EXE .\622\EGA.CPI DLDOS622.VFD=A:\EGA.CPI
IMGCPY.EXE .\622\EGA3.CPI DLDOS622.VFD=A:\EGA3.CPI
IMGCPY.EXE .\622\EMM386.EXE DLDOS622.VFD=A:\EMM386.EXE
IMGCPY.EXE .\622\EXE2BIN.COM DLDOS622.VFD=A:\EXE2BIN.COM
IMGCPY.EXE .\622\FDISK.EXE DLDOS622.VFD=A:\FDISK.EXE
IMGCPY.EXE .\622\FIND.EXE DLDOS622.VFD=A:\FIND.EXE
IMGCPY.EXE .\622\FORMAT.COM DLDOS622.VFD=A:\FORMAT.COM
IMGCPY.EXE .\622\HIMEM.SYS DLDOS622.VFD=A:\HIMEM.SYS
IMGCPY.EXE .\622\KEYB.COM DLDOS622.VFD=A:\KEYB.COM
IMGCPY.EXE .\622\KEYBOARD.SYS DLDOS622.VFD=A:\KEYBOARD.SYS
IMGCPY.EXE .\622\KEYBRD2.SYS DLDOS622.VFD=A:\KEYBRD2.SYS
IMGCPY.EXE .\622\LABEL.EXE DLDOS622.VFD=A:\LABEL.EXE
IMGCPY.EXE .\622\MEM.EXE DLDOS622.VFD=A:\MEM.EXE
IMGCPY.EXE .\622\MODE.COM DLDOS622.VFD=A:\MODE.COM
IMGCPY.EXE .\622\MORE.COM DLDOS622.VFD=A:\MORE.COM
IMGCPY.EXE .\622\MOVE.EXE DLDOS622.VFD=A:\MOVE.EXE
IMGCPY.EXE .\622\MSCDEX.EXE DLDOS622.VFD=A:\MSCDEX.EXE
IMGCPY.EXE .\622\NED.EXE DLDOS622.VFD=A:\NED.EXE
IMGCPY.EXE .\622\NEDREMOT.CFG DLDOS622.VFD=A:\NEDREMOT.CFG
IMGCPY.EXE .\622\NEDREMOT.COM DLDOS622.VFD=A:\NEDREMOT.COM
IMGCPY.EXE .\622\POWER.EXE DLDOS622.VFD=A:\POWER.EXE
IMGCPY.EXE .\622\PRINT.EXE DLDOS622.VFD=A:\PRINT.EXE
IMGCPY.EXE .\622\RESTORE.EXE DLDOS622.VFD=A:\RESTORE.EXE
IMGCPY.EXE .\622\ROM-DOS.SYS DLDOS622.VFD=A:\ROM-DOS.SYS
IMGCPY.EXE .\622\RSZ.EXE DLDOS622.VFD=A:\RSZ.EXE
IMGCPY.EXE .\622\SERLINK.EXE DLDOS622.VFD=A:\SERLINK.EXE
IMGCPY.EXE .\622\SERSERV.EXE DLDOS622.VFD=A:\SERSERV.EXE
IMGCPY.EXE .\622\SHARE.EXE DLDOS622.VFD=A:\SHARE.EXE
IMGCPY.EXE .\622\SMARTDRV.EXE DLDOS622.VFD=A:\SMARTDRV.EXE
IMGCPY.EXE .\622\SORT.EXE DLDOS622.VFD=A:\SORT.EXE
IMGCPY.EXE .\622\STACKDEV.SYS DLDOS622.VFD=A:\STACKDEV.SYS
IMGCPY.EXE .\622\SUBST.EXE DLDOS622.VFD=A:\SUBST.EXE
IMGCPY.EXE .\622\SYS.COM DLDOS622.VFD=A:\SYS.COM
IMGCPY.EXE .\622\SYSXP.EXE DLDOS622.VFD=A:\SYSXP.EXE
IMGCPY.EXE .\622\TRANSFER.EXE DLDOS622.VFD=A:\TRANSFER.EXE
IMGCPY.EXE .\622\TREE.COM DLDOS622.VFD=A:\TREE.COM
IMGCPY.EXE .\622\UMBLINK.EXE DLDOS622.VFD=A:\UMBLINK.EXE
IMGCPY.EXE .\622\VDISK.SYS DLDOS622.VFD=A:\VDISK.SYS
IMGCPY.EXE .\622\VERSION.SYS DLDOS622.VFD=A:\VERSION.SYS
IMGCPY.EXE .\622\XCOPY.EXE DLDOS622.VFD=A:\XCOPY.EXE

`MKVFD71.BAT' for ROM-DOS 7.10:

@ECHO OFF
REM ***************************************************************************
REM Get parts.
X.EXE .\71\SYS.COM BOOTSECT.512 $2E67 512
X.EXE .\71\SYS.COM IBMBIO.512   $3067 512
REM ***************************************************************************
REM Prepare floppy image.
COPY /B IBMBIO.512+.\71\ROM-DOS.SYS IBMBIO.COM
ECHO ROM-DOS v7.10 (Revision 4.20.1594SU)> IBMDOS.COM
ECHO Copyright (c) 1989-2008 Datalight, Inc.>> IBMDOS.COM
REM FIXME: File attributes are ignored by IMGCPY.
REM ATTRIB +R +A +S +H IBMBIO.COM
REM ATTRIB +R +A +S +H IBMDOS.COM
REM ***************************************************************************
REM Create floppy image.
DEL DLDOS71.VFD
IMGINIT.EXE -fat12 DLDOS71.VFD BOOTSECT.512
IMGCPY.EXE IBMBIO.COM DLDOS71.VFD=A:\IBMBIO.COM
IMGCPY.EXE IBMDOS.COM DLDOS71.VFD=A:\IBMDOS.COM
IMGCPY.EXE .\71\COMMAND.COM DLDOS71.VFD=A:\COMMAND.COM
REM ***************************************************************************
REM Some cleanup.
DEL BOOTSECT.512
DEL IBMBIO.512
REM FIXME: File attributes are ignored by IMGCPY.
REM ATTRIB -R -A -S -H IBMBIO.COM
REM ATTRIB -R -A -S -H IBMDOS.COM
DEL IBMBIO.COM
DEL IBMDOS.COM
REM ***************************************************************************
REM Put the rest of the bunch.
IMGCPY.EXE .\71\ANSI.SYS DLDOS71.VFD=A:\ANSI.SYS
IMGCPY.EXE .\71\ATA.SYS DLDOS71.VFD=A:\ATA.SYS
IMGCPY.EXE .\71\ATTRIB.EXE DLDOS71.VFD=A:\ATTRIB.EXE
IMGCPY.EXE .\71\BACKUP.EXE DLDOS71.VFD=A:\BACKUP.EXE
IMGCPY.EXE .\71\CHKDSK.EXE DLDOS71.VFD=A:\CHKDSK.EXE
IMGCPY.EXE .\71\CHOICE.COM DLDOS71.VFD=A:\CHOICE.COM
IMGCPY.EXE .\71\COMM.EXE DLDOS71.VFD=A:\COMM.EXE
REM Skip next, because it's already there.
REM IMGCPY.EXE .\71\COMMAND.COM DLDOS71.VFD=A:\COMMAND.COM
IMGCPY.EXE .\71\COMMAND.HLP DLDOS71.VFD=A:\COMMAND.HLP
IMGCPY.EXE .\71\COUNTRY.SYS DLDOS71.VFD=A:\COUNTRY.SYS
IMGCPY.EXE .\71\DELTREE.EXE DLDOS71.VFD=A:\DELTREE.EXE
IMGCPY.EXE .\71\DISK2IMG.EXE DLDOS71.VFD=A:\DISK2IMG.EXE
IMGCPY.EXE .\71\DISKCOMP.COM DLDOS71.VFD=A:\DISKCOMP.COM
IMGCPY.EXE .\71\DISKCOPY.COM DLDOS71.VFD=A:\DISKCOPY.COM
IMGCPY.EXE .\71\DISPLAY.SYS DLDOS71.VFD=A:\DISPLAY.SYS
IMGCPY.EXE .\71\DUMP.EXE DLDOS71.VFD=A:\DUMP.EXE
IMGCPY.EXE .\71\EGA.CPI DLDOS71.VFD=A:\EGA.CPI
IMGCPY.EXE .\71\EGA3.CPI DLDOS71.VFD=A:\EGA3.CPI
IMGCPY.EXE .\71\EMM386.EXE DLDOS71.VFD=A:\EMM386.EXE
IMGCPY.EXE .\71\EXE2BIN.COM DLDOS71.VFD=A:\EXE2BIN.COM
IMGCPY.EXE .\71\FDISK.EXE DLDOS71.VFD=A:\FDISK.EXE
IMGCPY.EXE .\71\FIND.EXE DLDOS71.VFD=A:\FIND.EXE
IMGCPY.EXE .\71\FORMAT.COM DLDOS71.VFD=A:\FORMAT.COM
IMGCPY.EXE .\71\HIMEM.SYS DLDOS71.VFD=A:\HIMEM.SYS
IMGCPY.EXE .\71\KEYB.COM DLDOS71.VFD=A:\KEYB.COM
IMGCPY.EXE .\71\KEYBOARD.SYS DLDOS71.VFD=A:\KEYBOARD.SYS
IMGCPY.EXE .\71\KEYBRD2.SYS DLDOS71.VFD=A:\KEYBRD2.SYS
IMGCPY.EXE .\71\LABEL.EXE DLDOS71.VFD=A:\LABEL.EXE
IMGCPY.EXE .\71\MEM.EXE DLDOS71.VFD=A:\MEM.EXE
IMGCPY.EXE .\71\MODE.COM DLDOS71.VFD=A:\MODE.COM
IMGCPY.EXE .\71\MORE.COM DLDOS71.VFD=A:\MORE.COM
IMGCPY.EXE .\71\MOVE.EXE DLDOS71.VFD=A:\MOVE.EXE
IMGCPY.EXE .\71\MSCDEX.EXE DLDOS71.VFD=A:\MSCDEX.EXE
IMGCPY.EXE .\71\NED.EXE DLDOS71.VFD=A:\NED.EXE
IMGCPY.EXE .\71\NEDREMOT.CFG DLDOS71.VFD=A:\NEDREMOT.CFG
IMGCPY.EXE .\71\NEDREMOT.COM DLDOS71.VFD=A:\NEDREMOT.COM
IMGCPY.EXE .\71\POWER.EXE DLDOS71.VFD=A:\POWER.EXE
IMGCPY.EXE .\71\PRINT.EXE DLDOS71.VFD=A:\PRINT.EXE
IMGCPY.EXE .\71\RESTORE.EXE DLDOS71.VFD=A:\RESTORE.EXE
IMGCPY.EXE .\71\ROM-DOS.SYS DLDOS71.VFD=A:\ROM-DOS.SYS
IMGCPY.EXE .\71\RSZ.EXE DLDOS71.VFD=A:\RSZ.EXE
IMGCPY.EXE .\71\SERLINK.EXE DLDOS71.VFD=A:\SERLINK.EXE
IMGCPY.EXE .\71\SERSERV.EXE DLDOS71.VFD=A:\SERSERV.EXE
IMGCPY.EXE .\71\SHARE.EXE DLDOS71.VFD=A:\SHARE.EXE
IMGCPY.EXE .\71\SMARTDRV.EXE DLDOS71.VFD=A:\SMARTDRV.EXE
IMGCPY.EXE .\71\SORT.EXE DLDOS71.VFD=A:\SORT.EXE
IMGCPY.EXE .\71\STACKDEV.SYS DLDOS71.VFD=A:\STACKDEV.SYS
IMGCPY.EXE .\71\SUBST.EXE DLDOS71.VFD=A:\SUBST.EXE
IMGCPY.EXE .\71\SYS.COM DLDOS71.VFD=A:\SYS.COM
IMGCPY.EXE .\71\SYSXP.EXE DLDOS71.VFD=A:\SYSXP.EXE
IMGCPY.EXE .\71\TRANSFER.EXE DLDOS71.VFD=A:\TRANSFER.EXE
IMGCPY.EXE .\71\TREE.COM DLDOS71.VFD=A:\TREE.COM
IMGCPY.EXE .\71\UMBLINK.EXE DLDOS71.VFD=A:\UMBLINK.EXE
IMGCPY.EXE .\71\VDISK.SYS DLDOS71.VFD=A:\VDISK.SYS
IMGCPY.EXE .\71\VERSION.SYS DLDOS71.VFD=A:\VERSION.SYS
IMGCPY.EXE .\71\XCOPY.EXE DLDOS71.VFD=A:\XCOPY.EXE

---
Forum admin

> Looks like since I last used ROM-DOS you now have to pay (US$55) even for
> the single-user version (SUV). Digging in my archive revealed a file named
> suv1594.zip.

Never used it, but I'm aware they still sell it online. (Kernel 7 is the LFN-aware series, right?) It hasn't been freeware for many years.

> Included Readme.txt says to use SYS A: to create
> a bootable floppy and then do XCOPY *.* A:. Okay, fine.
> But what about people, who want to play with ROM-DOS in a virtual machine,
> don't have access to a physical floppy disk drive and can't use something
> like Virtual Floppy Drive?

Buy a USB floppy drive, like I did (years ago). It works for the obvious 1.44 MB, 3.5" disks.

They seem to include a util called SYSXP.EXE, so I assume that's what you'd use atop Windows.

To extract files from a FAT .img, I'd just use 7-zip's 7Z.EXE.

For other uses, I'd use QEMU or libguestfs.

But .BATs like these are still cool and useful, obviously.

> (Kernel 7 is the LFN-aware series, right?)

Yes.

> Buy a USB floppy drive, like I did (years ago). It works for the obvious
> 1.44 MB, 3.5" disks.

Valid solution, if you're not in a hurry.

> They seem to include a util called SYSXP.EXE, so I assume that's what you'd
> use atop Windows.

Their SYSXP.EXE is for Windows, what SYS.COM is for DOS. Even SYS.COM works in XP x86, if you ACK its question about full access to the drive.

> To extract files from a FAT .img, I'd just use 7-zip's 7Z.EXE.

And how do you create a new FAT image? Yes, it's a rhetorical question, because you can always have spare one lying around and making a copy of.

> For other uses, I'd use QEMU or
> libguestfs.

A little bloated, I think.

> But .BATs like these are still cool and useful, obviously.

I'm often looking for the more difficult ways.

---
Forum admin

> > To extract files from a FAT .img, I'd just use 7-zip's 7Z.EXE.
>
> And how do you create a new FAT image? Yes, it's a rhetorical question,
> because you can always have spare one lying around and making a copy of.

Allegedly, Win10 doesn't come with a system MS-DOS (EBD) floppy image anymore, but older Windows like 7 have it in DISKCOPY.DLL (optionally used by RUFUS).

Creating a FAT image is easy on Win7 since it can mount such .VHD files into Explorer as a drive. (You can also use QEMU-IMG, but the one I tried was buggy, so Win7 didn't like it. I have no idea how to isolate that bug or to whom to report it.) Under Win7, I did so twice for MetaDOS (FAT16 and FAT32) and put both of them in HARDDISK.ZIP (albeit empty of any actual useful data).

Since 2014 (11.0), FreeBSD has also supported its own hypervisor (VT-X with EPT required), bhyve. But I've never used it. They also had a utility for disk creation / manipulation, but I forget the name (and a quick search doesn't show anything obvious).

> Since 2014 (11.0), FreeBSD has also supported its own hypervisor (VT-X with
> EPT required), bhyve. But I've never used it. They also had a utility for
> disk creation / manipulation, but I forget the name (and a quick search
> doesn't show anything obvious).

Usually the *nix commands are of the form mk*fs or mkfs.* with * the name of the filesystem. Try *=msdos dos,fat,vfat etc.

> > Since 2014 (11.0), FreeBSD has also supported its own hypervisor
> > (VT-X with EPT required). They also had a utility for disk creation
> > / manipulation.
>
> Usually the *nix commands are of the form mk*fs or mkfs.* with * the name
> of the filesystem. Try *=msdos dos,fat,vfat etc.

Apparently I was thinking of mkimg (first appeared in FreeBSD 10.1, from Nov. 2014).

As an aside, most newer cpus (2015+ ??) seems to have VT-X nowadays, thankfully. Even this Dell Chromebook has it ("Linux (beta)" Debian x64 container via KVM), but my old 2010 Dell laptop doesn't (while my 2011 Lenovo desktop has it). It helps a ton, obviously. Apparently VBox 6.1 series forcibly requires it (but 6.0 series is still supported until July 2020). Even 6.0 drops 32-bit host support!

> As an aside, most newer cpus (2015+ ??) seems to have VT-X nowadays,

Much earlier (like Sandy Bridge, which is afaik the 2011 generation), though Intel played games with that support, initially reserving that support for the more expensive (i7) series.

> thankfully. Even this Dell Chromebook has it ("Linux (beta)" Debian x64
> container via KVM), but my old 2010 Dell laptop doesn't (while my 2011
> Lenovo desktop has it). It helps a ton, obviously. Apparently VBox 6.1
> series forcibly requires it (but 6.0 series is still supported until July
> 2020). Even 6.0 drops 32-bit host support!

I cleaned out all Core2's early last year. So the oldest that I have now (except some Pentium-Ds) are Ivy Bridges. All have VT-X, since I looked out for that while buying

> > As an aside, most newer cpus (2015+ ??) seems to have VT-X nowadays,
>
> Much earlier (like Sandy Bridge, which is afaik the 2011 generation),
> though Intel played games with that support, initially reserving that
> support for the more expensive (i7) series.

My Lenovo desktop (Core i5, dual core, quasi four with HTT) from 2011 has Nehalem Westmere (tail end of gen 1) with VT-X and nested page tables (unrestricted guest mode, unreal/big real, whatever). Trying to emulate anything on my 2009 Dell (Penryn?) dual-core laptop was like pulling teeth. (I vaguely recall shortening build time for p7zip under QEMU/FreeDOS from 11 hours to 5 just by avoiding LFNs. Yeah, I know, fairly pointless, but it's still a useful util, even if nobody cares about rebuilding in DOS like they should.) Now that BIOS/CSM is effectively dead (no more native booting), VT-X is very crucial (if you "need" legacy that badly).

This low-end Chromebook is only supported until (I think) June 2022. The battery will "probably" die before then. (My 2011 Lenovo Android tablet lasted six years with its battery before the *software* failed!) There are of course much more expensive Chromebooks (Pixelbook?). This one has Intel N3060, Braswell/Airmont, only dual core, only SSE 4.2, no AVX. (So, a shrunken Celeron 2016 cpu in a 2019 model Chromebook from 2013 cpu tech.) So not really worse than the older hardware I already have. It's impossible to fully know or appreciate these things without taking a leap of faith and buying one.

There's too many cpus. Zen was from early 2017. MS Surface has Zen+. Zen 2 was just released. Intel's on, what, gen 10 or 11?? It's too much. I did briefly online look at some Dell Ryzen laptops, but I really wanted a reasonable Linux one, not Windows.

> I cleaned out all Core2's early last year. So the oldest that I have now
> (except some Pentium-Ds) are Ivy Bridges. All have VT-X, since I looked out
> for that while buying

You mentioned AVX2 on FASM's forum. I'm a bit underwhelmed there, but obviously all the math (Fortran?) nerds love it. I'm just not trendy or smart enough to care. Did you hear about AMD Threadripper 3 or whatever? 64 cores/128 threads! Phoronix did some tests vs. 2004 cpus, shows quite an increase!

I used to occasionally read the blog of the Darek Mihocka. He always kept up with various cpu releases, architectures, Bochs, emulators (including his own old Atari ones). He had a DOS one that he open-sourced years ago. So he was talking about various things like Haswell and other "modern" cpus. So that's what this reminds me of, even though I admit to not knowing or caring about literally every new tech release. I don't upgrade or purchase new stuff often, just mildly (morbidly??) curious.

I don't know what Delphi or FPC supports regarding multiple cores (a la OpenMP). And everything is ARM64 or x64 nowadays. One guy did write a C++11/17 book on multithreading, but I've not bothered learning C++ ('20 just finalized? ugh, "coming soon"). The world has barely caught up to '14/'17 yet. Even Delphi has too many versions (and books), so I worry about even pretending to care about that.

> My Lenovo desktop (Core i5, dual core, quasi four with HTT) from 2011 has
> Nehalem Westmere (tail end of gen 1) with VT-X and nested page tables
> (unrestricted guest mode, unreal/big real, whatever). Trying to emulate
> anything on my 2009 Dell (Penryn?) dual-core laptop was like pulling teeth.
> (I vaguely recall shortening build time for p7zip under QEMU/FreeDOS from
> 11 hours to 5 just by avoiding LFNs.

I don't remember exactly. Anyways, on this Lenovo 3.2 Ghz desktop (Win7, 64-bit), it only takes 8 minutes to rebuild on VBox 6.1.2 but 8 + 1/2 hours with QEMU 4.2.0 (no VT-X support, so I left it overnight).

> > > As an aside, most newer cpus (2015+ ??) seems to have VT-X nowadays,
> >
> > Much earlier (like Sandy Bridge, which is afaik the 2011 generation),
> > though Intel played games with that support, initially reserving that
> > support for the more expensive (i7) series.
>
> My Lenovo desktop (Core i5, dual core, quasi four with HTT) from 2011 has
> Nehalem Westmere (tail end of gen 1) with VT-X and nested page tables
> (unrestricted guest mode, unreal/big real, whatever).

Westmere was server, and mostly labeled as "Xeons", not "i5". If you have a 650 or 655, that is "enthusiast" variant Clarkdale. Still it was impressive stuff for the time. I skipped those however, goign from Core2 6600 (the original Conroe) jumping over three generations (core 8xxx, Nehalem and Sandy Bridge) to i7-3770.

> Trying to emulate
> anything on my 2009 Dell (Penryn?) dual-core laptop was like pulling teeth.
> (I vaguely recall shortening build time for p7zip under QEMU/FreeDOS from
> 11 hours to 5 just by avoiding LFNs. Yeah, I know, fairly pointless, but
> it's still a useful util, even if nobody cares about rebuilding in DOS like
> they should.) Now that BIOS/CSM is effectively dead (no more native
> booting), VT-X is very crucial (if you "need" legacy that badly).

Yes. Note that VT-X is mainly for non-cooperating (full emulation) OSes. Stuff like Linux runs better, because some high bandwidth drivers are replaced by ones that hand it nicely to the hypervisor.

> This low-end Chromebook is only supported until (I think) June 2022. The
> battery will "probably" die before then. (My 2011 Lenovo Android tablet
> lasted six years with its battery before the *software* failed!) There are
> of course much more expensive Chromebooks (Pixelbook?). This one has Intel
> N3060, Braswell/Airmont, only dual core, only SSE 4.2, no AVX. (So, a
> shrunken Celeron 2016 cpu in a 2019 model Chromebook from 2013 cpu tech.)
> So not really worse than the older hardware I already have. It's impossible
> to fully know or appreciate these things without taking a leap of faith and
> buying one.

Chromebooks are mainly intended to do some surfing (and then mostly "on the road"). I avoid them, and the N series in general (though I know some of the later ones are out of order, and not as bad as the early Atom ones).

I do a lot of FPC compiling, and while that doesn't require a umpteen core threadripper, a basic quad core is nice. Higher core counts are less utilized. (e.g. my Ryzen 2600 hexa core is about 25-35% faster than the i7-3770 compiling FPC).

Zen is nice though. The old core AMD advantages, price/performance, working well also if code isn't particularly optimized for it, and less playing games with the processor lineup than Intel does (this one gets vt-x, that one gets hyperthreading etc). A large part of the lineup has all features enabled.

At work we have the budget AMDs (about Eur 50, tax inclusive) as workhorse, Athlon 200GE, based on original Zen. Even those are nice.

> There's too many cpus. Zen was from early 2017. MS Surface has Zen+. Zen 2
> was just released. Intel's on, what, gen 10 or 11?? It's too much. I did
> briefly online look at some Dell Ryzen laptops, but I really wanted a
> reasonable Linux one, not Windows.

Wait. This summer a Ryzen 4xxx series laptops should come out, and they will be good. My work laptop is up for a change, so I might snap one up myself.

Buying "official" linux branded hardware is maybe not wise. Usually they are targeted at education and research institutions and relatively overpriced.

> > I cleaned out all Core2's early last year. So the oldest that I have now
> > (except some Pentium-Ds) are Ivy Bridges. All have VT-X, since I looked
> out
> > for that while buying
>
> You mentioned AVX2 on FASM's forum. I'm a bit underwhelmed there, but
> obviously all the math (Fortran?) nerds love it.

Remember that for work I'm in image processing. We had quite some projects lately that required some whole image processing, and then using SIMD matters. Speedups of 4 or 6 times are common if not too large (relative to the cache), and this is often the most expensive operation done on an image.

For normal programming it matters less if a few primitives (like memcpy/strlen and search for a byte/word/dword/qword in memory) optimized.

For fun here is one of my older SSE2/3 experiments, rotating an 1 byte per pixel image by 90 degrees: http://www.stack.nl/~marcov/rot8x8.txt

But it only slowly progresses since it is half an hobby, and the projects that I'm preparing for sometimes simply don't get realized, or only much later than planned.

> I'm just not trendy or
> smart enough to care. Did you hear about AMD Threadripper 3 or whatever? 64
> cores/128 threads! Phoronix did some
> tests
> vs. 2004 cpus, shows quite an increase!

That thing is a beast, but also expensive (Eur 4000) a very unpractical power requirement (noisy) etc.

But the fun part of the CPU market now is that the moderate (Eur 100-200) pricerange is quite nice too!

> I don't know what Delphi or FPC supports regarding multiple cores (a la
> OpenMP).

There is a binding for openmp, but not much. Of course normal threadsupport works. OpenMP is mainly for clustering purposes, not for cores within one machine.

The FPC project's build process uses Make in parallel mode on directories, getting about two to four times as fast when enabling multi core. But going from quad to hexacore or higher doesn't bring much, since due to dependencies they are underutilized.

But that is compiling FPC, not compiling WITH FPC.


> And everything is ARM64 or x64 nowadays. One guy did write a
> C++11/17 book on
> multithreading,
> but I've not bothered learning C++ ('20 just finalized? ugh, "coming
> soon"). The world has barely caught up to '14/'17 yet. Even Delphi has too
> many versions (and books), so I worry about even pretending to care about
> that.

Yes. All main apps are 64-bit at work except for one. That exception does a lot of x87 math. (like sin/cos etc), which seems to be faster in 32-bit, at least with Delphi.

C++20 has exciting new features like Modules and Coroutines. You know, the features that Modula2 had in 1980, and Modules were backported to Turbo Pascal as units in '86 or so

Maybe in 2040 they finally realize that = vs == is not smart either.

> IAnyways, on this Lenovo 3.2 Ghz desktop (Win7, 64-bit),
> [rebuilding p7zip] only takes 8 minutes to rebuild on VBox 6.1.2
> but 8 + 1/2 hours with QEMU 4.2.0 (no VT-X support.

First of all, I forgot to mention that M.K.'s CurlTiny (7.64?) doesn't seem to work on SF.net anymore, ugh. So I just used Links2 to manually download the source tarball. (EDIT: CURLTINY.EXE won't work, for unknown reasons, but CURLLITE.EXE and CURL.EXE both seem to still work okay.)

Anyways, for laughs, I updated to latest 6.0.x series of VBox (6.0.16) on my ancient non-VT-X laptop (2.2 Ghz). It's actually faster than QEMU on the better desktop: "only" five hours!

Just FYI. (YMMV.)

> > Anyways, on this Lenovo 3.2 Ghz desktop (Win7, 64-bit),
> > [rebuilding p7zip] only takes 8 minutes to rebuild on VBox 6.1.2
> > but 8 + 1/2 hours with QEMU 4.2.0 (no VT-X support.
>
> Anyways, for laughs, I updated to latest 6.0.x series of VBox (6.0.16) on
> my ancient non-VT-X laptop (2.2 Ghz). It's actually faster than QEMU on the
> better desktop: "only" five hours!

I don't wish to be off-topic, but this subforum is about emulation, and the OP is using ROM-DOS under a virtual machine. (N.B. Tuxera [NTFS on Linux] apparently bought Datalight last year.)

Mainly, I'm just following up with stats about cross-compilation (compared with slower emulation of native compilation). I'm testing Andrew Wu's cross G++ 7.2.0 (DJGPP 2.05, BinUtils 2.29, "MinGW standalone") atop Win7 SP1 64-bit. Actually, I'm using FPC's GNU Make 3.82 (dated 2012, built for "i686-pc-mingw32").

I tried -j1, -j2, etc., all up through -j6 on this "four" core Clarkdale (Lenovo i5 650). It's actually two cores but HTT makes it pretend to have four. But all the compiles seem the same speed, surprisingly, roughly 72 seconds, and all match the same CRC32 for 7ZA.EXE (which differs extremely slightly to the native DJGPP build, even with same version tools, dunno why). Hmmm, since "make -j" does infinite jobs, I tried that: only 33 secs!

Honestly, I almost resent cross-compilation. Not when it works (which is rare), but moreso because it just lets everything fall apart and ignores obvious portability problems with reasonable solutions. "All the world's a VAX!" It's good to have the option, but when even that doesn't work, it's annoying.

> Mainly, I'm just following up with stats about cross-compilation (compared
> with slower emulation of native compilation).

Just to follow up: native FreeDOS (on this same 3.2 Ghz machine), XMS only, LBAcache loaded, everything on RAM disk, all binaries uncompressed, it only takes about three minutes (3:14) to rebuild 7ZA.EXE. With LFNs enabled (thus avoiding some ugly patches I made), while resulting in the same CRC32, it's much slower at about nine minutes (9:06). EDIT: I can shorten it from 3:14 to 2:46 if I load "hdpmi32 -r" (HX 2.18) first. Saves 15% of time (roughly 30 secs).

So I wouldn't call three or even eight or nine minutes horrible. I know this isn't something you'd compile every day from scratch either. Still, it is curious how much it varies. Also, good to know that newer G++ versions aren't too much slower to rebuild stuff.

> For those people, I created the following two batch files.
> Batch files rely on my
> X and IMGINIT/IMGCPY
> (part of MTOOLS.ZIP or
> fat-2006-12-03.zip).

I created a much smaller variant using Bart Lagerweij's Build Floppy Image v1.0.

This is also not perfect, because BFI also ignores file attributes present for source files. BFI uses the WinImage SDK from WinImage 6.10. Both are not FLOSS.

> Usage:
> 1) Get and extract suv1594.zip.
> 2) Put X.EXE, IMGINIT.EXE,
> IMGCPY.EXE, MKVFD622.BAT, and

Not IMGINIT.EXE and IMGCPY.EXE, but BFI.EXE.

> MKVFD71.BAT to the same directory.
> 3) Run MKVFD622.BAT and MKVFD71.BAT.
>
> Then you get DLDOS622.VFD and DLDOS71.VFD for use
> in virtual machines.
>
> `MKVFD622.BAT' for ROM-DOS 6.22:

@ECHO OFF
REM ***************************************************************************
REM Get parts.
X.EXE 622\SYS.COM BOOTSECT.512 $2E67 512
X.EXE 622\SYS.COM IBMBIO.512   $3067 512
REM ***************************************************************************
REM Prepare floppy image.
COPY /B IBMBIO.512+622\ROM-DOS.SYS 622\IBMBIO.COM
ECHO ROM-DOS v6.22 (Revision 4.20.1594SU)> 622\IBMDOS.COM
ECHO Copyright (c) 1989-2008 Datalight, Inc.>> 622\IBMDOS.COM
REM FIXME: File attributes are ignored by BFI.
REM ATTRIB +R +A +S +H 622\IBMBIO.COM
REM ATTRIB +R +A +S +H 622\IBMDOS.COM
REM ***************************************************************************
REM Create floppy image.
DEL DLDOS622.VFD
BFI.EXE -o=IBMBIO.COM -oIBMDOS.COM -oCOMMAND.COM -b=BOOTSECT.512 -f=DLDOS622.VFD 622\
REM ***************************************************************************
REM Some cleanup.
DEL BOOTSECT.512
DEL IBMBIO.512
REM FIXME: File attributes are ignored by BFI.
REM ATTRIB -R -A -S -H 622\IBMBIO.COM
REM ATTRIB -R -A -S -H 622\IBMDOS.COM
DEL 622\IBMBIO.COM
DEL 622\IBMDOS.COM

> `MKVFD71.BAT' for ROM-DOS 7.10:

@ECHO OFF
REM ***************************************************************************
REM Get parts.
X.EXE 71\SYS.COM BOOTSECT.512 $2E67 512
X.EXE 71\SYS.COM IBMBIO.512   $3067 512
REM ***************************************************************************
REM Prepare floppy image.
COPY /B IBMBIO.512+71\ROM-DOS.SYS 71\IBMBIO.COM
ECHO ROM-DOS v7.10 (Revision 4.20.1594SU)> 71\IBMDOS.COM
ECHO Copyright (c) 1989-2008 Datalight, Inc.>> 71\IBMDOS.COM
REM FIXME: File attributes are ignored by BFI.
REM ATTRIB +R +A +S +H 71\IBMBIO.COM
REM ATTRIB +R +A +S +H 71\IBMDOS.COM
REM ***************************************************************************
REM Create floppy image.
DEL DLDOS71.VFD
BFI.EXE -o=IBMBIO.COM -oIBMDOS.COM -oCOMMAND.COM -b=BOOTSECT.512 -f=DLDOS71.VFD 71\
REM ***************************************************************************
REM Some cleanup.
DEL BOOTSECT.512
DEL IBMBIO.512
REM FIXME: File attributes are ignored by BFI.
REM ATTRIB -R -A -S -H 71\IBMBIO.COM
REM ATTRIB -R -A -S -H 71\IBMDOS.COM
DEL 71\IBMBIO.COM
DEL 71\IBMDOS.COM

---
Forum admin

> I created a much smaller variant using
> Bart Lagerweij's
> Build Floppy Image v1.0.
>
> This is also not perfect, because BFI also ignores file attributes present
> for source files. BFI uses the WinImage SDK from WinImage 6.10. Both are
> not FLOSS.

You can use my bootimg NASM script, which is 100% FLOSS (Fair License) and runs atop NASM (2-clause BSD license). Unfortunately it cannot initialise the BPB of the boot sector loader file. (It uses NASM's incbin directive which only allows including entire files, unlike say dd.) Also, it likewise does not support file attributes (yet), nor file datetimes. Additionally you have to list every file to include in the image, you cannot just instruct it to take a directory (because NASM does not have any interface for a source file to walk a directory).

For writing a boot sector loader there's my instsect application but it only supports operation with an actual DOS drive, not with image files (yet).

---
l

I just added two options that help initialising the boot sector loader. Before this commit, _BOOTFILE had to point to a 512-bytes file complete with the BPB properly initialised already. If that is not the case, the new options _BOOTJUMPFILE and _BOOTCODEFILE allow specifying loader fragments to initialise, while the script will write the BPB itself. The jump file should be 3 or 11 bytes long, taken from the beginning of the loader file. The code file, for FAT12 or FAT16, should be 450 (or 448 or 446) bytes taken starting from offset 3Eh in the loader file. Here is an example, using dd. Your X could be used instead, too.

bootimg$ dd if=../ldosboot/boot12.bin bs=1 skip=$((0x3E)) of=code.bin
450+0 records in
450+0 records out
450 bytes copied, 0.00307256 s, 146 kB/s
bootimg$ dd if=../ldosboot/boot12.bin bs=1 skip=0 count=11 of=jump.bin
11+0 records in
11+0 records out
11 bytes copied, 0.000261832 s, 42.0 kB/s
bootimg$ nasm -I ../lmacros/ bootimg.asm -D_PAYLOADFILE=::empty -D_BOOTJUMPFILE="'jump.bin'" -D_BOOTCODEFILE="'code.bin'"
bootimg$

---
l

> I just added two options that help initialising the boot sector loader.
> Before this commit, _BOOTFILE had to point to a 512-bytes file complete
> with the BPB properly initialised already. If that is not the case,
> the new options
> _BOOTJUMPFILE and _BOOTCODEFILE allow specifying loader fragments to
> initialise, while the script will write the BPB itself. The jump file
> should be 3 or 11 bytes long, taken from the beginning of the loader file.
> The code file, for FAT12 or FAT16, should be 450 (or 448 or 446) bytes
> taken starting from offset 3Eh in the loader file. Here is an example,
> using dd. Your X could be used instead, too.

Thanks!

---
Forum admin

I just added image file operation to instsect, allowing to use a command like instsect.com /M=diskette.img /S=bootsect.bin to write an arbitrary boot sector loader, with the BPB preserved. (Add /SN if the loader template's FS ID string does not match what instsect expects.)

---
l

Here's two variants of a batch file to do most of what you did. I didn't have the ROM-DOS files around so I made them with a few test files. Adjusting these scripts to install an actual DOS is left as an exercise to the reader. Likewise, using dd and bash for is easy to do based on this.

These scripts both assume that the source files are found in subdirectories of the DOS working directory. (All source files from my hg repos.) NASM and X need to be in the PATH. The directory testdir contains files that are all meant to be copied to the image. The ::empty keyword is a placeholder here, and could be replaced by actual files (found in the root directory not testdir).

Both scripts create almost the same output; the "large total sectors" field ends up initialised unnecessarily when using instsect. Still missing: File datetimes, file attributes.

=== makdx.bat

@echo %DEBUG%off
nasm -I lmacros/ ldosboot/boot.asm -D_COMPAT_LDOS -D_LOAD_NAME="'LDEBUG'" -o boot12.bin
x boot12.bin bootjump.bin 0 11
x boot12.bin bootcode.bin $3E
echo ; Auto-generated file, do not edit. > list.mac
echo %%define _BOOTJUMPFILE "bootjump.bin" >> list.mac
echo %%define _BOOTCODEFILE "bootcode.bin" >> list.mac
:: echo %%xdefine _PAYLOADFILE _PAYLOADFILE,::chdir,testdir >> list.mac
for %%i in (testdir\*.*) do echo %%xdefine _PAYLOADFILE _PAYLOADFILE,"%%i" >> list.mac
nasm -I lmacros/ bootimg/bootimg.asm -D_PAYLOADFILE=::empty -P list.mac -o diskette.img

=== makdinst.bat

@echo %DEBUG%off
nasm -I lmacros/ ldosboot/boot.asm -D_COMPAT_LDOS -D_LOAD_NAME="'LDEBUG'" -o boot12.bin
nasm -I lmacros/ instsect/instsect.asm -D_FAT16=0 -D_FAT32=0 -o inst12.com
echo ; Auto-generated file, do not edit. > list.mac
:: echo %%xdefine _PAYLOADFILE _PAYLOADFILE,::chdir,testdir >> list.mac
for %%i in (testdir\*.*) do echo %%xdefine _PAYLOADFILE _PAYLOADFILE,"%%i" >> list.mac
nasm -I lmacros/ bootimg/bootimg.asm -D_PAYLOADFILE=::empty -P list.mac -o diskette.img
inst12.com /M=diskette.img /S=boot12.bin
:: /SN
:: /F=ldebug.com

---
l

> Both scripts create almost the same output; the "large total sectors" field
> ends up initialised unnecessarily when using instsect. Still missing: File
> datetimes, file attributes.

Changed it so the output of both is exactly the same: https://hg.ulukai.org/ecm/instsect/rev/137027e11001

---
l

> > Both scripts create almost the same output; the "large total sectors"
> field
> > ends up initialised unnecessarily when using instsect. Still missing:
> File
> > datetimes, file attributes.
>
> Changed it so the output of both is exactly the same:
> https://hg.ulukai.org/ecm/instsect/rev/137027e11001

Added support for file attributes and datetimes, documented in https://hg.ulukai.org/ecm/bootimg/file/5f6e94c6e7fe/bootimg.asm#l45 (The defaults are to use no attributes and leave the file datetimes as the zero values, which correspond to the fictional datetime "1980-00-00 00:00:00". This is compatible to the prior behaviour of the bootimg script.)

---
l