OSDev.org

I did a little testing and I did get it a little wrong. Thanks for the correction. Take the sign bit (Xs or Ys) and or it to the 9th bit, bit 8, and sign extend to the width of the integer used.

For example, if the Xs bit is set and you have an 8-bit value of 0x01, this will be converted to a 32-bit integer as 0xFFFFFF01.

Therefore, you do have a range of -255 to +255.

Thank you for the correction.

Ben

Hi,



I'm wondering if you'd mind doing a little more testing for me...

My theory is that it may make more sense to use the overflow bit as the 9th bit, and the sign bit as the 10th, 11th, ... bits. This would give multiple possibilities depending on how the mouse handles overflow conditions (e.g. if the sign flag still works for overflow, if the other 8 movement bits are still valid, if the mouse clamps to the representable range, etc). The ideal case would be that you end up with a range from -512 to +511 with no problems at all (e.g. where "faster than +511" is just reported as +511).

More specifically, I think different mice might handle overflow in different ways, and that by treating it as "signed 11-bit integer" it'd be easier to handle each possibility (if you know the mouse's behaviour) and easier to "auto-guess" the mouse's behaviour when you don't know the mouse's behaviour (e.g. using some sort of "probability based on acceleration" logic).

Note that you might need to move the mouse quite fast to get overflow to occur. This depends on the resolution and sample rate. For example:

• "resolution = 1 count/mm, 10 samples per second" (slowest case): you'd need to move the mouse at over 4.6 Km/h to achieve overflow (and over 9.2 Km/h to test values outside the -512 to +511 range)
• "resolution = 1 count/mm, 200 samples per second": you'd need to move the mouse at over 25.6 Km/h to achieve overflow
• "resolution = 8 count/mm, 200 samples per second" (fastest case): you'd need to move the mouse at over 737 Km/h to achieve overflow

For this reason I'd want to configure the mouse for "resolution = 1 count/mm, 10 samples per second" for testing the true behaviour of overflow.

The other thing I'm wondering is if the overflow flag is sticky. For example, if you move the mouse right for 1234 counts then left for 1233 counts in between samples, does the mouse report "overflowed at some point during this period" or does it report "moved right 1 count".

Sadly; I haven't been able to find any information that adequately describes the behaviour on overflow.


Cheers,

Brendan

You all seem to be ignoring me and go offtopic. Stop responding to this thread, please.
You anyways just debate about sign bit while currently I could not get a damn packet right.


maybe you should repair your sentence:

Let me fix both of you:

Are you waiting for data from the PS/2 controller, or data from the mouse?

Try my code:
When reading data:

When writing data:

Your code is not better than Lukand's.

It works so I guess it is fine.

Works != good.

Now only the ones that notice any problem with this code should respond.
It seems clear that problem is not in function itself, but in something else...
Through if it gives any help, there is whole new updated mouse code:

I will try some tests and debugging to make timing out stop.

Lukand, what does 'sleep(1)' do ?

@Hannah: Is this Lukand's sleep() function, then? I wasn't able to locate it or anything else regarding scheduling in the Nutoak Github repo, but that doesn't appear to have been updated in the past two months, so I don't know if he's moved the repo somewhere else, or hasn't used it for some other reason.

Before I comment further, let me say that I don't have enough information to say if this actually might having anything to do with the problem at hand - I am following gerryg400's lead in this, and at this point only Lukand could say whether this is a relevant topic or not.

Now, to continue: if this is the sleep() function in question, it presents a significant problem, as it seems to be designed to busy-wait on the timer ticks. The comment seems to indicate that the process is meant to cede the CPU to the scheduler inside the loop at the point which is currently commented out, but in the absence of anything else, it will simply spin in place, modulo the timer interrupts, until the ticks variable (which is presumably a global variable in the kernel which is being updated by the timer interrupt handler) exceeds the computed amount of time (saved in a local variable in the function).

I don't want to say too much about this, given that we don't know about the implementation of the scheduler or the interrupt handlers. However, I will refine gerryg400's question by asking: a) will one tick (which seems to be equated to one millisecond) be sufficient time for the wait on this operation, b) what are the time resolutions of the scheduler and the timer interrupt handler, c) approximately how many clock cycles does the timer interrupt handler use in computing each tick, and d) how do you reconcile any RTC drift this might cause in the ticks variable?

Admittedly, I don't even know if these questions make sense in your current design, but they seem to be relevant from what I have seen so far.

facepalm Yeah, that is where I would expect to find that, sure.

OK, I will admit that I didn't look there, because... well, I assumed it would be in with the scheduling stuff, and I never found any. I need to make fewer assumptions of that sort, it seems.