TFMSX rev 2 features & problems

[arkadiusz.makarenko]

....and basic LED Support implemented. (link stays the same) I need to hold CAPS status in stm32, and I don't have way of reading current CAPSLOCK value from MSX,so I imagine it will be fairly easy to get those two values out of sync, but for standard use cases it will do the job.

[NYYRIKKI]

Hey, this time everything seems to work! It seems you were faster to fix the keyboard driver than I was to fix the test software, but I implemented the missing features anyway in case someone else might needs such a program in the future:

showkey.zip

(26.09 KiB) Downloaded 3 times

I noticed that indeed the CAPS-lock has it's own life, but I think it works well enough... For some reason it seems that if I read the status from PPI port (= ? INP(&HAA)) the command does not even read the CAPS-led status correctly, but this must be a bit missing from the FPGA-side PPI emulation.

The Kana-led / "Russian keyboard"-led is also not implemented, but if you can't implement it correctly, then I think it is good like it is now. These leds are anyway used quite rarely. I noticed that ie. in Tenebra 2 the CAPS-led is used to indicate if you carry torch or not, but I would say such things are just very rare and don't really have a real life use cases.

Overall I'm very happy with the keyboard driver now.

[NYYRIKKI]

As of mouse support I will add this to my todo list for this firmware, I am a little bit snowed in at work just now, but winters are long in Scotland.

@arkadiusz.makarenko
Yes, now that we got the keyboard working, we can start talking about the mouse support.

I did enhance the keyboard test one more time before I posted it on msx.org forums. In there someone pointed me that there is also another keyboard test program, but unfortunately I could not get it to run. In theory it might be interesting to you as it has also mouse test, but currently some more info is needed. The discussion is here:

https://www.msx.org/forum/msx-talk/hard ... ard-tester

While talking about MSX-mouse, one thing to keep in mind is that it is quite a low resolution device compared to modern mice (75dpi or so (?)) This means you need to implement some floating point/fixed point arithmetics in coordinate conversion to make it move smoothly. It should not be a big issue as long as you keep the resolution difference in mind from the start.

In theory MSX mouse is pretty simple device. It has two buttons, that work exactly like in joystick and beside that you only need to transfer X & Y deltas... Modern USB-mice are anyway more complex and have advanced features like scroll-wheel and extra buttons, that you may want to take into consideration.

If you just implement the basic mouse features (2 buttons & directions), it is more than enough... How ever, if you look the protocol specs that I posted all the way down, you will see that we enhanced the protocol to handle also these new features. I was personally involved making the new specs, but especially if you are worried about implementing useless features, I think you can more than safely skip this part... In theory, it sure is nice to scroll ie. Notepad window in SymbOS with scroll wheel same way as in Windows, but practically SymbOS is the only use case that even supports such things, and you can easily live without such features.

I did implement the enhanced protocol when I made PS/2 -> MSX mouse adapter on Arduino, but I also implemented another mode, where I can seamlessly adjust the mouse sensitivity/resolution with the wheel... And if you ask me now, what I use? It is running always in mode where I can adjust the sensitivity on the fly instead of having the scroll-functionality.

[arkadiusz.makarenko]

As of mouse support I will add this to my todo list for this firmware, I am a little bit snowed in at work just now, but winters are long in Scotland.

@arkadiusz.makarenko
Yes, now that we got the keyboard working, we can start talking about the mouse support.

I did enhance the keyboard test one more time before I posted it on msx.org forums. In there someone pointed me that there is also another keyboard test program, but unfortunately I could not get it to run. In theory it might be interesting to you as it has also mouse test, but currently some more info is needed. The discussion is here:

https://www.msx.org/forum/msx-talk/hard ... ard-tester

While talking about MSX-mouse, one thing to keep in mind is that it is quite a low resolution device compared to modern mice (75dpi or so (?)) This means you need to implement some floating point/fixed point arithmetics in coordinate conversion to make it move smoothly. It should not be a big issue as long as you keep the resolution difference in mind from the start.

In theory MSX mouse is pretty simple device. It has two buttons, that work exactly like in joystick and beside that you only need to transfer X & Y deltas... Modern USB-mice are anyway more complex and have advanced features like scroll-wheel and extra buttons, that you may want to take into consideration.

If you just implement the basic mouse features (2 buttons & directions), it is more than enough... How ever, if you look the protocol specs that I posted all the way down, you will see that we enhanced the protocol to handle also these new features. I was personally involved making the new specs, but especially if you are worried about implementing useless features, I think you can more than safely skip this part... In theory, it sure is nice to scroll ie. Notepad window in SymbOS with scroll wheel same way as in Windows, but practically SymbOS is the only use case that even supports such things, and you can easily live without such features.

I did implement the enhanced protocol when I made PS/2 -> MSX mouse adapter on Arduino, but I also implemented another mode, where I can seamlessly adjust the mouse sensitivity/resolution with the wheel... And if you ask me now, what I use? It is running always in mode where I can adjust the sensitivity on the fly instead of having the scroll-functionality.

At this point I am still stuck on hardware protocol itself related to sending directions.
I read following values from mouse X and Y which are in range of -255 to 255, and three mouse buttons values. I can read scroll wheel vales as well if I have to.

Now I still don't get how signal is sent to MSX, I have previously implemented quadrature mouse for Amiga, but I don't think it is the same?

[arkadiusz.makarenko]

@terriblefire

Mouse MSX port support.png (104.7 KiB) Viewed 192 times

I think because how pin 8 is used we might not be able to support mouse with current CPLD firmware?

[NYYRIKKI]

At this point I am still stuck on hardware protocol itself related to sending directions.

On MSX both X and Y are signed chars. (-128 to 127)
The basic (original MSX-mouse) protocol is pretty easy:

Code: Select all

- wait until joypin 8 = Low
- send X data bits 4-7 to Joypins 1-4
- wait until joypin 8 = High
- send X data bits 0-3 to Joypins 1-4
- set x to 0

- wait until joypin 8 = Low
- send -Y data bits 4-7 to Joypins 1-4
- wait until joypin 8 = High
- send -Y data bits 0-3 to Joypins 1-4
- sey y to 0

In reality the pin 8 will flip double amount of times during read, but if you have implemented the previous, it will just cause two more 0-bytes to be transferred immediately after the previous X & Y, so you don't need to worry about it. Typically this read routine is called 50- or 60-times/sec on MSX.

[NYYRIKKI]

@terriblefire

I think because how pin 8 is used we might not be able to support mouse with current CPLD firmware?

Since I managed to run even 57600 bps RS232 trough the port, I'm pretty sure you have implemented the joystick port correctly. (I used pins 1 & 6 only though) Now I don't remember if I actually tried mouse or not. In MSX pins 1, 2, 3 and 4 are input only. Pins 6, 7 ("button pins") can be configured as input or output and pin 8 is output only (pin8 in joystick mode is used as GND = If this pin is high, no value from joystick directions is returned.)

It is possible though that you have implemented the USB-support so that you can't read the pin 8 status, that would be a bit sad news.

[NYYRIKKI]

You may want to check out this MSX HIDtest tool: https://frs.badcoffee.info/tools.html

[arkadiusz.makarenko]

Stm32 doesn't directly access port lines, but via cpld, so if there was no right logic internally then I wouldn't have access to pin 8.
Terrible fire said that I should have access to pin 8 values on stm32 pin 37.
I will try to do some prof of concept this weekend.

[arkadiusz.makarenko]

After running this program

Code: Select all

10 screen 1:sprite$(0)="0HH0":fori=0to1:r=pad(12):x=(x+pad(13))and255:y=(y+pad(14))and255:put sprite 0,(x,y),8:i=-strig(1):NEXT

I managed to detect pin 37 (PC6 on stm32) equivalent pin 8 on gameport state change. And it was state change only after running this command, so this means that I have everything to implement mouse.
I still have some issues to solve, as there is already a lot of happening on the chip, as how to sync request for next set of data from MSX with other stuff already there, like USB stack, USB IRQs, HUB support, keyboard IRQs etc ...
It has to be IRQ based as I cannot block keyboard, and it has to be low priority as keyboard and possibly USB might need to take priority.