Alpine "Stop" Button Behavior

[+cubanismo]

Does anyone have details on what the Stop button does on Alpine boards? My understanding is it can force an interrupt on the 68k, but I can't find any Alpine Board schematics to determine how exactly it accomplishes this. I believe the Alpine connector on the Jaguar PCB side maps to U32 on the Jaguar schematic, which breaks out the VPA, FC1, FC0, DREOL? (This one is pretty blurry, but at any rate, corresponds to the 68k's Address Strobe), and IPL2 nets. However, I'm unclear which of these signals the Alpine uses and what it does with them to generate an interrupt. Is it sufficient to wire a switch between the ground pins and IPL2, or do I need to do something with VPA as well, or make sure it holds the signal(s) low until one or more of the output pins changes to some state?

[Zerosquare]

Here's a partial schematic made by Glenn Brunner: https://www.jagware.org/jag_uploads/dev/glenn_bruner_atarishowroom/pdf/alpine_memory.pdf

The STOP button is at the bottom center.

[+cubanismo]

Awesome, thanks. Now I'm wondering what that GAL16V8 is doing though. Probably time to just wire up the switch with a resistor and see if it does anything on its own. Doesn't look like it'll be damaging anything on its own.

[+cubanismo]

Ah, also, any idea what the values for the unlabeled resistors are? The R1 and R23 pull-ups in particular.

[Zerosquare]

From pictures, I'd say they're either 1K or 10K (probably 1K, since almost all of the other ones are the same value):

[+cubanismo]

Yeah, little fuzzy, but I think that's gotta be brown/black/red bands = 1k. Thanks for digging this stuff up.

 

[+cubanismo]

Drat, there's no VCC on the stop cable. Is it reasonable to source +5V from the VCC side of L29, right next to the stop cable header on the Jaguar PCB? Just need something to hook up to R23 to pull the IPL2 line high when the button isn't pressed.

[Zerosquare]

Yeah, it should be fine.

 

You can even solder the pull-up resistor inside the Jaguar, that way you'll only need two wires for the switch. And since IPL2 and GND are right next to each other on the stop cable header, you can even reuse the push-button from a PC case:

Edited November 21, 2021 by Zerosquare

[+cubanismo]

I tried to wire this up today to test it out. It doesn't seem to be working. This picture shows my understanding of the connection points I need to use on the Jaguar PCB:

 

 

So I soldered a 1K resistor from U32's IPL2 to L29's VCC, a ground wire to GND on U32, and another wire to the side of the resistor on U32's IPL2. I connected both wires to a switch such that the circuit is closed when the switch is pressed. Then I started up the Skunk GDB stuff (jserver + a 68k gdb connected to it), which from what I can tell loads a stub program onto the Jaguar that installs an exception handler that should break into gdb when any exception occurs. I then used gdb to load a simple hello world example program and run it.

 

However, when I press the button, little happens. The screen flickers or pauses a bit, but no exception appears to be triggered. I tried again running Jagmania from the BJL BIOS, which I thought similarly loads up a bunch of exception handlers that jump back to the BJL boot menu, but again, pressing the button just stops Jagmania in its tracks for a while, but when releasing it, the program just continues to run. The button is clearly doing *something* to the processor, but either it doesn't seem to be generating an exception as I'd expect, or I don't have the right exception handling stuff set up.

[+cubanismo]

Looking at the 68000 manual (https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf), it looks like I've probably underestimated the complexity of what's needed to make the stop button work. I assume this is why the other signals on the stop button cable exist and are wired up to a programmable logic device. These signals route over the stop button cable (Based on the Jaguar PCB schematic here and page 3-10 of the 68k manual above):

 

/VPA - /VPA (Valid Peripheral Address and Auto-Vector Interrupt) pin on the 68k - Input from the 68k perspective

/DREQL - /AS (Address Strobe) pin on the 68k - Output from the 68k perspective

FC0-FC1 - FC0 and FC1 (Function code, bits #0 and #1) pins on the 68k - Output from the 68k perspective

/IPL2 - /IPL2 (Interrupt Priority Level, bit #2) pin on the 68k - Input from the 68k perspective

I think what I want to do is assert IPL2 with the switch (Which is all I'm doing so far), but then also handle an Interrupt Acknowledge cycle using the rest of the signals, as outlined in the 68k manual section 5.1.4, CPU Space Cycle, starting on page 5-9, but specifically the following page covers interrupt ack cycle timing/operation. This is pretty complex. I think I'd need to wait until FC1 and FC0 are high (I'm assuming FC2 isn't relevant for some reason), also wait until /AS (or /DREQL in stop-cable terms) is asserted, possibly then check that A3 is high (Not available on stop cable, Alpine may have it via the cart connector, something called BA3 is routed into the programmable logic chip), then assert /VPA to indicate interrupt auto-vectoring should be used.

 

I guess I could get at A3 by soldering a wire to the m68k's address line or if I wanted to be exactly like the Alpine, to J2. Then I suppose it's just one big AND operation with a few NOTs in there, but it's still enough logic it'd probably require at least a perf board or something to wire it all up. Still, this is a lot more work than I thought I was getting into here.

 

I could also try just bridging the same signal I'm putting into IPL2 over to VPA I suppose and see what happens ?

[Zerosquare]

There may be some debouncing needed, too.

[+cubanismo]

Debouncing of the IPL2 switch? I don't see anything for that on the Alpine board schematic. The switch seems to be wired straight to the /IPL2 line on U32. Did you mean one of the other signals?

 

FWIW, I confirmed FC2 can be safely ignored because FC2/FC1/FC0 == 0/1/1 is an undefined/reserved state, so if FC1/FC0 == 1/1, it can be assumed the function code is 1/1/1. Page 6-3, section 6.1.4 "Reference Classification" in the above manual.

 

I'm also wondering if what happens now is that since I'm not asserting /VPA, the processor assumes a non-auto-vectored interrupt and tries to fetch the vector off the data bus bits 7-0, which I suppose in all likelihood would be 0. Perhaps that ends up running the user exception, which would be the only one most programs would override to handle vblank, and they just get stuck looping in their vblank handler until the button is released. This matches up with the behavior of Jagmania AFAICT. I'd kind of expect a bus error or something given no one would be asserting /DTACK either, but maybe the processor just soldiers on somehow.

[Zerosquare]

51 minutes ago, cubanismo said:

Debouncing of the IPL2 switch? I don't see anything for that on the Alpine board schematic. The switch seems to be wired straight to the /IPL2 line on U32.

You're right. I guess asserting IPL2 multiple times doesn't matter.

[+cubanismo]

Just leaving a note for myself/others, from page 12 of the Jaguar Docs "Getting Started (v10)" document, there's a pin numbering diagram of the alpine stop cable:

[JagChris]

May I ask what you are trying to do? 

[+cubanismo]

To distill it down from the above, add a button to my Jaguar that breaks into the debugger when pressed, like the Alpine stop button supposedly does. I'll have more updates here soon, I've been working on this.