Hacker News new | ask | show | jobs
by kunai 4873 days ago
So essentially, this is writing an application in machine code?

This is so fascinating I'm starting to get palpitations. I've always wanted to know how to program in machine code. I've looked through the web countless times in search of something like this, and haven't ever found it, until now.

Thanks for the great insight. This kind of stuff makes C/C++ look like stuff for total newbies. Getting this close to the hardware really is quite mind-boggling.

5 comments

> I've always wanted to know how to program in machine code.

1) Decide which processor you want to program. I'm going to use a Z80, since that's one I'm familiar with.

2) Get hold of a good book, making sure it includes a section that exhaustively describes each instruction and the machine code for each. Eg. "Programming the Z80" by Rodnay Zaks. The microprocessor's datasheet will generally do if your familiar with other processors.

3) Read the book, cover to cover.

4) Make three vertical columns on a sheet of paper.

5) Write your program, in assembly language, in the middle column. Use alphanumeric labels (label means variable name) for all addresses.

6) Decide at what address you want your program to start (the origin)

7) Write the numeric address in the left hand column, next to the first instruction.

8) Look up the machine code, for the instruction in the middle column, in the Zaks book.

9) Write the machine code in the right hand column.

10) Add the length of the instruction (# bytes) that you have just written down to the address, and write the answer on the next row of the left hand column. You might have to leave labels in place for instructions that refer to parts of the program that you have not yet assembled.

11) Repeat from step 8, until the entire program has been assembled.

12) Go back and fill in the numerical addresses for any addresses that are still labels.

13) Now you have to get the program in memory. We're going to assume that a programming language, such as BASIC is available. The alternative is a keypad with address/data entry functions and a method to get an initial value into the program counter.

14) Create a big array, in BASIC, with all the numbers from the right hand column.

15) Write a loop which POKES each numeric value into memory, starting from the origin address.

16) Transfer execution to the origin address, using the a USR(nnnn) instruction, where nnnn is the origin address.

17) Hopefully your program works, but if not, make changes and go back to step 4 until your program works.

Enjoy! In time, the process gets quicker, as you eventually remember the machine code for the the most common instructions and don't have to refer to the book.

If you're writing timing critical code, have a fourth column, in which you record the number of clock cycles for each instruction to execute, and sum those numbers to determine execution time. If you have a target execution time, you will need to add/remove instructions to achieve the target.

If I had a nickel for every hour I spent doing this as a teen... (Sinclair ZX-81, then TRS-80 Model 1.)

Also, that Zaks book rocks. To this day one of the best programming references I've ever used. http://www.z80.info/zaks.html

It is pretty fun. If you have a TI-83 or TI-84 calculator you can do the same thing a little bit easier.

In high school, I would print out 2 pages of all the Z80 opcodes and put them on my desk during class. The calculators let you directly input hex and then run your program with asm(), so I would write my program by hand on paper, and then next to each line translate it to machine code and put it into the calculator. A lot of TI routines are easily accessible with bcalls, so you don't have to reinvent the wheel with each program.

Plus Z80 is a lot easier than x86. (I still remember the return code: C9)

I had a lot of fun taking friend's calculators and disabling the LCD and power button in assembly :)

Neat. I still have my old TI-83 lying around in my cluttered desk somewhere, I'll be sure to try this when/if I find it.
Here's another article which starts with a .c program and refines it through a series of improvements to end up with a very tiny elf executable:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

Manually picking out hex opcodes is maybe a bit over the top. A nice assembler like nasm should be "low level enough" while still providing a lot more convenience and flexibility.

Well of course, nobody writes any applications in hex; it's more of a proof of concept, but a very interesting proof of concept.

Asm, at least for me, is still too low-level for me to do any sort of serious work. I make desktop/mobile apps, and don't really do any sort of kernel hacking, so currently, I'll stick with C++ and Java. It is a nice thing to know, however, I don't see myself learning it right now. It's inevitable that I'll have to learn it sometime in the future if I ever want to broaden my prospects, but it's nice to play around with, but isn't all too useful for me.

Hi, I'm the author. In this particular example, I basically skipped the compiler and linker to create an executable directly, yes. It's certainly a lot of fun, but if you're really trying to become proficient at programming in assembly language, I would recommend reading Assembly Language Step-by-Step: Programming with Linux.
Thanks. I'll be sure to check it out when I get into programming asm.
We did it all the time in the early eighties, with machine language monitors.