ecm
Düsseldorf, Germany, 07.01.2024, 20:43 |
Enhanced DR-DOS single-file load (2023 December revision) (Announce) |
I prepared a blog post at https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0107_enhanced_dr-dos_single-file_load
Basically, I converted EDR-DOS to load from a single kernel file. --- l |
roytam
08.01.2024, 07:26
@ ecm
|
Enhanced DR-DOS single-file load (2023 December revision) |
> I prepared a blog post at
> https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0107_enhanced_dr-dos_single-file_load
>
> Basically, I converted EDR-DOS to load from a single kernel file.
cool, this is kind of DR-DOS 7.06. |
Guti
10.01.2024, 17:09
@ ecm
|
Enhanced DR-DOS single-file load (2023 December revision) |
> I prepared a blog post at
> https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0107_enhanced_dr-dos_single-file_load
>
> Basically, I converted EDR-DOS to load from a single kernel file.
Good work. As your post stated, it open the doors to future improvements. Glad to see EDR is alive with you! --- Visit my personal blog at https://www.javiergutierrezchamorro.com |
Ro2003
13.01.2024, 09:28
@ ecm
|
Enhanced DR-DOS single-file load (2023 December revision) |
> I prepared a blog post at
> https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0107_enhanced_dr-dos_single-file_load
>
> Basically, I converted EDR-DOS to load from a single kernel file.
Great - both the changes and the blog post!
Can you please arrange for binary builds to be generated?
Does it support the LBA 33-bit?
Can you mention if some other features from lDOS, RxDOS, DR-DOS 7.03/8.x are not yet supported?
From your blog post I understand that December 2023 kernel can be booted from boot sectors of lDOS / RxDOS.3, FreeDOS, Enhanced DR-DOS, MS-DOS v6 / IBM-DOS, MS-DOS v7, Multiboot v1, Multiboot v2, NTLDR, BOOTMGR, or DOS-C IPL.SYS.
What about:
- booting from bootsectors of other DR-DOS (3.31-7.05), PC DOS 7.10
- boot sector that allows booting EDR-DOS, FreeDOS, PC DOS, MS-DOS v6, MS-DOS v7/8, DR-DOS
- boot sector that allows booting from GPT
- using COMMAND.COM from another DOS as main SHELL with the December 2023 kernel? (e.g. how much of these and these are implemented?) - the opposite question of this one. |
ecm
Düsseldorf, Germany, 14.01.2024, 22:58
@ Ro2003
|
Enhanced DR-DOS development |
> > I prepared a blog post at
> >
> https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0107_enhanced_dr-dos_single-file_load
> >
> > Basically, I converted EDR-DOS to load from a single kernel file.
>
> Great - both the changes and the blog post!
> Can you please arrange for binary builds to be generated?
My repo already has automatic (daily) current builds. You can find the most recent current build in https://pushbx.org/ecm/download/edrdos.zip - This file will be updated to a 2024 January revision within the next 1 hour as of this posting. This revision includes most of the patches from the SvarDOS repository, excluding some for building with OpenWatcom make and wlink instead.
All four kernel files are found in the root of the zipball. The shell is in command/bin/command.com as before. The files drbio.bin and drdos.sys exist in the subdirectories but are used only to build the single-file kernels, not needed otherwise.
> Does it support the
> LBA 33-bit?
No, not yet.
> Can you mention if some other features from lDOS, RxDOS, DR-DOS 7.03/8.x
> are not yet supported?
RxDOS comes with an LFN server built in (corresponding to the DOSLFN tool), but this is very incomplete and not fully compatible.
> From your blog post I understand that December 2023 kernel
This is only true of the kernel files using iniload, the *.com files. The *.sys files only support loading as FreeDOS or EDR-DOS kernels.
> can be booted
> from boot sectors of lDOS / RxDOS.3, FreeDOS, Enhanced DR-DOS, MS-DOS v6 /
> IBM-DOS, MS-DOS v7, Multiboot v1, Multiboot v2, NTLDR, BOOTMGR, or DOS-C
> IPL.SYS.
Yes, but don't say the last ones too loudly.
> What about:
> - booting from bootsectors of other DR-DOS (3.31-7.05),
I would have to test and/or study these. If you can provide images that use them I can look into it.
> PC DOS 7.10
The IBM-DOS entry of lDOS iniload does support PC-DOS 7.10 load, including from FAT32.
> - boot sector that allows booting EDR-DOS, FreeDOS, PC DOS, MS-DOS v6,
> MS-DOS v7/8, DR-DOS
My ldosboot boot sector loaders can be built to cover a number of protocols, though you may need to disable some options to make them fit. It is easier to set up lDebug (using any sector-to-iniload protocol to load the debugger) then enter a boot protocol=PROTOCOLNAME command and upon success run a Q command to make the debugger hand over control to the next kernel.
> - boot sector that allows
> booting
> from GPT
You need another loader stage to replace the traditional MBR loader which will load and pass control to the boot sector loader. Other than the 32-bit or 33-bit LBA limits most boot sector loaders do not care whether they are running on a GPT, MBR primary, or MBR logical partition.
> - using COMMAND.COM from another DOS as main SHELL with the December 2023
> kernel? (e.g. how much of
> these
> and these are implemented?) -
> the opposite question of
> this one.
I mostly work on the kernels. If you have any particular feature of another shell that doesn't work on this kernel, feel free to specify. --- l |
ecm
Düsseldorf, Germany, 20.01.2024, 13:24
@ ecm
|
lDebug boot loading other kernels |
> > - boot sector that allows booting EDR-DOS, FreeDOS, PC DOS, MS-DOS v6,
> > MS-DOS v7/8, DR-DOS
>
> My ldosboot boot sector loaders can be built to cover a number of
> protocols, though you may need to disable some options to make them fit. It
> is easier to set up lDebug (using any sector-to-iniload protocol to load
> the debugger) then enter a boot protocol=PROTOCOLNAME command
> and upon success run a Q command to make the debugger hand over control to
> the next kernel.
By the way, you can load a kernel file from any subdirectory of a (FAT12, FAT16, or FAT32) file system. For instance, boot protocol ldos hda1/kernels/edrdos.com could be used to load EDR-DOS from a subdirectory. Further, I fixed a bug recently which makes it so you can now load traditional dual-file kernels (MS-DOS v6 or IBM-DOS, but not old EDR-DOS) from any two subdirectories. boot protocol msdos6 fda/msdosio/msdos6io.sys /msdosdos/msdos6.sys would work. If the files are in the same directory, a command like boot protocol msdos6 fda/msdos/msdos6io.sys msdos6.sys works too (if the add name doesn't contain a slash it is in the same directory as the kernel name). Details in the manual. --- l |
CandyMan
07.06.2024, 16:19
@ ecm
|
Enhanced DR-DOS single-file load (2023 December revision) |
Modified EDR-DOS cannot enter to one of the directories on my hard drive.
I tested kernel from 19 may 2024.
https://pushbx.org/ecm/download/old/edrdos/20240519.zip |
ecm
Düsseldorf, Germany, 07.06.2024, 17:12
@ CandyMan
|
Enhanced DR-DOS single-file load (2023 December revision) |
> Modified EDR-DOS cannot enter to one of the directories on my hard drive.
>
> I tested kernel from 19 may 2024.
>
> https://pushbx.org/ecm/download/old/edrdos/20240519.zip
Does any earlier revision, including Udo Kuhnt's, work? Do other DOS versions work? What exactly does "cannot enter" mean, a CD command fails for this directory? Can you create a disk image that reproduces the problem in qemu? (Preferably with as little data on the drive as possible.) --- l |
CandyMan
07.06.2024, 18:56
@ ecm
|
Enhanced DR-DOS single-file load (2023 December revision) |
> > Modified EDR-DOS cannot enter to one of the directories on my hard
> drive.
> >
> > I tested kernel from 19 may 2024.
> >
> > https://pushbx.org/ecm/download/old/edrdos/20240519.zip
>
> Does any earlier revision, including Udo Kuhnt's, work? Do other DOS
> versions work? What exactly does "cannot enter" mean, a CD
> command fails for this directory? Can you create a disk image that
> reproduces the problem in qemu? (Preferably with as little data on the
> drive as possible.)
The kernels of other clones work and so do previous versions of EDR-DOS (I tested until August 2023). The CD command does not work and neither does trying to enter the directory with e.g. Volkov Commander. I suspect that these are directories with a cluster larger than 65535. My disk is USB FAT32 - 32GB. |
ecm
Düsseldorf, Germany, 07.06.2024, 19:42
@ CandyMan
|
Enhanced DR-DOS - CD bug |
> The kernels of other clones work and so do previous versions of EDR-DOS (I
> tested until August 2023).
What exact revision is the latest that works?
> The CD command does not work and neither does
> trying to enter the directory with e.g. Volkov Commander. I suspect that
> these are directories with a cluster larger than 65535. My disk is USB
> FAT32 - 32GB.
I'll see about trying this later. --- l |
ecm
Düsseldorf, Germany, 07.06.2024, 19:47
@ ecm
|
Enhanced DR-DOS - CD bug |
> > The kernels of other clones work and so do previous versions of EDR-DOS
> (I
> > tested until August 2023).
>
> What exact revision is the latest that works?
This could be cause for an error: https://hg.pushbx.org/ecm/edrdos/rev/8d3b6d9a415d
Does this one work?: https://pushbx.org/ecm/download/old/edrdos/20231205.zip --- l |
CandyMan
07.06.2024, 22:10
@ ecm
|
Enhanced DR-DOS - CD bug |
> > What exact revision is the latest that works?
Version <= 20240114.zip works fine
Version >= 20240329.zip doesn't work |
ecm
Düsseldorf, Germany, 07.06.2024, 23:17
@ CandyMan
|
Enhanced DR-DOS - CD bug |
> > > What exact revision is the latest that works?
>
> Version <= 20240114.zip works fine
> Version >= 20240329.zip doesn't work
I was able to reproduce, CD to a directory causes a critical error prompt. I built a hard disk image like this: nasm -D_MEDIAID=0F8h -D_SPF=2000 ../bootimg/bootimg.asm -I ../bootimg/ -I ../lmacros/ -D_MBR -D_BPE=32 -D_MBR_PART_TYPE=fat32 -o big32.img -D_PAYLOADFILE=::fill,'(512 * 76000),26h,fill.dat,::chdir,testdir,::fill,32,32,test.dat' -D_SPI=256000
I am fairly sure that a SvarDOS contribution changing the LBA flagging is to blame: https://hg.pushbx.org/ecm/edrdos/rev/220f54eecbb8 From https://github.com/SvarDOS/edrdos/commit/99765bd4c9ec9e035f1bd2af191c35d440c99383
It changed the LBA use to be indicated by the UDF_LBA flag. However, in add_unit this flag is cleared: https://hg.pushbx.org/ecm/edrdos/file/1137afe0115d/drbio/disk.asm#l616
The next changeset will fix this problem, please test today's June build in 45min from now. --- l |
ecm
Düsseldorf, Germany, 07.06.2024, 23:24
@ ecm
|
Enhanced DR-DOS - CD bug |
> > > > What exact revision is the latest that works?
> >
> > Version <= 20240114.zip works fine
> > Version >= 20240329.zip doesn't work
>
> I was able to reproduce, CD to a directory causes a critical error prompt.
> I built a hard disk image like this: nasm -D_MEDIAID=0F8h -D_SPF=2000
> ../bootimg/bootimg.asm -I ../bootimg/ -I ../lmacros/ -D_MBR -D_BPE=32
> -D_MBR_PART_TYPE=fat32 -o big32.img -D_PAYLOADFILE=::fill,'(512 *
> 76000),26h,fill.dat,::chdir,testdir,::fill,32,32,test.dat'
> -D_SPI=256000
>
> I am fairly sure that a SvarDOS contribution changing the LBA flagging is
> to blame: https://hg.pushbx.org/ecm/edrdos/rev/220f54eecbb8 From
> https://github.com/SvarDOS/edrdos/commit/99765bd4c9ec9e035f1bd2af191c35d440c99383
>
> It changed the LBA use to be indicated by the UDF_LBA flag.
> However, in add_unit this flag is cleared:
> https://hg.pushbx.org/ecm/edrdos/file/1137afe0115d/drbio/disk.asm#l616
>
> The next changeset will fix this problem, please test today's June build in
> 45min from now.
This is the fix changeset: https://hg.pushbx.org/ecm/edrdos/rev/dde66e015fb8 --- l |
CandyMan
08.06.2024, 09:59
@ ecm
|
Enhanced DR-DOS - CD bug |
> The next changeset will fix this problem, please test today's June build in
> 45min from now.
Version 20240607 works fine.
Could you create an alternative version of EDR-DOS and add detection of FAT drives on the GPT partition? See how this is done in FreeDOS.
Thanks.
InitDisk.C (FreeDOS)
https://megawrzuta.pl/download/078fe0c107fb750fb2f9120126d869e5.html |
CandyMan
19.06.2024, 19:45
@ ecm
|
? |
? |
boeckmann
Aachen, Germany, 20.06.2024, 18:00
@ CandyMan
|
Enhanced DR-DOS - CD bug |
> Could you create an alternative version of EDR-DOS and add detection of FAT
> drives on the GPT partition? See how this is done in FreeDOS.
There are also a bunch of incompatibilities between FreeDOS / MS-DOS and EDR kernels regarding drive letter assignment
https://github.com/SvarDOS/edrdos/issues/59
and the permitted access to non-initialized FAT partitions
https://github.com/SvarDOS/edrdos/issues/15
If anyone is interested in working on this, feel free to join... |
glennmcc
North Jackson, Ohio (USA), 22.06.2024, 02:13
@ CandyMan
|
? |
> ?
What is your question ? --- --
http://glennmcc.org/ |
nico7550
23.06.2024, 08:18
@ glennmcc
|
? |
> > ?
>
> What is your question ?
His question is is in the post just above the interrogation point post |
boeckmann
Aachen, Germany, 30.06.2024, 16:57
@ boeckmann
|
Enhanced DR-DOS - CD bug |
The DRBIO.SYS source is now fully ported to JWasm and can also be build under Win32 (and probably Linux if OpenWatcom WLINK is installed). Porting DRDOS.SYS will take some time. But after that the EDR-DOS kernel should be buildable with free software. |
CandyMan
03.07.2024, 17:55
@ glennmcc
|
unnecessary "stc" |
"STC" instructions are unnecessary in "dos7.asm" if there is a jump to error_exit() where the flags are changed and the interrupt is exited with the CF flag set.
stc
jmp error_exit ; no, then exit with error
|
CandyMan
03.07.2024, 18:54
@ ecm
|
FAT32 search on GPT partition |
This code may be added to EDR-DOS sources.
GPT_Signature equ 00h
GPT_Revision equ 08h
GPT_HeaderSize equ 0Ch
GPT_HeaderCRC equ 10h
GPT_Reserved equ 14h
GPT_CurrentLBA equ 18h
GPT_BackupLBA equ 20h
GPT_FirstUsableLBA equ 28h
GPT_LastUsableLBA equ 30h
GPT_DiskGUID equ 38h
GPT_PartitionsLBA equ 48h
GPT_PartitionNumber equ 50h
GPT_PartitionEntrySize equ 54h
GPTEntry_PartitionGUID equ 00h
GPTEntry_uniqGUID equ 10h
GPTEntry_StartLBA equ 20h
GPTEntry_EndLBA equ 28h
GPTEntry_Attributes equ 30h
GPTEntry_Name equ 38h
db 'GPT',0 ;gpt code flag
gpt_init:
nop ;to modify by hex editor to "ret" - 0xC3
mov dl,80h ;start from 1st hard disk
;push di
ya_gpt:
xor di,di ;\ start from zero partition
xor bx,bx ;/
again_gpt:
cmp nunits,MAXPART ; do we already have the maximum?
jae lt_gpt ; skip if space for more units
lea si,diskaddrpack ; pointer to disk address packet
mov word ptr [si+ 8],1 ;\ make dword = 1
and word ptr [si+10],0 ;/
push bx
call login_read_dx_lba ; read sector
pop bx
jc no_gpt
mov si,CG:local_buffer ; check if sector start
lodsw ; with "EFI PART" string
cmp ax,"FE"
jnz no_gpt
lodsw
cmp ax," I"
jnz no_gpt
lodsw
cmp ax,"AP"
jnz no_gpt
lodsw
cmp ax,"TR"
jnz no_gpt
; start from, qword = 2?
cmp word ptr [si+GPT_PartitionsLBA-4*2+0],2
jnz no_gpt
xor ax,ax
cmp [si+GPT_PartitionsLBA-4*2+2],ax
jnz no_gpt
cmp [si+GPT_PartitionsLBA-4*2+4],ax
jnz no_gpt
cmp [si+GPT_PartitionsLBA-4*2+6],ax
jnz no_gpt
; partition size, qword = 80h?
cmp word ptr [si+GPT_PartitionEntrySize-4*2+0],0080h
jnz no_gpt
cmp word ptr [si+GPT_PartitionEntrySize-4*2+2],ax
jnz no_gpt
; save number of partitons
push word ptr [si+GPT_PartitionNumber-4*2+2]
push word ptr [si+GPT_PartitionNumber-4*2+0]
; save LBA sector number (dword)
push word ptr [si+GPT_PartitionsLBA-4*2+2]
push word ptr [si+GPT_PartitionsLBA-4*2+0]
lea si,diskaddrpack
; copy LBA sector number to packet and load this sector
pop word ptr [si+ 8]
pop word ptr [si+10]
; make partition number division by 4
mov ax,di
mov cx,bx
shr cx,1
rcr ax,1
shr cx,1
rcr ax,1
; add division result to the sector number
add word ptr [si+ 8],ax
adc word ptr [si+10],cx
push bx
call login_read_dx_lba ; read sector
pop bx
jc er_gpt
; make pointer to 128 bytes structure in sector (512/128=4)
mov ax,di
and ax,3
mov cl,80h
mul cl
add ax,CG:local_buffer
mov si,ax
; load LBA disk starting sector number
mov ax,[si+GPTEntry_StartLBA+0*8+0]
mov cx,[si+GPTEntry_StartLBA+0*8+2]
; save partition start
mov word ptr [partstart+0],ax
mov word ptr [partstart+2],cx
; zero ?
or ax,cx
jz nx_gpt
; if partition finish (dword +4)<>0 then skip
mov ax,[si+GPTEntry_EndLBA+4+2]
or ax,[si+GPTEntry_EndLBA+4+0]
jnz nx_gpt
; save partition finish
mov ax,[si+GPTEntry_EndLBA+2]
mov word ptr [partend+2],ax
mov ax,[si+GPTEntry_EndLBA+0]
mov word ptr [partend+0],ax
mov ax,word ptr [partstart+0]
mov cx,word ptr [partstart+2]
; compute partition size
mov si,word ptr [partend+0]
sub si,ax
mov word ptr [part_size+0],si
mov si,word ptr [partend+2]
sbb si,cx
mov word ptr [part_size+2],si
add word ptr [part_size+0],1
adc word ptr [part_size+2],0
lea si,diskaddrpack ; pointer to disk address packet
mov word ptr [si+ 8],ax
mov word ptr [si+10],cx
push bx
call login_read_dx_lba ; read 1st partition sector
pop bx
jc nx_gpt
mov si,CG:local_buffer
mov ax,[si+52h] ;\
cmp ax,"AF" ; \
jnz nx_gpt ; > = "FAT"? to skip NTFS
mov al,[si+54h] ; /
cmp al,"T" ;/
jnz nx_gpt
mov [parttype],FAT32X_ID
pushx <di,bx,dx>
call login_p0 ; add and register new disk
popx <dx,bx,di>
nx_gpt:
add di,1 ;\ next partition
adc bx,0 ;/
pop ax ;\ left partitions
pop cx ;/
cmp cx,bx
jnz again_gpt
cmp ax,di
jnz again_gpt
jmp no_gpt
er_gpt:
add sp,2*2
no_gpt:
inc dl ; next hard disk to check
jnz ya_gpt ; if ZF=0 jump
lt_gpt:
;pop di
ret
|
tom
Germany (West), 03.07.2024, 19:48
@ CandyMan
|
FAT32 search on GPT partition |
> This code may be added to EDR-DOS sources.
As I said: just 187 assembly lines (including empty lines).
more like 50 lines in C.
What is missing is the part where partition start and ending offsets are beyond
2^32 (almost trivial) AND WHERE TO STORE these offsets, adding them to LBA48 offsets before passing to the BIOS. |
tom
Germany (West), 03.07.2024, 19:51
@ tom
|
FAT32 search on GPT partition |
> This code may be added to EDR-DOS sources.
As I said: just 187 assembly lines (including empty lines).
probably more like 50 lines in C.
What is missing is the part where partition start and ending offsets are
beyond 2^32 (almost trivial) AND WHERE TO STORE these offsets, adding them to
LBA48 offsets before passing them to the BIOS. |
CandyMan
03.07.2024, 20:55
@ tom
|
FAT32 search on GPT partition |
> > This code may be added to EDR-DOS sources.
>
> As I said: just 187 assembly lines (including empty lines).
>
> probably more like 50 lines in C.
>
> What is missing is the part where partition start and ending offsets are
> beyond 2^32 (almost trivial) AND WHERE TO STORE these offsets, adding them
> to
> LBA48 offsets before passing them to the BIOS.
I made some small corrections. Thanks.
GPT_Signature equ 00h
GPT_Revision equ 08h
GPT_HeaderSize equ 0Ch
GPT_HeaderCRC equ 10h
GPT_Reserved equ 14h
GPT_CurrentLBA equ 18h
GPT_BackupLBA equ 20h
GPT_FirstUsableLBA equ 28h
GPT_LastUsableLBA equ 30h
GPT_DiskGUID equ 38h
GPT_PartitionsLBA equ 48h
GPT_PartitionNumber equ 50h
GPT_PartitionEntrySize equ 54h
GPTEntry_PartitionGUID equ 00h
GPTEntry_uniqGUID equ 10h
GPTEntry_StartLBA equ 20h
GPTEntry_EndLBA equ 28h
GPTEntry_Attributes equ 30h
GPTEntry_Name equ 38h
db 'GPT',0 ;gpt code flag
gpt_init:
nop ;to modify by hex editor to "ret" - 0xC3
mov dl,80h ;start from 1st hard disk
;push di
ya_gpt:
xor di,di ;\ start from zero partition
xor bx,bx ;/
again_gpt:
cmp nunits,MAXPART ; do we already have the maximum?
jae lt_gpt ; skip if space for more units
lea si,diskaddrpack ; pointer to disk address packet
mov word ptr [si+ 8],1 ;\ make dword = 1
and word ptr [si+10],0 ;/
push bx
call login_read_dx_lba ; read sector
pop bx
jc no_gpt
mov si,CG:local_buffer ; check if sector start
lodsw ; with "EFI PART" string
cmp ax,"FE"
jnz no_gpt
lodsw
cmp ax," I"
jnz no_gpt
lodsw
cmp ax,"AP"
jnz no_gpt
lodsw
cmp ax,"TR"
jnz no_gpt
; start from, qword = 2?
cmp word ptr [si+GPT_PartitionsLBA-4*2+0],2
jnz no_gpt
xor ax,ax
cmp [si+GPT_PartitionsLBA-4*2+2],ax
jnz no_gpt
cmp [si+GPT_PartitionsLBA-4*2+4],ax
jnz no_gpt
cmp [si+GPT_PartitionsLBA-4*2+6],ax
jnz no_gpt
; partition size, qword = 80h?
cmp word ptr [si+GPT_PartitionEntrySize-4*2+0],0080h
jnz no_gpt
cmp word ptr [si+GPT_PartitionEntrySize-4*2+2],ax
jnz no_gpt
; save number of partitons
push word ptr [si+GPT_PartitionNumber-4*2+2]
push word ptr [si+GPT_PartitionNumber-4*2+0]
; save LBA sector number (dword)
push word ptr [si+GPT_PartitionsLBA-4*2+2]
push word ptr [si+GPT_PartitionsLBA-4*2+0]
lea si,diskaddrpack
; copy LBA sector number to packet and load this sector
pop word ptr [si+ 8]
pop word ptr [si+10]
; make partition number division by 4
mov ax,di
mov cx,bx
shr cx,1
rcr ax,1
shr cx,1
rcr ax,1
; add division result to the sector number
add word ptr [si+ 8],ax
adc word ptr [si+10],cx
push bx
call login_read_dx_lba ; read sector
pop bx
jc er_gpt
; make pointer to 128 bytes structure in sector (512/128=4)
mov ax,di
and ax,3
mov cl,80h
mul cl
add ax,CG:local_buffer
mov si,ax
; StartLBA >= 2^32
mov ax,[si+GPTEntry_StartLBA+4+0]
or ax,[si+GPTEntry_StartLBA+4+2]
jnz nx_gpt
; load LBA disk starting sector number
mov ax,[si+GPTEntry_StartLBA+0*8+0]
mov cx,[si+GPTEntry_StartLBA+0*8+2]
; save partition start
mov word ptr [partstart+0],ax
mov word ptr [partstart+2],cx
; zero ?
or ax,cx
jz nx_gpt
; if partition finish (dword +4)<>0 then skip (EndLBA >= 2^32)
mov ax,[si+GPTEntry_EndLBA+4+2]
or ax,[si+GPTEntry_EndLBA+4+0]
jnz nx_gpt
; save partition finish
mov ax,[si+GPTEntry_EndLBA+2]
mov word ptr [partend+2],ax
mov ax,[si+GPTEntry_EndLBA+0]
mov word ptr [partend+0],ax
mov ax,word ptr [partstart+0]
mov cx,word ptr [partstart+2]
; compute partition size
mov si,word ptr [partend+0]
sub si,ax
mov word ptr [part_size+0],si
mov si,word ptr [partend+2]
sbb si,cx
jc nx_gpt ; overflow? yes, skip
mov word ptr [part_size+2],si
add word ptr [part_size+0],1
adc word ptr [part_size+2],0
lea si,diskaddrpack ; pointer to disk address packet
mov word ptr [si+ 8],ax
mov word ptr [si+10],cx
push bx
call login_read_dx_lba ; read 1st partition sector
pop bx
jc nx_gpt
mov si,CG:local_buffer
mov ax,[si+52h] ;\
cmp ax,"AF" ; \
jnz nx_gpt ; > = "FAT"? to skip NTFS
mov al,[si+54h] ; /
cmp al,"T" ;/
jnz nx_gpt
mov [parttype],FAT32X_ID
pushx <di,bx,dx>
call login_p0 ; add and register new disk
popx <dx,bx,di>
nx_gpt:
add di,1 ;\ next partition
adc bx,0 ;/
pop ax ;\ left partitions
pop cx ;/
cmp cx,bx
jnz again_gpt
cmp ax,di
jnz again_gpt
jmp no_gpt
er_gpt:
add sp,2*2
no_gpt:
inc dl ; next hard disk to check
jnz ya_gpt ; if ZF=0 jump
lt_gpt:
;pop di
ret
|
boeckmann
Aachen, Germany, 08.07.2024, 22:31
@ CandyMan
|
Kernel ported to JWasm |
I finished porting the EDR-DOS kernel[1] to JWasm and was able to build it under DOS, Win32 and MacOS. This should also build under Linux. OpenWatcom, specifically wmake, wlink and exe2bin are additional build requirements for building drbio.sys and drdos.sys. The command.com build also depends on the Watcom C compiler.
Porting required some manual steps, opening the door for human errors. Time will tell how many of them I added to the source...
[1] https://github.com/SvarDOS/edrdos |
boeckmann
Aachen, Germany, 09.07.2024, 18:22
@ boeckmann
|
Kernel ported to JWasm |
Binaries and a 1.44M floppy image are now automatically generated via Github workflows. They can be downloaded from https://github.com/SvarDOS/edrdos/actions. Click on the last successful workflow run to get to the files... |
Japheth
Germany (South), 10.07.2024, 17:32
@ boeckmann
|
Kernel ported to JWasm |
> Binaries and a 1.44M floppy image are now automatically generated via
> Github workflows. They can be downloaded from
> https://github.com/SvarDOS/edrdos/actions. Click on the last successful
> workflow run to get to the files...
https://github.com/SvarDOS/edrdos/actions --- MS-DOS forever! |
ecm
Düsseldorf, Germany, 14.07.2024, 21:03
@ boeckmann
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
> I finished porting the EDR-DOS kernel[1] to JWasm and was able to build it
> under DOS, Win32 and MacOS. This should also build under Linux. OpenWatcom,
> specifically wmake, wlink and exe2bin are additional build requirements for
> building drbio.sys and drdos.sys. The command.com build also depends on the
> Watcom C compiler.
>
> Porting required some manual steps, opening the door for human errors. Time
> will tell how many of them I added to the source...
>
> [1] https://github.com/SvarDOS/edrdos
I picked most of the changes to port DRBIO into my EDR-DOS repo. I used my new identicalising tool ident86 to validate that all changes in the binary are due to different encoding choices that have the same meaning in the disassembly. I wrote about this on my blog.
It turns out your DRBIO port seems to be completely right, except for a few problems along the way like the initcode: WRT keyword you used in this commit for nlsfunc.asm which you silently undid in a commit described as "convert bdosldr.a86 to JWASM". That's not good. I also made sure in my picks to separately copy, move, rename, or delete files in separate changesets that do not change any of the content in the same changeset, to simplify following the changes if you were to inspect the revisions' logs.
I didn't get around to applying the same process to the DRDOS module yet. As mentioned, this may require a small adjustment to ident86 to work with the DRDOS binary and its associated trace listing file drdos.tls created by the scripts in my build. --- l |
boeckmann
Aachen, Germany, 14.07.2024, 22:37
@ ecm
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
> It turns out your DRBIO port seems to be completely right, except for a few
> problems along the way like the initcode: WRT keyword you used
> in
> this commit for nlsfunc.asm which you silently undid
> in
> a commit described as "convert bdosldr.a86 to JWASM". That's not
> good. I also made sure in my picks to separately copy, move, rename, or
> delete files in separate changesets that do not change any of the content
> in the same changeset, to simplify following the changes if you were to
> inspect the revisions' logs.
Really helpful having someone double checking this! Thanks.
I learned a couple of things. Especially what not to do when converting a file: Copy it to a new file, convert the new file, check in the new file, and delete the old file. Good reciepe to make tracking the changes via commit log really hard. Better way is to commit as the original file and then rename. So you get a more meaningful diff. I tried to follow this later when porting DRDOS component.
>
> I didn't get around to applying the same process to the DRDOS module yet.
> As mentioned, this may require a small adjustment to ident86 to work with
> the DRDOS binary and its associated trace listing file drdos.tls created by
> the scripts in my build.
In contrast to the port of DRBIO, I tried not to introduce offset changes resulting from different instruction encodings, inserting NOPs etc. if needed. Made life easier when doing binary comparisons. |
CandyMan
22.07.2024, 16:57
@ boeckmann
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
It would be useful to change some instructions "LEA Dst,Addr" to the shorter "MOV Dst,OFFSET Addr" |
boeckmann
Aachen, Germany, 23.07.2024, 20:50
@ CandyMan
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
> It would be useful to change some instructions "LEA Dst,Addr" to the
> shorter "MOV Dst,OFFSET Addr"
Yes, I can give you access to the repo at https://github.com/SvarDOS/edrdos |
ecm
Düsseldorf, Germany, 23.07.2024, 21:34
@ CandyMan
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
> It would be useful to change some instructions "LEA Dst,Addr" to the
> shorter "MOV Dst,OFFSET Addr"
Apparently this is done by some version of MASM, but JWasm doesn't do it. --- l |
Rugxulo
Usono, 24.07.2024, 00:25
@ ecm
|
EDR-DOS kernel ported to JWasm - ident86 validated DRBIO port |
> > It would be useful to change some instructions "LEA Dst,Addr" to the
> > shorter "MOV Dst,OFFSET Addr"
>
> Apparently this is done by some version of MASM, but JWasm doesn't do it.
TASM and A86 do it by default, but newer MASMs (since v5?) don't do it anymore. Some purists complain when an assembler does things "behind your back".
IIRC, the recommended fix is via a macro with opattr 8 (or such). You probably have to use "option nokeyword:<lea>" first if you insist on calling the macro LEA.
It only saves a byte per instance and probably isn't noticeably faster.
> MASM 6.11 README.TXT
> The MASM 6.1 Reference indicates that the LEA instruction is
> encoded as a MOV when the source operand is a direct memory address.
>
> In response to programmer requests, MASM 6.1x no longer performs this
> optimization automatically. The optimization can be performed by
> using the OPATTR operator, as shown in the following macro:
MOVLEA MACRO Dest, Symbol
IF (OPATTR(Symbol)) AND 08h
MOV Dest, OFFSET Symbol
ELSE
LEA Dest, Symbol
ENDIF
ENDM
|