Using PotGo on Mouse Port (Port 0)?

[Daedalus]

Does anyone know how it might be possible to write to the PotGo bits of the mouse port without shutting down the whole OS?

Allocating the bits normally gives you the joystick bits fine but not the mouse bits, presumably because Intuition has already allocated them for the mouse. I've tried cheating by ignoring the allocation and writing to the address with the mouse bits masked in but it doesn't seem to have any effect. Doing a Forbid() before writing also doesn't seem to allow me to use the pins, so I'm not sure what exactly is stopping me. Any ideas?

Cheers!

[Photon]

Thread moved to System - although you haven't specified your environment (Workbench version). Do post code! Cheers

[Daedalus]

Thanks I was hoping for a Workbench-independent method, but the code is very simple and looks something like this:

myMask = AllocPotBits(0b0011001100000000);

WritePotGo(0b0011001100000000, myMask);

Delay(50);

WritePotGo(0b0010001000000000, myMask);

Delay(50);

This should turn on pin 5 as an output and set it high / +5V on both ports for around 1 second, then set both pins low / 0V. This only works for port 1 as the allocation returns 0b0011000000000000 (bits 12 and 13 allocated but bits 8 and 9 not allocated). Ignoring the allocation and writing with a mask of 0b0011001100000000 doesn't work, I suspect because Intuition is getting in the way for reading the mouse buttons on pins 5, 6 and 9. Using Forbid() and Permit() around the code above doesn't help.

I've also tried writing directly to the POTGO register ($DFF034), but that didn't work either.

[Toni Wilen]

OS writes to POTGO register every frame. I don't think there are any legal ways to change mouse POTGO bits.

[hooverphonique]

would lowlevel.library SystemControlA SCON_StopInput tag help, maybe?

[Daedalus]

Thanks for the replies guys I was hoping to avoid using lowlevel.library... My ultimate goal was to be able to read a CD32 pad without lowlevel.librar, so it could be used under 3.0 and lower. So far it works fine with port 1, but it would've been great to use it for both ports.

I looked at the SCON_StopInput tag, which would help except the autodocs say it's not reversible, so if I re-enable input.device I might end up with garbage in the input stream. I might try it anyway and see exactly what "garbage" I get.

So, what part of the OS writes to POTGO every frame? I thought Forbid() would stop that from happening but apparently not.

[Toni Wilen]

If you only want to read CD32 pad, why not do the pad read in vblank interrupt? In interrupt routine first store original POTGO, poke POTGO directly/read pad, restore original POTGO, exit. No need to care about what OS does

If you want to read it in non-interrupt code, you need to disable interrupts, poke POTGO, restore POTGO, restore interrupts. (OS reads it in vblank interrupt)

[Daedalus]

Good idea! I'll give it a go - thanks!

[Daedalus]

Okay, so both of these approaches appear to work with a proof-of-concept joypad tester (thank you!), but the tight timing in the vertical blank causes some weirdness so I'll go with the Disable()/Enable() option. Next question though: How can I do timing with interrupts disabled? A tiny delay is needed after writing the bits I need to POTGO before I read the response. When interrupts are enabled it's fine of course, but I can't use a CIA timer or Delay() when interrupts are disabled because it pops all interrupts straight back to enabled (understandably).

Currently I'm simply busy-looping (5000 reads from a CIA address appears to do it), but that seems wrong! According to the Hardware Reference Manual, those lines need around 300 microseconds to discharge their capacitors and switch modes, so how do I introduce such a wait without using interrupts?

[Toni Wilen]

I am not sure if HRM is correct, even official lowlevel.library code has only few CIA access "delays" between setting POTGO (third button) to output mode and data=1 before starting read sequence.

It looks like I'll have to measure the delay

[Daedalus]

Well, with no delay I effectively get garbage during reading, and with a very short delay I seem to either misread the first button in the stream (blue), or just generally don't get a 100% reliable readout. I haven't measured it myself, I must hook up a scope and see what's actually happening.

It's interesting that lowlevel.library only delays a few cycles... It would certainly help to fit the reading code inside the vblank interrupt.

[Toni Wilen]

I checked it using a scope. A1200, scope connected to mouse port middle button line.

Interestingly full high to low transition takes only about 24us (from 5v to 0v) but when going from low to high, first ~3v change takes 24us, the rest takes milliseconds. I assume about 3v is detected as high state by the pad or at least lowlevel code would not work.

[Daedalus]

Yep, anything above 2V is acceptable for logic high. That's strange, further investigation needed at my end so to figure out why I'm getting such unreliable readings without a substantial delay... Thanks for checking that!

[Toni Wilen]

Bad capacitors?

I measured it without CD32 pad connected, I'll retest it with pad connected.

[Daedalus]

Oops...

Found the problem, it was only after trying the code on another A1200 that I found I could reduce the delay down to around 10 reads instead of 5000. I then started investigating the motherboard of my first A1200, and found that about 18 years ago I had added a couple of capacitors to the pot lines in order to increase the sensitivity of analogue joysticks. Totally forgot about that! But thanks Toni for putting me on the right trail!