Manchester encoding subroutines of the TRS80 MC10.

[Dukov Ahzrukhal]

Hello everyone, I've been working on an FPGA implementation of the TRS80 model MC10 computer. By now I have fully implemented and tested all the hardware on my FPGA board, and I can get it to run an unmodified copy of the TRS-80 ROM. The next part of the project is to replace the tape drive with something more modern, like USB or SD cards. For this I want to reverse engineer the code that encodes the data that goes to the tape drive. Looking at the waveforms its pretty obvious that they're using Manchester encoding or something very similar, but I think the best way to ensure compatibility is to reverse engineer the code they are using. I could not find a disassembler for the 6803 processor, so I wrote my own. Sadly it missed the code Im interested in. By running a simulation of the FPGA project in Modelsim I found some of the code, but Im having a hard time understanding how its called, where the start is, and how it actually decodes the data. Using what I learned from the simulation I ran the disassembler again on the start of the subroutines I found, so I now have the disassembly listing. Can someone please help me understand how this works?

I goofed. On second inspection the encoding scheme does not seem to be Manchester encoding. Perhaps some form of FM encoding?

[JimRemington]

Do you have any way of posting waveforms that might come from the tape head, e.g. a screen shot from Audacity, or scope pic.

The "Kansas City Standard" encoding (FM 1200/2400 Hz) was pretty popular in the early days. https://en.wikipedia.org/wiki/Kansas_City_standard

Edit: this page documents the tape encoding format for the 500 and MC-10 1500 Baud rates: https://github.com/lkesteloot/trs80-cassette-reader. 

Here are the rest of the details, including the ROM listings: http://www.trs-80.com/trs80-zaps-internals.htm  and http://www.trs-80.com/wordpress/trs-80-computer-line/mc-10/

[ozcar]

Wow, it's been a long time, and I don't remember much.

Here are a couple of programs that might help if you are still stuck. They are 6809 programs that ran on TSC Flex. One reads MC10 cassette data, and the other generates a MC10 cassette file (for “virtual MC10”).

Comment in the first one says:

* MC-10 USES PULSE WIDTH MODULATON FOR CASSETTE RECORDING
* PULSE FOR 0 BIT IS TWICE LENGTH OF THAT FOR 1 BIT.

[ozcar]

I was thinking that I have a 6803 disassembler, which is a slightly tweaked version of the “Dynamite” 6800/6809 disassembler. It runs on Flex, but, would you believe, I can still run that.

However, that reminded me that years ago I had an annotated disassembly of the MC10 rom. It was a printed-on-paper thing created by a bloke here in Australia. I certainly don't have that any more, but I was wondering if that had ever been scanned and is out there just waiting to be found. Well, I did not find that one, but did find another:

http://www.roust-it.dk/coco/mc10/romlist.txt

I had a quick look at a couple of points in it, and it does seem to match the code you have.

[Dukov Ahzrukhal]

I found the service manual for the MC-10. It actually shows the waveforms and even goes into detail about how the the data is formatted. It seems to be pretty simple, so maybe I didn't have to reverse engineer the code after all. Should I keep trying to figure out how the code works or should I just write my own from scratch? Let me know what you guys would do.

[JimRemington]

It is very simple to do what the manual says, which is to output either one cycle of 1200 Hz or two cycles of 2400 Hz, per bit. The voltage divider/RC filter on the output takes care of converting that to a 1 Vpp, tape-friendly (approximate) sine wave.

Schematic here: http://shiny3d.de/public/mc-10/circuit.png

[Dukov Ahzrukhal]

Indeed, it seems easy to encode the data that way. But what about decoding it? I could use a subroutine to measure the length of pulses to determine if they are a 0 or 1. But what about maintaining alignment and accounting for the possibility that the tape recorder (which could be any off the shelf recorder) might invert the signal? Surely the code in the TRS80 is designed such that it does not matter if the signal is inverted, meaning they cant assume that the positive half of the cycle will come before the negative half, or the other way around. I can test to see what happens if I invert the signal on an actual TRS80, but I'll be very surprised if it doesn't work.

[mikerj]

You just measure the time between zero crossings and ignore the polarity.

[JimRemington]

Surely the code in the TRS80 is designed such that it does not matter if the signal is inverted

Yes, the comments in the annotated disassembler listing posted in reply #3 above make that clear.

You have the code, written in very simple machine language, so spend a few minutes to understand exactly what it does.