search

dosemu2 / fdpp

FreeDOS plus-plus, 64bit DOS
GNU General Public License v3.0
198 stars 18 forks source link

MFT memory report allocations inconsistent #180

Closed andrewbird closed 3 years ago

andrewbird commented 3 years ago

Since the FDPP kernel moved up in memory MFT(QEMM 7.5) has an inconsistent display of allocation. The region at issue is 0070.000 to 0084:0000.

Here it's allocated to DOS

dosoverview

Here it's not displayed but since the free range starts above it I think it's allocated

firstmegprograms

Here it's in the free block

firstmegoverview

stsp commented 3 years ago

So why do you think this is the case? It thinks of some "DOS data". What can this be? Maybe it assumes LoL is there?

andrewbird commented 3 years ago

Not sure. DR-DOS 7.03's mem thinks it's Device drivers, but then shows it again as Environment. I don't think Caldera released the source to the utilities, only the kernel and command.com, which is a shame as we'd know where it was getting confused.

Current

│   70:0000 │     BIOS │  FA490h,1,025,168 │ Device drivers                    │
│   70:0000 │      MEM │    150h,     336 │ Environment                       │
│   85:0000 │      MEM │  15C20h,  89,120 │ Program                           │

Before you moved it

│   70:0000 │     BIOS │    690h,   1,680 │ Device drivers                    │
│   60:0644 │ CON      │                  │  System device driver             │
│   60:0656 │ PRN      │                  │  System device driver             │
│   60:0668 │ AUX      │                  │  System device driver             │
│   60:067A │ LPT1     │                  │  System device driver             │
│   60:068C │ LPT2     │                  │  System device driver             │
│   60:069E │ LPT3     │                  │  System device driver             │
│   60:06B0 │ COM1     │                  │  System device driver             │
│   60:06C2 │ COM2     │                  │  System device driver             │
│   60:06D4 │ COM3     │                  │  System device driver             │
│   60:06E6 │ COM4     │                  │  System device driver             │
│   60:06F8 │ CLOCK$   │                  │  System device driver             │
│   60:070A │    A:-E: │                  │  System device driver             │

So there's a gap between 0x700(0070:0000) and the first internal driver 0x0xc44(0060:0644) of 0x544 bytes. Reading the map file from the freedos kernel I can see this at those addresses (0010 segment ends up at 0070), but what is at those first 256 bytes I'm not sure.

0010:0100      _intvec_table
0010:0119      _int1e_table
0010:0127      _TEXT_DGROUP
0010:012a      _kbdType
0010:012b*     ConInit
0010:013b*     ConRead
0010:0158*     KbdRdChar
0010:017b      CommonNdRdExit
0010:01b9*     ConInpFlush
0010:01d8*     ConWrite
0010:01ec      _int29_handler
0010:01fe      _got_cbreak
0010:020d      _ReqPktPtr
0010:0213      GenStrategy
0010:02ca      _IOSuccess
0010:02d4      _IOExit
0010:02e8      _IODone
0010:02ec      _IOCommandError
0010:02ee      _IOErrCnt
0010:02f6      _IOErrorExit
0010:02fa      GetUnitNum
0010:040d      uPrtNo
0010:0544      _con_dev
stsp commented 3 years ago

but what is at those first 256 bytes I'm not sure.

PSP. But because its below the MCB chain, you do not list it in dosdebug.

andrewbird commented 3 years ago

Is that PSP for the kernel? What's it used for? Is the address 0070:0000 always the kernel's load position on all DOSes (except FDPP)?

I'm a little confused though, I booted FreeDOS 1.2 kernel and expected to see a PSP signature at 0070:0000.

dosdebug> d 0070:0000

0070:0000 00 01 00 08 00 00 7C 05 E8 E2 04 04 F1 00 F0 E8  ......|.hb..q.ph
0070:0010 DB 04 B3 FE 00 F0 E8 D4 04 87 E9 00 F0 E8 CD 04  [.3~.phT..i.phM.
0070:0020 2B E1 00 F0 E8 C6 04 A6 FE 00 F0 CB EB 10 69 F5  +a.phF.&~.pKk.iu
0070:0030 00 F0 4B 42 00 EB F4 00 00 00 00 00 00 00 E8 B5  .pKB.kt.......h5
0070:0040 04 EB 10 0D F1 00 F0 4B 42 00 EB DF 00 00 00 00  .k..q.pKB.k_....
0070:0050 00 00 00 E8 A0 04 EB 10 0E F1 00 F0 4B 42 00 EB  ...h .k..q.pKB.k
0070:0060 CA 00 00 00 00 00 00 00 E8 8B 04 EB 10 0F F1 00  J.......h..k..q.
0070:0070 F0 4B 42 00 EB B5 00 00 00 00 00 00 00 E8 76 04  pKB.k5.......hv.
stsp commented 3 years ago

Signature is on 60, kernel is at 70 (unless in UMB).

andrewbird commented 3 years ago

Signature is on 60, kernel is at 70

This seems to be the content I'm looking for (irqstack.asm), but it's not useful to me.

0070:0000
segment _IRQTEXT                                                                

stack_size      dw      0                                                       
stack_top       dw      0                                                       
stack_offs      dw      0                                                       
stack_seg       dw      0                                                       
%macro irq 0                                                                    
                call    general_irq_service                                     
                dd      0                                                       
%endmacro                                                                       

%macro irqshare 1                                                               
                jmp     short %%1                                               
                dd      0                                                       
                dw      424bh                                                   
                db      0                                                       
                jmp     short retf%1                                            
                times 7 db 0                                                    
%%1:            call    general_irq_service_share                               
%endmacro                                                                       

nmi:            irq                                                             
irq_0:          irq                                                             
irq_1:          irq                                                             
irq_08:         irq                                                             
irq_0d:         irq                                                             

retf1:          retf                                                            
irq_2:          irqshare        1                                               
irq_3:          irqshare        1                                               
irq_4:          irqshare        1                                               
irq_5:          irqshare        1                                               
irq_6:          irqshare        1                                               
irq_0a:         irqshare        2                                               
irq_0b:         irqshare        2                                               
irq_0c:         irqshare        2                                               
irq_0e:         irqshare        2                                               
irq_0f:         irqshare        2                                               
retf2:          retf                                                            

                ; align to 100h to align _LOWTEXT for interrupt vectors         
                ; in kernel.asm                                                 
                times (100h - ($ - stack_size)) db 0                            

0070:0100 _intvec_table
stsp commented 3 years ago

This seems to be the content I'm looking for (irqstack.asm), but it's not useful to me.

How useful should it be?

andrewbird commented 3 years ago

This second paragraph from pg377 of Undocumented Dos suggests that it would normally be data from IO.SYS. I imagined that something in there might influence MFT that it's allocated to DOS even though the MCB chain starts there. undoc377

stsp commented 3 years ago

You can redefine DOS_PSP to 0x50 and see if those 0x70 address would change or remain.

andrewbird commented 3 years ago

I changed it in two places

ajb@polly:/clients/common/fdpp.git$ git diff
diff --git a/fdpp/makefile b/fdpp/makefile
index ec6c7341..4923f053 100644
--- a/fdpp/makefile
+++ b/fdpp/makefile
@@ -68,7 +68,7 @@ else
 %.elf %.map : $(DEPS_OF_ELF)
 endif
        $(LINK) -melf_i386 -static --build-id=sha1 -Map=$(TARGET).map -o $@ \
-               $(^:%.ld=-T%.ld) --defsym=DOS_PSP=0x60
+               $(^:%.ld=-T%.ld) --defsym=DOS_PSP=0x50
        chmod -x $@

 $(TARGET).elf.tmp: $(srcdir)/kernel.ld $(OBJS) $(PPOBJS) $(DOBJS)
diff --git a/hdr/mcb.h b/hdr/mcb.h
index 199b3ec8..0e549ff0 100644
--- a/hdr/mcb.h
+++ b/hdr/mcb.h
@@ -51,7 +51,7 @@ static BYTE *mcb_hRcsId =
 #define MCB_NORMAL      0x4d
 #define MCB_LAST        0x5a

-#define DOS_PSP         0x0060  /* 0x0008 What? seg 8 =0:0080 */
+#define DOS_PSP         0x0050  /* 0x0008 What? seg 8 =0:0080 */
 #define FREE_PSP        0

 #define MCB_SIZE(x)     ((((LONG)(x))<<4)+sizeof(mcb))

But it won't boot now and in the terminal I get

ERROR: bad dos helper function: AX=0x5044

and the boot screen itself Screenshot_2021-08-13_13-17-37

stsp commented 3 years ago

It should be enough to change it only in header. In makefile its there only to hack up the relocation table.

andrewbird commented 3 years ago

Interesting it works just changing the header. Here are the screenshots. I'm not sure what's going on. Screenshot_2021-08-13_14-48-04 Screenshot_2021-08-13_14-47-50 Screenshot_2021-08-13_14-47-24

stsp commented 3 years ago

In config.c:420 try to add back the changed range, like this: base_seg = DOS_PSP + (sizeof(psp) >> 4) + 0x10;

andrewbird commented 3 years ago 
diff --git a/hdr/mcb.h b/hdr/mcb.h
index 199b3ec8..0e549ff0 100644
--- a/hdr/mcb.h
+++ b/hdr/mcb.h
@@ -51,7 +51,7 @@ static BYTE *mcb_hRcsId =
 #define MCB_NORMAL      0x4d
 #define MCB_LAST        0x5a

-#define DOS_PSP         0x0060  /* 0x0008 What? seg 8 =0:0080 */
+#define DOS_PSP         0x0050  /* 0x0008 What? seg 8 =0:0080 */
 #define FREE_PSP        0

 #define MCB_SIZE(x)     ((((LONG)(x))<<4)+sizeof(mcb))
diff --git a/kernel/config.c b/kernel/config.c
index 6d80ee9f..22379860 100644
--- a/kernel/config.c
+++ b/kernel/config.c
@@ -417,7 +417,7 @@ void PreConfig2(void)

   base_seg = FP_SEG(AlignParagraph((BYTE FAR *) DynLast() + 0x0f));
   if (base_seg > FP_SEG(lpTop))
-    base_seg = DOS_PSP + (sizeof(psp) >> 4);
+    base_seg = DOS_PSP + (sizeof(psp) >> 4) + 0x10;
   LoL->_first_mcb = base_seg;

   if (Config.ebda2move)

Screenshot_2021-08-13_15-10-23 Screenshot_2021-08-13_15-10-03 Screenshot_2021-08-13_15-09-39

stsp commented 3 years ago 
dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0070:0000 0x0016 [FREE]
0087:0000 0x0034 [FREE]
00bc:0000 0x9f42 [FREE] (END)

Now for the sake of an experiment, you need to hack up with dosdebug the LoL->first_mcb to make it 0x87 (the second mcb from the dosdebug dumb above). After that, start mft and see what it says.

stsp commented 3 years ago

the LoL->first_mcb to make it 0x87

Likely 0x86

andrewbird commented 3 years ago 
dosdebug> d fab9:0026

fab9:0026 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06 40 FA  z.9zL.9zx.@zD.@z
fab9:0036 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00 00 00  ..m.9z..|C......
fab9:0046 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55 4C 20  .....C..|...NUL 
fab9:0056 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 73      ...........s
fab9:0066 00 01 00 03 03 00 00 10 0A FF FF 00 00 00 00 00  ..............
fab9:0076 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00 FF 00  ....R.9z.......
fab9:0086 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05 00 10  ...............
fab9:0096 92 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> d fab9:0024

fab9:0024 70 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  p.z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> m fab9:0024 0x86
Modified 1 byte(s) at 0x000fabb4 with value 0x86

dosdebug> d fab9:0024

fab9:0024 86 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  ..z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

But... Screenshot_2021-08-13_15-48-49

Did I mess up?

stsp commented 3 years ago

You didn't list mcbs and used the value from my dump. Also I am not sure if subtracting 1 is needed or not.

andrewbird commented 3 years ago 
dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0070:0000 0x0014 [FREE]
0085:0000 0x0034 [FREE]
00ba:0000 0x9f44 [FREE] (END)

ADDR(UMA) PARAS  OWNER
9fff:0000 ------ [LINK]
c300:0000 0x021c [DOS]
  => ADDR      PARAS TYPE USAGE
     c301:0000 0x0009 [D] Driver (EMS)
     c30b:0000 0x000a [D] Driver (EMUFS)
     c316:0000 0x0031 [D] Driver (CDROM)
     c348:0000 0x00b2 [F] Files
     c3fb:0000 0x008f [L] CDS Array
     c48b:0000 0x0080 [S] Stacks
     c50c:0000 0x0010 [B] Buffers
c51d:0000 0x000a [FREE]
c528:0000 0x0410 [COMMAND]
c939:0000 0x00e6 [COMMAND - Data]
ca20:0000 0x0018 [COMMAND - Environment]
ca39:0000 0x15c5 [FREE]
dfff:0000 ------ [LINK]
f000:0000 0x09ff [FREE] (END)

dosdebug> d fab9:0026

fab9:0026 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06 40 FA  z.9zL.9zx.@zD.@z
fab9:0036 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00 00 00  ..m.9z..|C......
fab9:0046 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55 4C 20  .....C..|...NUL 
fab9:0056 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 73      ...........s
fab9:0066 00 01 00 03 03 00 00 10 0A FF FF 00 00 00 00 00  ..............
fab9:0076 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00 FF 00  ....R.9z.......
fab9:0086 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05 00 10  ...............
fab9:0096 92 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> d fab9:0024

fab9:0024 70 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  p.z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> m fab9:0024 0x85
Modified 1 byte(s) at 0x000fabb4 with value 0x85

dosdebug> d fab9:0024

fab9:0024 85 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  ..z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

Screenshot_2021-08-13_16-28-58 Screenshot_2021-08-13_16-28-36 Screenshot_2021-08-13_16-28-21

stsp commented 3 years ago

Without any patches, right?

stsp commented 3 years ago

So clearly it reflects the first_mcb. Now this mysterious DOS data moved to 86-99, and we changed only 1 byte in LoL.

stsp commented 3 years ago

So maybe it thinks if there is no any DOS data, there might be some, 320bytes long. :)

andrewbird commented 3 years ago

I'm still running with these.

diff --git a/hdr/mcb.h b/hdr/mcb.h
index 199b3ec8..0e549ff0 100644
--- a/hdr/mcb.h
+++ b/hdr/mcb.h
@@ -51,7 +51,7 @@ static BYTE *mcb_hRcsId =
 #define MCB_NORMAL      0x4d
 #define MCB_LAST        0x5a

-#define DOS_PSP         0x0060  /* 0x0008 What? seg 8 =0:0080 */
+#define DOS_PSP         0x0050  /* 0x0008 What? seg 8 =0:0080 */
 #define FREE_PSP        0

 #define MCB_SIZE(x)     ((((LONG)(x))<<4)+sizeof(mcb))
diff --git a/kernel/config.c b/kernel/config.c
index 6d80ee9f..22379860 100644
--- a/kernel/config.c
+++ b/kernel/config.c
@@ -417,7 +417,7 @@ void PreConfig2(void)

   base_seg = FP_SEG(AlignParagraph((BYTE FAR *) DynLast() + 0x0f));
   if (base_seg > FP_SEG(lpTop))
-    base_seg = DOS_PSP + (sizeof(psp) >> 4);
+    base_seg = DOS_PSP + (sizeof(psp) >> 4) + 0x10;
   LoL->_first_mcb = base_seg;

   if (Config.ebda2move)

Should I try again clean?

stsp commented 3 years ago

Yes, and I suspect nothing will change.

stsp commented 3 years ago

It reflects first_mcb, its quite clear now.

andrewbird commented 3 years ago

Clean test

dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0070:0000 0x0014 [FREE]
0085:0000 0x0034 [FREE]
00ba:0000 0x9f44 [FREE] (END)

dosdebug> d fab9:0024

fab9:0024 70 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  p.z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> m fab9:0024 0x85
Modified 1 byte(s) at 0x000fabb4 with value 0x85

dosdebug> d fab9:0024

fab9:0024 85 00 7A 19 B9 FA CC 00 B9 FA F8 06 40 FA 44 06  ..z.9zL.9zx.@zD.
fab9:0034 40 FA 00 02 6D 00 B9 FA 00 00 FC C3 00 00 00 00  @z..m.9z..|C....
fab9:0044 00 00 05 1A 00 00 17 C3 04 80 7C 0E 81 0E 4E 55  .......C..|...NU
fab9:0054 4C 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00  L     ..........
fab9:0064 00 73 00 01 00 03 03 00 00 10 0A FF FF 00 00 00  .s............
fab9:0074 00 00 00 00 00 01 D2 14 B9 FA 00 00 00 00 00 00  ......R.9z......
fab9:0084 FF 00 00 00 00 00 00 00 FF 9F 00 00 00 05 00 05  ..............
fab9:0094 00 10 92 12 00 00 00 00 00 00 00 00 00 00 00 00  ................

dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0085:0000 0x0034 [FREE]
00ba:0000 0x9f44 [FREE] (END)

Screenshot_2021-08-13_17-03-57 Screenshot_2021-08-13_17-03-12 Screenshot_2021-08-13_17-03-02

So what creates that first free MCB and why is it that size?

stsp commented 3 years ago

But the size it displays, doesn't match the size of any MCB. So does it matter who created the first mcb?

andrewbird commented 3 years ago

Just curious.

What's going on in HMA the DOS/Overview seems to show a block at FFFF that extends to 0085, i.e. it wraps? Does DOS now it's loaded in the HMA need to be encased in an allocated MCB?

andrewbird commented 3 years ago

Edited last comment.

stsp commented 3 years ago

No, its not a wrap. HMA extends beyond ffff so let's say it have just skipped the leading 1 digit.

stsp commented 3 years ago

Or maybe it is a wrap indeed: 85 hints strongly to one, as the first one is 86. Plus, where did it got these numbers?? mcbs of dosdebug shows nothing in ffff area, so... it seems like we didn't unlink UMB again.

stsp commented 3 years ago

Well, UMB is unlinked, this can even be seen from an mcbs output. So I have no idea why does it display something above fa00. Maybe DOS DS is there at fa00? Or where could it get that number?

stsp commented 3 years ago

Also it shows HMA twice. But this fa00 puzzles me, as it is quite correct to show DOS there. Just unclear where it got that info if there is no MCB.

andrewbird commented 3 years ago

Plus, where did it got these numbers?? mcbs of dosdebug shows nothing in ffff area,

I don't really understand what the link MCBs do and I think that part of the dosdebug mcbs command was written by you. So since you wrote both that part of mcbs and fdpp it's pretty much guaranteed that they work well together. However perhaps the person that wrote mft has a slightly different understanding and there's some nuance that's missing. Reading the doc at http://helppc.netcore2k.net/table/mcb doesn't mention UMB, do you know if there is some authoritative reference?

andrewbird commented 3 years ago

Also I forgot to say that I wonder if wrapping is the reason that drdos's mem shows those > 0xffff MCB sizes.

stsp commented 3 years ago

Also I forgot to say that I wonder if wrapping is the reason

Please tell me what is the reason of wrapping first. There is no UMB at fa00 and above, this is clearly seen with dosdebug.

stsp commented 3 years ago

http://helppc.netcore2k.net/table/mcb doesn't mention UMB, do you know if there is some authoritative reference?

Good link:

- DOS 3.1+ the first memory block contains the DOS data segment
      ie., installable drivers, buffers, etc

This explains why do they expect devices at 0x70. Likely it explains also fa00 mystery, as perhaps we return DOS DS at fa00.

stsp commented 3 years ago

Can you try dosemu -Y and bypass DOSDATA=UMB please?

dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0070:0000 0x01d5 [DOS]
  => ADDR      PARAS TYPE USAGE
     0071:0000 0x00b2 [F] Files
     0124:0000 0x008f [L] CDS Array
     01b4:0000 0x0080 [S] Stacks
     0235:0000 0x0010 [B] Buffers
0246:0000 0x0017 [FREE]
025e:0000 0x0d7d [FREE]
0fdc:0000 0x9022 [FREE] (END)

ADDR(UMA) PARAS  OWNER
9fff:0000 ------ [LINK]
c300:0000 0x0047 [DOS]
  => ADDR      PARAS TYPE USAGE
     c301:0000 0x0009 [D] Driver (EMS)
     c30b:0000 0x000a [D] Driver (EMUFS)
     c316:0000 0x0031 [D] Driver (CDROM)
c348:0000 0x000b [FREE]
c354:0000 0x0410 [COMMAND]
c765:0000 0x00e6 [COMMAND - Data]
c84c:0000 0x0018 [COMMAND - Environment]
c865:0000 0x1799 [FREE]
dfff:0000 ------ [LINK]
f000:0000 0x09ff [FREE] (END)
andrewbird commented 3 years ago 
dosdebug> mcbs

ADDR(LOW) PARAS  OWNER
0070:0000 0x01d5 [DOS]
  => ADDR      PARAS TYPE USAGE
     0071:0000 0x00b2 [F] Files
     0124:0000 0x008f [L] CDS Array
     01b4:0000 0x0080 [S] Stacks
     0235:0000 0x0010 [B] Buffers
0246:0000 0x0014 [FREE]
025b:0000 0x0034 [FREE]
0290:0000 0x9d6e [FREE] (END)

ADDR(UMA) PARAS  OWNER
9fff:0000 ------ [LINK]
c300:0000 0x0047 [DOS]
  => ADDR      PARAS TYPE USAGE
     c301:0000 0x0009 [D] Driver (EMS)
     c30b:0000 0x000a [D] Driver (EMUFS)
     c316:0000 0x0031 [D] Driver (CDROM)
c348:0000 0x000a [FREE]
c353:0000 0x0410 [COMMAND]
c764:0000 0x00e6 [COMMAND - Data]
c84b:0000 0x0018 [COMMAND - Environment]
c864:0000 0x179a [FREE]
dfff:0000 ------ [LINK]
f000:0000 0x09ff [FREE] (END)
stsp commented 3 years ago

And? MFT?

andrewbird commented 3 years ago

Screenshot_2021-08-14_11-09-31 Screenshot_2021-08-14_11-09-21 Screenshot_2021-08-14_11-09-10

stsp commented 3 years ago

So the lower part is now consistent. As for fa00 - I guess it queries LOL and SDA and see them there. This has nothing to do with MCBs as there are none.

andrewbird commented 3 years ago

So if you do load dosdata into UMB, can you leave a small fake DOS MCB behind at 0070:0000 just to placate things that care?

stsp commented 3 years ago

dosdata=umb is not invented by fdpp or the patch in question. So you need to ask this question to freedos ppl. :)

stsp commented 3 years ago

Or another idea: try loadfix mft

andrewbird commented 3 years ago

with loadfix mft Screenshot_2021-08-14_18-27-24 Screenshot_2021-08-14_18-26-46 Screenshot_2021-08-14_18-26-32

with loadfix mem (drdos 7.03)

│    0:0000 │ -------- │  A0000h, 655,360 │ ------------- RAM --------------- │
├───────────┼──────────┼──────────────────┼───────────────────────────────────┤
│    0:0000 │ -------- │    400h,   1,024 │ Interrupt vectors                 │
│   40:0000 │ -------- │    100h,     256 │ ROM BIOS data area                │
│   50:0000 │      DOS │    200h,     512 │ DOS data area                     │
│   70:0000 │     BIOS │  FA490h,1,025,168 │ Device drivers                    │

│   70:0000 │  COMMAND │   F900h,  63,744 │ Data                              │
│ 1000:0000 │      MEM │    150h,     336 │ Environment                       │
│ 1015:0000 │      MEM │  15C20h,  89,120 │ Program                           │
│ 25D7:0000 │ -------- │  7A280h, 500,352 │ FREE                              │
│ 9FFF:0000 │      DOS │  23010h, 143,376 │ System                            │
├───────────┼──────────┼──────────────────┼───────────────────────────────────┤
│ C000:0000 │ -------- │   2800h,  10,240 │ ------------- ROM --------------- │
├───────────┼──────────┼──────────────────┼───────────────────────────────────┤
│ C300:0000 │      DOS │   21D0h,   8,656 │ System                            │
│ C302:0000 │ EMMXXXX0 │     90h,     144 │  DEVICE = installed device driver │
│ C30C:0000 │ EMUFS$   │     A0h,     160 │  DEVICE = installed device driver │
│ C317:0000 │ MSCD0001 │    310h,     784 │  DEVICE = installed device driver │
│ C349:0000 │      DOS │    9F6h,   2,550 │  HANDLES=, FCBS=  48 total blocks │
│ C51D:0000 │ -------- │     B0h,     176 │ FREE                              │
│ C528:0000 │  COMMAND │   4110h,  16,656 │ Program                           │
│ C939:0000 │  COMMAND │    E70h,   3,696 │ Data                              │
│ CA20:0000 │  COMMAND │    190h,     400 │ Environment                       │
Press Enter to continue...   
│ C939:0000 │  COMMAND │    E70h,   3,696 │ Data                              │
│ CA20:0000 │  COMMAND │    190h,     400 │ Environment                       │
│ CA39:0000 │ -------- │  15C60h,  89,184 │ FREE                              │
│ DFFF:0000 │      DOS │  10010h,  65,552 │ System                            │
├───────────┼──────────┼──────────────────┼───────────────────────────────────┤
│ E000:0000 │      EMS │  10000h,  65,536 │ ---------- EMS memory ----------- │
├───────────┼──────────┼──────────────────┼───────────────────────────────────┤
│ F000:0000 │ -------- │   A000h,  40,960 │ FREE                              │
│ FA40:0644 │ CON      │                  │  DEVICE = installed device driver │
│ FA40:0656 │ PRN      │                  │  DEVICE = installed device driver │
│ FA40:0668 │ AUX      │                  │  DEVICE = installed device driver │
│ FA40:067A │ LPT1     │                  │  DEVICE = installed device driver │
│ FA40:068C │ LPT2     │                  │  DEVICE = installed device driver │
│ FA40:069E │ LPT3     │                  │  DEVICE = installed device driver │
│ FA40:06B0 │ COM1     │                  │  DEVICE = installed device driver │
│ FA40:06C2 │ COM2     │                  │  DEVICE = installed device driver │
│ FA40:06D4 │ COM3     │                  │  DEVICE = installed device driver │
│ FA40:06E6 │ COM4     │                  │  DEVICE = installed device driver │
│ FA40:06F8 │ CLOCK$   │                  │  DEVICE = installed device driver │
│ FA40:070A │    A:-E: │                  │  DEVICE = installed device driver │
│ FAB9:0000 │      DOS │ FFF05B70h,4,293,942,128 │ System
     │
└───────────┴──────────┴──────────────────┴───────────────────────────────────┘

Press Enter to continue...
stsp commented 3 years ago

So loadfix only fixes mft. Perhaps it should create the dummy initial system UMB.

andrewbird commented 3 years ago

I wonder how small the dummy could be and still fix mft.

stsp commented 3 years ago

But mft already fixed with loadfix.

andrewbird commented 3 years ago

Oh I thought you were just suggesting loadfix as proof of concept for adding an initial MCB dummy. Thanks anyway.