Chuck(G)
25k Member
I suspect that he's setting EXM to 0.
0000 - 00 52 4F 4F 54 5F 43 50 4D 49 4D 47 03 00 00 80 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 - +ROOT_CPMIMG++++++++++++++++++++
0000 C3 03 FC 00 0C C3 00 F0 00 00 00 00 00 00 00 00 ├+³++├+++++++++
0010 00 00 00 00 00 00 00 00 C3 7D D4 00 00 00 00 00 ++++++++├}È+++++
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ++++++++++++++++
0030 C3 69 D1 00 00 00 00 00 C3 BC D3 00 00 00 00 00 ├iÐ+++++├╝Ë+++++
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ++++++++++++++++
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 44 53 4B +++++++++++++DSK
0060 20 20 20 20 20 20 20 20 00 00 00 00 00 20 20 20 +++++
0070 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 ++++++++
0080 05 20 44 53 4B 01 20 44 53 4B 01 4D 00 2B 00 01 + DSK+ DSK+M++++
0090 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ×+++++++++++++++
00A0 44 5A 45 58 44 4F 43 20 20 43 4F 4D 00 0B 00 44 DZEXDOC COM+++D
00B0 E2 00 27 01 28 01 29 01 2A 01 00 00 00 00 00 00 Ô+'+(+)+*+++++++
00C0 00 43 43 42 41 53 49 43 20 43 4F 4D 00 00 00 7C +CCBASIC COM+++|
00D0 1D 01 1E 01 1F 01 20 01 21 01 22 01 23 01 24 01 ++++++ +!+"+#+$+
00E0 00 53 54 41 54 20 20 20 20 43 4F 4D 00 01 00 29 +STAT COM+++)
00F0 27 00 28 00 29 00 00 00 00 00 00 00 00 00 00 00 '+(+)+++++++++++
Is it a combination of the EX and RC that is used to track record then, and that there is no extent with EX=0? ( except when the extent is not full ) - Am I understanding that correctly?Based on the DPB data you showed (which does not appear to match how your custom BDOS views things) the first file in your example directory data should take up only one entry and look like:
Code:0000 - 00 52 4F 4F 54 5F 43 50 4D 49 4D 47 03 00 00 80 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 - +ROOT_CPMIMG++++++++++++++++++++
Regarding the STAT DSK: problem, it may be the case that something is corrupting the variables (memory) in the STAT memory image. Does your BDOS switch stacks on entry? If not, it could be overflowing the STAT stack and corrupting memory.
I suspect that he's setting EXM to 0.
That's what I'm having trouble reasoning-out. The only reasons I can think of that STAT would be reading beyond the end of the commandline are: The commandline was malformed by the CCP; the commandline buffer was corrupted later; STAT variables were corrupted to cause reading of invalid data.Nope, it wasn't the stack. Having watched the code execute, it seems that it's related to the STAT application reading beyond the character buffer at 0080 - So it's reading positions that don't exist... I'm still not sure why.
Hi Doug,That's what I'm having trouble reasoning-out. The only reasons I can think of that STAT would be reading beyond the end of the commandline are: The commandline was malformed by the CCP; the commandline buffer was corrupted later; STAT variables were corrupted to cause reading of invalid data.
If you're able to watch the code execute, where (at what address) is STAT reading the command byte that causes the "Bad Delimiter" and what byte value did it read?
0080: N C1 C2 ... CN \0
0080 05 20 61 62 63 64 0D 00
The CCP does not place a CR in the command buffer. only a NUL terminator.The command-line buffer 0080h is 80h =- number of characters in the command tail, followed by the command tail, followed by a carriage return (0Dh). Note that the first character in the buffer is a space and the return at the end isn't counted in the count at 80h. e.g.
Some utilities use the byte count; others scan for the return.Code:0080 05 20 61 62 63 64 0D 00
A>cmdline dsk:
0000 C3 03 EB A9 00 C3 06 DD C3 F6 F3 76 5E 22 D0 64
0010 FB C9 70 00 1A C3 67 01 C3 7D F5 C3 F2 09 97 0F
0020 C3 38 F2 0F 06 1C 3E F1 FB C9 20 C3 09 02 3F 00
0030 FB C9 20 00 00 00 00 00 FB C9 20 C3 21 03 C3 26
0040 00 11 22 01 C3 FC 09 C3 60 78 C3 25 0A F1 00 EB
0050 D1 E1 DD E1 FD E1 D9 08 C1 78 ED 47 00 44 53 4B
0060 20 20 20 20 20 20 20 20 00 00 00 02 00 20 20 20
0070 20 20 20 20 20 20 20 20 00 00 00 00 00 FD E5 DD
0080 05 20 44 53 4B 3A 00 E5 E5 E5 E5 E5 E5 E5 E5 E5
0090 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00A0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00B0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00C0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00D0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00E0 21 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00F0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
A>cmdline a: dsk:
0000 C3 03 EB A9 00 C3 06 DD C3 F6 F3 FD BE 22 D0 64
0010 FB C9 70 00 1A C3 67 01 C3 7D F5 C3 F2 09 97 0F
0020 C3 38 F2 0E 05 1C 3E F1 FB C9 20 C3 09 02 3F 00
0030 FB C9 20 00 00 00 00 00 FB C9 20 C3 21 03 C3 26
0040 00 11 22 01 C3 FC 09 C3 60 78 C3 25 0A F1 00 EB
0050 D1 E1 DD E1 FD E1 D9 08 C1 78 ED 47 01 20 20 20
0060 20 20 20 20 20 20 20 20 00 00 00 02 00 44 53 4B
0070 20 20 20 20 20 20 20 20 00 00 00 00 00 FD E5 DD
0080 08 20 41 3A 20 44 53 4B 3A 00 E5 E5 E5 E5 E5 E5
0090 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00A0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00B0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00C0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00D0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00E0 21 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
00F0 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
A>
If there's a CR in the buffer, that will trigger the "Bad Delimiter" error in STAT.Could be that my programs stuck a CR at the end for uniformity (with DOS) sake. I can't recall--this was about 40 years ago. In any case, that final character isn't counted in the tail count at 80h.
Yes, STAT does not use the length byte, it expects the NUL terminator. Many other programs are written the same.Even if it's not in the tail count?