The original had 3x 5V and 1x 12V out. (still haven’t taken the time to figure out where the 12v is for but that will come later)

Thankfully I had a Mean Well switching PS around and Paul mentioned to me that it would easilly do so I set out to replace the old PSU with this one. Cleaned up the connectors as well, where originally the lines were directly soldered to the mainboard.

The new PSU is autoswitching, so the voltage selector is now disonnected.

A few caveats came into play.

The original code did a dual check to see if a card presented indeed contained a valid OS.
it looked for an OS string and calculated a checksum. After some poking around and creating a modified bootloader rom, I discovered that the OS label was valid, but it always failed on the checksum part.

I now worked out how that worked and how I can create a full OS EPROM that validates both checks, but it took a lot of back and forth between adjusting the bootloader code, burning EPROMS and re-check. For now I’ve opted to completely hack out the checksum code – I’ll add it back in later as for now I want to focus on a good quick OS improvement workflow.

A few things on my todolist:
Right now I’m relying on my very old XP pc to run the build, as the compiler is DOS based.
I want to see if I can get that to work on an XP emulation on my mac. XP is already running, but getting a shared folder seems to be more involved than expected. Dosbox-X may be an alternative.

A lot of the functionality is pretty straight forward and I got it mapped out, but some pattern / sequence related stuff threw me for a loop.

My experiments often resulted in weird sounding sequences where I would expect things I had entered in the machine. It dawned on me that maybe the workspace region memory was having issues. So I swapped the old, stacked IC’s witih a couple of fresh ones in the correct size.

This stacking was done with smaller capacity ICs to create one unit in the correct footprint, presumably back in the late 80’s, the correct sized IC’s were not available or extremely expensive. I now have a box full  of ‘m for a few bucks, so I swapped them.

And indeed it seemed to fix a lot of issues.  Next up will be replacing the OS memory, but before I do that, I want the melcard stuff working,  so I can dump and load via card (and check the correct content).

Another thing is to extend the programming. This version has a ton of stuff in it, but error handling can be improved. There are a lot of things that don’t give complete feedback or in some cases, nothing at all. I’ve made a list of which I want to add. This will all become release 1.8.

• Replace all tantalum caps
• Create a better solid power supply
• Get the MELCARDS working and create a MELCARD writer to connect to USB
• Write a manual
• Create a schematic of the whole hardware
• Do some bugfixing and perhaps some feature building

I’m also desperately trying to reseach all I can on the Transposer module that was part of “Direct”.  Together with PaulMC we’re trying to create a new variant of sorts that looks like the original. I have some info on what it was supposed to do. Ultimately, it would be amazing if I ever could analyze and describe one of the originals.

It was hard to find, but I managed to find a picture showing the original box:

It uses the same midi and jack connectors as the Zyklus MPS.

So I set out to create my own box. Got myself an empty enclosure with an ALU frontpanel and started drilling:

Didn’t look particulary neat, so with the help of Paul, started mucking about in KiCad and designed a proper panel.

One week later, this is the result. At some point I will have to create a revision of this, as there is also a MIDI Clock in and out and the panel is slightly too small, but for now it’s fine.

The PCB Paul created for the memory card came in. It’s again a work of art….

I’m going to arrange for a company to map out the old memory card connections towards the IDC. The pins are too thin to measure by hand, at least for me as I keep touching other pins.

Hopefully I can get them to create a new wire harness for one of the EMU Proteus MPS card slots I got from Syntaur. I want to use the other to create a card programmer.

I’m waiting for a delivery from JLPCB for a front panel for the MIDI stage box I’m building, that will hold all the midi ports and some other stuff.

And I *may* have a lead on a more recent software version, but that is a big ‘if’ and kinda involved. But here’s to hoping.

On another note, Bronswerk – the Zyklus Improviser creator – came over last weekend for a Direct & Vangelis geek-out. Fun times!

There were a few issues trying to get it to this point:

• There was a short on the newly soldered joints for the replacement button panel, which caused Track and Thru switch 4 and 5 to trigger simultaneously.
• The OS loaded, but right after reboot, it reported that there was no OS.

The system has a few hidden key combos for various functions. If you hold track key 8 while booting, it will skip the OS checks. The OS checks in this case are twofold: a checksum on the entire OS in memory, and an OS ID that needs to be found at the beginning. I didn’t know which of the two checks failed, because there is no feedback.

Since I had a working compilation workflow, I decided to rewrite that section of the EPROM slightly and make the beep for the checksum failure higher in pitch so I could tell which check had failed. It turned out to be the checksum.

Another key combo is holding 1, 3, and 5 while starting. This formats the Data Region memory and initializes all the constants and variables there. Without that, the OS can’t function properly and shows E11. Because of Issue #1 (which I hadn’t yet discovered—we initially thought it might have been a design flaw in the new board), I decided to change that key combo to just key 1 and recompile the OS, as that part was not in the EPROM but rather in the actual OS code.

After that change, it did format, and the system booted. I then installed an EPROM booter that skips the checks altogether while I figure out what’s going wrong with the checksum at a later point.

With those changes, the machine ran fully. Yesterday, I set out to figure out what was wrong with the panel. I think I spotted a solder joint touching another, and after some tweaking, the panel behaved as it should. One problem fixed.

I also started working on the breakout box. This proved to be more challenging than I expected, as drilling the holes through the aluminum panel of the little box I bought did not end up very neatly at all. So I’ll design one in KiCad and have it made by JLCPCB. The second issue was the crimp connectors for the EDAC connector. They were massive and didn’t fit my tool at all. Using a vise wasn’t working either. So I placed a new order—this time for connectors with solder eyes. They should arrive next week.

But I still wanted to test Direct, so I jerry-rigged three DIN connectors and soldered them to the crimp connectors. If they’re not in the connector housing, I can stick them into the other side to make contact. It’s not very sturdy, but it will do for testing.

My first test was strange. While I could see something happening on the module I connected (specifically, a patch change when I used that function), there were no notes coming in.

After a lot of double-checking, replacing the optocoupler, and hooking up the scope, I finally discovered that one connection was broken on the case-side connector. It was miserable to repair, but I managed, and from that point on, everything worked!

Here is my to-do list for the remainder:

1. Design the breakout box panel and have it printed.
2. Finish the breakout box, including the foot switch connectors, serial port, and leaving room for USB as well.
3. Find out and fix the OS checksum check failure.
4. Map out the memory card connector. I got two replacement connectors from Syntaur (removed from an EMU Proteus MPS). Hopefully, I can have a company measure the connections and map out a new flat cable to make the Proteus connector work (it has enough pins; it’s just a matter of mapping them correctly). The pins in the connector are extremely small—one in the original is already damaged—and I don’t have the proper tools to handle it myself. I also don’t have tools to create flat cables, so I’ll outsource this. I now have two 32kb memory cards and one 128kb card on the way. Maybe I can get a company to create a small board that allows me to write to these cards over USB.
5. Install the new EPROM/memory card board, which should arrive this week. This will replace the hand-wired prototype board I made last week. I can use it together with my EPROM emulator.
6. Consider creating a PCB for the power supply. It works fine now, but it looks like it was done in haste back then, without a proper PCB.
7. Create additional hardware documentation. I’ve learned a lot about what makes this box tick and have collected many replacement ICs, including memory, DUARTs, CPU, etc.
8. Create a manual. There isn’t one, so it’s a matter of experimenting with it and reading through the code.
9. Inventory of bugs. I’ve already found a few. This was a very early code build, and there was a major rewrite after this version. I can’t reproduce anything done after this version—there’s nothing left of it—but perhaps I can develop some new ideas myself.
10. Have some fun with it!

With that, I’m leaving a standing invitation to the Powers That Be at the Vangelis estate: I’d be happy to refurbish the other machine as well. It likely wouldn’t take as much effort as this one.

This unit was deemed unfix-able in 2007, and indeed it probably was at the time. But thanks to the popularity of retro computing—along with sites like the Internet Archive and Bitsavers—it was possible to make it work again. It’s still not at the latest spec, but if that code ever surfaces, I’m confident it could work again too. Digging through archives, finding obscure data sheets on MELCARDs, and getting a different version of the linker/compiler tool chain to work were some of the more interesting and fun challenges. This box was destined for the scrap heap, but I’m glad it escaped that fate; at least one Direct can be preserved in working condition, a museum piece it deserves to be.

I want to add that I owe a major thanks to PaulMC, who helped me nearly daily on this project. He even found and fixed an original hardware bug in the machine! His help has been amazing, so thank you Paul!!

I’ll elaborate more soon on what the hiccups were, but here she is, running Version 1.7, which is actually 1.5 but slightly modified by me.

I can’t connect it yet to any keyboards as I’m still working on making the breakout box, but here she is, alive and kicking!

I fired up my old (I mean OLD – pentium 200 mmx) PC and installed the tool chain.

The compiler worked nicely and with the options found in the batch file, I noticed that it didn’t compile to OBJ format, but rather to assembly code, which then got compiled by the assembler into obj files.
The linker used a linker command file with memory layout options to then barf out one complete ABS file. The ABS file contains, besides the absolute addressing information, the hex file.

Now I have my own workflow for doing assembly, which I used to create my own ‘diag’ eproms. At first I tried to use m68k-elf-as but I kept running into all sorts of weird issues. Eventually, I opted to change to vasm which made life a lot easier. It enabled me, along with some other tools like srec_cat to create the ODD/EVEN eproms.

Today I set out to try to use the splitting and burning part of my tool chain, with the original code and compilers. I wanted to recompile the EPROM code which some OS checksum checks disabled to see if I could get it to boot directly into the OS entry point and hopefully use the predetermined key combo to clean the Data Region, which needs formatting (as the E11 error tells me).

In order to do this, I had to modify the compilation batch files, along with with some command options per line to make it work with the slightly newer version of the linker. In order to build my new EPROM, I needed everything compiled to OBJ files, because of external references in the PROM code that it needs to find.  After some hackery, I managed to compile the whole code base and link it using the memory layout options as detailed in the linker command file. I have two of these command files, one is for doing the EPROM only, the rest is for the whole codebase.

I then moved the resulting ABS file to my mac and pushed it through my split / burn workflow and 2 new EPROMS were born. Stuck in in the machine and the good news is, it booted as I expected, directly into the OS showing the E11 code. However, the startup keys to reformat the WS memory space didn’t work (reinforcing my believe that those RAM IC’s are toast, or at least one of them. If I switch them around, other unpredictable stuff happens. New ones are on order, I have to be patient…..).

I also did a full build on the codebase and compared the resulting HEX part of the ABS file with the HEX file I already have and it looks like it’s identical. So with that I can now fully build and rebuild the OS and EPROMs.

Paul was kind enough to create a little memory card board based on the prototype we made with a protoboard so it looks neat. These are being printed right now and should be here next week.

And finally, I had to tackle an issue with the metronome / system volume control. This potmeter had a capacitor and resistor soldered to the legs and they kept coming off. I created a tiny board of a piece of protoboard, laid it out on there and this will make it a bit more sturdy.

More to come soon…

• Use the MCL68+ CPU emulator.  This wouldn’t work out of the box, for the simple reason that the original CPU sits on one of those very expensive IC foots with turned connectors. You can’t stick a header pin in them. So I need to find some kind of (long) header pins that are small enough to fit in there.
• Use a memory card, as originally intended. Well, we don’t know the card, and we don’t know how to get stuff on there even if we knew.
• Use serial. This could work, but serial communication needs some kind of protocol. This would require a custom boot rom etc. Nothing too spectacular, but I’d consider this if all else fails.
• Use custom EPROM’s with the OS as payload. This was pretty much my first option, but I never got it to work.

So I set out to map out all the pins on the memory card’s IDC connector and trace them to the various endpoints. I also spent some time on google trying to learn more about these 60 pin cards that basically predates the PCMCIA standard. I found out that Hammond used these type of cards (in 32k format) as did EMU in their Proteus MPS. Finding a service manual of a Proteus MPS and having traced most lines from the IDC taught us that the connection is pretty straight forward:  16 Address lines, 8 data lines and some additional stuff. From the little hardware document that exists, we know that:

Access to the cartridge can only be made byte wise, on even byte
locations ( D8 - D15 ). 

With this we figured we could connect an EPROM to this. There were some card sense options that basically describes what kind of card sits in there. The code provided some insight. Thanks to Paul – who incidentally has been such a huge help in this project, I went on to build something on a protoboard with a header, ic socket, jumpers etc. Attempt 1 failed because I’m daft, but the second one yielded some interesting results.

Armed with a logic analyzer, when plugged in and using the correct OS Load procedure, I noticed a lot of traffic on the data lines:

This told me a few things, based on the original EPROM code the startup goes something like this:

•  Wait a few ms to settle the voltages
• check the RAM for a valid OS, it does this by checking an OS id and a checksum
• if either fails, sound the alarm bells (Buzzer ON)
• Wait until os load procedure starts
• When button pressed, check if there is a card, if that card has an OS ID
• If yes? Stop buzzer. Load OS into RAM
• Reboot.

Well, when I initiated the OS load, the buzzer went off. So it saw the card and recognized is as OS card. But after reboot, the alarm bells were back on.

So while data was being copied to RAM, it seemed that it didn’t stick in the ram. But that maybe a main board issue, not the cartridge we made!

I then remembered that there was an option to skip the OS check during startup by holding a button while turning on. I did that and to my surprise, the display showed E11:

This was big news. E11 is indeed a predefined Error code. However, that code comes from the OS, not from the boot eprom. Which means the OS is actually in memory! In this case, E11 tells me that the Workspace Data memory region, needs to be formatted. You could do that by holding a few other buttons during startup, but since the OS check fails, this never works.

So why does the OS check fail? That is hard to determine directly, but moving some memory IC’s around result in unpredictable behavior, so that tells me that quite likely, one or more memory IC’s are not that healthy anymore. I could write a bit of assembly code that does a bit-for-bit memory test and I might do that, but for now, I sourced a load of new memory chips and wait for them to arrive.

There is also a lot of TTL logic that helps with memory allocation (perhaps because they designed the system for growth, it can use various memory sizes) – and maybe one of those TTL’s has gone tits-up.  First I’ll try new memory when it comes in. The TTL’s are mostly not socketed, so when we have to come to that part of diagnosing, I’ll have to see if we can diagnose as much in circuit as possible. It was my original intention to socket all the IC’s, but the board is very fragile and de-soldering everything isn’t going to do it any favors, so I opted not to take that route.

So all in all, it looks like our pseudo memory card was a success! While I wait for new memory IC’s, I’ll turn my focus on building the MIDI breakout box.

Later on, since I now have a working Assembly workflow and better understanding on how the Odd/Even organization works, I want to recompile the original Bootrom from source, maybe take out some of the checks and see if I can force it to boot into the OS and force a Data Region memory format. Just in case it still goes nuts over the OS checksum.