| From: | Thilo K�hler |
| Date: | 21 Jun 2001 at 14:56:54 |
| Subject: | Re: cia timing |
Hello amorel
> QWuick response btw, I guess you code mostly at night too? ;-)
I code 24h a day ;-)
> That is what I have(Anthon Reinhauer or how oine spells his name)
> converted a c source. I reckon yours works about the same way?
I just put up an CIA interrupt with setintvector_. It`s not very hard.
Btw: I noticed that using the paula interrupt is a bit easier
(but more hardware banging!) and provides better timing,
because it has not the problem with the detuning when
CPU is on heavy load. (Also this problem seems to
be very slighly) Disdvantage is that you loose one
audio channel. I also implemented this successfuly.
> See my other email. The RIfastserial library does not use a serial
> interrupt and uses a 1<->1 handshaking. It`s a hack and it`s fast, but not
> too bad to do imo.
Yes, saw RIFastserial. Seems to be a similar hack like mine.
Difference is that my code can be executed within interrupts
because it is pure ASM, as RIFastserial consists of Blitz Commands.
As I am also a musician, my intention is to write
a professional application that supports several
serial ports like the silversurfer and is system friendly.
You can not write a hardware hack for all serial
connectors out there, that is because serial.devices exist.
My programm will support up to 4 MIDI outs.
(limitation is only the gadgets in the prefs-gui,
could easily increased)
> C=Better method would be:
> C=Install a seperate thread. This thread should
> C=have a very high priority and put itself into sleep
>
> That`s an interesting idea. I did screw around with upping the priority of
> the main application, but it did not seem to have much effect. My main
> concern was that if you would drag a window the notes would drop until the
> window had been redrawn. I wonder if a very high priority seperate thread
> would be influenced by things as window dragging. The Amiga does give high
> priority to user input, that`s one of the thing the gui is so responsive.
> Actually I think most module/octamed/etc. playroutines use a cia interrupt
> timing, or similar as they`re all very unsensitive to system load.
If you manage MIDI out within a thread instead of an interrupt
you have two problems:
- your thread can`t do things parallel like open/close
windows, do graphic output and MIDI output.
Thus install a seperate thread with a higher priority than
the main thread that has only one thing to do: MIDI output (or input)
This thread will NOT be blocked by window sizing, menues
and similar stuff.
- thread is blocked by other threads with higher priority
Solution: put it very high. I think setting priority over 25
will prevent the thread from suffering from user inputs.
I will see in the near future how good the performance is.
> C=But it could be even more efficient than an interrupt
> C=because an interrupt is called every MIDI tick,
>
> I do not notice much performance loss with an interrupt going at so many
> ticks, but it can`t be bad to improve efficiency =)
Yes, performance is very good, i know. Currenlty I have "your"
solution implemented.
I don`t know which resolution you are
trying, I use 192 ticks per quarter.
But if there is no data to
send within a cetain period of time (say one quater),
my "thread solution" will sleep all the time and consume 0% CPU
while the interrupt is caused 192 times, only to notice
that there is no data to send.
At 192 ticks per quarter there are about 95% of the interrupt
calls unneccessary.
Ciao,
Thilo
---------------------------------------------------------------------
To unsubscribe, e-mail: blitz-list-unsubscribe@netsoc.ucd.ie
For additional commands, e-mail: blitz-list-help@netsoc.ucd.ie