Upgrading serial port for higher speed / more midi stability

[edingacic]

Option 3 would be most interesting if you can keep the timings same or better as other legacy devices . Friendchip is only 8 outs no input, and yes it is really needed to have 8 outs with drivers when you need to connect multiple devices you really fast run out of a room. And as you know keeping everything spaced helps with timing. Its all about this I guess if, not I would be using modern solutions that don't exist .

I contacted the guy that has MM1 and will get you the drivers hopefully soon.

[edingacic]

• FRIEND*CHIP MM1
You know what they say: owning multitimbral sound modules means never being able to say you've got enough MIDI Outs! Even with five outputs courtesy of the MO4, you may still find that you need additional MIDI hardware, such as Switch and Thru boxes.

This is where Friend*chip's MM1 comes in. This eight-MIDI Out device also connects via the ST's printer port, and adds an extra 128 MIDI channels to your setup. It is fairly small (about eight inches by five), and requires a 9-volt AC adaptor for power.

The MM1 has three modes. Bypass allows for normal use of a printer connected to the thru port at the rear, MIDI is the standard mode that gains the extra outputs, and Control allows you to switch between MIDI and printer via an included desk accessory. Neat.

ST and Falcon installations are provided on the disk, both of which are for Cubase. Again, the MM1 appears as extra outputs in the pop-up menu of the Output column on the Arrange page.

At £299, the MM1 isn't cheap, but as the only alternative is a patchbay (with all the complexities and problems one of these adds), and the MM1 appears to behave impeccably, you now have a decent option.

[Foxie]

I contacted the guy that has MM1 and will get you the drivers hopefully soon.

Fantastic, thanks! This would be so much easier than writing a driver from scratch. Being output-only, my guess is that the protocol is very simple. I had a very quick look at the SMP24 driver, but it looks like there's a lot going on. Probably the SMP24 provides the sequencer clock from extracted SMPTE.

Personally I don't really need an SMPTE reader. I wonder if anyone still does? If I need to synchronise to analogue tape, I'll use one of those SMPTE to MIDI time code converter boxes.

One thing I don't know is how big the buffer inside the Friendchip is. It might be possible to guess by looking at internal photos - but I doubt anyone is willing to take one apart. I could play it safe by making the clone have a really big buffer. That might perform even better than the real thing.

The other thing I forgot to add - I don't suppose anyone would care if I dropped the printer thru port? It just adds complexity because you need to handle the fact the printer might be plugged in and turned off (dragging your bus lines down). Easier to use an off-the-shelf switch box.

[edingacic]

I would not care if you drop the printer port who cares . We need more outs and fast timings . I also asked for him to take pictures from the inside

[Miguel]

No Foxie I did not test the latency of the S2000, I just used a pair of them to compare the Atari's MIDI Out port (using soft Thru) and the Atari's MIDI Thru port (which is hardware) and I didn't place the Atari ST under any considerable strain for the test.

Yeah the SMP24 has a lot going on, it does SMPTE, MIDI input and has transport controls so it's driver will most likely be just as complex whereas the MM1 should be more straightforward although admittedly I thought the same of their K..AT controller and I haven't been able to build a fully functional alternative yet. Yes SMPTE is still useful if you have a hybrid setup, I mean it's functionality is not limited to old tape machines and it does free up a MIDI port.

[edingacic]

I agree timecode would be nice but for the printer port I don't think is needed because we can use midex+ for this and have 13 out and 3 in with this solution. Right now this is what I use on my TT030 Midex+ and SoundPool mo4 giving me 8 out plus atari = 9 OUT and 3 IN. But it would be nice to have a new device that does it all and does it faster

[Foxie]

I agree timecode would be nice but for the printer port I don't think is needed because we can use midex+ for this and have 13 out and 3 in with this solution. Right now this is what I use on my TT030 Midex+ and SoundPool mo4 giving me 8 out plus atari = 9 OUT and 3 IN. But it would be nice to have a new device that does it all and does it faster

I had a close look at the schematic for the Midex, it's interesting. The SMPTE reader is entirely discrete, there's no microcontroller anywhere in it. It's quite difficult to read the SMPTE time code from a sequencer - you need to turn interrupts off, read the bit counter twice then do a whole load of shifting and finally find the start of the frame. If I make a sequencer, I'm not sure I want to go to that effort to support the Midex's SMPTE!

Have you had any luck with the drivers for the MM1 yet? I'm more interested in supporting the MM1 protocol than the MO4, but the MO4 might be a good fallback.

[edingacic]

Yes here it is thanks to Autonomy Music - Evert . Please download the pictures from wetransfer as soon as possible as they expire.

https://wetransfer.com/downloads/46f95c ... 427/092a1b

Drivers I can send you by email or private if its possible I see I can't attach it here?

[edingacic]

and here is the MM1 driver link

https://wetransfer.com/downloads/2e5a80 ... 400/1c5eab

p.s. Let me know what you think

[edingacic]

IMGP1623.jpg

MM1 top

back.jpg

rear

board.jpg

bottom

[Atari74user]

Nice pics of the ever illusive MM1!

[Foxie]

Yes here it is thanks to Autonomy Music - Evert . Please download the pictures from wetransfer as soon as possible as they expire.

Amazing! Thanks! These pics will be extremely useful ^.^

Just glancing over the pics, I can already see a clue to how it works. I'm astounded it's that simple! There's nothing programmable inside at all, and not even a UART. It's just a bunch of shift registers!

So, I would guess they address which port they want to write to (falling edge of strobe?), then write the data to the latch which is transferred to the shift register. It looks like there's another flip-flop on the output, probably to delay by one bit to generate the start bit.

I need to figure out a couple of things - there's a 245 in there, so is the bus bidirectional? What's it reading back I wonder? Busy/ready status for each port? The other thing I need to figure out is how they're timing their writes. You probably can't write another byte to a port while it's transmitting the current byte because it will corrupt the shift register. So they need a way of generating 0.32ms intervals.

The worst thing they could have done is create a periodic 0.32ms pulse on the busy line of the printer port. I hope it's more sophisticated than that. If they used a periodic pulse, everything will be jittered by 0.32ms!

I'll try and monitor what the driver is doing to answer some of these questions. Or maybe trace the schematic out. It might also be helpful to run some test programs on the real hardware at a later stage.

Do you have any idea what those DIP switches are for? I can't think why a non-intelligent interface would need them.

[edingacic]

Hi Foxie, as I am hardware clueless these questions are better answered by other people on the forum here. Maybe those DIP switches are for the printer settings like IRQ things I might be talking bull now but that could be it. It would be amazing if we could clone this 1 to 1. I think there is an accessory app for the printer port switching. I have asked Evert if there is anything else he can share and I'll forward it here to you. Also, I think he is willing to run tests when you need them.

here is what he wrote in the email to me .

" Hi Edin,

With fear, pounding heartbeat and shaking hands and even a drop of sweat or two, I took the MM1 apart,… You know what you did to me by asking me this!??!!? . I did a test run of all the connected gear to see if it still worked,… pfff,… yes!
You know a guy who can clone this? He is a hero to me! My superior if you will "

.

[Foxie]

Hi Foxie, as I am hardware clueless these questions are better answered by other people on the forum here. Maybe those DIP switches are for the printer settings like IRQ things I might be talking bull now but that could be it.

I suppose it could be something to do with the printer. I think the interface was made specifically for Cubase? In which case it can't be to select different software.

Would you mind asking the owner if he knows what the switches are for?

It would be amazing if we could clone this 1 to 1.

The good news is that it might be possible to clone it at the protocol level, with far fewer ICs needed yet identical performance. But let's assume it does in fact use 0.32ms interrupts. In that case, a clone could be *better* than the original by providing buffering. Instead of Cubase having to wait until the next "time slot" to transmit, it could just blast the data to the device at full-speed. In theory, that might work with the existing driver without modification - but I'll be finding out soon!

I'm currently downloading the latest Hatari source. I'll do the usual process I use for reverse-engineering - modify Hatari to catch writes to the printer port. Interestingly, with the driver installed in Cubase it locks up when I send MIDI data. That tells me straight away that there is some kind of feedback from the device. I'll know very shortly what kind of feedback that is.

With fear, pounding heartbeat and shaking hands and even a drop of sweat or two, I took the MM1 apart,… You know what you did to me by asking me this!??!!? . I did a test run of all the connected gear to see if it still worked,… pfff,… yes!

Let him know that I very much appreciate his effort! Already those internal pics have been absolutely key to figuring it out.

[edingacic]

Yes I think device is only for CuBase but maybe there were drivers for other sequencers later but I'll see if I can find more info. Here is a copy paste one more time of the function we know.

"The MM1 has three modes. Bypass allows for normal use of a printer connected to the thru port at the rear, MIDI is the standard mode that gains the extra outputs, and Control allows you to switch between MIDI and printer via an included desk accessory. Neat."

[Foxie]

Update: I had a quick look at the protocol, and so far it seems extremely simple.

It uses what appears to be standard printer handshaking. You write the data byte first, followed by the port number (00-07). That's it!

Now, the only thing I need to figure out before it can be cloned is exactly how it handles "buffer full" conditions. I believe it may use a periodic interrupt for that. A test program running on the real hardware to test its behaviour could be useful here.

[edingacic]

This is really promising Foxie . Looks like simple solutions are always the best if you can improve on them with today's knowledge and tools that would be even better. KISS rule - Keep it simple stupid!

[Foxie]

This is really promising Foxie . Looks like simple solutions are always the best if you can improve on them with today's knowledge and tools that would be even better. KISS rule - Keep it simple stupid!

I've started disassembling the driver. In my tests, I ran into some mysterious timing problems. There was a 0.32ms delay between each byte transmitted to the interface - even when multiple ports are being addressed. That can't be right - it would cause the total bandwidth of the entire interface to drop to the speed of a single MIDI port!

I think the reason it's doing that is because I'm not sending the right kind of handshaking yet. The driver doesn't use any handshaking during transmitting data packets, but it does use interrupts from the printer port. I need to dig deeper into the code.

Would it be possible to get the MM1 owner to run a test program soon? I haven't written one yet, but I might need to.


Update: unless I'm making a grave mistake, the number of CPU clock cycles between writes remains pretty much constant. So, the faster the machine the lower the delay. Could it really be that Cubase at 8MHz is just too slow to effectively drive multiple ports?

Luckily, I have some MROS development information. I could write a little MROS test program to see if the bottleneck is in Cubase itself or MROS (or the driver). I'm also going to be testing the Atari's on board MIDI outputs and the modem port to see if the delays occur there. If they do, we know it's nothing to do with the MM1 driver.

Of course it's still possible I'm making some kind of error with the handshaking. Testing the other ports will answer this.

Second update: It might be possible that Cubase will perform better when completely filling the buffer each cycle. At the moment I'm interrupting after every byte as you would a printer. If the interrupt was delayed by 0.32ms, it might have a chance to more completely fill the buffer. To test this, I need to figure out how to get Hatari to generate an interrupt n cycles ahead. I'm not terribly familiar with Hatari's source.

[Miguel]

I thought I would look for information on the StarPort seems as how it is supposed to be identical to the MM1 and this is what I found.

"Brand new at Geerdes in distribution is the StarPort, a hardware extension that offers eight additional MIDI ports and is connected to the Atari via the Centronics interface. Up to four of these units can be cascaded, giving a maximum of 512 additional independent MIDI channels. The price for a StarPort unit is 498 marks. DVPI has announced in this context a MIDIShare compatible version of the session partner, which also supports the StarPort. Freestyle by Sound-Pool also controls the StarPort. The device is identical to the MMI MIDI expander by Friendchip."

[Foxie]

Up to four of these units can be cascaded, giving a maximum of 512 additional independent MIDI channels.

Interesting! I suppose that means the MM1 can also be cascaded? I wonder if that's what the DIP switches are for? I'm still trying to figure them out. At first I thought they disabled/enabled MIDI ports in pairs, but on closer inspection I don't think so. It could be to select which of the four units in the chain it is. It looks like some of the bits in the port selection byte will select one of the DIP switches and somehow use that to control one of the MIDI ports. It could well be that there's one DIP switch for each position in the chain.

I have no idea how to get the driver to expose 32 ports. Looking at the interrupt handler it seems like it's limited to 8 ports. I'm not really sure how you'd keep four units in sync - I believe the protocol relies on a 0.32ms clock generated by the unit.

If it really can go to 32 ports, that must make it the largest MIDI expander for the Atari.

The price for a StarPort unit is 498 marks. DVPI has announced in this context a MIDIShare compatible version of the session partner, which also supports the StarPort. Freestyle by Sound-Pool also controls the StarPort. The device is identical to the MMI MIDI expander by Friendchip."

I'd love to get my paws on the software that came with the StarPort, but I guess it's even more obscure than the MM1.

[edingacic]

Wow this is all too interesting to read. Foxie if you write a program I am sure my friend will run it and give you data back. He is using it on Falcon and I would love to use it on my TT030. I have original dongles and Midex+ & SoundPool MO4 if you need anything tested here I can do that too. Keep up the good work.

@ Miguel - What is this device StarPort never heard of it? Do you have pictures/ drivers?

[Foxie]

Wow this is all too interesting to read. Foxie if you write a program I am sure my friend will run it and give you data back. He is using it on Falcon and I would love to use it on my TT030.

Fantastic! I'll get to work on a test program later today.

It's good to know it works on the Falcon, because I did wonder if it was using delay loops. If it works on the faster machine, then it must be cleanly written. The faster processor should also improve MIDI bandwidth quite a bit since Cubase can zip through its internal number crunching much more quickly.

I have original dongles and Midex+ & SoundPool MO4 if you need anything tested here I can do that too. Keep up the good work.

That could be useful once I've finished reverse-engineering the MM1. I'm interested in the Midex and on the Notator side, the Unitor. They look quite possible to clone too. But I think the MM1 will deliver better performance since it's interrupt-driven.

[Atari74user]

Cool, never heard of the Starport, that's interesting!

Likewise, if you need any help with testing on ST with Cubase v3.1 or Notator/ Falcon with CAF or LAF for that matter, let me know:
-SMP II
-Unitor 2
-Log 3
-MIDI Xtra (16+)
-Export
-M04 (as edingacic)
-Midex (as edingacic)

[hasbab]

there is a fairly extended discussion on gearslutz about midi latency and jitter with some info about the ST and dongles if that's of any use to any of you

https://www.gearslutz.com/board/steinbe ... -yeah.html

[Miguel]

When I noticed the two ports and DIP switches I thought they are either for daisy-chaining or configuring the MM1 for some other platform like the DIP switches on Steinberg's MIDI-3.

@ edingacic Apparently the StarPort is the same as the MM1 although I have not seen a picture of it or even looked for drivers....I just remember having read about it somewhere so I thought I would look it up.