New mouse project!

[Zerosquare]

You can more or less do that, but the delay is active, not passive ; it's controlled by the device, so you have to keep reading an input untils it toggles.

What I don't know yet is if there's a risk of the 68k (or DSP, if we move the code to it) actually being preempted long enough to lose sync.

[Starcat]

This looks really promising! Keep up the great work Zerosquare! I can't wait to see more of it.

[Tyrant]

The principle is pretty simple : the PS/2 protocol uses serial communication, with one data line and one clock line (bits are sent one at a time). My code is just a straightforward implementation. Synaptics has made available a nice document with all the details.

When I was looking at this a while ago I found this guide quite helpful. http://www.computer-engineering.org/ps2protocol/

 

One potentially troublesome thing : you can poll the device whenever you want, but the clock signal is generated by the device so you have to keep polling the inputs regularly until the communication is finished ; the high and low states can be as short as 30 µs. Also, the data bytes transmitted can be separated by "pauses" which waste time.

 

At the moment the code is 68k-based ; it works, but I'm not sure if it would be OK in a finished program where the 68k could lose arbitration to the GPU, DSP, Blitter or op. So it would probably be better to use the DSP, but I'm not sure if the code should run in a timer interrupt or just use standard loops.

So, one question for Jag developers : what would work best for you ?

None of my projects are really at a stage where I have any real opinion on that. I suppose a lot of it is application dependant. However most people will probably just be using the DSP for sound generation and nothing else, and those who are doing more complex things with it will be good enough with risc asm to adapt any code you supply to their needs, so I'd probably say go with whatever is likely to be most useful, and assume the dsp will only be running sound.

[Zerosquare]

I've reread the PS/2 documentation carefully, and it seems that the device is allowed up to 25 ms of delay before responding, and up to 20 ms of delay between bytes (a standard mouse position uses three bytes). Though the mice I've tested (apart from one) don't take nearly as long, it's a very wide margin and it's probably going to be a problem in practice. Basically, it means we can't expect the mouse access to last only a short time ; we'll have to poll the joystick port constantly, at least once every 25 µs (since the minimum clock state duration is 30 µs, and we need a bit of leeway), so a 40 kHz timer interrupt will be required. It also cannot be merged with the audio interrupt, as most games use a lower sample rate.

 

Another problem is that joystick port accesses don't seem to be local to Jerry, as I had more or less assumed ; apparently, they go through the main bus. Consequently, using a simple loop without interrupts won't work, as it would completely saturate the bus. And even if we use an interrupt, the bus usage may still be too high.

 

I thought the problem was solvable by pausing the device when you're not ready -- the PS/2 protocol allows this, but it turns out you can only do it between bytes, not during the transmission of a byte ; I didn't read the documentation carefully enough the first time. So that won't fix the problem.

 

To sum up, here are the options I'm thinking about :

 

1) find a specific model of mice that communicates quickly enough, and only support this one. The Logitech optical mice I have seem to fit this criteria ; some of the older ball mice I've tried are slower.

 

2) add a small microcontroller (a cheap, 8-pin one would do fine, I think) to act as a bridge ; it would allow the code to access the joystick port without needing any specific timing or wasting bus bandwidth. This is the most convenient options for coders, but it makes the adapter a bit more complicated.

NOTE : Rotary controllers, Atari 2600 paddles and other controllers could possibly be used in the same fashion, with the same advantages.

 

3) forget about the whole thing, give up, and only use Atari/Amiga mice with the Jag

 

I'm leaning toward option 2, but before developing it further, I'd like to know if it's worth it, i.e. if developers would support it. Come on Jag coders (other members of Jagware, Reboot, Matthias, Starcat & others) -- I need your opinion !

Edited August 23, 2010 by Zerosquare

[+CyranoJ]

2) add a small microcontroller

 

Go with this one. Who cares if it adds $5 to the overall cost

 

It's something we'd definatly consider using, *especially* if a read-once rotary can be built

[+Stephen Moss]

To sum up, here are the options I'm thinking about :

 

1) find a specific model of mice that communicates quickly enough, and only support this one. The Logitech optical mice I have seem to fit this criteria ; some of the older ball mice I've tried are slower.

 

2) add a small microcontroller (a cheap, 8-pin one would do fine, I think) to act as a bridge ; it would allow the code to access the joystick port without needing any specific timing or wasting bus bandwidth. This is the most convenient options for coders, but it makes the adapter a bit more complicated.

NOTE : Rotary controllers, Atari 2600 paddles and other controllers could possibly be used in the same fashion, with the same advantages.

 

3) forget about the whole thing, give up, and only use Atari/Amiga mice with the Jag

 

I'm leaning toward option 2, but before developing it further, I'd like to know if it's worth it, i.e. if developers would support it. Come on Jag coders (other members of Jagware, Reboot, Matthias, Starcat & others) -- I need your opinion !

I must have missunderstood as I though you were already using a microcontroller, not trying to read it directly. I personally could not see it being done with using a microscontroller interface as I would imagine that reading the serial data directly would be a nightmare.

I have a USB logitec optical mouse at work I took apart when I looked at a mouse controller (not had time to take it further) and as far as I could tell from the data sheet for one of the chips was outputing the data on an SPI bus which microcontrollers can handle easily.

I would suggest not using the DSP via the Jag serial port as that would then preclude the possibility of ever beeng able to write a networkable game with mouse control.

 

If you or Gnn or anybody is going to start mass producing Jaguar mice then we need to decide now what format it will be, I know that there is currently one or two releases and a hand full of mice already out ther but at this time I think the numbers are small enough that a change will not cause to many problems.

As I see it there are two possible output options, grey code as per the rotary controllers or Bank Switch as Atari intended so let us consider the advantage and disadvantages of each...

 

Grey Code output:

Advantages

Compatable with existing Jag Mouse and mouse supporting software?

Firmware should be the same for Jag and ST

Disadvantages

Does not identify itself to Jag software

Requires a lot of reads for X & Y (at least 1 roughly every 2mS if T2K is any indicator) and more if a wheel button is supported as you would need to read an additional row.

 

Bank Switching:

Advantages

Can identify itself to game software.

Easier to read, only require two bank reads.

Disadvantages

Does not support mouse games/demos currently available, unless you add a switch to make change behavior so that is does.

 

Personally I am infavour of the bank swithcing mouse as I think it will require less reads per 20mS (50Hz) with leaves more processing time for other things plus you do not have to read both banks in the same 20mS period.

[Tyrant]

Personally I am infavour of the bank swithcing mouse as I think it will require less reads per 20mS (50Hz) with leaves more processing time for other things plus you do not have to read both banks in the same 20mS period.

I couldn't agree more. To read a bus mouse (or to directly read a ps/2 mouse) would require an absurd amount of processing time being devoted simply to reading inputs, whereas a small cheap processor could do the job on an adaptor and pass the deltas in two banks of data, and still have room for 4 buttons. Adding a third bank would allow for a scroll wheel and up to 16 buttons, and yet take no more effort to read than a normal Jag pad.

[Zerosquare]

Thanks for the feedback.

 

Using Grey code (the standard Atari mice and rotary encoder format) is out of the question for me, as it would only partially solve the problem. It would be compatible with the existing solutions, but if we're doing something new, I think it's better to do it properly from the start

 

I will probably not use the Atari bank switching standard either -- I've always found it needlessly complicated, and not flexible enough. Additionally, there are no peripherals or code that actually use it, so there's no compatibility advantage to gain. I think a simpler and better protocol can be created

[Tyrant]

Using Grey code (the standard Atari mice and rotary encoder format) is out of the question for me, as it would only partially solve the problem. It would be compatible with the existing solutions, but if we're doing something new, I think it's better to do it properly from the start

Good move. I would suggest supporting Atari mice as an input option along side ps/2 mice, but that depends on what kind of adaptor you build.

 

I will probably not use the Atari bank switching standard either -- I've always found it needlessly complicated, and not flexible enough. Additionally, there are no peripherals or code that actually use it, so there's no compatibility advantage to gain. I think a simpler and better protocol can be created

Bad move. It really isn't that complex at all, and I can't think of any better method. The way a Jaguar controller is read only supports twenty-four bits of data per controller. You could multiply that by four if you're willing to sacrifice team-tap compatibility, but bank switching really is simple and by far the best option. It barely requires any extra effort on the part of the controller micro or the jaguar programmer. Perhaps you should re-read techref? I don't see why you think it's "needlessly complicated and not flexible enough".

[Zerosquare]

I've just reread TechRef. Here's what I don't like about the bank switching scheme :

 

- there's no explicit synchronization, you have to keep reading to identify which bank is #0. It's not a big problem, but I don't like the principle

 

- there are fixed delays of 40 or even 200 µs you have to follow, even in the cases they may not be needed.

 

- it requires four inputs on the microcontroller. That means that cheap ones with a low pin count can't be used.

 

- it's unidirectional : there is no easy way to send data from the Jaguar to the controller. If we want to support devices that need this in the future (keyboards [think Num Lock / Caps lock LEDs], rumble, etc.), it's going to be a problem.

 

The only advantage I can see is compatibility with Teamtaps, but I don't think anyone is going to use both together.

 

A SPI-like scheme (possibly with added flow control) looks more adequate to me, and it's even supported in hardware by some microcontrollers

Edited August 23, 2010 by Zerosquare

[Tyrant]

Hmm... you make good points. I should be less quick to object to things I think.

[Zerosquare]

Nah, it's fine. I'm asking for comments, I get comments

[Zerosquare]

I've been thinking about the low-level communication stuff for the adapter, and here are my ideas so far :

 

- use the standard I/O configuration for the joypad ports : 4 outputs, 6 inputs. Bidirectionnal schemes use fewer wires, but there's the risk of contention if both sides are out of sync with each other, and decide to both configure the same line as an output.

 

- use flow control. Basically, that means that each side (Jaguar or adapter) cannot transmit until the other side has signaled that it is ready to receive. The effect is that there are no fixed timings to follow, no need for regular polling, and data will never be lost because it wasn't read fast enough. The advantage is clear on the Jaguar side : it means that you can communicate with the adapter whenever you choose, and that the communication can be paused at any time if something with a higher priority occurs (interrupts, for example). On the adapter side, it means that the communication with the Jaguar can be delayed a little to take care of input devices that need strict timing (PS/2 devices fall in this category, and Playstation controllers even more so). A large timeout (a few milliseconds or so) will still be required on the Jaguar side to make sure the game doesn't hang if the adapter stops responding for some reason, e.g. if it's been accidentally unplugged.

 

- transmission from one side to the other will use two wires ; let's call them A and B. Sending a zero will be done by toggling the A wire ; sending a one will be done by toggling the B wire.

Compared to more traditional clock / data schemes, this protocol has two advantages :

* because there's only one signal switching at the same time, no race conditions are possible, so there's no need for any fixed delay (when two signals switching simultaneously are sent through a cable, they may not arrive at the exact same time because of inevitable differences between channels)

* it uses both signal transitions (low-to-high and high-to-low) instead of a single one, so it's faster

It is also quite simple to implement in software or firmware.

 

- after transmitting a bit, each side will wait for the other side to respond by transmitting another bit. This will act both as flow control, and as a way to detect errors (for example, we may use the convention that a 0 reply means OK, and 1 means an error)

 

- beside the A and B wire, the Jaguar side may use a third output wire ( C ) to signal the beginning of a transmission, to avoid the need for manual synchronization. Basically, before the transmission, you would toggle the C wire once and wait for a reply.

 

- I've not decided yet on the higher level stuff, but it will be standard serial stuff : bits sent in order from MSB to LSB (or LSB to MSB, depending on what's more convenient), possibly a parity bit. I've not chosen which four (or five) pins of the joypad port to use.

 

- include an "enable" command that must be sent first to the adapter before using it ; until it has been issued, both output lines from the adapter will be high. This is to ensure compatibility with the standard joypad reading scheme, so that the adapter doesn't try to execute invalid commands, and doesn't return bogus keypresses (it will appear as a standard pad with no key pressed).

Note : there's a potential problem there if you reset the Jaguar without powering it down. But since there are devices which will be confused by it too (PS/2 devices at least), I think it's simpler to just tell people to power down their Jaguar instead.

 

- use Atmel AVR microcontrollers for my adapter. I know Microchip PICs are cheaper, but I personally don't like them and I'm not comfortable developing on them. Note that the communication protocol is independant of this choice ; it will work as well on a PIC or any other microcontroller, so if someone wants to use something else, that won't be a problem.

 

 

What are you thoughts ?

Edited August 30, 2010 by Zerosquare

[Amstari]

I have been trying to play Syndicate and it would great to play it with a mouse. So after some searching I found this topic.

 

I'm considering making a simple mouse interface that works in "joystick mode". So moving the mouse up would be sent to joystick port as moving the joystick up. The same way the track ball for the 2600 can be set to "joystick mode". The drawback is that it wont matter how fast you move the mouse it will only move at the same speed on the screen.

 

This could be used for Syndicate, Cannon Fodder and any other game like this.

 

My electronics knowledge is only basic so any advice or feedback would be appreciated.

[rush6432]

wow... bumping an old thread are we?

[JagChris]

wow... bumping an old thread are we?

 

Old threads are some of the funnest.

[Amstari]

wow... bumping an old thread are we?

 

Not quite a necrobump, but it is an old thread.

 

Some of the people who posted previously are following this thread. I was hoping they might have some advice.

[Zerosquare]

It's probably doable but the results may be disappointing. How well does it work on the 2600 trackball?

[Amstari]

It's probably doable but the results may be disappointing. How well does it work on the 2600 trackball?

 

I haven't tried the 2600 trackball myself but I have been told it works well with Missile Command and Centipede.

[Zerosquare]

IIRC, at least Missile Command has been designed to support the trackball in "native" mode (and it works well indeed), so it's not an useful reference to see whether the "joystick emulation" mode is good. A non-trackball game with a cursor would be better to test that.