Another gift from Frank C. Odds : Probe!

Frank tells us :

PROBE!
Writing PROBE! (ca. 1984) was the only time I ever made money from working with the PC-1500. The biggest problem with Sharp’s wonderful pocket computer was that it had no compiler. You wrote programs in BASIC, and when they ran, the computer painfully interpreted each step from BASIC, line by line, and thus executed the instructions.
In any computer processor, the ‘true’ inputs and outputs are bytes of binary symbols, e.g. 10011000 011011110 etc. No human brain can seriously contemplate writing complex programs this way, but if each 8 binary digits (each byte) is written as a hexadecimal number (the previous example would be 98 DE) they become slightly easier to deal with. A program written as a series of hexadecimal bytes poked into successive memory locations is described as ‘machine code’.
Machine code still requires a pretty giant intellect to put together hexadecimal bytes in a way that constructs a useable program. It would be handy to have a programming language less complex than BASIC, but which makes better sense than a string of bytes. Such a language is known as ‘assembler’. Its details depend on the precise way the computer’s central processing unit (CPU) functions.
The PC-1500 CPU works with three ‘registers’, X, Y and U, each of which can hold 2 bytes, an accumulator (A) and a small number of other components with names such as ‘program counter’, ‘timer’, and ‘carry flag’, but I’m trying to keep things here as simple as possible! Programming then becomes a sequence of loading numbers into various registers, getting the accumulator to work on them, and many remarkably small steps which, between them, perform the functions you want.
The bottom line: a high-level language like BASIC is fairly easy to understand as a series of English-language instructions. Assembly language — a lower-level language — looks like gobbledygook, but it is a labguage one can learn, and it gets much closer to the way the CPU truly functions.

In the early 1980s, Sharp published their Technical Reference Manual for the PC-1500. This gave a lot of information on the PC-1500’s hardware and software. Critically, it explained and detailed the instructions that could be handled by the CPU in both assembly code and its machine language equivalents. This made it possible for users to write complex programs in assembler, and to poke the corresponding machine code into the PC-1500 memory. The result was a program that ran many, many times faster than a BASIC program.
I loved the whole challenge of writing complicated programs in assembler and was (then) young enough to learn the language and remember the many commands. I must have spent many hours with the Technical Reference Manual at my side: many of the pages are now completely loose!
The Sharp Technical Reference Manual was a really nicely produced book. As well as very thorough descriptions of PC-1500 assembler language, it also showed how the PC-1500 memory (ROM and RAM) were laid out. What it did not provide was details of the Sharp proprietary machine code that interpreted user’s BASIC programs. Consider a line such as this…
10: INPUT “What is your name? ”; A$
You know that, somewhere in the computer’s memory, there is a machine-code routine that displays the string “What is your name? ” and waits for you to input A$, which is then passed somewhere to memory. But you have no idea of the memory address where that machine code starts to run.

Fig. 1

So I wrote PROBE! It’s a kind of reverse assembler. When you run PROBE! you input a memory address and the program prints out the machine code that starts at that address. In fact, it does a lot more, because PROBE! doesn’t merely read the hex bytes: it reverse-interprets the machine code so a sequence of assembler instructions is printed out by the CE-150. The user can even select an option for PROBE! to follow branches and jumps in assembler, in which case the output should reflect precisely the way a particular routine carries out its function. The catch is that you have to be lucky or accurate in your chosen starting memory address, or the output will not be helpful. It’s the equivalent of translating DNA codons out of phase.
When I’d finished putting PROBE! together, I contacted Ronald Cohen, who produced the monthly magazine called Status 1500. PROBE! was far too long and complex a program for Ronald to print it in the magazine, and for readers painfully to copy it to their PC-1500s. The answer was to sell the program ready loaded on cassettes. (It may seem incredible, but the idea of paying for ready-to-run software was still pretty novel in the mid-1980s!)
Ronald advised I should charge a high price. I was unhappy to do so: I was unsure how well the tape cassettes I produced would run on other people’s set-ups, and I have never really been an entrepreneur. I advertised the program in Status 1500 at £4 per cassette. To my amazement, I received about 30 orders, all within just a couple of weeks.
Let me end this story with a confession. I hope the people who bought PROBE! had more success with it than I did myself. I quickly tired of randomly guessing where built-in routines might start, and ultimately I just developed the skill to write my own assembler code. As far as I can recall, I never used any output from PROBE! to help me develop my machine-code programs!

You can download Probe! files here :
User manual, Bas file, Wav file

Thank you very much Frank !!!
Readers, enjoy this gift and thank you for your feedbacks.

Fig. 1. The opening of my machine code program EASI-THOUGHT from the hand-written original. In the left-hand column I have noted what a routine does. The centre column shows the instructions in assembler, and the right-hand column gives the appropriate machine code hexadecimals, as copied from the Sharp Technical Reference Manual.