26-Apr-2024 19:15 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 34 items in your selection
[Events] Show report on os.amiga.com (forum)ANN.lu
Posted on 07-Oct-2003 18:47 GMT by Kjetil (Edited on 2003-10-07 21:53:41 GMT by Christian Kemp)34 comments
View flat
View list
There is show report at os.amiga.com (forum) as well. [ Edited: cleaned up text, fixed link, removed ambiguity. - CK ]
Show report on os.amiga.com (forum) : Comment 1 of 34ANN.lu
Posted by Peter Gordon on 07-Oct-2003 16:51 GMT
What? Are they all getting along really well? Is there chemistry in the air? ;-)
Show report on os.amiga.com (forum) : Comment 2 of 34ANN.lu
Posted by Kjetil on 07-Oct-2003 17:01 GMT
In reply to Comment 1 (Peter Gordon):
Well there are not MOS users there!! LOL
Show report on os.amiga.com (forum) : Comment 3 of 34ANN.lu
Posted by hooligan/dcs on 07-Oct-2003 17:12 GMT
LOL * n+1 & ROTFL * 8
---------------------

Those damn MOS feckers
Show report on os.amiga.com (forum) : Comment 4 of 34ANN.lu
Posted by Anonymous on 07-Oct-2003 17:18 GMT
I hate marine rap.
Show report on os.amiga.com (forum) : Comment 5 of 34ANN.lu
Posted by Amon_Re on 07-Oct-2003 17:20 GMT
Well, he is right you know, both "camps" showed alot of respect towards each others, and the atmosphere was very friendly.

For those who wonder about the directory loading he mentioned, this is/was due to layers.lib IIRC

Cheers
Show report on os.amiga.com (forum) : Comment 6 of 34ANN.lu
Posted by mahen on 07-Oct-2003 17:26 GMT
In reply to Comment 5 (Amon_Re):
nice :-)
Show report on os.amiga.com (forum) : Comment 7 of 34ANN.lu
Posted by Anonymous on 07-Oct-2003 18:30 GMT
That's a really lousy report -- all he talks about is the
stupid mouse pointer...
Show report on os.amiga.com (forum) : Comment 8 of 34ANN.lu
Posted by Amon_Re on 07-Oct-2003 18:46 GMT
In reply to Comment 7 (Anonymous):
Not enough mudslinging perhaps?

Cheers
Show report on os.amiga.com (forum) : Comment 9 of 34ANN.lu
Posted by Anonymous on 07-Oct-2003 19:01 GMT
In reply to Comment 8 (Amon_Re):
>Not enough mudslinging perhaps?

mudslinging I can do without, but how about
some more OS4 information :)...
Show report on os.amiga.com (forum) : Comment 10 of 34ANN.lu
Posted by takemehomegrandma on 07-Oct-2003 20:14 GMT
OT:

I think this yellow colour for this "Events" category too yellow and too bright. It's kind of sticky in your eyes IMHO ...
Show report on os.amiga.com (forum) : Comment 11 of 34ANN.lu
Posted by Anonymous on 07-Oct-2003 21:53 GMT
In reply to Comment 7 (Anonymous):
> That's a really lousy report -- all he talks about is the stupid mouse pointer...

Well, yes, it is a lousy report ;) Anyway, as far as that mouse pointer is concerned: I once wrote a serial driver to connect a PC mouse to a classic Amiga and had the same problem: I couldn't get smooth pointer movements out of a normal serial mouse at 1200 baud. Don't know about mice with higher resolution or USB connection but a standard serial PC mouse on a Pegasos or Amiga One probably will never feel as smooth as an Amiga mouse (which has no serial protocol but directly connects to hardware counters in the Amiga).
Show report on os.amiga.com (forum) : Comment 12 of 34ANN.lu
Posted by Wayne Hunt on 08-Oct-2003 01:27 GMT
In reply to Comment 5 (Amon_Re):
> Well, he is right you know, both "camps" showed alot of respect
> towards each others, and the atmosphere was very friendly.

I said this at AmiWest. When you get down to it, there are no "camps" when people are face to face. It's only open forums which seem to breed miscontent and conspiracy theories.

When people are placed in a situation where they can say anything they want without fear of reprisal, I'm sorry to say that you end up seeing the worst in that person. When you add in the fact that it's human nature to create "cliques", anonymity can be a very, very bad thing.

At AmiWest, I walked in, expecting the two teams to spend the entire show fighting with one another, or at least a food fight over breakfast. What we all got was 10 or so people who have opposing viewpoints but were still able to sit down over breakfast and "talk shop".

There is no great conspiracy here folks, only people trying to do their jobs to bring you the systems that we (respectively to both teams) think that you -- the community -- want to have on your desk, in your entertainment center, and in your pocket. Don't want one or the other? Fine... It's OUR job to demonstrate to you why you want our product. Just keep an open mind.

There is no need for animosity. Humans are people too. Their emotions get fragile and they react. Just think how you'd respond if you were really sitting across from the table and the world would be a much better place.

(/me takes off the Hari Krishna robe and flowers)

Wayne Hunt
Show report on os.amiga.com (forum) : Comment 13 of 34ANN.lu
Posted by greenboy on 08-Oct-2003 02:14 GMT
In reply to Comment 12 (Wayne Hunt):
Just so, Wayne. Pass the macrobiotic spinach, willya?

--
Popeye
Show report on os.amiga.com (forum) : Comment 14 of 34ANN.lu
Posted by Kjetil on 08-Oct-2003 08:13 GMT
In reply to Comment 11 (Anonymous):
I written a mouse driver for Linux once, used the clone() function so the driver run parallel whit my program, and the most where whey smooth, cool thing about clone is that you get one task running your program and one task running a function whit in your program, and they all share the same local memory and shard memory resources, so it can depend on how well the mouse driver is written, how ever I do not think this is the issue.

I think the most likely issue for mouse to move in strange way, is if the mouse is not cleaned,

An other thing it might be is that ABOX environment is running on top of quark and mouse driver running on top of ABOX and there for you get some strange timing issues, on slower computers, remember you have JIT running in the background compiling programs from time to time, and compiling programs is a CPU heavy task when it going on, well it depends on the level of optimization,

(Off topic: I think the most cpu heavy part when you compile is the AscII text to conversion binary, lots of lookup to Se if variables and functions exists and where they are located relatively speaking.)
Show report on os.amiga.com (forum) : Comment 15 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 08:59 GMT
In reply to Comment 14 (Kjetil):
>An other thing it might be is that ABOX environment is running on top of quark and mouse driver running on top of ABOX and there for you get some strange timing issues, on slower computers, remember you have JIT running in the background compiling programs from time to time, and compiling programs is a CPU heavy task when it going on, well it depends on the level of optimization,

Since I wrote my mouse driver for classic Amigas, there was no ABOX (and of course it was fully asynchronous?!). The problem was not with the OS but with the PC mouse. Simple mice have 1200 baud, that's only 150 bytes per second, at best. It's difficult to get smooth movement out of that. For the sake of an example, let's assume the mouse has 300 dpi and is moved (slowly) 10 cm in a second. That generates 1200 coordinates, good enough for a 1280x1024 screen, but the protocol can not send more than 10% of those to the computer. 90% of coordinates just are lost. I guess it's possible to fool the user with advanced nonlinear interpolation but I didn't go so far. I now use a A5 tablet with my PC and will never go back to mice anyway.
Show report on os.amiga.com (forum) : Comment 16 of 34ANN.lu
Posted by Alkis Tsapanidis on 08-Oct-2003 09:19 GMT
In reply to Comment 14 (Kjetil):
No, that's not the problem, Amiga mice sent movement info when it happened, there wasn't any polling at the ports.
The ABOX drivers access the hardware directly, there are no such timing problems.
Show report on os.amiga.com (forum) : Comment 17 of 34ANN.lu
Posted by itix on 08-Oct-2003 09:46 GMT
In reply to Comment 14 (Kjetil):
Using Pegasos here and cant notice difference to my Amiga. Also when I was running MOS on my Amiga could not see any difference between MOS and AOS.
Show report on os.amiga.com (forum) : Comment 18 of 34ANN.lu
Posted by Kjetil on 08-Oct-2003 12:02 GMT
In reply to Comment 16 (Alkis Tsapanidis):
Any way the serial.device will normal buffer reads and writes, if the mouse driver where not up to the job it normally will shown as latency not jitter.

So you are saying the driver make use of some interrupt to schedule it self, that be quite nice.

Well it help that diver do NOT read from an other driver or NOT an other API to get it’s coordinates, if that where the case it will it will add latency like badly written game engine or emulator, that part is quite clear to me, and I don’t suspect any one to be that stupid to implement it. :-)

How ever that’s not what I take about, I questioning the priorities that mouse diver operates on in comparison with JIT emulator, and the interaction between the Quark task scheduler and the ABOX (exec task scheduler), in that case it you get hi peeks of cpu loads short period of time this will give the user a feeling of jitter.

And I do not say it nursery say it’s the problem it can equally be dust on mouse ball or optical sensors, roller pins in side the mouse. (this is the default fault)

An other problem is the number of bit that holds the movement values, if they are not read in a speed that is optimal the result is, that you get this values get overflowed and becomes negative this will happen if you move the mouse extremely fast, if you think the mouse movement is slow and accelerate the values then small changes becomes large changes and they become really visible on hi resolution screen, so if you like better movement then turn down the mouse speed, and mouse acceleration is best turned off, if your going to paint.

So what I’m saying is that this can say a lot or nothing about MorphOS.
Show report on os.amiga.com (forum) : Comment 19 of 34ANN.lu
Posted by Kjetil on 08-Oct-2003 12:03 GMT
In reply to Comment 17 (itix):
I think the most likely issue for mouse to move in strange way, is if the mouse is not cleaned,
Show report on os.amiga.com (forum) : Comment 20 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 12:22 GMT
In reply to Comment 18 (Kjetil):
> How ever that’s not what I take about, I questioning the priorities that mouse diver operates on in comparison with JIT emulator, and the interaction between the Quark task scheduler and the ABOX (exec task scheduler), in that case it you get hi peeks of cpu loads short period of time this will give the user a feeling of jitter.

What part of "cheap pc mice to not send enough coordinates to implement smooth mouse movements as-we-know-it" do you not understand ?! You have now posted the same nonsense on ABOX and JIT three times (you must assume that the MOS developers are extremly stupid if they let the design of the OS get in the way of a mouse driver). Get your serial PC mouse, connect it to your Amiga and download any serial mouse driver from Aminet. You will instantly see that it is not responding as nicely as a real Amiga mouse. It is of course also a matter of perception because it's a minor issue of subtle non-smoothness, not a big deal really ;-)
Show report on os.amiga.com (forum) : Comment 21 of 34ANN.lu
Posted by Fabio Alemagna on 08-Oct-2003 12:23 GMT
In reply to Comment 16 (Alkis Tsapanidis):
> No, that's not the problem, Amiga mice sent movement info when it happened,
> there wasn't any polling at the ports.

Actually, there IS polling, 50 times a sec, and the Amiga mouse has 100dpi of resolution.
Show report on os.amiga.com (forum) : Comment 22 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 12:35 GMT
In reply to Comment 21 (Fabio Alemagna):
> Actually, there IS polling, 50 times a sec, and the Amiga mouse has 100dpi of resolution

But not in the strict sense (sending an IO request and waiting for the completion). Amiga hardware has hardware counters, in Agnus if I remember correctly, no waiting required. The OS can just pass by and read out the current value, that takes no time at all. Btw, you can poke into those registers and move the mouse pointer.
Show report on os.amiga.com (forum) : Comment 23 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 12:35 GMT
In reply to Comment 21 (Fabio Alemagna):
> Actually, there IS polling, 50 times a sec, and the Amiga mouse has 100dpi of resolution

But not in the strict sense (sending an IO request and waiting for the completion). Amiga hardware has hardware counters, in Agnus if I remember correctly, no waiting required. The OS can just pass by and read out the current value, that takes no time at all. Btw, you can poke into those registers and move the mouse pointer.
Show report on os.amiga.com (forum) : Comment 24 of 34ANN.lu
Posted by Fabio Alemagna on 08-Oct-2003 12:45 GMT
In reply to Comment 22 (Anonymous):
> But not in the strict sense (sending an IO request and waiting for the
> completion).

That is not polling, that is sending a request and waiting, polling doesn't wait by definition :-)
Show report on os.amiga.com (forum) : Comment 25 of 34ANN.lu
Posted by Alkis Tsapanidis on 08-Oct-2003 13:21 GMT
In reply to Comment 18 (Kjetil):
How ever that’s not what I take about, I questioning the priorities that mouse diver operates on in comparison with JIT emulator, and the interaction between the Quark task scheduler and the ABOX (exec task scheduler), in that case it you get hi peeks of cpu loads short period of time this will give the user a feeling of jitter.
--

You did not get it, the JIT is IN the A/Box. It's actually trance.library.
Show report on os.amiga.com (forum) : Comment 26 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 14:19 GMT
In reply to Comment 24 (Fabio Alemagna):
> That is not polling, that is sending a request and waiting, polling doesn't wait by definition :-)

Oops, really? I though polling was a busy loop until something was completed (bad bad style, in other words). Pulling the current value out of hardware obviously would be part of polling, but without the tight loop, I wouldn't have thought of it as polling.
Show report on os.amiga.com (forum) : Comment 27 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 14:29 GMT
In reply to Comment 7 (Anonymous):
Well feel of mouse pointer has been compared AmigaOS vs Windows and now AmigaOS vs MOS too :) I think feel of Mousepointer responsiveness tells something about the system too.
Show report on os.amiga.com (forum) : Comment 28 of 34ANN.lu
Posted by Anonymous on 08-Oct-2003 14:45 GMT
In reply to Comment 27 (Anonymous):
> I think feel of Mousepointer responsiveness tells something about the system too.

I think discussing feel of mousepointer responsiveness tells something about the user too. I would rather discuss why Amiga Office prints upside-down or why Amiga Draw 16 does not recognize my printer or how to install Pegasos Java. Alas, we have little but mouse pointers to discuss at this point.
Show report on os.amiga.com (forum) : Comment 29 of 34ANN.lu
Posted by LjL on 08-Oct-2003 15:12 GMT
In reply to Comment 26 (Anonymous):
Oops, really? I though polling was a busy loop until something was completed (bad bad style, in other words). Pulling the current value out of hardware obviously would be part of polling, but without the tight loop, I wouldn't have thought of it as polling.

--------

The loop is still there. Only, it's spinned by a timer interrupt and not by branch instructions.
Sure, you get to run other programs between one poll and the other, but then, when a program *is* actually tight-looping in a preemptive environment, you get to run other programs as well. I don't think that tells whether something is polling or is not.

The time the interrupt that triggers the I/O routine is *not* a timer interrupt but an interrupt generated by the concerned I/O device only when it has actual information to send, we've gone interrupt-driven and we've quit polling.

I'm writing software for a ZX Spectrum that reads from the keyboard every 1/50 sec (i.e. every time a timer interrupt occours, and that's the only interrupt a Spectrum has got). Is my keyboard driver "interrupt-driven" then, only because it wakes up thanks to a vector in the same old boring usual vertical blank interrupt? I wouldn't have thought so...
Show report on os.amiga.com (forum) : Comment 30 of 34ANN.lu
Posted by Kjetil on 08-Oct-2003 15:41 GMT
In reply to Comment 25 (Alkis Tsapanidis):
Finally some information, okey...

:-) that good thing I think... :-)
Show report on os.amiga.com (forum) : Comment 31 of 34ANN.lu
Posted by Fabio Alemagna on 08-Oct-2003 20:37 GMT
In reply to Comment 26 (Anonymous):
> Oops, really? I though polling was a busy loop until something was completed
> (bad bad style, in other words).

A busy loop implies polling, polling doesn't imply a busy loop.
Show report on os.amiga.com (forum) : Comment 32 of 34ANN.lu
Posted by LjL on 09-Oct-2003 20:46 GMT
In reply to Comment 31 (Fabio Alemagna):
Uh, yeah, but why explain it in a line when you can do it in three paragraphs? My reply was better :P

Anyway who said busy waiting implies polling?

type GetDataFromDevice() {
while(AskSystemIfMyDeviceHasRaisedAnInterrupt()==FALSE);
return *DEVICEDATAPORT;
}

Why, I think I could actually use this... not.
Show report on os.amiga.com (forum) : Comment 33 of 34ANN.lu
Posted by Fabio Alemagna on 11-Oct-2003 05:14 GMT
In reply to Comment 32 (LjL):
> Anyway who said busy waiting implies polling?

Ehm... look at the code you typed :-) Unless you were joking, that is.
Show report on os.amiga.com (forum) : Comment 34 of 34ANN.lu
Posted by LjL on 11-Oct-2003 10:01 GMT
In reply to Comment 33 (Fabio Alemagna):
>> Anyway who said busy waiting implies polling?

> Ehm... look at the code you typed :-) Unless you were joking, that is.

I was joking. Still, according to some definitions of "polling" (which say you only "poll" a device port), my code is not doing it. It's just calling a system call, which is supposed to return true if an interrupt has occurred. This system call would only "poll" a boolean variable the interrupt service routine may have set; no actual polling of a device is involved.

Of course, I would not recommend using that code for anything.
Besides, in response to what Anonymous said in comment 26... is busy-waiting / tight-looping / polling "bad bad style" by definition? No. It depends entirely on the context.
For example, sometimes it may be better and more efficient (for both the program and the system) to busy-wait until a semaphore is released, instead of having the system switch context and wake us up later.
Anonymous, there are 34 items in your selection
Back to Top