Hi everybody ! Hope you had a great Xmas time.

Recently I experimented with the new chinese thing mentionned in Subject, looks promising to say the least, but I find I have at least two annoying problems which, maybe, someone can share advice about them, they are :

1. Mouse: can't have the mouse activated whatever settings in the .ini file

For reference purposes: Win 98 SE , PS2 "logitech clone" mouse .

2. I will likely patch the keyboard driver to suit the national keyboard I'm using. Before I put the hands in the engine though, has anyone done so before ? (yes I -am- lazy

See you

--
Cz.

hihi... but my kbd patch seems not working so good. so, i afraid i could not offer your need. see my homepage in trw section for plug-ins if you want to see for a while

regards

sighted your text, Dion ! Unfortunately i don't have my programming station available until a few days to check what your findings give...

'Bout the "out e1,ax" instructions though, I guess they are just a sort of "wait" for in/out delay(very common in BIOSes. ports other than E1 are sometimes used for the same goal, of course with that sort of coding there is always the risk that the "dummy" port number is -not- dummy on some platform after all ;~)

Cheers and ... happy new year to all who happen to read !

--
Czerno

Thanks Czerno for the info

btw, i think you can program your own ps2 mouse driver and hook the buggy code

regards

Well, I had 2 spare hours today within which lapse I successfully patched TRW's keyboard tables to handle a foreign keyboard

Some hints for anyone wants to follow my track : (all offsets are Hex and relative to start of file trw2000.sys)

The keyboard translation table (i.e., OEM scan code -> ASCII char or special function ) is at +3490C. It is comprised of 59h * 4 bytes, indexed by OEM scan code value from 0 (dummy) to 58.

Each group has =

+0 : type (0:modal key/1=letter/2=other ASCII/6=number keys, 1st row/other: special processing,need not concern us for the patching here)
(for types 1,2,6):
+1 : UNshifted ASCII (0 to 7F / or FF=none)
+2 : shifted ----------
+3 : with CONTROL, ---------

so just change those characters you need to. If your keyboard has some "alternate" (third) graphics on some keys, you should assign them to the "Control+key" combo instead of the Windows "right alt".

Have fun !

And uh, Dion , I checked your text, too . Unfortunately I think you are a bit too blindly brave, almost everything you did is nonsense (only the "test al,20" instead of "test al,2" was a bug as you correctly realized
When I take the time, I shall comment and explain that keyboard stuff ; meanwhile I suggest you cancelled the changes you made, as any problems you encountered are not to be solved thus IMHO ...

C. U.

--
Czerno

hi Czerno, wow! thanks a lot that's because i felt none care about it



uhm... would you please tell me which one of them?



wow! i wait for it

regards

OK you 're welcome; BTW I apologize for the word nonsense which may feel rude when I didnot mean to be.


> mov ebx,FB8B0080h
> mov cl,2
EBX is correct and should not be changed ( look at Vkd.inc for the meaning of this.) CL=2 means hotkey active on release IIRC and should be OK too but you may try other conditions here ; only ensure you have read the docs before making mods !!!

I do not know how severe a problem you encounter with TRW2000. I haven't got serious trouble in this respect either on the 486 or the K6/2 system. The annoyment with the "control" state, as you noted, is easily circumvented by operating the control-key and it is mostly unavoidable ( depending on how applications try to monitor key states beyond relying on windows messages ). Also you might try to leave the debugger using the "X" command rather than the control-hotkey combo if this is where you're having trouble...

After quick peeking at TRW's keyboard code, I can see a possible source for serious annoyment though, in that it makes use of the non-standard Kb Controller command 0D2h ( in order to reinject scancodes at the "output buffer" and have them trapped later by windows' keyboard vxd ) This command however is not part of the original AT 8042 KbCtrlr, so it may not be understood by all and any modern chipsets ... that might explain lockups on some machines. TRW is very different in this respect from SICE which has its own full fledged treatment for keyboard and does not interact with Windows' vxd .

As for the mouse, I haven't looked at how it is treated. On a modern PCI system with a "PS2"-like mouse port,
my mouse is not operative under TRW, even with the "winmouse=ON" setting . Do you know any one had a similar problem ?

Meseems the website of TRW is down so no hope to contact the authors ... or do you know the new URL, or active discussion forum of those people ?

Regards
--
Czerno

well, frankly i dont know ;p from chinese friends said that LiuTaoTao had left the scene long time ago

uhmm.... about mov cl,2, i had tried to experiment with it and found that changing it to OnComplete was more stable in my computer [dont lock the kbd so often].

about mov ebx, blah.... well, its work, so why bother

gee! hope you'll write some patch info about D2h and if it true is the source of bug. about sice, yup, i agree, it is more independant.

ps. could i know what your job is, Czerno? i see you had enuff h/w exp here

regards

Example for the french keyboard, plus a small how-to ...
File attached.
HTH

--
Czerno

To swap the left/right mouse buttons under TRW,
you may swap the byte values at offsets 2DA78
(original=20h) and 2DA84 (original = 10h) in the
TRW2000.SYS file !

You might do the patching with an hew editor of
your choice, or even you might do it with TRW running, using TRW2000 to patch itself in memory ...

Of course you may want to add a menu and controls
to the TRW2000.EXE windows app for doing the patch.
Left as an exercise to the reader ...

--
Cz.

about "control" state, i thought its not the ctrl key whos wrong here, and i neva use ctrl key to exit, but F5 and still locked up. just replace it with alt, and you'll know what i meant.

about mouse stuff, some obvious prefs [prior to v1.23 in RVA]:

1) .1E164 GetMouseData
2) .1E3AD SerialMouseIRQHandler
3) .1E219 PS2MouseIRQHandler

oh, before forgot, for v1.22 the kbd table is on +34BEC IIRC
and thanks for the file, its uploaded

regards

>about "control" state,...
The problem here is not with the "control" used for returning to Windoze, it's with the "control" state left when popping-up the TRW. It goes without the saying that, for things to work smoothly, the same keystate should be in effect when Windoze retrieves control over the operations : the best way to approximate this IMO is to set the flags to CL=1 (CallOnPress), not 8 or 2.
In this way, the same state of the control key (down) is retrieved when Windoze gains control than when it lost it ! Try it, it feels much better - though no perfect quickpatch solution exists. For one, be sure to press the same control key (left or right) when leaving than when popping into TRW .

> about mouse stuff, ...

Thanks, I found that code of course, but had no time to experiment. The fact is, on my old system all works perfectly, whereas on my newer APTIVA the mouse is inactive under TRW, though both are PS2-alike mice ! Well, I'll have to do some debugging with the help of the debug version of the vmouse.vxd I'm afraid !

Oh BTW I suggest you substracted 100000h from the offsets in TRW2000.SYS as you give them. I assume you get those values from something like Wdasm that loads the .sys at its "preferred" load address of 100000, but really that means nothing for an "NT" sys mini driver !

> and thanks for the file, its uploaded
You mean you put it on your site ? Well uh, you're
welcome but please do pass the warning that it's quick and dirty Did you patch your own kbd ?

C.U...
--
Czerno

thanks Czerno, i understood what ur meant now
btw, i dont need to patch my kbd table since it works fine already.

I found it was the Logitech drivers for that wheel-mouse that somehow prevented TRW2000 from "seeing"/using the rodent ;

after nuking them drivers and forcing the standard Microzoft PS2 mouse drivers, everything is good ...

Oh well, I lost the use of the middle mouse button in the process. The standard control panel DLL does not even mention it. Is there a tweak for forcing a 3-button mouse to be recognized while staying with the basic mouse vxd ? I do not want to let any kind of "mouseware" autodetect the contraption, since it would likely destroy my "fix" , I am afraid it would

P.S. The wheel is functionnal its only the 3rd button which isn't. The mouse is branded DeXXa fwiw. I would use the 3rd button as a shortcut for 1st-button-dbleclick.

--
Czerno aka The-Passer-by