Image Map Image Map
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 39

Thread: Model 4 Cassette Operation

  1. #11

    Default

    So the D code means data error.

    I looked at the source for TAPE100/EXE and it looks like the headers are unique for the Model 100. The Model III ROM didnt know about this because it didnt exist at the time, however in Model 4 mode there was no Model III ROM to do the decoding of the data in.

    It does look like 1500 baud, just a different header/sync.

    There is a wav2cas program, might be able to play with that and move some stuff around/convert to Model 4 and play it back that way, or if you have a disk system in that Model 4 you can use TRSDOS TAPE100/exe

  2. #12

    Default

    If you can convert your cassette to a wav file, then you try loading it into a TRS emulator.

    Also, have you aligned the head on your cassette recorder?

  3. #13
    Join Date
    Feb 2015
    Location
    Cleveland, OH, USA
    Posts
    1,287

    Default

    Quote Originally Posted by Robbbert View Post
    If you can convert your cassette to a wav file, then you try loading it into a TRS emulator.
    I know you can convert cassette programs to .wav files but I hadn't thought about using an emulator. I'm trying to stay closer to the metal.

    Quote Originally Posted by Robbbert View Post
    Also, have you aligned the head on your cassette recorder?
    Uh.... Aligned?

    -CH-

  4. #14
    Join Date
    Feb 2015
    Location
    Cleveland, OH, USA
    Posts
    1,287

    Default

    Quote Originally Posted by Tibs View Post
    So the D code means data error.

    I looked at the source for TAPE100/EXE and it looks like the headers are unique for the Model 100. The Model III ROM didnt know about this because it didnt exist at the time, however in Model 4 mode there was no Model III ROM to do the decoding of the data in.

    It does look like 1500 baud, just a different header/sync.

    There is a wav2cas program, might be able to play with that and move some stuff around/convert to Model 4 and play it back that way, or if you have a disk system in that Model 4 you can use TRSDOS TAPE100/exe
    AHA! Thanks!

    -CH-

  5. #15
    Join Date
    Mar 2013
    Location
    Chaffee, MO
    Posts
    1,612

    Default

    That was an interesting article that I OCR'd.

    Code:
                        CASSETTE INPUT AND OUTPUT           PAGE 118
    
    
     Transferring  data between memory and the cassette tape
     recorder is similar to reading the keyboard or displaying
     characters on the video monitor.  It is not really necessary
     for a programmer to know how such a transfer works, as long as
     he knows how to use the ROM subroutines that carry out the
     essential operations.  One important difference between the
     keyboard and video display on the one hand, and the cassette
     recorder on the other, is that the former are memory mapped,
     whereas the cassette recorder is interfaced through an
     input/output port, number 255 (hexadecimal FF), which also
     controls the 32- or 64-character mode of the video display.
     Thus, only certain bits of this port are used.  The disks and
     line printer are also memory-mapped, whereas the RS-232-C
     interface and various other peripherals are interfaced through
     ports.  The TRS-80 has much room for expansion of input and
     output devices using either method.
    
        The addresses of ROM subroutines that are used for cassette
     input and output have been mentioned above in chapter 5, but
     they will be reviewed here in more detail.  All are located
     between addresses 01D9H and 0313H.  ("H" is often appended  to
     addresses to remind you that they are hexadecimal numbers.)
    
    
                        CASSETTE INPUT AND OUTPUT           PAGE 119
    
    
                      14.1  Cassette ROM Subroutines
    
      Address   Function
      ---------------------------------------------------------------
       01F8H    Turns cassette off.  Uses register A.
       0212H    "Define drive":  A=0 Łor cassette 1 or 1 for
                cassette 2.
                Turns on the proper cassette drive and selects it
                for subsequent operations.
       0235H    Read byte, which is returned in A.
                Uses no other registers.
       0264H    Write byte in A to cassette.
                Uses no other registers.
       0287H    Write leader and sync byte.  Uses AF, C.
       0296H    Read leader and sync byte.  Uses AF.  Two
                asterisks appear in the upper right corner of the
                video display when leader and sync byte are found.
       0314H    Reads two bytes (LSB/MSB) and transfers to HL.
                uses AF.
      ---------------------------------------------------------------
         All cassette input and output operations in assembly
      language can be done using these subroutines.  All standard
      tape  formats are readable.  Some programmers have developed
      non-standard methods that encode the bits in some different
      way.  These operations are beyond the scope of this
      discussion.
    
         The beginning of a file on the cassette tape is signified
      by a "leader and sync byte", which is actually a succession of
      255 zeros followed by A5 (the sync byte).  Each bit of data is
      read from the tape separately.  This means that the timing  of
      the routine that reads the bits is extremely crucial.  This is
      why you must disable interrupts (CMD"T") in Disk Basic when
      reading cassettes.  It is also why TRS-80 owners who have had
      the clock speed modified must switch to the older, slower
      speed in order to read standard cassette tapes.
    
         Once the cassette tape is turned on and the leader and sync
      byte located or written, it is the programmer's responsibility
      to keep up with the speed of the cassette in order to read or
      write data properly.  (Writing data may be less crucial than
      reading it.)  The data-transfer speed of the cassette is 500
      baud ("baud" means "bits per second"), so that a bit must be
      read or written every 2 milliseconds.  What this means is
      that, for most purposes, all you can do is to read or write
      data into or out of memory and stop the cassette when you want
      to do some computation.  Each time you stop the cassette, you
      must start it again with a leader and sync byte combination,
      to make sure that no data is lost due to the start and stop
      motion of the cassette.  Any program that does not keep up
      with the 500-baud data transfer rate will lose bits of data,
      thus reading incorrect values.
    
    
                        CASSETTE INPUT AND OUTPUT           PAGE 120
    
                            14.2  Tape Formats
         To keep up with the cassette's speed, standard tape formats
      have been developed by Radio Shack to indicate what the data
      on the tape represents, where it goes, when to stop the
      cassette, and what to do after stopping.  There are four
      standard tape formats:  Basic programs, Basic data, machine-
      language object tapes (the SYSTEM format), and
      Editor/Assembler symbolic-program files.  Other formats, such
      as data files for the Electric Pencil program, have been
      devised for various reasons, but will not be discussed here.
    
      1.  Machine Language Object (SYSTEM) Tapes
         An "object program" is a program in machine code ready to
      run on a computer.  When stored on an external medium such as
      a cassette tape, it is necessary only to dump it  into  memory
      and jump to the starting location.
    
         The object-program format is also known as the SYSTEM
      format because of the Basic command used to read such tapes.
      Data is written on the tape in the form of blocks less than
      256 bytes in length.  Each block begins with a header byte
      identifying what kind of block it is.  There are three types
      of blocks:  FILENAME, DATA, and ENTRY.  FILENAME is first,
      followed by any number of DATA blocks.  The ENTRY block comes
      last, after which the cassette is turned off.  The whole tape
      has the following structure:
    
              (Leader and Sync Byte)
              Filename Header        55H
              File Name              6 bytes (ASCII), filled with
                                     blanks if name less than 6
                                     characters.
              Data Header            3CH
              Count Byte             Number of data bytes to
                                     follow (1-256)
              Load Address           2 bytes, LSB/MSB, indicating
                                     where data is to be loaded
               (Other Data Blocks)
              Entry Header           78H
              Entry Address           2 bytes, LSB/MSB.
    
         The fact that each data block has its own address means
      that data can be loaded anywhere in memory, and that the same
      tape can contain data that goes into several different  areas.
      Usually, only the Editor/Assembler program produces such tapes
      (through the use of different ORG statements), because
      monitors such as TBUG or Monitors 3 and 4 (as well as the
      TAPEDISK utility program) require that you specify one
    
    
    
                       CASSETTE INPUT AND OUTPUT           PAGE 121
    
    
     contiguous block.  If the checksum is wrong, or if the header
     byte is not 55, 3C, or 78, an error is produced.   If  reading
     the cassette under SYSTEM, a "C" replaces one of the asterisks
     in the upper right corner.
    
    
     2.  Editor/Assembler Source Program Tapes
        Source tapes for the Editor/Assembler program have a format
     different from other tapes:
             (Leader and sync Byte)
             Filename Header         D3H
             File Name               6 bytes (ASCII), padded with
                                     blanks
             Individual program statements:
             Llne Number            5 bytes, ASCII-encoded,
                                    with bit 7 (parity) set
             Statement Code         (Any length).  TAB (right
                                    arrow) key encoded as 09.
             carriage Return        0D (ENTER key)
             (Last statement - END - encoded in same manner)
             End Byte                1AH (shift down-arrow)
    
        This format is essentially a dump of the memory area that
     holds the source program when running the Editor/Assembler
     program, except that when the program resides in memory, the
     line numbers are stored in two bytes (LSB/MSB).  The tape thus
     takes more room than the program in memory.  This is also the
     format used to hold symbolic files on disk.
    
    
     3.  Level II Basic Program Tapes
        A Level II Basic program tape is essentially a dump of the
     program as it is stored in memory.  This is not the way in
     which you type it in, nor the way it is listed when you print
     it, because all of the key words are translated into a  binary
     code.  Statement numbers are stored in two bytes.  This is why
     they may have a maximum value of 65529 (65535 less a few
     values used for special purposes).  The only recognizable data
     is the ASCII text in PRINT  statements, variable names, and
     constants.  The complete format is as follows:
    
    
                       CASSETTE INPUT AND OUTPUT           PAGE 122
    
             (Leader and Sync Byte)
             Header                  D3 D3 D3
             File Name               First byte only, ASCII
             Program Statements      Starts loading directly into
                                     42E9H (Level II)
                                     or 68BAH (Disk Basic)
             End Flag                00 00 00
    
        This is also the standard format used to store Basic
     programs on disk, except that disk storage also provides the
     "ASCII" option (SAVE "PGM",A), which stores the program in
     exactly the same way that it is printed by a LIST command.
    
    
     4.  Level II Basic Data Tapes
        Because of the one important point mentioned above --  that
     you must write a new leader and sync byte each time that you
     start or stop the cassette -- Level II Basic data tapes are
     stored in a very inefficient manner.  Each time a PRINT #-1 or
     INPUT #-1 is executed, a new leader and sync byte is written
     or read.  A Basic program can take advantage of this
     situation, by trying to include as much data as possible
     within a single statement, but it is impossible to escape the
     fact that most of the time is spent reading the leader and
     sync bytes.
    
        The exact format of a data tape is so simple that a table
     is not  necessary.  After the leader and sync byte comes the
     data itself, terminating in a carriage return.  Individual
     items in the list are separated by commas.  For this reason a
     comma cannot be included in a string saved on cassette tape
     (nor can a carriage return).  Strings are written simply as a
     series of characters.  All numbers, whether they represent
     integers or single- or double-precision values, are stored as
     ASCII strings surrounded by blank  spaces.  Thus, a number
     could be written as an integer and read as a single- or
     double-precision number or string.  The decimal  point is
     included if present.  A string consisting of numerals can be
     written as a string and read as a number, but if it contains
     any non-numerical characters, an error is produced.  The
     warning in the LEVEL II BASIC REFERENCE MANUAL is not totally
     correct.  It is possible to read data in some form other than
     that in which it was written, but you  must always read the
     same number of items.  The carriage-return character (0DH) is
     the cue to stop the cassette when data is being read.
    
    
                       CASSETTE INPUT AND OUTPUT           PAGE 123
    
             14.3  Programming Cassette Input and Output
    
     The most useful format for an assembly-language programmer is
     that for machine-language object tapes.  Using this format,
     both programs and data can be saved, as long as they are read
     into or out of a contiguous memory block.  The  program shown
     below reads an object tape into memory, even blinking the
     asterisk in the upper right corner like the SYSTEM command.
     Rather than having you specify the name, however, the name is
     read off the tape and printed on the video display.  When the
     program has been read completely, the starting, ending, and
     entry addresses are also printed.  The program then walts for
     you to type a key.  If you type ENTER, execution of the
     program read into memory begins.  otherwise, the system is
     rebooted.
    
    
     ;PROGRAM TO READ MACHINE-LANGUAGE OBJECT TAPES
     REBOOT  EQU     0               ;ROM ADDRESSES
     VIDEO   EQU     33H
     INPUT   EQU     49H
     CASOFF  EQU     1F8H
     DEFDRV  EQU     212H
     RSYNC   EQU     296H
     RBYTE   EQU     235H
     RHL     EQU     314H
             ORG     7E00H           ;NEAR TOP OF 16K
     START   CALL    CLS             ;CLEAR SCREEN AT START
     READY   LD      HL,FREADY       ;PRINT "READY CASSETTE"
             CALL    PRINT
             CALL    INPUT           ;WAIT FOR KEYIN
             LD      HL,FNAME        ;MESSAGE
             CALL    PRINT
             XOR     A               ;CASSETTE 1
             CALL    DEFDRV
             CALL    RSYNC
             CALL    RBYTE           ;FlRST BYTE
             CP      55H             ;FILENAME HEADER
             JR      NZ,CERR         ;WRONG TAPE IF NOT
             LD      B,6             ;6-LETTER NAME
             CALL    RBYTE
             CALL    DISP            ;PRINT ON SCREEN
             DJNZ    $-6
             CALL    RBYTE           ;FIRST BLOCK
             CALL    RDH
             LD      (ADR1),HL       ;SAVE 1ST LOC
             JR      CLP2
     CLP     CALL    RBYTE           ;1ST BYTE O~ BLOCK
             CP      78H             ;ENTRY?
             JR      Z,CEND
             CALL    RHD
    
    
                       CASSETTE INPUT AND OUTPUT           PAGE 124
    
     CLP2    ADD     A,L             ;COMPUTE CHECKSUM
             LD      C,A             ;SAVE IN C
     CRD     CALL    RBYTE           ;READ DATA
             LD      (HL),A          ;SAVE IN MEMORY
             ADD     A,C             ;COMPUTE CHECKSUM
             LD      C,A             ;SAVE IN C
             INC     HL              ;NEXT LOC
             DJNZ    CRD             ;CONTINUE THRU BLOCK
             CALL    RBYTE           ;CHECKSUM FROM TAPE
             CP      C               ;OK?
             JR      NZ,CHKSM        ;*IF NOT, BAD READ
             PUSH    HL
             LD      HL,3C3FH        ;RIGHT CORNER OF VIDEO
             LD      A,'*'           ;BLINK
             CP      (HL)            ;IF '*' ALREADY THERE,
             JR      NZ,$+4          ;CHANGE TO
             LD      A,' '           ;BLANK
             LD      (HL),A          ;STORE
             POP     HL
             JR      CLP             ;GET NEXT BLOCK
      CHKSM  LD      HL,FCHKSM       ;CHECKSUM ERROR
             R       $+5
      CERR   LD      HL,FCERR        ;READ ERROR
             CALL    PRINT
             CALL    CASOFF          ;STOP TAPE
             JR      READY           ;TRY AGAIN
      CEND   LD      (ADR2),HL       ;ENDING ADDRESS
             CALL    RHL             ;GET ENTRY ADDRESS
             LD      (ADR3),HL       ;SAVE
             CALL    CASOFF          ;STOP
             LD      HL,(ADR1)       ;PRINT ADDRESSES
             CALL    PHL             ;START
             LD      HL,(ADR2)       ;END
             CALL    PHL
             LD      HL,(ADR3)       ;ENTRY
             CALL    PHL
             CALL    INPUT           ;WAIT FOR KEYIN
             CP      13              ;ENTER KEY
             JP      NZ,REBOOT       ;REBOOT IF NOT
             JP      (HL)            ;ELSE EXECUTE PR~~RAM
      RHD    CP      3CH             ;CODE FOR DATA BLOCK
             JR      NZ,CERR         ;IF NOT DATA, NOGOOD
             CALL    RBYTE           ;LENGTH
             LD      B,A             ;SAVE IN B
             JP      RHL             ;GET ADDRESS, RETURN
      PRINT  LD      A,(HL)          ;PRINT MESSAGE
             AND     7FH             ;MASK PARITY
             CALL    DISP
             BIT     7,(HL)          ;DONE IF NZ
             RET     NZ
             INC     HL              ;NEXT LOC
    
    
    
                       CASSETTE INPUT AND OUTPUT           PAGE 125
     
             JR      PRINT           ;CONTINUE
     PHL     LD      A,' '           ;PRINT
             CALL    DISP            ;TWO
             CALL    DISP            ;SPACES
             LD      A,H             ;PRINT H
             CALL    HEX             ;AND L
             LD      A,L             ;IN HEX
     HEX     PUSH    AF
             RRCA
             RRCA
             RRCA
             RRCA
             CALL    HEX2
             POP     AF
     HEX2    AND     15
             ADD     A,30H
             CP      3AH
             JR      C,DISP
             ADD     A,7
     DISP    CALL    VIDEO
             RET
     ;FORMATS
     FREADY  DEFM    'READY CASSETTE'
             DEFB    8DH
     FCERR   DEFM    'CASSETTE READ ERROR'
             DEFB    8DH
     FCHKSM  DEFM    'CHECKSUM ERROR'
             DEFB    8DH
     FNAME   DEFM    'NAME    START END   ENTRY'
             DEFB    8DH
     ;DATA AREAS
     ADR1    DEFS    2               ;START
     ADR2    DEFS    2               ;END
     ADR3    DEFS    2               ;ENTRY
             END     START
     
    
       This program contains four utility subroutines and one
     specialized subroutine.  The utility subroutines are DISP,
     which displays a byte on the video screen (note that it is not
     necessary to save DE and IY, because they are not used); HEX,
     which prints the byte in A in hexadecimal form;  PHL, which
     prints two spaces followed by the bytes in H and L in
     hexadecimal form; and PRINT, which displays an ASCII  message
     until a byte with bit 7 set is found.  At the end of the
     program, there are four messages printed by this subroutine
     (FREADY, FCERR, FCHKSM, and FNAME).  Each message terminates
    
    
                      CASSETTE INPUT AND OUTPUT          PAGE 126
    
    
        The program begins by printing "READY CASSETTE" and waitlng
     for you to type a key.  It then prints a message indicating
     the information it will give you about the tape it reads (name
     and starting, ending, and entry addresses).  After getting the
     tape going, it checks to see whether the first  byte  is  55H,
     which is the code for file name.  If not, the wrong type of
     tape is being read.  The address of the first  block  must  be
     saved for the message later.  For this reason, the portion of
     the program that checks to see if a data block is occurring as
     expected, and reads the length and address of the block, is
     made into a subroutine (RHD).  The block is read and checksum
     computed.  At the conclusion of the block read, the checksum
     computed is compared to that on the tape.  If they are not
     identical, an error has occurred.  Any tape error results in
     the program being restarted from the "READY CASSETTE"
     message.
    
         The asterisk blinks only at the end of a block.  If an
     asterisk is already present in the upper right corner of the
     video display, it is changed to a blank.  Otherwise an
     asterisk is stored there.  After the entry block has been
     read, the tape is stopped and the addresses displayed.  The
     program is then executed if you type ENTER.
    
         Suppose that you have a tape written in some non-standard
     format that you want to know how to read.  How can you
     discover what is on the tape?  The following program can be
     used for this purpose.  All it does is read the bytes off the
     tape directly into memory, starting at 7026H (BUFFER).  It
     never stops, so you must press the RESET button when you think
     it is done.  After hitting RESET, you can use a  program  such
     as Monitor 3 or 4 or SUPERZAP to examine the contents of
     memory and see what is on the tape.  This method was in fact
     used to work out the tape formats described above.
     
     ;PROGRAM TO READ A CASSETTE TAPE DIRECTLY INTO MEMORY
      DEFDRV  EQU     212H
      RSYNC   EQU     296H
      RBYTE   EQU     235H
      BLINK   EQU     3C3FH                   ;UPPER RIGHT CORNE8
              ORG     7000H
      START   DI                              ;SAME AS CMD"T"
              XOR     A                       ;START TAPE
              CALL    DEFDRV
              CALL    RSYNC
              LD      DE,BLINK                ;SET UP BLINKING
              LD      B,'*'
              EXX
              LD       B,' '
              EXX
    
    
                         CASSETTE INPUT AND OUTPUT           PAGE 127
    
              LD      HL,BUFFER              ;WHERE TO PUT DATA
      READ    CALL    RBYTE                  ;GET BYTE
              LD      (HL),A                 ;STORE
              INC     HL                     ;NEXT LOC
              LD      A,B                    ;GET BLINK CHAR
              LD      (DE),A                 ;BLINK
              CALL    RBYTE                  ;NEXT BYTE
              LD      (HL),A                 ;STORE
              INC     HL                     ;NEXT LOC
              EXX                            ;GET OTHER BLINK CHAR
              LD      A,B
              EXX
              LD      (DE),A                 ;BLINK
              JR      READ                   ;CONTINUE
      BUEFER  DEFS    1                      ;TO END OF MEMORY
              END     START
    
         You may wonder why it was not possible simply to read the
      tape directly to the video display itself, rather than having
      to save it in memory.  The reason is that the computation
      involved in converting the data to hexadecimal form is too
      lengthy for the computer to keep up with the 500-baud tape
      speed.  The computation involved in blinking the asterisk in
      this example, which consists of loading an asterisk into B and
      a blank into B', and then alternately storing B or B'  in  the
      upper right corner, is an example of the kind of computation
      that can be carried out when reading data from cassettes.
    
         Recently, some companies have been selling programs that
      come with a special tape-loading program that uses a
      non-standard format, to prevent you from listing or saving the
      program.  This prevents people from making pirated copies of
      the software.  The program above, coupled with a disassembler,
      can be used to discover the method actually used to load the
      programs, and ultimately to read them yourself.  While reading
      such tapes is certainly possible, understanding how these
      loaders work is a much more complicated task, beyond the scope
      of this discussion.
    
         This information is a testimony that there is no mystery of
      the TRS-80 is beyond the power of a person who understands
      assembly-language programming.  Nevertheless, we do not
      encourage people to discover how to make pirate copies of
      software, which is a serious problem in the microcomputer
      industry today.

    Larry

  6. #16
    Join Date
    Feb 2015
    Location
    Cleveland, OH, USA
    Posts
    1,287

    Default

    That was, indeed. Thanks, Larry. Do you happen to recall the name of the publication?

    -CH-

  7. #17
    Join Date
    Mar 2013
    Location
    Chaffee, MO
    Posts
    1,612

    Default

    Charles,
    It was "TRS-80_Assembly_Language_1981_Prentice_Hall.pdf".
    https://www.classic-computers.org.nz...age-(1981).pdf


    Larry

  8. #18
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,840
    Blog Entries
    1

    Default

    That looks like the chapter from the Howe book. Much more readable than the copy I have so I am very appreciative of it.

  9. #19
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,083

    Default

    That "dump a cassette file into memory raw" program would be interesting to run against an ASCII Model 100 tape to see if it actually reads correctly with the Model III's BASIC ROM algorithm; is it really just different headers, or does it come out garbled because of bit encoding/timing/whatever differences?

    (Although, actually, I'm curious if it runs unmodified on a Model III to read "fast" tapes based on the power-on selection, or if you need to call a different ROM routine for 1500 baud tapes verses 500 baud.)
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  10. #20
    Join Date
    Feb 2015
    Location
    Cleveland, OH, USA
    Posts
    1,287

    Default

    I read enough of the text yesterday to glean that the author is talking about the Model I, as he refers to a processor speed of 1.7 MHz, a tape "baud" of 500 and the need to keep processing overhead to a minimum to keep pace with the tape. Later machines with faster processors apparently could keep up with 1500 bps. I don't know if the Model III is equal to the Model 4 in that ability. I also don't know if the Model 100 wrote at 500 baud or faster. Eudimorphodon poses an interesting question in that regard.

    Regrettably, I have never seen a Model I and my knowledge on the subject has more holes than Swiss cheese. But the author makes a couple of interesting points. For example, he observes that there is more than one version of the ROM code - functionally equivalent yet not verbatim. He also alludes to different ROM configurations, containing either Level I (4k) or Level II (12k) BASIC. Having 12k BASIC plus other ROM routines must have been impossible on a 16k machine; there would have been no TPA, as CP/M calls it. So the differentiation of Model I machines between Level I and Level II BASIC was in effect a memory capacity distinction, was it not?

    Knowing this prompts me to ask: Do the Model III and Model 4 share the same Level II BASIC as the Model I? I know their ROM code is somewhat different, as the Model 4 has a "Model III mode" and a "Model 4 mode" built in. There may also be differences in the ROMs of the 4P or GA or NGA.

    -CH-

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •