-
SBC-85 Cassette Tape Interface Build Files Released
03/30/2020 at 00:59 • 0 commentsIf you head on over to the SBC-85 project website, the documentation and build files for the cassette tape interface are available. Note that this interface is not limited to the SBC-85 project since the port to the computer is simple TTL and could be driven by any system.
For the software, I will be uploading the current version of the SBC-85 Utilities that has functions for reading and writing to the tape as well as adding the leader. In the SBC-85_Utility_Call_Examples.A85 file there are examples on how to write to a tape, read 100 bytes from the tape, and dump the received data to the terminal.
Enjoy ! -
Planning for v2
03/17/2020 at 16:47 • 0 commentsThe first version of this cassette tape interface can either run off the SID and SOD lines on the SBC-85 backplane or it can use an I/O port header. On most systems the SID/SOD are probably busy with the RS232 interface on the SBC board and the expansion port is inconvenient because it takes one bit out of two different ports (unless running off a 8755 with its bit defined port direction)
So I am thinking that v2 will be stand alone and take its own I/O space. I have not decided if this should be via an I/O chip like the 8255 PPI so there are additional ports available or if I should just create one port for the cassette interface and have this card dedicated just to the cassette. No more work either way, but the 8255 is a little harder to find for most than just a 74xx latch.
I have a few other things on the front burner now and it will be a month or so before I am submitting another board run so time to think about it. Any suggestions would be appreciated. -
Software-Check. Testing-Check. Reliability-Check. That's a wrap.
03/15/2020 at 21:21 • 0 commentsAssemble....probe....tweak.....repeat pretty much sums up getting the details refined for this tape software. Have it working reliably now after adding a couple of details that I hadn't thought about in the beginning. First I added a really long (15s) burst leader to the tape output to give me time to get the tape started and into position and to give the player's automatic adjustment time to decide what it is going to do with this strange music it is hearing. Then the leader finishes with an ASCII countdown from nine to zero as a data integrity check and then jumps right to the data. As of right now I do not have any error checking on the data other than confirmation of the leader countdown.
There are two software parameters:
- Tone frequency of burst (I picked 2kHz)
- Number of cycles in bit (I picked 5 cycles per 1/3 segment so 15 cycles per bit)
These values give an output rate of 7.5ms per bit or 133 bits per second, a.k.a., 133 BAUD which is a little less than 900 bytes per minute of tape. Not bad for a first try and there is still plenty of room to play with these two software parameters. Standard Tarbell was about 10x that speed so there is a great deal of room for improvement. I may take it up to at least an even 1kB per minute of tape if I feel the need for round numbers. A lot of my old data tapes are 7.5 minute which will hold much more than the available RAM in the SBC-85. I never liked putting multiple programs on one tape since I don't have a position counter on most of my players and I like the simplicity of one-tape-one-program. One thing that I need to remember to do is to write on each tape the parameters I used until I settle on final values. Otherwise future me will have to go back to the logic probe to figure them out.
After getting the basic tape output and tape input portion going, I started doing little features like controlling the board status LEDs and such. The basics of those are done but adding features will probably continue as I am actually using the cassette interface to save and retrieve data for the SBC-85.
Admittedly I used Tarbell standard back in the day and actually never used the Intel format before now. One thing that has surprised me is the insensitivity to output volume on playback. Once the volume is high enough for the integration RC into the last op-amp to maintain a logic one, additional volume comes with no penalty and the circuit seems to be completely immune to clipping or saturation. As a result, I have been running with the output volume pegged on max with no ill effect. That is something that the Kansas City and Tarbell circuits always seemed to have difficulty since there was a volume sweet spot for playback.
So, except for the documentation, I am calling this project done except for determining the maximum reliable data rate. With some early playing around with this, it is apparent that too much modification of the output frequency will require an update to the values of the RC in the integrator. If this doesn't drain quick enough there is a period of time where the logic at the end of a tone burst becomes indeterminate which can lead to false triggers of the next bit. For now, I need to update the user's manual and include waveform captures for diagnostics.
-
Hardware Checks, Software Status
03/14/2020 at 21:04 • 0 commentsThe first task was to write the code to output the bursts and spaces. 30 or so lines of assembly code later and that is done.
Back to the hardware......Here is the schematic
For the first test I simply looped the output directly back into the input and went through the various test points with the scope to see if the signals were as expected. For the most part, the hardware worked as designed, one tweak on the resistor value R6 which is the threshold value used by comparator. With a normal 0.6V drop across the two summing diodes D1 and D2, the summed signal (at TP3) was not quite high enough to trigger the comparator U1D to swing to the high rail. In the end, I put in a 0-ohm for R6 so that the DC output of U1B and U1C is the same as the reference voltage for the comparator U1D. That done, the signals started popping out the comparator and TP2 is getting nice rail-to-rail swings. To better integrate the spikes at the summing point, R12 went up to 10K. I think that I am going to call it on the hardware. Something may pop up later, but things are good to move on.
Here is what the output of an ASCII SPACE looks like with the output looped back to the input. The top line is the output to the tape, middle line reference spikes, bottom line the signal at JP2, i.e., the end result after the output character is read back and integrated over the bursts. (To save you the trouble, a space is 0010 0000 which is why we used to always use it to auto-set the baud rate). Timing spikes on one of the LEDs were added to help find the beginning of each character and data bytes are sent LSBit to MSBit. While logic probes can fudge the voltage levels, on the scope the input to the CPU is a hard 0V to 3.8V.