MidiLink 2.0 looking for testers. (no MIDI devices required)

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Sorgelig, Moderator Team

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Wed Mar 06, 2019 3:23 am

BBond007 wrote:Just be careful. I remember this one time back in the early 80s when I almost inadvertently started WW3 trying to impress Ally Sheedy with my modem.


People have started wars for far less noble reasons.
- Paradroyd
@paradroyd on twitter

robdaemon
Retro freak
Retro freak
Posts: 13
Joined: Mon Jul 24, 2017 5:01 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby robdaemon » Sat Mar 09, 2019 3:43 am

BBond007 wrote:I know very little about the Atari 8-bit computers and their architecture. I'm not even sure what the most common (or preferable) interface would be for connecting the UART. It would seem that some of the options include Atari 850 Interface Module (which uses SIO port?), Atari 835 direct-connect Modem and Atari Telelink cartridge. Given my complete lack of knowledge of the Atari 800 architecture, hardware and terminal emulation, I don't have an answer as to how difficult it would be. It might be better ask the question in the thread for that core.


I would go with the Atari 850 interface, which is SIO - that one lets you connect RS-232 devices, and all the terminals for the Atari 800 support it. I have an 850 with a WiFi modem attached to my physical Atari 800XL today. Basically you load a R: handler program (and there are a few out there) but the 850 is the most common that I know of. That's what AtariMax APE and RespeQt do with the SIO-to-USB adapters.

I would very much like to have this support too. This has been really awesome in the cores it's in now!

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Tue Mar 19, 2019 6:09 am

I have updated MidiLink in order to correct a bug which was found in the general release (ver 2.5) - when I added support for multiple AT commands on a single line I broke the AT&K# commands for setting flow-control.

Also,

TCP_TERM_TRANS = PETSKII was breaking q-link (which is looking for "connect" vs "CONNECT").

Finally,

I have disabled Nagle's algorithm which queues small packets to be sent in a larger packet in order to reduce network congestion at the expense of additional latency.

This change allows Knights of the Sky (which seems to be timing sensitive) to connect on the Minimig core. Prior to this change I could only get the game to connect using the UDP option.

Knights of the Sky head-to-head (Minimig) --> http://y2u.be/TH1GDu2Da9A

glaucon1984
Atariator
Atariator
Posts: 24
Joined: Fri Aug 04, 2017 12:23 pm

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby glaucon1984 » Thu Apr 11, 2019 10:59 pm

I've been testing MidiLink using the internal MUNT/FluidSynth and I have to report the same as other users before, MUNT doesn't sound right, it feels like it cannot handle all the notes and there is a point were it releases several notes at once to get up to speed with the melody. Not sure if it's an issue with the ARM processor not having enough power to handle MUNT emulation or with the communication over serial port having some jitter.

I tend to vote for the second option, as the speed of the Roland devices was 31250 but the serial port on a PC has to be at 34800.

I've seen this about a serial port driver that helps with this issue converting 38400 -> 31250 bauds here, but it's a driver for Windows NT-based OS:
https://www.vogons.org/viewtopic.php?t=17586#p126528

Maybe it's possible to recompile SoftMPU to use 31250 bauds for the serial port? Or maybe it's better to wait for the implementation of a proper MPU-401...

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Fri Apr 12, 2019 10:02 am

glaucon1984 wrote:I tend to vote for the second option, as the speed of the Roland devices was 31250 but the serial port on a PC has to be at 34800.

If that was the issue then the problem would also occur when using a real MT-32 or MUNT on windows when (connecting via remote:UDP) or even when using FluidSynth. That has never been reported. MUNT sometimes exhibits the same behavior using the Minimig core too - which does run the UART at 31250 for MIDI.

People have also reported the notes jamming phenomenon when running MUNT on the Raspberry Pi3 (similar ARM CPU with faster clock-speed) and the suggested solutions for minimizing it is CPU governor tweaks and overclocking --> https://retropie.org.uk/forum/topic/125 ... on-rpi-3/5

The DE10-nano ARM CPU is already running full-tilt. I have tried various MUNT compiler optimizations, runtime configuration options (such as buffering mode/size and emulation mode) and even tried allowing MUNT to utilize both ARM CPUs to no avail.

I still think it is a cool feature even if it's not perfect. For games that don't have super complex music, I think it sounds reasonably good... better than Adlib/SandBlaster FM anyway :)

Maybe someday someone will make a MT-32 implementation in HDL or the MiSTer will migrate to a platform with a more powerful HPS, but until that happens, I would suggest using remote:UDP to send the raw MIDI data to MUNT running on a more powerful x86 PC or purchasing a used CM-32L/MT-32 for better results.
glaucon1984 wrote:Maybe it's possible to recompile SoftMPU to use 31250 bauds for the serial port?

If you do decide to try and recompile SoftMPU you can alter the [ao486] section of the /media/fat/linux/MidiLink.INI and set MIDI_BAUD = 31250.
glaucon1984 wrote:Or maybe it's better to wait for the implementation of a proper MPU-401...

A MPU-401 implementation in the ao486 core would definitely be nice, improving game compatibility and simplifying configuration, but I doubt it would help the issue with notes jamming when using MUNT on the HPS.

Sorry I don't have any better ideas :(

glaucon1984
Atariator
Atariator
Posts: 24
Joined: Fri Aug 04, 2017 12:23 pm

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby glaucon1984 » Fri Apr 12, 2019 4:18 pm

BBond007 wrote:If that was the issue then the problem would also occur when using a real MT-32 or MUNT on windows when (connecting via remote:UDP) or even when using FluidSynth. That has never been reported. MUNT sometimes exhibits the same behavior using the Minimig core too - which does run the UART at 31250 for MIDI.

OK, it makes sense. I thought that traffic over UDP wasn't restricted to 38400 bauds but of course, the communication happens through the same serial connection. Also if there are reports of issues with Amiga at 31250 bauds then it will probably be caused by MUNT not performing well enough.

BBond007 wrote:Sorry I don't have any better ideas :(


I remember Sorgelig commenting in the past that he only uses one thread on the ARM CPU to improve CPU temp. I wonder if instead of multithreading you tried to assign one (the?) unused core exclusively to MUNT.

Another idea... what's the scheduler used by the kernel? maybe it's possible to try with something oriented to low latency?

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4177
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Sorgelig » Fri Apr 12, 2019 7:11 pm

glaucon1984 wrote:I remember Sorgelig commenting in the past that he only uses one thread on the ARM CPU to improve CPU temp.

That's old info. Not true now.

glaucon1984 wrote: I wonder if instead of multithreading you tried to assign one (the?) unused core exclusively to MUNT.

this is almost how it works now.

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Mon Apr 15, 2019 2:57 am

FYI, the latest C64 core, (C64_20190415.rbf) seems to break Midilink / UART support.

You can immediately see the effect by repeatedly typing "athelp", "atdir" or anything else that produces long output from a terminal program. I've dropped back to the previous core (C64_20190413.rbf) and the problem does not seem to exist there, but is very easy to reproduce in C64_20190415.rbf.

IMG_20190414_213212.jpg
You do not have the required permissions to view the files attached to this post.
- Paradroyd
@paradroyd on twitter

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4177
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Sorgelig » Mon Apr 15, 2019 5:55 am

New C64 release has original PAL/NTSC clocks instead of 32.0MHz as before.
May be Midilink needs adjust the speed of UART according to new clocks?

Try NTSC mode - it has a little faster clock than PAL.

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Mon Apr 15, 2019 5:13 pm

Sorgelig wrote:New C64 release has original PAL/NTSC clocks instead of 32.0MHz as before.
May be Midilink needs adjust the speed of UART according to new clocks?

Try NTSC mode - it has a little faster clock than PAL.


I thought about that and tried switching modes when I saw that the clock was one of the things that had changed in this update . I did that before I reported the issue (I should have mentioned that).

I normally run on NTSC unless I specifically require PAL. Unfortunately, setting PAL vs NTSC makes no difference to the serial corruption issue.

At the moment it's not a problem, because when I need to use the Midilink / UART, I just boot the previous release for that session and it works fine. I'm just reporting it so that you know about it.

Thanks.
- Paradroyd
@paradroyd on twitter

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Mon Apr 15, 2019 5:16 pm

Paradroyd wrote:At the moment it's not a problem, because when I need to use the Midilink / UART, I just boot the previous release for that session and it works fine. I'm just reporting it so that you know about it.


I have the same problem with C64_20190415.rbf.

This test build incorporates all of the latest changes except I reverted one change to the CIA.
You do not have the required permissions to view the files attached to this post.

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Mon Apr 15, 2019 5:35 pm

BBond007 wrote:I have the same problem with C64_20190415.rbf.

This test build incorporates all of the latest changes except I reverted one change to the CIA.



Thanks. I'll check it when I get home tonight.
- Paradroyd
@paradroyd on twitter

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4177
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Sorgelig » Mon Apr 15, 2019 6:14 pm

if it fixes the UART, then i will revert it in my repo too.

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Mon Apr 15, 2019 8:07 pm

Sorgelig wrote:if it fixes the UART, then i will revert it in my repo too.


this is the proposed change.
https://github.com/bbond007/C64_MiSTer/ ... 7100f07103

I will run Lorenz and VICE CIA test and compare to C64_20190415.rbf
If it seems ok, I can do a pull request...

Paradroyd wrote:Thanks. I'll check it when I get home tonight.


Thanks,

I tested it a little, but I really need to pause for a while and work on my 2018 taxes which I have put off until the last minute...

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Tue Apr 16, 2019 12:06 am

BBond007 wrote:
I tested it a little, but I really need to pause for a while and work on my 2018 taxes which I have put off until the last minute...


Hope the tax activities have been fulfilling.

This test version is definitely a great improvement. The incidence of corruption is way down from C64_20190415.rbf, but unfortunately, it still happens occasionally.

I'm basically just alternating typing "atdir" and "athelp" over & over many times quickly to get this result. These screenshots are of CCGMS Ultimate running in NTSC mode, with CCGMS in PETSCII mode.

IMG_20190415_182511.jpg


IMG_20190415_182556.jpg


IMG_20190415_184210.jpg


Once again, dropping back to C64_20190413.rbf seems to completely eliminate the problem.
You do not have the required permissions to view the files attached to this post.
- Paradroyd
@paradroyd on twitter

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Tue Apr 16, 2019 2:40 am

Paradroyd wrote:This test version is definitely a great improvement. The incidence of corruption is way down from C64_20190415.rbf, but unfortunately, it still happens occasionally.

...

Once again, dropping back to C64_20190413.rbf seems to completely eliminate the problem.


It tool like 10 rounds, but I did see finally the corruption.

One thing I notice with CCGMS, the corruption seems to be with the character set and not the actual serial data. Meaning once the corruption happens it is consistent...

For example, after a corruption occurs, if you press F1 (upload file) a few time the characters corrupt characters are consistent - and those characters are not coming from MidiLink. F7 seems to reset the character set?

I have added the command 'ATUARTTEST'
Which will automate the test you are performing (ATHELP+ADIR in an endless loop). - Reset UART connection to exit...

'ATUARTTEST!'

will set the rows to 0 which disables '[PAUSE]'

Not important, but you could add to MidiLink.INI:

[C64]
TCP_TERM_TRANS = PETSKII

You will see (in the help) :

AT - Attention
...
vs
at - aTTENTION
...

User avatar
Paradroyd
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Sep 10, 2013 10:50 pm
Contact:

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby Paradroyd » Tue Apr 16, 2019 4:51 am

BBond007 wrote:It tool like 10 rounds, but I did see finally the corruption.

One thing I notice with CCGMS, the corruption seems to be with the character set and not the actual serial data. Meaning once the corruption happens it is consistent...

For example, after a corruption occurs, if you press F1 (upload file) a few time the characters corrupt characters are consistent - and those characters are not coming from MidiLink. F7 seems to reset the character set?


Yeah..I see what you mean. I'm not sure where the corruption is coming from, but as scarce as it is now, there's still clearly something wrong somewhere, and I haven't been able to get any corruption at all in C64_20190413.rbf or earlier.

BBond007 wrote:I have added the command 'ATUARTTEST'
Which will automate the test you are performing (ATHELP+ADIR in an endless loop). - Reset UART connection to exit...

'ATUARTTEST!'

will set the rows to 0 which disables '[PAUSE]'


That's cool I will play around with that.

BBond007 wrote:Not important, but you could add to MidiLink.INI:

[C64]
TCP_TERM_TRANS = PETSKII

You will see (in the help) :

AT - Attention
...
vs
at - aTTENTION
...


I was actually messing with that earlier. I just didn't bother switching it for my latest tests.

One thing I did do was switch the term program from PETSCII to standard ASCII, and the corruption was almost impossible to reproduce, or at least a lot harder to notice.
That really makes sense though, because there's a lot less that can go wrong with ASCII. Any nonsense above CHR$127 is going to get cut off/ ignored, where in PETSCII you've got single characters above CHR$127 that if they randomly get triggered, will affect everything that comes after them. Plus you have more possibilities of characters that can go wrong in general.

Fun stuff.
- Paradroyd
@paradroyd on twitter

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Tue Apr 16, 2019 6:14 am

Paradroyd wrote:I was actually messing with that earlier. I just didn't bother switching it for my latest tests.

One thing I did do was switch the term program from PETSCII to standard ASCII, and the corruption was almost impossible to reproduce, or at least a lot harder to notice.
That really makes sense though, because there's a lot less that can go wrong with ASCII. Any nonsense above CHR$127 is going to get cut off/ ignored, where in PETSCII you've got single characters above CHR$127 that if they randomly get triggered, will affect everything that comes after them. Plus you have more possibilities of characters that can go wrong in general.

Fun stuff.


That is interesting an interesting and potentially relevant observation. I guess I forgot there was a PETSKII code for C+Shift witch also effects everything. Was that with C64_20190415.rbf or the C64_20190416.rbf (I attached above) or both?

All the (MidiLink) PETSKII translation really does is switch the case of A-Z <> a-z for some of the results returned from MidiLink itself (such as ATHELP and ATDIR).

Fun stuff indeed :)

Anyway, thanks for testing :)

slingshot
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Mon Aug 06, 2018 3:05 pm

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby slingshot » Sat Apr 20, 2019 12:16 am

BBond007 wrote:
I will run Lorenz and VICE CIA test and compare to C64_20190415.rbf
If it seems ok, I can do a pull request...



There's no tests for the flag_n pin (as it requires an external source).
Did you try with the "new" CIA model? (mode = 1). Recently the Timer B bug was added which affects the "old" model.

BBond007
Captain Atari
Captain Atari
Posts: 280
Joined: Wed Feb 28, 2018 3:23 am

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)

Postby BBond007 » Sat Apr 20, 2019 2:39 am

slingshot wrote:There's no tests for the flag_n pin (as it requires an external source).
Did you try with the "new" CIA model? (mode = 1). Recently the Timer B bug was added which affects the "old" model.


Does not fix the issue :(

Reverting back to the previous mos6526.v (Apr 11, 2019) does seem to fix the problem though...


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 5 guests