As it's not a problems of DOSBox, the general idea is to ask Infocom or other developers of text games. Different hardware and its settings have different limits and compatibility (try to increase free conventional memory, for example).

Are you writing outside some buffers maybe ? That would be my first guess if you end up with a broken MCB chain.

Booting MS-DOS in DOSBox and checking whether the program still crashes might be a good idea for diagnostic purposes.

dgriffi wrote:

...

... woah, you're following me around the Internet! 🤣

1dos mem corrupt, first_mcb=0277
2prev 0899:0000|4D 9A 08 80 64 E9 91 03 46 52 4F 54 5A 00 00 M?.?d??.FROTZ...
3notM26D1A:0000|58 60 1D EA 23 25 FC A5 7B 54 1E 70 23 f2 6B X`..?#%??{T.p#?k
4
5PANIC: before 4a: MCB chain corrupted
6System halted

Don't know if it's any help, but the cryptic "before 4a" message means that the crash occured at the start of the int21/ah=4a handler. "prev" is the last good block, and "notMZ" is the bad block (where the first byte is neither 'M' or 'Z').
The failing address (26D1A:0000) strikes me as odd. I don't believe int21 has any business dealing with memory all the way up there. This would imply that the previous block, occupied by FROTZ, is impossibly large.

Bytes 3 and 4 (80 64) are the block size, and 0889+6480+1=6D0A, not 26D1A. (but then I have no idea if that's the right way to calculate it)

jwt27 wrote:

Bytes 3 and 4 (80 64) are the block size, and 0889+6480+1=6D0A, not 26D1A. (but then I have no idea if that's the right way to calculate it)

That's the correct way to calculate the next MCB segment, but you started with 0889 instead of 0899. The "2" may be a mis-transcribed "Z", if the message should indeed say "notMZ".

Is this error message from FreeDOS?

ripsaw8080 wrote:

jwt27 wrote:

Bytes 3 and 4 (80 64) are the block size, and 0889+6480+1=6D0A, not 26D1A. (but then I have no idea if that's the right way to calculate it)

That's the correct way to calculate the next MCB segment, but you started with 0889 instead of 0899. The "2" may be a mis-transcribed "Z", if the message should indeed say "notMZ".

Oops, you're right. In that case, the address would be correct, and FROTZ may be writing beyond its own memory space.

ripsaw8080 wrote:

Is this error message from FreeDOS?

Yes.

1/*
2 * Check the MCB chain for allocation corruption
3 */
4COUNT DosMemCheck(void)
5{
6  REG mcb FAR *p;
7  REG mcb FAR *pprev = 0;
8
9  /* Initialize                                           */
10  p = para2far(first_mcb);
11
12  /* Search through memory blocks                         */
13  while (p->m_type != MCB_LAST) /* not all MCBs touched */
14  {
15    /* check for corruption                         */
16    if (p->m_type != MCB_NORMAL)
17    {
18      put_string("dos mem corrupt, first_mcb=");
19      put_unsigned(first_mcb, 16, 4);
20      hexd("\nprev ", pprev, 16);
21      hexd("notMZ", p, 16);
22      return DE_MCBDESTRY;
23    }
24
25    /* not corrupted - but not end, bump the pointer */
26    pprev = p;
27    p = nxtMCB(p);
28  }
29  return SUCCESS;
30}

1      /* Set memory block size */
2    case 0x4a:
3        if (DosMemCheck() != SUCCESS)
4          panic("before 4a: MCB chain corrupted");
5
6      if ((rc = DosMemChange(lr.ES, lr.BX, &lr.BX)) < 0)
7      {
8#if 0
9        if (cu_psp == lr.ES)
10        {
11          psp FAR *p = MK_FP(cu_psp, 0);
12          p->ps_size = lr.BX + cu_psp;
13        }
14#endif
15        if (DosMemCheck() != SUCCESS)
16          panic("after 4a: MCB chain corrupted");
17        goto error_exit;
18      }
19      lr.AX = lr.ES; /* Undocumented MS-DOS behaviour expected by BRUN45! */
20      break;

Does dosbox perform this MCB consistency check on int21/4a too?

jwt27 wrote:

Does dosbox perform this MCB consistency check on int21/4a too?

DOSBox 0.74 usually hangs in an infinite loop on the next memory block operation after the MCB chain is broken. SVN has an error exit instead of the hang. So, to answer your question, 0.74: sorta, SVN: yes.