TRS-80 software I wrote
  Zeta BBS
  Printer Utils
  Operating Systems
  Library of C
  Include files
  FORTRAN Programs
  File Utils
  Disk Utils
  Comms Programs
  CMD File Utils
  BASIC Programs
  University assignments

Your donation gives me time
to develop more cool free stuff

Nick Andrew - TRS-80 - Languages

TRS-80 Languages

This package contains a variety of programs related to software development or computer languages.

Stuff for the Alcor C Compiler. There's a patch here to make it work on the model 1, and a program to concatenate its object files together (presumably required to execute a separately-compiled program).
A small C program which "cleans up" ASM source files by reformatting certain lines. It removes the colons from label definitions and adjusts all comments (which did not start at the start of the line) to start in a particular column so the comments all line up. Null lines are replaced by lines containing only a semicolon.
This small C program converts an assembler source file to all uppercase (excluding character or string literals and comments).
This is a program which evaluates a constant expression in the C language. It understands the four basic operations as well as right and left association and open and close parentheses. This program was obviously written for educational purposes, as it is full of debugging.
I wrote this cute little program in 1985 to compress a 'C' source file given knowledge of all the C reserved words. It also did Run-Length Encoding of spaces and tabs (only). I don't recall what typical compression ratios were achieved but somehow I doubt that it achieved the 50% of LZW.
As a kid I once went for a job at a software house which wrote for the Apple II platform. Why? I was a TRS-80 guy. I dunno. Anyway to show that I could do 6502 assembly language I wrote a bunch of Z80 macros which emulated the 6502. I wrote an integer multiply function as a test and the macros worked. Of course it wasn't a proper 6502 emulator as there was no instruction decode, but it was a good way to learn the 6502 code. I didn't get the job but I'm not bitter about it.
The comment on this program says "Decodes a /REL file". I think a /REL file is compiled FORTRAN and the strings in the source back me up on this. Consider this program like an nm for TRS-80 FORTRAN.
This program "removes extraneous labels from source code created using Newdos Disassem package". I guess that disassem wasn't all that smart, and assigned labels for things which did not need labels. I recall that sometime later I used a very cool program called DISNDATA which used flow-of-control analysis to identify which parts of a disassembled program were code and which were data, and represent the data parts as literals and the code parts as Z80 instructions. DISNDATA helped so much in the arduous task of opening up and studying and fixing all the TRS-80 software which I had. There's also a BASIC program of the same name which probably does the same thing.
This is a small C interpreter for an invented structured language. The language cannot do much on its own but it was a cute idea to write little special-purpose languages. The interpreter is only 150 lines of code.
Show how an assembler program flow by printing all labels, jumps and calls. It looks like almost a "grep" for control-flow altering statements in an assembler source file. I would have thought something which actually analysed the structure and reported in 2 dimensions or constructed a reference graph would have been more useful. I guess it solved some hard problem I faced at the time!
change.asm in this directory converts a /EDT type file created with probably the Radio Shack assembler, to the format required by the TRS-80 FORTRAN compiler. This is probably because the FORTRAN editor was a hunk of junk and so I would have started using the more convenient EDTASM as an editor.
This was a University assignment for Languages and Processors (lecturer: John Colville). It is a compiler and/or interpreter for an invented language called L2. I'm sure it's written exactly the way the Dragon Book says a compiler should be written. It's actually quite a large program. Some L2 test programs are included; the language looks similar to Pascal (although obviously not repeating all of Pascal's design flaws).
This program implements a peephole optimiser for assembler source code created by the LC program (LDOS C Compiler). LC was like Small C, only worse - a lot worse. It was a memory hog and it ran very slowly and it had bugs. At least, I think it had bugs. I was much happier after porting Small C and improving the latter's type handling.

The optimiser looks for a certain common 3-line sequence: "PUSH HL; LD HL,n; POP DE" and replaces it with the more efficient "EX DE,HL; LD HL,n".

A further optimisation look for a "LD HL,n; PUSH HL; LD HL,n" sequence (where the 'n' is the same) and eliminates the final line.

The final optimisation looks for "EX DE,HL; LD HL,n; EX DE,HL" and replaces this with "LD DE,n".

This program reads a disk file containing a tokenised BASIC program and expands the tokens into their original keywords. Interestingly enough, it contains token tables for both CP/M (which flavour?) and TRS-80, and the CP/M one is enabled.

Just as an aside, in the process of recovering all my TRS-80 source code I wrote a BASIC untokenizer in perl. My perl script was undoubtedly easier and faster to write, and has the feature that it also selectively adds whitespace around the expanded tokens for the benefit of 21st century dudes like me who can barely understand BASIC programs now, and I wouldn't be at all happy if I had to strain to separate the language keywords from their operands. Almost nobody nowadays thinks that "PRINTX" is a good way to write "PRINT X" because it saves one space.

One day I will add my perl untokenizer here, so you can see what a difference 15 years of computing technology makes. Not much difference to count of lines of code it seems, as both programs seem to be about 150 lines long (excluding the translation table). Of course the perl program spends a good half of its length at figuring out its selective addition of spaces around tokens. And the perl program has comments.

This directory also contains an untokenizer in C, of similar length. This program is interesting because it actually manipulates the language a little, stripping any code after 'CLEAR' for example.

First there was EDAS, an Editor-Assembler for LDOS. I modified that to work under Newdos-80 and renamed it NEDAS. There's a NEDAS command reference in this directory.
It's a cross-reference program written in C and attributed to Gustav Francois (a pseudonym I used sometimes in 1986) called nedasref.
This simple program looks for multiple instances of "RST 38H" in a disassembler output and changes it to "DC nnH,0FFH". "RST 38H" is opcode 0xFF.
This simple program does the same thing as noffs above, except for "NOP" instructions (which are opcode 0x00).
This program changes tabs in source files to runs of spaces. It knows that a tab represents a variable number of columns.
This assembler program converts Pascal-80 source files to plain ASCII.

Like with the tokenized BASIC, I had to write a Pascal-80 converter in perl for extracting my code. The perl Pascal-80 converter is 49 lines of spaced and commented code compared to about 116 lines of mostly uncommented assembler. Perl rocks :-) although after finding the assembler version I noticed that it was more functional than the perl one (the assembler version stripped trailing spaces from the output). Of course it was a few moments work to change the perl one to do that also (that change is included in the 49 lines of code).

This is a simple C preprocessor which I wrote. I think it's all my code. I think I had a problem with the integrated preprocessor in the Small C compiler, namely that it was too big, so I cut out the preprocessor to save space and wrote my own for the exercise. Or maybe I did no such thing, it's so hard to tell 17 years later. Anyway I think now that keeping the preprocessor in the code was the right thing to do for a small machine, because multi-pass multi-program compiling would have made things too slow.
I wrote an 8086 implementation of my Zeta-BBS message system (Treeboard) for the NSW Disadvantaged Schools Program. The code was to run on an MP/M-86 microcomputer. As far as I know the program worked fine. I didn't really rewrite it from scratch, I simply hand-translated it from Z80 assembler to 8086 assembler and I wrote some interface functions to handle the specific differences between TRS-80 and MP/M-86 systems (like file or keyboard I/O).

Anyway it looks like I made a colossal blunder when rewriting the code. I was using "ret nz" in places, which is perhaps not a valid instruction for an 8086. In 2002 I would not have thought offhand that the 8086 could be less powerful than the Z80 in this respect, and a quick web search leaves me none the wiser. Anyway this program takes an 8086 assembler source code file and changes all instances of "retnz" to a conditional jump around an unconditional return.

This program changes spaces to tabs in an assembler source file, and it doesn't appear to care about preserving the columns (in other words it will change any number of contiguous spaces to a single tab).
This program removes the line numbers from source files. Obviously source files created with those cumbersome line editors which insisted on preserving the line numbers with the saved file.
This program looks like it changes a COBOL source file to all upper-case, excepting comments. I looked carefully for any COBOL programs I may have written to be preserved in my TRS-80 packages archive, but alas there were none, and I don't get to express in HTML my utter disgust for the COBOL language.

To be more precise, there was one, a calculator program, and I couldn't be certain that I wrote it, so I did not include it. The calculator program could perform the 4 basic operations only, on only 2 operands, so it was not an "expression evaluator" unless the expression was no more complex than "2 + 3" or "4 * 5". I suspect this program was a sample program written by Ryan-McFarland Corporation who wrote RMCOBOL which was rebadged by Radio Shack as RSCOBOL. It strikes me as quite ironic that a calculator program should be used, as this is a task for which COBOL is quite unsuited.

This program removes a trailing TAB from source files created by disassem. It appears that all lines with opcodes but no operands have this trailing TAB.
Unline "takes line numbers off long source files". I imagine it takes them off short source files too, but the line numbers only became a problem with long source files. How long? Maybe the system did not accept line numbers larger than 65535, and it would be necessary to strip them before loading them into an editor.