22 Feb
2009
22 Feb
'09
11:50 p.m.
Ok, sorry for continually replying to my own posts, and sorry for
spamming the group with stuff, but I found the answer.
And the answer comes from Rick, c. 1999 :).
http://www.classiccmp.org/pipermail/cctalk/1999-February/120292.html
Looks like, based on that encoding, it's just the lower-nybbles of each
pair of characters forming one machine code byte. Makes sense :). (I
swear I tried this without success earlier, but now I'm having better
luck...)
Now to figure out everything else. Now I wish I had a bitmapped display
to make debugging easier :).
Josh
Josh Dersch wrote:
Small correction: The string "EXEC" takes
does not seem to need to
only hexadecimal digits, the only requirement seems to be that it have
a non-zero, even length.
So I'm unsure of the encoding -- strings on the Tek are limited to
7-bit ASCII, so using CHR() to build a string directly from 6800
machine codes isn't going to work. Given that the call requires an
even-length string, clearly two characters are combined somehow to
form one machine code, but how isn't immediately obvious. I've played
around with a few simple combinations with no luck so far.
Josh
Josh Dersch wrote:
Looks like your memory is not too bad... the
documented method for
calling ROM code (in expansion packs) is via the "CALL" command with
a string that names the function to be called. (i.e. I have the
EDITOR rom, and that's invoked by doing 'CALL "EDITOR"').
Well, I just tried this:
A$="ABCDEF"
CALL "EXEC",A$
And the machine immediately reset and gave me a system error :). So
it seems evident that this was executing the string as machine code
(and crashing horribly).
Further experimentation reveals that the string can only contain
hexadecimal digits (strings containing other characters returns an
I/O error), so I'm wagering that the "EXEC" call does a simple
translation from the hex string to bytecodes, then executes it.
Now to work out various sundry details like calling conventions,
where the code is in memory when it's executed (so I can do jumps)
and then onto more fun things like doing something useful!
Thanks!
Josh
Rick Bensene wrote:
I recall that there was a way to make the 4051
execute machine code. I
don't remember the exact method, but I remember that the bytes of 6800
machine code were encoded into a character string using the CHR$()
function. For example, hex 43 would turn into CHR$(67), or a "C".
The
bytes were put into a string with the limit of program size being the
max. size of a character string. The next part is where my memory
fails
me -- there was a way to cause the BASIC interpreter to branch to the
first character in the string, executing the code there. It involved
doing the transfer in such a way that it was if the code was
branched to
with a "jump to subroutine" call, and when the code was complete, a
"return from subroutine" instruction would be in the code, and that
would cause a branch back to the BASIC interpreter. As I'm writing
this,
a statement called EXEC$ or something along those lines pops into my
head. I don't know if this is any help at all, but I really clearly
remember
seeing 4051 programs (I worked at Tektronix from 1977 to 1990, and
did a
lot of tinkering with 4051/2/4) that filled character strings with
hand-assembled machine code, and had a means to execute it. Hopefully
someone can find some docs that might substantiate these memories and
solve the mystery.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com