Upgrading serial port for higher speed / more midi stability

[hasbab]

Hi everyone,

I'm looking to mod the serial port on my Atari STE so I can reliably add 3 more midi channels.

I've looked into doing the RSVE mod but don't have access to a GAL programmer and can't seem to find any kits with preprogrammed GAL chips available.

I found this old thread at Atari Age quite interesting:
http://atariage.com/forums/topic/83649- ... try1056420

That thread mentions that the GAL chip is a needless addition. It also mentions that higher modem speeds are impossible without an accelerator.

I have two questions if anyone is able to help:

1) Is there a serial port enchancer mod that does not require a programmed GAL chip?

2) Will a serial port enhancement to add additional midi channels to the ST require hardware acceleration in order to perform without excessive latency?

Thanks!

[1st1]

Why not just using a Midex, SMP24, Unicorn?

[Atarieterno]

Try the MIDIXTRA.ZIP (C) by Björn Julin:

http://atari4ever.free.fr/

[charles]

probally will need some enhancing ,
because even with a midiex and me using only two ports , my midi latency was greatily increased.....unstable timing and program becomes non responsive..

I have a rs232 midi port expander however have not tried it yet ,,
I do believe this should solve the latency issue as its not all coming out of the same port

[hasbab]

probally will need some enhancing ,
because even with a midiex and me using only two ports , my midi latency was greatily increased.....unstable timing and program becomes non responsive..

I have a rs232 midi port expander however have not tried it yet ,,
I do believe this should solve the latency issue as its not all coming out of the same port

I've heard that C-Lab even warned against using Export (RS232 midi port expansion) for high bandwith applications, such as mod wheel changes, it was only really recommended for note on and note off messages.

It's pretty difficult to find anyone who has performed this upgrade recently, or to find any info on performing it without programming a GAL chip

[charles]

its a rock solid platform however as soon as users beginning adding extras it is unable to perform as required.....
I for one am interested in the upgrades but would not trust or install on any of my machines....

I would encourage someone to program and write a proper handler for these extra ports , duplicating the traps of the bios placing a bios set of call of a new 68000 trap calls ,
this might lighten the load of the signal to cpu usage but I feel hardware add ons wont be a permentant fix...

[hasbab]

I have also posted this over in Atari Age Forum and Zogging Hell mentioned there that there was a serial port upgrade mentioned in ST Format (possibly from issue 40 onwards) or ST Review that allowed you to double the speed of the serial port to 38400. Speeds higher than 38400 are unstable on Atari's without hardware acceleration.

He mentioned this is around about the same baud requirement for midi, which does appear to be the case meaning it would probably be good for midi expansions through the serial port

The 38400 mod is available here:
http://atari4ever.free.fr/hardware/zip/mfp38400.zip

Unfortunately, the instructions are both minimal and written in German. The mod itself does appear to be relatively simple (attached circuit diagram below) but would be really useful to know if anyone has instructions in English or some experience of installing the mod

[hasbab]

I found the ST Format serial mod in issue 71:

http://www.atarimania.com/atari-magazin ... 1_189.html

Looks to be simpler than previous mods I've posted

[Fujiyama]

I've heard that C-Lab even warned against using Export (RS232 midi port expansion) for high bandwith applications, such as mod wheel changes, it was only really recommended for note on and note off messages.

It's pretty difficult to find anyone who has performed this upgrade recently, or to find any info on performing it without programming a GAL chip

Years ago I got hold of an ST_ESCC, ready built directly from the author (Harun Scheutzow) which I installed inside my STe. It added two high speed serial ports (for a total of three serial ports, similar (the same?) to what the Mega STe has). The HSMODA software needs to be present in the AUTO folder to make it work.
Prior to this I built an RSVE board (also designed by Harun Scheutzow, and downloadable from his website) which speeds up the existing serial port of the STe. I probably etched the PCB myself, as it being a small and simple. It too needs the HSMODA software to work.
Back in the day I used a variety of US Robotics "Sportster" modems (14.4K, 28.8K and finally a 56K and can't remember having any issues with them). I'm pretty sure the RSVE modification was present at the time.
Truth be told though, I haven't really put the ST_ESCC to use. I just thought it was a smart upgrade to get at the time, but have no experiences with it other than testing to see if the ports would work (they did).

I never thought about the advantage to having the upgrade for use with the C-Lab "Export" (which I also have), but these upgrades might prove to be invaluable as my STe will be used mainly for MIDI from now on. I also have C-Lab's other MIDI expansion devices (Unitor 2 and Log-3).
Has anyone actually tried it with an RSVE modification (or via the two additional ST_ESCC ports) and noticed any difference? I'd try it myself if my STe wasn't disassembled (to be upgraded/serviced) and my Mega STe is still in a repair state.

Oh, does anyone know what RSFI is?
On Harun Scheutzow's website, scrolling down to the section for the RSVE section it says:

RSVE
RSVE - the hardware to speed up the MODEM1 serial port of Atari ST, STE, MegaST, MegaSTE and TT to 38400 and 57600 (and with good luck 115200) bps while still keeping the old data rates. Hint: RSFI is much better.
Download RSVE_GE.LZH (25 KByte)

No web search has turned up anything useful on "RSFI".

[Foxie]

What a lot of people seem to overlook is the ST's modem port can actually go up to 307.2k baud without modification!

Of course servicing the serial port at this speed will suck your processor dry. But if you use a polling scheme instead of interrupts, you can do it. It really depends how the MIDI sequencer is designed.

The big catch is that when operating at such high speeds, the serial port cannot accept any input. It's an output-only port. Well, that's not *strictly* true. If your input were somehow able to be synchronised with the MFP's clock, then you would be OK. But in practice that's not possible. Another downside is the baud rates are funny. 76.8k, 102.4k, 153.6k and 307.2k. Good luck finding a device that will accept those rates.

For MIDI output it's interesting. I'm designing a MIDI interface device which connects to the modem port and gives you four outputs. You should be able to get nearly full bandwidth on all four ports at once. The downside? There's no drivers for Cubase or anything else yet! There's a thread about that problem here: viewtopic.php?f=111&t=32977

Simply cranking up the serial port rate is no good by itself. You need special hardware like a specially designed MIDI interface device attached to the modem port to make use of it. Export simply won't work with these higher baud rates.

The reason Export performs so badly is because it's a bit of a fudge. It sets the modem port to 31.25k baud (same as MIDI), and squirts MIDI data out. Export then relays this to one - and only one - of the MIDI ports, unchanged. Export has literally no intelligence at all, it's £0.50 worth of parts. It's more like a simple cable than a MIDI interface. That's fine for driving a single port - it will give you full bandwidth just like the built-in Atari MIDI ports. Contrary to popular belief, it doesn't matter which single port you use either. But if you drive all three ports at once, Notator or Cubase will switch between them rapidly. It sends one MIDI event at a time to each port. Transmission on port 1 has to complete before it can start on port 2. It's completely unable to transmit events simultaneously out of all three ports - it has to time-share. That means your bandwidth is cut into a third! It's no better than using a MIDI thru chain.

An intelligent interface running at a very high baud rate can get around those problems. But a special driver is absolutely essential - and therein lies the problem.

If I do manage to crack the driver problem, I'm also interested in the printer port. There's a tremendous amount of bandwidth available there. You could drive 10+ ports without any lag.

[charles]

midi is meant to be its own speed , isn't it technically set to 31 kps for a reason?

[Fujiyama]

For MIDI output it's interesting. I'm designing a MIDI interface device which connects to the modem port and gives you four outputs. You should be able to get nearly full bandwidth on all four ports at once. The downside? There's no drivers for Cubase or anything else yet! There's a thread about that problem here: viewtopic.php?f=111&t=32977

Wow! That's indeed very interesting.
I don't have any experience with Cubase, being a Notator user myself, but it appears that with Cubase there are separate drivers for each hardware but with Notator there isn't and has to be supported in the actual Notator/Creator software. Does this mean that if you do succeed with the Cubase drivers there still won't be any hope for improvement for Notator users using that 4-port MIDI interface of yours?
Or can drivers be put in the AUTO folder which "talks" to Notator/Creator which would make this possible?

Simply cranking up the serial port rate is no good by itself. You need special hardware like a specially designed MIDI interface device attached to the modem port to make use of it. Export simply won't work with these higher baud rates.

So improving the serial port with an RSVE or similar won't make any difference and is a waste except if a modem is to be attached to that serial port as well? This is probably one of those situations when "if it sounds too good to be true it usually is".

The reason Export performs so badly is because it's a bit of a fudge. It sets the modem port to 31.25k baud (same as MIDI), and squirts MIDI data out. Export then relays this to one - and only one - of the MIDI ports, unchanged. Export has literally no intelligence at all, it's £0.50 worth of parts. It's more like a simple cable than a MIDI interface. That's fine for driving a single port - it will give you full bandwidth just like the built-in Atari MIDI ports. Contrary to popular belief, it doesn't matter which single port you use either. But if you drive all three ports at once, Notator or Cubase will switch between them rapidly. It sends one MIDI event at a time to each port. Transmission on port 1 has to complete before it can start on port 2. It's completely unable to transmit events simultaneously out of all three ports - it has to time-share. That means your bandwidth is cut into a third! It's no better than using a MIDI thru chain.

I had no idea! These add-on boxes cost quite a bit back in the day and I would never have imagined it working that badly. So it all boils down putting it to use in a smart manner: resisting to use all 3 ports and instead just settle on one additional OUT from that expansion box.
Fortunately I also have a Log-3 and Unitor-2 (and with such a setup Notator doesn't even use the Export but re-routes its output to the Log-3. But Notator Logic (which I also have, because of the built-in dongle found in the Log-3) takes advantage of the Export).

I'm glad someone's looking into improving the MIDI side of the ST and addition to all the other hardware advancements we've been getting lately. I just hope it'll be of use to Notator/Creator users as well

[arf]

Hi everyone,
[…] It also mentions that higher modem speeds are impossible without an accelerator.

I have two questions if anyone is able to help:

[…]

2) Will a serial port enhancement to add additional midi channels to the ST require hardware acceleration in order to perform without excessive latency?

I can’t comment on the usage as MIDI channels, but if you want to achieve more than 38k4, you need a) HSMODA, b) software that makes use of HSMODA, or b) an improved serial controller with FIFO "cache", or c) CPU acceleration.

Best is if you combine all options. See the docs of HSMODA.

[charles]

I think its the cpu speed you need to improve .
midi side of things is ok .
so double clock the cpu and viola ! ???

[Foxie]

midi is meant to be its own speed , isn't it technically set to 31 kps for a reason?

That's true, which is why Export can't work at the higher baud rates. It would produce a too-fast MIDI stream which no synths could understand! You need an "intelligent" interface which can receive the data at high speed into a buffer. Then it trickles the data out slowly to the MIDI ports at 31.25k. The advantage is you have plenty of bandwidth to drive four ports at once. Export can't do this - it's really just a straight-through connection between the MIDI port and the modem port.

If you want MIDI input through the modem port too, good luck. You could either use a MegaSTE/TT/Falcon which can accept input at high speed no problem. Or you could do a modification to the serial port hardware. Lots of different options there, some good and some not so good. The most common modification overclocks the chip when going to 115.2k. Like all overclocking, it may be hit and miss. The MIDI interface device I designed does allow a MIDI input - if you have the necessary Atari hardware to handle it. Drivers are another matter entirely.

Funnily enough, the interface will also work on an Amiga, classic Mac, or a stinking PeeCee. The advantage with the modem port is a wide range of software support on different platforms. I implemented a handful of different protocols in the firmware and use a DIP switch to select which one to use. You can even emulate an Export if you want universal software support and wobbly timing!

Printer port is trickier. There are no well-defined protocols. The difficulty is handling two-way communication - if it were MIDI output only or MIDI input only it would be easy. I think I have a protocol in mind but it needs a completely from-scratch driver.

Does this mean that if you do succeed with the Cubase drivers there still won't be any hope for improvement for Notator users using that 4-port MIDI interface of yours?

It becomes much more difficult, but it may be possible to patch Notator to support it. In some ways it might even be easier than working blindly with MROS/Cubase drivers because it's all self-contained. When I disassembled one of the Cubase drivers, the biggest problem I had was figuring out how it was talking to MROS.

One potential problem I see is protection. If the software has sophisticated anti-cracking measures, it might reject any attempt to patch it. It depends how insane they were with protection. A simple dongle check is OK, but a constant memory checksum and other countermeasures would be a nightmare.

So improving the serial port with an RSVE or similar won't make any difference and is a waste except if a modem is to be attached to that serial port as well? This is probably one of those situations when "if it sounds too good to be true it usually is".

Sadly, that is the case for Export. However, a faster modem port would be useful for the interface device I designed - if you had drivers for it. You wouldn't gain anything in terms of outputs (the unmodified ST modem port is plenty fast enough for four output-only MIDI ports) but you would gain an extra MIDI input. The unmodified ST's serial port can't accept a MIDI input at all.

These add-on boxes cost quite a bit back in the day and I would never have imagined it working that badly.

It's pretty shocking really! It's the so-called "pro audio tax" at work. Export could have been so much better if they had stuck a microcontroller in it, and a RAM chip for a buffer. Even in the 90s you were only talking £20 extra in parts. Unfortunately that's £19 more than the Export's parts!

That's pretty much what I've done with my interface - except I don't need a separate RAM chip. Technology has moved on since the 90s, and you can now get big enough RAM capacities on a single microcontroller to do the job.

Fortunately I believe Log3 and Unitor do contain microcontrollers and buffers. Being cartridge port devices means they can't deliver an interrupt. That may or may not adversely impact performance, depending on how Notator is designed. I can't remember hearing about any timing accuracy problems with Unitor so I guess it's OK? I've heard some complaints about Midex. Also, I hear Midex has some issues on the Falcon. I don't really know why.

If possible I'd like to steer clear of the cartridge port when designing a new interface device. Mainly because it's a place for dongles, and you definitely don't want to interfere with the operation of those. If this were the 90s and I were designing a commercial sequencer, I'd surely have a cartridge dongle with a built-in 8 in/out interface. The concept of a dongle is much easier to swallow when it also does something useful!

So it all boils down putting it to use in a smart manner: resisting to use all 3 ports and instead just settle on one additional OUT from that expansion box.

That's pretty much it. You can use all three ports at once, but keep in mind it will be no better than having all three synthesisers on a single MIDI thru chain. So don't try to hit them all at the same time with lots of data.

Back in the day it was quite popular to build a modem-to-MIDI cable using one resistor and one diode. The same cable would also work on an Amiga, but not an IBM because it can't set the baud rate to 31.25k to be MIDI-compatible.

I think its the cpu speed you need to improve .
midi side of things is ok .
so double clock the cpu and viola ! ???

That's probably true of general TOS stuff like terminal programs and web browsers. MIDI sequencers are a slightly different beast. They tend to take over the system more aggressively. Some will use fast interrupt handlers, others will poll. With those, you can easily achieve higher speeds on an 8MHz system.

There are basically two concerns with high baud rates on the ST. The first is that you need an interrupt for every byte. Interrupt handling takes some time - if you're running at 307.2k, the interrupt rate is 30kHz. The machine will *very* significantly slow down when handling that much data continuously - even with a fast interrupt handler. Think of what happens when you play a sample at 30kHz on a standard ST (not STE). My guess is that TOS does not have fast interrupt handlers, and it will completely grind to a halt. At this speed, it's better to poll than use interrupts - requiring a redesign of the software.

The second is that you need to avoid masking interrupts for too long. I'm not sure what TOS and GEM do in this regard. I noticed accessing the disk causes the interrupt mask to be changed - so I'm guessing other parts of TOS also need to mask them. Evidently, TOS is able to handle 31.25k comfortably from the MIDI ports. So we know that TOS never masks interrupts for more than 0.32ms. But at 307.2k, you need interrupts to be masked for less than 0.03ms.

The danger with masking interrupts for too long is that received data may be lost. If you're only outputting data (like MIDI), you don't have this problem.

[charles]

well said foxie ,
we need these functional to sell for next year ,,lol kidding
that's a huge task you've set aside for yourself , hope all goes well

and if you have time im interested in learning about a vertical blank timer to use in my sequencer/playback routine
u breifily hit on in one of your previous posts

[Miguel]

Yeah I knocked up a cheap modem-to-MIDI cable because as Foxie said the Export was only ever decent at using a single output anyway and of course to achieve the same functionality as provided by the expensive Export you are better off just getting a decent MIDI expander, I mean why have 3 rubbish outputs when you can have 4 or 8 that you can use for switching patches on effects units or whatever.

The other thing I built was an adapter to separate the Atari's MIDI out and MIDI Thru, the advantage of which is not monitoring your playing using the soft MIDI Thru which adds about 2ms of latency over using the hardware MIDI Thru. The main advantage of the Atari is actually it's input latency because that's something which can't be compensated for by time stamping protocols such as LTB which sends MIDI data ahead of time from the sequencer tracks of Cubase to the more modern discontinued MIDEX interfaces.

[Foxie]

that's a huge task you've set aside for yourself , hope all goes well

Thanks ^.^

and if you have time im interested in learning about a vertical blank timer to use in my sequencer/playback routine
u breifily hit on in one of your previous posts

I'd strongly suggest considering using one of the MFP timers instead of the vertical blank interrupt, if you can. The vertical blank only happens every 20ms, which will cause really bad jitter on your MIDI events. It's OK for MOD playback because the tempo is synchronised to a multiple of the framerate, but with MIDI you don't have that guarantee.

Vertical blank music is probably more useful for games and demos, where you're too busy during active scan to do anything else.

The simplest way to get periodic interrupts is to set timer A to 0.3ms period. That's frequent enough to catch MIDI bytes by polling, fast enough for acceptable jitter and slow enough not to completely hog the processor. You need to put the address of your routine in the longword at $134. Then you set timer A data ($FFFA1F) to $C4 and timer A control ($FFFA19) to $01. Then you can enable the interrupt by setting bit 5 in $FFFA07 and $FFFA13 (don't change the other bits). At least, that's what I recall - let me know if it doesn't work!

The other thing I built was an adapter to separate the Atari's MIDI out and MIDI Thru, the advantage of which is not monitoring your playing using the soft MIDI Thru which adds about 2ms of latency over using the hardware MIDI Thru.

Have you actually measured the 2ms figure? I've never done any measurements on Cubase or Notator, I'd like to set up a test rig some time. I've heard it said that it's "tight to 1ms" but that doesn't sound very scientific to me. Also 1ms isn't very good by MIDI standards anyway.

In theory the software MIDI thru delay could be as low as 0.3ms. But the software has to go to great lengths to achieve that - merging and routing data byte-by-byte rather than event-by-event. The next level up is working with whole MIDI events, which gives you about 1ms latency. If it's higher than that, I would guess some sloppy programming comes into play. Perhaps it has a 2ms timer running and only forwards events on each timer clock? Or perhaps the 8MHz CPU is just too slow to run the code any faster (which I assume was written in C).

If I get around to making a sequencer, I'd want it to be tight to much less than 0.3ms - and with a MIDI thru delay of 0.3ms also. That's really going to take a lot of work, but I don't think it's worth making a new sequencer unless it performs to a high standard. I'm not totally sure what the limits of the human ear are, but I've heard it said that you can hear jitter of 0.5ms. I can also feel a latency of about 1.5ms, but jitter is more disturbing than latency.

The main advantage of the Atari is actually it's input latency because that's something which can't be compensated for by time stamping protocols such as LTB which sends MIDI data ahead of time from the sequencer tracks of Cubase to the more modern discontinued MIDEX interfaces.

Yeah, USB is a complete catastrophe for MIDI. I had a glimmer of hope that MIDI over Ethernet would take off. It's supported natively in OS X. But it seems nobody is really interested, and I doubt the driver stack is very fast anyway. For accurate performance, nothing beats an Atari ^.^

Latency problems in software have got so bad now that Firefox can't even handle my typing in real-time. That's a latency of about two seconds! My iPad often does the same thing when using a bluetooth keyboard.

[Miguel]

Yes Foxie I actually measured the 2ms latency between the Atari's MIDI Thru port and the Atari's MIDI Out port (using soft MIDI Thru) by hooking up two identical Akai S2000 samplers to each port on the Atari and each audio output to a DAW for comparison.

USB is not very good at all for MIDI input however like I said it is possible to get really good timing by using a MIDI time stamping to send pre-recorded MIDI data ahead of time for release by dedicated hardware, that's how Cubase's LTB works with the MIDEX8 interface, Logic's discontinued AMT protocol with the old discontinued Unitor8 which has now been replaced with MOTU's MIDI time stamping protocol under Core MIDI when using one of MOTU's MIDI interfaces....you have to pair the protocol with it's dedicated pre-buffering hardware of course or there is no advantage....the point being such protocols really can compensate for the sloppiness of USB to a point where it can be comparable to the MIDI output of an Atari ST but of course where the modern computers actually fall down is in the recording and monitoring from the MIDI Input.

[guus.assmann]

Hello,
Would a Steinberg Midex+ interface do the right job?
As it happens, I do have a lot of data on that.
There's the schematic diagrams, GAL files and data for the modification. (Originally the Midex has PAL's)
And there's a document for a Falcon mod. (That I've not tried yet)
Also, I have test programs.
For one, it's possible to (re)make the midi-ports and SMTP-bit. (Skip the Dongle ports)
If this helps, let me know and I'll send the stuff. (PM-me-too )
All data files are too big for upload to this forum.

BR/
Guus Assmann

[Foxie]

Yes Foxie I actually measured the 2ms latency between the Atari's MIDI Thru port and the Atari's MIDI Out port (using soft MIDI Thru) by hooking up two identical Akai S2000 samplers to each port on the Atari and each audio output to a DAW for comparison.

Interesting! Did you measure the latency of the S2000 by itself? I've got an S3000XL and an S6000, and they "feel" extremely quick to me. Noticeably more responsive than say a JV1080. I've not measured them though. Also, did you notice any jitter in the MIDI thru delay? This could reveal something about the inner workings of Cubase.

A MIDI event takes 1ms to transmit in full, so if Cubase buffers up an entire event before it can forward it then it will add an extra 1ms at minimum. I wonder where the extra 1ms is coming from if it's not the MIDI event transmission time itself? Have you got a faster Atari to test on, in case the slow processor is a bottleneck?

USB is not very good at all for MIDI input however like I said it is possible to get really good timing by using a MIDI time stamping to send pre-recorded MIDI data ahead of time for release by dedicated hardware, that's how Cubase's LTB works with the MIDEX8 interface,

I think it's a terrible shame that nobody makes an interface with firmware MIDI thru and input timestamping. You could make the interface route MIDI thru data and merge it with MIDI out data, all with excellent performance. It wouldn't be that hard, since a timestamping MIDI interface already has the needed hardware for the job. It just needs some extra code. I guess the problem is you'd need to integrate support deeply into every sequencer. The sequencer would need to tell the interface which track you've selected and therefore which input+channel to route to which output+channel. You'd also need to tell it whether the track has an active transpose. Not really sure if a third-party would ever be able to get enough support of sequencer manufacturers to implement a feature like that. Though don't MOTU have their own sequencer?

If I recall correctly, MIDI over Ethernet has time stamping for both input and output. But no MIDI thru support.

Hello,
Would a Steinberg Midex+ interface do the right job?
As it happens, I do have a lot of data on that.
There's the schematic diagrams, GAL files and data for the modification. (Originally the Midex has PAL's)
And there's a document for a Falcon mod. (That I've not tried yet)
Also, I have test programs.
For one, it's possible to (re)make the midi-ports and SMTP-bit. (Skip the Dongle ports)
If this helps, let me know and I'll send the stuff. (PM-me-too )
All data files are too big for upload to this forum.

I'd be *very* interested in this! Is there enough detail to build a Midex clone? Or implement support for Midex in a new sequencer?

Not sure how good the performance of Midex is. I heard some complaints about it, but in theory it should be able to deliver OK performance since the bandwidth is high. Looking at the schematics and firmware might help answer that question. ^.^

[guus.assmann]

Hello Foxie,

The full schematics in a four sheet PDF, sometimes a bit hard to read, but ok.
And the Jedec files for the main GAL, as well as the data to create this GAL. (20V8)
And the Jedec file for the SMTP-Gal, a 16V8
So in my opinion, enough to recreate a Midex+ expander.
Just let me know an E-Mail address and I can send the stuff, so you can see for yourself.

BR/
Guus

[Foxie]

Hello Foxie,

The full schematics in a four sheet PDF, sometimes a bit hard to read, but ok.
And the Jedec files for the main GAL, as well as the data to create this GAL. (20V8)
And the Jedec file for the SMTP-Gal, a 16V6
So in my opinion, enough to recreate a Midex+ expander.
Just let me know an E-Mail address and I can send the stuff, so you can see for yourself.

BR/
Guus

Thanks very much! I've PMed you my e-mail address ^.^

[edingacic]

Wow, nice Foxie. I have TT030 with Midex+ and Sound Pool Mo4 if you want I can do some tests for you as far as timing you are talking about but you need to give me some direction and tools how to do that. After reading everything that you have mentioned in your responses what I think you should look at is the Friendchip MM1 MIDI interface. I am looking for one it is a unicorn to find but I know the guy that has one and could possibly take pictures of the inside... there is a driver for Cubase and maybe is better to clone that 1:1 as i heard is the best device there is for ATARI but that is just what I heard from few musicians. Here is the picture he took and I posted in wanted section http://www.atari-forum.com/viewtopic.php?t=32207

I think there is a big need for a device like that. Anyways let me know if I can help in any of your latency testings on my TT030. Thanks for doing this!

[Foxie]

Wow, nice Foxie. I have TT030 with Midex+ and Sound Pool Mo4 if you want I can do some tests for you as far as timing you are talking about but you need to give me some direction and tools how to do that.

Thanks! If I can figure out how the Midex interface works from a programming perspective, I'd definitely be interested in whether some test programs will run on it. I've got the schematics of the Midex now, and it looks quite simple actually. It should be possible to support it natively in a new sequencer, and also should be possible to build a clone that works in Cubase.

Interestingly, it looks like the Midex has the potential to handle four MIDI inputs. They just haven't wired them to anything! With the necessary driver modification (could be difficult) and a very minor hardware mod, you could get two extra MIDI inputs from it. If I build a Midex clone, I'll definitely include the extra two MIDI inputs in case software support is possible in the future.

After reading everything that you have mentioned in your responses what I think you should look at is the Friendchip MM1 MIDI interface.

This looks like a very interesting device! Are the 8 MIDI sockets all outputs? Does it allow for any kind of MIDI input?

If you know where to find a Cubase driver for it, I could perhaps reverse-engineer the protocol it uses and clone it.

I can see really three options for building a printer port MIDI interface:

1 - Make a clone of the Friendchip (8 outputs?),
2 - Make a clone of the SMP24 (2 inputs and 4 outputs),
3 - Make something completely original and write drivers from-scratch for it.

I already have in mind a hardware design and protocol for option 3. I know nothing about the protocol used by 1 and 2, so it depends on reverse-engineering. The SMPTE reader of the SMP24 complicates things.

With option 3, the device I have in mind would give you 8 outputs and 6 inputs. It would also be possible to daisy-chain a second device for another 8 outputs and 6 inputs. The cable length needs to be kind of short though, so I don't think making it a rackmount interface would be a good idea. Better to have a small box that sits behind the ST.

Hardware-wise, I'd use 8 microcontrollers - one for each port. And three TTL chips to buffer the parallel port. That's about it really - quite simple and cheap hardware. All through-hole parts that anyone can solder easily.

An output-only device like the Friendchip might be even easier and cheaper to build. Might even be possible to do it with one chip! But does anyone want extra MIDI inputs? I find that's a limitation on a standard 1040ST. I don't mind using a MIDI merge/switch box for most MIDI sources, but I'd want a couple of keyboards connected directly to the ST without the associated latency of a merge box. Then again, maybe that's where a Midex clone comes in handy.