It's the mapm m_apm_pow() function, specifically the second ("decimal_places") argument. If it's set to fewer characters than the result, you'll get rounding errors. (TCC is already adding 20 digits on its own, which is why you didn't see it until you got a > 30 digit result.)
Maybe it's a bug, or a lack of documentation, (or me) but when computing base**exponent, (MAPM::pow() or m_apm_pow()) and base>1, "decimal_places" actually specifies the number of significant digits (which certainly includes what's to the left of the decimal point) and not the number of places after the decimal point.
If you add the number below (instead of 20) to the desired number of decimal places (when base>1) you should be safe. If you wish, I'll translate it into the non-C++ version (i.e., using m_apm_func() instead of MAPM::func()).
// this is before the decimal point; add the desired number of decimal places
INT extra (MAPM base, MAPM exponent)
MAPM u, mm1 = MM_One;
u = ++((base.log10() * exponent).ceil());
CHAR *szdp = (CHAR*) AllocMem(u.significant_digits()+1);
x = atoi(szdp);
I reproduced (and fixed, as above) the problem with 2**103. But I don't need the fix for .5**(-103), which is the same number. @EVAL, however, has the same problem with both.