ecm 2026-04s

[ecm-pushbx]

Add sort-as IDs to 2F.4310 entries, so that the XMS entrypoint with all its subfunctions/tables comes first.

Update Contributing.md. I have two questions regarding these updates, please reply before merging:

All contents are copied exactly into the LST file during compilation, except that leading and trailing empty lines are skipped.

Is this accurate?

Note that all used flags must be listed here again because the header Flag fields do not affect the compiled LST file.

Ditto. Also, if it is, does makelist check that the Flag: entries exactly match the flags listed in the summary base line? If not perhaps it could do so.

[ecm-pushbx]

Added sort-as IDs to 21.71 entries.

[ecm-pushbx]

After this there's a blank and a dash and another blank. The remainder of the line is the Name of the entry. It may start with one or multiple component or system identifiers separated from the remaining Name by another dash each. Words other than proper nouns or identifiers are typically in all-caps.

This is mostly conjecture. Also, examples like indeed 21.4C use terms like - "EXIT" - as a dash-separated identifier. So maybe I should tweak the wording to be more generic than "component or system identifiers".

[shidel]

Add sort-as IDs to 2F.4310 entries, so that the XMS entrypoint with all its subfunctions/tables comes first.

Update Contributing.md. I have two questions regarding these updates, please reply before merging:

All contents are copied exactly into the LST file during compilation, except that leading and trailing empty lines are skipped.

Is this accurate?

Technically, no.

Along with trimming the blank lines, all text is standardized to use CRLF line endings regardless of what is used in the file.

Otherwise, yes at present.

However at some point, I think I should add a couple other filters when processing those entries. For example, tab expansion into spaces, trim trailing white-space, compress extra white-space in the title and possibly standardize the occurrence of when blank lines are present. I am fairly certain I have seen that sometimes things like Returns: and SeeAlso: are preceded by a blank line, sometimes not.

Note that all used flags must be listed here again because the header Flag fields do not affect the compiled LST file.

Ditto. Also, if it is, does makelist check that the Flag: entries exactly match the flags listed in the summary base line? If not perhaps it could do so.

Well, the Flag: fields in the header are not used for anything at this time. They are not part of the Section ID or anything like that. For now, they are simply an FYI.

But, I do intend to use those fields to verify against the information in the Title. I just have not added that to makelist at present.

I also intend to have it verify the Category character entry as well.

Notes:

• Both Flag and Category fields in the header can use either n/a or a '-' to represent not defined.
• References to see a table within the text are (see #ID). See may or may not be capitalized. The ID is the table number which may have a letter prefix.
• Some interrupts use registers other than A[XHL]. Some use CX, BX etc. Mostly these are rare and obsure. But, running grep -i '\-\-\-\-\-\-\-\-' INTERRUP.* you can see several towards the end of the list.

[ecm-pushbx]

Add sort-as IDs to 2F.4310 entries, so that the XMS entrypoint with all its subfunctions/tables comes first.
Update Contributing.md. I have two questions regarding these updates, please reply before merging:

All contents are copied exactly into the LST file during compilation, except that leading and trailing empty lines are skipped.

Is this accurate?

Technically, no.

Along with trimming the blank lines, all text is standardized to use CRLF line endings regardless of what is used in the file.

Otherwise, yes at present.

Oh yeah, I did think of that earlier but forgot to add it.

However at some point, I think I should add a couple other filters when processing those entries. For example, tab expansion into spaces,

Please only with a special option. Besides, coreutils expand can do this with the compiled list so maybe no need for adding it to makelist.

trim trailing white-space, compress extra white-space in the title and possibly standardize the occurrence of when blank lines are present. I am fairly certain I have seen that sometimes things like Returns: and SeeAlso: are preceded by a blank line, sometimes not.

Maybe, but I didn't see any scanning the int 21h list some.

Note that all used flags must be listed here again because the header Flag fields do not affect the compiled LST file.

Ditto. Also, if it is, does makelist check that the Flag: entries exactly match the flags listed in the summary base line? If not perhaps it could do so.

Well, the Flag: fields in the header are not used for anything at this time.

Yes, that matches what I wanted to express here.

They are not part of the Section ID or anything like that. For now, they are simply an FYI.

But, I do intend to use those fields to verify against the information in the Title. I just have not added that to makelist at present.

Sounds good.

I also intend to have it verify the Category character entry as well.

What do you mean by verify? It doesn't occur redundantly like the flags.

Notes:

* Both _Flag_ and _Category_ fields in the header can use either `n/a` or a '-' to represent _not defined_.

_Category.txt lists the last (not defined) entry with an asterisk instead. But users use a dash.

* References to _see a table_ within the text are `(see #ID)`. _See_ may or may not be capitalized. The _ID_ is the table number which may have a letter prefix.

First table number byte is alphanumeric actually. The total "number" is always a hash sign followed by 5 bytes, so I wouldn't call the letter a "prefix". Makes me think it should have 5 digits after a letter, rather than 4.

Also using the scriptlet ~/proj/list$ grep '#[A-Z0-9][0-9]{4}' -E source/Interrupt\ List/ -R --color=always | grep -v 'see |SeeAlso' -Ei we can find a few entries without see . Many more if you include SeeAlso: lines.

* Some interrupts use registers other than _A[XHL]_. Some use CX, BX etc. Mostly these are rare and obsure. But, running `grep -i '\-\-\-\-\-\-\-\-' INTERRUP.*` you can see several towards the end of the list.

INTs EF, E0, 94, 80, 7A, 6F, 65, 60 from what I found scanning the result. But you can still make references that will be found by IntList, you just have to include INT xx/ before the register. Will have to check whether any SeeAlso lines include register-only references with a non-accu reg.

[ecm-pushbx]

Three minor fix commits added. I amended the Contributing.md commit with a statement that linebreaks are normalised to CR LF.

[andrewbird]

BTW you could force CRLF for everything in the "source" folder and its subfolders
by adding source/** text eol=crlf to a .gitattributes file then do

git add --renormalize .
git commit -m "Normalize line endings to CRLF"

[ecm-pushbx]

There are a number of SeeAlso lines with non-accu registers, see ~/proj/list$ grep -Ei '^\s*seealso:.*[^\/](E?[BCD][XHL]|E?[SD]I|E?[SB]P)=' TheList/INTERRUP.LST

[ecm-pushbx]

Force pushed. Main update commit now lists flags and categories are case-sensitive, and additional commit references https://hg.pushbx.org/ecm/tractest/rev/1396393e2554 to state it allows reg-only non-accu register references in SeeAlso lines.

[ecm-pushbx]

Force pushed again. Add mentions of the maximum line width (fewer than 80 columns) and tab stop width.

[ecm-pushbx]

Unless any of you have more comments it can be merged now from my side.

[ecm-pushbx]

I am fairly certain I have seen that sometimes things like Returns: and SeeAlso: are preceded by a blank line, sometimes not.

You did this! d3b3ff0

Haven't seen this anywhere else yet.

[shidel]

I am fairly certain I have seen that sometimes things like Returns: and SeeAlso: are preceded by a blank line, sometimes not.

You did this! d3b3ff0

Haven't seen this anywhere else yet.

Well... Since that is the only place you found with a blank line preceding those "tags", I probably should not have inserted them. I will remove those blank lines in a couple minutes so it conforms with all other entries.

On the plus side, at least I was correct in thinking I saw that used somewhere. It just happened to be by me once. LOL.

[ecm-pushbx]

To be fair, one of the table references without a "see" was also added by me.

[ecm-pushbx]

To be fair, one of the table references without a "see" was also added by me.

It actually has a "see", but it was wordwrapped across a linebreak:

TheList/source/Interrupt List/INT 21 DOS Function Calls/INT 214C DOS 2 EXIT TERMINATE WITH RETURN CODE.txt

Lines 15 to 16 in c107178

	reads the SS:SP stack of the parent from the parent's PSP (see
	#01378 [offset 2Eh] at AH=26h) and returns on that user stack,

Regardless, my algorithm doesn't seem to find any false positives even matching without "see".

[ecm-pushbx]

By the way, did you invent the "MORE:" section name? I just used Notes: and BUGS: for everything I added.

[shidel]

BTW you could force CRLF for everything in the "source" folder and its subfolders by adding source/** text eol=crlf to a .gitattributes file then do

git add --renormalize .
git commit -m "Normalize line endings to CRLF"

Thanks for the tip @andrewbird. However since I tend to run makelist locally alot, the program still should perform this function. While implementing that .gitattributes would likely be fine, I would like to verify it does not mangle CP 437 ASCII characters above #127. I have seen a lot of issues regarding Code page text in the web interface.

[shidel]

By the way, did you invent the "MORE:" section name? I just used Notes: and BUGS: for everything I added.

Yes. That was a sort-of hold over from before The List was started and my RBILtoHTML was splicing things into the entries on the fly. I wanted to distinguish such things from the original notes. But, that is no longer necessary. We can drop "MORE:" completely. When I remove those blank lines, it will just become an additional "Note:" section.

Furthermore, do we really need Note: and Notes: along with BUG: and BUGS?

[ecm-pushbx]

Furthermore, do we really need Note: and Notes: along with BUG: and BUGS?

I've been wondering about that. Should be fairly easy to replace automatically, just match BUG:<TAB> and Note:<TAB>. Do you want to do that?

[shidel]

I also intend to have it verify the Category character entry as well.

What do you mean by verify? It doesn't occur redundantly like the flags.

At present, it can only have one category field or it will throw an error.
It will accept n/a or a single character. Otherwise, it simply complains and continues.
That complaint should be and error in --cicd mode.

Also, I was going to verify that the character was in the list of Categories (or n/a, or -).
While nearly all upper and lower case letters are used in the Categories List, this would prevent garbage entries like 5 or á from being used.

Notes:

• Both Flag and Category fields in the header can use either n/a or a '-' to represent not defined.

_Category.txt lists the last (not defined) entry with an asterisk instead. But users use a dash.

Verification of flags would also check for duplicated flags, compare against the title (base description) and ensure they are actually in the Flags list.

• References to see a table within the text are (see #ID). See may or may not be capitalized. The ID is the table number which may have a letter prefix.

First table number byte is alphanumeric actually. The total "number" is always a hash sign followed by 5 bytes, so I wouldn't call the letter a "prefix". Makes me think it should have 5 digits after a letter, rather than 4.

True. But, I always thought of it this way... There are a Lot of tables for the INTERRUP.LST so it has a 5 digit number. Other LST files have far fewer tables and use a 4 digit number. Also, these tables in other LST files start with a letter that corresponds to the LST file in some way. I think there are occasionally references in one LST file to a table in a different LST file. However, that may only be the case in the TABLES.LST file. So, I just always thought of it as a single letter prefix. :-)

Furthermore, do we really need Note: and Notes: along with BUG: and BUGS?

I've been wondering about that. Should be fairly easy to replace automatically, just match BUG:<TAB> and Note:<TAB>. Do you want to do that?

That sounds like a good idea to me. Also, as we come across big blobs of notes or bugs, we can break them into individual Note: and Bug: sections in the files. I think such a change would improve readability.

[shidel]

Also, sometimes those section tags are indented like this:
(using ./makelist -m 720)

INTERRUP.H-----------F705-------------------------------
INTERRUP.H-INT F7 - FSBBS 2.0 - TIMER FUNCTIONS
INTERRUP.H-        AH = 05h
INTERRUP.H-        AL = function
INTERRUP.H-	           00h get time remaining
INTERRUP.H:                Return: DX = number of minutes remaining
INTERRUP.H-            01h get current time
INTERRUP.H:                Return: DS:DX -> 8-character time string

And I need to look at the ones like these:

INTERRUP.F:              Return: CX = status (0000h,000Bh,0014h) (see #02739)
INTERRUP.F:      Return: AX = status (see #02860)
INTERRUP.F:              Return: DF clear
INTERRUP.F:              Return: DF clear
INTERRUP.G:Return:       AH = 00h always???
INTERRUP.G:Return:       BX, CX, DI, ES may be destroyed