PIA interrupts from SIO?

[tschak909]

Am curious, I know that the INTERRUPT and PROCEED lines are attached to the first PIA, am wondering if I have to poll the state of those lines, or if an interrupt can be set up?

 

-Thom

[Chilly Willy]

The PIA can interrupt the CPU on either the positive or negative edge of transitions on both those lines. They're part of the PACTL and PBCTL register settings - see the Altirra Hardware Manual (10.5).

[Rybags]

They're not in use by any peripheral or product I know of (but entirely possible one or both is, likely some sort of homebrew).

 

By default there's only the stub OS handler that generally clears the status bit and returns so you'd need at least an IRQ handler if using them.

[AtariGeezer]

I've touched on thus subject before: https://atariage.com/forums/topic/262518-sio-wifi-modem-with-esp8266/?do=findComment&comment=4371533

[phaeron]

SIO PROCEED and INTERRUPT are used by real devices. The 1030 uses them for signaling command completion and carrier detect, while the SX212 uses them for high speed and CD.

 

You can't poll the state of the lines, only read edges via the IRQ.Only one edge polarity can be selected, so if you want both edges, you have to flip the edge mode back and forth on each interrupt. This can also be polled because unlike POKEY, the PIA will set its interrupt status bits even if the interrupt is disabled. However, there's a conflict with the OS VBI handler because the joystick poll code reading PORTA will also clear port A interrupts.

 

The SX212 handler has to work around the problem with not being able to sense the high speed mode. On reset, it blindly sends +++ in both low speed and high speed to resynchronize its high speed state with the device.

 

[baktra]

Other "devices" using those interrupts are data recorders upgraded with RAMBIT TURBO TAPE (INTERRUPT) or TURBO 6000 (PROCEED). But these are very rare.

And example of such interrupt handler: https://github.com/baktragh/turgen_tape_loaders/blob/master/gb_rambit/modern/rambit_mono_modern.asm

Edited November 13, 2019 by baktra
Grammar and spelling

[tschak909]

I am wanting to use PROCEED/INTERRUPT for different purposes, e.g. INTERRUPT for notifying the system that a packet awaits on an N: device, and PROCEED for hardware handshaking on the modem. Does this sound reasonable?

 

-Thom

[ivop]

MIDI Mate also uses them as external triggers for pre-MIDI gear.

 

Edit: the recent MIDI devices (MIDI Muse, XEL/XLD and SIO2MIDI) do not use them.

 

 

Edited November 14, 2019 by ivop

[xxl]

SIOCart also uses the PROCEED and INTERRUPT lines. With SIO commands you can set counters for SIOCart, thanks to which you can periodically generate IRQs and release POKEY generators from this function

[tschak909]

kind of funny nobody has answered my question, but am inferring that what I am asking is reasonable.

-Thom

[ivop]

Sorry. Xxl and I merely named devices that also use the PROCEED and INTERRUPT lines. I guess as long as you don't try loading MP3's over the internet, play them with the SIOCart and save them to a RAMBIT TURBO TAPE, your proposal is reasonable

 

Seriously, it sounds reasonable.

 

Edit: how exactly does the interrupt line work? If it fires, do you have to scan all devices to see which one interrupted you or do you start waiting for a SIO packet from said device that interrupted you?  The latter would be extremely helpful, as multiple devices can share the interrupt line. You could even attach a USB keyboard (with proper USB2SIO conversion) and have it interrupt the Atari every time a key is pressed. Or does it work entirely different?

 

Edited November 14, 2019 by ivop

[phaeron]

There's no standard for sharing the SIO PROCEED/INTERRUPT lines that I know of. The OS will poll the IRQ sources to determine that the PIA is the source of the interrupt and acknowledge it before calling the ISR. Beyond that, there's no OS convention for sharing the IRQ across multiple handlers or a hardware convention for identifying the source on the SIO bus. Some devices just assume they own those lines, others only drive them when they're active and assume they own the whole SIO bus anyway.

 

The one thing that bothers me about using these lines is the interference from stage-2 VBLANK reading the joysticks. Checked the SX212 handler, and it doesn't do anything to mitigate this -- it must just accept the 0.013% chance that the interrupt is lost.

[mellis]

22 hours ago, tschak909 said:

kind of funny nobody has answered my question, but am inferring that what I am asking is reasonable.

-Thom

 

I think it's kind of funny you wrote the above instead of "Thanks to everyone for their insights! I might go ahead an give my idea a try."

[tschak909]

Can I use the OS routine that sets IRQ's to attach to the PIA IRQs for INTERRUPT/PROCEED?

-Thom

[ivop]

Yes, I think you can use:

 

Quote

 

514,515 202,203 VPRCED

Serial (peripheral) proceed line vector, initialized to 59314 ($E7B2), which is merely a PLA, RTI instruction sequence. It is used when an IRQ interrupt occurs due to the serial I/O bus proceed line which is available for peripheral use. According to De Re Atari, this interrupt is not used and points to a PLA, RTI instruction sequence. This interrupt is handled by the PIA chip and can be used to provide more control over external devices.

 

As there's no standard to share this line, perhaps "we" should determine one for this and future devices?  I mean those old modems are obsolete, MIDI Mate/Max are hard to get and I don't think people use the external trigger via SIO. And it's also possible to do the same via the joystick port. I think there's only one piece of software that uses this functionality, which is MidiTrack. SIOCart is not finalized yet, so it could adhere to the same standard "we" decide on. And Rambit Tapes.... well, forgetaboutit

 

Edit: and you have to mitigate the stage 2 VBI problem phaeron mentioned. Perhaps you can set CRITIC (66 $42) or set your own VVBLKD (548/9 $224/5). Guess phaeron can help here

Edited November 15, 2019 by ivop

[tschak909]

Ok, what would such a standard look like?

-Thom

[Rybags]

Setting CRITIC would work - normal SIO does this anyway so unless you want a peripheral that can poll the host adhoc it should work fine.

[ivop]

Thinking about it a bit more, setting CRITIC is only effective if you expect an interrupt. But nobody expects The Spanish Inquisition an interrupt. That's the point of an interrupt I mean you cannot set CRITIC, waiting for an interrupt.

 

I think that even intercepting VVBLKD would not cut it. Eventualy you have to poll PORTA, otherwise the joystick shadow registers don't "work". So the devices should expect that their interrupt could get lost 0.013% of the time. If not acknowledged in time, the device should repeat its interrupt.

 

[Rybags]

Yep, deferred VBlank isn't much use because it occurs after the stick reads.  Immediate would work but then you have the problem of having to supply the entire VBlank codebase which wastes memory.

But IMO CRITIC usage just like other SIO should be fine.  The problem should then only arise if you want the device to be able to poll the computer adhoc.