🚀 go-pugleaf

In article <903@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:
>In article <3487@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>>
>> ....  About 7 years ago, I disassembled the BASIC ROMs on my TRS-80 Model I
>> I noticed a curious piece of code (which I will pseudocode here):
>> 0998	LOAD	(C), 0
>> 1000	LOAD	(AB), 0112
>> 1003	LOAD	(AB), 0212
>> 1006	LOAD	(AB), 0312
>> 1009	real stuff
>> ....
>> They were taking advantage of the fact the the 12 in 12xx in the operand
>> field was also the operator for LOAD (C)!  They were jumping in to the
>> middle of instructions ...
>
> Without examining it too closely, it seems to me that it is MUCH more likely
> that you are disassembling on the wrong boundaries than the code is jumping
> into the middle of instructions!!  Interpreting binary dumps can be VERY
> misleading!

I was NOT dissembling on the wrong boundaries!!  Let me explain the
circumstances which lead to this discovery and the reasons I think that they
coded it this way.  (Besides, what are the odds of finding what looks like
useful code if you disassemble on the wrong boundary??)  Please excuse any
Z80 notational problems in this; it's been about 5 years since I last
programmed in Z80 assembler. :-)


I was writing some assembler functions to be called from BASIC (via the usr()
function call, I think), and I needed to produce error messages in case the
input was bad, overflow occurred, etc.  I wanted these errors to be trapped
like all the other errors that a BASIC program could produce (ie, if
the user of this function had an "ON ERROR GOTO" statement in his program, the
program should jump there if an error occurred and the correct value should be
in ERR).  In order to do this correctly, I disassembled the code that traps
errors (I was simply going to JMP to it, but I had to know what needed to be
put in each register).

Just before the standard entry point to this routine, there were three
statements which loaded the BC register with three different values.
(BTW, Looking throught the routine, I noticed that it didn't use the
value loaded into BC.)  Wondering
why this seemingly useless code was here, I looked for all the references to
those locations and found out that all the references JMPed into the middle of
the LOAD BC instructions.  Disassembling from the place that was JMPed to, I
found that the instruction was LOAD E, which was what all the other routines
did before JMPing to the standard entry point for this routine!


Now to explain the reasons why I feel that it was done this way.  Suppose you
were using the E register and you wanted to check for an error condition.  If
it occurred, you would have to branch away, load E with the correct error
value, and JMP to the error handling routine.  This takes seven bytes (2 for
the branch, 2 for the load E, and 3 for the JMP).  If you JMP into the middle
of the the load BC instruction, you only need 6 bytes (3 for the JMP, 2 for the
load E, and 1 for the load BC opcode--this was needed so that others JMPing
into this routine before your entry point would ignore the LOAD E instruction).

They had to fit all of BASIC in a 12K ROM, and every trick in the book had to
be used to conserve memory (if I remember correctly, on the original release
they did it with 8 bytes to spare).  They had to be excellent assembly language
programmers to find tricks like this!  I take my hat off to these coders (as
well as the original Apple ROM writers); they did some of the most impressive
assembly work that I have ever seen!
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah