The definitive "teach yourself machine code" text?

[dfzx]

Just to clear up a couple of your misunderstandings...

First, absolutely no one is going to point and laugh at anything you produce. We all started right at the beginning, just like you are.

Second, your BASIC program might well occupy 76 bytes, but don't forget it needs 16,384 bytes of BASIC interpretter code to make it work. Those 76 bytes aren't really a program by themselves, they need the 16K of code in ROM to make them do something.

Third, you don't need to know anything about transistors, or buses, or the workings of the ULA to write ZX Spectrum Z80 code. You don't need to be able to do hex calculations in your head. The fact you already understand how the display file works, and how you can change what the user sees by changing values in that area of memory, shows you probably already know enough to write a little game.

It actually seems like you've done the hard bit, but it hasn't quite gelled in your head yet.

Why don't you try writing:

10 FOR n=22528 TO 22879: POKE n,15: POKE n+352,48: NEXT n

in assembly language? There's a useful lesson in just that little line.

[Morkin]

What you really need to learn and understand is how the Spectrum works. Learn and understand its architecture (it’s fairly basic), what each component (you can access as a programmer) does, and how to interpret its state or change it. Then figuring out how to program becomes the easy part.

I cannot stress this enough—there is absolutely no point in trying to “teach yourself machine code,” if you don’t have a good handle on how computers work. So, start with that. Here are some of the topics you should become familiar with (in no particular order):

1. What is a CPU?
2. What is data? What is code? The concept of duality of data and code.
3. The binary system; why it’s relevant for programming
4. Input and output
5. Data/code storage and retrieval
6. Data and address buses
7. How the video signal is formed by the ULA.
8. Where the ULA gets data to display on the screen.

...I'd probably slightly disagree with this - I don't really know much (if anything) about computer and Speccy architecture, or how the hardware works at all at an electronic level, how the computer actually deals with your code etc.

I'd say when I was learning assembly I only really learned (3) and (5) in this list and that was enough to learn enough to write two Speccy games. I think the other elements may be more important at a more advanced level - e.g. super-smooth movement and syncing with the display beam (which you can tell [mention]Ast A. Moore[/mention] is a wizard at if you look at his Yankee game). I'd argue that they can come (much) later.

On the book front, I personally dipped in and out of books, and used most of them for reference - I'm not sure if there was a single one that taught me everything (and I clearly still don't know everything!).

I totally agree with Project 1 - just starting out with just trying out your own code doing bits and bobs, however messy it is - if it works, it works!

Personally I'd suggest not worrying about Project 2 (optimization) unless you're running out of memory. But if you're at that point it's likely that you probably know enough as you'll have written a fairly hefty program - you'll find even messy and convoluted assembly code takes up infinitely less space than a BASIC program. But if you want to do it, then go for it, I'm sure it's all good for learning.

[Ast A. Moore]

Is understanding the internal workings of the Spectrum more like that? In other words, "this is the Z80, this is the ULA, this is the bus, they do this", but I don't need to know the internal structure, i.e. why an extensive network of thousands upon thousands of transistors laid out in this very specific way produces the result that it does.

You got it. I mean, knowing a little bit of electronics will always come in handy, but strictly speaking, it’s not necessary for programming (at least for the Spectrum). But you do need to know the underlying logic of computer operation. In other words, it’s not necessary to study the photographs of the die of the Z80 to understand what a register or ALU looks like at a physical level. You do, however, need to learn what a CPU is, what it can and, most importantly, what it can’t do, how to feed it the numbers to crunch, and how to retrieve them for use later.

As for your other question about program size vs. speed, comparing higher-level programming languages such as BASIC with low-level ones, such as assembly, is never straightforward. In many ways, higher-level languages are a compromise between efficiency and legibility. For example, the Z80 cannot multiply or divide two arbitrary numbers. (It can, however, multiply and divide by two.) So, when you issue a simple instruction in BASIC such as LET a=x*y, a whole lot of code of the BASIC interpreter residing in ROM will be executed. Some of it will be the BASIC parser itself, and some will be a special routine that will multiply the two numbers by using several iterations of additions. So, your (roughly) six bytes of BASIC will actually translate to a few dozen bytes of machine code.

[Ast A. Moore]

I don't really know much (if anything) about computer and Speccy architecture, or how the hardware works at all at an electronic level, how the computer actually deals with your code etc.

I'd say when I was learning assembly I only really learned (3) and (5) in this list and that was enough to learn enough to write two Speccy games. I think the other elements may be more important at a more advanced level - e.g. super-smooth movement and syncing with the display beam (which you can tell @Ast A. Moore is a wizard at if you look at his Yankee game). I'd argue that they can come (much) later.

Thank you!

Of course it depends on how one’s particular mind works. Mine can be a little thick, so I need to have a deeper understanding of how computers work in order to use and program them efficiently. Otherwise, the problem becomes too abstract for my poor brain to understand it.

[TMD2003]

Just to clear up a couple of your misunderstandings...
First, absolutely no one is going to point and laugh at anything you produce. We all started right at the beginning, just like you are.

But to clear up your misunderstanding (and that of anyone else who might have made it), I wasn't implying anyone would laugh at my code, it was that you probably would (and should) laugh at the code produced by the Softek Compiler. Which leads us to...

Why don't you try writing:
10 FOR n=22528 TO 22879: POKE n,15: POKE n+352,48: NEXT n
in assembly language? There's a useful lesson in just that little line.

I've already got an idea of how I'd do it, but so far all I know about is LD, INC and JP to get it to loop back. I'm almost certainly going to need a CP in there somewhere so that the computer knows when to stop looping, but I haven't got that far yet. Once I've written the routine that does the same as this BASIC line, I'll send the Softek compiled version through a disassembler, see if it actually does dissasemble into a readable listing (everything I've tried so far hasn't...) and see how it compares with what I wrote from scratch.

Right now I am reading the Usborne Introduction To Machine Code For Beginners. As it's intended for kids in single digits (which, at the time of its publication, I was... just not now), it's incredibly simple and should be understandable even for a complete dunce. There is probably no shame in doing so if James May's revelation about Ladybird books is anything to go by (which I think was in one of his Toy Stories) - grown men in their 40s working for engineering firms kept covert copies of Ladybird's "how things work" books, without their illustrated covers, that they could use as quick and easy reference guides that stated the facts that they needed to know. I just don't need all the cartoonish drawings illustrating everything.

I'd say when I was learning assembly I only really learned (3) and (5) in this list and that was enough to learn enough to write two Speccy games. I think the other elements may be more important at a more advanced level - e.g. super-smooth movement and syncing with the display beam (which you can tell [mention]Ast A. Moore[/mention] is a wizard at if you look at his Yankee game). I'd argue that they can come (much) later.

Ast is clearly a level 99 wizard with intrinsically high magic stats, whereas I'm a level 1 wizard at the moment with whatever stats the random number generator gave me. When I first heard "floating bus", I thought of a lost storyline for if there'd ever been a Chitty Chitty Bang Bang Part II: What Caractacus Potts Did In His Shed After Truly Divorced Him For Spending Too Much Time In His Shed. Maybe, one day, I'll understand it, but that day is still a long way off!

Personally I'd suggest not worrying about Project 2 (optimization) unless you're running out of memory. But if you're at that point it's likely that you probably know enough as you'll have written a fairly hefty program - you'll find even messy and convoluted assembly code takes up infinitely less space than a BASIC program. But if you want to do it, then go for it, I'm sure it's all good for learning.

There is a good reason why I'd want to optimise. Look at some of the things I've shoved on the BASIC Dumping Ground, such as the Mighty Musical Character Sets. They're effectively the culmination of my fascination with user-defined character sets, and in this project I discovered what happens if the set is POKEd too high. What I do is load the character set starting at an address that divides by 256, so that I will never need to POKE 23606 with any other value than its default 0.
i.e.: character set loaded at 64000, POKE 23607,249; character set loaded at 64512, POKE 23607,251.

It is possible to load the character set at 64768 and POKE 23607,252 but the characters from lower-case "k" onwards clash with the UDGs. Even so I thought I'd try it anyway because the musical character set didn't need UDGs (though they might be useful if there were any single-square characters, which there weren't). What I found was, while I was defining characters in the top two rows (i.e. space to _), the characters in the third row that weren't UDGs (i.e. £ and a to j) were becoming corrupted. I was using my own program that defines both character sets and UDGs - it uses no machine code but it also doesn't set RAMTOP to the byte before the character set.

But if I did stick to defining the character set at 64512 so that I can get a full 96 characters in as well as a full set of UDGs and load the whole lot in one go - and if I rememebered to CLEAR 64511 beforehand, then...
LOAD "bytes" CODE 64512,1024 - breaks down as 64512-652769 for the character set, 65368-65535 for the UDGs, and... 65280-65368 unused. That's 88 measly bytes which, if they are left untouched, would be useful for the kind of short machine code routines I might want to include.

So there's my first target for Project 2. The Softek compiler took 97 bytes to do what I want to do; I have to get it down to 88 or less.

[Rorthron]

For what little it's worth, I personally I didn't much like William Tang, Spectrum Machine Language for the Absolute Beginner. I found it spent too much time on vague analogies and too little on the specifics. I preferred Ian Sinclair, Introducing Spectrum Machine Code - How To Get More Speed and Power, and the ultimate Z80 bible, Rodney Zaks, Programming the Z80 (though it's not Spectrum specific). But I am about as far as it's possible to get from a Spectrum assembly expert!

(That's two programming threads I've commented on. I'm not quite sure what's come over me!)

[Morkin]

...I'd almost forgotten what it was like to keep track of UDGs and alternate character sets in BASIC - the beauty of assembly is that you can just use text labels instead, and store pretty much as many graphics as you want to design.

...It would be interesting to see what the compiled BASIC code looks like.

Of course it depends on how one’s particular mind works. Mine can be a little thick, so I need to have a deeper understanding of how computers work in order to use and program them efficiently. Otherwise, the problem becomes too abstract for my poor brain to understand it.

Of course - the fact that most tutorials start off with that stuff indicates that some people like to start from the ground up in a structured way.

[BenHanson]

Hello,

You obviously are nearly there. Here is the complete code:

ORG 23296
LD BC, 352 ; Counter
LD HL, 22528
LD IX, 22880
LOOP:
LD (HL), 15
LD (IX+0), 48
INC HL
INC IX
DEC BC
LD A, B
OR C
JR NZ, LOOP
RET

I have been working on my own Z80 assembler in C++ and poking around I came across your question. From what you've said already you should be able to follow the code OK. The complication is that DEC BC does not set the zero flag, so you have to involve the A register.

Hope that helps!

Regards,

Ben

[AndyC]

Firstly forget worrying about transistors or low level electronics or any of that nonsense. What you need is a reasonable (but by no means perfect) logical model of how the spectrum operates. Knowing things like the fact that instructions are fetched from memory one at a time, change values held in "register" depending on the commands and that manipulating certain memory addresses or IO ports make things happen on screen etc.

And don't worry about size of code etc right now, certainly don't worry about comparing it with BASIC. A single PRINT command may only take a byte, but the implementation details of it along with the interpreter itself is enormous, so it's comparing apples and oranges.

Finally start with really, really small examples. Play around with trivial tasks like clearing the screen or adding a few numbers together. You can learn a lot more by experimenting with changing simple short programs than by diving head in and trying to write complex sprite routines. Allow yourself small victories and in no time you'll be ready for bigger ones.

[TMD2003]

Hello,
You obviously are nearly there. Here is the complete code:
ORG 23296
LD BC, 352 ; Counter
LD HL, 22528
LD IX, 22880
LOOP:
LD (HL), 15
LD (IX+0), 48
INC HL
INC IX
DEC BC
LD A, B
OR C
JR NZ, LOOP
RET

I have been working on my own Z80 assembler in C++ and poking around I came across your question. From what you've said already you should be able to follow the code OK. The complication is that DEC BC does not set the zero flag, so you have to involve the A register.

Hope that helps!

Strangely, at around the same time PeterJ just sent me an email with a list of codes to disassemble, to see if I could work out what it was doing - and it fills the screen in inked-in pixels, a row of eight at a time, and does it so quickly I barely have time to notice. His listing doesn't involve IX at all - but it does involve that LD A,B and then OR C so this must be the magic part of the code that tells the computer when to stop looping.

That's a fine introduction to the forum, and then some.

Finally start with really, really small examples. Play around with trivial tasks like clearing the screen or adding a few numbers together. You can learn a lot more by experimenting with changing simple short programs than by diving head in and trying to write complex sprite routines. Allow yourself small victories and in no time you'll be ready for bigger ones.

I've thought of something I might want to do which could be useful - convert a decimal number (0-255) to binary, and fish out individual bits from the byte. I'm starting by converting the ZX81 "Hex Bin Converter" from Sinclair Programs in April/May 1983 to the Spectrum so I can see how it works, and being a ZX81 listing it's strictly one statement per line.

Why I might want to do this: I can see why I might need the ATTR function broken down into smaller chunks, and thought I could do it via some DEF FNs, i.e.
DEF FN f(r,c) = ... returns 1 if the square is flashing, otherwise 0.
DEF FN b(r,c) = ... returns 1 if the square is bright, otherwise 0.
DEF FN p(r,c) = ... returns the paper colour of that square.
DEF FN i(r,c) = ... returns the ink colour of that square.

The first is easy enough... test ATTR(r,c) and see if it's 128 or more. FN b involves a hit more manipulation (i.e. ATTR(r,c) is >=64 and <=127), but FN p and FN i will involve a string of three bits that then have to be re-converted to decimal. Something tells me this would be (a) slow and (b) actually easier in machine code, with its shift-the-bits-left-and-right opcodes.

[AndyC]

It's not a bad place to start. You'll want to look at how AND works in a bitwise fashion, along with the shift and rotate operations. And possibly BIT for testing things like Bright and Flash.

[BenHanson]

- LD A with your byte
- Use BIT 7, A to test whether the top bit is set
- Use SLA A to shift the bits in A left
- Loop back to the BIT 7, A check

LD B, 8 ; Counter
LD A, %00110100
Loop:
BIT 7, A
JR NZ, set
; print 0 here
JR next
set:
; print 1 here
next:
DJNZ Loop
RET

[TMD2003]

Right, everyone, what's going on here? I'm testing the routine that's supposed to return a zero so the computer will jump out of a loop, so I wrote a short program to see if OR C does what I think it's doing.

I can't LD C,(address), I can only LD A,(address). Hence, if I do this:
POKE 65024,177 - 0xFE00, if you didn't notice, to make the code slightly easier
POKE 65025,162

And then run this routine:
LD A,(65025)
LD C,A
LD A,(65024)
OR C
RET

There should be the values 177 in A, and 162 in C. I'm expecting a bitwise 177 OR 162 (10110001 OR 10100010) which is 179 (10110011).

I get... 60066, the second byte of which is 162, i.e. C.

What is C being ORed with, if it isn't A?

EDIT: I should probably include the BASIC listing in case I've made an error I was unaware was an error:
10 CLEAR 59999
20 FOR n=60000 TO 60008
30 READ bt: POKE n,bt: NEXT n
40 DATA 58,1,254: REM ld a,(65025)
50 DATA 79: REM ld c,a
60 DATA 58,0,254: REM ld a,(65024)
70 DATA 177,201: REM or c | ret
80 INPUT "A? ";a,"C? ";c
90 POKE 65024,a: POKE 65025,c
100 LET d=a: GO SUB 1000: PRINT "A = ";a;" ";h$;" ";b$
110 LET d=c: GO SUB 1000: PRINT "C = ";c;" ";h$;" ";b$
120 LET d=USR 60000: GO SUB 1000: PRINT "AorC= ";d;" ";h$;" ";b$
130 PRINT : GO TO 80
(1000 is a subroutine that takes the variable d and outputs b$ and h$, strings containing 8-bit binary and two-digit hex versions of the value d)

[Morkin]

OR C changes the A register, but it doesn't affect the C register.

C will still contain its original value LD'd earlier. Unless you do a LD C,A before the RET.

[BenHanson]

See https://worldofspectrum.org/ZXBasicManu ... hap26.html

You need a value in BC if you want to return it to basic.

10 LET a=32500
20 READ n: POKE a,n
30 LETa=a+1:GOTO20
40 DATA 1,99,0,201

then

PRINT USR 32500

[Ast A. Moore]

Add LD B,0 before RET. Also, if you wish to see the result of your bitwise OR, then you need to load the value in A back into C: LD C,A. So, your code should look something like this:

Code: Select all

	LD A,(65025)
	LD C,A
	LD A,(65024)
	OR C
	ld c,a
	ld b,0
	RET

I strongly recommend you start using a debugger. Then you can step through your code instruction by instruction, and before you see the result of each, try to predict how the registers or memory contents will change. Then compare the actual results with your predictions.

[TMD2003]

Looking through these responses, at least this confirms that it is doing a bitwise OR. That's useful to know.

And adjusting the program Peter sent me earlier wasn't too hard...

ld hl,22528
ld bc,352
ld (hl),87
inc hl
dec bc
ld a,b
or c
jr nz -8
ld hl,22880
ld bc,352
ld (hl),120
inc hl
dec bc
ld a,b
or c
jr nz -8
ret

...there's the program I needed, in 29 bytes. That'll do nicely. You may now all laugh derisively at the Softek compiler. See, I knew it could be given a pants-down thrashing.

Now on with the rest of it! And that includes understanding why the instructions ld a,b / or c do what they are needed to do here.

[BenHanson]

See https://www.google.co.uk/url?sa=t&rct=j ... PWnvolzweu

(PDF) for the Zilog Z80 manual.

LD r, n

Condition Bits Affected: None

(Page 86)

OR s

"The s operand is any of r, n, (HL), (IX+d), or (lY+d), as defined for the analogous ADD instructions."

Condition Bits Affected
S is set if result is negative; otherwise, it is reset.
Z is set if result is 0; otherwise, it is reset.
H is reset.
P/V is set if overflow; otherwise, it is reset.
N is reset.
C is reset.

(Page 173 and 174 (note PDF page nos by the way))

Here you see that the Z flag is set for an OR instruction, so then you can JR NZ/JR Z off the back of it.

[BenHanson]

Let me know if you want my z80 assembler source BTW and I can create a CodeProject article. Are you on Linux or Windows?

I now having the assembler loading a default .sna and then writing out a new one with the assembled code copied over. This hugely speeds up testing.

[TMD2003]

Let me know if you want my z80 assembler source BTW and I can create a CodeProject article. Are you on Linux or Windows?

Windows 7, although I have access to Lubuntu 15.10 on a USB stick.

Just don't assume I can run before I can walk...!

[Einar Saukas]

10 FOR n=22528 TO 22879: POKE n,15: POKE n+352,48: NEXT n
[...]
This could be done in 20 bytes, maybe even ten, but who needs this many?"

I know it was a rethoric question but since you mentioned my name...

I believe the minimum implementation is 17 bytes

[BenHanson]

For anyone that is interested you can find my Z80 assembler here: https://www.codeproject.com/Articles/52 ... -Assembler

Be sure to report any issues, this is all very new!

Thanks

[Morkin]

I believe the minimum implementation is 17 bytes

* (Gets popcorn and waits for the optimization to begin)

[TMD2003]

Is this also the right time to suggest a Machine Code sub-forum for threads like this one, the one cmal's just made, and others? It might well be useful.

[Ast A. Moore]

I believe the minimum implementation is 17 bytes

It’s late and I’m tired, but I can’t for the life of me to get it below twenty:

Code: Select all

	ld bc,352
	ld de,$5800+352	
	ld hl,$5800
	ld a,48		

loop	ld (hl),15
	ld (de),a
	inc de
	cpi
	jp pe,loop