Controlling LHES with a joystick

[eidis]

Hi Guys !

There is a thing which I wanted to add to the HDD images for a long time but knowledge prevents from doing so. It would be very beneficial for all keyboard-less users if file commander LHES could be controlled with the joystick. It can be done, however it involves some coding. There is a program called keywitch which remaps key presses to joystick port so programs which require joystick can be used with the keyboard. The source code is available and well commented...... cough, in Japanese. Could anyone please, if you have the time, look at the source code and try to modify the joystick routine ?

The program can be downloaded from here:
http://www.retropc.net/x68000/software/system/key/keywitch/index.htm

It must be started by typing keywitch.x -j in order to make the joystick routine work. Numeric arrow keys, Z and X are mapped to Joystick port 1. They can be redefined in keywitch.env file. The easiest way to test this program is by using Sorcerian which is in Mini HDD image Games2 directory.

Mini image can be downloaded here:
http://nfggames.com/X68000/Games/Mini.zip

Any expertise will be highly welcome.

Keep the scene alive !
Eidis

[RetroRepair]

I was thinking about this the other day, even if you have a keyboard, if you run your machine on a TV with a scaler like I do then it'd be great to put the keyboard away.

I was kinda hoping to find some dev tools so I could look into building a nice GUI, though of course it'd put a strain on the already limited memory these images require.

[neko68k]

What needs to be changed?

[eidis]

 Hi Neko68k !

The joystick routine needs to be changed so that it translates joystick input to keyboard key presses. IMHO it would be best if joystick directions would be mapped to arrow keys, joystick button 1 to ENTER and joystick button 2 to Q.

Keep the scene alive !
Eidis

[neko68k]

Oh I get it. I read that wrong. If I have time I'll look at it this weekend.

[lydux]

I don't have time to build this, but to me, it would be easier to start with a newer program.
The idea is simple : creating newer dos syscalls for _INKEY or _KEYSNS (or other related to keyboard input). Substitute the originals ones with _INTVCS and save the address of the original routine.
These syscalls would execute iocscall _JOYGET and depending on the result will return a corresponding keystroke, or continue with original syscall execution.

Here is the basic idea for developpers. This hasn't been tested at all and is wrong anyway ! You need a similar code in a driver instead of a standalone program (no main). That's because the newer handler will
be lost after the program execution. It has to be memory resident...

Code Select Expand


#include <dos.h>
#include <iocs.h>

#define JOY0 0
#define JOY1 1

/* JOYGET bits */
#define JOY_BUTTON1 (1 << 6)
#define JOY_BUTTON2 (1 << 5)
#define JOY_RIGHT (1 << 3)
#define JOY_LEFT (1 << 2)
#define JOY_DOWN (1 << 1)
#define JOY_UP (1 << 0)

/* X68K Keystroke */
#define KEY_LEFT 0x3b
#define KEY_UP 0x3c
#define KEY_RIGHT 0x3d
#define KEY_DOWN 0x3e
#define KEY_ENTER 0x4e
#define KEY_Q 0x11

typedef int (*__key_fn_t) (void);

/* Saved original _INKEY handler */
static __key_fn_t org_inkey;

/* Our newer _INKEY handler */
int __attribute__((__interrupt_handler__)) my_inkey (void)
{
  int joy_st;

  joy_st = _iocs_joyget (JOY0);

  if (joy_st & JOY_UP)
    return KEY_UP;
  else if (joy_st & JOY_DOWN)
    return KEY_DOWN;
  else if (joy_st & JOY_LEFT)
    return KEY_LEFT;
  else if (joy_st & JOY_RIGHT)
    return KEY_RIGHT;
  else if (joy_st & JOY_BUTTON1)
    return KEY_ENTER;
  else if (joy_st & JOY_BUTTON2)
    return KEY_Q;

  /* No joystick action. Execute default syscall */
  return org_inkey ();
}

/* /!\ This normally should be a character driver ! */
int main (int argc, char **argv)
{
  /* Change _INKEY syscall handler */
  org_inkey = _dos_intvcs (0xff07, my_inkey);

  return 0;
}


Good luck guys !

[eidis]

 Hi Lydux !

Thank you very much for your expertise and being a true inspiration.

Keep the scene alive !
Eidis

[kamiboy]

At the request of our most esteemed eidis I, the clueless fool that I am, decided to look into this subject. At first glance all seemed simple enough, as it seemed that our resident wizard class coder Lydux had seemingly already done all the heavy lifting.

Alas, alas I say. It was not long before I hit an insurmountable wall. The wall that revealed my total ineptitude in the subject of driver writing. I did a brief search on the net on the subject of howtos on writing drivers for DOS, only to soon realize that it is prolly completely different for Hu68k since it is just rigged to resemble DOS, not be a clone.

Lacking any documentation I gave up on that route and ventured upon the simpler alternative. To just have the program terminate and stay resident, which should work.

In theory all I needed to add to Lydux's sample code was to dump a _dos_keeppr(..) call at the end of main(). Alas, once again. That function required me to know how much space the program takes in memory as I need to tell it how much memory it is to keep resident upon exit.

That was but a simple hurdle, I thought, why not just feed it an arbitrary value, like, say, 20k and see if that would do the trick. No dice tough. The program seems to remain resident with 20k as a command call of process.x reveals. But when I write a simple test program that then tries to call the replaced 0xFF07 iterrupt call I get a bus error.

Well, not knowing what the deuce I am doing in the first place means that I am now dead in the water.

Sorry, lad, I tried.

[eidis]

 Hi Kamiboy !

Thank you for your generous efforts. It is the thought that counts. Sooner or later this project will become a reality. Keep up the good work ! Believe in X68000 you must.

Keep the scene alive !
Eidis

[kamiboy]

Fret not, Lydux may yet throw some light on the subject.

The best solution would still be to write a tiny game folder browser that is written to work with joystick commands and does nothing but provide a populated list of launchable games and launches the one the user chooses from the list. If written well it should have a smaller memory footprint than any of the file browsers that we are used to.

I tried to write one, but I think some of the dos calls that I need to search for files and folders from a C program are not part of Lydux's X68K C build enviroment.

Though, even if they were Lydux's build env tends to produce rather large executables which would no doubt have a large footprint.

Perhaps I should start looking into ways of using the native 68k C compiler.

[eidis]

 Hi Kamiboy !

It all comes down to Inside X68000. Is there anyone who could join the translator team ? Translate the book we must.

Keep the scene alive !
Eidis

[kamiboy]

How many pages are those arcane tomes? Could we not start a collection to hire a professional translator to do the job? Only guaranteed way to get anything done, and fast, is to throw money after it I fear.

[eidis]

 Hi Kamiboy !

Only 528 pages. The idea of hiring a professional translator is tempting, however, who will finance it ?

Keep the scene alive !
Eidis

[kamiboy]

528 pages of highly technical details regarding obsolete 80's hardware and software architecture. Not exactly a job for any old translator.

As for the funds, why we will pay for it of course. Us, the flourishing english speaking X68000 community, for we are legion. Jesting aside, though we are but a handful we are at least people of great means, do not deny it! No poor person can afford to own the Rolls Royce of gaming hardware.

Surely we can all dig deep into those bottomless pockets of ours for a worthy cause.

[lydux]

You'll not find anything about drivers in Inside X68000 as it talk about X68000. Drivers are Human68K specific is I guess is covered by an another book.

Fret not, Lydux may yet throw some light on the subject.

Hum well... Yes, I do have what you are looking for ! Since the creation of my ERSA board, I write a little DDK for Human68k. Actually, it's far from complete and requires some knowledges about OS and hardware development. I didn't really know where to start explaining you how to write drivers, but I now think this one might be a very good approach.

Please stay tuned. I'm going to open a new thread.