artrag Posted March 3, 2019 Share Posted March 3, 2019 Ok, but it is using hw multiplications few lines later for 192 EB86:F 02BC 00C0 MVII #192,R4 EB88:F 0241 9F86 MVO R1,40838 EB8A:F 0244 9F87 MVO R4,40839 EB8C:F 0281 9F8E MVI 40846,R1 Is it faster here? Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 Ok, but it is using hw multiplications few lines later for 192 EB86:F 02BC 00C0 MVII #192,R4 EB88:F 0241 9F86 MVO R1,40838 EB8A:F 0244 9F87 MVO R4,40839 EB8C:F 0281 9F8E MVI 40846,R1 Is it faster here? There's no MULT macro for 192. They stop at 127. (See intybasic_prologue.asm for all of them.) That said, if you used the "MULT 24" macro and then shifted left by 3 (SLL R0,2; SLL R0, 1), it would be 6 cycles slower, but still 1 word shorter. The fastest multiply-by-192 I can think of off the top of my head: . MOVR R0, R4 ; 6 \ ADDR R0, R4 ; 6 |- Multiply by 3 ADDR R4, R0 ; 6 / SLL R0, 2 ; 8 \ SLL R0, 2 ; 8 |- Multiply by 64. (192 = 3*64) SLL R0, 2 ; 8 / ;-- ;42 . That's 2 cycles longer than the JLP accelerator, but 2 words shorter. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 (edited) ok. But, then, where is the problem with v140? I've just tested v141 and play.music is fixed, but the other problem about define varptr is still there Edited March 3, 2019 by artrag Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 ok. But, then, where is the problem with v140? I thought there was. If it's greater than 127, it inserts a SLL first, halves the constant, and processes it through the macro: IF (%const% > $7F) _mul.const QSET (_mul.const SHR 1) SLL %reg%, 1 ENDI Or did that change in the latest IntyBASIC? Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 I was on a wrong path. In order to see if the problem was in MULT I've replaced it in the ASM by the JLP hw multiplication and the DEFINE issue is still there. So the problem has to be elsewhere. Due to the fact I cannot see any relevant difference among the two sources, I will look later if something else is modifying sprites in GRAM Actually, after the loop from 0 to 127 there is a short loop of 31 frames for bosslife=0 to 127 gosub ms_loop gosub boss_explode gosub warp_anim next for bosslife=0 to 31 gosub ms_loop gosub warp_anim next In theory no modification should happen to the sprites used to the boss battle, but I will try to explore differences there Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 But I cannot see any difference there..... Is there any difference in the way DEFINE and DEFINE ALTERNATE are implemented ? Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 I was on a wrong path. In order to see if the problem was in MULT I've replaced it in the ASM by the JLP hw multiplication and the DEFINE issue is still there. So the problem has to be elsewhere. Due to the fact I cannot see any relevant difference among the two sources, I will look later if something else is modifying sprites in GRAM Actually, after the loop from 0 to 127 there is a short loop of 31 frames for bosslife=0 to 127 gosub ms_loop gosub boss_explode gosub warp_anim next for bosslife=0 to 31 gosub ms_loop gosub warp_anim next In theory no modification should happen to the sprites used to the boss battle, but I will try to explore differences there Are you able to reproduce the conditions that cause the glitch? If so, you could try enabling CPU history in the debugger, then set a breakpoint right after it occurs and dump the history. With that we can examine which values were processed and where they came from. -dZ. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 (edited) I thought there was. If it's greater than 127, it inserts a SLL first, halves the constant, and processes it through the macro: IF (%const% > $7F) _mul.const QSET (_mul.const SHR 1) SLL %reg%, 1 ENDI Or did that change in the latest IntyBASIC? no idea about the correctness, but this has not changed between v129 and v140/141 Edited March 3, 2019 by artrag Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 Are you able to reproduce the conditions that cause the glitch? If so, you could try enabling CPU history in the debugger, then set a breakpoint right after it occurs and dump the history. With that we can examine which values were processed and where they came from. -dZ. Sure, It happens each time the boss explodes. After the last frame of the explosion, it shows a huge filled box of FFFFh I was expecting to see the DEFINE pointing outside my data table to an uninitialized rom area (which is FFFFh) but the math implementation in VARPTR seems equivalent and the index variables stay in the correct range (at least in the loop that calls the procedure). I've no idea of how the debugger works, how do I set a break point and enable the history? Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 I thought there was. If it's greater than 127, it inserts a SLL first, halves the constant, and processes it through the macro: IF (%const% > $7F) _mul.const QSET (_mul.const SHR 1) SLL %reg%, 1 ENDI Or did that change in the latest IntyBASIC? Ah, I missed that. It wasn't in the original mpyk.mac that this was based on. Seems like that will only work if the multiply constant is even (which 192 happens to be). I was on a wrong path. In order to see if the problem was in MULT I've replaced it in the ASM by the JLP hw multiplication and the DEFINE issue is still there. So the problem has to be elsewhere. Due to the fact I cannot see any relevant difference among the two sources, I will look later if something else is modifying sprites in GRAM FWIW, I didn't see any meaningful difference between the two bits of code you showed, other than that IntyBASIC 1.4 used the faster MULT sequence, so it makes sense that the issue wasn't here. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 Sure, It happens each time the boss explodes. After the last frame of the explosion, it shows a huge filled box of FFFFh I was expecting to see the DEFINE pointing outside my data table to an uninitialized rom area (which is FFFFh) but the math implementation in VARPTR seems equivalent and the index variables stay in the correct range (at least in the loop that calls the procedure). I've no idea of how the debugger works, how do I set a break point and enable the history? Are you using the IntyBASIC SDK? If so, you can invoke the "intydbug command" and it'll include all the necessary symbols. If not ... When calling jzIntv from the command line, include the -d option to enable debugging. When it starts, it'll halt in the debugger prompt. From there... type "h" <ENTER> to enable CPU history type "b <ADDRS>" <ENTER> to set the breakpoint at <ADDRS> type "r" <ENTER> to run the program as normal. Since you probably haven't done the symbol mapping to the IntyBASIC source (don't worry about it), just use the addresses in the LST file. When the breakpoint hits, the program will halt again and bring up the debugger prompt. From there... type "d" <ENTER> to dump the CPU history to a file type "q" <ENTER> to quit the debugging session and emulation (or "r" to continue running if you'd like) The CPU history will include all execution history for the past several thousand cycles (it recycles after a while), all the way to the point you dumped it. If you post that, hopefully we can help you trace it back to the problem point. -dZ. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 (edited) Ah, I missed that. It wasn't in the original mpyk.mac that this was based on. Seems like that will only work if the multiply constant is even (which 192 happens to be). I just noticed that. Yeah, it seems to be one of the last vestiges of the enhancements I made in a rush which none of us tested. FWIW, I didn't see any meaningful difference between the two bits of code you showed, other than that IntyBASIC 1.4 used the faster MULT sequence, so it makes sense that the issue wasn't here. I'm more inclined to think it's an interrupt cycle overrun or a data corruption issue. Edited March 3, 2019 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 I'm more inclined to think it's an interrupt cycle overrun or a data corruption issue. Wait, I take that back. It can't be a cycle overrun because it seems it is actually writing GRAM with bad data. artrag, from the breakpoint prompt, you can also dump the GRAM image into a file with the "gs" command. At least this will give us an idea if that card you are seeing is actually in GRAM or if it's been picked up from somewhere else. In any case, the "^" command will also show if GRAM write events failed. You should set that at the beginning of execution, like the "h" history command. -dZ. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 (edited) no idea about the correctness, but this has not changed between v129 and v140/141 Probably this macro should test the number of zeros right, shifting right the constant and left the register, and then continue as normal if the resulting constant is less than 128. As it is now it can be source of troubles.. Oscar, you should fix or remove that IF/ENFI Edited March 3, 2019 by artrag Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 Probably this macro should test the number of zeros right, shifting right the constant and left the register, and then continue as normal if the resulting constant is less than 128. As it is now it can be source of troubles.. Oscar, you should fix or remove that IF/ENFI Well, it was a failed attempt at adding support for values larger than 127. Perhaps that test at the top should be removed and keep it at 127. Alternatively, it can be fixed with additional work, which may still be cheaper than calling the full-blown runtime multiplication function. -dZ. Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 (edited) Well, it was a failed attempt at adding support for values larger than 127. Perhaps that test at the top should be removed and keep it at 127. Alternatively, it can be fixed with additional work, which may still be cheaper than calling the full-blown runtime multiplication function. Well, according to the IntyBASIC source, "your" macro (really ours, isn't it?) only gets used for values <=127 anyway: . } else if (val <= 127) { // DZ-Jay's macro output->emit_m(N_MULT, reg, 4, val); Edited March 3, 2019 by intvnut Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 And FWIW, there is a cost table in IntyBASIC 1.4.0 that determines when to use JLP vs. using the macro. It theoretically could be extended to handle more cases. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 Well, according to the IntyBASIC source, "your" macro (really ours, isn't it?) only gets used for values <=127 anyway: . } else if (val <= 127) { // DZ-Jay's macro output->emit_m(N_MULT, reg, 4, val); Sorry, I didn't call it my macro -- it's not. I even asked nanochess to remove "by DZ-Jay" from the source and the manual because it was yours. The only part I take ownership of is of all the errors. Those went completely untested for a long time until someone pointed them out. For the record, the MULT macro was created by intvnut (originally called MLPY), and he gets full credit for it. I then modified it to add support for values greater than 127 and to replace some shift sequences with SWAP and broke it. I get full credit for that. -dZ. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 } else if (val <= 127) { // Joe Z.'s macro, screwed up by DZ-Jay output->emit_m(N_MULT, reg, 4, val); FTFY. OK then, that bug has been neutralized. Phew! Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 Sorry, I didn't call it my macro -- it's not. I even asked nanochess to remove "by DZ-Jay" from the source and the manual because it was yours. The only part I take ownership of is of all the errors. Those went completely untested for a long time until someone pointed them out. For the record, the MULT macro was created by intvnut (originally called MLPY), and he gets full credit for it. I then modified it to add support for values greater than 127 and to replace some shift sequences with SWAP and broke it. I get full credit for that. I think my original mpyk.mac had some broken entries in it that are errors of my own creation. :-) 1 Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 I think my original mpyk.mac had some broken entries in it that are errors of my own creation. :-) OK, now you're trying to take credit for the errors too? Jeez, don't I get a break? J/K Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 Are you using the IntyBASIC SDK? If so, you can invoke the "intydbug command" and it'll include all the necessary symbols. If not ... When calling jzIntv from the command line, include the -d option to enable debugging. When it starts, it'll halt in the debugger prompt. From there... type "h" <ENTER> to enable CPU history type "b <ADDRS>" <ENTER> to set the breakpoint at <ADDRS> type "r" <ENTER> to run the program as normal. Since you probably haven't done the symbol mapping to the IntyBASIC source (don't worry about it), just use the addresses in the LST file. When the breakpoint hits, the program will halt again and bring up the debugger prompt. From there... type "d" <ENTER> to dump the CPU history to a file type "q" <ENTER> to quit the debugging session and emulation (or "r" to continue running if you'd like) The CPU history will include all execution history for the past several thousand cycles (it recycles after a while), all the way to the point you dumped it. If you post that, hopefully we can help you trace it back to the problem point. -dZ. Here the dump just after the broken frames have appeared. Do you need also the LST file? dzgorf_dump.zip Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 I have set the brekpoint at the end of the first loop on bosslife, i.e. at $5382 . This means that the bug has to be in DEFINE, in the procedure "boss_explode" SRCFILE "dzgorf.bas",483 ;[484] for bosslife=0 to 127 SRCFILE "dzgorf.bas",484 536D 01C0 CLRR R0 536E 0240 0131 MVO R0,var_BOSSLIFE 0x5370 T27: ;[485] gosub ms_loop SRCFILE "dzgorf.bas",485 5370 0004 0154 035A CALL label_MS_LOOP ;[486] gosub boss_explode SRCFILE "dzgorf.bas",486 5373 0004 01E8 0332 CALL label_BOSS_EXPLODE ;[487] gosub warp_anim SRCFILE "dzgorf.bas",487 5376 0004 01E4 0148 CALL label_WARP_ANIM ;[488] next SRCFILE "dzgorf.bas",488 5379 0280 0131 MVI var_BOSSLIFE,R0 537B 0008 INCR R0 537C 0240 0131 MVO R0,var_BOSSLIFE 537E 0378 007F CMPI #127,R0 5380 0226 0011 BLE T27 ;[489] SRCFILE "dzgorf.bas",489 ;[490] for bosslife=0 to 31 SRCFILE "dzgorf.bas",490 5382 01C0 CLRR R0 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 3, 2019 Author Share Posted March 3, 2019 If for some reason boss_explode is called again it would fail because bosslife is 128 after the FOR Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 If for some reason boss_explode is called again it would fail because bosslife is 128 after the FOR There has to be something nastier, boss_explode is called only in that loop. Moreover while tracing step by step the code I've ended to this picture that is strange because halfway between the correct frame and the dummy FFFFh frame... What could it be? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.