From: Jonathan Wienke <JonWienk@ix.netcom.com>
Date: Sat, 11 Oct 1997 12:29:14 +0800
To: Jim Choate <cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: Re: 6502 ML programming
In-Reply-To: <199710090439.XAA16340@einstein.ssz.com>
Message-ID: <3.0.3.32.19971010211816.02fa1704@popd.netcruiser>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Boundary..3985.1071713739.multipart/signed"

--Boundary..3985.1071713739.multipart/signed
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

At 11:39 PM 10/8/97 -0500, Jim Choate wrote:
>Forwarded message:
>
>> Date: Wed, 8 Oct 1997 23:10:26 -0400
>> From: ghio@temp0132.myriad.ml.org (Matthew Ghio)
>> Subject: Re: [LONG, off-topic]] Interactive Programming
>
>> Reminds me of a time, years ago, where I was trying to modify a program
>> written in 6502 assembler.
>
>> Consider the following line of C code:
>> 
>>   result = function(x,y,z);
>> 
>> One could write this in 6502 assembler as:
>> 
>>   JSR function
>>   DATA x
>>   DATA y
>>   DATA z
>>   STA result
>> 
>> where x,y,z,result are pointers to storage locations.
>
>There in no 'DATA' construct in 6502 assembly.
>
>This is some sort of macro that either the assembler or programmer
>defined. All official Rockwell/Commodore [1] 6502 assembly mnemonics are
>three letter. There are NO official macro's from MOS Technologies under
>either Rockwell or Commodore other than the ORG. ORG simply defined the
>starting address for the target code.

I concur.

>The most efficient way to store data in 6502 is to put it in the first 256
>bytes of ram, then it could be called in no more than 2 clock cycles. Also,
>in 6502 good programmers use the branch instructions (BCC, BCS, BEO, BMI,
>BNE, BPL, BVC, BVS) because the JSR required three bytes versus 2 bytes for
>a Bxx. The only constraint was that the branch target must reside in the same
>256 byte page as the branch itself. The biggest boo-boo committed here was
not
>realizing that branch offsets that took you across the upper page boundary
>would leave you at the lower page boundary plus some remaining offset.

This is not quite correct.  I can't seem to find my Commodore 128
Programmer's Reference Guide, (of all the things I lost going to the PC, I
miss my PRG the most.  It contains complete BASIC & assembler language
reference guides, lists EVERY memory address used by the OS and what it
does, register-level programming info on every chip, and even schematics
for my 128!  Unfortunately, nobody seems to publish such a book for PC's,
but I digress.)  The branching instructions used 1 byte for the in
struction, followed by 1 data byte which was a signed integer.  This
allowed one to branch up to 127 bytes ahead, or 128 bytes back from the
current instruction address register value.  The coolest thing about this
was that if you were able write your code to branch and not JMP or JSR,
your code could be located anywhere in memory and it would work perfectly,
which was very useful when writing interrupt wedges that were supposed to
work on the C-64 and the C-128, or that could be loaded in various places
in memory.

>Idealy a jump table was created that had the various target addresses for
your
>routines. Then a Bxx followed by a indirect mode JMP (NOT a JSR). If that
table
>was in the first 256 bytes it was possible to save a whole clock cycle AND a
>byte in the process. At 64k and 1Mhz clock these sorts of short-cuts were
>significant.

This is where self-modifying code came in handy.  During initialization, a
self-mod routine would increment the addresses in the jump table so they
pointed to the proper addresses of the respective routines.

>Because of the architecture of the 6502 the 0 page of RAM was a very busy
>place indeed because any operation there automaticaly saved a byte and a
>clock cycle.

If I remember correctly, there were all of 5 or 10 bytes available for
"user programs", depending on which OS functions you were willing to break.

My first computer was a Commodore VIC-20. 5 points and Geek of the Week to
the first email correctly specifying the "Basic Bytes Free" on a vanilla
VIC-20.

Real Programmers don't use symbolic addresses.


Jonathan Wienke

What part of "the right of the people to keep and bear Arms, shall not be
infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution)

PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC
Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred.

Get your assault crypto before they ban it!

US/Canadian Windows 95/NT or Mac users:
Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/
Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html

Non-US PGP 5.0 sources:
http://www.ifi.uio.no/pgp/
http://www.heise.de/ct/pgpCA/download.shtml
ftp://ftp.pca.dfn.de/pub/pgp/V5.0/
ftp://ftp.fu-berlin.de/pub/pc/win95/pgp
ftp://ftp.fu-berlin.de/pub/mac/pgp
http://www.shopmiami.com/utopia.hacktic.nl/pub/replay/pub/pgp/pgp50/win/

RSA export-o-matic:
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

--Boundary..3985.1071713739.multipart/signed
Content-Type: application/octet-stream; name="pgp00005.pgp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pgp00005.pgp"
Content-Description: "PGP signature"

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogUEdQIGZv
ciBQZXJzb25hbCBQcml2YWN5IDUuMApNZXNzYWdlSUQ6IC9mZzM4QTJ4eDVw
SkVYM1dsM2dpRHhBNDdkZ3JTR1F4CgppUUEvQXdVQk5ENy9Ic0pGMGtYcXB3
M01FUUlMd2dDZ3VDeGx6M3VOcnFGRVpxc2R2Mms3ZmtNUGlDd0FvTitRCkFX
bTdDd1FIWi8zalpnd3Z0dHRyQmdGSQo9TU9KaQotLS0tLUVORCBQR1AgU0lH
TkFUVVJFLS0tLS0K
--Boundary..3985.1071713739.multipart/signed--