TOS/GEM interrupt latency

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

TOS/GEM interrupt latency

Postby Foxie » Sun Jan 21, 2018 1:01 am

To receive MIDI data without losing bytes, you need to respond to an ACIA interrupt within 0.32ms.

I wrote a test program that sets up a timer A interrupt and reads the counter in the interrupt handler to determine how much time elapsed. If I'm doing my maths right, it appears that TOS routinely has an interrupt latency of > 0.2ms, and if you wiggle the mouse around it sometimes jumps to over 0.5ms. So something must be masking interrupts for a long time? Perhaps in the vertical blank or timer C handlers?

Is this sort of latency normal, or am I doing something wrong? It would appear that it's not possible to use an ACIA interrupt to reliably read MIDI data without turning off all other system interrupts. That doesn't sound right to me. Sequencers manage to allow mouse movement during playback and even allow windows to be opened and closed.

Has anyone else measured the typical interrupts-masked time for TOS and GEM?

I'm not seeing this interrupt latency on every interrupt - some happen almost instantly. But the peak within about half a second of measurement is generally > 0.2-0.5.

Weirdly, if I print to the screen during the measurement window (so it scrolls), the latency drops significantly!

The results of the tests are as follows:

Normal, no mouse movement:
234us

Normal, mouse moving:
390us

Timer C and VBL off, no movement:
39us

Timer C and VBL off, moving:
546us

Timer C on, VBL off, no movement:
182us

Timer C on, VBL off, moving:
533us

Timer C off, VBL on, no movement:
39us

Timer C off, VBL on, moving:
312us

So it looks like Timer C handler is particularly bad, but even worse is the ACIA handler.

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2272
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: TOS/GEM interrupt latency

Postby charles » Sun Jan 21, 2018 1:49 am

from what I know
our interrupts can only execute if they fall under a certain amount of time ,

midi I think???? what ever routine it jumps to can only take 1ms or less

if memory serves correct the Atari compendium, I have ...and read , states a lot of this .
but could also be a part of the st internals books

but I think you are wrong about loosing bytes none will be lost cause there is cylindrical buffer to capture these bytes
up to 128 of them at once

id be interested to see some of your midi projects ,,maybe we can port to Atari ?
atari is my lifestyle,not a hobby.
HOLD ON ! ! !,
Im printing unreadable characters ...!

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2272
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: TOS/GEM interrupt latency

Postby charles » Sun Jan 21, 2018 2:45 am

the 68000 permits duplicating traps ...maybe this will help eleviate some h/w

you could have two instances of bios,xbios gemdos calls running at once?

two separate buffers
one for in
one for out ,,,,
these are just illusive thoughts , nothing I am skilled to do at this moment

and to cramp in on this topic ,, the midi on an Atari ive read is bidirectional

I suppose u might not need my input but here is last thing for I say for a while

Code: Select all

'====================================================
'for use within gfa basic 3.5 and higher
'
'
vectors%=0
mvec%=0
msys%=0
'
midivec|=0
midisys|=8
'
midi_buff%=0
'
ibuf|=0
ibufsize|=4
ibufhd|=6
ibuftl|=8
ibuflow|=10
ibufhi|=12
'
thruflag!=FALSE
midithru%=0
'
console|=2
midi|=3
'
GOSUB main
'
END
'
' ***********************************************
'
PROCEDURE main
'
oldmibuf%=0
mymibuf%=0
'
oldmsize%=0
mymsize%=0
'
character|=0
mymsize%=6400
'
vectors%=XBIOS(34)
'
mvec%={vectors%+midivec|}
msys%={vectors%+midisys|}
midi_buff%=XBIOS(14,2)
oldmibuf%={midi_buff%+ibuf%}
oldmsize%=INT{midi_buff%+ibufsize|}
'
DIM a|(mymsize%)
mymibuf%=V:a|(0)
'
RESTORE thru
FOR x|=0 TO 48 STEP 2
READ a%
a$=a$+MKI$(a%)
NEXT x|
midithru%=V:a$
'
{midi_buff%}=mymibuf%
INT{midi_buff%+ibufsize|}=mymsize%
INT{midi_buff%+ibufhd|}=INT{midi_buff%+ibuftl|}
'
PRINT INT{midi_buff%+ibufsize|};" byte MIDI buffer established."
PRINT "Waiting for MIDI...(ESC to exit, C to clear screen)"
'
'
WHILE NOT character|=27
'
WHILE BIOS(1,midi|)=TRUE
a|=BYTE(BIOS(2,midi|))
PRINT a|;" ";
WEND
'
'
WHILE BIOS(1,console|)=TRUE
character|=BYTE(BIOS(2,console|))
IF character|=ASC("C")
CLS
LOCATE 1,1
PRINT "Waiting for MIDI...(ESC to exit, C to clear screen)"
ELSE IF character|=ASC("T") OR character|=ASC("t")
CLS
LOCATE 1,1
IF thruflag!=FALSE
GOSUB thru_on
thruflag!=TRUE
ELSE IF thruflag!=TRUE
GOSUB thru_off
thruflag!=FALSE
ENDIF
ENDIF
WEND
'
WEND
'
{midi_buff%+ibuf|}=oldmibuf%
INT{midi_buff%+ibufsize|}=oldmsize%
'
IF thruflag!=TRUE
CLS
LOCATE 1,1
GOSUB thru_off
ENDIF
'
ERASE a|()
CLR a$
'
RETURN
'
PROCEDURE thru_on
{vectors%+midivec|}=midithru%
PRINT "MIDI thru enabled."
RETURN
'
PROCEDURE thru_off
{vectors%+midivec|}=mvec%
PRINT "MIDI thru disabled."
RETURN
'
'
'
thru:
DATA &H1211
DATA &H801
DATA &H01
DATA &H6700
DATA &HFFF8
DATA &H1340
DATA &H02
DATA &H3228
DATA &H08
DATA &H5241
DATA &HB268
DATA &H04
DATA &H6500
DATA &H04
DATA &H7200
DATA &HB268
DATA &H06
DATA &H6700
DATA &H0C
DATA &H2450
DATA &H1580
DATA &H1000
DATA &H3141
DATA &H08
DATA &H4E75
'
'



atari is my lifestyle,not a hobby.
HOLD ON ! ! !,
Im printing unreadable characters ...!

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: TOS/GEM interrupt latency

Postby Foxie » Sun Jan 21, 2018 3:34 am

charles wrote:but I think you are wrong about loosing bytes none will be lost cause there is cylindrical buffer to capture these bytes
up to 128 of them at once


The issue is that although there is a buffer, it uses the interrupt handler to transfer data into the buffer. So if the interrupt handler gets delayed, data could possibly be lost before it gets transferred to the buffer.

Considering the worst interrupt delays happen when moving the mouse, it's possible that the ACIA interrupt handler continuously checks the MIDI input during running. That would avoid losing data, but I bet the code looks really weird. I don't really know why handling a simple ACIA interrupt takes TOS so long!

charles wrote:id be interested to see some of your midi projects ,,maybe we can port to Atari ?


I'm mainly interested in primarily developing for the Atari, since the IBM is just a huge mess these days!

The modem port MIDI interface I've designed will work on other computers too, and some drivers already exist that can use it. But I'd encourage everyone to switch to Atari for music!

As for designing a printer port MIDI interface, that will be Atari-only. It might also work with the Amiga - I stumbled across full specs for the CIA chip, and electrically it looks safe to do what I have in mind. That could be useful in conjunction with the Amiga EmuTOS port, since fast Amigas are cheaper than fast Ataris. But such a device should never be connected to an IBM, since it will destroy the printer port.

User avatar
Atari74user
Captain Atari
Captain Atari
Posts: 269
Joined: Mon Aug 10, 2009 8:00 pm

Re: TOS/GEM interrupt latency

Postby Atari74user » Sun Jan 21, 2018 10:26 am

Nice online resource, never stumbled across this before, a lot of work has been put in to compile this on the internet: http://www.bighole.nl/pub/mirror/homepa ... _guide.htm
Atari Falcon 14mb, 68882, Dual 8gb CF, Steinberg FDI & Analog 8
Atari Jaguar, Rotary controller, Skunkboard & Cat Box
Atari 520STFM 4mb, TOS 2.06 switcher, OverScan, GigaFile, PARCP-USB, Unicorn-USB, System Solutions MiniS HD, SyQuest drives, ICD Link II, PhatBoy MIDI Controller, Philip Rees 5M MIDI merge box, SoundPool MO4, Steinberg MIDEX, SMP II, Emagic Log 3, C-Lab Unitor 2, Combiner & Export expanders


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: metalages and 3 guests