Release Qemu for Pandora (for rebirth competition)

[hmc]

Dont forget that you should never execute Files in shared Folder.

Copy the The Files into the Image and please run from there then should it work.

Qemu cannot write into the shared Folder and quit everytime.

Second is that Qemu on Pandora cannot handle 800x600 Resolutions.

640x480 work fine and 320x240 work but its then stretched ^_^

Thanks!

Sometimes it's good to read the ENTIRE Wiki page, and not just the instructions for setting up something. ;-) I didn't know that I must not execute something from a shared folder.

After copying the program folder to the HDD image, I can now execute the program.

However, there are still some issues I am faced. Will try to circumvent of solve them one by one.

1. Worst thing is the keyboard layout. In DOS, ":" and "\" are often needed, and I even read your instructions on the Wiki page how to enter them ;-) But for efficient working with DOS, this is a no-go. Approximately the same problems also exist in DOSBox, where there is a theoretical solution using a customized keyboard layout:


best mapper file so far (2012-10-24) (spoiled in message):

http://boards.openpandora.org/index.php?/topic/5290-dosbox-conf/#entry178850


bukkit's explanation of "the perfect way of mapping" (involving xkeyb driver)

http://boards.openpandora.org/index.php?/topic/10473-dosbox-decent-keyboard-mapper-file/#entry196296

Are there any solutions already to the keyboard layout problem in QEmu?

2. keypresses are executed twice:

After starting the HP200LX connectivity pack, it is necessary to use the cursor keys to navigat through the menu of applications and also for several other things. However, arrow key presses are always executed twice, which makes navigation quite tricky. ;-) Do you have an idea what the reason can be?

3. Mouse support is totally messed up, which is not such a problem, because CPack doesn't use the mouse at all. But e.g. the editor "EDIT" in freedos is theoretically usable with the mouse, and I have big problems using that editor. However, not much experimenting done yet. I guess I'll find a solution here.

Seen using the Freedos premade image with UniVBE support. 

I may also test other images to see if they work better.

Thanks so far!

 

[ingoreis]

Ah i see what for Problems you have.

For the double Arrow using is the Solution simple

Just underclock your Pandora and it should work better.

When you activate Adlib is the entire Qemu Emulation bit slower too.

The second Problem with the Keyboard Layout have i not because i make all my Images ready on PC,test and run them on Pandora.

For Doublepoint its a simple Solution that i use on Pandora.

Just type in Freedos Keyb gr And you have the Doublepoint with pressing Shift and Doublepoint on Pandora.

The Backslash use i nearly never.

When i want to go in directory C:\windows\command Type i cd simply 2 Times.

Cd windows

Cd command

And under Dos can you use only the Nubs as Mouse,dont use the Touchscreen,touchscreen work only under win98 Emulation with tricks.

Hope it helped a bit

 

[hmc]

May I suggest some improvements for the qemu PND:

1. Combine selection of a qemu HDD image and launching qemu on one page of the GUI and make selection of an image easier, maybe using a dropdown field, that already lists all images found in the images folder. That drastically reduces the number of necessary GUI interactions when quitting qemu with one image and re-starting qemu with another image.

2. Define keyboard shortcuts for those GUI actions mentioned in (1), so that selection of a HDD image and launching qemu with the selected image can be done with the keyboard only

3. Fix that double-awrrow problem in a general way. Making the Pandora or qemu slower manually is - sorry - a quite dirty workaround ;-)

4. For the image file "file open" dialogs, save the last used path, so that when the dialog is summoned again, the last used path is restored. 

5. If there is a reason for qemu not to start, when the user clicks "Launch!", inform the user about the reason for failing (certainly qemu produces some output - would be nice to see that in a message box of the GUI then)

(just had that case, when the "Shared Folder" path pointed to a non-existent directory, because the SD card the path ponited to was removed)

6. When qemu is launched, the mouse / touchscreen doesn't seem to work outside of qemu in the XFCE desktop anymore. Is this a known issue? (More precisely: Mouse movement is registered, as buttons change their color when mousing over them, but a mouse click isn't registered anymore, or maybe with a huge delay - many seconds or several minutes. When quitting qemu, this gets restored to normal slowly, only after some time after quitting qemu).

7. Put all the tipps and tricks and info about known issues from the Wiki page into the Readme that's shown under "Documentation" in the Pandora menu, so it is always at hand even without an online connection.

By the way: Is there any way to quit qemu from within qemu (by entering a specific command maybe)?

The "mouse click has no reaction" issue often prevents me from quitting qemu gracefully using a mouseclick on the cross in the upper right corner or onto the "Cancel" button of the GUI.

Not always, only often. Don't know what this is dependent on.

 

[hmc]

Oh an Ingo, I just tried your workarounds for the double-arrow problem, but they doesn't help, evenif I combine Adlib enabling with underclocking to 600MHz (1GHz Pandora) and switching to 486 emulation instead of Pentium.

I assume those workarounds work for the issue, that sometimes a key press is executed several tiiiiimes ;-) (but this can be from 1 to X times, not only exactly 2 times). 

What I experience is, that only the arrow keys are executed always exactly twice, so this is probably another problem.

 

[ingoreis]

Maybe it help when we recompile Qemu with all the newer Libs.
Then are maybe some Errors gone and we can add ac97 support,maybe Notaz newest SDL and when it be compiled under newest GCC,have we maybe little speedups too
With Notaz SDL can we maybe solve that:Qemu cannot Resolutions over 640x480 on Pandora,because in Betatesting Times worked that on some Versions from Mcobit.

And when the configure is made with linuxbochs installed LIBGL can we experiment in this too

For the Problem with exit have i a simple Solution.

Ctrl+alt+f exit fullscreen and
Ctrl+alt let the grabbed mouse free.


This Evening try i to install Codeblocks,install LBs GL Files in Codeblocks and try to recompile the 0.15.1 Qemu Version.

 

[hmc]

Ingo, it would be great, if this would help. However (see below) the problem is also visible in QEmu on my Mac ("Q" based on QEmu 0.9.1). 

Just in case it's any good for debugging / optimizing / helping me ;-)... here is an email I just wrote to the HP 200LX community about this problem as a reply to a fellow's support attempt:

> Does the arrow key duplication happen in other applications in qemu?
 

I didn't try many applications so far:
- CPack: yes
- Pure DOS (command line): no
- "Edit" editor of FreeDos: no.
- Apperently it also does never happen in any game they use in qemu.

I replaced "cg.com" by palrun in app200.bat, and still the same
problem, so it's also not a cg.com problem.


> Have you tried any other DOSes?
 

I have tried FreeDos and DRDos (see the image links below). Same
problem in both.



> Does the arrow key duplication happen under freeDOS on QEMU on another
> system?
 

Yes, just tried on Mac. The same problem.


> When I get home from the office today, I can try and load up a desktop
> installation of QEMU and give it a shot, if you'd like.
 

If you don't mind that it's the German version, you may test using one
of my HDD images:
http://www.hermocom.com/temp/DRDOSLeer.qcow2.zip (2.2MB) or
http://www.hermocom.com/temp/FreedosWithUniVBE.qcow2.zip (34MB)
(should one of the links not work, go to browsable directory
http://www.hermocom.com/temp/ and look for the file)

Usage:
- Boot image
- Press Enter once (Freedos driver menu; only for FreeDOS image)
- cd cpack
- app200.bat (uses Palrun) or app200cg.bat (uses CG.COM)
- then move the highlighting around in AppMgr with the cursor keys and
experience the problem

 

[hmc]

Ingo, forgot to tell you this:

Thanks for Ctrl-Alt hint to release mouse cursor. I forgot about the emulation capturing the mouse and the need to release it manually (too much used to seamless integration of VMWare / VirtualBox ;-).

 

[hmc]

I've got feedback from Francois of the HP 200LX community. He could replicate my problem and found a solution - for an Android version of qemu.

Now I tried to use the same solution for the Pandora port, but to no avail.

He wrote:

> I just tried your freedos image on an android version of qemu (limbo, free

> keyboards as well as the on-screen keyboard.  One of the options presented

> is "user interface" with the options of SDL and VNC.   In VNC mode the arrow

> keys double in cpack.  In SDL mode the arrow keys work normally with both cg

> and palrun.    Try changing the setting if you have one on your qemu

> launcher, or remove -vnc and options, adding a -sdl to your launch command. 

However, the GUI launcher of our qemu does not offer such options.

So I wrote "-sdl" into the otherwise empty "Other Options" field, but this doesn't change anything.

How is qemu for Pandora compiled? Does it use VNC mode in a hardcoded way? Does it use a different command line option to switch to SDL mode? Or does it always use SDL mode and have this problem anyway?....

I guess I need your advice here.

By the way: From what I know so far about VNC and SDL, I'd guess SDL is faster on the Pandora and if we currently use VNC mode, it may speed things up if we permanently switch to SDL mode...?

Thanks!

 

[ingoreis]

Yesterday i tried to recompile with newer Libs but failed with Codeblocks.

Wow great and many News from you

I have a Idea for you what i maked sometimtes in the past for Testing.

Start the Qemu for Pandora and open then a Terminal

The executable Qemu Binary is now on


/mnt/utmp/qemu/bin/qemu
Now go to your SD Card or where your Image is and type


/mnt/utmp/qemu/bin/qemu -hda freedos.qcow2 -soundhw sb16,adlib -m 128 -cpu pentium -net none
You can Add -sdl when you want for testing

Normaly Qemu uses SDL but i think we builded a old Version in.

Mcobit can say that better,he maked the PND and build all fresh.

I can only dirty Things :rolleyes:

Solving that Bug would be nice because in some Games like Terminal Velocity and Starfighter3000 can i dont good fly because this.

 

[hmc]

oh, so this problem of doubled arrow keys is also present in other applications / games? So far I thought it would only be present in my cpack application! 

Thanks for your hint, tried to execute qemu manually from the terminal adding -sdl.

How the problem is not gone, but in about 10% of the arrow key presses cpack only reacts once now (but in 90% of the cases it still reacts twice). So it seems that using -sdl makes things a slight bit better.

Does this mean something to you, Ingo or mcobit?

 

[hmc]

ingo, mcobit,

when scanning the command line options for qemu (qemu --help), I stumbled upon this one:


-k language     use keyboard layout (for example 'fr' for French)
 
So this probably means, that qemu has some key mapping code built-in.

If so, it should be possible to creeate a mapping that's directly tailored for the Pandora keyboard. Would make sense for the Pandora port, IMO. On that low programming level it could be possible to even circumvent the problems that we have in DOSBox with the key mapper, that unshifted and shifted key values cannot be mapped correctly at the same time.

Then, for example, there could be an option "-k pandora" (which should be the default), so that qemu is flawlessly usable with the Pandora keyboard. If the user wants to use another layout, e.g. with an externally connected standard keyboard, he can use -k fr etc.

Maybe it makes sense to make that option also available in the GUI then (with a dropdown for the most often used layout settings and a text entry field for cases, where the user wants to use a different layout).

Hmm, when looking into the source code, keymap.c loads keymap files, and those keymap files are in qemu-1.5.1\pc-bios\keymaps.

Their content looks like this (beginning of the "de" keymap file):


# generated from XKB map de
include common
map 0x407
exclam 0x02 shift
onesuperior 0x02 altgr
exclamdown 0x02 shift altgr
 Do you think that it's possile to completely map the Pandora keyboard correctly using that mapping scheme?

How do I know the hex key codes of the Pandora keyboard, that are used as the second value in each line? I'd like to try to create a map that fits the Pandora keyboard.

 

[ingoreis]

Maybe we can steal this keymap.c from another Projects and simply renaming it on the right Place?

Here ist a interesting Project with that:

http://boards.openpandora.org/index.php/topic/2428-keyboard-layout-changer/page-2

Maybe setting the Pandora Keyboard Ramping up help?

(Just a Idea) ^_^

 

[hmc]

Those XModmap files have a completely different format.

The first line of qemu's keymap files, "# generated from XKB map de", suggests that there is a converter from XKB (=xmodmap) files to qemu keymap files. However, in the source tree of qemu 1.5.1 I could nto find such a converter. But maybe I haven't looked well enough.

If we find that converter, then it should indeed be possible to convert the default .pndXmodmap file, that's in the home directories of every Pandora OS installation, into one that could work well with qemu.

But maybe it's not so hard to manually "convert" that .pndXmodmap file. When I have some time I'll look into it, if we don't find the converter.

Any idea where to find that converter?

 

[ingoreis]

That sounds complicated.
Another maybe much more simple Solution:
Is there no simple tool for Dos that can we make our own Keyboard Layout for Dos?
That can i implementiert then in the Freedos/Drdos Images but that solve unfortunaly not that doubling Problem.
However then have we a Dos with Pandora Keyboard Layout and that helps too.

Sorry when the Text is in one Block,Tapatalk make that often.

 

[hmc]

looking more deeply into the files and comparing them (~/.pndXmodmap from my Pandora and the "en-us" keymap file of qemu), I fear it's easier to generate a new qemu pandora keymap from scratch. The qemu keymap file only has a few entries for special characters, the remaining stuff seems to be standard; so the file seems to contain only differences to the standard.

But I assume that in the qemu keymap file we need to add each key and modified key explicitly.

I vaguely remember there was some command line tool to get key codes from every key pressed. Such a tool would be needed now. Its name had something to do with "X events" or so...

Any idea?

 

[ingoreis]

In the Moment have i no idea,but sorry.
Must go work.
I am curous what you found out and what i can all learn from you

 

[hmc]

A key mapping driver <i>inside</i> qemu (i.e. installed in DOS) wouldn't work. Same problem as doe DOSBox. It has to do with the problem that unmodified and modified key values cannot be mapped correctly at the same time.

I think a more detailed explanation of the problem can be found in the links I gave in a proir posting of this thread:

best mapper file so far (2012-10-24) (spoiled in message):

http://boards.openpandora.org/index.php?/topic/5290-dosbox-conf/#entry178850

bukkit's explanation of "the perfect way of mapping" (involving xkeyb driver)

http://boards.openpandora.org/index.php?/topic/10473-dosbox-decent-keyboard-mapper-file/#entry196296

But if we can solve the key mapping issues on a lower level, i.e. directly in qemu, this should actually work somehow.

I will see, if I find a way.

 

[ingoreis]

In my Images can i change under dos the Keyboard Languages with keyb gr to German(as example)

When i renember right saw i a Dos Tool to make own Dos Keyboard Layouts,that should work then under Windows too in Qemu.

But the old Problem with twice pressed when on Time is pressed,is not solved with that.

I recognized that is a speeding Problem in Qemu.
When i test 286 Dosgames happen that often.
When i Test Pentium Games have i that error nearly never.

Another Idea for this is a Pandora Software Slowering Tool.
I think there are Dos Software slowering Tools out to Solve that Timing Errors.
Software Breaking to Build in Qemu Images should be a funny Idea.

 

[hmc]

Okay guys, I did the following. But apperently I'm doing something wrong:

I compiled the xev tool and executed it. It shows the key code for each pressed key.

I decidede to use the "V" key for my testing.

For the "V" key, xev displays the following.

KeyPress event, serial 38, synthetic NO, window 0x4200001,
root 0x44, subw 0x0, time 3156882925, (168,-7), root479,132),
state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (76) "v"
XmbLookupString gives 1 bytes: (76) "v"
XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x4200001,
root 0x44, subw 0x0, time 3156883014, (168,-7), root479,132),
state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (76) "v"
XFilterEvent returns: False
So the V key has the keycode 55.
I tried the same for Fn-V (for testing of remapping the "#"), and that resulted in keycode value 194.

Then I converted both values to hex, resulting in

0x37 (55, V) and

0xC2 (194, Fn-V)

Now I created a qemu keymap file for testing, named "newtest" with the following contents:

bracketright 0x37
percent 0x37 shift
asterisk 0xC2
dollar 0xC2 shift
My assumtion was, that when this keymap is loaded, inside qemu I would get:- the bracketright character, if I press V

- the percent character, if I press Shift-V

- the asterisk, if I press Fn-V

- the dollar sign, if I press Shift-Fn-V

I copied the file to appdata/qemu/share/qemu/keymaps/newtest

Then I started qemu, opened a terminal and did the following:

$ cd /mnt/utmp/qemu/bin
$ ./qemu -hda ../images/DRDOSLeer.qcow2 -soundhw sb16,adlib -m 128 -cpu pentium -net none -k newtest
After DOS has finished booting, I pressed first V, then Shift-V, then Fn-V, then Shift-Fn-V.In DOS I did not get any reaction.

In the linux terminal, where I started qemu, I got:

panXsd1:/mnt/utmp/qemu/bin$ ./qemu -hda ../images/DRDOSLeer.qcow2 -soundhw sb16,adlib -m 128 -cpu pentium -net none -k newtest
Warning: no scancode found for keysym 58
Warning: no scancode found for keysym 58
Warning: no scancode found for keysym 58
Warning: no scancode found for keysym 118
Warning: no scancode found for keysym 118
Warning: no scancode found for keysym 304
Warning: no scancode found for keysym 118
Warning: no scancode found for keysym 118
Warning: no scancode found for keysym 304
Warning: no scancode found for keysym 35
Warning: no scancode found for keysym 35
Warning: no scancode found for keysym 304
Warning: no scancode found for keysym 35
Warning: no scancode found for keysym 35
Warning: no scancode found for keysym 304
So apperently my testing keymap file does not have any effect on the V / Fn-V key.Which makes sense: qemu seems to expect keysym values in the keymapping file, not keycode values (which is sad; it may mean that the same problems will exist for qemu that we have for DOSBox, since the keysym value is the same for a key and the same key "shift"ed. Let's see.)

Back to the drawing board.

I'll test a new keymap file with keysym values instead of keycodes.

Okay, let qemu open and pressed the keys again, to see what keySYMs are reported by qemu or xev:

- V: 118 (= 0x76)

- Shift-V: 304 (Shift) and 118

- Fn-V: 35 (= 0x23)

- Shift-Fn-V: 304 (Shift) and 35

(Left shoulder button: 303, real Shift key: 304)

So I created a new "newtest" keymap file:

bracketright 0x76
percent 0x76 shift
asterisk 0x23
dollar 0x23 shift
When testing this file with qemu, unfortunately I ge tthe same output (no scancode found for keysym ....) when pressing the V key in those various combinations.

Need to stop for now, maybe until I can continue someone has an idea what I am doing wrong...?

Thanks!

 

[ingoreis]

Are you interested on just newer compiled files for Qemu?
In the Wine Qemu Thread have i actual Qemu1.5 uploaded.
But i have it only shortly tested.
Maybe when you steal the Keyboard Files from this, maybe replacing the old Keyboard Files with the newer ones help.

Dont forget that in actual Qemu Versions the Binary now call qemu-system-i386,not more simple Qemu.