42bs Posted July 7, 2018 Share Posted July 7, 2018 Hi I am facing a strange bug: I have OP interrupt and timer interrupt (1ms period) active. From time to time, it seems R31 (stackpointer) is not decremented in the timer interrupt which results in a stack underflow. The OP interrupt never shows this. Did anyone see a similar problem? I could not find a hint in the bug list. Cheers 42Bastian 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 11, 2018 Share Posted July 11, 2018 Could they both be firing at the same time? or one is firing within the execution of the other? What is your ISR handler code doing? In my DSP code (I have 3 interrupts all running, all timer based), I don't clear the latches etc until the ISR has completed. Quote Link to comment Share on other sites More sharing options...
42bs Posted July 11, 2018 Author Share Posted July 11, 2018 Hi I did a lot of debugging and it seems it is somehow related to my JSR/RTS macros. MACRO JSR move pc,LR subqt #4,SP addqt #10,LR jump \0 store LR,(SP) ENDM MACRO RTS load (SP),LR jump (LR) addqt #4,SP ENDM I switched now to a more RISC like style (ARM,PPC) and load only PC into an register w/o pushing. Now it seems to work far better. The strange thing is that I really do not use the same registers for IRQ and normal work. For IRQ r31/r30 (reserved them in both banks) and for normal subroutines r29/28. Anyway, good to know the DSP works with a lot of interrupt. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 11, 2018 Share Posted July 11, 2018 I assume you have a stack pointer in GPU RAM and not on the bus too ? I'd not be surprised if that store could fail to complete before the return happened if that were the case For my DSP stuff I have split the banks, so the interrupts have their own stack and bank of registers to play with and I know 100% that the rest of the code's data isn't scrambled. Quote Link to comment Share on other sites More sharing options...
42bs Posted July 11, 2018 Author Share Posted July 11, 2018 Both stacks are in GPU RAM. But I tried also to move the non-IRQ stack into DRAM. No change. It is realy weird. It seems r31 is sometimes not decremented. I checked some of the game sources I have, but it seems no one used the GPU really as main processor as I do. Guess I am a bit late with such problem :-) Quote Link to comment Share on other sites More sharing options...
JagChris Posted July 12, 2018 Share Posted July 12, 2018 Do you have access to and have you checked the Fight For Life sources? Quote Link to comment Share on other sites More sharing options...
42bs Posted July 12, 2018 Author Share Posted July 12, 2018 Do you have access to and have you checked the Fight For Life sources? No. Do you have a link? Quote Link to comment Share on other sites More sharing options...
JagChris Posted July 12, 2018 Share Posted July 12, 2018 No but I think I can send it to you in chunks unless someone else pops up with a link Quote Link to comment Share on other sites More sharing options...
JagChris Posted July 12, 2018 Share Posted July 12, 2018 If you can give me some keywords to search for that might enable me to give you specific files that may be helpful. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted July 12, 2018 Share Posted July 12, 2018 If you can give me some keywords to search for that might enable me to give you specific files that may be helpful. Or maybe you could just ZIP it and upload it, making it a lot easier... 4 Quote Link to comment Share on other sites More sharing options...
philipj Posted July 12, 2018 Share Posted July 12, 2018 I got a copy... I use to play around with the 3DStudio Max files animation sequences. I even had a JS2 copy of the Beta version limited release before I sold it sometime back. I hope this helps out. FFLSource.zip 3 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 12, 2018 Share Posted July 12, 2018 The strange thing is that I really do not use the same registers for IRQ and normal work. For IRQ r31/r30 (reserved them in both banks) and for normal subroutines r29/28. Just having a scan through the manual and remembered that Primary R30 is trashed when flow is transferred to the ISR, and Primary R31 is Interupt Stack pointer... perhaps this could be the issue? The end of ISR code I use: load (STACKPTR),r28 ; Get the address of the last instruction executed from stack addq #4,STACKPTR ; realign the stack addq #2,r28 ; point to the next instruction jump T,(r28) ; jump back into main code store r29,(r30) ; write the control flags back STACKPTR is R31 obviously 3 Quote Link to comment Share on other sites More sharing options...
JagChris Posted July 12, 2018 Share Posted July 12, 2018 Or maybe you could just ZIP it and upload it, making it a lot easier... If I remember correctly mine has a bunch of ROMs in the same directory that makes it exceed the upload limit. Was feeling too lazy to pick through it all. Or maybe I'm thinking of the HS CD sources I lost. Quote Link to comment Share on other sites More sharing options...
42bs Posted July 12, 2018 Author Share Posted July 12, 2018 If you can give me some keywords to search for that might enable me to give you specific files that may be helpful. Any GPU source Quote Link to comment Share on other sites More sharing options...
42bs Posted July 12, 2018 Author Share Posted July 12, 2018 I got a copy... I use to play around with the 3DStudio Max files animation sequences. I even had a JS2 copy of the Beta version limited release before I sold it sometime back. I hope this helps out. Cool, thanks. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 13, 2018 Author Share Posted July 13, 2018 Just having a scan through the manual and remembered that Primary R30 is trashed when flow is transferred to the ISR, and Primary R31 is Interupt Stack pointer... perhaps this could be the issue? The end of ISR code I use: load (STACKPTR),r28 ; Get the address of the last instruction executed from stack addq #4,STACKPTR ; realign the stack addq #2,r28 ; point to the next instruction jump T,(r28) ; jump back into main code store r29,(r30) ; write the control flags back STACKPTR is R31 obviously Just like mine ... (well, I do not need to use the T, for jumps with lyxass). I tried different places for the fixing of the return address. No change. The Atari docs are not clear, when the writing of the flags takes place. So I also tried this addqt #2,r28 ; return address moveta r28,r28 jump (r28) move r29,(r30) But looking throuh FFL sources, it seems to be like in others: The GPU is mainly used for short code sequences. Which run to completion and then stop. No interrupts. 1 Quote Link to comment Share on other sites More sharing options...
JagChris Posted July 13, 2018 Share Posted July 13, 2018 You've modified your lynx assembler to work with the Jag? Interesting. 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted July 13, 2018 Share Posted July 13, 2018 For what it's worth, this is my GPU interrupt code, works 100%, but again, only using a single interrupt (GPU Interrupt Object) gpu_int: load (r26),r29 bclr #3,r29 ; Clear IMASK bset #12,r29 ; Clear Pending load (r31),r28 ; Addr of last instruction addq #4,r31 ; Correct Stack addq #2,r28 ; Next instruction ; some code jump (r28) ; RTE store r29,(r26) nop r26 = #G_FLAGS r31 = Stack pointer *Addendum Another point of note - I don't use the jump vectors, this code is directly at the vector address. 2 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) You've modified your lynx assembler to work with the Jag? Interesting. Yes. Years ago But lately fixed bugs. ... I should put it on M$hub (eh) GitHub Edited July 13, 2018 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 16, 2018 Author Share Posted July 16, 2018 Ok, it seems, the bug is almost gone, with a small workaround. Every 60000 or so interrupts, I still see that the stackpointer is not decremented. I wonder if there are design documents of GPU/DSP arround because pushing the return address hardcoded seems to be complicated. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 16, 2018 Share Posted July 16, 2018 (edited) Random thought, does this happen on VJ too? If it does might help identify the particular alignment of voodoo or some such. Have you tried assembling your code via another assembler? just to validate that there isn't something weird going on there too (not saying your assembler is at fault and it's a pretty grasping idea.. but this is the jag ) Is the OP Interrupt being triggered by GPU objects in an OP list too? I believe these are somewhat buggy as it is, and maybe you have found a new aspect of their buggyness?) Edited July 16, 2018 by LinkoVitch 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2018 Author Share Posted July 17, 2018 VJ is not running on my machine (like MAME and other sdl based stuff). Another assembler will be difficult as I use a lot of the lyxass macro features, but I counter checked the code with my small quick'n'dirty disassembler. So far no bugs. But yes, the cat has bitten me once or twice. "Nice" example: cmpq #7,r0 jr z, .cont moveq #10,r1 mult r0,r1 .cont moveq #20,r1 // debug Due to the scoreboard bug, the mult writes back after the moveq and the 20 never appeared. Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2018 Author Share Posted July 17, 2018 Is the OP Interrupt being triggered by GPU objects in an OP list too? I believe these are somewhat buggy as it is, and maybe you have found a new aspect of their buggyness?) I use the OP interrupt for VBL. I could try and do the VBL in 68k for a test. 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 17, 2018 Share Posted July 17, 2018 Be interesting to hear if that "fixes" the issue Quote Link to comment Share on other sites More sharing options...
42bs Posted July 21, 2018 Author Share Posted July 21, 2018 Be interesting to hear if that "fixes" the issue I first quick test does also show the issue. Though I have the subjective impression it happens less often. Though my workaround works, it is still not reasonable. Atari says, the r31 is decremented and then the return address is store to the new r31. That's how we return: Load from r31 then increment. The workaround is _not_ to increment r31. So as if the GPU does not decrement it sometimes. I will place an sentinel at the end of stack to see if it gets corrupted. 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.