I was recently reminded of an mid-1990s comp.lang.asm thread about programming in x86 assembler... using just the ASCII characters-- that is, the opcodes and oprands being limited to 0x20-0x7E --and the newsgroup went as far as producing a xmodem bootloader (..and quite possibly inspired a lot of exploit shellcode over the following decade..). The idea is certainly older than the 1990s, as ZX81 programers had their machine-code-in-REM statements trick. I checked and I couldn't really find anything for the 6502, which left me sleepless, so I started researching it myself.

With the vanilla 6502 CPU, $20-$7E doesn't give you much-- however most importantly the JSR, JMP, and RTS instructions is in there, and SEC BMI PHA PLA AND BIT ROL EOR LSR ADC ROR are what you have to work with. (SEI CLI PLP BVC BVS RTI as well, but they're next to useless here.)

The only memory-modifying (outside of the stack) instructions in the set are the bit-rolling ops ROL, ROR, and LSR-- so if you want to write to memory... guess what you've got to do!All the register-immediate instructions are up around $Ax, so a LDA_XXXX macro is needed, or a bit more efficiently:Executable code-- at least anywhere you need to read, write, branch or jump to, has to be in areas of memory with the $20-$7E limit as well ($2020-$207E, $2120-$217E, ... $7E20-$7E7E). Code can reside beyond those areas, however it won't be possible to refer to it (LD/ST/JSR/JMP).

The only practical branch instruction BMI can only skip forward $20-$7E bytes.

What does an actual working 'printable 6502 machine code program' look like you ask? :) .. Here's a sample!...this is Shellcode for the Commodore 64! :D ... The assembler source: http://kildall.apana.org.au/~cjb/C64/decode-ascii.asm

Progress photos from this little experiment are on my Twitter account : https://twitter.com/Chris_J_Baird/status/867611129073160192 ... https://twitter.com/Chris_J_Baird/status/867170413444333568

https://web.archive.org/web/20170714132 ... m/slammer/

Mike B.

[edit: updated dead link. Thanks, Ed]

An interesting technical challenge, Chris!

I think, Mike, that Slammer! is an interesting idea too, but different, because while it supports printable-only machine code, the tool itself, which in effect unpacks that machine code and causes it to be executed, is not written in a printable-only dialect. (Edit: I'm wrong - see below)

Wow, thanks for posting. This is supremely absurd -- I love it!!

As loaded, yes. But is there any prohibition on self-modifying code? (It won't be the only example where SMC can make a dramatic difference.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yep! A little shifting, masking, inverting, etc., on the memory-resident code and suddenly most of the instruction set might become available. Of course, figuring out what to shift, mask, invert, etc., to produce the desired results would be the real challenge.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Are you sure about that, Ed?

https://web.archive.org/web/20170818125 ... LAMMER.TXT

Mike B.

[edit: updated dead link ... thanks, Ed]

Interesting! Slammer has been slammed. In hindsight, that's obviously possible. Thanks for the correction.

Well, you really don't need more than a base-16 decoder, a bit like I've already done :)

But yes-- a year ago I was playing around with One Instruction Set Computers, and there the challenge was even more extreme, having to find efficient ways to produce even the simplest instructions.

An idea I considered (but dismissed attempting in the concept code for being too memory-hungry and needing a lot of initialization) would be to take a cue from indirectly-threaded FORTH, and make most of the whole instruction set JSR'able.

(I've updated the code on the link in the OP, too-- I'd missed a non-ascii "adc #1" instruction.)

I recall the cable cross link between PC use ascii to
boot strap on another machine ( I forget what it was called ).
You used the serial cable to down load the ascii and then
changed the name to *.com and executed it. It would then
read the rest of the files across the cable.
Once there, you could then use the parallel cable that
was fast. It was something link or link something.
Oh well, a little more brain fade.
Dwight

"LapLink", perhaps? https://en.wikipedia.org/wiki/LapLink_cable

Yep, that was it. Thanks
Dwight

The Wikipedia article incorrectly shows pins 18 of each plug being wired together. Those two are "no connects."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

https://en.wikipedia.org/wiki/LPT#Pinouts

ETA: it's possible that some printer cables don't bother to connect all the grounds, and treat pin 18 as a No-Connect. Nevertheless, BDD, the spec says pin 18 is Ground. Your criticism of the Laplink connection chart is plainly, um, groundless!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Oops! I was thinking of pin 18 on the 36 pin Centronics connector that is on a printer. Most printers apply 5 volts to pin 18.

Time for me to retire from this electronic stuff when I can't keep stuff I've worked with for some 40 years straight in my head anymore.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!