Jump to content











Photo
- - - - -

Writing to the Grub4dos' keyboard buffer possible?

grub4dos

  • Please log in to reply
110 replies to this topic

#26 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 18 May 2021 - 05:15 PM

Sorry, too late already to edit my previous post.

 

While testing sub-routines from this post in the text-editor I'm working on, I found writing to 'num_hist' not always desirable, because in the way I use the History Buffer, the buffer became relatively fast 'full'.

 

So I added two lines to ':add_hist' to NOT change 'num_hist' if the History Buffer is supposed to be 'full'. Without these lines there are no problems so far, but I think it's 'good' if 'num_history' reflects the actual number of entries in the History Buffer. :lol:

 

Revised sub-routine ':add_hist':

:add_hist
setlocal && set * && set NHistory=%NHistory%
if not exist NHistory && endlocal && echo Abort: NHistory not found && pause --wait=7 && goto :eof
read %NHistory% > nul &; set /A numhist=%@retval% > nul &; echo num_history found: %numhist%
cat --skip=0x3EC4BC --locate=\x00\x00\x00\x00 --length=0x4 (md)0x0+0x1F63 > nul &; set /a histroom=%?% > nul
if not %histroom%>=1 && set /a numhist=%numhist% > nul &; echo History Buffer is full, 'num_history' stays at %numhist% entry's && pause --wait=7 && endlocal && goto :eof
set /A numhist=%numhist%+0x1 > nul &; echo num_history to write %numhist% - histroom=%histroom%
call :cnvBE2LE "%numhist%"
if not exist valueLE && endlocal && echo Abort: can not write num_history to NHistory && pause --wait=7 && goto :eof
write --offset=%NHistory% --bytes=4 (md)0x0+0x1D00 %valueLE% > nul
read %NHistory% > nul &; set /A numhist=%@retval% > nul &; echo num_history written: %numhist%
cat --hex --skip=%NHistory% --length=0x4 (md)0x0+0x1D00
endlocal && set /a numhist=%numhist% > nul
goto :eof

BTW lines 5 and 6 are the new ones, compared to previous post. Entry-length in the History Buffer is four bytes at minimum. So if four 'zero'-bytes are NOT found at the end of the History Buffer, the call to ':add_history' ends.



#27 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 May 2021 - 07:51 PM

Should be possible to do that "mathematically" instead of "textually", something loosely like:

https://www.microchi...FindPost/385301

 

BUT I don't thiink it will be faster nor more compact and shift, and, etc. operators AFAICR are "tricky" to use in grub4dos, I seem to remember that Steve6375 did some experiments to find the details for the exact syntax, some operators allow spaces, some do not.

 

:duff:

Wonko



#28 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 19 May 2021 - 10:04 AM

Wonko, thanks a lot!
I agree, my text-based approach is a 'poormans' solution, but I thought it's needed because of the \x..\x..\x..\x.. format I'am using with 'write'.
I think your bit-shifting approach wouldn't be helpfull in this direction.

BUT, after reading again Steve's book 'Getting started with Grub4Dos' I tried directly writing to a memory address with 'write'. This gives the desired Little Endian format in memory, if an integer is written!

See my action picture:
http://imgur.com/gallery/fPgUyrj

Edited by deomsh, 19 May 2021 - 10:14 AM.


#29 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 May 2021 - 04:45 PM

Yes, but I think you have to write to a memory location and then read it to get the values into a variable, be aware that writing and reading from memory need to have decompression disabled to work "always" or reliably Steve6375 has also a few notes about this.

 

:duff:

Wonko



#30 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 28 May 2021 - 11:59 PM

I did some new tests regarding num_hist and the History Buffer and found something new.

 

If the History Buffer is fully filled up, num_hist still increases if new commands are added. But if ALL entries in the History Buffer are 'called' with the Arrow-Up key, afterwards num_hist has been changed to the actual number of entries.

 

See the action-picture (especially last two lines), but I can't show the walking to the History of cause.

https://postimg.cc/0K8vx50V

 

So I revised my add_hist sub-routine, without check of the state of the History Buffer. Separate conversion of hex-values to Little Endian are not needed anymore, (raw) read from and (raw) write to the memory address 'NHistory' is enough. Below both routines with (in my opinion) needed functionality.

:NHistory
setlocal && set *
cat --skip=0x340000 --locate=\x00\x00\x00\x00\x00\x92\x3E\x00 (md)0x0+0x1D00 > nul &; set /A ZHistory=%?% > nul
set /A SHistory=%ZHistory%+0x8 > nul
raw read %SHistory% > nul &; set /A read=%@retval% > nul
if not %read%==0x6 && set /A SHistory=%SHistory%+0x4 > nul &; raw read %SHistory% > nul &; set /A read=%@retval% > nul
if %read%==0x6 && set /A NHistory=%SHistory%+0x10 > nul
if not %read%==0x6 && set NHistory=
#if not exist NHistory && echo num_history not found
raw read %NHistory% > nul &; set /a numhist=%@retval% > nul
endlocal && set NHistory=%NHistory% && set numhist=%numhist% && goto :eof

:add_hist
setlocal && set * && set NHistory=%NHistory%
set /A num_hist=0x0 > nul && set /a numhist=0 > nul
if not exist NHistory && endlocal && goto :eof
#if not exist NHistory && endlocal && echo Abort: NHistory not found && pause --wait=7 && goto :eof
raw read %NHistory% > nul &; set /A num_hist=%@retval% > nul &; set /a numhist=%num_hist% > nul
set /A num_hist=%num_hist%+0x1 > nul && set /a numhist=%numhist%+1 > nul
raw write --bytes=2 %NHistory% %num_hist% > nul
raw read %NHistory% > nul &; set /A num_hist=%@retval% > nul &; set /a numhist=%num_hist% > nul
endlocal && set numhist=%numhist%
goto :eof


Of cause the variable 'numhist' can be left out, is only the decimal representation of num_hist. Also the setlocal/ endlocal lines are not strictly needed.

 

Further I used my next version of KEYBUFF.G4B to do a more reliable investigation of maximum possible length of the command-line.

In case of the 'grub> ' command-line after typing the maximum of chars accepted, I found the History Buffer entry to be 0x642, so 1602 bytes. Minus two leading index-bytes and one terminating byte the maximum number of chars WRITTEN in the History Buffer will be 1599.

 

See the action picture (also a preview of the new functionality of 'FIFO' I added to KEYBUFF.G4B)

https://postimg.cc/ZB9m5sGd

 

In case of the 'set /p' command-line the after typing the maximum of chars accepted, I found the History Buffer entry to be 0x201, so 513 bytes. Minus two leading index-bytes and one terminating byte the maximum number of chars will be 510, same number as I tested directly.

 

Last I found if the History Buffer is fully filled up, and if the last entry is PARTLY 'shifted' from the LIFO-buffer, this 'crippled' entry can still be 'called' with the Arrow-Up key. In earlier tests I found the contrary.

The index bytes of the entry-length has not been changed. I think the zero's in memory AFTER the buffer are counted, but will be neglected in the length of the recreated command.

 

BTW a correction regarding the length of the History Buffer. Should be 0x1F40 (exactly 8000 bytes), NOT 0x2000 (= 8192 bytes) as I stated in the text-part of earlier versions of KEYBUFF.G4B.
 



#31 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 09 June 2021 - 08:51 PM

I finished KEYBUFF.G4B! It has become a History Buffer Multitool.

 

I added following:

1) Sync => Check integrity of History Buffer, delete 'bad' entries and synchronize num_hist.

2) Export => Export full History Buffer to a 8000-bytes file with -almost unused- extension '.kbc' (stands for KeyBufferCopy).

3) Import => Import earlier exported .kbc-file.

4) Fifo => reverse order of all valid entries in History Buffer.

5) Convert => Convert all History buffer entries to text and save as file (LineFeed only, no Carriage Return).

 

Still didn't ask Brito for more rights (I think he must have been very busy lately). So pictures on imgur and file from my DropBox.

 

The ZIP contains further a specimen of History Buffer and text-conversion. Further eight empty HISTBUF1-8.KBC files (8000 bytes) and eight empty HISTBUF1-8.TXT files (7990 bytes).

 

Files: https://drive.google...iew?usp=sharing

 

Images: https://imgur.com/gallery/ERD00HX

 

 

BTW if FAT is available, creation of files possible too (searched for in (bd), (bd)/grub and current root).


Edited by deomsh, 09 June 2021 - 09:10 PM.


#32 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 20 June 2021 - 04:02 PM

I wonder if it's possible to give Grub4Dos an ArrowUp-command from a script, to get the last entry of the History Buffer on a 'set /p' command-line.

If editing a line with the the Grub4Dos built-in menu-editor, History Buffer entries can be 'called' too (if existing). But the current line if pushing 'e' to edit, is already written to the command-line, with cursor at the end if the command-line. With help of KEYBUFF.G4B I found that 'Entered' lines are written to the History Buffer too.

For now I have to press the ArrowUp-key physically if using History Buffer entries with the 'set /p' command-line.

Any help would be appreciated!

Edited by deomsh, 20 June 2021 - 04:14 PM.


#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 June 2021 - 06:19 PM

Sorry, but I am missing the practical utility of a "scriptable" Arrow-up key press. :unsure:

 

I thought that through your script(s) you can access the history buffer from the script itself (bypassing the grub4dos arrow up function) :dubbio:

 

Can you make an example of a situation where this would be useful?

 

Have you tried with Fn.2 (putchar)?

https://rmprepusb.co...4dos-internals/

 

:duff:

Wonko



#34 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 20 June 2021 - 09:38 PM

My KEYBUFF.G4B is a more or less experimental preparatory study to use Grub4Dos' History Buffer in a text-editor for Grub4Dos I am working on. As I mentioned earlier in this thread.

KEYBUFF.G4B as such has limited practical use, although I already use it to export experiments with commands on the Grub4Dos command-line to text. In that case the fifo-function is really practical too.

 

My current editor can edit full lines one by one only. A set /p command-line is called to edit the chosen line (together with some magic using Fn.4/ Fn.5 call's). Just before editing the full content of that line is copied to the History Buffer, and can be 'called' back to the set /p command-line with ArrowUp. Afterwards the line can be edited, moving the cursor with arrows or go to Home or End, just as normally on a Grub4Dos command-line.

 

I converted a screenshot to text with an online convertor (bad quality, I had to edit the result - all '%' became 'x').

Written as text below my editor in EDIT-mode of an older version of my editline-script. Highlighting of Menu-entries or line-numbers not visible of course.

-------------------------------------------------------------------------------
Add Ins Edit Write Join Sel Copy Xut Paste Goto Find Next Del Replace Menu_ 
----------------------------EDIT (fd0)/fattext.g4b-----------------------------
0575 :keybuff
0576 setlocal
0577 set /A mdbasel=%mdbase%+0x1 > nul
0578 set /A mdkeybuf=%mdbase%+0x7 > nul
0579 set /A length=%length%-0x2 > nul
0580 set /A entrylen=%length%+0x3 > nul
0581 if %entrylen%>=0x203 && set bufentry=\x02\x02
0582 if %entrylen%<=0x202 && set bufentry=\x%entrylen:-3,2%\x0%entrylen:-2,1%
0583 if %entrylen%<=0xFF && set bufentry=\x%entrylen:-2%\x00
0584 if %entrylen%<=0xF && set bufentry=\x0%entrylen:-2,1%\x00
0585 echo -n > (md)%mdkeybuf%+16
0586 echo -n -e %bufentry% > (md)%mdkeybuf%+16
0587 dd if=(md)%mdbasel%+3 of=(md)%mdkeybuf%+16 bs=1 count=%length% skip=0 seek
     =0x2 > nul
0588 set /A bufflen=0x2000-%entrylen% > nul
0589 dd if=(md)0x0+0x1F63 of=(md)%mdkeybuf%+16 bs=1 count=%bufflen% skip=0x3EA4
     C0 seek=%entrylen% > nul
0590 call Fn.24 0x3EA4C0 0x00 0x2000
0591 dd if=(md)%mdkeybuf%+16 of=(md)0x0+0x1F63 bs=1 count=0x2000 skip=0 seek=0x
     3EA4C0 > nul
0592 endlocal
--------------------------------------------------------------------------------

In this case line 0576 is the 'active' line (line-number is highlighted).

 

If I press 'E' to edit the line, the echo-part of the set /p command-line plus cursor can be 'seen'.

-------------------------------------------------------------------------------

----------------------------EDIT (fd0)/fattext.g4b-----------------------------
0575 :keybuff
0576>_
0577 set /A mdbasel=%mdbase%+0x1 > nul
(.......)

After pressing ArrowUp once, the original line is ready for editing:

-------------------------------------------------------------------------------

----------------------------EDIT (fd0)/fattext.g4b-----------------------------
0575 :keybuff
0576>setlocal_
0577 set /A mdbasel=%mdbase%+0x1 > nul
(.......)

After editing the line and pressing Enter, things look like:

-------------------------------------------------------------------------------
Add Ins Edit Write Join Sel Copy Xut Paste Goto Find Next Del Replace Menu_ 
----------------------------EDIT (fd0)/fattext.g4b-----------------------------
0575 :keybuff
0576 setlocal && set * && set mdbase=%mdbase% && set length=%length%
0577 set /A mdbasel=%mdbase%+0x1 > nul
0578 set /A mdkeybuf=%mdbase%+0x7 > nul
0579 set /A length=%length%-0x2 > nul
0580 set /A entrylen=%length%+0x3 > nul
0581 if %entrylen%>=0x203 && set bufentry=\x02\x02
0582 if %entrylen%<=0x202 && set bufentry=\x%entrylen:-3,2%\x0%entrylen:-2,1%
0583 if %entrylen%<=0xFF && set bufentry=\x%entrylen:-2%\x00
0584 if %entrylen%<=0xF && set bufentry=\x0%entrylen:-2,1%\x00
0585 echo -n > (md)%mdkeybuf%+16
0586 echo -n -e %bufentry% > (md)%mdkeybuf%+16
0587 dd if=(md)%mdbasel%+3 of=(md)%mdkeybuf%+16 bs=1 count=%length% skip=0 seek
     =0x2 > nul
0588 set /A bufflen=0x2000-%entrylen% > nul
0589 dd if=(md)0x0+0x1F63 of=(md)%mdkeybuf%+16 bs=1 count=%bufflen% skip=0x3EA4
     C0 seek=%entrylen% > nul
0590 call Fn.24 0x3EA4C0 0x00 0x2000
0591 dd if=(md)%mdkeybuf%+16 of=(md)0x0+0x1F63 bs=1 count=0x2000 skip=0 seek=0x
     3EA4C0 > nul
0592 endlocal
--------------------------------------------------------------------------------

If there is a way to write ArrowUp to *somewhere* it's recognized before set /p is called, My line-editing would be more 'smooth' (in this respect like the Grub4Dos built-in Menu-editor).

 

I experimented with beep 0 3000 on the command-line. If I press ArrowUp twice during beep, the command before is 'called' from the History Buffer to the set /p command-line, and directly editable. Below the 'print-screen'.

grub> set /a c=1
grub> echo Press ArrowUp twice ;; beep 0 3000 ;; set var= ;; set /p "var= > "
Press ArrowUp twice
 > set /a c=1
grub> echo %var%
set /a c=1

BTW pause didn't work, the keystroke is 'consumed' afterwards.

 

BTW2 is there more information available about call Fn.2 putchar?
 


Edited by deomsh, 20 June 2021 - 09:52 PM.


#35 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 June 2021 - 03:23 PM

I don't know what added info, it is only something to test.

 

 

 

2 putchar – e.g. call Fn.2 49 prints ‘1’ (if in the text mode console, call Fn.2 7 will ‘beep‘ the internal speaker if your BIOS and hardware supports it – i.e. if it is a PC and has a ‘beeper-speaker’ fitted!)

 

Try:

call Fn.2 49

it should print 1 to the command line

 

Then try:

call Fn.2 <with various ascii control character numbers, 1 to 31)

 

does it send a character/control that works for your need? :unsure:

 

:duff:

Wonko

 



#36 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 21 June 2021 - 04:36 PM

Thanks a lot.
I tried all numbers up to hundred, but chars are writen to screen before 'set /p'. So no solution.

In case of 'beep' keystrokes are written to the BIOS Keyboard Buffer, I checked the 32 bytes starting at 0x41C.

I found a BIOS Interrupt, INT16\AH=05h which can be used to write keystrokes to the BIOS Keyboard Buffer. But I have no idea about the how-to.

I found following in: https://en.m.wikiboo...errupt_handlers
"Prepare : AH = 05h CH – scan code of keystroke (table A.02-1) CL – ASCII code of corresponding character (table A.02-1)

On return : AL – error code (A.06-1) AH contents may be altered.

Note 1: Obsolete BIOS versions don't support this function.

Note 2: Codes of several keys (for example, of the ENTER key), being inserted into keyboard buffer, induce execution of corresponding functions.

Note 3: The INT 16\AH=05h function can't be used to insert codes of "functional" keys (SHIFT, CTRL, ALT)."

Maybe some magic with grubutil BIOS?

#37 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 June 2021 - 07:59 PM

Well, you can try that, it is int 16,5:

https://stanislavs.o...c/int_16-5.html

https://stanislavs.o...scan_codes.html

 

From what I can understand, this example here:

https://rmprepusb.co...ntor-1616/#bios

 

 

 

# beep the speaker (if one is fitted) - send a Ctrl-G to the display
/bios int=0x10 eax=0xe07 ebx=0x0 > nul

is using interrupt 10:

http://www.ctyme.com/intr/rb-0106.htm

with ah=0E (and al=07)

 

Using the info here:

https://stackoverflo...al-map-onto-eax

 

https://www.cs.uaf.e..._registers.html

 

It should be possible to find out the right eax value combining ah, ax, al, etc. so that you can use the /bios grubutil. :unsure:

possibly:

/bios int=0x16 eax=0x0500 ecx=0x4800 

:dubbio:

 

:duff:

Wonko



#38 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 21 June 2021 - 10:09 PM

First try already seems to work! The last entry in the History Buffer is 'automagically' written to the set /p command-line and can be edited as usual. Next is testing in my editline-script.

 

I used following script to observe the BIOS Keyboard Buffer too.

--------------------------------------
INT16AH5.G4B
--------------------------------------
!BAT
## Test INT16\AH=05 with grubutil BIOS
echo && echo View keycode in BIOS Keyboard Buffer of key 'ArrowUp' written with Int16\AH=05h && echo
/bios int=0x16 eax=0x0500 ecx=0x48E0 ;; echo ;; echo
read 0x417 > nul &; set /A read417=%@retval% > nul
set /A index417=0x%read417:~2,2%+0x400-0x2 > nul
read %index417% > nul &; set /A keycode1=%@retval% > nul
set keycode1=%keycode1% &; set /a codelen1=%@retval% > nul
echo read417=%read417% index417=%index417%
echo keycode1=%keycode1% codelen1=%codelen1% && echo
if %codelen1%==10 && echo keycode1 BIOS=%keycode1:~0,6%
if %codelen1%==9 && echo keycode1 BIOS=%keycode1:~0,5%
if %codelen1%==8 && echo keycode1 BIOS=%keycode1:~0,6%
if %codelen1%==6 && echo keycode1 BIOS=%keycode1:~0,6%
echo && cat --hex --length=0x40 (md)0x2+1 && echo
set var= ;; set /p "var= > " && echo && echo
echo setpvar=%var% && echo

:eof

Again I converted the print-screen to text (below):


grub> int16ah5

View keycode in BIOS Keyboard Buffer of key 'ArrowUp' written with Int16\AH=05h

EAX=00000500 EBX=00000000 ECX=00004800 EDX=00000000 ESI =00000000 
EDI=00000000 EBP=00000000 ESP=00006634 EIP=00000000 eFLAG=00200256 
DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 CS=0000 NU UP EI PL ZR AC PE NC

read417=0x30000000 index417=0x42E keycode1=0x48001COD codelen1=10

keycode1 BIOS=0x4800

00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 9F ; ................ 
00000010: 6F 00 00 7F 02 00 00 00 00 00 30 00 32 00 00 48 ; 0.........0.2..H 
00000020: 0D 1C E0 48 E0 48 E0 48 0D 1C E0 48 E0 48 0D 1C ; ...H.H.H...H.H.. 
00000030: 00 48 E0 48 E0 48 0D 1C E0 48 E0 48 0D 1C 02 00 ; H.H.H...H.H.....

 > int16ah5

setpvars=int16ah5

grub>

Wonko, you are genius! Thanks SO much :worship:
 



#39 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 June 2021 - 07:26 AM

Very good. :)

 

Though as always I only tried to put together (half-@§§edly) bits and pieces from here and there.

 

I am not sure to understand (actually I am quite sure I don't understand) the ecx=0x48E0

echo && echo View keycode in BIOS Keyboard Buffer of key 'ArrowUp' written with Int16\AH=05h && echo

/bios int=0x16 eax=0x0500 ecx=0x48E0 ;; echo ;; echo

Where does the E0 come from?

Is it the 48E0 scancode you get on your BIOS for the Up Arrow?

But then why the ecx is 4800? :dubbio:

View keycode in BIOS Keyboard Buffer of key 'ArrowUp' written with Int16\AH=05h


EAX=00000500 EBX=00000000 ECX=00004800 EDX=00000000 ESI =00000000

 

Whilst in the hex dump it is seemingly 48E0?

 

As a side-side note, it seems like GRUB2 has a "plain" sendkey command:

https://www.gnu.org/...ey.html#sendkey

 

If the approach of int16,5 works, it should be possible to "emulate" its functions in a script/batch. :unsure:

 

This could be useful (maybe) to emulate (in some special cases) what good ol' XOSL could do (I remember a system, may years ago where I had as primary bootloader XOSL and as secondary NTLDR with a rather long, 5 or 6 items BOOT.INI and had various entries in XOSL, that were actually connected to the BOOT.INI ones by sending a number of down arrow chars to the keyboard buffer).

That way you were able to choose what to boot directly in the XOSL (semi) graphical interface, by-passing the text mode BOOT.INI choices.

 

:duff:

Wonko



#40 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 23 June 2021 - 12:01 PM

Oeps! :wub: Wrong line copied... Your eyes are better than mine.

But the 'output' was correct, (ECX=00004800). I tested the 'official' code for ArrowUp (=0x48E0) too, makes no difference in result.

 

I made my script a bit more universal to test writing multiple keystrokes (BIOS Keyboard Buffer shown with absolute addressing):

!BAT
## Test INT16\AH=05 with grubutil BIOS
debug off
echo View keycode in BIOS Keyboard Buffer of inserted keycode/number of writes with Int16\AH=05h && echo
set key= &; set /p /A "key= Give key scancode in hex > " && echo
if not exist key && goto :eof
set /a number=1 > nul &; set /p /a "number= Give number (Enter=1) > " && echo && echo
set /a counter=0 > nul
:loop
set /a counter=%counter%+1 > nul
if not %counter%==1 && set "null=> nul"
if %counter%==1 && set null=
if %number%==1 && debug on
/bios int=0x16 eax=0x0500 ecx=%key% %null%
debug off
if not %counter%>=%number% && goto :loop
read 0x417 > nul &; set /A read417=%@retval% > nul
set /A index417=0x%read417:~2,2%+0x400 > nul
read %index417% > nul &; set /A keycode1=%@retval% > nul
set keycode1=%keycode1% &; set /a codelen1=%@retval% > nul
#echo read417=%read417% index417=%index417%
#echo keycode1=%keycode1% codelen1=%codelen1% && echo
echo && echo
if %codelen1%==10 && echo keycode1 BIOS=0x%keycode1:~-4,4%
if %codelen1%==9 && echo keycode1 BIOS=0x%keycode1:~-3,3%
if %codelen1%==8 && echo keycode1 BIOS=0x%keycode1:~-4,4%
if %codelen1%==6 && echo keycode1 BIOS=0x%keycode1:~-4,4%
echo && cat --hex --skip=0x400 --length=0x40 (md)0x0+3 && echo
set var= ;; set /p "var= > " && echo && echo
echo setpvar=%var%
set var=%var% &; set /a setplen=%@retval% > nul &; echo setplen=%setplen%
:eof

This is the 'output' - 4 ArrowUp's are needed of course (input on set /p command-line is written to the History Buffer too).

grub> Wonko is Good!
Error: No such command: Wonko
grub> int16ah5
View keycode in BIOS Keyboard Buffer of inserted keycode/number of writes with I
nt16\AH=05h

 Give key scancode in hex > 0x4800
 Give number (Enter=1) > 4

EAX=00000500 EBX=00000000 ECX=00004800 EDX=00000000 ESI =00000000
EDI=00000000 EBP=00000000 ESP=00006634 EIP=00000000 eFLAG=00200256
DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 CS=0000 NU UP EI PL ZR AC PE NC

keycode1 BIOS=0x4800

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 3A 00  22 00 00 48 ; o.........:."..H 
00000420: 00 48 E0 48  E0 48 E0 48  E0 48 0D 1C  E0 48 E0 48 ; .H.H.H.H.H...H.H 
00000430: E0 48 E0 48  E0 48 E0 48  0D 1C 00 48  00 48 02 00 ; .H.H.H.H...H.H..

 > Wonko is Good!

setpvars=Wonko is Good!
setplen=14
grub>

If char-codes are used, I found the maximum number to be 15. See 'output' below

grub> int16ah5
View keycode in BIOS Keyboard Buffer of inserted keycode/number of writes with I
nt16\AH=05h

 Give key scancode in hex > 0x1E41
 Give number (Enter=1) > 16

EAX=00000500 EBX=00000000 ECX=00001E41 EDX=00000000 ESI =00000000
EDI=00000000 EBP=00000000 ESP=00006634 EIP=00000000 eFLAG=00200256
DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 CS=0000 NU UP EI PL ZR AC PE NC

keycode1 BIOS=0x1E41

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 2C 00  2A 00 41 1E ; o.........,.".A. 
00000420: 41 1E 41 1E  41 1E 41 1E  41 1E 0D 1C  41 1E 41 1E ; A.A.A.A.A...A.A. 
00000430: 41 1E 41 1E  41 1E 41 1E  41 1E 41 1E  41 1E 02 00 ; A.A.A.A.A.A.A...

 > AAAAAAAAAAAAAAA

setpvars=AAAAAAAAAAAAAAA
setplen=15
grub>

So I can imagine other uses will function too.
 

 



#41 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 June 2021 - 01:07 PM

Should be 16 (according to the off-topic source):

https://www.gnu.org/...ey.html#sendkey

maybe one char (two bytes in this case like the scancode)  is "consumed" by some of the grub4dos mechanism (but the 0D1C in the hex dump is (why?) after 6 occurences :w00t: and after it there 9 more :ph34r:). :unsure:

 

Through the 0x1E41 example, it is now clear that the value is written in little-endian, so the 4 (four)  occurences in the hex dump for:

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 4

 

 

must be:

 

 

00000400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 9F ; ................
00000410: 6F 00 00 7F 02 00 00 00 00 00 3A 00 22 00 00 48 ; o.........:."..H
00000420: 00 48 E0 48 E0 48 E0 48 E0 48 0D 1C E0 48 E0 48 ; .H.H.H.H.H...H.H
00000430: E0 48 E0 48 E0 48 E0 48 0D 1C 00 48 00 48 02 00 ; .H.H.H.H...H.H..

 

Whilst in the previous one there was only a single occurrence:

 

 

00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 9F ; ................
00000010: 6F 00 00 7F 02 00 00 00 00 00 30 00 32 00 00 48 ; 0.........0.2..H
00000020: 0D 1C E0 48 E0 48 E0 48 0D 1C E0 48 E0 48 0D 1C ; ...H.H.H...H.H..
00000030: 00 48 E0 48 E0 48 0D 1C E0 48 E0 48 0D 1C 02 00 ; H.H.H...H.H.....

immediately followed by the 0D1C (which then seemingly acts as separator) :dubbio:

 

It is "queer".

 

Unless the E048's (and the "strange" 0D1C positions) are "remnants" of previous experiments.

 

What happens if you (starting from a fresh boot) issue:

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 1

 

and then, again from fresh boot, issue:

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 2

 

and then, again from fresh boot, issue:

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 3

 

and then, again from fresh boot, issue:

 

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 4

 

Maybe comparing the respective hex dumps it would be possible to make sense of the behaviour. :unsure:

 

As a side note, personally I would change "number" with "times" or "how many times? (max 15)".

 

:duff:

Wonko



#42 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 23 June 2021 - 02:37 PM

0D1C is Little-Endian for 0x1C0D = Enter. So in the 'output' I gave their should be at least 4 of them in the BIOS (CIRCULAR) Keyboard Buffer.

 

Even entries from the MS-DOS command-line are preserved; apparently Grub4Dos didn't 'clean' the BIOS Keyboard Buffer (I tried with Fn.24 0x41E 0x00 0x20: in LimboX86 possible, but in Vbox a big crash...).

 

If I start everything from batches without textual input in between (so starting INT16AH4.G4B from MENU.LST I get:

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 24 00  26 00 0D 1C ; o.........$.&... 
00000420: 0D 1C 0D 1C  00 48 00 00  00 00 00 00  00 00 00 00 ; .....H..........
00000430: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 02 00 ; ................

But because the History Buffer is empty, nothing happens on the set /p command-line, which make sense. In MS-Dos I have to give Enter twice, and once for choosing my menu in MENU.LST

 

If I do what you asked for ('output' always below):

 

Give key scancode in hex > 0x4800
Give number (Enter=1) > 1

 

Gives '1' on my set /p command-line

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 36 00  38 00 0D 1C ; o.........6.8... 
00000420: 0D 1C 0D 1C  30 0B 78 2D  34 05 38 09  30 0B 30 0B ; ....0.x-4.8.0.0.
00000430: 0D 1C 31 02  0D 1C 00 48  00 00 00 00  00 00 02 00 ; ..1....H........

Give key scancode in hex > 0x4800
Give number (Enter=1) > 2

 

Gives '0x4800' on my set /p command-line

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 36 00  3A 00 0D 1C ; o.........6.:... 
00000420: 0D 1C 0D 1C  30 0B 78 2D  34 05 38 09  30 0B 30 0B ; ....0.x-4.8.0.0.
00000430: 0D 1C 32 03  0D 1C 00 48  00 48 00 00  00 00 02 00 ; ..1....H.H......

Give key scancode in hex > 0x4800
Give number (Enter=1) > 3

 

Gives '0x4800' on my set /p command-line (only two entries in History Buffer!)

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 36 00  3C 00 0D 1C ; o.........6.<... 
00000420: 0D 1C 0D 1C  30 0B 78 2D  34 05 38 09  30 0B 30 0B ; ....0.x-4.8.0.0.
00000430: 0D 1C 33 04  0D 1C 00 48  00 48 00 48  00 00 02 00 ; ..3....H.H.H....

Give key scancode in hex > 0x4800
Give number (Enter=1) > 4

 

Gives '0x4800' on my set /p command-line (only two entries in History Buffer!)

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 36 00  1E 00 0D 1C ; o.........6..... 
00000420: 0D 1C 0D 1C  30 0B 78 2D  34 05 38 09  30 0B 30 0B ; ....0.x-4.8.0.0.
00000430: 0D 1C 34 05  0D 1C 00 48  00 48 00 48  00 48 02 00 ; ..4....H.H.H.H..

And one for free:

 

Give key scancode in hex > 0x4800
How many times? (max 15 - Enter=1) > 5

 

Gives still '0x4800' on my set /p command-line (only two entries in History Buffer!)

00000400: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 C0 9F ; ................ 
00000410: 6F 00 00 7F  02 00 00 00  00 00 36 00  20 00 00 48 ; o.........6. ..H 
00000420: 0D 1C 0D 1C  30 0B 78 2D  34 05 38 09  30 0B 30 0B ; ....0.x-4.8.0.0.
00000430: 0D 1C 35 06  0D 1C 00 48  00 48 00 48  00 48 02 00 ; ..5....H.H.H.H..

And so on. I hope I made no mistakes, typed everything by hand.

 

BTW in this case there are no 'Enters' (0D1C) after 0048-ArrowUp's written with INT16\AH=05 (except 'older ones' that are not overwritten yet = last case of '5 times') B)

 

BTW2  Start reading from 0x417: Keyboard Status (2 bytes); 0x419: Alt-related (1 byte); 0x41A: Address of Keyboard Buffer Head (2 bytes); 0x41C: Address of Keyboard Buffer Tail (2 bytes); 0x41E: Keyboard Buffer (32 bytes). 0x43E+F are diskette-related.


Edited by deomsh, 23 June 2021 - 02:54 PM.


#43 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 June 2021 - 09:19 AM

Even entries from the MS-DOS command-line are preserved; apparently Grub4Dos didn't 'clean' the BIOS Keyboard Buffer (I tried with Fn.24 0x41E 0x00 0x20: in LimboX86 possible, but in Vbox a big crash...).

 

Maybe looping a few Fn.19's ? :dubbio:

From what I get from the scarce information available, the difference between Fn. 19 and Fn. 20 is that the first clears the buffer, while the latter doesn't :unsure:.

 

So,

0x41A is fixed to 0x0036

0x41C starts from (in this example) 0x0038, and increases by two, 0x003A, 0x003C, then it "jumps" to 0x001E (why? :unsure:) and with the "free" fifth iteration it wraps around and becomes 0x0020.

 

And still the 32 bytes at 0x041E should imply 16 possible scancodes, not 15 :dubbio:

 

:duff:

Wonko



#44 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 24 June 2021 - 07:19 PM

Looping Fn19's only readout the key-codes from the keyboard buffer. They are not deleted. The only a difference with pause --test-key I found is the debug output: high and low byte only with pause --test-key, none with Fn.19. With echo %@retval% both give the decimal scan-code. Also Fn.19 seems to wait until a key is pressed, pause --test-key can be combined with --wait=xx (seconds).

 

Fn.20 didn't work for me, output is always -1 (or 0xFFFFFFFFFFFFFFFF if converted to hex).

 

But in between I have some ideas about the BIOS Keyboard Buffer.

 

Fact: BIOS Keyboard Buffer is a circular 32 bytes FIFO-buffer, starting at offset 001E, ending at 003D (so 0x41E-0x43D). Pointers are 'head' at 0x41A and 'tail' at 0x41C.

 

Observation I: after a keystroke is written, head and tail are always equal, and point directly to an address after the address of the last keystroke written.

Observation II: before a keystroke is written, head is mostly a lower value than tail. In that case for one keycode the difference is always 2 bytes

Obrservation III: if the head points to, and the key to be written lies at 0x41C, so at the end of the buffer, tail points to the beginning of the buffer at 0x41E.

 

My Theory of Operation: if head an tail are equal, there is no read-out of the buffer. If they are NOT equal, the buffer will be read-out, and keystrokes are written to the command-line. Afterwards the value of the head-pointer is set equal to the value of the tail-pointer. This will explain too why only 15 of 16 key-codes can be read-out in one 'session'.

 

Experiment: script BIOSKEY.G4B

1) read-out the head-pointer.

2) write ONE key-code to the corresponding address.

3) Set the tail-pointer 2 bytes higher, unless that value points to 0x43E.

4) In that case set tail to 1E, so pointer to address 0x41E.

5) Hex-dump of needed bytes before read-out of the buffer

6) Go to some command-line to get the result

7) Hex-dump of needed bytes after read-out of the buffer

------------------------------------
BIOSKEY.G4B
------------------------------------
!BAT
debug 0 ;; pager off
set newkey= && set /p:60 /A "newkey= Give keycode in hex > " && echo && echo
if not exist newkey && goto :eof
read 0x41a > nul &; set /A read41a=%@retval% > nul
set /A head=%read41a:~0,4% > nul && set /A tail=0x%read41a:~-2,2% > nul
set /A headmem=%head%+0x400 > nul
read %headmem% > nul &; set /A key=%@retval% > nul
if %key%>=0x10000 && set /A oldkey=0x%key:~-4,4% > nul
if %key%<=0xFFFF && set /A oldkey=%key% > nul
echo read41a=%read41a% head=%head% tail=%tail% headmem=%headmem% oldkey=%oldkey%
cat --hex --skip=0x410 --length=0x30 (md)0x0+3 && echo
echo newkey=%newkey% headmem=%headmem%
write --bytes=2 %headmem% %newkey% > nul
cat --hex --skip=0x410 --length=0x30 (md)0x0+3 && echo
set /A newtail=%head%+0x02 > nul &; if %newtail%>=0x3E && set /A newtail=0x1E > nul
echo newtail=%newtail%
write --bytes=1 0x41C %newtail% > nul
cat --hex --skip=0x410 --length=0x30 (md)0x0+3 && echo
set /p:60 "var= > " && echo && echo
cat --hex --skip=0x410 --length=0x30 (md)0x0+3 && echo

:eof

This is the 'output' (as usually bad-OCR image-to-text-conversion - I checked everything except the hex-translations this time)

grub> bioskey
 Give keycode in hex > 0x00221

read41a =0x3C003C head=0x3C tail=0x3C headmem=0x43C oldkey=0x48E0 
00000410: 6F 00 00 75  02 00 00 00  00 00 3C 00  3C 00 0D 1C ; 0. ............ 
00000420: E0 48 E0 48  E0 48 0D 1C  21 02 0D 10  E0 48 E0 48 ; .H.H.H... ...H.H 
00000430: E0 48 0D 1C  E0 48 E0 48  E0 48 0D 10  E0 48 02 00 ; .H...H.H.H...H..

newkey=0x221 headmem=0x43C 
00000410: 6F 00 00 7F  02 00 00 00  00 00 3C 00  3C 00 0D 1C ; 0.........<.<... 
00000420: E0 48 E0 48  E0 48 0D 1C  21 02 0D 10  E0 48 E0 48 ; .H.H.H... ...H.H 
00000430: E0 48 0D 1C  E0 48 E0 48  E0 48 0D 1C  21 02 02 00 ; .H...H.H.H.....

newtail=0X1E 
00000410: 6F 00 00 75  02 00 00 00  00 00 3C 00  1E 00 0D 1C ; 0. .............
00000420: E0 48 E0 48  E0 48 0D 1C  21 02 0D 10  E0 48 E0 48 ; .H.H.H... ...H.H
00000430: E0 48 0D 1C  E0 48 E0 48  E0 48 0D 1C  21 02 02 00 ; .H...H.H.H..!...!

> !

00000410: 6F 00 00 77  02 00 00 00  00 00 20 00  20 00 0D 1C ; 0...... 
00000420: E0 48 E0 48  E0 48 0D 1C  21 02 0D 10  E0 48 E0 48 ; .H.H.H... ...H.H 
00000430: E0 48 0D 10  E0 48 E0 48  E0 48 0D 1C  21 02 02 00 ; .H...H.H.H.....
grub>

BTW I had to play a bit with extra zero's before the key-code input to get the desired result: tail = 1E (because of many input-keys before). After the key-code is written to the set /p command-line I had to give Enter to move on, so the last head/tail values are 20 instead of 1E
 

 

 



#45 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 24 June 2021 - 09:38 PM

Post edit: the values at 0x41B should be '1C' not '10' in all four hex read-outs



#46 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2021 - 09:24 AM

Very good :), it seems that everything is clear but the why we have 15 values and not 16.

 

What happens with (say) 0x352F or 0x2D78 (i.e. better readable in hex dump "/5" or "x-":

Give key scancode in hex > 0x352F
Give number (Enter=1) > 15

 

vs:

 

Give key scancode in hex > 0x352F
Give number (Enter=1) > 16

 

:unsure:

 

:duff:

Wonko



#47 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 26 June 2021 - 10:03 PM

Still not convinced? I found in various sources a 'simple;  Circular Buffer will read-out (n-1) elements, unless extra overhead is used to administrate head and tail positions.

 

But here is what you asked for (in one 'picture' to reduce OCR-correction workload - but /5 is easier in this respect too).

grub> int16ah5 
View keycode in BIOS Keyboard Buffer of writes with Int16\AH=05h 
 Give key scancode in hex > 0x352F 
 How many times? (max 15 - Enter=1) > 15
00000410: 6F 00 00 7F  02 00 00 80  00 00 28 00  26 00 2F 35 ; o.........(.&./5 
00000420: 2F 35 2F 35  2F 35 0D 1C  2F 35 2F 35  2F 35 2F 35 ; /5/5/5../5/5/5/5 
00000430: 2F 35 2F 35  2F 35 2F 35  2F 35 2F 35  2F 35 02 00 ; /5/5/5/5/5/5/5..
 > ///////////////
setpvar=/////////////// 
00000410: 6F 00 00 7F  02 00 00 80  00 00 28 00  28 00 2F 35 ; o.........(.(./5 
00000420: 2F 35 2F 35  2F 35 0D 1C  2F 35 2F 35  2F 35 2F 35 ; /5/5/5../5/5/5/5 
00000430: 2F 35 2F 35  2F 35 2F 35  2F 35 2F 35  2F 35 02 00 ; /5/5/5/5/5/5/5.. 
grub> int16ah5
View keycode in BIOS Keyboard Buffer of writes with Int16\AH=05h
 Give key scancode in hex > 0x352F
 How many times? (max 15 - Enter=1) > 16
00000410: 6F 00 00 7F  02 00 00 80  00 00 2A 00  28 00 2F 35 ; o..........*.(./5 
00000420: 2F 35 2F 35  2F 35 2F 35  0D 1C 2F 35  2F 35 2F 35 ; /5/5/5/5../5/5/5 
00000430: 2F 35 2F 35  2F 35 2F 35  2F 35 2F 35  2F 35 02 00 ; /5/5/5/5/5/5/5..
 > ///////////////
setpvar=/////////////// 
00000410: 6F 00 00 7F  02 00 00 80  00 00 2A 00  2A 00 2F 35 ; o.........*.*./5 
00000420: 2F 35 2F 35  2F 35 2F 35  0D 1C 2F 35  2F 35 2F 35 ; /5/5/5/5../5/5/5 
00000430: 2F 35 2F 35  2F 35 2F 35  2F 35 2F 35  2F 35 02 00 ; /5/5/5/5/5/5/5..
grub>


 



#48 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 June 2021 - 08:38 AM

I still think we are misled by the [ENTER] or 0x1C0D you have to press, in theory if you fill the buffer, there would be only 0x352F's :unsure:

 

I.e., if you use a pre-made batch hardcoded so that you do not have to provide input, you should be able to write 16 0x352F :dubbio:

 

Or maybe the [ENTER] you have to press anyway to issue the command counts as well and ends in the buffer ...

 

Anyway, it doesn't matter, the actual original problem has been solved, good work  :thumbsup: .

 

:duff:

Wonko



#49 deomsh

deomsh

    Member

  • Advanced user
  • 99 posts
  •  
    Netherlands

Posted 27 June 2021 - 10:08 PM

Thanks a lot for all help!

 

INT16\AH=05h is 'alive and kicking' in my line-editor. Only two script-lines extra needed, it's miracle. :rolleyes:

 

I added Home (0x4700) for always starting at the beginning of the command-line. I am not so fond of the Grub4Dos way to set the cursor always at the end of a line after 'calling' an entry from the History Buffer. But that's personal preference of course.

(......)
bios int=0x16 eax=0x0500 ecx=0x4800 > nul && if not %length%<=512 &; bios int=0x16 eax=0x0500 ecx=0x4800 > nul && if not %length%<=1022 &; bios int=0x16 eax=0x0500 ecx=0x4800 > nul
bios int=0x16 eax=0x0500 ecx=0x4700 > nul
call Fn.5 0 %cursor% ;; set /p "line1=%echonum%>"
(......)

Extra ArrowUp's because of 510 chars limitation of the set /p command-line. During editing a line longer lines are copied to the History Buffers in max three parts 510 chars (two extra bytes are 0D0A for Carriage Return + Line Feed).

 

BTW 'bios' is already loaded with insmod, no '/' needed.
 



#50 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15873 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2021 - 08:54 AM

 

I added Home (0x4700) for always starting at the beginning of the command-line. I am not so fond of the Grub4Dos way to set the cursor always at the end of a line after 'calling' an entry from the History Buffer. But that's personal preference of course.

 

Maybe, just maybe in the (more complex) text editor you could try to use (and peruse) the grub4dos Fn. 5 function to be able (via some hotkey, the usual is Ctrl+Right Arrow) to jump at the beginning of each word:

 

5 gotoxy – e.g. call Fn.5 0 11 set cursor pos to beginning of line 11

 

( it is one of the features I personally use a lot when editing/correcting texts).

 

:duff:

Wonko







Also tagged with one or more of these keywords: grub4dos

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users