DOS ain't dead

glennmcc

North Jackson, Ohio (USA),
21.07.2023, 20:13

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

> I released new versions DRDOS 7.01.7 & 7.01.8
>
> Files with the "org" extension are uncompressed, while the others are.
>

Fantastic !

I did not know that anyone was working on new versions.

Question: Do either of them have 'native' FAT32 support
and/or 'native' LFN support ?

---
--
http://glennmcc.org/

nico7550 21.07.2023, 20:27 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Hi, for sure I love to see new version of old kernel, so it's based on EDR-DOS 7.01.08 WIP ? What kind of tests do you need ? I'm finishing to integrate Paragon DOS 7.01 in my bootdisk and I will take a look at it.

fritz.mueller Munich, Germany, 21.07.2023, 20:29 @ nico7550	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Hi, ehhmmm, where to click to download it? There is only advertisement.

glennmcc

North Jackson, Ohio (USA),
21.07.2023, 20:34

@ fritz.mueller

New version DRDOS 7.01.7 & 7.01.8

Post reply

> Hi,
> ehhmmm, where to click to download it? :-(
> There is only advertisement.

Click the 'Pobierz plik' button.

English translation... 'download file'

---
--
http://glennmcc.org/

CandyMan 21.07.2023, 22:18 @ nico7550	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> What kind of tests do you need ? Booting on real hardware with multiple drives. It would be useful to test individual system functions (checking the operation of interrupts - 21h, 2Fh etc.) in order to detect bugs.

nico7550 21.07.2023, 22:45 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> > What kind of tests do you need ? > > Booting on real hardware with multiple drives. It would be useful to test > individual system functions (checking the operation of interrupts - 21h, > 2Fh etc.) in order to detect bugs. Sadly, I give old my old computers to a local computer club in order to make room in the house. I'm using 86Box for some years and I'm relly happy with it.

nico7550 22.07.2023, 09:40 @ nico7550	New version DRDOS 7.01.7 & 7.01.8 Post reply
	But I will test it for sure. Can you give some info about the compression process (did you remove the loader at the begining of the file to turn it into an exe, patch it a lot, compress it and reinject the loader to turn it back to sys as Mercury127 did with his IOPACK suite of tools based on aPACK) ?

CandyMan

22.07.2023, 23:06

@ nico7550

New version DRDOS 7.01.7 & 7.01.8

Post reply

> But I will test it for sure. Can you give some info about the compression
> process (did you remove the loader at the begining of the file to turn it
> into an exe, patch it a lot, compress it and reinject the loader to turn it
> back to sys as Mercury127 did with his IOPACK suite of tools based on
> aPACK) ?

Not exactly, but I used the aPACK and UPX programs for the BIOS and DOS parts respectively and some tricks.

Guti

24.07.2023, 11:08

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

Love you are bringing back the EDR-DOS project!

> I released new versions DRDOS 7.01.7 & 7.01.8
>
> Files with the "org" extension are uncompressed, while the others are.
>
> Here are some changes:
>
> Does not scan LBA drives when dx<80h,
> For unsupported functions, 71xx returns ax=7100h again,
> Handling interrupts 0x00 and 0x06 (division by zero and invalid opcode) as
> in FreeDos.
>
> You can download it from here:
> https://megawrzuta.pl/download/252a1cd7d21a0187e9e04a5fbc4dbc86.html
>
> nico7550 can you test this version?

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

CandyMan 25.07.2023, 15:04 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Here is another improved version of EDR-DOS. Now the interrupt vectors saved at startup are again at the fixed address 0070h:0100h. There is also MS.COM (Memory Statistics) at the request of nico7550. https://megawrzuta.pl/download/e7c2a5ace1d02143ea0c64ac15b49135.html

nico7550

26.07.2023, 15:19

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

> Here is another improved version of EDR-DOS. Now the interrupt vectors
> saved at startup are again at the fixed address 0070h:0100h.
>
> There is also MS.COM (Memory Statistics) at the request of nico7550.
>
> https://megawrzuta.pl/download/e7c2a5ace1d02143ea0c64ac15b49135.html

Hi,

Thanks for this update

Should the behaviour be different when using the compressed ot the uncompressed version ?

Why working on .7 instead of only .8 ?

Thanks for the MS tools it's great, small and a lot of info, can I ask one thing please:
can the default scren be the summary screen (last screen) and a switch to have the details screen instead of all screen at once ? (you can also take a look to the memory tools source by Japheth (EMSSTAT, XMSSTAT and MEMSTAT) if you want to add more stuff ? Maybe produce a lightweigh version also ? With only a summary scren) Anyway great I will use MS now.

Guti

30.07.2023, 11:12

@ nico7550

New version DRDOS 7.01.7 & 7.01.8

Post reply

> Why working on .7 instead of only .8 ?
I am curious too.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

DieTotenByte 30.07.2023, 01:09 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Hi CandyMan. Can you upload the sourcecode or some diff? I have been messing around DRDos source, mostly to add a few options to make the booting process and command com less verbose, and I'd love to see what you did.

CandyMan 30.07.2023, 10:55 @ DieTotenByte	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> Hi CandyMan. Can you upload the sourcecode or some diff? > I have been messing around DRDos source, mostly to add a few options to > make the booting process and command com less verbose, and I'd love to see > what you did. Here is the source code: https://megawrzuta.pl/download/cbef417c0f85eeaed244828d5915c6e5.html

CandyMan 03.08.2023, 21:46 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Today I added the INT21.AX33FF.DX0000 function as in RxDOS and FreeeDOS. I also removed exception handling 0x6 due to some BIOSes using invalid CPU instructions prefixed with 0xF0 (LOCK) generating this exception. New kernel files are here: https://megawrzuta.pl/download/61b85729a033da2c534aab878da404c0.html

CandyMan 10.08.2023, 11:09 @ CandyMan	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Here is my final version of EDR-DOS 7.01.8 for now, checked by nico7550. https://megawrzuta.pl/download/52f9590ae302e4d20b693e7e1b79ca72.html

ecm

Düsseldorf, Germany,
10.08.2023, 15:52

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

> Here is my final version of EDR-DOS 7.01.8 for now, checked by nico7550.
>
> https://megawrzuta.pl/download/52f9590ae302e4d20b693e7e1b79ca72.html

The older latest EDR-DOS had a bug when 64-bit seek (int 21h function 7142h) was called on redirector handles. DOS should either return an error then, or try to pass it to the dosemu2 extension service int 2Fh function 11C2h/1142h (as my seekext TSR does). Perhaps you can include a fix to that?

---
l

CandyMan 10.08.2023, 19:21 @ ecm	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> The older latest EDR-DOS had a bug when 64-bit seek (int 21h function > 7142h) was called on redirector handles. DOS should either return an error > then, or try to pass it to the dosemu2 extension service int 2Fh function > 11C2h/1142h (as > my > seekext TSR does). Perhaps you can include a fix to that? Maybe we can fix this bug together. I don't want to spoil what I have.

CandyMan 11.08.2023, 10:47 (edited by CandyMan, 13.08.2023, 23:54) @ ecm	New version DRDOS 7.01.7 & 7.01.8 Post reply
	Is what I changed enough? Should I add anything else?

ecm

Düsseldorf, Germany,
12.08.2023, 21:13

@ CandyMan

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> Is what I changed enough? Should I add anything else?

The problem is the calls to redir_dhndl_offer, on line 128 (of the 2011-07-21 WIP release) / label f7142_handle_ok as well as on line 335 / label f71a6_handle_ok.

Those branch into file redir.a86 line 125:

redir_dhndl_offer: ;================ ; The FDOS has called this hook to see if we are operating on an MSNET drive. ; We return if we are not, or stay and process function here if we are test es:byte ptr DHNDL_WATTR+1[bx],DHAT_REMOTE/100h jnz redir_dhndl_accept ret redir_dhndl_accept:

This eventually branches to line 263 / label redir_accept:

redir_accept: ;============ ; We have decided to accept an FDOS function. ; Note by this time the functions have been validated as legal mov file_attrib,16h ; default search attribs to all pop si ; discard the near return address mov si,2[bp] ; SI -> parameter block mov si,ds:[si] ; fdos code number add si,si ; make it a word offset jmp cs:redir_tbl-(39h*WORD)[si] ; call the relevant function

It appears that the "fdos code number" is uninitialised (0). Perhaps the pointer expected in word [bp + 2] is uninitialised, too, it also reads as zero here when entered from the 7142h code.

This causes the table dispatch to jump to line 1537 of file funcs.fdo, below label fdos_select. For me, this happens to load a zero into AX and to then branch to fdos_select30, which is a retn instruction. This returns to pcmif.a86 line 292, after the label int21_e60. As AL is zero, this sets the application's AL to zero too.

The proper initialisation of the parameter block and FDOS code number appears to happen in fdos_entry, line 41 in file funcs.fdo. For example, disk.a86 line 676 label func40 calls the fdos_handle function, at line 723 in the same file, which chains to fdos_crit line 121 in file support.a86, which calls fdos_nocrit line 177 same file, which finally calls fdos_entry. Finally, the function 40h dispatches to file funcs.fdo function fdos_write (line 829), which calls vfy_dhndl_ptr and then redir_dhndl_offer.

The FD_FUNC field of fdos_data is populated by function set_retry, then fdos_nocrit passes the offset of fdos_data to fdos_entry which finally uses this code to read the parameter block and store some of it on the stack:

;========== fdos_entry: ; FDOS module entry point ;========== ; On Entry: ; DS:DX -> parameter block ; On exit: ; AX = BX = return code ; (DS/ES corrupted) ; entry: DS:DX = argument ; ; exit: AX,BX = return code mov si,dx lodsw ; AX = FDOS number sub ax,39h ; base it at zero jc fd_error ; stop if too low cmp ax,FDOS_MAX ; check if function in range jae fd_error ; yes, continue push ds ; save parameter segment push dx ; save parameter offset push ax ; save sub-function mov bp,sp ; SS:BP -> working variables mov bx,ax add bx,ax add bx,ax call fdos_tbl[bx]

The redir_dhndl_offer function reads word [bp + 2] which is the DX pushed by fdos_entry.

All this to say that redir_dhndl_offer should not be called from lfn.asm at any point, because it does not set up the FDOS stack frame and data structures. Both calls of this should go away.

However, you do not need most of the code that you copied from seekext. The call to vfy_dhndl_ptr_AX_call already sets up ES:BX -> the SFT entry. You can copy this line from the redir_dhndl_offer function to check for redirector SFTs:

test es:byte ptr DHNDL_WATTR+1[bx],DHAT_REMOTE/100h

Then branch to a part that sets DI to the passed BX value, and call the int 2Fh functions 11C2h and 1142h as you do already. I'm not quite sure how to pass errors back to the interrupt 21h dispatcher but you seem to have the correct code already in your attempt:

_iret_CF: jc f71_error jmp return_AX_CLC

(Just the label name is not accurate here, because this is not an IRET handler as such.)

The use of redir_dhndl_offer in f71a6_handle_ok is equally wrong. dosemu2 also has an extension function for this, at int 2Fh function 11A6h.

Additionally, the two checks for DHAT_DEV also seem wrong. They appear to return to the interrupt 21h dispatcher without properly setting up error codes, and neither do they fill in either of the passed buffers. (For comparison, in file funcs.fdo the label lseek_dev at line 1051 makes sure to return a new seek position of 0000_0000h for device handles, so presumably function 7142h should also zero the output buffer when called on a device.)

---
l

CandyMan 13.08.2023, 11:16 @ ecm	EDR-DOS bugs on int 21h functions 7142h and 71A6h Post reply
	I don't think I can make these changes alone. I'm not that familiar with the DOS kernel.

ecm

Düsseldorf, Germany,
13.08.2023, 13:59

@ CandyMan

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> I don't think I can make these changes alone. I'm not that familiar with
> the DOS kernel.

I can prepare a patch later.

I tested MSWindows 95 (on pcjs) and a device handle works a little differently than on EDR-DOS:

* Function 42h allows to seek anywhere, as if the device is a file of length zero.

* Function 71A6h returns with CY set (even if input was NC, that is not "CF unchanged"), AX=7100h.

---
l

ecm

Düsseldorf, Germany,
13.08.2023, 14:39

@ ecm

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> > I don't think I can make these changes alone. I'm not that familiar with
> > the DOS kernel.
>
> I can prepare a patch later.
>
> I tested MSWindows 95 (on pcjs) and a device handle works a little
> differently than on EDR-DOS:
>
> * Function 42h allows to seek anywhere, as if the device is a file of
> length zero.
>
> * Function 71A6h returns with CY set (even if input was NC, that is not "CF
> unchanged"), AX=7100h.

Running function 71A6h on a file on a redirector file system (Phantom 3.0) MSW 95 also appears to return CY, AX=7100h.

---
l

CandyMan 13.08.2023, 19:23 @ ecm	EDR-DOS bugs on int 21h functions 7142h and 71A6h Post reply
	> > I can prepare a patch later. > Thanks for your commitment and help. PS: I noticed that you are also working on the RxDOS kernel. Is it stable?

ecm

Düsseldorf, Germany,
13.08.2023, 21:41

@ CandyMan

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> >
> > I can prepare a patch later.
> >
>
> Thanks for your commitment and help.

I took the opportunity to create an EDR-DOS repo on our server, at https://hg.pushbx.org/ecm/edrdos (I interpret the new CP/M and derivatives license agreement as of 2022-07-07 as including EDR-DOS, so it should be fine to host it. This license agreement is in the file license.htm in the repo's root directory.)

I added one patch to COMMAND that was needed to build with OpenWatcom 1.9 (from a DOS host system, running in dosemu2) fixing a bug.

I fixed the redirector support for functions 7142h and 71A6h, both to support the dosemu2 extensions and to never crash on a redirector handle. (If the extensions are not supported, 7142h returns an error code of CY, ax=0001h and 71A6h an error code of CY, ax=7100h (like MSWindows).)

Further, I modified both the old-style function 42h and 7142h to work on device handles in the same way as MSWindows, allowing to seek as if the device was an empty file. I also changed it so function 71A6h returns CY, ax=7100h on a device handle.

> PS: I noticed that you are also working on the RxDOS kernel. Is it stable?

No, far from it. And I'm not technically working on it currently. Haven't in a long time. You can view the current state in the repo: https://hg.pushbx.org/ecm/rxdos-7.2x/

I prefer contributing to the FreeDOS kernel now. I also use it for most of my developments (primarily the lDebug debugger).

---
l

CandyMan

13.08.2023, 22:41

@ ecm

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

Thanks for making these changes. My most important fix is the one below (last two lines posted - in "disk.asm"). Without it, the system freezes on my computer with grub4dos.

push cx push si pushx <es,di,dx> mov ah,ROS_LBAPARAM ; get extended drive parameters lea si,int13ex_para ; DS:SI -> drive parameter buffer int_____DISK_INT popx <dx,di,es> jc equip_type_nolba ; error, assume standard FDD test word ptr 2[si],4 ; removable drive? jnz equip_type_nolba ; no cmp dl,80h ; Hard Disk? - CandyMan jb equip_type_nolba ; no - CandyMan

ecm

Düsseldorf, Germany,
13.08.2023, 23:18

@ CandyMan

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> Thanks for making these changes. My most important fix is the one below
> (last two lines posted - in "disk.asm"). Without it, the system freezes on
> my computer with grub4dos.

If you allow it, I want to add your changes to my repo. I already downloaded the source archive you uploaded earlier:

> Here is the source code:
>
> https://megawrzuta.pl/download/cbef417c0f85eeaed244828d5915c6e5.html

Other than what you quoted here I am also interested in the other changes you mentioned:

> Files with the "org" extension are uncompressed, while the others are.
>
> Here are some changes:
>
> Does not scan LBA drives when dx<80h,
> For unsupported functions, 71xx returns ax=7100h again,
> Handling interrupts 0x00 and 0x06 (division by zero and invalid opcode) as in FreeDos.

and

> Not exactly, but I used the aPACK and UPX programs for the BIOS and DOS parts respectively and some tricks.

and

> Here is another improved version of EDR-DOS. Now the interrupt vectors saved at startup are again at the fixed address 0070h:0100h.

and

> Today I added the INT21.AX33FF.DX0000 function as in RxDOS and FreeeDOS.
>
> I also removed exception handling 0x6 due to some BIOSes using invalid CPU instructions prefixed with 0xF0 (LOCK) generating this exception.

Did you actually not use the EDR-DOS packer to compress your kernel files? https://pushbx.org/ecm/download/edrdos/pack100.zip and https://pushbx.org/ecm/download/edrdos/pack101.zip

---
l

CandyMan

13.08.2023, 23:51

@ ecm

EDR-DOS bugs on int 21h functions 7142h and 71A6h

Post reply

> Did you actually not use the EDR-DOS packer to compress your kernel files?

I used aPACK, UPX and FASM for compression.

My actual code:
https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos extender only directories are visible (no files).

ecm

Düsseldorf, Germany,
14.08.2023, 07:18

@ CandyMan

EDR-DOS development

Post reply

> > Did you actually not use the EDR-DOS packer to compress your kernel
> files?
>
> I used aPACK, UPX and FASM for compression.
>
> My actual code:
> https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

Thanks, I will look into this later.

> By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem
> to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> extender only directories are visible (no files).

Can you upload the exact files you're using? If I can reproduce this bug I may be able to fix it.

---
l

CandyMan

14.08.2023, 09:43

@ ecm

EDR-DOS development

Post reply

> > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't
> seem
> > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> > extender only directories are visible (no files).
>
> Can you upload the exact files you're using? If I can reproduce this bug I
> may be able to fix it.

Also, the 7Z archiver started with the *.* mask only sees directories.
I don't know if it's the fault of DOS or the dos extender.

Below are the programs I use:
https://megawrzuta.pl/download/400807cf0f611833d8248747468acd74.html

ecm

Düsseldorf, Germany,
15.08.2023, 20:49

@ CandyMan

EDR-DOS development

Post reply

> > > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't
> > seem
> > > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> > > extender only directories are visible (no files).
> >
> > Can you upload the exact files you're using? If I can reproduce this bug
> I
> > may be able to fix it.
>
> Also, the 7Z archiver started with the *.* mask only sees directories.
> I don't know if it's the fault of DOS or the dos extender.
>
> Below are the programs I use:
> https://megawrzuta.pl/download/400807cf0f611833d8248747468acd74.html

Can you list the exact commands or actions that I can do to reproduce the errors, please?

---
l

ecm

Düsseldorf, Germany,
15.08.2023, 20:51

@ ecm

EDR-DOS development

Post reply

> Can you list the exact commands or actions that I can do to reproduce the
> errors, please?

Also, I haven't used it in a long time so I'm unsure what setup (if any) the HX extender needs in order to run MSWindows programs.

---
l

ecm

Düsseldorf, Germany,
19.08.2023, 19:56

@ CandyMan

EDR-DOS development

Post reply

> Also, the 7Z archiver started with the *.* mask only sees directories.
> I don't know if it's the fault of DOS or the dos extender.

I believe that the source of this problem, or a part of it, may be that EDR-DOS's functions 714Eh, 714Fh, and 71A1h do not really allow concurrent searches. It may require some amount of work to fix this.

What happens now is 7-Zip finds a directory, recurses into it, and tries to start a new search. After finishing processing the directory, it closes the Find handle and tries to continue the search of the original working directory. This is corrupted from the recursive search.

Another part is with 7z a ..\t.7z *.* nothing is found, but I believe this is intentional on the part of 7-Zip. (All files and directories in my test directory do not contain dots in their names.) It does mean that you may have mistakenly specified the *.* mask when it should be *. (The DOS functions are documented as finding everything with either, but 7-Zip also applies its own pattern matching.)

---
l

CandyMan

14.08.2023, 14:35

@ ecm

EDR-DOS development

Post reply

What do you think about adding to EDR-DOS and maybe to FreeDOS an extended Exec() function with variants with for example bit 6 of the AL register set (Int21.AX=4B40, Int21.AX=4B41 etc.) to run the program with the line command longer than 127 bytes? The long command line would be copied into the program environment and would be available under the name CMDLINE as the 4DOS interpreter does. It annoys me that it's so short.

bretjohn

Rio Rancho, NM,
14.08.2023, 21:12

@ CandyMan

EDR-DOS development

Post reply

> What do you think about adding to EDR-DOS and maybe to FreeDOS an extended
> Exec() function with variants with for example bit 6 of the AL register set
> (Int21.AX=4B40, Int21.AX=4B41 etc.) to run the program with the line
> command longer than 127 bytes? The long command line would be copied into
> the program environment and would be available under the name CMDLINE as
> the 4DOS interpreter does. It annoys me that it's so short.

It's unnecessary to add new DOS function(s) for this -- there's already a "standard" way to do it. Check the byte value at PSP:80h (the number of characters in the command-line string) and if it's at least 7Eh then look for a CMDLINE environment variable. If the CMDLINE variable doesn't exist then 7Eh is the actual size of the command-line string.

Just as a cautionary note, you shouldn't just automatically look for a CMDLINE environment variable since the user can set that environment variable called CMDLINE to anything they want that has nothing to do with the command-line. You should only use it if the value at PSP:80h is >= 7Eh.

BTW this also works in at least some versions of the Windows command-line shell.

CandyMan 15.08.2023, 11:49 @ bretjohn	EDR-DOS development Post reply
	Thanks for the exhaustive explanation. Who asks not stray.

ecm

Düsseldorf, Germany,
15.08.2023, 20:46

@ CandyMan

EDR-DOS development

Post reply

> > Did you actually not use the EDR-DOS packer to compress your kernel
> files?
>
> I used aPACK, UPX and FASM for compression.

Do you want to share scripts or descriptions for this too? Your latest sources only seem to add the load-fix.inc file as a part that seems related to compression.

> My actual code:
> https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

I have some questions:

Why do you want to clear only 12h bytes at 0:500h rather than 20h bytes?

Can you describe the failure without your disk.asm change not to do something with diskette units?

Why did you change the colour offset? It seems like 24, 25, 26 points after the CON device header and its "COLOUR" signature while you subtract 6. So it actually uses the signature as data.

I don't think unsupported subfunctions of a partially supported int 21h service 71h function should return 7100h.

Both FreeDOS and RxDOS do not check for DX being zero for function 33FFh. I did call it like that in callver as well as in comcom32 but that is just to harden the check on whether it is supported.

Finally, what name (if any) do you want me to enter into the repository for changes I pick from your patches?

---
l

CandyMan

15.08.2023, 22:29

@ ecm

EDR-DOS development

Post reply

>1. Why do you want to clear only 12h bytes at 0:500h rather than 20h bytes?

>2. Can you describe the failure without your disk.asm change not to do something with diskette units?

>3. Why did you change the colour offset? It seems like 24, 25, 26 points after the CON device header and its "COLOUR" signature while you subtract 6. So it actually uses the signature as data.

>4. I don't think unsupported subfunctions of a partially supported int 21h service 71h function should return 7100h.

>5. Finally, what name (if any) do you want me to enter into the repository for changes I pick from your patches?

>6. Also, I haven't used it in a long time so I'm unsure what setup (if any) the HX extender needs in order to run MSWindows programs.

>7. Can you list the exact commands or actions that I can do to reproduce the errors, please?

1. I did it for my own use. On my boot disk, I use a different kernel loader and store interrupt vectors 13h and 15h Linux/GRUB4DOS at address 0:0512 for later transfer to UMB memory and back after Int19h. Data at this address was probably used only by GWBasic.

2. I don't remember now, it was 3 years ago. I'm using a little Linux and GRUB4DOS to run DOS because I don't have a floppy drive anymore. The disk drive is emulated and is somewhere in memory above 1MB. Without this fix, it just freezes.

3. I did it so that the DOS interrupts were stored at a fixed address 0070h:0100h

4. Some programs (7zip launched with the command to unpack the archive using HX-DOS) only understand the code 7100h. When the code 0001h is returned, they assume that the file/directory cannot be created and abort without executing short file name function (39h).

5. You can use any name (e.g. CandyMan fix).

6. HX configuration: any XMS driver and C:\HX\BIN in the PATH environment variable and running HXLDR32.EXE resident

7. Programs to reproduce the error: just run DN.EXE or 7Z a -mx Archive.7Z *.*

The way it compresses the kernel:
https://megawrzuta.pl/download/c3100b23f1dc691db9e9e9b693d256d4.html

ecm

Düsseldorf, Germany,
16.08.2023, 10:06

@ CandyMan

EDR-DOS development

Post reply

> >1. Why do you want to clear only 12h bytes at 0:500h rather than 20h
> bytes?
>
> >2. Can you describe the failure without your disk.asm change not to do
> something with diskette units?
>
> >3. Why did you change the colour offset? It seems like 24, 25, 26 points
> after the CON device header and its "COLOUR" signature while you subtract
> 6. So it actually uses the signature as data.
>
> >4. I don't think unsupported subfunctions of a partially supported int 21h
> service 71h function should return 7100h.
>
> >5. Finally, what name (if any) do you want me to enter into the repository
> for changes I pick from your patches?
>
> >6. Also, I haven't used it in a long time so I'm unsure what setup (if
> any) the HX extender needs in order to run MSWindows programs.
>
> >7. Can you list the exact commands or actions that I can do to reproduce
> the errors, please?
>
> 1. I did it for my own use. On my boot disk, I use a different kernel
> loader and store interrupt vectors 13h and 15h Linux/GRUB4DOS at address
> 0:0512 for later transfer to UMB memory and back after Int19h. Data at this
> address was probably used only by GWBasic.

Okay, I can do that. I don't think this patch will do any harm.

> 2. I don't remember now, it was 3 years ago. I'm using a little Linux and
> GRUB4DOS to run DOS because I don't have a floppy drive anymore. The disk
> drive is emulated and is somewhere in memory above 1MB. Without this fix,
> it just freezes.

All right.

> 3. I did it so that the DOS interrupts were stored at a fixed address
> 0070h:0100h

Oh, I missed that you also commented out the db "COLOUR" signature itself. This is the wrong way to achieve the correct address for vecSave. In my repo I already did it the right way.

> 4. Some programs (7zip launched with the command to unpack the archive
> using HX-DOS) only understand the code 7100h. When the code 0001h is
> returned, they assume that the file/directory cannot be created and abort
> without executing short file name function (39h).

Does this apply to all uses of error code 0001h in lfn.asm or only some? At least function 7142h with cl > 2 should return error 0001h I think.

> 5. You can use any name (e.g. CandyMan fix).

Okay.

> 6. HX configuration: any XMS driver and C:\HX\BIN in the PATH environment
> variable and running HXLDR32.EXE resident
>
> 7. Programs to reproduce the error: just run DN.EXE or 7Z a -mx Archive.7Z
> *.*

Thanks. I may have time to try this later, probably within the week.

> The way it compresses the kernel:
> https://megawrzuta.pl/download/c3100b23f1dc691db9e9e9b693d256d4.html

Interesting, thanks! I do have some comments:

Can you describe fix-bio's use of virtual and load dword / store dword? I am not used to FASM specific directives. The load and store access and change data that is already assembled? file is like NASM incbin? virtual assembles into a space that is discarded afterwards, just for access with load?

The registers don't all need to be preserved by fix-bio. es, di, si, bx, and cx are probably not used by the EDR-DOS load protocol. dl, ds, bp, ss, sp may be used.

I don't like the use of the memory at 004F0h for saving the registers. It would be better to use the stack or at least 005F0h.

The fix-bio expects the compressed file to be < 64 KiB. Fair enough.

The mov word [cs:0], ax could be replaced by directly storing a 16-bit immediate to the memory, instead of going through AX. Hmm, may actually be the same length of instruction bytes.

The retf in fix-bio can be replaced by a jmp far immediate because the kernel must be loaded at 70h:0 (currently).

What are the first 8 bytes supposed to be in the upx-compressed drdos.com that are replaced by fix-dos? I think you could add load directives to check that those instructions match what you expect.

In the batch file you use "vasm". Is that a typo for "fasm"?

What versions of apack and upx do you use?

---
l

CandyMan

16.08.2023, 12:54

@ ecm

EDR-DOS development

Post reply

> Interesting, thanks! I do have some comments:
>
> Can you describe fix-bio's use of virtual and load dword / store dword? I
> am not used to FASM specific directives. The load and store access and
> change data that is already assembled? file is like NASM incbin? virtual
> assembles into a space that is discarded afterwards, just for access with
> load?
>
> The registers don't all need to be preserved by fix-bio. es, di, si, bx,
> and cx are probably not used by the EDR-DOS load protocol. dl, ds, bp, ss,
> sp may be used.
>
> I don't like the use of the memory at 004F0h for saving the registers. It
> would be better to use the stack or at least 005F0h.
>
> The fix-bio expects the compressed file to be < 64 KiB. Fair enough.
>
> The mov word [cs:0], ax could be replaced by directly storing
> a 16-bit immediate to the memory, instead of going through AX. Hmm, may
> actually be the same length of instruction bytes.
>
> The retf in fix-bio can be replaced by a jmp far immediate because the
> kernel must be loaded at 70h:0 (currently).
>
> What are the first 8 bytes supposed to be in the upx-compressed drdos.com
> that are replaced by fix-dos? I think you could add load directives to
> check that those instructions match what you expect.
>
> In the batch file you use "vasm". Is that a typo for "fasm"?
>
> What versions of apack and upx do you use?

In fix-bio.asm I add a small procedure at the end of dosbio.sys.
In the virtual block, I set a new jump instruction for this procedure and then copy the previous compressed jump instruction to drbio.sys (4 bytes) to be able to recreate it and run the unpacking procedure to the address CS-10h:IP+100h
The "file" directive works exactly like the "incbin" in nasm, but you can also specify the start and size of the loaded file block.

The memory at address 4F0h (16-bytes) is for the user and I took advantage of that.

The first 8 bytes of compressed drdos.com should be:
CMP SP,constant JA Above INT 20h Above:

"vasm" is my replacement for "fasm" run by the D3X dos extender.

I use aPACK v1.0 and UPX v3.96.

ecm

Düsseldorf, Germany,
16.08.2023, 18:19

@ CandyMan

EDR-DOS development

Post reply

You didn't reply about the int 71h function error codes. Apart from the compression support and the colour signature removal, this is the only patch of yours I didn't add to my repo yet.

> In fix-bio.asm I add a small procedure at the end of dosbio.sys.
> In the virtual block, I set a new jump instruction for this procedure and
> then copy the previous compressed jump instruction to drbio.sys (4 bytes)
> to be able to recreate it and run the unpacking procedure to the address
> CS-10h:IP+100h

Yes, I do think 3 bytes would suffice though. A near jump instruction is 3 bytes.

> The "file" directive works exactly like the "incbin" in nasm, but you can
> also specify the start and size of the loaded file block.

Actually, NASM's incbin does have that too: https://www.nasm.us/xdoc/2.16.01/html/nasmdoc3.html#section-3.2.3 It might be a little known feature however, as I didn't know about it when I originally wrote my bootimg FATFS format script.

Unlike this, NASM really does not have fasm's load and store directives. Those are more powerful, even though 3 of your fix files' uses of them can be replaced by using incbin with various parameters. (The replacement of the last byte of the compressed drdos.com by a pop ax can only be done with incbin by knowing the size of the file beforehand. NASM has no way of detecting the size without including the file data up to and including the last byte.)

Writing of which, how does the far address of the DOS kernel file end up on the stack so that by modifying the last byte of the compressed drdos.com to a pop ax and retf you have it branch where you want?

Oh, I just noticed that your DOS compression is exactly copied from pack101. Except that shipped with upx 1.25d. I was about to write, I would implement this with an lDebug script. (The pack100/pack101 debug scripts do work with lDebug, though I assume they were written for DR-DOS Debug.)

I found out how the address gets on the stack: https://hg.pushbx.org/ecm/edrdos/rev/c2e9bc4c642b#l27.50

> The memory at address 4F0h (16-bytes) is for the user and I took advantage
> of that.

Oh, yes, you're correct. The interrupt list calls it "intra-application communication area": http://fd.lod.bz/rbil/memory/other/m004000f0.html
I didn't know that and assumed it may be used by the ROM-BIOS.

> The first 8 bytes of compressed drdos.com should be:
> > CMP SP,constant > JA Above > INT 20h > Above:
>
> "vasm" is my replacement for "fasm" run by the D3X dos extender.

Is there a need for that here? Why did you use one once and the other once, rather than twice the same?

> I use aPACK v1.0 and UPX v3.96.

Thanks!

---
l

CandyMan

16.08.2023, 18:55
(edited by CandyMan, 16.08.2023, 19:10)

@ ecm

EDR-DOS development

Post reply

> You didn't reply about the int 71h function error codes. Apart from the
> compression support and the colour signature removal, this is the only
> patch of yours I didn't add to my repo yet.
>
I didn't answer because I'm not entirely sure. Perhaps it is enough for HX-DOS to understand the return code 0001h as it understands 7100h.

> Is there a need for that here? Why did you use one once and the other once,
> rather than twice the same?
>

I just forgot to change. When I run under Win64 I can't use "vasm", and when I don't have HX loaded in DOS I can't use "fasm".

I now know, though not exactly, why the system freezes. After loading DRDOS.SYS (also uncompressed) it jumps to the wrong place for me and after the RET instruction to the next one. However, I don't know exactly how to fix it. The only correct solution was the amendment I proposed. I used Dark Debugger to trace the boot process.

ecm

Düsseldorf, Germany,
20.08.2023, 01:35

@ CandyMan

EDR-DOS development

Post reply

>
> By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem
> to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> extender only directories are visible (no files).

I was confused by your wording here, you wrote "after running DN2" but I think you meant *when* running DN2 then in the application only directories are visible.

If I am correct in that then I fixed that bug. It also affected 7-Zip which wants to get all files for a * pattern, but EDR-DOS's 714Eh/714Fh exposed the DOSism that *.* is required to get all files and * only finds files without a dot in their name. 7-Zip, however, does globbing itself to postprocess the DOS found files and it interprets *.* as meaning "only files with a dot in their name", unlike DOS.

> Also, the 7Z archiver started with the *.* mask only sees
> directories. I don't know if it's the fault of DOS or the
> dos extender.

Please test with my build that will be updated later today (in 22h from now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip

---
l

CandyMan

21.08.2023, 00:27

@ ecm

EDR-DOS development

Post reply

> Please test with my build that will be updated later today (in 22h from
> now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip

I just tested your latest version. Everything seems to work perfectly. Thanks a lot.

I have one question like this. Why have I never been able to build an EDR-DOS kernel by running BAT files on a system other than FreeDos? RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS and are only in FreeDos. Do the FCB functions work in EDR-DOS? I ask because when I try to build an EDR-DOS kernel in a system other than FreeDos (also in EDR-DOS itself) I get the message: "Sector not found reading drive ?:" - ? - drive number here (C drive when building on C, and drive Y when building on RAMDISK Y).

ecm

Düsseldorf, Germany,
21.08.2023, 22:54

@ CandyMan

EDR-DOS development

Post reply

> > Please test with my build that will be updated later today (in 22h from
> > now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip
>
> I just tested your latest version. Everything seems to work perfectly.
> Thanks a lot.

Good to hear.

> I have one question like this. Why have I never been able to build an
> EDR-DOS kernel by running BAT files on a system other than FreeDos?
> RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS
> and are only in FreeDos.

According to my understanding, MS-DOS 7.10+ disables FCB I/O on FAT32 FS. I did not test that yet but the interrupt list hints at this. Perhaps it would work better on a FAT12 or FAT16 FS?

> Do the FCB functions work in EDR-DOS? I ask
> because when I try to build an EDR-DOS kernel in a system other than
> FreeDos (also in EDR-DOS itself) I get the message: "Sector not found
> reading drive ?:" - ? - drive number here (C drive when building on C, and
> drive Y when building on RAMDISK Y).

I did not test this yet. I may get around to it within the week, though I would first test it in dosemu2 (MFS-redirected DOS drives). That may yield a different result than operating on a (to DOS) local FAT FS.

I found three FreeDOS bugs in the FCB directory search support while considering your post, though: https://github.com/FDOS/kernel/issues/112

---
l

ecm

Düsseldorf, Germany,
29.08.2023, 17:49

@ CandyMan

EDR-DOS development

Post reply

> I have one question like this. Why have I never been able to build an
> EDR-DOS kernel by running BAT files on a system other than FreeDos?
> RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS
> and are only in FreeDos. Do the FCB functions work in EDR-DOS? I ask
> because when I try to build an EDR-DOS kernel in a system other than
> FreeDos (also in EDR-DOS itself) I get the message: "Sector not found
> reading drive ?:" - ? - drive number here (C drive when building on C, and
> drive Y when building on RAMDISK Y).

I just updated my EDR-DOS repo on the local machine (running a recent dosemu2 with KVM, on a Debian amd64 desktop system) and booted my EDR-DOS + dosemu2 diskette image. Using the mak.bat file wouldn't work because of the required SET /E switch (FreeCOM specific), but instructing dosemu2 with the explicit lredir -f i: ... command, then setting the OpenWatcom variables (from C:\WATCOM) then running the make.bat in each directory, I get the exact same result files as on FreeDOS.

Actually, I noticed that to non-interactively overwrite a file using COPY, FreeCOM requires the COPY switch /Y, while EDR-DOS command defaults to overwriting. I added a /Y switch to EDR-DOS, which is a no-op by default. (It does override /C if both are used.) This makes my modified make.bat files fully work on both shells.

---
l

ecm

Düsseldorf, Germany,
29.08.2023, 18:26

@ ecm

EDR-DOS development

Post reply

> I just updated my EDR-DOS repo on the local machine (running a recent
> dosemu2 with KVM, on a Debian amd64 desktop system) and booted my EDR-DOS +
> dosemu2 diskette image. Using the mak.bat file wouldn't work
> because of the required SET /E switch (FreeCOM specific), but instructing
> dosemu2 with the explicit lredir -f i: ... command, then
> setting the OpenWatcom variables (from C:\WATCOM) then running the
> make.bat in each directory, I get the exact same result files
> as on FreeDOS.

I also built a HDD image like so: (This is a small FAT32 image, which is why a recent mtools is required. I downloaded it from GNU and built using ./configure then make commands. I did this to test that EDR-DOS works with a small FAT32 image.)

~/proj/edrdos$ hg clone repo selbau updating to branch default 168 files updated, 0 files merged, 0 files removed, 0 files unresolved ~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=0 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=128 -D_SPC=16 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::empty ../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (16384 entries (128 sectors), 15985 needed (125 sectors)) [-w+user] ../bootimg/bootimg.asm:523: warning: FAT would be detected as FAT16 (15983 = 3E6Fh clusters) [-w+user] ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s selbau/* ::

Then run dosemu2 with the HDD image configuration: -I "disk { hdimage /home/ecm/proj/edrdos/selbau.img }". Again set the OpenWatcom 1.9 variables for C:\WATCOM, then run each make.bat. (I think it will use the FreeDOS subst.exe that I have in C:\bin.)

After building, copy the files back to the host like so:

~/proj/edrdos$ mkdir selbau.res ~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s ::drbio/bin/drbio.sys ::drdos/bin/drdos.sys ::command/bin/command.com selbau.res/

Finally, compare the files using bdiff like so:

~/proj/edrdos/dl$ for file in drbio/bin/drbio.sys drdos/bin/drdos.sys command/bin/command.com; do ls -l "../selbau.res/${file##*/}"; bdiff "../selbau.res/${file##*/}" "../repo/$file"; done -rw-r--r-- 1 ecm ecm 35495 Aug 29 18:22 ../selbau.res/drbio.sys File: ../selbau.res/drbio.sys Files are identical. -rw-r--r-- 1 ecm ecm 36973 Aug 29 18:22 ../selbau.res/drdos.sys File: ../selbau.res/drdos.sys Files are identical. -rw-r--r-- 1 ecm ecm 63521 Aug 29 18:22 ../selbau.res/command.com File: ../selbau.res/command.com Files are identical.

---
l

ecm

Düsseldorf, Germany,
29.08.2023, 18:32

@ ecm

EDR-DOS development

Post reply

Did the same test using a normal (non-small) FAT32 file system, filling it initially with a 120 MB file to avoid the source files ending up with low cluster numbers:

~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=1 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=2560 -D_SPC=1 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::fill,120_000_000,0,zeroes.bin ../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (327680 entries (2560 sectors), 250866 needed (1960 sectors)) [-w+user]

---
l

ecm

Düsseldorf, Germany,
29.08.2023, 18:49

@ ecm

EDR-DOS development

Post reply

And another test:

~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=1 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=2560 -D_SPC=1 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::fill,120_000_000,0,zeroes.bin,::chdir,build ../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (327680 entries (2560 sectors), 250866 needed (1960 sectors)) [-w+user] ~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s selbau/* ::build ~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s ::build/drbio/bin/drbio.sys ::build/drdos/bin/drdos.sys ::build/command/bin/command.com selbau.res/

This puts the directory entries for the drbio, drdos, and command subdirectories into a directory cluster beyond the first 64 Kilo-binary clusters, too.

---
l

Rugxulo

Usono,
29.08.2023, 23:28

@ ecm

EDR-DOS development

Post reply

> Actually, I noticed that to non-interactively overwrite a file using COPY,
> FreeCOM requires the COPY switch /Y, while EDR-DOS command defaults to
> overwriting. I added
> a /Y switch to EDR-DOS, which is a no-op by default. (It does
> override /C if both are used.) This makes my modified make.bat
> files fully work on both shells.

%COPYCMD% was introduced in, what, MS-DOS 5? In .BAT files, COPY defaults to /Y, otherwise if interactive it asks you before overwriting.

ecm

Düsseldorf, Germany,
30.08.2023, 09:47

@ Rugxulo

EDR-DOS development

Post reply

> > Actually, I noticed that to non-interactively overwrite a file using
> COPY,
> > FreeCOM requires the COPY switch /Y, while EDR-DOS command defaults to
> > overwriting. I
> added
> > a /Y switch to EDR-DOS, which is a no-op by default. (It does
> > override /C if both are used.) This makes my modified
> make.bat
> > files fully work on both shells.
>
> %COPYCMD% was
> introduced in, what, MS-DOS 5? In .BAT files, COPY defaults to /Y,
> otherwise if interactive it asks you before overwriting.

Oh, right, FreeCOM does default to overwrite without asking in a batch file. I hadn't considered that it may differ.

---
l

roytam

29.12.2023, 15:33

@ ecm

EDR-DOS development

Post reply

> >
> > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't
> seem
> > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> > extender only directories are visible (no files).
>
> I was confused by your wording here, you wrote "after running DN2"
> but I think you meant *when* running DN2 then in the application only
> directories are visible.
>
> If I am correct in that then I fixed that bug. It also affected 7-Zip which
> wants to get all files for a * pattern, but EDR-DOS's
> 714Eh/714Fh exposed the DOSism that *.* is required to get all
> files and * only finds files without a dot in their name.
> 7-Zip, however, does globbing itself to postprocess the DOS found files and
> it interprets *.* as meaning "only files with a dot in their
> name", unlike DOS.
>
> > Also, the 7Z archiver started with the *.* mask only sees
> > directories. I don't know if it's the fault of DOS or the
> > dos extender.
>
> Please test with my build that will be updated later today (in 22h from
> now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip

it anything changed in DR-COMMAND.COM?
Udo's COMMAND.COM can display short filenames in NTVDM(otvdm/msdos.exe) after patching DR-check
but yours shows no file when running `dir/w`

Ro2003

10.10.2023, 16:24

@ ecm

EDR-DOS repository

Post reply

> I took the opportunity to create an EDR-DOS repo on our server, at
> https://hg.pushbx.org/ecm/edrdos (I interpret the new CP/M and derivatives
> license agreement as of 2022-07-07 as including EDR-DOS, so it should be
> fine to host it. This license agreement is in the file license.htm in the
> repo's root directory.)
>
> > PS: I noticed that you are also working on the RxDOS kernel. Is it
> stable?
>
> No, far from it. And I'm not technically working on it currently. Haven't
> in a long time. You can view the current state in the repo:
> https://hg.pushbx.org/ecm/rxdos-7.2x/

I'm happy to see this updated EDR-DOS 7.01.08 WIP! EDR-DOS repository also got a Github mirror.

Now that the license is opened - it would be great if the EDR-DOS branch gets reunited with DR-DOS 7.07.

Matthias Paul once wrote:

> I still have not completely lost hope, that at some fine day in the future the current owner of the DR-DOS assets may decide that its commercial life is finally over and that it is due to open source the system. This would make it possible to reunificate the different code branches to create the most advanced DR-DOS ever for all its fans. Well, well... ;-)

So, if he gets contacted (e.g. via his Wikipedia talk page?) in these improved license circumstances, maybe he can help with:

- DR-DOS 7.07 (Kernel and drive tools?) - binary/source?
- WinGlue/WinBolt (ability to run Win9x) - in case that's not possible in DR-DOS 7.06 and 7.07.
-- binary/source?
-- is combined BIOS+BDOS file mandatory? Or separate files IBMBIO.COM, IBMDOS.COM, MSDOS.SYS (settings text file), IO.SYS (if such kind of placeholder/redirect is needed) can exist at the same time?
-- can DR-DOS 7.07 boot from Win9x/Me boot sectors? Does DR-DOS 7.07 include all functionality from DR-DOS 7.06?
-- boot logo, etc. Win9x settings in MSDOS.SYS/WINBOOT.INI - any issues with those?
- optionally loadable multi-user security extension - (World/Group/Owner) access permission system - DR DOS "Panther" BETA 1 - birnary/source for that?
- DR-DOS 7.03 source (Kernel or full software package)?

Did you ask Bryan Sparks (the DRDOS owner) if he can help with any of these?

Also, what about:
- DR-DOS 8.0/8.1 - are there any Kernel/IBMBIO/IBMDOS/COMMAND.COM changes in comparison with 7.01.06 and 7.03? FAT32 DELWATCH and SHARE, but those are external files?
- RxDOS - are there any changes not yet implemented in the EDR branch?
- What about functionalities from lDOS not yet implemented in the EDR branch? What is lDOS, actually?

ecm

Düsseldorf, Germany,
12.10.2023, 19:04

@ Ro2003

EDR-DOS repository

Post reply

> > I took the opportunity to create an EDR-DOS repo on our server, at
> > https://hg.pushbx.org/ecm/edrdos (I interpret the new CP/M and
> derivatives
> > license agreement as of 2022-07-07 as including EDR-DOS, so it should be
> > fine to host it. This license agreement is in the file license.htm in
> the
> > repo's root directory.)
> >
> > > PS: I noticed that you are also working on the RxDOS kernel. Is it
> > stable?
> >
> > No, far from it. And I'm not technically working on it currently.
> Haven't
> > in a long time. You can view the current state in the repo:
> > https://hg.pushbx.org/ecm/rxdos-7.2x/
>
> I'm happy to see this updated EDR-DOS 7.01.08 WIP! EDR-DOS repository also
> got a Github mirror.
>
> Now that the
> license is
> opened - it
> would be great if the EDR-DOS branch gets reunited with
> DR-DOS 7.07.

This would require, at least, either descriptions of what changed, or actual files of that version. Preferably both. Neither seems to be provided in that thread.

> Matthias Paul
> once
> wrote:
>
> > I still have not completely lost hope, that at some fine day in the
> future the current owner of the DR-DOS assets may decide that its
> commercial life is finally over and that it is due to open source the
> system. This would make it possible to reunificate the different code
> branches to create the most advanced DR-DOS ever for all its fans. Well,
> well... ;-)
>
> So, if he gets contacted (e.g. via
> his
> Wikipedia talk page?) in these improved license circumstances, maybe
> he can help with:
>
> - DR-DOS 7.07 (Kernel and drive tools?) - binary/source?
> -
> WinGlue/WinBolt
> (ability to run Win9x) - in case that's not possible in DR-DOS 7.06 and
> 7.07.
> -- binary/source?

Never seen any of either.

> -- is combined BIOS+BDOS file mandatory? Or separate files IBMBIO.COM,
> IBMDOS.COM, MSDOS.SYS (settings text file), IO.SYS (if such kind of
> placeholder/redirect is needed) can exist at the same time?

I don't think it is required to combine the file. It is good for other reasons though.

> -- can DR-DOS 7.07 boot from Win9x/Me boot sectors? Does DR-DOS 7.07
> include all functionality from DR-DOS 7.06?
> -- boot logo, etc. Win9x settings in
> MSDOS.SYS/WINBOOT.INI - any issues with those?
> - optionally loadable multi-user security extension - (World/Group/Owner)
> access permission system - DR DOS "Panther" BETA 1 - birnary/source for
> that?

Never seen.

> - DR-DOS 7.03 source (Kernel or full software package)?

Also never seen.

> Did you ask Bryan Sparks (the DRDOS owner) if he can help with any of
> these?

No, I did not yet.

> Also, what about:
> - DR-DOS 8.0/8.1 - are there any Kernel/IBMBIO/IBMDOS/COMMAND.COM changes
> in comparison with 7.01.06 and 7.03? FAT32 DELWATCH and SHARE, but those
> are external files?
> - RxDOS - are there any changes not yet implemented in the EDR branch?

RxDOS isn't a "branch" of anything. It is not based on any other existing 86-DOS version. So this is very confusing.

> - What about functionalities from lDOS not yet implemented in the EDR
> branch? What is lDOS, actually?

lDOS is my name for a DOS that would be completely developed by me. Some components of it are actually implemented:

Most notably the ldosboot boot12/boot16/boot32 (with FSIBOOT) boot sector loaders and the multi-protocol iniload which is the initial stage of a kernel that can be loaded as MS-DOS v6 kernel, MS-DOS v7 kernel, IBM-DOS kernel, FreeDOS kernel, Multiboot1 or Multiboot2 specification kernel, or lDOS kernel. This is used for recent RxDOS revisions and more importantly (and usefully) for bootable lDebug. There is also some additional stages like fdkernpl (load wrapped FreeDOS-style kernel) and inicomp (compressed payload, depack during triple-mode execution) that can be added to iniload.

Another component is ldosmbr, which provides two different MBR loaders both based on original sources from syslinux but improved.

Finally there is the ldos repo which provides a few partial bits and bobs. This has some sectioning stuff, some relocations of DOSDATA (UMA/LMA) and DOSCODE (HMA/UMA/LMA), entrypoints using the relocated sections, and a replacement memory allocation (LMCB/UMCB) subsystem. This repo is integrated into the most recent revision of RxDOS. During development I called the combined kernel lRxDOS, but it's back to just RxDOS (in the file RXDOS.COM) more recently.

RxDOS is very immature in any case. The only things it definitely does better than EDR-DOS is the ldosboot stages and single-file kernel loading. To implement single-file loading requires some knowledge of the DOS memory maps at various points in the load process. (I don't have this knowledge for (E)DR-DOS.) The other advantage is it builds with NASM, rather than a hodgepodge of JWasm (open source but not free software), WarpLink (public domain with NASM sources but runs in DOS), and free-but-no-sources software RASM and linker.

---
l

Ro2003

13.10.2023, 08:23

@ ecm

EDR-DOS repository

Post reply

> I don't think it is required to combine the file. It is good for other reasons though.

What are the other reasons?

I think it's worth to reach out to Matthias Paul and Bryan Sparks (and other former team members, if you know any) to ask for DR-DOS binaries or sources.
Especially since Matthias himself was mentioning that it'll be good to merge EDR-DOS 7.01.xx and DR-DOS 7.07.
Maybe they can help also with the DOS memory maps in the load process.

nico7550

13.10.2023, 15:53

@ Ro2003

EDR-DOS repository

Post reply

> > I don't think it is required to combine the file. It is good for other
> reasons though.
>
> What are the other reasons?
>
>
> I think it's worth to reach out to Matthias Paul and Bryan Sparks (and
> other former team members, if you know any) to ask for DR-DOS binaries or
> sources.
> Especially since Matthias himself was mentioning that it'll be good to
> merge EDR-DOS 7.01.xx and DR-DOS 7.07.
> Maybe they can help also with the DOS memory maps in the load process.

I try myself to reach Paul but without success, I hope you will have more luck.

And same for CandyMan

ecm

Düsseldorf, Germany,
13.10.2023, 18:16

@ Ro2003

EDR-DOS repository - Single-file kernel load

Post reply

> > I don't think it is required to combine the file. It is good for other
> reasons though.
>
> What are the other reasons?

Several:

* BIO and DOS file can get out of sync, potentially resulting in failures to boot or even data corruption.
* One more file to keep track of.
* Need a FAT FS read implementation in the BIO that is only ever used to read the DOS file, this is in bdosldr.a86 for EDR-DOS, called by the BIO init routines here.
* The BIO kernel has to locate the DOS file, meaning it will have to include a directory scanner. (Arguably, lDOS iniload contains just as much of a FAT FS reader (to read the remainder of the kernel file) as EDR-DOS's BIO file, but lDOS iniload certainly does not need a directory scanner.)
* Compression of kernel files also needs two bespoke solutions, one for each file, whereas lDOS iniload + inicomp has a single compression stage which depacks the entire remaining kernel. This can make for better compression ratio than compressing two files, too.

Back in the day I discussed this with Udo in the EDR-DOS forums. However, that thread is likely lost to time. I recall that Udo brought up you can update one of the files without the other, and vendors could get away with only providing a BIO file sharing a common DOS file that they wouldn't have to know much about. At the time I already noted that this last advantage is minor if the entire kernel is available as free software.

The second link that I included in my list also hints it is possible for the DOS to be resident somewhere already, and not have the BIO load it from a file. This means part of the work towards a single-file kernel may already be done.

---
l

ecm

Düsseldorf, Germany,
13.10.2023, 18:23

@ ecm

EDR-DOS repository - Single-file kernel load

Post reply

Another advantage is you may be able to share more code between the entire kernel than if you split it into two files. And some build time calculations may be possible to optimise things that a two-file kernel cannot do. (In lRxDOS's single-assembly build, NASM can potentially calculate things that even a single-file kernel build cannot if you use a linker to link multiple object files into one executable.)

---
l

Ro2003

10.10.2023, 16:32

@ ecm

EDR-DOS version number

Post reply

Regarding version number - to avoid past confusion cases - would be nice if:

- 6.5, 7.5, 8.5, etc. are reserved for use in emulators - by analogy with NTVDM
- 7.01.08 WIP is kept as "work in progress" and version is not increased to 7.01.09. That's the case with this update here, which is good!
- 7.08 and 7.09 are reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of EDR-DOS 7.01.08 and DR-DOS 7.07
- 7.1 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of MS-DOS 7.1, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08
- 8.2 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of MS-DOS 8.0, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08, DR-DOS 8.0, DR-DOS 8.1, RxDOS 7.2x
- 8.3 and up are reserved for UEFI versions or at least used with restrain
- 9.x gets reserved for future substantial change.
- incremental changes to get increase only in the x.xx.rr revision rather than the minor/major version number, e.g. use the 7.01.08 WIP until it gets merged with 7.07, then 7.09.rr until all 7.1 functionality is included, then 7.1x.rr until all 8.1 functionality is included, etc.

ecm

Düsseldorf, Germany,
12.10.2023, 19:08

@ Ro2003

EDR-DOS version number

Post reply

> Regarding version number - to avoid past confusion cases - would be nice
> if:
>
> - 6.5, 7.5, 8.5, etc. are reserved for use in emulators - by analogy with
> NTVDM
> - 7.01.08 WIP is kept as "work in progress" and version is not increased to
> 7.01.09. That's the case with this update here, which is good!

If I will do more work on EDR-DOS I am considering a 7.01.09 or beyond. But that remains to be seen.

> - 7.08 and 7.09 are reserved for IBMBIO/IBMDOS/COMMAND combination that
> provides all functionality of EDR-DOS 7.01.08 and DR-DOS 7.07
> - 7.1 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all
> functionality of MS-DOS 7.1, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08
> - 8.2 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all
> functionality of MS-DOS 8.0, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08,
> DR-DOS 8.0, DR-DOS 8.1, RxDOS 7.2x
> - 8.3 and up are reserved for UEFI versions or at least used with restrain
> - 9.x gets reserved for future substantial change.
> - incremental changes to get increase only in the x.xx.rr revision rather
> than the minor/major version number, e.g. use the 7.01.08 WIP until it gets
> merged with 7.07, then 7.09.rr until all 7.1 functionality is included,
> then 7.1x.rr until all 8.1 functionality is included, etc.

Don't have much of a comment on any of this.

---
l

glennmcc

North Jackson, Ohio (USA),
13.08.2023, 22:19

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

> I released new versions DRDOS 7.01.7 & 7.01.8
>

Question...

What ever happened to Udo ?

---
--
http://glennmcc.org/

glennmcc

North Jackson, Ohio (USA),
29.08.2023, 23:04

@ glennmcc

What ever happened to Udo ?

Post reply

> > I released new versions DRDOS 7.01.7 & 7.01.8
> >
>
> Question...
>
> What ever happened to Udo ?

No reply at-all ??

---
--
http://glennmcc.org/

Ro2003 10.10.2023, 16:10 @ glennmcc	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> > I released new versions DRDOS 7.01.7 & 7.01.8 > > > > Question... > > What ever happened to Udo ? The last post by Udo Kuhnt in his forum, 2012-Feb-02 is mentioned here, but link is broken and I can't find an archive of it. Any clues on that?

glennmcc

North Jackson, Ohio (USA),
10.10.2023, 21:35

@ Ro2003

New version DRDOS 7.01.7 & 7.01.8

Post reply

> > > I released new versions DRDOS 7.01.7 & 7.01.8
> > >
> >
> > Question...
> >
> > What ever happened to Udo ?
>
> The last
> post by Udo Kuhnt in his forum, 2012-Feb-02 is mentioned
> here,
> but link is broken and I can't find an archive of it. Any clues on that?

Way back 10yrs ago in this thread, DOS386 insinuated that Udo had died
but never clarified if that statement was just figuratively
due to the status of his Enhanced DR-DOS project
or if it was meant literally and Udo was actually physically dead.

http://www.bttr-software.de/forum/forum_entry.php?id=12870

---
--
http://glennmcc.org/

boeckmann

Aachen, Germany,
12.12.2023, 17:04

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

I made some changes to the latest EDR-DOS sources maintained by ecm:

- re-implement proprietary FIXUPP utility with open source version
- fixed bug in DRDOS.SYS div32 function, leading to division errors on partitions with more than 66535 FAT sectors. There is also a div32 function in DRBIO.SYS present, but it did not contain the bug.
- create FAT-32 default BPB for FAT-32 partitions instead of FAT-16 default BPB, which prevented FreeDOS format from formatting such a partition as FAT-32
- make DRDOS.SYS linkable with OpenWatcom wlink by adding missing group definitions and running FIXUPP on all RASM86 produced object files.
- create Watcom makefiles for DRBIO.SYS and DRDOS.SYS (using wlink)

Repository is located at https://github.com/SvarDOS/edrdos

ecm

Düsseldorf, Germany,
12.12.2023, 18:47

@ boeckmann

New version DRDOS 7.01.7 & 7.01.8

Post reply

> I made some changes to the latest EDR-DOS sources maintained by ecm:
>
> - fixed bug in DRDOS.SYS div32 function, leading to division errors on
> partitions with more than 66535 FAT sectors. There is also a div32 function
> in DRBIO.SYS present, but it did not contain the bug.

https://github.com/SvarDOS/edrdos/commit/167fe71ec058f80b7da47f11f2a34fc66938ad57

div16: mov ax,12[bp] mov dx,14[bp]

Surely you can xor dx, dx here if you already checked that word [bp + 14] is zero?

More to the point if the divisor high word is zero, a two-step division of two 32/16=16 divisions can be done on a 32-bit dividend (with 32-bit quotient) which would be faster than the full 32-bit division (that fully supports 32-bit divisors in addition to dividends/quotients).

The division functions in DRBIO both do not offer the fast path for smaller numbers:

https://github.com/SvarDOS/edrdos/blob/f6584d40d6dda553e63f7682ad672536f53ae6ff/drbio/disk.asm#L3286

https://github.com/SvarDOS/edrdos/blob/f6584d40d6d...e63f7682ad672536f53ae6ff/drbio/bdosldr.a86#L772

---
l

boeckmann

Aachen, Germany,
12.12.2023, 21:15

@ ecm

New version DRDOS 7.01.7 & 7.01.8

Post reply

> > I made some changes to the latest EDR-DOS sources maintained by ecm:
> >
> > - fixed bug in DRDOS.SYS div32 function, leading to division errors on
> > partitions with more than 66535 FAT sectors. There is also a div32
> function
> > in DRBIO.SYS present, but it did not contain the bug.
>
> https://github.com/SvarDOS/edrdos/commit/167fe71ec058f80b7da47f11f2a34fc66938ad57
>
> div16:> mov ax,12[bp] > mov dx,14[bp]
>
> Surely you can xor dx, dx here if you already checked that
> word [bp + 14] is zero?
>
> More to the point if the divisor high word is zero, a two-step division of
> two 32/16=16 divisions can be done on a 32-bit dividend (with 32-bit
> quotient) which would be faster than the full 32-bit division (that fully
> supports 32-bit divisors in addition to dividends/quotients).
>
> The division functions in DRBIO both do not offer the fast path for smaller
> numbers:
>
> https://github.com/SvarDOS/edrdos/blob/f6584d40d6dda553e63f7682ad672536f53ae6ff/drbio/disk.asm#L3286
>
> https://github.com/SvarDOS/edrdos/blob/f6584d40d6d...e63f7682ad672536f53ae6ff/drbio/bdosldr.a86#L772

Yes, by re-arranging a little bit, the unconditional jump can also be eliminated, like so:
div32: ; 32-bit division ;-------- ; On Entry: ; 32-bit dividend & divisor on stack ; space for 32-bit quotient & remainder reserved on stack ; SP-16 ; On Exit: ; 32-bit quotient & remainder on stack ; SP-16 ; Modified registers: ; AX,CX,DX,BP mov bp,sp ; base address of temporary variables add bp,2 cmp word ptr 10[bp],0 ; if divisor high => 32bit div jne div32_full cmp word ptr 14[bp],0 ; if dividend high => 32bit div jne div32_full div16: mov ax,12[bp] ; AX=low 16 bits of dividend xor dx,dx div word ptr 8[bp] xor cx,cx mov [bp],dx mov 2[bp],cx ; clear high part of remainder mov 4[bp],ax mov 6[bp],cx ; and quotient result ret div32_full: ...
I first thought that the xor cx,cx can be eliminated too, by clearing the result after the xor dx,dx. But the xor cx,cx leaves the flags in a defined state, which the div does not. So I think it is safer to leave this xor cx,cx in.

boeckmann

Aachen, Germany,
12.12.2023, 21:27

@ boeckmann

New version DRDOS 7.01.7 & 7.01.8

Post reply

> I first thought that the xor cx,cx can be eliminated too, by clearing the
> result after the xor dx,dx. But the xor cx,cx leaves the flags in a defined
> state, which the div does not. So I think it is safer to leave this xor
> cx,cx in.

It probably IS save. Because everytime div32 is used in the source, an addition follows that sets the flags anyway. So I will try to further optimize this and incorporate your suggestion regarding the two divisions on 16-bit divisor.

CandyMan

13.12.2023, 16:58

@ boeckmann

New version DRDOS 7.01.7 & 7.01.8

Post reply

> > I first thought that the xor cx,cx can be eliminated too, by clearing
> the
> > result after the xor dx,dx. But the xor cx,cx leaves the flags in a
> defined
> > state, which the div does not. So I think it is safer to leave this xor
> > cx,cx in.
>
> It probably IS save. Because everytime div32 is used in the source, an
> addition follows that sets the flags anyway. So I will try to further
> optimize this and incorporate your suggestion regarding the two divisions
> on 16-bit divisor.

You can convert the code below for Int64 to Int32 and replace the 32-bit registers with 16-bit registers to skip the 32-time loop.

function ModU(const A,B:Int64):Int64; assembler;{&FRAME-}{&USES EBX,ESI,EDI} var I:Int64; J:Int64; asm MOV EBX,A MOV EAX,[EBX+0] MOV EDX,[EBX+4] MOV DWORD [I+0],EAX MOV DWORD [I+4],EDX MOV EBX,B MOV ECX,[EBX+4] MOV EBX,[EBX+0] MOV DWORD [J+0],EBX MOV DWORD [J+4],ECX MOV EAX,EBX OR EAX,ECX JZ DivisionByZero MOV EAX,DWORD [I+0] TEST ECX,ECX JNZ @@BigDivisor CMP EDX,EBX JAE @@TwoDivs DIV EBX MOV EAX,EDX MOV EDX,ECX JMP @@Done @@TwoDivs: MOV ECX,EAX MOV EAX,EDX XOR EDX,EDX DIV EBX MOV EAX,ECX DIV EBX MOV EAX,EDX XOR EDX,EDX JMP @@Done @@BigDivisor: MOV EDI,ECX SHR EDX,1 RCR EAX,1 ROR EDI,1 RCR EBX,1 BSR ECX,ECX SHRD EBX,EDI,CL SHRD EAX,EDX,CL SHR EDX,CL ROL EDI,1 DIV EBX MOV EBX,DWORD [I+4] MOV ECX,EAX IMUL EDI,EAX MUL DWORD [J+0] ADD EDX,EDI SUB EBX,EAX MOV ECX,DWORD [I+4] MOV EAX,DWORD [J+0] SBB ECX,EDX SBB EDX,EDX AND EAX,EDX AND EDX,DWORD [J+4] ADD EAX,EBX ADC EDX,ECX @@Done: MOV ECX,@Result MOV [ECX+0],EAX MOV [ECX+4],EDX end; function DivU(const A,B:Int64):Int64; assembler;{&FRAME-}{&USES EBX,ESI,EDI} var I:Int64; J:Int64; asm MOV EBX,A MOV EAX,[EBX+0] MOV EDX,[EBX+4] MOV DWORD [I+0],EAX MOV DWORD [I+4],EDX MOV EBX,B MOV ECX,[EBX+4] MOV EBX,[EBX+0] MOV DWORD [J+0],EBX MOV DWORD [J+4],ECX MOV EAX,EBX OR EAX,ECX JZ DivisionByZero MOV EAX,DWORD [I+0] TEST ECX,ECX JNZ @@BigDivisor CMP EDX,EBX JAE @@TwoDivs DIV EBX MOV EDX,ECX JMP @@Done @@TwoDivs: MOV ECX,EAX MOV EAX,EDX XOR EDX,EDX DIV EBX XCHG EAX,ECX DIV EBX MOV EDX,ECX JMP @@Done @@BigDivisor: MOV EDI,ECX SHR EDX,1 RCR EAX,1 ROR EDI,1 RCR EBX,1 BSR ECX,ECX SHRD EBX,EDI,CL SHRD EAX,EDX,CL SHR EDX,CL ROL EDI,1 DIV EBX MOV EBX,DWORD [I+0] MOV ECX,EAX IMUL EDI,EAX MUL DWORD [J+0] ADD EDX,EDI SUB EBX,EAX MOV EAX,ECX MOV ECX,DWORD [I+4] SBB ECX,EDX SBB EAX,0 XOR EDX,EDX @@Done: MOV ECX,@Result MOV [ECX+0],EAX MOV [ECX+4],EDX end;

boeckmann

Aachen, Germany,
14.12.2023, 18:00

@ CandyMan

New version DRDOS 7.01.7 & 7.01.8

Post reply

> You can convert the code below for Int64 to Int32 and replace the 32-bit
> registers with 16-bit registers to skip the 32-time loop.

Thanks for the code. I can not convert it one by one, because the DRSYS div32 procedure also returns the remainder, but I get the idea...

However, for now I decided to leave the shifting algorithm as it is, mainly because it is a code path not often taken, and i want to fix more things than I break :-D

The div32 procedure is mainly called with 512 as the divisor (to calculate sectors and offsets into the FAT). So 99% of the time, the optimized 16-bit shortcut is used, I guess.

The current version is here:
https://github.com/SvarDOS/edrdos/blob/8fa1acd6576...9fd7f283a9119e3494036ce7/drdos/bdevio.a86#L2029

It should yield correct results (kernel behaves as expected). But perhaps someone with more assembly experience might double-check (from div32_full on it is the original code).

ecm

Düsseldorf, Germany,
14.12.2023, 20:58

@ boeckmann

New version DRDOS 7.01.7 & 7.01.8

Post reply

> > You can convert the code below for Int64 to Int32 and replace the 32-bit
> > registers with 16-bit registers to skip the 32-time loop.
>
> Thanks for the code. I can not convert it one by one, because the DRSYS
> div32 procedure also returns the remainder, but I get the idea...
>
> However, for now I decided to leave the shifting algorithm as it is, mainly
> because it is a code path not often taken, and i want to fix more things
> than I break :-D
>
> The div32 procedure is mainly called with 512 as the divisor (to calculate
> sectors and offsets into the FAT). So 99% of the time, the optimized 16-bit
> shortcut is used, I guess.
>
> The current version is here:
> https://github.com/SvarDOS/edrdos/blob/8fa1acd6576...9fd7f283a9119e3494036ce7/drdos/bdevio.a86#L2029
>
> It should yield correct results (kernel behaves as expected). But perhaps
> someone with more assembly experience might double-check (from div32_full
> on it is the original code).

div32: ; 32-bit division ;-------- ; On Entry: ; 32-bit dividend & divisor on stack ; space for 32-bit quotient & remainder reserved on stack ; SP-16 ; On Exit: ; 32-bit quotient & remainder on stack ; SP-16 ; Modified registers: ; AX,CX,DX,BP mov bp,sp ; base address of temporary variables add bp,2

Twice `inc bp` is cheaper in code space.

xor dx,dx cmp 10[bp],dx ; if divisor high != 0 => 32bit div jne div32_full mov cx,8[bp] ; CX <- divisor low mov 2[bp],dx ; clear remainder high, guaranteed to ; ...be zero here mov ax,14[bp] ; AX <- dividend high test ax,ax ; if both dividend and divisor are ; ...16bit, perform one 16bit division jz div16 ; ...else perform two 16bit divisions dix2x16: div cx ; divide dividend high by divisor low div16: mov 6[bp],ax ; 6[bp] <- quotient high mov ax,12[bp] ; AX <- dividend low div cx ; divide dividend low by divisor low ; ...DX -> remainder of previous ; ... division or zero mov [bp],dx ; store remainder low mov 4[bp],ax ; store quotient low ret div32_full:

Looks good to me. Dispatching to either the two-step division or a single one is new to me. I do think you could save code space at the cost of some performance by just dropping the test and jz. Zero divided by CX is always zero.

---
l

boeckmann Aachen, Germany, 16.12.2023, 21:52 @ ecm	New version DRDOS 7.01.7 & 7.01.8 Post reply
	> Looks good to me. Dispatching to either the two-step division or a single one is new to me. I do think you could save code space at the cost of some performance by just dropping the test and jz. Zero divided by CX is always zero. Thanks, used the `inc bp` you proposed, and left in the jump.

ecm

Düsseldorf, Germany,
30.12.2023, 14:27

@ boeckmann

New version DRDOS 7.01.7 & 7.01.8

Post reply

Note that I accidentally edited your post rather than replying to it. Here's my reply as its own post as it should have been posted.

> Thanks, used the inc bp you proposed, and left in the jump.

You can actually get rid of the inc if you just adjust all the references with BP in this function.

---
l

boeckmann

Aachen, Germany,
01.01.2024, 13:57

@ ecm

New version DRDOS 7.01.7 & 7.01.8

Post reply

> Note that I accidentally edited your post rather than replying to
> it. Here's my reply as its own post as it should have been posted.
>
> > Thanks, used the inc bp you proposed, and left in the jump.
>
> You can actually get rid of the inc if you just adjust all the references
> with BP in this function.

Thanks for the hint.

I now have DRBIO.SYS, DRDOS.SYS and COMMAND.COM linked with WLINK, and each has its own makefile.

For COMMAND.COM I had to change the reloading code and the loading of the appended help file, because the code assumed a fixed 512 byte EXE header. Its now variable in that the size of the header is determined by offset 8 of the EXE header itself. I changed COMMAND.COM to behave normally if it is fed with a .BAT file containing LF endings. I by accident created such a file and COMMAND.COM freaked out over it.

Regarding DRBIO.SYS, it should now create default FAT-32 BPBs conformant to MS-DOS / FreeDOS. But the code calculating the FAT size still produces non-optimal results, in that the size of the FATs themself is not respected when calculating it, wasting a few sectors. Unformatted partitions can now be formatted under DR-DOS with an unaltered FreeDOS format.

New version DRDOS 7.01.7 & 7.01.8 (Announce)

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS bugs on int 21h functions 7142h and 71A6h

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS development

EDR-DOS repository

EDR-DOS repository

EDR-DOS repository

EDR-DOS repository

EDR-DOS repository - Single-file kernel load

EDR-DOS repository - Single-file kernel load

EDR-DOS version number

EDR-DOS version number

New version DRDOS 7.01.7 & 7.01.8

What ever happened to Udo ?

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8

New version DRDOS 7.01.7 & 7.01.8