English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 19 March 2018, 22:03   #1
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 215
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?
Kalms is offline  
Old 19 March 2018, 22:23   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,020
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.
Toni Wilen is offline  
Old 20 March 2018, 15:25   #3
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 215
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.
Kalms is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Blitter interrupt during VERTB interrupt phx Coders. Asm / Hardware 32 03 December 2017 11:34
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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.05924 seconds with 12 queries