Emulated A500 with Kick 1.3 generates spurious Lev6 interrupt

Kalms · 19 March 2018, 22:03

Hi,

I was looking into a graphical corruption the other day, and ended up at "it seems that the OS is touching blitter-related bits when it shouldn't". Perhaps someone here can shed some light?

Scenario:

I boot an emulated A500 (512k chip + 512k fast) with KS1.3 and an emulated harddrive. It is run in a slightly modified version of FS-UAE.

The harddrive has a Startup-Sequence which does the following:

setpatch >NIL: [v1.34]
SYS:System/FastMemFirst
launch homemade application

The homemade application performs:

OwnBlitter
WaitBlit
Forbid
LoadView(NULL)
WaitTOF x2

Then the application performs some graphics stuff using both CPU and blitter. The blitter activity is done via a homemade blitter queue.

In one of the frames, the blitter interrupt is triggered while BBUSY is still set in DMACON.

It seems that the following happens:
CIAB TOD counter goes from $000fff to $001000. Due to a hardware bug, it reads out as $000000 for some cycles. This triggers the CIAB alarm interrupt. This, in turn, makes the hardware set the EXTER bit in INTREQ. This interrupt is enabled by the OS since earlier.

The OS interrupt handler will run some code that sets the BLIT bit in both INTREQ and INTENA. This happens despite my application having called OwnBlitter...

My application happens to be in the middle of a blit at that time. When the OS interrupt handler sets BLIT in INTREQ, my blitter queue thinks that the current blit operation is completed, and begins to set up the next blit.

I can protect against this by testing BBUSY in my blitter interrupt handler, and returning without doing anything if BBUSY happens to be set. I can also protect against it by turning off CIA interrupts and/or taking over lev2/lev6 autovectors.

I'm still left scratching my head. Why is this happening? Am I missing something obvious? How do you others deal with this? Is this documented somewhere? Is my emulated a500 config perhaps incorrect?

Toni Wilen · 19 March 2018, 22:23

I think (It was long time ago when I noticed it, not sure if I remember correctly) that it happens when KS notices blitter interrupt. It confuses graphics.library making it think QBlit/QBSBlit blit queue is active.

Kalms · 20 March 2018, 15:25

Sounds plausible, thanks. I will probably both add BBUSY tests to my BLIT handler and disable CIA interrupts (via CRA/CRB/ICR) to be safe.

19 March 2018, 22:03	#1
Kalms Registered User Join Date: Nov 2006 Location: Stockholm, Sweden Posts: 237	Emulated A500 with Kick 1.3 generates spurious Lev6 interrupt Hi, I was looking into a graphical corruption the other day, and ended up at "it seems that the OS is touching blitter-related bits when it shouldn't". Perhaps someone here can shed some light? Scenario: I boot an emulated A500 (512k chip + 512k fast) with KS1.3 and an emulated harddrive. It is run in a slightly modified version of FS-UAE. The harddrive has a Startup-Sequence which does the following: setpatch >NIL: [v1.34] SYS:System/FastMemFirst launch homemade application The homemade application performs: OwnBlitter WaitBlit Forbid LoadView(NULL) WaitTOF x2 Then the application performs some graphics stuff using both CPU and blitter. The blitter activity is done via a homemade blitter queue. In one of the frames, the blitter interrupt is triggered while BBUSY is still set in DMACON. It seems that the following happens: CIAB TOD counter goes from $000fff to $001000. Due to a hardware bug, it reads out as $000000 for some cycles. This triggers the CIAB alarm interrupt. This, in turn, makes the hardware set the EXTER bit in INTREQ. This interrupt is enabled by the OS since earlier. The OS interrupt handler will run some code that sets the BLIT bit in both INTREQ and INTENA. This happens despite my application having called OwnBlitter... My application happens to be in the middle of a blit at that time. When the OS interrupt handler sets BLIT in INTREQ, my blitter queue thinks that the current blit operation is completed, and begins to set up the next blit. I can protect against this by testing BBUSY in my blitter interrupt handler, and returning without doing anything if BBUSY happens to be set. I can also protect against it by turning off CIA interrupts and/or taking over lev2/lev6 autovectors. I'm still left scratching my head. Why is this happening? Am I missing something obvious? How do you others deal with this? Is this documented somewhere? Is my emulated a500 config perhaps incorrect?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Blitter interrupt during VERTB interrupt	phx	Coders. Asm / Hardware	38	01 October 2021 19:54
kick 1.2 VS Kick 1.3 for A500'games compatibility	laser	support.WinUAE	35	12 November 2014 12:40
Assembler that generates all M68k opcodes	TheDarkCoder	Coders. Asm / Hardware	12	07 February 2013 10:37
A500 kick 1.3 in A600..?	8bitbubsy	support.Hardware	14	02 November 2009 23:10
Spurious checksum errors	MagerValp	support.Hardware	6	28 August 2008 17:10

19 March 2018, 22:23	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,510	I think (It was long time ago when I noticed it, not sure if I remember correctly) that it happens when KS notices blitter interrupt. It confuses graphics.library making it think QBlit/QBSBlit blit queue is active.

20 March 2018, 15:25	#3
Kalms Registered User Join Date: Nov 2006 Location: Stockholm, Sweden Posts: 237	Sounds plausible, thanks. I will probably both add BBUSY tests to my BLIT handler and disable CIA interrupts (via CRA/CRB/ICR) to be safe.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)