uEmacs and pcJr (anyone? Is this Mic on? tap tap)

[toddvernon]

Ok, sorry for the very specific post.

I have been using MicroEmacs (uEmacs) for three decades and continue to use it on macOS and Linux today. I have built it, scavenged it, ported it, everything.

But, I got several versions today and thanks to my new PalmZip drivers, I moved several versions to my PCjr. In each case, it was not the best.

Always, it starts and draws the screen correctly. Usually, no keyboard is recognized and at the bottom flashes "keybindings not found" or something like that.
uEmacs has the option of an emacs.rc file that overrides some keybindings. But this is different, it's like it doesn't understand "anything keyboard".

It a long shot but, if any programmers from the '80s are out there and know what's up let me know.

Everything works great on Dosbox. Arrrgggg!

[Brutman]

I'm a vi user ...

Where is the source code and what compiler are you using to port it to DOS? What version of DOS are you using?

If the program is doing DOS or BIOS level calls to read the keyboard it should work fine. The PCjr keyboard BIOS does a good job of mapping the layout to a more sensible layout, but you have to go through DOS or the BIOS for that.


Mike

[DoctorOctal]

Have you installed an INT 9 patch? There’s a bug in the PCjr’s BIOS compatibility that trips up some software and prevents the keyboard from working. Several people produced little TSRs to patch the BIOS.

Here’s PC Enterprises’ version:

• COM file
• documentation file

[toddvernon]

Mike, im using precompiled binaries for DOS from around the web. Its still a very popular editor (for me included). I have compiled it many time on unix, linux, mac, etc. DoctorOctal thanks for the INT9 patch, unfortunately it didn't seem to help. It really weird all the different version have about the same problem. Just acts like no keys are ever seen by the program. Works on Dosbox no problem. I'll keep investigating.

[Brutman]

If you can point at a specific version that you want to use, then recompiling from source is possible. Assuming it uses a reasonable toolchain (Turbo C++ or Open Watcom) it would be possible to debug it properly.

Sometimes the problems are specific to DOS versions. What version of DOS have you tried on the Jr?

[toddvernon]

Im running Dos 3.3. Heading for 5 but just got 3.3 running. I do have Turbo C on dosbox so maybe I'll head there once I run out of other options.

[Trixter]

Sounds like the original programmer got "smart" and wrote his own keyboard handler. Problem is, the PCjr keyboard ports aren't the same, so anything expecting IBM PC keyboard hardware isn't going to work.

To fix this, you must edit the code you find to use BIOS routines only for the keyboard.

[toddvernon]

So digging into the source. I'm not an accomplished bios programmer but I do think I have it down to the last layer before the bios here. The symptom is much like the intXfix program as it appears the editor as continuos keys being pressed (followed by) "no-key-bound", hilarity ensues... This is where the "key" is retrieved. My two thoughts are that the code (in other places) looks at INT 99 for a mouse (if compiled that way) and might think there is a mouse (creating a stream of jibberish, or its just wrong as all the #if's seem to be looking for int86 as the bios vector?

int doschar() /* call the dos to get a char */

{
#if ATKBD /* AT-style extended keyboard with grey keys */

rg.h.ah = 0x10; /* Get Keyboard Input call */
int86(0x16, &rg, &rg);

/* function key!! */
if (rg.h.al == 0 || rg.h.al == 0xE0) {

rg.h.cl = rg.h.ah; /* swap scan code and value */
rg.h.ch = rg.h.al;
rg.x.cx = extcode(rg.x.cx);
in_put(rg.h.ch & 255); /* prefix byte */
in_put(rg.h.cl & 255); /* event code byte */
return(0); /* extended escape sequence */
}
return(rg.h.al & 255);
#else

#if (TURBO | IC) && HP150 == 0
/* Added 8/13/89 by DRK to get Turbo C version to use BIOS for
keyboard input. Low byte of k has first byte of extended scan
(ASCII value for reg. char, 0 for extended char), high byte has
extended key scan code.
*/

unsigned k = (unsigned)bioskey(0);
unsigned c; /* Extended character to return. */

if ((k & 0xFF) == 0) { /* Check for extended key. */
/* Convert extended key scan code to a
uEMACS internal form. */
c = extcode(k >> 8);
in_put(c >> 8); /* Report prefix and event code bytes. */
in_put(c & 0xFF);
return(0); /* Return extended escape sequence. */
}
return (k & 0xFF); /* Return regular ASCII value. */

#else
register unsigned int c; /* extended character to return */

rg.h.ah = 7; /* dos Direct Console Input call */
intdos(&rg, &rg);
#if HP150 == 0 /* this translation level is deeper on the HP150 */
if (rg.h.al == 0) { /* function key!! */
rg.h.ah = 7; /* get the next character */
intdos(&rg, &rg);
c = extcode(rg.h.al);
in_put(c >> 8); /* prefix byte */
in_put(c & 255); /* event code byte */
return(0); /* extended escape sequence */
}
#endif
return(rg.h.al & 255);
#endif
#endif
}

[Brutman]

If it was compiled with ATKBD enabled that's going to be an automatic fail ... the PCjr BIOS does not support function 0x10 on interrupt 0x16 (they keyboard interrupt.)

If it was compiled with ATKBD undefined then you should be ok, as the Turbo C calls work fine and the DOS interrupt should be fine.

I'd be happy to try to recompile this and get it running on the Jr if you point me at the code.

[toddvernon]

many thanks, I'll dig in and try and compile from source.