OSDev.org

Sik wrote:Um, the bit you're talking about is the sign bit... that's essentially the 9th bit of the value (mouse motion is 9-bit, not 8-bit). The range is actually -255 to +255. (EDIT: oh and in case somebody wonders why not -256... mouses that return -0 are a thing sadly and you should be aware of them)

  int delta;
  if (Xs)
    delta = 0xFFFFFF00 | Xd;
  else
    delta = 0x00000000 | Xd;

BenLunt wrote:

Sik wrote:Um, the bit you're talking about is the sign bit... that's essentially the 9th bit of the value (mouse motion is 9-bit, not 8-bit). The range is actually -255 to +255. (EDIT: oh and in case somebody wonders why not -256... mouses that return -0 are a thing sadly and you should be aware of them)

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.

• "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

I don't want somebody else to run into this thread and not realize there's a mistak

I don't want somebody to run into their thread and not realize there's a mistak

Lukand wrote: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.

I don't want somebody else to run into this thread and not realize there's a mistak

maybe you should repair your sentence:

I don't want somebody to run into their thread and not realize there's a mistak

I don't want somebody else to run into this thread and not realize there's a mistake

Lukand wrote:Waiting always times out.

Lukand wrote:Waiting always times out.

uint32_t timeout = 100000;
while(timeout--)
{
	if((Inportb(0x64) & 0x01) == 1)
	{
		return;
	}
}

uint32_t timeout = 100000;
while(timeout--)
{
	if((Inportb(0x64) & 0x02) == 0)
	{
		return;
	}
}

octacone wrote:Try my code:

Octocontrabass wrote:

octacone wrote:Try my code:

Your code is not better than Lukand's.

octacone wrote:

Octocontrabass wrote:Your code is not better than Lukand's.

It works so I guess it is fine.

gerryg400 wrote:Lukand, what does 'sleep(1)' do ?

void sleep(int16 ms)
{
	uint need=ms+ticks;
	while(need>ticks)
	{
		//nextTask(), or whatever it needs to be in future
	}
}

Schol-R-LEA wrote:@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.