Input stops working until reset for some software

[ijor]

What might happen if the higher priority interrupt is constantly firing? I'm thinking, for example, of severe noise on MIDI ports causing it to think its buffer is full?

The MIDI port can't provoke interrupts at a higher frequency than the configured baud rate no matter what. This is basically true for any UART that is clocked internally. As long as the software can keep with data arriving at full speed, it shouldn't be any problem.

But certainly software that is misbehaving can leave TOS input logic in an unstable case. It is well known that you must be careful when disabling interrupts for too long, e.g.. Otherwise if there are pending interrupts, TOS might not be able to recover. I don't have much experience with MIDI, but I assume that something similar could happen if the software is is not processing the MIDI serial stream correctly.

May be there is an issue with game adaptations that didn't consider MIDI. The OP should test original software, just in case.

[ijor]

I re read the thread because I think I misunderstood the issue. I thought the problem was related to software using MIDI, but seems it's actually software that does not.

A long cable conceivable can provoke a MIDI interrupt. It won't flood the hardware, as said, it won't be able to generate interrupts at a high frequency. But it might generate an interrupt. Now, if MIDI interrupts are enabled, which they are by default, and the software doesn't handle them properly, it could create all sort of problems.

So either disconnect the MIDI cables, or at least attach them to some MIDI device which might need to be turned on. Perhaps just a loop-back connector would be enough.

[Cwiiis]

I re read the thread because I think I misunderstood the issue. I thought the problem was related to software using MIDI, but seems it's actually software that does not.

A long cable conceivable can provoke a MIDI interrupt. It won't flood the hardware, as said, it won't be able to generate interrupts at a high frequency. But it might generate an interrupt. Now, if MIDI interrupts are enabled, which they are by default, and the software doesn't handle them properly, it could create all sort of problems.

So either disconnect the MIDI cables, or at least attach them to some MIDI device which might need to be turned on. Perhaps just a loop-back connector would be enough.

Would it be possible to run a program that disabled midi interrupts to fix this issue in software? I only use midi when I boot in mono, it would be neat to be able to put something in AUTO to fix this rather than having to shuffle cables.

[Badwolf]

A long cable conceivable can provoke a MIDI interrupt. It won't flood the hardware, as said, it won't be able to generate interrupts at a high frequency. But it might generate an interrupt. Now, if MIDI interrupts are enabled, which they are by default, and the software doesn't handle them properly, it could create all sort of problems.

Thanks for the info, Ijor & sounds like a good theory.

BW

[ijor]

Would it be possible to run a program that disabled midi interrupts to fix this issue in software?

Probably yes.

[Cwiiis]

I got as far as building an ST binary, but I've no idea about TOS/GEMDOS/XBIOS or indeed 68000, so it'll probably be a while before I can write that program, assuming it's possible...

From what I've gleaned so far, keyboard and midi share the same interrupt, so it wouldn't be a case of just disabling the interrupt... Perhaps you could replace the system interrupt handler with a handler that automatically discards MIDI events (presumably it could just check the type of event and return if it's a MIDI event, otherwise fall back to the system handler)? This presumes that affected games aren't already just overriding the system interrupt handlers... This also presumes that this is possible and wouldn't cause some conflict, though I expect the necessary code would only be a few bytes, so given disk drivers seem to have variable size, I assume there's some space somewhere for this and some provision to mark the memory as used (I've really no idea how 68000/TOS work...)

My presumption is that a game is using its own IKBD handler (Is there even a system/default handler? Presumably GEM has one, but would a TOS app have access to that?) and letting MIDI events flood the queue by either not processing them fast enough or not processing them at all. Once the queue is full, presumably no further events are queued until it gets flushed, which also presumably in these cases, never happens.

[ijor]

I got as far as building an ST binary, but I've no idea about TOS/GEMDOS/XBIOS or indeed 68000, so it'll probably be a while before I can write that program, assuming it's possible...
From what I've gleaned so far, keyboard and midi share the same interrupt, so it wouldn't be a case of just disabling the interrupt... Perhaps you could replace the system interrupt handler ...

You need to disable interrupts directly at the Midi ACIA chip. I suggest you open a different in thread in some of the software subforums about exactly how to do it. This is best answered by the people more familiar with TOS.