42bs Posted January 25, 2019 Author Share Posted January 25, 2019 I don't know but it looks like the interrupt it's running using the same register bank as the normal code, because I can see the sprites if I don't have an OP interrupt, but with an GPU Object I can't see anything, and now it hangs... WTF!?!? I had the same impression when tuning Tetris. All the weird effects went away at the moment I did reset r31 to the stack-top. Quote Link to comment Share on other sites More sharing options...
42bs Posted January 25, 2019 Author Share Posted January 25, 2019 sprite list with the 68000 & rasters on (GPU) ---> works sprite list with the GPU & rasters off ---> works sprite list with the GPU & rasters on (GPU) ---> black screen but the game it's running. So OBL update is also done with the GPU, I assume. Is your OBL correct? End and start values? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted January 25, 2019 Share Posted January 25, 2019 (edited) So OBL update is also done with the GPU, I assume. Is your OBL correct? End and start values? If I turn off the rasters (don't include the GPU Object in the list) it works, that object it's done with the 68000, the GPU routine just converts an array of "sprites" to the OP list. I'll have another look tomorrow with a fresh mind. Edited January 25, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted January 25, 2019 Share Posted January 25, 2019 I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself. RE Stack handling from interrupts, I have never had an issue with stack pointer corruption. I use: load (r31),r28 addq #4,r31 addq #2,r28 jump T,(r28) At the end of my ISR routines in U235SE. I have split the reg banks, so my ISRs have their own bank of registers to play with no worries of corrupting the secondary set. Quote Link to comment Share on other sites More sharing options...
42bs Posted January 26, 2019 Author Share Posted January 26, 2019 I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself. RE Stack handling from interrupts, I have never had an issue with stack pointer corruption. I use: load (r31),r28 addq #4,r31 addq #2,r28 jump T,(r28) At the end of my ISR routines in U235SE. I have split the reg banks, so my ISRs have their own bank of registers to play with no worries of corrupting the secondary set. But that's DSP code, isnt't it? Anyway, all my weird problems went away when I did not use the "addq #4,r31" but instead reload r31 to the stack top. I added debug code to verify r31 and saw that the value "before" incrementing was already stacktop (0xf03ffc in my case)! So first I thought it is because I did use r31 in the normal bank as stackpointer as well, but even when I changed to two different SPs, the same happened. I did check many game sources, and most of them do the same. And actually, that's no problem unless one uses nested interrupts. Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 26, 2019 Share Posted January 26, 2019 (edited) I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself. GPU object doesn't use the YPOS. I initialy thought it was a bug, but in fact it seems that some version of the doc are wrong as the last i known version (7 Nov 1994) describe the GPU obj as interrupt always and reading the netlist confirm that. Probably it was a forgotten features or they think it was not needed since there is branch object and prefer to use more bits to pass information to GPU ? Edited January 26, 2019 by SCPCD 2 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted January 26, 2019 Share Posted January 26, 2019 But that's DSP code, isnt't it? Anyway, all my weird problems went away when I did not use the "addq #4,r31" but instead reload r31 to the stack top. I added debug code to verify r31 and saw that the value "before" incrementing was already stacktop (0xf03ffc in my case)! So first I thought it is because I did use r31 in the normal bank as stackpointer as well, but even when I changed to two different SPs, the same happened. I did check many game sources, and most of them do the same. And actually, that's no problem unless one uses nested interrupts. Yep it is DSP. I guess I cannot assume the GPU and DSP cores will behave the same for all things, they do have their other differences, I was simply assuming that the way they would handly things such as stack would be identical. Not had any need to poke the GPU yet, but I will be with current projects soon, so I am glad to be forewarned about the "fun" on my horizon Quote Link to comment Share on other sites More sharing options...
swapd0 Posted January 30, 2019 Share Posted January 30, 2019 (edited) I bet that when an interrupt it's triggered sometimes the register swap gets a bit delayed (maybe because a movei instruction?). This is my start up code. start:: movei #OBF,op movei #G_ENDRAM,stack ; enable OP interrupt movei #G_FLAGS,flagsPtr load (flagsPtr),flags bset #7,flags store flags,(flagsPtr) moveta op,op ... And here my interrupt code: op_interrupt: movei #G_FLAGS,flagsPtr load (flagsPtr),flags ; GPU_FLAGS movei #_hdma_colors,rasterPtr load (rasterPtr),colors movei #CLUT,clut ... movei #OBF,op ; ????? storew op,(op) ; rte bclr #3,flags ; serviced bset #12,flags ; clear interrupt flag load (stack),rts movefa stack,stack ; reload stack, no sp++ addq #2,rts jump T,(rts) store flags,(flagsPtr) ; restore interrupt I must have the movei #OBF,op uncommented or the OP it's not resumed and I don't see anything, but that value it should be already in the register!!!!!!!!!!1!!! Edited January 30, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted January 30, 2019 Share Posted January 30, 2019 Maybe the only (robust) solution is to avoid the register overlap, even they are into a different set... Quote Link to comment Share on other sites More sharing options...
42bs Posted January 30, 2019 Author Share Posted January 30, 2019 (edited) Ok, for one, why do you use "movei" s in the interrupt. You should keep it short, so I'd recommend to have those values loaded once in the foreground code. Depending on what you are else doing in the interrupt, I recommend to move the restarting of the OP at the top of the ISR. I had also the impression, that sometimes the ISR did modify the wrong register bank. Therefore, both r31 contain the IRQ SP and I both r29 (in my case) contain the flag address. So my initial IRQ code is this: org $f03030 load (IRQ_FLAGADDR.a),IRQ_FLAG.a movei #obj_irq,IRQScratch0.a bset #12,IRQ_FLAG.a load (IRQ_SP.a),IRQ_RTS.a jump (IRQScratch0.a) bclr #3,IRQ_FLAG.a So even if the bank-swap is delayed, the first "load" is done correctly. After these changes I had no longer problems with the interrupts. I increased my 1kHz timer to 10kHz (besides the OP-VBL interrupt) w/o problem. Edited January 30, 2019 by 42bs 2 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted January 30, 2019 Share Posted January 30, 2019 If I remove the movei in the interrupt code it doesn't work. And it should work because I've load it into the startup code. Anyway I'll have another look at it... Quote Link to comment Share on other sites More sharing options...
42bs Posted January 31, 2019 Author Share Posted January 31, 2019 (edited) Are you sure you've selected bank 1 for the foreground code? When switching bank, you should not use any register for at least 2 cycles: movei #1<<14|%11111<<9,r1 ; clear all ints, REGPAGE = 1 store r1,(status) nop nop ; wait moveta status,IRQ_FLAGADDR.a Edited January 31, 2019 by 42bs 2 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 1, 2019 Share Posted February 1, 2019 (edited) I've done some test and all the registers that I move to the alternative back are not preserved at the irq routine, and I only use moveta at the init code, the only way that I get the correct values at the irq service routine it's if I run the GPU on a nops loop. If I touch any register I see them modified at the irq. I've copied the flags register to a memory location and the init code runs at register bank #0, I need to see if the irq runs at bank #1... but now I'm very tired, I've wasted many hours with this. Edited February 1, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 1, 2019 Author Share Posted February 1, 2019 (edited) IRQ runs on register bank 0! 14 REGPAGE Switches from register bank 0 to register bank 1. This function isoverridden by the IMASK flag, which forces register bank 0 to be used. See my previous post! Edited February 1, 2019 by 42bs 2 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 1, 2019 Share Posted February 1, 2019 IRQ runs on register bank 0! See my previous post! Then my init code it's wrong because I do a move.l #0,G_FLAGS and that make the main code runs at bank 0. 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 1, 2019 Share Posted February 1, 2019 Fixed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!!!! Thanks a lot Bastian By the way I got this in my init code. moveq #0,d0 move.l d0,D_FLAGS ; disable DSP-IRQs move.l #1<<14|%11111<<9,G_FLAGS ; disable GPU-IRQs, bank #1 If I set the DSP with the same flags as the GPU the u235se doesn't work... 2 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 1, 2019 Share Posted February 1, 2019 Fixed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!!!! Thanks a lot Bastian By the way I got this in my init code. moveq #0,d0 move.l d0,D_FLAGS ; disable DSP-IRQs move.l #1<<14|%11111<<9,G_FLAGS ; disable GPU-IRQs, bank #1 If I set the DSP with the same flags as the GPU the u235se doesn't work... The start of the DSP code in u235SE sets the DSP up how it likes it, and enables things only once it is ready. I imagine if you are starting the DSP with all the things already set it may be firing interrupts before they are configured, or running in the wrong bank etc. I'd not try and pre-empt it's own setup routine. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 1, 2019 Share Posted February 1, 2019 Don't worry, when I fixed the GPU rasters on a test program Classic Kong refuses to work, so I had to change the DSP init code. It looks a bit weird because the setup code it's different, but I don't care because I load the u235SE code, run and forget about it. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 1, 2019 Share Posted February 1, 2019 BTW would anyone like to post a small working example of this so everyone will get some closure? Quote Link to comment Share on other sites More sharing options...
42bs Posted February 1, 2019 Author Share Posted February 1, 2019 BTW would anyone like to post a small working example of this so everyone will get some closure? I am currently reworking the BJL examples for rmac/rln/tj_ass. 1 Quote Link to comment Share on other sites More sharing options...
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.