Zerosquare Posted February 28, 2021 Share Posted February 28, 2021 (edited) Also, if you're using C, make sure every variable that's accessed by both the 68k and another processor has the volatile keyword in the declaration: https://barrgroup.com/embedded-systems/how-to/c-volatile-keyword Otherwise you'll have endless weird and hard-to-find bugs. Edited February 28, 2021 by Zerosquare 1 Quote Link to comment Share on other sites More sharing options...
SCPCD Posted February 28, 2021 Share Posted February 28, 2021 (edited) One of the bug is indeed what CyranoJ says. I will see another one : from what I understand, bank0 is used for your service interrupt and bank1 for your user code. In your post #21, i don't see any r31 configuration (don't know if it's in part of code we don't have), but I will explain what I suspect now that we have more code and mixing with post #4. Initialisation : (#4) movei #init_raster,r0 ; 3 movei #G_ENDRAM,stack ; 3 jump t,(r0) ; 1 moveta stack,stack ; 1 => G_ENDRAM in b0r31 & b1r31 (stack = r31) Dispatcher code : (probably b1r31) (#21) ; jsr to routine movei #.l0,return subqt #4,r31 jump (event) store return,(r31) => b1r31 changed and ".l0" written in stack Interrupt code : (b0r31) (#4 & #21) load (r31),r30 addq #2,r30 addqt #4,r31 jump (r30) store flags,(gpuFlagsPtr) ; restore interrupt => b0r31 changed during interrupt entering and PC written in stack -> RTE : jump back to user code correcting stack pointer Event RTS : (#21) ;rts moveq #0,r0 ; skip 0 parameter load (r31),r1 jump (r1) addqt #4,r31 If it's the case, when entering the interrupt routine during your user "event" code, your stack content is overwritten as b0r31 & b1r31 are independant. Then, the interrupts service completed and go back to the user code, at the end of your user "event" code when your "rts" append, the PC go back to an unattended address. Edit: Hmm in #4, i see a subq #4, for the "user" stack, maybe to reserve one stack slot for the interrupt service routine ? Edited February 28, 2021 by SCPCD 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 28, 2021 Author Share Posted February 28, 2021 9 hours ago, CyranoJ said: The 68000 writes to the GPU RAM in 16-bit segments, so two writes for a longword. The GPU reads as 32bit, and is clocked higher. It's reading only half the address (the high half) You should be setting a sempahore flag, and checking that, not the actual pointer value. .wait_list: load (list_ptr),event_list or event_list, event_list jr EQ,.wait_list nop That is your problem. When I wrote the routine I though about that but I hoped that the GPU would be blocked until the 68000 writes both parts of the longword. I was wrong. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 28, 2021 Share Posted February 28, 2021 Simple fix is to read it again after the NOP. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 28, 2021 Author Share Posted February 28, 2021 (edited) With a second read still fails ? I'm going to try to move the raster code to a small 100% asm sample program. Edited February 28, 2021 by swapd0 Quote Link to comment Share on other sites More sharing options...
SCPCD Posted February 28, 2021 Share Posted February 28, 2021 (edited) I don't think adding a load just after the nop will be enough: Each 68k memory acces takes 6cycles on the jaguar (from what I remember) so arround 12gpu cycles : you will have approx 12 cycles between each word write. If I don't do mistakes, the "wait_list" will take arround 6 cycles to complete. Adding extra nop (I would say approx 6) before the second load will probably do the trick for test purpose, but it's not the solution. The best way is indeed a semaphore. Edit: After posting I have a doubt about if it's 5 or 6cycles on the jaguar for the 68k memory access, need to check in my notes, but it's higher than standard 68k use. Edited February 28, 2021 by SCPCD 2 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 28, 2021 Author Share Posted February 28, 2021 Next thing to try is the semaphore. I've moved the code to an old sprite test and it works... What I don't understand it's that now it fails quickly (the C test program), and usually when I press down or right in the joypad to move the sprites down or to the right. In test-c.jag you have to press * on the joypad to turn rasters on, you can move the sprites with the joypad. rasters.zip test-c.jag Quote Link to comment Share on other sites More sharing options...
Cyprian Posted March 2, 2021 Share Posted March 2, 2021 Is it possible to run that test-c.jag under VirtualJag? Quote Link to comment Share on other sites More sharing options...
dilinger Posted March 3, 2021 Share Posted March 3, 2021 (edited) 8 hours ago, Cyprian said: Is it possible to run that test-c.jag under VirtualJag? I have transformed it as a coff file and took this screenshot. I can move the sprites freely but If I press * I got a white screen in the window. Edited March 3, 2021 by dilinger Quote Link to comment Share on other sites More sharing options...
swapd0 Posted March 3, 2021 Author Share Posted March 3, 2021 When you press * a GPUOB is inserted in the beginning of the OP list, sometimes it hangs quickly, some times you must move the sprites to crash the code, I don't know why. The same code (copy & pasted) is used in the raster.zip code (sorry I forgot to include the binary) and it works there. I hope to have some free time today to implement the semaphore, it's the right way to do it, but still don't know why it's so unstable because I'm using this for the background rasters in Classic Kong, and it worked in the demo that I uploaded some time ago. Quote Link to comment Share on other sites More sharing options...
Cyprian Posted March 3, 2021 Share Posted March 3, 2021 (edited) 8 hours ago, dilinger said: I have transformed it as a coff file How? do you have a dedicated tool? Changing a file extension from .jag to .cof doesn't work for me. Edited March 3, 2021 by Cyprian Quote Link to comment Share on other sites More sharing options...
swapd0 Posted March 3, 2021 Author Share Posted March 3, 2021 (edited) 40 minutes ago, Cyprian said: How? do you have a dedicated tool? Changing a file extension from .jag to .cof doesn't work for me. I think that he used this tool, you just can't change the extension and make it work. https://www.reboot-games.com/rebootnews/jiffi/ Executable version of the asm example. rasters.jag Edited March 3, 2021 by swapd0 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted March 3, 2021 Share Posted March 3, 2021 thanks @swapd0 Quote Link to comment Share on other sites More sharing options...
matmook Posted March 3, 2021 Share Posted March 3, 2021 Nice effect! Another option is to NOT use interrupts for your rasters but a sprite instead. You will have an extra sprite to manage and write to but you won't interrupt the GPU on each line. 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted March 3, 2021 Author Share Posted March 3, 2021 3 hours ago, matmook said: Nice effect! Another option is to NOT use interrupts for your rasters but a sprite instead. You will have an extra sprite to manage and write to but you won't interrupt the GPU on each line. Yes, I though about that but I'll need a 16bits background, the OP would eat all the bus cycles and the 68000 won't have enough free cycles to run the game logic. Or use a 8bits background with less colors. Anyway I want to try it with a semaphore. Quote Link to comment Share on other sites More sharing options...
SCPCD Posted March 3, 2021 Share Posted March 3, 2021 Don't know if it's what you would like to achieve, but, I give it a try and made some modification (search SCPCD tags) Seems working fine on real Jaguar, JagFPGA & VirtualJaguar. rasters_SCPCD.zip 5 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted March 4, 2021 Author Share Posted March 4, 2021 (edited) 10 hours ago, SCPCD said: Don't know if it's what you would like to achieve, but, I give it a try and made some modification (search SCPCD tags) Seems working fine on real Jaguar, JagFPGA & VirtualJaguar. rasters_SCPCD.zip 74.08 kB · 8 downloads I just copy&paste the raster code, in that sprite demo it works, but in the other one it doesn't work... I've no idea why this happens, IMO it should work or doesn't on both programs. Edit: I had a quick look at your modifications, yesterday I did almost the same (including a semaphore) but I forgot to use the indexed load and one of the relative jump was too far, I had to write more code and use a unconditional jump. I'll use your solution, the code looks more clean now. Thanks. Edited March 4, 2021 by swapd0 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted March 7, 2021 Author Share Posted March 7, 2021 I've had a very bad cold so no coding in a couple of days, today I'm ok so it's time to test it and it works. Thanks SPCD for your help. 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 10, 2021 Author Share Posted December 10, 2021 Anyone had success in reading Object Code (OB0 to OB3) register from a GPU Object interrupt? I've this: volatile uint32_t *ptr0 = (uint32_t *)(0x4000-8); volatile uint32_t *ptr1 = (uint32_t *)(0x4000-4); *ptr0 = 0x01234567; *ptr1 = 0x89abcdef; LOG(*ptr0); LOG(*ptr1); while (1) { // do some stuff LOG(*ptr0); LOG(*ptr1); } And the output is. *ptr0 = 19088743(01234567) *ptr1 = 16895471(0101cdef) *ptr0 = 19088743(01234567) *ptr1 = 16895471(0101cdef) *ptr0 = 19088743(01234567) *ptr1 = 16895471(0101cdef) *ptr0 = 19088743(01234567) *ptr1 = 16895471(0101cdef) *ptr0 = 19088743(01234567) ... The GPU code to read the OB0-3 registers is like. GPU code interrupt ... movei #OB0,r2 movei #$4000-4*2,r20 loadw (r2),r28 addqt #2,r2 storew r28,(r20) addqt #2,r20 loadw (r2),r28 addqt #2,r2 storew r28,(r20) addqt #2,r20 loadw (r2),r28 addqt #2,r2 storew r28,(r20) addqt #2,r20 loadw (r2),r28 storew r28,(r20) ... Why only writes one word (0x0101cdef)? and where the 0x0101 comes from? I've tried to modify the ptr0 and ptr1 values from C and they got changed but the 0x0101 is constant... WTF!? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 10, 2021 Author Share Posted December 10, 2021 nah! forget about this... 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.