This file is valuable for crafting (raw) files, with form@fix. First frame this.
// \F "fixRaw.htm" \\this file
The MSDOS .com files almost always suppose a two-byte int format. But if your form@fix processor is not the fixDX, the default int width may be something else. For fixWin, that is 4-bytes. Therefore, what we would like to have first, is the certainty of what we suppose. Set the format-width, as well as the remz-offset, manually.
\r rOffset0 \r fixRaw
For scratch work, not written to the file but useful toward that, we may allocate the piece of memory beyond a point. Set that at a point beyond the length of your final file, for the two portions not to overlap. I like to set that at 0x5000 (that is, 20480 bytes). Modify this (to less, or more), depending on the specific application.
\a 0x5000 \\toward form@fix@RunTime_Max
fix.exe for MSDOS is limited to segment width (64K, in total). The 0x5000 is a good rule-of-thumb, within 64K. If your file/work needs a lot, then choose the fix.exe for Win32, for 0xAF0000 in total -- extendable, trivially.
For byte data-or-remz,
\r = \r =1 \\the platform =1 \r attr= \\byte-width, although flexible for the future \\r+ is 0 \a+1 4 \\width is 1 \a+1 1 1 \a+1 3
For padding from byte-width to int-width
\r fiz \*= 1 0 \\fill with zeroes, if positive \r -fiz \*= 1 0xFF \\fill with 0xFF to sign-extend, if negative
For word data-or-remz,
\r =2 \\the platform is =2 \\r+ is 0 \a+1 4 \\width is 2 \*= 2 0 0 0
For dword data-or-remz,
\r =4 \\the platform is =4 \\r+ is 0 \a+1 4 \\width is 4 \*= 4 0 0 0
In case, we would refer to the int-width of the fix.exe that is processing this file,
//ARZ.Zero, the [platform.r+]-free offset. // Purely, the 0th byte of ARZ, that is. \r RZ \r =. \\the default platform-format is this. \\r+ is 0 \a+1 4 \\width is 0 \a+1 4
This default format is useful for a remz (or, remz-list) like for frag. Good, because otherwise frag would have to acept only a single width for all platforms. For coding in fixDX, that is a waste to accommodate the double-width of Win32. Not to mention that, for a future support of Win64, the thing would get totally problematic.
A few run-time only conveniences. Although referrable while fixing the .com, do not refer to such a run-time-only remz, from within your .com, because that would be what is known as dangling-pointer problem.
\r [?] \'?' \*= 0 \\frag for not returning a result
\r {/} \*=4 0 \\empty set
f0 is only a fancier name, to fill with zeroes, at byte-width, e.g: with \a+f0 20 to fill with 20 zeroes. i.e: "1" is the fill-width, not the filler-value. Filler is zero, if not explicitly specified.
\r f0 \*=4 1
A few for conveniently referring to a macro type. Macro-flag is 0x80. The letter 'F' plus 0x80 is 0xC6.
\r mid80.macro \a 0xD0 \r Pm \\Petri transition \a 0xD5 \r Um \\UCLA control-node \a 0xC6 \r Fm \\Nutt F-transition \a 0xCA \r Jm \\Nutt J-transition \a 0xD4 \r Tm \\Nutt T-transition \a 0xD8 \r Xm \\Nutt X-transition \a 0xD9 \r Ym \\Nutt Y-transition .\a 0xCB \r Km \a 0xC4 \r Dm \\Danthine mod for X-transition \a 0xE2 \r bm \\binary loc \a 0xF0 \r pm \\Petri loc \a mid80.macro \r- mid80.macro
\r width(formal) \*RZ 0 0 0 0 0 0 0 0 0 0 \* width(formal)\-f \a width(formal) \a+ 1 \*= 0 0 0 \\pad width(formal) to four-bytes
For a frozen@mid80 style fragging, for form@fix, we may think a single-transition "net." This T-transition is running the frag (predicate) that is to follow immediately after the "\F@ @FragFun" statement.
\r @FragFun
\'\\r .fm'
//allocating the formal-list width, for returning-to afterward
\'\\a+ width(formal)'
\'\\r b1\\\'b\'\\*= 1\\*attr= 0'
\'\\r b2\\\'b\'\\*= 2\\*attr= 0'
\'\\r .L'
\'\\*RZ b1 b2 0'
\'\\r .M0'
\'\\*RZ b1\\*= 1'
\'\\*RZ 0'
\'\\r a1'
\'\\\'T\'\\*= 1' \\T1
\'\\*RZ b1 b2'
\'\\*RZ {/}' \\ immediately finishing
\'\\r .t\\*RZ 0' \\ activity/transition procedure
\'\\r .A'
\'\\*RZ a1 0'
\'\\r .z'
\'\\a .fm'
\'\\*RZ .A {/} {/} .M0 .L .L {/} {/}' \\formal net.
\'\\a .t\\*RZ .z'
\'\\a .z'
\'\\r/ .fm'
\'\\r- .fm'
\*= 0
\r form@fix@RunTime_Max \\to keep in mind, the high-ARZ remz
\a 0