The block of code surrounding line #15308 in src\mp.pas appears to detect phase errors during the the assembly process. How safe is it to change the $120 to $1 so that there is no deviance between the current assembly pass and the previous pass? Is there a possibility Mads could get stuck in an endless loop flip/flopping an address calculation?
|
asm65(#9'ift (?adr < ?old_adr) && (?old_adr - ?adr < $120)'); |
I'm trying to output to a PGZ file format but it requires the known length of Mads' final .OBX file to be used in the file header written before the object file. I have all the extra code in place and inserted a new line after the Fastmul detection, line #15042, asm65('F256BINARYSIZE'#9'= * - CODEORIGIN');. However, with the $120 value in line #15308 the value is off by several bytes for my game. Changing the value to $1 resulted in an extra pass and the correct size calculation for a working PGZ file.
The block of code surrounding line #15308 in src\mp.pas appears to detect phase errors during the the assembly process. How safe is it to change the $120 to $1 so that there is no deviance between the current assembly pass and the previous pass? Is there a possibility Mads could get stuck in an endless loop flip/flopping an address calculation?
Mad-Pascal/src/mp.pas
Line 15308 in 65e009f
I'm trying to output to a PGZ file format but it requires the known length of Mads' final .OBX file to be used in the file header written before the object file. I have all the extra code in place and inserted a new line after the Fastmul detection, line #15042,
asm65('F256BINARYSIZE'#9'= * - CODEORIGIN');. However, with the $120 value in line #15308 the value is off by several bytes for my game. Changing the value to $1 resulted in an extra pass and the correct size calculation for a working PGZ file.