Effect of writing to MFP AER fffa03 ?

[npomarede]

Hello, I'm looking for some infos on bit 3 in fffa03 (active edge register)
Although reading bit 3 is related to the blitter, I couldnd't find doc on what writing to bit 3 is doing.

Does anyone know what would be the effect of these 2 instructions for example (on an STF or STE) :
blcr #3,fffa03
bset #3,fffa03

Does it affect the way some MFP timers are processed ?

Nicolas

[charles]

parellel port hi to low or low to hi from my documentation ,, the 24 8 bit registers start at a uneven address $FFFa01 and communicate with xbios routines...timer rsconfinterupt disable etc etc so active edge register is used for the parrelle port input set or unset relates the communication input ...

charles straight from the tos refernce book ==>sheleed leemoon#1
so i don't feel it will really effect blitter mode in my opion.

[thothy]

Charles, please ... avoid posting if you don't have a real clue what you're writing about.

Nicolas, according to the german book "Atari ST Profibuch", the AER is used to select when the corresponding interrupt happens: Either at the transition from LOW to HIGH of the corresponding line (when the bit in the AER is set to 1) or from HIGH to LOW (when the bit in the AER is set to 0).

For bit 3 this would mean that the interrupt is either generated at the very start of the blitter operation or at the very end. But then I wonder whether there the interrupt can be scheduled at all before the blitter starts to block the CPU bus...
But it's certainly a difference when the blitter does not run in HOG mode, then the start interrupt will be scheduled before the blitter finishs.

[npomarede]

Charles, please ... avoid posting if you don't have a real clue what you're writing about.

Nicolas, according to the german book "Atari ST Profibuch", the AER is used to select when the corresponding interrupt happens: Either at the transition from LOW to HIGH of the corresponding line (when the bit in the AER is set to 1) or from HIGH to LOW (when the bit in the AER is set to 0).

For bit 3 this would mean that the interrupt is either generated at the very start of the blitter operation or at the very end. But then I wonder whether there the interrupt can be scheduled at all before the blitter starts to block the CPU bus...
But it's certainly a difference when the blitter does not run in HOG mode, then the start interrupt will be scheduled before the blitter finishs.

Yes, that's what I understood at first.

In fact, I'm trying to find what is causing Seven Gates Of Jambala to run weird.

TImer B interrupts are delayed by 2 lines on each VBL, which creates a "scrolling rasters" effect.
But the code is changing twice bit 3 of fffa03 (although it doesn't use the blitter), so I wonder if this can't have a not well known effect on timer B counting.
The game is bugged under Steem too, so it really must use some uncommon method.

Nicolas

[Nyh]

[TImer B interrupts are delayed by 2 lines on each VBL, which creates a "scrolling rasters" effect.
But the code is changing twice bit 3 of fffa03 (although it doesn't use the blitter), so I wonder if this can't have a not well known effect on timer B counting.
The game is bugged under Steem too, so it really must use some uncommon method.

My doc's say writing to the AER when interrupts are enabled may cause an interrupt. If I read the documentation correctly writing to bit 3 in AER may cause an extra count on the timer B register, so flipping the bit may count as one extra scan line. I doesn't say whether setting or resetting the bit will cause an extra count (or it might even be dependent on the state of the DE signal itself). I think the only way to say for sure is testing on real hardware.

Hans Wessels

[npomarede]

[TImer B interrupts are delayed by 2 lines on each VBL, which creates a "scrolling rasters" effect.
But the code is changing twice bit 3 of fffa03 (although it doesn't use the blitter), so I wonder if this can't have a not well known effect on timer B counting.
The game is bugged under Steem too, so it really must use some uncommon method.

My doc's say writing to the AER when interrupts are enabled may cause an interrupt. If I read the documentation correctly writing to bit 3 in AER may cause an extra count on the timer B register, so flipping the bit may count as one extra scan line. I doesn't say whether setting or resetting the bit will cause an extra count (or it might even be dependent on the state of the DE signal itself). I think the only way to say for sure is testing on real hardware.

Hans Wessels

Hi, that's interesting, what doc are you using ? I couldn't find a doc that makes a relation between timer B and bit 3 (I'm using the MFP doc at wiki/index.php/MFP_MK68901 for instance)

As the game is changing this bit twice during active interrupts (before doing BCLR.B #$0000,$fffffa0f + RTE), this would clearly enter the case of "changing AER when interrupt is ON".

From the expected game behaviour, changing the bit would not generate a new interrupt, but it would "simulate" a new event on the timer b event count pin, thus decrementing twice timer b count even if no new real of end of line was present.
Since changing AER will create an event on a 0->1 or 1->0 transition, perhaps we first have an event count when DE is disabled, then bit 3 is changed, which will create a new event count when DE is enabled again ?

In that case, would it mean that depending on AER bit, the timer B interrupt could happen either when DE is disabled and right border is displayed (around cycle 404 as usual), or when DE is enabled and we exit the left border (around cycle 56) ?
I'm not sure having a timer B interrupt when DE starts would be useful, but it could be interesting anyway.

Anyone feeling like plugging his ST to test, or should I take mine out of the box ?

Edit : the official pdf data sheet is in fact much clearer on the relation between timer B and bit 3 of AER, I should have started by reading this instead of the "simplified" html version, thanks to Hans for pointing this.

Nicolas

[ijor]

Edit : the official pdf data sheet is in fact much clearer on the relation between timer B and bit 3 of AER,...

Both timers (A & B) when working in count event mode have an interrupt associated channel. The AER bit of this associated interrupt channel determines the active polarity of the timer. Changing bit 3 reverses the polarity of Timer B, and would count on opposite edges of DE.

As the game is changing this bit twice during active interrupts (before doing BCLR.B #$0000,$fffffa0f + RTE), this would clearly enter the case of "changing AER when interrupt is ON".

It doesn't matter here if interrupts are on or are off, it matters if the timer is enabled and in event count mode. Changing the AER bit won't produce an interrupt per se here (that is only true for PORT interrupts, not for timers), it might produce an event count.

In that case, would it mean that depending on AER bit, the timer B interrupt could happen either when DE is disabled and right border is displayed (around cycle 404 as usual), or when DE is enabled and we exit the left border (around cycle 56) ?

Yes, that's correct.