New GUI for the Atari 8-bit

[flashjazzcat]

Nice write-up on the GUI in this week's Micro Mart (Project-M also mentioned):

 

 

Many thanks to Shaun, and looking forward to the interview.

 

(Unscanned last paragraph on Project-M simply provides a download link).

[philipj]

Wow that's got to be pretty gratifying... that's pretty neat.

[bpj1138]

I myself am a holder of the Earth's greatest physical science theory, ie "Push Gravity" and the greatest blunder in human history.

That's cool, I am a brain too. But there are so many things you could apply your life to... what good is the science unless there is practical application?

 

I myself am a holder of - a Korean BEER!

 

Humanity. Knowing for the sake of knowing. Well, it was cool talking to you. Hopefully you can get me a job.

[flashjazzcat]

Just stumbled across Jaskier/Taquart's article on mouse reading (via popmilo's link to a MWP scrolling article in the FQ thread):

 

Using the Mouse

 

Hard to deduce what's different about this sampling routine just by looking at it, and I notice it has to be resynchronized every so often.

 

Can anyone shed any light on it before I go ahead and give it a spin?

[popmilo]

Just stumbled across Jaskier/Taquart's article on mouse reading (via popmilo's link to a MWP scrolling article in the FQ thread):

 

Using the Mouse

 

Hard to deduce what's different about this sampling routine just by looking at it, and I notice it has to be resynchronized every so often.

 

Can anyone shed any light on it before I go ahead and give it a spin?

That Ironman wiki is full of nice routines (not 100% clear thou...).

 

I don't see how it can work just from VBI and be comparable to 1200 Hz sampling ?

 

It seems to work by finding index in the table of consecutive values and then comparing that with previous index value to determine if mouse was moved left or right... (and up-down).

 

Few problems thou... It uses table of 4 values... And it uses AND #3 after INC...

That "wrapping" doesn't look ok to me...

 

Other thing - it just checks for greater or less value and then increments or decrements x_cursor value by one.

So faster movement wouldn't result in faster cursor change?

 

ps. If it helps:

 

http://ftp.pigwa.net/stuff/collections/atari_forever/Extension/MOUSE/mouse.html

 

And this part might help:

 

"From: Marcin Lewandowski

Message-Id: <199708071635.SAA16514@Leon.mat.uni.torun.pl>

Subject: Re: tqa-mega-demo

To: nadkar@fh-pforzheim.de (Nady Karoly)

Date: Thu, 7 Aug 1997 18:35:43 +0200 (MET DST)

...

> hi... then send me sources codes for both mouses;)

> thanx... papa

> heaven/tqa"

 

Look at the date!

We should ask Karoly about it (Heaven/tqa) - maybe he knows more about it...

Hmm... I wonder what is that "tqa-mega-demo"

[+Philsan]

I think it's a good idea to support Atari and Amiga mouses to have the wider user base.

 

For people wanting maximum speed and smoothness, you could support Irgendwer CMI08 interface too.

http://www.youtube.com/watch?v=KnwpMZAuxZo

Using paddle mode you would have no samplings problems.

 

BTW, ECKN+ is an excellent game, with or without mouse!

[flashjazzcat]

That Ironman wiki is full of nice routines (not 100% clear thou...).

Indeed so. Perhaps we should put forward the mouse routine we designed for inclusion.

 

I don't see how it can work just from VBI and be comparable to 1200 Hz sampling ?

Me neither.

 

Look at the date!

We should ask Karoly about it (Heaven/tqa) - maybe he knows more about it...

Yeah. At first I expected to see a variation of what we'd put together here on the forum, but it looks to me as if it would be a step backwards. It demonstrates that there's no such thing as a free lunch, apparently. Interesting nevertheless, though.

 

I think it's a good idea to support Atari and Amiga mouses to have the wider user base.

Absolutely, and it's already done.

 

For people wanting maximum speed and smoothness, you could support Irgendwer CMI08 interface too.

Agreed.

 

Using paddle mode you would have no samplings problems.

Yes, but the only thing which concerns me is the resolution of the paddle. If the max X value is 255 or thereabouts, we lose single pixel resolution altogether.

[Rybags]

Pretty sure paddle mode returns delta value, not absolute, ie - offset coords from when you last sampled it.

 

Although that's the Commodore way for it's 8-bit machine's mouse, I don't think Atari ever had a mouse that worked other than the ST way.

[flashjazzcat]

Pretty sure paddle mode returns delta value, not absolute, ie - offset coords from when you last sampled it.

OK - that would work. I must admit I have no clue what's what when it comes to paddles.

[Rybags]

The use of Pots is to give more bits of precision. The generated value has to be done by a custom microcontroller, probably using a resistor ladder on 8 bits of output per channel.

 

It could probably be done digitally as well, but then you'd need to do signalling to tell the device what value/part you're wanting to receive.

 

What would be cool is if there was a low-cost solution that was adopted by lots of people, using the Delta/Pot method. Then you only need to read the thing periodically rather than devote big chunks of CPU time for it.

[kskunk]

It could probably be done digitally as well, but then you'd need to do signalling to tell the device what value/part you're wanting to receive.

The Mouse 1351 transmits the counts digitally over the paddle wires, which makes it quite a bit more reliable than a resistor ladder. The LSB is noise, but this is only because the clock in the mouse is not perfectly in phase with the clock in the C64. The remaining bits can be sent digitally to the paddle register without corruption.

 

Just like on the Atari, paddle values are measured by running a timer inside the C64. So the Mouse 1351 just watches for the 'charge' voltage to terminate, then begins counting in rough synchronization with the C64's pot counter. When the counter crosses the current mouse position, it changes the value of the paddle input digitally, latching the value inside the C64.

 

A modern microcontroller could do this easily.

 

As an aside, the 1351 does send 'absolute' positions, which is helpful if you can't poll at exactly the same time on every VBI. You're expected to handle rollover, to map the mouse onto a large-size desktop, without giving up per-pixel precision.

 

The 1351 guarantees up to 31 counts at 60 Hz or 1860 counts/second. (You only get 31 counts because the MSB isn't used, the LSB is subject to clock noise, and of the remaining 6-bits, 31 is the max distance you can go without confusing the direction/signs.)

 

- KS

Edited August 6, 2011 by kskunk

[+Philsan]

Pretty sure paddle mode returns delta value, not absolute, ie - offset coords from when you last sampled it.

OK - that would work. I must admit I have no clue what's what when it comes to paddles.

"Touch tablet mode" and "paddle mode" have only 255 values and would lower pointer resolution.

"Driving controller mode" don't have this problem.

Knowing that Jon discarded PMG pointer to have 320 horizontal resolution, I would never have suggested to support CMI08 interface if a 320 mode wasn't available.

 

If people are interested, I think Irgenwender has the skills to design a new smaller interface (maybe usb too).

 

EDIT

 

The mode to be used is "driving controller mode" not "paddle mode".

[Irgendwer]

If people are interested, I think Irgenwender has the skills to design a new smaller interface (maybe usb too).

 

Thank you for being so confident...

 

I've explained it some time before, but maybe I should clarify it again:

 

CMI08:

* touch tablet mode: good for absolute positioning with slightly limted resolution and useable also with very lazy polling

* paddle mode: just like the touch table mode with inverted axis (shouldn't be used for 2D positioning, since loosing compatibility to touch tablet mode is bad)

* driving controller mode: unlimited workspace thanks to overflow. Relative movement can be catched very precise when estimating the pot samples every, let's say 5th or even 10th VBI

* ST & Amiga-mouse mode: Good for compability but IMHO outdated: Needs much more CPU time, more code and still tends to swallow signals

 

If desired I can come up with an example for the relative mode, but thanks to limited emulator support regarding the CMI08, testing is only usefull with the 'real thing'

 

One thing regarding the commodore 1351 mice: Their range is very limited thanks to their simple way of working. The small range needs to be sampled much more often than the ranges of the CMI08. This is independent from POT jittering or so.

Edited August 6, 2011 by Irgendwer

[Irgendwer]

It could probably be done digitally as well, but then you'd need to do signalling to tell the device what value/part you're wanting to receive.

 

AFAIK this is the way of working of the 'Black Mouse' (browse atarionline.pl for it), but it also needs more code and is more timing critical than requesting POT values.

Edited August 6, 2011 by Irgendwer

[+Philsan]

So the best mode for having 320 horizontal resolution is "driving controller mode" and not "paddle mode"?

[Irgendwer]

What would be cool is if there was a low-cost solution that was adopted by lots of people, using the Delta/Pot method. Then you only need to read the thing periodically rather than devote big chunks of CPU time for it.

 

Maybe the CMI08 is to costly, but your other requirements are matching quite nice the interface...

[Irgendwer]

So the best mode for having 320 horizontal resolution is "driving controller mode" and not paddle mode?

 

Exactly!

 

(And remember: The scroll wheel support works in this mode - contrary to ST/Amiga-mode - too!)

[+Philsan]

So the best mode for having 320 horizontal resolution is "driving controller mode" and not paddle mode?

 

Exactly!

 

(And remember: The scroll wheel support works in this mode - contrary to ST/Amiga-mode - too!)

Thanks.

 

BTW, we have a good weather in Switzerland, isnt' it?

[Irgendwer]

BTW, we have a good weather in Switzerland, isnt' it?

 

-

[Alphasys]

I'm not sure what "Driving controller mode" means exactly, but I was thinking about the resolution problem on a touchpad and I was thinking about how those work on the laptop... Since it's relatively easy to detect if someone has the stylus on there or not, that would be a way to still keep 320p resolution.

[Bryan]

I think the best helper-adapter for reading a mouse would be an interface where the current position could be latched and serially clocked in via the joystick port at any time. There could also be some commands clocked out to set the speed and size of the mouse area, and to set the current position.

[kskunk]

I think the best helper-adapter for reading a mouse would be an interface where the current position could be latched and serially clocked in via the joystick port at any time.

If that's what you like, have you thought about directly wiring a PS/2 mouse to the joystick port? It's 5V, so it's electrically compatible.

 

PS/2 is a slow enough serial interface to bit bang, running at a top speed of 107 Atari cycles per bit. A PS/2 mouse supports two kinds of flow control, so it's easy to ensure the data is only clocked in when you want it. A complete mouse packet takes 36 bits, or 4,000 cycles. 13% CPU at 60FPS, or 6.5% for 30FPS, which would be fine since the counters are 9-bits each. You can even poll during the "less valuable" CPU time in screen display, since you don't need all 107 cycles.

 

- KS

Edited August 7, 2011 by kskunk

[Irgendwer]

I think the best helper-adapter for reading a mouse would be an interface where the current position could be latched and serially clocked in via the joystick port at any time. There could also be some commands clocked out to set the speed and size of the mouse area, and to set the current position.

 

This is is like the "Dark Mouse": http://atarionline.pl/v01/index.php?subaction=showfull&id=1214668595&archive=&start_from=0&ucat=6&ct=wynalazki

 

(sorry for my wrong memorization "Black Mouse").

 

But I do not aggree. IMHO there is nothing simpler on the driver side like the CMI08 solution. If the position will be serially clocked into the port you either

 

* have a limited workspace when given absolute positions

or

* also have to track relative movements with a timing constraint

 

Additionally you have more complexity to sync to the clocked data.

[Irgendwer]

I'm not sure what "Driving controller mode" means exactly, but I was thinking about the resolution problem on a touchpad and I was thinking about how those work on the laptop...

 

You have to estimate relative movement even if the values overflow. This is timing dependent, but not really a problem (esp. given the ranges of the CMI08):

 

e.g.

Range A: 5-80

Range B: 81-160

Range C: 160-228

 

If the value crosses the A -> C boundary you can estimate the negative relative movement, like you can determine the positive movement when a C -> A crossing occurs.

 

If you remove the LS-bit you have a nearly jitter free positioning estimation.

Edited August 7, 2011 by Irgendwer

[danwinslow]

Hmm...maybe you guys should start a 'mouse discussion' thread.....