The TI-99/4A was issued with a built-in interface for cassette tape recorders. This was meant as a cheap alternative to a disk drive. The console contains the necessary hardware to read from, write to, and control the motor of two tape recorders. The relevant software is located in the console ROMs and GROMs.
Texas Instruments originally recommended the following recorders,
but
many others will work. I even used the one on my stereo, with
tune-tracking
system, etc. Most of the time the volume control should be set at
mid-range,
and the tone control (if any) at the highest possible pitch.
Brand | Model | Volume set | Tone set |
---|---|---|---|
Superscope | C2L00LP | 8.0 | N/A |
Panasonic | RQ2309A | 5.0 | 10 |
Sears | 2165 | Mid Range | N/A |
Sears | 21686 | Mid Range | HI |
JC Penney | 6568 | Mid Range | High |
Hardware
Connector
Internal circuitery
CRU map
Software
Direct control
Cassette tape format
ROM routines
DSRs in GROM
___________
( 1 2 3 4 5 )
\ 6 7 8 9 /
# I/O Use \_______/
- --- -------
1 > Cass 1 motor control
2 > Ditto (negative)
3 > Output to tape 1 or 2 (neg)
4 > Audio gate
5 > Output to tape 1 or 2
6 > Cass 2 motor control
7 > Ditto (negative)
8 < Input from tape 1
9 < Ditto (neg)
Texas Instruments marketed a connection cable, with a 9-holes
connector
at one end, and 5 jacks at the other (three for one tape recorder, two
for the other).
Pins 5 and 3 go to two jacks (on red cables) to be plugged in the the
microphone socket
on each recorder. Pins 8 and 9 go to a jack (on a white cable) to
be plugged in the "ear-plug" socket of recorder #1. Finally
pins 1 and 2 go to a smaller jack (on a black cable) to be plugged into
the remote control socket on recorder #1, while pins 6 and 7 play the
same
role for recorder #2.
As you see, only one recorder can be read from. I'm not sure why.
May
be because, if the output lines of two recorders are connected
together,
there is a risk that one is damaged when the other is outputing sound?
An important point is that the connections are polarised (see circuitery below). In particular, the remote-control jacks are connected to transistors, not to relays. This may cause some tape recorders to malfunction if their polarity is inverted with respect to that of the cassette jack. But it's a trivial job to build an adapter: get a male and a female jack and just cross their wires. I think you can even buy such adapters.
TMS9901 |
TMS9901 |
220pF |
Bit | R12 addr | I/O | Usage |
---|---|---|---|
22 | >002C | O | 1: Turn motor on for recorder #1 |
23 | >002E | O | 1: Turn motor on for recorder #2 |
24 | >0030 | O | Audio gate 1: Silent input |
25 | >0032 | O | Data output to recorders #1 and #2 |
27 | >0036 | I | Data input from recorder #1 |
You can control the tape recorders directly, using the CRU bits mentionned above. Note that it does not have to be tape recorders... I'm thinking of using the cassette port to hook-up two TI consoles and have a debugger program running on one and monitor the other. Communications would be slow (in serial mode by definition), but it would not require accessing any peripheral card.
* This routine performs some dummy cassette tape operations CSTEST LI R12,>0000 CRU address of the TMS9901 CSTES2 CLR R12 CRU address = >0000 |
Texaz Instruments adopted a frequency modulation encoding system to
store data on tape. This is only a convention, and you may come up with
another, if you feel like it. Similarly, TI defined the format the data
should have whithin a tape file. Again, this is only a convention.
Bits are encoded by output level changes. With a 3 MHz console, the output toggles every 725.3 microseconds. To encode a 1, invert the output in the middle of this time period:
0 0 _1 _0_ 1_ 1_ 0 Bits to encode
| |___| |_| |_| |_| |___| Output (low/high)
c c c c c c c c Clock intervals
Courtesy Dean Corcoran
This results in frequencies of 689.37 Hz for a space (0) and 1379 Hz
for a mark (1) which is well within the audio range, thus suitable for
a tape player. In addition, I was told that you can connect the
cassette
port to a PC sound card and save/load programs as .wav files (The
"Scott
Adams compilation" CD ROM by Frank Traut uses this trick, if I'm well
informed).
Name # of bytes Content
--------- ---------- --------
File sync 768 >00
Data mark 1 >FF
Size 1 # of records
Repeat size 1 ditto
Rec sync 8 >00 }
Data mark 1 >FF } Rec 1
Data 64 data bytes }
Checksum 1 sum of the 64 data bytes }
Repeat rec 1
Rec 2
Repeat rec 2
etc.
At the beginning of the files are 768 zeros (>300), for
synchronisation
purposes. The motor speed can vary a little from recorder to recorder
(not
too much, otherwise you would notice it when listening to music). So
the
tape reading routine in the console ROMs uses this stretch of zeros to
time the tape recorder. Once it has determine how long a "0"
bit lasts, it is a simple matter to detect a "1" which cuts this
interval in half.
The data mark signals the end of the sync stretch. It is followed by the number of records, repeted twice (to ensure reading is correct).
Each record in the file is repeted twice. It begins with a short sync stretch of 8 zeros, followed by an >FF data mark. The only allowed file format is Dis/Fix 64, so there is always 64 data bytes in a record. The record ends with a checksum: this is the sum of all 64 data bytes: it is likely to be greater than 256, and thus requires two bytes. However, only the least significant byte is recorded on tape.
The tape reading routine calculates its own checksum while reading data, then compares it with the recorded value. If it does not match, the routine will get another chance, as the record repeats. If the checksum matches the first time, the second repeat is just ignored. This format slows down cassette operations by a factor of two, but is more user-friendly: since a tape recorder is by definition sequential, a bad record that aborts reading forces you to start all over again, from the beginning of the file. In the worst case, it means the file cannot be read. At least with this method, even if a record is unreadable its copy might still be good. The probabilty that both copies go bad is very low (the square of the probability that one record goes bad).
There is no special end-of-file mark. Recording just stops after the
second repeat of the last record.
There are three cassette operating routines in the console ROM: cassette write, cassette read and cassette verify. All three can be called by the GPL opcode "I/O", with respectively 3, 4 or 5 as a source argument. The destination argument consists in two words: the number of bytes to transfer, and the VDP buffer address.
Operation | GPL I/O | Address in ROM |
---|---|---|
Write | 3 | >1346 |
Read | 4 | >142E |
Verify | 5 | >1426 |
For obvious reasons, they all require precise timing and this is done by using the built-in timer in the TMS9901 interface controller chip, which is part of the console. The cassette routines enable the interrupt function of the TMS9901, which requires taking control of the interrupt service routine. This is done by setting a flag bit (value >20) in byte >83FD. From now on, the console main ISR will treat any interrupt as issued by the TMS9901 and branch to the cassette ISR at >1404. If you are not familiar with the concept of interrupts service routines (ISR) you may want to have a look at the page on interrupts, as well as at the page describing the TMS9901.
What all this implies is that no other interrupt should be allowed, and cassette routines begin by masking them off (by setting CRU bit 1 and 2 to 0 in the TMS9901). This would be necessary anyway, given the nature of a tape recorder: once you start reading you can't stop and come back later, as the tape keeps running! A temporary interruption would mean skipping one or more records, which would force the user to start the cassette operation all over again.
* This routine prepares for cassette interrupts SETCS LI R3,>0023 Timer value (>0011) plus clock bit, inverted * This routine returns to normal operations CLRCS SZC @H0010,R14 Clear read/verify flag |
Upon writing, the timing is ensured by loading >0011 (i.e. 17) into the clock register of the TMS9901 chip. The resulting delay is:
17 = 363.6 usec
(3MHz / 64)
The write subroutine writes to the output by toggling CRU bit 19 and entering a forever loop:
HERE JMP HERE |
The only way to get out of this loop is via the interrupt that will occur once the timer has elapsed. The cassette ISR checks whether the main program is trapped into such a loop and (if this is the case) returns to the next instruction, thereby effectively jumping out of the loop.
* This routine writes a byte to the cassette. The byte is in R4. EMITBY LI R6,>0008 Bit counter: 8 bits per byte X R8 Toggle CRU bit 19 MOV R4,R4 Test leftmost bit |
And here is the infamous cassette-specific interrupt service routine:
* Cassette ISR, located at >1404-1422 in the console ROM. CASISR SBZ 0 Make sure we're not in timer mode SK2 LWPI >83C0 Branch to vector in R6, with ISR workspace |
Now, all Write has to do is to use the above routines to send the appropriate bytes. Please refer to file format, above.
The Read subroutine also makes use of the timer to time the stretches of "0" bits in the sync field at the beginning of each record. First it loads the maximum value (>3FFF) in the TMS9901 timer and waits for 8 bits to arrive. Then it reads the timer and see how much time has elapsed. It uses 8 bits rather than just one to get an average value.
* This routine checks whether the input toggled. ISTOGL TB 27 Check tape input port ISONE CZC @H00FF,R1 Input is 1. What was it before? * This routine makes use of the above to time the cassette recorder TIMECS LI R9,>7FFF Timer value >3FFF, plus clock bit SBO 0 Enter clock mode |
Once this value has been determined, it is fed to the timer for further reading operations. If the timer fires before the output toggles, the incoming bit is a "0". If the output toggles while the timer is still mid-way to zero, the incoming bit is a "1". Simple enough, no?
* This routine receives a bit. It uses the toggle detection routine above. GETBIT MOV R11,R10 ORI R1,>FF00 Flag for ISR: use vector in R6 if times out LP5 TB 27 Wait till input toggles back to 1 LDCR R3,15 Reload delay in clock * This routine receives a byte. GETBY LI R8,>0008 Bit counter: 8 bits per byte |
Now, here is how Read works:
This routine is nothing more than a cassette read that compares the incoming data with the content of the buffer, instead of filling the buffer with them. If a mismatch occurs, the routine returns with bits >21 set in >837C (GPL status byte).
There are two DSR in the first console GROM: CS1 and CS2. They can be found as GROM addresses: >1320-16DC. As you might expect, CS1 deals with the first tape recorder, and CS2 with the second. These are unusually high-level DSRs, that directly interact with the user. For instance, they display prompting messages on screen and wait for the user to press a key. It is one of the rare occurences when byte 8 in the PAB is effectively used to pass a screen bias to a DSR.
By the way, the prompting messages are send by calling a subprogram, whose name is >03. It must be called with the screen address in >8364 and the a string number in >8362. This number (0 to 32, by steps of 2) is an offset into a table of 2-byte long string pointers located at GROM address >15A0. For some strings, the subprogram also adds the cassette number (CS1 or CS2) to the string and displays "then press enter". In any case it beeps by calling the "accept tone" GROM routine at >0034.
As mentionned above, the file type must be display, variable 64, and sequential. In addition, CS2 can only be opened for output (as recorder #2 cannot be read from).
EXIT
GETKEY
CHECK