Jump to content
IGNORED

GPU interrupt & GPU Object


swapd0

Recommended Posts

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 by Zerosquare
  • Thanks 1
Link to comment
Share on other sites

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 by SCPCD
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by SCPCD
  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

image.thumb.png.de3ac972f015eeec96fbcf87b5638351.png

 

I can move the sprites freely but If I press * I got a white screen in the window.

Edited by dilinger
Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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 by swapd0
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

rasters.jpg

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 by swapd0
  • Like 1
Link to comment
Share on other sites

  • 9 months later...

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!?

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...