Please help testing upcoming openMSX release!

It's not persistent unfortunately. Right now, I tried to reproduce and now it accepts connections again - as was the case for a long time earlier - like all of 2020. It's just that once openmsx starts to deny connections from the debugger, I can always remedy it by not running scripts.

So, when this happens again, where should I look?

(a long time ago, I remember that the debugger was very slow to connect, and then there were lots of files somewhere that just needed to be deleted. let me know if there are tricks like that )

I compared the Main-ROM of the Sony HB-10P with that of the HB-20P which I probably got in the zip of the full set ROM for Open MSX.

hb-10p_basic-bios1.rom (sha=5e7c8eab238712d1e18b0219c0f4d4dae180420d)
hb-20p_basic-bios1.rom (sha=365c93d7652c9f727221689bcc348652832a7b7a)

Both are indicated "PAL" but in that of the HB-10P, it is indicated that it is an English version and that of the HB-20P is a Spanish version.

The wiki pics show that both models have the same keyboard and there is also an HB-10P with an english keyboard.

https://www.msx.org/wiki/images/c/c8/HB-10P.jpg
https://www.msx.org/wiki/images/2/2e/Sony_HB-20P.jpg

https://www.msx.org/wiki/images/e/ef/Hb10pa.jpg

It is better to differentiate them. I think this problem is not limited to this model. It lacks a bit of rigor.

Does anyone have the spanish version ROMs? Is there a dump of English version of the HB-20P?
In addition, does anyone have the ROMs of Japanese HB-55 and HB-75?

Hi!

I've created a program that reads line 6 of the keyboard matrix (F3,F2,F1,Code,Caps,Graph,ctrl,shift). When I press Shift Key I get 254 as expected, but if I keep it pressed and press space bar, I read 255 in place of the 254.

I was expecting to read always 254 while shift is pressed whether space is pressed or not.

I've tried other keys of the line: F3,F2,F1 and Ctrl, and it works as expected. Either I press space or not it reads the value well.

PS: The program is a c file using fusion-c. Here is the source code:

#include "msx_fusion.h"
#include 

#define HALT __asm halt __endasm // wait for the next interrupt
void WAIT(int cicles) {
  int i;
  for (i = 0; i < cicles; i++)
    HALT;
  return;
}

void main (void) {
  Screen(0);
  Width(80);
  unsigned char linia_Shift = GetKeyMatrix(6);
  unsigned char linia_A = GetKeyMatrix(2);

  while( (linia_A & 64)==64) {
    printf("%d\t", linia_Shift);
    linia_Shift = GetKeyMatrix(6);
    linia_A = GetKeyMatrix(2);
    WAIT(1);
  }
  Print(" Hi!");
  WaitKey();
  Exit(0);
}	

I've tried this in my real MSX and it works as expected for all the keys, including Shift.

Is my window manager doing something strange (I'm using KDE)? or does anybody else have this problem with openMSX?

Hi again,

I think I found the explanation ...

OpenMSX has different 'keyboard mapping modes'. The default mode is 'CHARACTER'. In this mode we try to remap a host character to the corresponding MSX character. Let me explain via an example:

Suppose my host keyboard layout is US-QWERTY, but I'm emulating a MSX machine with a french AZERTY keyboard layout. When on my host keyboard I press SHIFT+7, I type the '&' character. But to type this character on this particular MSX I need to press the '1' key without holding shift.

In other words: in CHARACTER mode, the intention is to type characters and these then get translated from host keyboard presses to the corresponding MSX keyboard presses. In this mode, as an openMSX user, I don't need to be aware of keyboard layout differences between host and MSX.

Internally in the implementation of CHARACTER mode we make a distinction between 'typeable' and 'non-typeable' key presses. Typeable means a sequence that results in a unicode character. Examples of a non-typeable key presses are e.g. the cursor keys or pressing SHIFT without any other key presses. For every unicode character that can be typed on a specific MSX model, openMSX 'knows' what combination of MSX keys (if any) to press to generate the corresponding MSX character.

In your case: pressing SHIFT+SPACE generates unicode character 32. OpenMSX knows how to produce character 32 on MSX: just press space. OpenMSX is not smart enough to know that character 32 can ALSO be produced by pressing SHIFT+SPACE.

As a workaround you could try some of the other openMSX keyboard modes: KEY or POSITIONAL. In these two modes individual host keys get mapped to individual msx-keys. So if we retake the above example, pressing SHIFT+7 on the host keyboard will result in SHIFT+7 on the MSX keyboard. Though on the host side this will produce a '&' while on the MSX side (with french keyboard layout) this will produce a '7'. On the other hand SHIFT+SPACE on the host will now also translate to SHIFT+SPACE on the MSX (i just tested this).

the debugger is nice, but I like to see real-time variables..
To see direct consequences when I send variables to port &ha8, &hab, &hbb, etc...
I like to see the reason why the emulator is giving a message like "PPI not emulated correctly" when sending data to specific ports...