After having found out how I can make my vintage 1981 Busch 2090 microcomputer board output a program from memory to the 2095 cassette interface board I was hoping that the knowledge I had gained during the process would help me to reach my ultimate project goal which was to send a 2090 program from a Raspberry Pi via its GPIO ports to the original microprocessor board so I can execute it there. At the beginning it looked like a straight forward process but one thing kept me on the edge for quite a while.
The Story So Far
To quickly recap, I was doing this project because I didn’t have a 2095 cassette interface board and they are very hard to get on eBay. Also, I didn’t have a protocol description so I depended on experiments to find out how the interface works. Earlier I found out that the 2095 interface board generates all signals required to make the 2090 output the content of the program memory to the OUT1 pin. My working assumption was thus that a similar process would work for the reverse direction as well.
And Now The Conclusion
After a bit of experimenting I could confirm my theory. Like in the reverse direction, setting OUT3 from the Raspberry Pi’s point of view (IN3 from the 2090 point of view) starts the transmission of one instruction. Each instruction has a length of 3x 4 bits = 12 bits. Equally like in the reverse direction, the bits are sent on OUT/IN1 and the clock for each bit is sent on OUT2. At the end of the procedure all OUT/INs are set to 0 again and one can see the OUT LEDs on the 2090 blink for a fraction of a second while the 2090 writes the received nibbles to the external memory. Everything looked like a home run at first…
A Random Gremlin Creeps Up
Unfortunately I had to notice soon that I occasionally got transmission errors and an instruction received on the 2090 would be wrong. The issue was seemingly random as sometimes the program would be fully correct while during subsequent program downloads some instructions, always at different places, would be wrong. Quite frustrating. At first I thought that perhaps I was looking at a timing problem with the clock signal so I experimented for a long time with increasing and decreasing the times the different signals were set to high and low. No change, random errors still crept up from time to time. Then I thought that perhaps the time between two instructions might be too short and that the 2090 wouldn’t have enough time to write the received instructions to its external memory. So I increased the time between the transmission of two instructions but this also didn’t help. At some point I had to give up and sleep it over, which sometimes helps.
Day 2 With New Ideas
The next day I started experimenting with characteristic bit sequences such as AAA, 555 and 123 and quickly found out that some bit sequences produced errors more often than others. Especially those with the first bit of the transmission set to 1 failed more often than others. What was even more interesting was that they always failed in the same way, the first bit was always missing, i.e. the 12 bits where left shifted by 1. In other words if there is an error it is caused at the beginning of the transmission of the 12 bit instruction from the Raspberry Pi to the 2090. This is when I realized that perhaps there is no need for a clock signal on OUT2 for the first bit as the start of the transmission is signaled on OUT3 as well. So I modified my code to skip the clock tick for the first bit. Instantly everything became rock solid, I haven’t seen a single transmission error since. You can imagine my sigh of relief…
The Need For Speed
Now that the transmission errors were gone I became adventurous again and started experimenting on how far I could push transmission speeds. When a real tape interface board is used the transmission speed is 14 baud, i.e. 14 bits a second which is around one instruction a second. Things remained stable in my setup right up to around 84 baud, i.e. around 7 instructions per second instead of 1. That significantly reduces the time it takes to download a program which is especially useful for larger programs which would otherwise take several minutes to download from a real cassette tape.
Programs, Programs, Programs
Finally, I had a stable download mechanism so I went ahead and ran quite a few of the 2090 programs Michael Wessel has scanned in, digitized and put on Github here. Great stuff!
Everything On Github
In the meantime I’ve put the thoroughly commented code, pictures of the setup and the schematics on Codeberg. Enjoy!