Memory contents different on real hardware

[onlyonemac]

Hi!

I'm having a really confusing problem with my keyboard driver. When I execute the code shown below on real hardware, cl is always 1 (although that memory location is 0 as I have proven by reading its contents in other places), however on both Bochs and Qemu it comes out as 0 (which is as expected).

Code: Select all

	keyboard.movewindow:

	push	ax
	push	ebx
	push	cx
	push	ds

	push	ax
	mov	ax, #0x0010
	mov	ds, ax
	pop	ax

	mov	ebx, #279
	seg	ds
	mov	cl, [ebx]

	inc	ebx
	seg	ds
	mov	ch, [ebx]
	inc	ebx
	seg	ds
	mov	ah, [ebx]
	cmp	ah, #0
	jz	keyboard.skipmovewindow

	mov	bh, al
	and	bh, #0x03
	sub	bh, #2
	mov	bl, al
	and	bl, #0x0C
	ror	bl, #2
	sub	bl, #2
	push	bx

	int	0x6A
	mov	al, #2
	cmp	ch, #1
	jz	keyboard.getwindowscroll
	cmp	cl, #1
	jz	keyboard.getwindowsize
	int	0xAC
	jmp	keyboard.valuesfetched
	keyboard.getwindowscroll:
	int	0xAD
	jmp	keyboard.valuesfetched
	keyboard.getwindowsize:
	int	0xAB
	keyboard.valuesfetched:

	pop	ax
	add	bh, ah
	add	bl, al
	int	0x6A
	mov	al, #1
	cmp	ch, #1
	jz	keyboard.setwindowscroll
	cmp	cl, #1
	jz	keyboard.setwindowsize
	int	0xAC
	jmp	keyboard.valuesset
	keyboard.setwindowscroll:
	int	0xAD
	jmp	keyboard.valuesset
	keyboard.setwindowsize:
	int	0xAB
	keyboard.valuesset:

	keyboard.skipmovewindow:
	pop	ds
	pop	cx
	pop	ebx
	pop	ax
	ret

Any ideas?

Thanks,

onlyonemac

[iansjack]

How can anyone possibly give a sensible answer to that when your int 0x6A is a black box?

[bwat]

The real computer is the benchmark and the emulator is a best effort approximation. Memory tends to work correctly - we wouldn't use computers as much as we do if this weren't so. You know this so trust your knowledge and experience. Your problems are either assumptions made in the emulator (zeroed memory which isn't the case on a real machine), or some other piece of code isn't working in the same way on the real machine as it does in the emulator (for perfectly understandable reasons), you assume otherwise, and a side effect of this is that you think a memory location contains something it really doesn't.

Personally, I would dump the contents of cl to screen at certain check points (unless I had a debugger on target).

[onlyonemac]

I have zeroed the memory location and confirmed that straight after the load cl is 1, not 0.

Also, all the software interrupt calls preserve register cl.

[bwat]

Then either
i) your zeroing code is wrong, or
ii) somebody is overwriting after zeroing, or
iii) that ISR doesn't work the way you think it does.

I would put a canary on either side of the read address to see if someone was overwriting. I would also verify that it is zero after zeroing using a subroutine then use the same subroutine after reading cl (eliminates problems where zeroing and reading use different segment values).

Accept your code is wrong or you misunderstand it as the chances of hardware failure are quite low. The emulator execution result is useless to you.

[onlyonemac]

I'm not saying that my hardware's at fault; all I'm saying is that I can't see what would cause the memory location to be different on real hardware. And no, my zeroing code's not at fault because there's other code which would also fail if that memory location was non-zero - and the ISRs are irrelevant becuase I'm talking about what happens before any of the ISRs get called. Also, it doesn't seem to matter what register I load it into as I have checked a few different ones.

[bwat]

I'm not saying that my hardware's at fault;

I'm not saying you're not saying that.

all I'm saying is that I can't see what would cause the memory location to be different on real hardware.

You don't understand your code then. If you stepped through your code looking at the important memory locations at each step then you would "see" what happens. To say "I can't see" means you've not done this and made incorrect assumptions instead.

And no, my zeroing code's not at fault because there's other code which would also fail if that memory location was non-zero

I wouldn't rely on that as proof. I would be dumping the contents of memory before zeroing, after zeroing, and after loading into cl (as you have done).

it doesn't seem to matter what register I load it into as I have checked a few different ones.

You're clutching at straws. If I were you, I would have a cup of tea then come back to the problem in a different frame of mind.

The odds are that this is a self inflicted problem so you need to eliminate your assumptions and prove that everything works as it should.

[onlyonemac]

How do I debug on real hardware? With a debugger. How do I get a debugger when my OS is different from Linux and it can barely host an application? It's not possible.

Perhaps if you can stop making assumptions about my OS then we can actually try and eliminate the bug with the tools we've got (so far I've been debugging by either adding an infinite loop to dump a register value or a conditional halt).

[Combuster]

How do I debug on real hardware? With a debugger.

There are quite a few more mundane methods of testing, with printf-debugging in any of its forms being the obvious choice to start with. Can you print pieces of text after one another yet? Go make that work first, then you have something that can pump a screen full of what your code is actually doing over time.

[onlyonemac]

Well I've found out that my hardware is producing a shift key press scan code prior to pressing any of the arrow keys, and shift key release code after releasing the arrows. I have no idea why, and I haven't seen anything about that in the wiki. Any ideas?

[Brendan]

Hi,

Well I've found out that my hardware is producing a shift key press scan code prior to pressing any of the arrow keys, and shift key release code after releasing the arrows. I have no idea why, and I haven't seen anything about that in the wiki. Any ideas?

No, no ideas. I don't know if you're using BIOS functions or your own driver, and if it's your own driver I don't know if it's PS/2 scan code set 1 or PS/2 scan code set 2 or USB HID; but for all those cases you shouldn't get shift before cursor keys.

I also don't know if you're testing on real hardware or a virtual machine (or which virtual machine). Virtual machines have a hard time getting keyboard scan codes exactly right, as the host OS mangles the keypress into whatever form it likes and then virtual machine has to reverse this "pre-mangling" to end up with something that sort of seems like what hardware might have sent. However, even with the "mangle then de-mangle" mess, I'm not sure you'd get shift before cursor for any of the virtual machines running on any of the host OSs.


Cheers,

Brendan

[onlyonemac]

I'm using PS/2 scan code set 1 through my own driver. The virtual machines are not giving shift-key scancodes (read the first post before replying); the real hardware is giving shift-key scancodes before the press of a cursor key and after the release of a cursor key. All I can assume is that the keyboard thinks the OS needs the shift key to be pressed when the cursor keys are pressed, although there's nothing about that in the wiki. Would "initialising" the keyboard with a BAT help?

[iansjack]

Fairly obviously, your driver is faulty. You are the only one who's seen the source of it so you are in the best position to fix it.

[Brendan]

Hi,

I'm using PS/2 scan code set 1 through my own driver. The virtual machines are not giving shift-key scancodes (read the first post before replying); the real hardware is giving shift-key scancodes before the press of a cursor key and after the release of a cursor key.

I did read the first post; but nothing indicated that the shift-key problem had anything to do with the original "memory not zero" problem.

All I can assume is that the keyboard thinks the OS needs the shift key to be pressed when the cursor keys are pressed, although there's nothing about that in the wiki.

I can imagine several possibilities:

• a keyboard sends "shift then cursor"
• a PS/2 keyboard sends "cursor" and then for no known reason the PS/2 controller decides to send "shift then cursor"
• a USB keyboard sends "cursor" and the firmware's implementation of "PS/2 device emulation for USB devices" meets the current industry standard for lack of quality (where "buggy beyond belief, or worse" seems to be one of the requirements of the PS/2 device emulation )
• you actually get the correct data from the PS/2 controller's IO port, but your keyboard driver is buggy and incorrectly reports it as "shift then cursor" when it wasn't
• you get the correct data from the PS/2 controller's IO port and your keyboard driver is correct; but there are bugs in the code that receives the keypress information from the keyboard driver

Would "initialising" the keyboard with a BAT help?

If other keys work as expected, then a BAT probably won't help.


Cheers,

Brendan

[onlyonemac]

Well I managed to get rid of the spurious scan codes with a reset and a BAT (it wouldn't work with just a reset, and neither did a BAT on its own suffice). I don't know why it was set like that; I've never read anything about strange BIOSes initialising keyboards like that nor how one could even achieve that setting.

The strange thing now is that the memory location is now showing 0 when other code indicates that it is 1.

EDIT: Well it seems like now I'm getting a shift key release code before a cursor key press code and a shift key press code after a cursor key release code. So all I've managed to do is get the shift key state to swap round. It's almost as though the keyboard is "forcing" the shift key to be in a particular state when the arrow keys are pressed, although I don't remember reading anything about that in the wiki, even amongst "odd" keyboards.

EDIT 2: I've found that it depends on the Num Lock state: if Num Lock is on then the shift key is forced to the "pressed" state when the cursor keys are pressed; when Num Lock is off then the shift key is forced to the "released" state when the cursor keys are pressed. Clearly there is a way around this (since Linux for example can detect the shift key and the cursor keys independantly) - if that way requires filtering out the extra shift key scan codes, then I'm very surprised that the wiki says absolutely nothing about that.