Learning machine code

[EdToo]

How on earth did people learn machine code back in the 80's? I remember my school used to have a regular day when someone would come from outside with a selection of books that we could buy. I bought Supercharge your Spectrum on one of these occasions, with the intention, to learn machine code.

My childhood memories were that after trying to follow it I decided machine code was not for mortals such as me.

Fast forward to now. While clearing out my loft I found the offending book and thought I would revisit it while I have some spare time. I typed in the basic listing for the Hexaid program to enable me to lower the ramtop and poke in machine code. This went well, the first machine code program ran and displayed. However, there didn't seem to be any explanation of the machine code. Flicking through the book I found on Page 178, Appendix C the sentence "In this book I have refrained from attempting to teach the reader how to program in machine language". No wonder I got nowhere as a kid, at least open the book with that message.

So I thought let's go back to the book I should have bought in the 80's Spectrum Machine Language for the Absolute Beginner. Perfect! Except I have just got to the first basic listing designed to convert decimal numbers into hex.

Code: Select all

100 REM Decimal to hexadecimal conversion
110 PRINT "Please input decimal value."
120 INPUT n: PRINT n
130 LET s$="" 135 LET n2=INT (n/16)
140 LET n1=INT (n-n2*16)
150 LET s$ = CHR$((n1(=9)*(n1+48)+(n1 )9)*(55+n1))+s$
160 IF n2=0 THEN PRINT : PRINT "HEXADECIMAL = 0";s$;"H": FOR I=1 TO 200: NEXT I: RUN
170 LET n=n2: GO TO 135

The listing is clearly messed up on line 130, I'm presuming 135 should actually be :
It is also messed up on line 150 though I haven't figured it out yet.

Back to my question how did anyone learn when the reference books (and magazine type-ins) were riddled with errors?

[Twig]

I'm pretty sure I did the same thing a while back. The listing being incorrect put me off continuing with it.

I've installed this - https://github.com/OniDaito/speccy/

But I'm not sure how to progress from there (if any book is best for getting started?).

[AndyC]

Looks like there should be a newline before 135, as it's a separate line.

And

150 LET s$ = CHR$((n1(=9)*(n1+48)+(n1 )9)*(55+n1))+s$

Should be

150 LET s$ = CHR$((n1<=9)*(n1+48)+(n1 > 9)*(55+n1))+s$

[EdToo]

150 LET s$ = CHR$((n1(=9)*(n1+48)+(n1 )9)*(55+n1))+s$

Should be

150 LET s$ = CHR$((n1<=9)*(n1+48)+(n1 > 9)*(55+n1))+s$

Thanks, Andy, just finally worked it out I thought I had totally lost my grasp on how basic worked until I realised it is working out if it need to display a letter once it is higher 9.

I can only assume whoever typed the book up from the programmer's draft didn't think there was any difference between < and ( . A few years too late to ask for my money back.

[EdToo]

I'm pretty sure I did the same thing a while back. The listing being incorrect put me off continuing with it.

I've installed this - https://github.com/OniDaito/speccy/

But I'm not sure how to progress from there (if any book is best for getting started?).

How to Write ZX Spectrum Games by Jonathan Cauldwell, seems a lot better though more slewed towards games programming. I'll probably end up going back to that one. Currently, I'm trying to discover whether I could easily have taught myself back in the 80's.

[EdToo]

Looks like there should be a newline before 135, as it's a separate line.

Doh! Totally missed the obvious, I even noticed the last line goes back to 135 and didn't twig

[AndyC]

FWIW, this was the book I used:

https://archive.org/details/an-introduc ... enfoldacme

It's not at all Spectrum specific and you'd need an assembler to make use of it, but I found it particularly helpful in describing how everything works. I still have my very dog eared copy (minus the cover which fell off at some point) to this very day.

[Ast A. Moore]

Back to my question how did anyone learn when the reference books (and magazine type-ins) were riddled with errors?

Yeah, that was a bummer. Here’s the thing, though. It’s a mistake to think you need to learn machine code. In reality, machine code in and of itself is quite simple. What you really need to learn is how the Spectrum works, i.e. its basic architecture: the CPU, RAM, ROM, ULA, I/O, the address space layout. Being a very simple machine, it lends itself very well to studying in detail. Then you need a crash course in how the Z80 works. Then you can go ahead and start dabbling in machine code; otherwise, it’ll probably won’t make much sense to you.

[ParadigmShifter]

I don't think you need to know about IO or the ULA really.

All you need to know is where the ROM is (maybe with ROM calls to help you out at first, so you need to know the useful ones), how to change stuff on the screen, SYSVARS if you use the ROM, where it is safe to put your code, that's about it when starting out... the only IO you need is how to read the keyboard (but there is a sysvar for like INKEY$ when starting out). Sound is probably too complicated when starting out, I always use a library for that (BeepFX is good).

You shouldn't be learning from old books these days, it was very hard back in the day to learn from them (I tried and failed). It's much easier now.

First thing you need is a cross-assembler so you can write ASM on a PC and assemble it to binary for an emulator. EDIT: And then you need to know how the emulator debugger works and how to use it.

There's no need to know how to poke opcodes and operands into memory these days at all.

Jonathan Cauldwell's PDF is excellent, I agree with that, Chibikakumas is pretty good too.

EDIT: If you want a book that does not just deal with game programming then Rodney Zak's book is still the best.

[1024MAK]

@EdToo Try Mastering Machine Code On Your ZX Spectrum by Toni Baker.
link to PDF version

Also, have a read of this page of reviews of books about machine code...

Mark

[AndyC]

All you need to know is where the ROM is (maybe with ROM calls to help you out at first, so you need to know the useful ones), how to change stuff on the screen, SYSVARS if you use the ROM, where it is safe to put your code, that's about it when starting out... the only IO you need is how to read the keyboard (but there is a sysvar for like INKEY$ when starting out). Sound is probably too complicated when starting out, I always use a library for that (BeepFX is good).

You shouldn't be learning from old books these days, it was very hard back in the day to learn from them (I tried and failed). It's much easier now.

The problem with using the ROM is that it encourages thinking about your assembly code as if it were BASIC and that tops out the usefulness very quickly. Personally I think learning how to "hit the hardware" directly teaches you more quickly, as long as you start with simple problems like drawing patterns on the screen etc. Where people do tend to fall over is jumping straight in at the deep end and wanting to write the next RoboCop, without having ever managed Hello World!

But I'd definitely agree that using old books that assume (or encourage) actually programming on the hardware itself with BASIC routines etc is not a great way of going about it now we have extensive cross development options and emulators with much more powerful debugging tools at hand.

[ParadigmShifter]

That's why I said "maybe using ROM calls to start out". I never use the ROM (maybe I would for load/save or if you only print out chars with RST 16 but I don't like that either since it is so slow and means you need to retain the sysvars etc.

ROM is fine if you are learning (looking at what the ROM code is doing and making it more sensible is better though of course).

Problem with the ROM is it tries to find a general solution where most of the time a solution that fits your needs is better and faster.

[Dr beep]

I read William Tang Machinecode for the absolute beginner.

For coding I used Gens 3m / Mons 3M.

Later I switched to TORNADO.
Now I use crossassemblers.

And I had a book with the complete ROM-disassembly.

[AndyC]

Problem with the ROM is it tries to find a general solution where most of the time a solution that fits your needs is better and faster.

It's not even about better/faster. In fact, I'd say one of the biggest problems for beginners asking for help on modern forums is they'll get a stream of answers full of masses of optimisation tricks when all they really need to begin with is a simple answer.

The problem I see more often is that people try to think up the solution in BASIC, then line-by-line translate that into machine code and that's often where it becomes both difficult and inefficient. It's also difficult to un-learn that process as.you get proficient, so becomes a stumbling block for beginner coders. On balance, I'd say it's better to ignore the ROM (except maybe the "print a character" routine) and just do simple problems in assembly before moving on to more complex topics, including your own "print a character" routine (which everyone should write at least once)

[Jbizzel]

Probably a good place to start is learning the screen.

We did a challenge maybe last Christmas to draw the test screen in machine code

Try doing it without using a ROM call for the text



Certainly, understanding the screen is essential

[ParadigmShifter]

Yes definitely start with the screen (maybe attribs since that's easier).

You need to understand the "contents of" a register for that though i.e.

ld hl, $5800 ; start of attribs
ld (hl), 0 ; set it to black ink black paper

which is a bit more complicated than most books start out with.

But doing stuff like that (next off, fill whole of the attribs area, then do stripes, then do checkerboard) is a good start.

[AndyC]

I'm going to be contrary. Don't start by trying to learn the screen, it's weird and complicated. You want to start out by doing really, really simple things like counting to 10 or adding up a list of numbers etc.

In the old days this was tricky, because you needed some way of checking the results were right. In modern times, however, you can just get used to using the emulator debugger to let you "see" the values held in registers etc. Which is why I'm not sure you really need to deal with the "print a character" stuff anymore (that used to be the easiest way to get some sane output).

When you're confident with loops, registers, reading and writing values from memory etc, then you can start worrying about how the screen memory works. It's a lot easier to learn any programming language if you take baby steps each time rather than starting out with a big idea and stumbling over little things.

[Jbizzel]

Are you using an emulator or pasmo or what?

The first step is getting comfortable with you rig.

I am quite amused that there might be a good first step before this.

[Hedge1970]

@EdToo Try Mastering Machine Code On Your ZX Spectrum by Toni Baker.
link to PDF version

Also, have a read of this page of reviews of books about machine code...

Mark

I am on my third attempt using “Mastering Machine Code”. First I tried using the spectrum Zeus assembler and disassembler programs by Crystal. This was my first ever attempt at both machine code and the programs, I really stumbled at the first attempts with the books examples but I did learn about the construct and general principles of machine code. My second attempt was using Pasmo and a text editor (notepad ++) I got a lot further this time and almost managed to complete the draughts game and got my first own program snippets working but I struggled to follow all the examples in the book using pasmo and was not able to learn everything due to this. I am now in my third attempt but this time I am doing it using the books own machine code program. Now of course I’ve learned from each previous attempt but I am finding this attempt the very best of all three. The only down side to this book is she/he does not spoon feed you. So at the end of each chapter are a couple of self learn “can you do this…” type questions but with no answers or examples showing how to do it! Some will like this others hate it, I sometimes just wish I had the answers but equally feel very pleased with my self when I get the result she asks for.


Good luck!

[Mpk]

You want to start out by doing really, really simple things like counting to 10 or adding up a list of numbers etc.

Have to agree with this. Learn the grammar first, then think about what you want to do. For a project, I started by porting a BASIC listing into ASM. Learned a lot about how the fundamentals worked ( PUSH & POP etc. ) that way, and it was a manageable target.
J. Cauldwell's book is good, and explains the mechanisms well.

I always recommend the Zeus GUI for learning, it has a debugger built in and is very friendly.

As for learning back in the day - I've no ide how anyone did it on original hardware. It's so easy to crash & corrupt everything, I can't imagine constantly saving and loading from tape.

[AndyC]

As for learning back in the day - I've no ide how anyone did it on original hardware. It's so easy to crash & corrupt everything, I can't imagine constantly saving and loading from tape.

It was a deeply painful experience. A microdrive or disk drive was pretty much essential, as was learning to reason about code without running it as much as possible.

It wasn't a good experience though and it certainly doesn't make you a "better" coder. It's why I always encourage people to use modern tools when they want to learn. I know some people think it's more "authentic" to do it old school, but honestly we used crappy tools because it was the best available - had any of us had access to better at the time you can be sure we'd have jumped at the chance.

[ParadigmShifter]

The main problem with developing on a real machine is the lack of a debugger and Z80 not having a debug break instruction so breakpoints/single stepping is not really viable. (Although I think there may be a debugger that replaces opcodes with a call to the debugger maybe so can use that for breakpoints).

I use sjasmplus as my assembler and Spin for emulator. The debugger in Spin is pretty good although I've not worked out how to get symbols imported (so I just refer to the symbol file sjasm produces if I need to inspect variables). The memory window isn't very good in spin though

[Jbizzel]

Im I right in saying many games back in the day were not written on an actual spectrum?

Except for r type - Bob Pape is bad ass.

[AndyC]

Im I right in saying many games back in the day were not written on an actual spectrum?

Except for r type - Bob Pape is bad ass.

Really early ones possibly were, but as time went on it certainly got a lot more likely that professional software was produced using more powerful machines like STs or PCs with some kind of (usually slightly bogged) interface for pushing data onto the Speccy as fast as possible.

[1024MAK]

I am on my third attempt using “Mastering Machine Code”. First I tried using the spectrum Zeus assembler and disassembler programs by Crystal. This was my first ever attempt at both machine code and the programs, I really stumbled at the first attempts with the books examples but I did learn about the construct and general principles of machine code. My second attempt was using Pasmo and a text editor (notepad ++) I got a lot further this time and almost managed to complete the draughts game and got my first own program snippets working but I struggled to follow all the examples in the book using pasmo and was not able to learn everything due to this. I am now in my third attempt but this time I am doing it using the books own machine code program. Now of course I’ve learned from each previous attempt but I am finding this attempt the very best of all three.

We are fairly certain that Toni is a woman.

Unfortunately, one of the problems when learning machine code, is, that assembler language is one person or one organisations mnemonics. Not all assemblers use the exact same set of mnemonics (compare the 8080 compatible instructions used on the Z80 with the 8080 mnemonics. For the exact same machine code instruction, mnemonics are often different).

Just to be clear, a machine code instruction as far as a 8 bit microprocessor is concerned is one, or a short series of numbers, each in the range 0 to 255 (decimal). The mnemonics are for use by humans, as we find working with long series of numbers hard work and are likely to make mistakes if we try to write long programs using this method. Using hexadecimal numbers only makes this slightly easier.

An assembler takes the mnemonics and the values (source code), and processes this to produce the actual machine code (known by various names, including object code, binary, executable, depending on if a linker is being used, or if this is an intermediate stage, or the final output file).

Secondly, each assembler is different in terms of symbols (which of these are acceptable for meaning a hexadecimal number "#nn", "$nn", "&nn" or 0xnn), assembler operations/operators (instructions) (as opposed to actual microprocessor instructions) and acceptable syntax.

Then there are different methods for the layout of the code (does it use tabs or spaces, do labels need a prefix or a suffix?).

And then there are the undocumented instructions that, because they are not documented by the microprocessor manufacturer, can't have 'official' mnemonics. And don't even start me on macros...

Actual machine code is very simple. As it has to be. Because for the 8 bit microprocessors like the 8080, Z80, 6800, 6502 etc, they only understand 8 bit binary numbers (yes, parts are 9 bit or 16 bit, but in memory, it's all 8 bit).

Break the vast majority of microprocessor instructions down and most are just copy instructions (LD), simple maths instructions (ADD), jump/branch (including subroutines) or combined with yes/no decisions.

Mark