Repository navigation
ecm int2F.1261 error fix - #274
ecm-pushbx wants to merge 2 commits into
Conversation
|
Some more context: If the debugger init finds that 2F.1261 isn't supported it falls back to a heuristic to find the first UMCB, which requires toggling the UMB link and walking the MCB chain until the first UMCB is found. The first UMCB is typically at segment 9FFFh if a full 640 KiB are available as Low Memory Area to DOS. So the first UMCB itself is actually located at the end of the LMA. But if its size is not zero, then the area that it covers is at the beginning of the UMA. |
|
@ecm-pushbx this looks reasonable. Did you intend to update the country submodule (not necessarily a bad thing) in this commit? |
lDOS programs such as lDebug's init call int 2Fh function 1261h to query for the first UMCB. To ensure the function is supported, the caller enters the int 2Fh handler with CY (Carry Flag set) and only trusts the result if it is NC (Carry Flag clear) and AX is returned as none of 0FFFFh, 0, nor 1. The condition removed by this commit would handle unknown functions above 31h as if they were supported: Flags NC and AX not set to any error code value. This clashes with MS-DOS and lMS-DOS which will both set CY, AX = 1 for unsupported 12h subfunctions. Function 61h is supported by lMS-DOS but not by MS-DOS. Using this commit, the lDOS programs will detect that function 1261h is not supported. The other change is to set AX = 1 on the unknown function, which subfunctions below-or-equal 31h previously did not. The second reference indicates that MS-DOS v4 (and lMS-DOS) sets AX = 1 for subfunctions 30h and 31h. (DTab is defined in ms_table.nas and does not contain subfunctions past 47 = 2Fh.) Reference: https://hg.pushbx.org/ecm/ldebug/file/7c168a97c52e/source/init.asm#l5266 Reference: https://hg.pushbx.org/ecm/msdos4/file/3aeedd765a59/src/DOS/ms_code.nas#l655
cf4526d to
12f4f7d
Compare
No, I didn't. Thanks for notifying me. Fought with git until I was able to undo that. |
Noticed an error while running a recent lDebug: The command
dirml 21would not display the MCB name for an int 21h handler with CS = 0F001h in a self-owned UMCB (at segment 0F000h), instead indicating "system in UMA". This was because the shortcut call to determine the first UMCB apparently succeeded on recent FreeDOS kernels, while it wasn't actually supported. Thedirmlcommand doesn't enable the UMB link, rather determining that a 'Z' MCB is the last LMCB (and should thus be proceeded past) if it points to the known first UMCB.