|Re: [hatari-devel] (raw) MIDI connection reliability? (was: Can't build Hatari on Mac if PortMidi is not installed)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 11.6.2022 13.03, Thomas Huth wrote:
Am Sun, 29 May 2022 19:30:09 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
I've just tested it and it works, although it's a bit fragile. For some
reason MIDI communication sometimes takes a lot of time / or times out.
I tested several TOS and machine configs, but could not find a
repeatable pattern. STE / TOS 2 or EmuTOS did seem more reliable that
ST / TOS 1.x though.
There were also few other games I tested for MIDI ring networking
* MidiMaze 1 I did not get working, it just gave a "MIDI Boo-Boo" dialog
after trying to connect, but it's apparently known to be buggy(?)
* Midimaze 3 is beta version, and GUI lost mouse cursor (under EmuTOS
v1.1.1) before I was able to start game from the menu.
There was a description of MidiMaze MIDI communication at Atari forum
recently, and it's pretty minimal.
At start it just sync maze and settings between machines, and after that
it sends just joystick input, i.e. very little. *If* I remember
correctly, control info (quit) just had extra bit set in those bytes.
* Masters of Chaos did connect with MIDI between two Hatari instances,
but I have no idea what it was doing with the connection
* JitterBug threw an error after game run for a while
I can add another game here (which I tested recently while working on the
RS232 code): Oxyd 2 ... the game now works fine when starting the
two-player mode via an RS232 connection, but when using MIDI, it aborts
after a couple of seconds (at least I never made it any further than level
two when using MIDI).
Something is definitely still causing major trouble here...
I wonder could the issue come when there's very little being
communicated between the machines?
Looking at midi.c and Midi_Host_WriteByte(), it uses *buffered* fputc()
to do MIDI byte writes, but only fflush() call is in
Midi_InterruptHandler_Update(), *and* commented out...
(Best would be using write() directly, but that's not portable, so I
guess fputc() + fflush() is second best alternative.)
Btw. when looking at rs232.c, RS232_TransferBytesTo() also has buffered
fwrite(), but no fflush().