maemo.org - Talk - DOSBox 0.65 ... ftw

maemo.org - Talk (https://talk.maemo.org/index.php)

- Games (https://talk.maemo.org/forumdisplay.php?f=12)

- - DOSBox 0.65 ... ftw (https://talk.maemo.org/showthread.php?t=5686)

Re: DOSBox 0.65 ... ftw

Quote:

Originally Posted by Estel (Post 1412229)

Now I only need to find how the hell one creates DOS's keyb (duckduckgo/google time)

Apart from Google (try to find FreeDOS documentation, I remember it was somewhat better), there is also the following:

http://depot.javispedro.com/nit/dosbox/kc.tar.gz -- I ported FreeDOS's "key compiler" to ANSI C, so that you can build it on your N900 or a desktop. Includes Makefile. Also includes the original documentation which describes the key file syntax.

http://depot.javispedro.com/nit/dosbox/rover/ -- Source files for the rover.sys I created. They are not in UTF-8 but rather in DOS codepage 850, so they are hard to edit unless your editor supports that. An example of a somewhat good editor supporting such code page is DosBox's edit.com :)

You might want to use
http://depot.javispedro.com/nit/dosbox/rover/us.key
as a starting point for key file, but I don't really remember the syntax.... I however remember that every entry in [keys] should be like this:

Code:

scancode command_for_plane1 command_for_plane2 ....

where scancode is the "real" keyboard scancode (suffixed with C if it's a key that can be influenced by "caps lock"). For every plane, you can set either a command or a character. Commands are prefixed with ! (e.g. !0 is "command 0" which means 'use defaults').

Planes in the us.key file are:
1. Normal
2. Caps lock
3. Shift + N900's FN
4. FN

They are defined in the [planes] section (first two planes are implicit).

Re: DOSBox 0.65 ... ftw

Slightly off topic but are you guys aware of the FastDOSBox fork optimised for ARMv7?

Re: DOSBox 0.65 ... ftw

Quote:

Originally Posted by Estel (Post 1412229)

Thanks a lot for your detailed answer. Yea, while searching, I've run into informations about <> keys working on different level, but it was very vague and I hadn't idea what do make out of it.

The game I'm interested in definitely works with DOS's keyb - numbers are working flawlessly (and stop doing so, if I skip keyb rover.sys us line). So, I understand that creating "custom" keyb.sys with those keys mapped would work? That's great to hear! Now I only need to find how the hell one creates DOS's keyb (duckduckgo/google time)

/Estel

Did you manage to get this working?

I am more or less usings vi_'s keymap, based my design on his... So I have F1-F12 mapped fn + shift but these don't work very well in dosbox with rover.sys loaded but also not with the default keyboard loaded :(

Re: DOSBox 0.65 ... ftw

Having just returned to using dosbox, I am pleased to see some great improvements with regard to the mouse:

1. there is no more offset between a stylus tap and a mouse click. Reading through the thread, I can't find how/when this happened. Either way, thanks much.

2. it is possible to right click by pressing a configurable key (e.g. shift)

However, this is not well documented (there is also the SDL_Mouse_Relative entry in the .conf file - what does it do?), so the average user will have to plow through the thread (assuming he even knows of the new features). Should the wiki page be updated?

Re: DOSBox 0.65 ... ftw

Quote:

Originally Posted by mr_pingu (Post 1421680)

Not yet, sorry. Too much ~~women and booze~~ projects, not so much time, so while I saved javispedro's nice instructions on personal notes in case TMO gets blown, I haven't had a chance to test it yet in practice.

If you want to try it, take your time - I'll gladly drink a vine of your efforts :D

/Estel

Re: DOSBox 0.65 ... ftw

er... How does one obtain keycodes?

Re: DOSBox 0.65 ... ftw

Hmm... No traffic here for nearly four years... I wonder if anyone is still using DOSBox on their N900s...

Never mind, it might be worth a shot. Posting costs nothing (yet ;)).

As mentioned in another thread, I have recently rediscovered some old PC games. After playing for a while I noticed some... let's say interesting effects. The list is short but the blurb is rather long-winded. Sorry about that:

Running DOSBox sucks the battery dry in no time. 30 minutes of DOSBox is like 8 hours on standby. 2 hours and the phone is dead. But that is hardly surprising, DOS is not really optimized for idling.
When the screen timeout kicks in, DOSBox loses the mouse. Tapping on the screen is no longer registered. The screen does not need to blank out completely: it dims first for a few seconds before switching off, but the mouse is lost the moment is starts dimming. It had bugged me for a while - I went through hoops to kill and restart the application to get the mouse back - until I found that simply turning the screen on again by the slider on the side solves the problem.
This effect can be observed immediately. Start DOSBox and wait for 30 seconds for the screen to time out.
After a few hours of play and then leaving the game and exiting DOSBox (legally, through menu options and the "exit" command), I get back to the Maemo desktop, but the screen is all wrong: the wallpaper is gone, the icons descriptions are gone, the rotation lock setting is gone... I have to reboot the phone to get back to normal.
This is accumulative. It does not need to be a single, several hours long session. I can play for two hours, exit, start again, play for 30 minutes, exit... After a few cycles like that, usually taking 2-3 days, I am guaranteed to get into the described situation. The best way to avoid it is a prophylactic reboot after every day of play, then the leak or whatever there is never has a chance to accumulate enough to trigger the effect.
The fact that it accumulates over multiple instances of running and exiting DOSBox and the game makes me believe that it is not a leak in the game itself, but in something that keeps running after the game and DOSBox is terminated. Hildon desktop? The kernel?
Sometimes,if ignored for long enough, the above effect can accumulate enough to corrupt the graphics inside DOSBox itself. Once that happens, it may no longer be possible to exit the game normally, it may need to be killed by brute force.
A more lasting effect: the browser history is corrupted, although I have observed that in the past in unrelated circumstances. Any unexpected reboot can corrupt the browser history. You need to clear it.
By far the most serious: I lost the receiver speaker. The phone rings, I answer - silence. Switch to a loudspeaker, OK. Switch to Bluetooth, OK. Switch back to the receiver, silence.
I suspect a corrupt file in some package, but which one? How do I find out?

Re: DOSBox 0.65 ... ftw

For the dimmer/mouse/lock switch problem I would look at the Maemo patches. Might be it's only checking for the lock switch. Haven't looked at it since I built the update for the ARM optimizations.

Not sure where to start on other issues. Could it be partly related to OOM?

Re: DOSBox 0.65 ... ftw

Quote:

Originally Posted by pichlo (Post 1539967)

By far the most serious: I lost the receiver speaker. The phone rings, I answer - silence. Switch to a loudspeaker, OK. Switch to Bluetooth, OK. Switch back to the receiver, silence.
I suspect a corrupt file in some package, but which one? How do I find out?

That one happened to me a few times over the years with N900 without using DOSBox too - in fact when using only phone/messaging/microb since previous restart, so it might be something more generic (Nokia's alsa patches?).

Re: DOSBox 0.65 ... ftw

Quote:

Originally Posted by misiak (Post 1540060)

Yeah, I am suspecting a corruption due to an unexpected reboot, which was only indirectly related to DOSBox (when I had to reboot due to unresponsiveness).

How did you fix it? I would rather not reflash if I can avoid it.