Is it possible?

[576XE]

Hi, friends.

 

Some days ago I read two articles about creating Apple II Mouse interface card and it's programming.

_http://www.folklore.org/StoryView.py?project=Macintosh&story=Apple_II_Mouse_Card.txt

_http://www.matarese.com/matarese-files/11673/apple-mouse-programming/index.html

 

Generally, it was some kind of HW module, introducing and standardizing Mouse API (because of it's HW nature) for Apple II.

I'm asking good old HW gurus, Is there an ability to create smth like this?

All the attempts to use ST/AMIGA mouse very tricky and so could not be used in every possible environment.

 

Sorry for my rectangle English :-) and

Best regards from Moscow,Russia.

Edited June 23, 2008 by 130XE

[thorfdbg]

Hi, friends.

 

Some days ago I read two articles about creating Apple II Mouse interface card and it's programming.

_http://www.folklore.org/StoryView.py?project=Macintosh&story=Apple_II_Mouse_Card.txt

_http://www.matarese.com/matarese-files/11673/apple-mouse-programming/index.html

 

Generally, it was some kind of HW module, introducing and standardizing Mouse API (because of it's HW nature) for Apple II.

I'm asking good old HW gurus, Is there an ability to create smth like this?

All the attempts to use ST/AMIGA mouse very tricky and so could not be used in any environment.

 

Sorry for my rectangle English :-) and

Best regards from Moscow,Russia.

 

 

Well, of course it is possible to create something like this, the only problem is really to make sure that programs use the interface you introduced. For the 8bit ataris, I build a very simple mouse interface that connects to the joystick port, but which doesn't require permanent polling, thus no CPU time is wasted. I also added a patch that would insert the current mouse positione into the POT counters, so programs that work with paddles (and use the Os shadow registers) would work fine with the mouse. However, as always, the problem is to prevent the

program from overwriting or deinstalling the patch. As said, the true problem is not the HW, but on the software side.

 

So long,

Thomas

[Rybags]

ST/Amiga mouse works fine, I believe, even with 50 samplings per second. Doing 100 samples or more is no great problem either.

 

There's also the Commodore mouse they specifically made for the 128 (?)

It returns delta values on the Paddle registers, or something like that.

 

So, not worth anyone's time or effort reinventing the wheel.

[576XE]

Hi, friends.

Thank you for your replies.

 

Yes, the Idea was to eliminate mouse data polling and to supply our Atari8 by precooked mouse data.

It may be the first step to create Atari8 mouse API.

 

Times when we looked at floppy drive as at Mersedez have gone.

Now there is the ability to connect SD, CF cards, CD and HD to Atari.

 

Mouse is absolutely needed now!

 

Please, take into account the fact that there are serious Polish programmers/HW gurus

working on SDX128 - modern cartridge based DOS.

I beleive that 128kb still very large space for Atari.

I mean that all mouse soft but some Z-page registers may be enclosed there

and may be accessed almost momentarily.

 

As far as it's concearned standard ways to use shadow/hardware registers in Atari8 I think we need not to search the best possible way.

 

There are many places in atari memory to hide 6 or 8 bites of SIMULATED mouse interface registers protected of soft Reset.

And even if I'm wrong we can save mouse data on flash or HD using our own reset procedure.

And only then their using for mouse driver purposes may become standard in fact.

 

As far as its concearned using AtariST mouse on 8-bit Atari I think that it's only some kind of artefact.

Atari never have intention to use native ST mouse with 8-bit.

1.79Mhz and 8 bit is not the same as 8Mhz and 16bit.

Mouse sampling frequency is not a problem with relatively low 8-bit screen resolution.

The problem is in relatively slow mouse cursor motion. It's not comfortable.

 

Once more, using ST-mouse never leads to standardizing of 8-bit mouse API.

We must to have in mind that it's using may be incompartible with legion of software.

 

By the way, Commodor's mouse is simply some kind of joystick SIMULATION.

Real mouse sences hand acceleration and pass this acceleration to cursor.

 

130XE

[+orpheuswaking]

Sorry for my rectangle English :-) and

Best regards from Moscow,Russia.

 

Definitely not rectangle English More Circular LOL... Actually it was better than most of us English as a first language posters...

 

(My Girlfriend is learning Russian and was impressed, even if she had no idea what any of the Atari stuff was about)

 

Welcome to Atari Age.

[Rybags]

A good black-box solution would probably involve using a PIC or something, which retains delta values for an Amiga or ST type mouse.

 

Plug into the joystick port, then write values to the PORTA register to select nybbles of the data which can then be read.

 

e.g. STRIG0 = left mouse button (as normal)

 

PORTA output nybble select values:

00 - read X delta low nybble, 01 - read X delta high nybble

10 - read Y delta low nybble, 11 - read Y delta high nybble and reset X/Y deltas to zero

 

In theory, you could have the PIC constantly monitoring the mouse. The delta value returned would always be valid so long as the mouse hasn't moved >=127 steps in either direction. So long as it was read at a reasonable rate and the mouse wasn't being moved too quickly, it would work OK.

 

Also, I believe that solutions already exist to connect PS2 type mice to the Amiga/ST. But I think they just read the mouse in PS2 protocol then return values in the fashion of the ST or Amiga.

[thorfdbg]

e.g. STRIG0 = left mouse button (as normal)

 

PORTA output nybble select values:

00 - read X delta low nybble, 01 - read X delta high nybble

10 - read Y delta low nybble, 11 - read Y delta high nybble and reset X/Y deltas to zero

 

In theory, you could have the PIC constantly monitoring the mouse. The delta value returned would always be valid so long as the mouse hasn't moved >=127 steps in either direction. So long as it was read at a reasonable rate and the mouse wasn't being moved too quickly, it would work OK.

 

That's approximately how my mouse interface worked. Two bits of the joystick port had to be configured as outputs, two as inputs. The first output pin acts as a clock signal to drive the mouse counter registers (X & Y) into the two input pins, the second output pin reseted the serial shift register. So basically, a small routine had to shift in the mouse counters bit by bit, eight bits per direction. The left mouse button was the trigger, the right the potentiometer input. The interface was designed to work with Amiga mice (which I had back then). I think ABBUC carries the schematics of this interface, basically one EXOR gate, four 4516 up/down counters and two shift registers, all in CMOS.

 

It was much easier than to connect a PS/2 mouse to the Atari, the protocol is much more cumbersome than that of the (dump) Amiga mouse whose output bins really carry the digitalized

data from the optical sensors.

 

So long,

Thomas

[576XE]

2orpheuswaking

Thank you for your kind words. My special best wishes to your Girlfriend in learning Russian.

Ivan the Terrible.

 

Hi, again,

Many thanks, friends, for your detailed explaination of hard mouse work.

 

You found at one stroke the main idea turning me to come into discussion.

 

It's, of course, the existance of some strange PS/2 to ST mouse constructions, delivering to 'ST world' cheap mouse NIRVANA,

but limiting 8-bit world in it's previous bondaries or even leading it to dead end.

 

I'm not skilled enough to estimate exhaustly your HW desisions. Sorry, bad luck!

My expearence is only MAX233 one chip SIO2PC soldering.

 

Only one thing...

A lot of questions!!!

 

What is the ABBUC opinion on this matter?

Why the great idea RIPed now?

Where can I read about it?

 

Do you hear something about USB 8-bit projects? I think all them are much MORE complicated than even using PS/2 as mouse media.

 

Is there a theoretical ability to make some kind of PIC-driven translator to deliver immediately mouse data to some HW atari registers,

F.E. PBI/ECI but not symply to JoyPort. I want to say that ECI has some interrupts capability while Joy has not.

May be we can examine the ability to create freshly NEW 8-bit Mouse PORT! Parallel, serial or PS/2 type.

 

I beleive it's possible.

 

Any API announses some 'named' standard procedures giving access to periferal devices.

For Apple II they are:

SET_MOUSE

SERVE_MOUSE

READ_MOUSE

CLEAR_MOUSE

POS_MOUSE

CLAMP_MOUSE

HOME_MOUSE

INIT_MOUSE

 

As I can understand their way is:

Detect mouse device in system, initialise it, get mouse-event interrupt, decifer mouse bitwise interrupt status register (motion or button click), skip any further actions when no changes in status or transfer position data to X,Y Atari registers, set motion bondaries,

put deltas for moving cursor along the screen accordingly, etc.

 

All this works almost without CPU cicles stealing.

 

So long,

Evgeni.

[Irgendwer]

...

What is the ABBUC opinion on this matter?

...

 

Just sit and wait to see what the anual hardware contest brings this year...

 

CU

Irgendwer