New mouse project!

[sh3-rg]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

Matthias has mouse-supporting routines & infos. Check about 1/2 way down the page: M D GAMES.

 

His next release will support it

[Tyrant]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

Matthias has mouse-supporting routines & infos. Check about 1/2 way down the page: M D GAMES.

 

His next release will support it

Like I said earlier, I just hope he polls the mouse fast enough to keep up with an 800dpi monster.

[sh3-rg]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

Matthias has mouse-supporting routines & infos. Check about 1/2 way down the page: M D GAMES.

 

His next release will support it

Like I said earlier, I just hope he polls the mouse fast enough to keep up with an 800dpi monster.

 

Yea, that's true. The exact model of mouse isn't chosen yet so he can experiment a bit. If he could make one up as an adaptor I'd be happy to go test all the different flavours I have here & buy a half dozen or so more to test with... I'm pretty hard on my mice & I have to say these Logitech optical mice are great value, if I can have the same type of mouse on my PC, Falcon & Jaguar I'll be happy

[Tyrant]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

Matthias has mouse-supporting routines & infos. Check about 1/2 way down the page: M D GAMES.

 

His next release will support it

Like I said earlier, I just hope he polls the mouse fast enough to keep up with an 800dpi monster.

 

Yea, that's true. The exact model of mouse isn't chosen yet so he can experiment a bit. If he could make one up as an adaptor I'd be happy to go test all the different flavours I have here & buy a half dozen or so more to test with... I'm pretty hard on my mice & I have to say these Logitech optical mice are great value, if I can have the same type of mouse on my PC, Falcon & Jaguar I'll be happy

Talk with him about it. It should be possible. As I once suggested, there should be enough time to poll for changes (and write them into a buffer) inside the sound-rendering interrupt, and I'm pretty sure that runs often enough to keep up with... about 27 inches per second mouse movement at 800dpi from a 22khz sample rate.

[jaguar_fan]

Depending on price I would go for one each ST and Jaguar.

 

Thanks.

[Zerosquare]

sh3 : if you use my firmware, DPI won't be a problem ; it limits the pulse rate to the maximum the ST keyboard processor can accept (I think it's 2000 pulses/second, but it's been a while, I'd have to check.). It can be changed if necessary.

[Matthias]

Hello!

 

... The exact model of mouse isn't chosen yet so he can experiment a bit. If he could make one up as an adaptor I'd be happy to go test all the different flavours I have here & buy a half dozen or so more to test with... I'm pretty hard on my mice & I have to say these Logitech optical mice are great value, if I can have the same type of mouse on my PC, Falcon & Jaguar I'll be happy

 

Here is why i never came up with (--> released ) a PS/2-mouse adapter or something integrated as you plan:

Atari says that the joyports are only good for 50mA, at the timeframe i looked into the topic the majority of ball-mice and all of the optical mice needed more than 50mA so it would have been necessary to add a secure power supply to the adapter.

 

Kind regards

Matthias

[Zerosquare]

That's true, but I think Atari was conservative with the 50 mA specification ; the +5 volt pin on the pads connectors is connected directly to the main power supply through an inductor. Assuming you don't have anything else connected to the other pad port, drawing 100 mA from a single pad port should probably be OK.

 

Anyways, most optical mice tend to require 100 mA, but I've seen a lot of ball mice which require less than 50 mA.

By the way, I'm working on a simple PS/2 adapter right now

[danny_galaga]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

I was wondering that myself. What can you use a Jaguar mouse on? I'd certainly buy one if there were any mouse games! If only Cannon Fodder had mouse support...

[Tyrant]

Okay, while it may be possible to make a mouse for the Jaguar, one would also need to make software to utilize said mouse. Heck, that applies to ANY new hardware made for a video game console.

 

I was wondering that myself. What can you use a Jaguar mouse on? I'd certainly buy one if there were any mouse games! If only Cannon Fodder had mouse support...

As has already been said, the upcoming Impulse X will support mouse input, as will Eerievale, when it is eventually released. Also I believe mice can be used on T2k as a poor-mans rotary.

[+Sauron]

I'd have to say that hacks for mouse support in Cannon Fodder and Syndicate would make both games far more playable. Cannon Fodder with just pad controls is quite playable as-is, but Syndicate would be an order or magnitude better.

[PeterG]

I'd have to say that hacks for mouse support in Cannon Fodder and Syndicate would make both games far more playable. Cannon Fodder with just pad controls is quite playable as-is, but Syndicate would be an order or magnitude better.

Mouse support would definitivly help a lot with these games. Unfortunatly aside from that Syndicate is also very very slow. I tried to play it again because I loved it back in the day and lost my patience. And it even gets worse in later levels from what I remember. This one sadly hasn't aged well for me. :-(

[BuddyBuddies]

I'd have to say that hacks for mouse support in Cannon Fodder and Syndicate would make both games far more playable. Cannon Fodder with just pad controls is quite playable as-is, but Syndicate would be an order or magnitude better.

 

+1

[ovalbugmann]

I think Lars' Ocean Depths CD with the EerieVale demo on it had a few special edition copies sold by him that included a mouse/adaptor for use on the Jag with the EerieVale demo on there. It might have been a ST ball mouse.

[BuddyBuddies]

I think Lars' Ocean Depths CD with the EerieVale demo on it had a few special edition copies sold by him that included a mouse/adaptor for use on the Jag with the EerieVale demo on there. It might have been a ST ball mouse.

 

mine came with a mouse:)

[ovalbugmann]

You got the rare special edition copy with Jag Mouse/adaptor then! I saw one on ebay a year or two ago but was really low on funds/credit so I couldn't get it. Nice score.

[+Stephen Moss]

Matthias has mouse-supporting routines & infos. Check about 1/2 way down the page: M D GAMES.

 

His next release will support it

I may be wrong but as far as I can see that method relies on the mouse outputs basically being two, 2 bit grey codes simlar to the rotary controllers (although they only use one) which is how older wheel mice worked. My understaning of modern optical (and particullay USB) mice is that they output 3 or 4 bytes of data depending on if it has a wheel button thingy or not so I don't think it is that simple.

I do however think the way modern mice output data is better for the Jag as it is scalable so programmers can multiply/devide the values to get the speed they want or even let users calibrate it to speed they prefer and save the scaling value to the cart, additionally that type of output lends it self more easily to the Bank Switching advanded controller type that Atari have mice listed as in the TechRef.

 

sh3 : if you use my firmware, DPI won't be a problem ; it limits the pulse rate to the maximum the ST keyboard processor can accept (I think it's 2000 pulses/second, but it's been a while, I'd have to check.). It can be changed if necessary.

I am quite prepaired to be proved wrong on this but don't modern optical mice basically take two images, compare them to work out how far the mouse has moved between images. If so then it may not be necessary to read the mouse at the rate it can sample the amount of movement, provided the byte values are internally updated regardless of if they are read or not you will always read a movement value out if the mouse if it is moveing. The fact that you only read say one in every 10 samples it is capable of outputting may not be an issue as...

1) The revieved value is scalable as I mentioned before so that can be compensated for

2) Concidering the resolution of the typical Jaguar game screen is about a quarter of that of a modern PC screen you I doubt you would need the same dergee of accuracy and there need less samples per second otherwise a small movement of the mouse would send the cursor right across the screen.

 

But I have not had time to look into a Jaguar mouse fully (it is on my to do list) so I am largely speculating at this point.

 

Here is why i never came up with (--> released ) a PS/2-mouse adapter or something integrated as you plan:

Atari says that the joyports are only good for 50mA, at the timeframe i looked into the topic the majority of ball-mice and all of the optical mice needed more than 50mA so it would have been necessary to add a secure power supply to the adapter.

That's true, but I think Atari was conservative with the 50 mA specification ; the +5 volt pin on the pads connectors is connected directly to the main power supply through an inductor. Assuming you don't have anything else connected to the other pad port, drawing 100 mA from a single pad port should probably be OK.

 

Anyways, most optical mice tend to require 100 mA, but I've seen a lot of ball mice which require less than 50 mA.

By the way, I'm working on a simple PS/2 adapter right now

I have done some testing on my Jag and I have to agree with current limits Atari place on the Jaguar I/O ports, if you absolutely have no other option you could go are far as 100mA per controller port but that is an absolute never to be exceeded value.

The one issue I have with anyone doing that espically for a single controller is that someone who may not be aware that it is taking that much current may later decide to write an 4 or 8 player game for that controller resulting in your Jag going up in smoke as you try and suck 400mA from each controller port as not everyone would think/be prepaired to buy 8 controllers to fully test it and thus blow up thier Jag first.

 

My advice to controller developers (for what it is worth) would be to stick with the 50mA per controller Port limit (12mA/Controller to allow for 4 players) but if exceeding that it can not be avioded do not exceed 100mA per controller port (24mA/Controller to allow for 4 players) and preferably provide your hardware with its own power supply.

[Tyrant]

I may be wrong but as far as I can see that method relies on the mouse outputs basically being two, 2 bit grey codes simlar to the rotary controllers (although they only use one) which is how older wheel mice worked. My understaning of modern optical (and particullay USB) mice is that they output 3 or 4 bytes of data depending on if it has a wheel button thingy or not so I don't think it is that simple.

I do however think the way modern mice output data is better for the Jag as it is scalable so programmers can multiply/devide the values to get the speed they want or even let users calibrate it to speed they prefer and save the scaling value to the cart, additionally that type of output lends it self more easily to the Bank Switching advanded controller type that Atari have mice listed as in the TechRef.

Basically there are two kinds of mice in the world, old Atari/Amoeba mice which, as you say, output the pulses directly as two pairs of square waves, and pc mice which output data serially. The first kind (technically called bus mice) basically they just hook the outputs from the sensor into the computer. They require the computer do all of the processing and basically watch the mouse like a hawk (watching a mouse), as any missed pulses will result in a loss of precision or seemingly random movement. On the ST there is a dedicated processor on the keyboard watching the mouse constantly. It is not left up to the CPU, the CPU just asks the mouse processor how far the mouse has moved since the last time it asked, and it gets told it. This is pretty much exactly how serial mice work, except that in a serial mouse, the dedicated processor is on the mouse itself, and it just reports (when asked), how far it has travelled since the last time it was asked (as well as button states, obv).

 

On the Jaguar you *could* use Jerry to watch the mouse, but like I said you would have to do it on an extremely fast interrupt. A better idea would be to use a mouse with a dedicated processor, either on an adaptor or on the mouse itself. This could watch the mouse and output its data in the bank-switching arrangement atari suggested (look at analog joysticks, it's almost the same scheme). Another alternative would be to hook up a serial mouse to the Jaguar's serial port on the back. The adaptor would be relatively simple to build and it would, again, take the load off the Jag's processors.

 

The problem, however, is that there are currently two games in development which support bus mice (as well as a well known adaptor schematic for ST mice), and it does not seem likely that either Matthias or Lars would want to integrate support for yet another type of mouse which nobody has. What we need is for someone to come up with a really simple adaptor pcb and a simple drop-in bit of 68k code that reads it, and make both available.

 

I have done some testing on my Jag and I have to agree with current limits Atari place on the Jaguar I/O ports, if you absolutely have no other option you could go are far as 100mA per controller port but that is an absolute never to be exceeded value.

The one issue I have with anyone doing that espically for a single controller is that someone who may not be aware that it is taking that much current may later decide to write an 4 or 8 player game for that controller resulting in your Jag going up in smoke as you try and suck 400mA from each controller port as not everyone would think/be prepaired to buy 8 controllers to fully test it and thus blow up thier Jag first.

 

My advice to controller developers (for what it is worth) would be to stick with the 50mA per controller Port limit (12mA/Controller to allow for 4 players) but if exceeding that it can not be avioded do not exceed 100mA per controller port (24mA/Controller to allow for 4 players) and preferably provide your hardware with its own power supply.

I agree. It seems like a hard limit to me, and the Vcc and GND rails supplied to the controller do appear to be the main ones of the system (accidentally shorting them together causes the Jag to crash spectacularly). I've been trying to advise against using bus mice like this for years, but I hadn't considered the power problems.

[Zerosquare]

Stephen Moss : note that the mice ggn talks about would be modified ones, which would include a module to emulate the signals of a real bus (or Atari/Amiga) mouse. So while what you said about the internal workings is true, it would be irrelevent.

 

Regarding the power problems, what both of you said is true, but I think as long as we make it clear that only one mouse should be connected at the same time, and no other controller, things will be fine. I don't believe accidental short-circuiting is a real problem ; if we discover it is, we can include a self-resettable fuse in the mice or in the adapter.

 

Using the serial port on the DSP port would work, but if you want to use older serial-based mice, a JagLink (or similar device) would be required to convert the 5 volts CMOS signals to RS-232 levels. Additionally, remember that the Jaguar UART is buggy ; it can be worked around using a timer to poll the input pin, but it requires a frequently occuring interrupt.

 

I'm currently designing an adapter for PS/2 mice which is pretty simple to build ; it only requires two transistors and some wires. The hardware side is done, and I'm working on the software right now. If I'm not mistaken there's a way to make it work without needing any interrupt. I'll keep you updated

[Zerosquare]

Okay, I've just finished the first test software for the PS/2 to Jaguar adapter. There are a few potential problems to solve but the basic principle seems to works fine.

 

Here's a short video.

[the.golden.ax]

Very cool indeed. +1

 

AX

[sh3-rg]

Great work zerosquare!

[Tyrant]

Okay, I've just finished the first test software for the PS/2 to Jaguar adapter. There are a few potential problems to solve but the basic principle seems to works fine.

 

Here's a short video.

Nice, but upon which principles is it working?

[Zerosquare]

Here's the schematic :

I've added an (optional) second PS/2 port in the case someone wants to do a mouse+keyboard game, or a two-player one with two mice

 

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.

 

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 ?

Edited August 19, 2010 by Zerosquare

[+CyranoJ]

Ok, so you have to read the pulses.. but not in a timing exact way.

 

How much CPU does the actual pulse read take without all the boring delay bits? Because there are surely going to be places in a games main loop you could jump out to read the mouse.

 

EG, Kick off the GPU to do something, immediate return. Read the mouse. Wait for GPU to finish.