As I said in the previous post, the 2.8” touchscreen is too small. And its resistive touch isn’t responsive enough.

On the picture below the top left one is the “old” 2.8” resistive touch display.

So I had to test new capacitive touchscreens : 

• 2.8″ 320*240 pixels, ratio 4:3 (bottom left)
• 3.2″ 320*240 pixels, ratio 4:3 (the one in the middle, fitted into my MicroDexed Touch)
• 3.5″ 480*320 pixels, ratio 3:2 (right)

To give an idea of the pixels gained with the 3.5” resolution 480 * 320 compared to the 320 * 240 pixels : 

After a little poll between us, we decided to go bigger. So I bought a 4″ capacitive screen (480*320 pixels, ratio 3:2) to have more space. The code for this new type of display needed new libraries for the new drivers (ST7796 for display and FT6206 for touch) and some rewiring. Fortunately Paul had anticipated everything and exposed pins for both the microcontroller and the display on the PCB so it was an easy fix.

This time the display was too big to fit between the encoders, so I desoldered the left encoder…

Now we have a comfortable display, with responsive touch

To be continued…

David

When we started assembling our Zyklus clones, we realized how complex it would be to upgrade the hardware (based on a Z80) and the software written in assembly language.

Just take a look at the PCBs needed for the ReZyklus :

Especially since we couldn’t find the toolchain to compile the old assembly code for rewriting EPROMs. So, the idea quickly emerged of perhaps developing a V2 based on modern, simplified hardware and a software layer that was easy to write, compile, and maintain.

After much discussion and experience with other projects, we chose the Teensy 4.1 microcontroller.

At the end of 2024 I spoke about this V2 with Paul, our electronics wizard. Rather than embarking on “spaghetti” breadboard projects, I suggested building a prototype PCB to validate the hardware choices and confirm that we could indeed achieve our desired functionality. Paul recommended using the HT16K33 chip, which can scan up to 39 buttons in a single scan and control up to 128 LEDs. So the prototype PCB includes:

• a Teenzy 4.1 microcontroller
• a HT16K33 chip
• a 2.8″ resistive touchscreen
• three rows of eight buttons, each associated with an LED
• two rotary encoders
• two MIDI IN and two MIDI OUT ports
• a buzzer
• a footswitch jack input
• a jack input for an external clock
• a USB host port

I ordered the PCBs and here’s what it looks like :

After soldering the components and writing some code to test them, it immediately becomes much more enjoyable

Here I used the same “vintage” buttons as on the ReZyklus V1.

But then I realized that a 2.8″ touchscreen was really small, and the resistive touch wasn’t very responsive. So I looked for another solution.

To be continued…

David

First, I masked the outsiude of  the  viewport on the frontside:

Using this, I could mask the actual viewport on the inside, leaving out the part that needs to be matted:

Add a shitload of black matte paint (quick drying)

And presto:  Came out pretty good – maybe a tad too much on the far right side.

https://github.com/jeroenhn/zykl

Thanks so much to Pete and Bill for allowing this project to go this far.

Now go ahead and make your own!

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.

In essence we could now release everything as open source, where people can build their own and run it on the old MPS-1 software.

But wouldn’t it be nice to have the ReZyklus variant of the software?
I managed to find a linker and now I can build the whole code base as originally given to me. The problem is that the resulting EPROMS don’t actually run the machine. There are some variations in the main EPROM that are likely the result of further untested development when they were working towards V 1.3.  This is a bit of a puzzle obviously, but one I’m convinced I could nail using modern debugging tools and creating an emulator in Python.

To be continued.

The bank eproms also build and EPROM 2 actually runs….

• 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.

Now I can build new EPROMS and burn them, but the better and quicker way, I thought, would be using EPROM Emulators so I can upload the bin files quickly without spending time burning, erasing, burning etc.

First try:
I can emulate EPROM 0 without a hitch, the machine boots. including the others though, not so much. Not sure what is going on here.

For funsies, here’s a picture of the setup:

Second try, I can run on EPROM 0 and 2 emulated, so I’m thinking that one of the emulators is borked.

to confirm, I use 2 to emulate 1 and that works too.

Now I use the old 1 to emulate 2 and all of a sudden all three work.

Eh. Weird stuff. Oh well, now I can focus on building the new binaries! Yay!