Crap 0.1 first assembly project

[Nomad]

What's a man's age? He must hurry more, that's all;
Cram in a day, what his youth took a year to hold:

I like the position map idea, that would a good way to keep track of the board. with a screen printer that just endlessly looped over the map using the tile code you showed would work a treat I think.

Will get cracking.

In other news, inexplicably (well to me) Zeus decided it would run under wine on my machine. small mercy's indeed. Will make debugging much easier now.

[Nomad]

Day 7: 358 days left..

Progress: Have a much better understanding of the basics of z80 instructions, figure time spent getting the basics straight will pay dividends later on and lead to a better game. (and less bugs, mistakes). Thankfully I now have figured out how to use subroutines/functions within assembler. (I am not the sharpest pencil in the tin lol it took a while.)

With this revelation came the realisation I needed to re-factor what I had previously done with the game. Have all of the interesting ideas/suggestions on how to make the game better and get it finished from you fellows.

More preparation stuff went on today, set up a lab book, so I can record all of my noob experiments in z80 assembler so I can refer back to when either I forget or I screw something up later. Plus with this method I can clearly reference where I got such and such an idea from.. I think overall it will help keep my notes straight and make it easy to look stuff up later. Especially laying the groundwork for porting the software its going to be useful to have a clear set of notes for later. I don't want to go back and have to dig through hundreds of pages of notes when the time comes to port another game to say msx or cpc.

How do the rest of you guys keep your notes straight when writing programs for the microcomputers? Any tips or hints?

More on the research side, currently downloading the archive.org mirror of WOS. the TOSEC archive i'll get next. With those two I should have a fair chunk of all zx spectrum software and most of the magazines.

On more general z80 stuff, found some good articles on how the original calculator functions were written by HP. The journals are good sources for information on the thinking behind the development of the early software. Plus the journals are just full of vintage test equipment/calculator porn.

Game wise - today will start re factoring the code. It is boring but I think long term it will save a lot of time and make what finally does come out more useful in future projects. Stuff like a general menu system, stuff like that if its well written will be able to be used many times in my projects.

But overall not must progress to the game today. More storing up win for later.

[Ast A. Moore]

How do the rest of you guys keep your notes straight when writing programs for the microcomputers? Any tips or hints?

I have three words for you: comments, comments, comments. Comment the bejeezus out of your code. Assembly is a tricky language. Source code can be very ambiguous, so you need to spend much more time writing comments than writing the actual code. And don’t rely on “oh, I know what I’m doing here, I don’t need to comment it”—you’ll forget it within a day or two.

Here’s a typical example of my code:

[Nomad]

Thanks for the tip, I see what you mean about commenting the code - its not just best practice its pretty essential for it to be of use later on. Will try and get my comments to that standard in my own work.

[dfzx]

Thanks for the tip, I see what you mean about commenting the code

Here's a question for you though: if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?

[Ast A. Moore]

if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?

This is not a complete routine, though. Just a (fairly) random snippet of a routine. Without the rest of the code posted, I doubt it’s possible to determine what it’s used for. I only posted it as a real-world example of assembly code commenting.

[Nomad]

Here's a question for you though: if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?

The routine scans the keyboard (the first rom call).
Then it checks if a key has been pressed, until there is keyboard input it goes into a loop.
Once there is key input, the input is debounced, then the input checked, assuming it was a character the code is returned. (K_TEST), that is the second rom routine used.

Then the program calls the rom beep routine. - third rom routine used.

Not sure what it is doing beyond that, my guess is its part of a screen editor.

[Ast A. Moore]

Here's a question for you though: if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?

The routine scans the keyboard (the first rom call).
Then it checks if a key has been pressed, until there is keyboard input it goes into a loop.
Once there is key input, the input is debounced, then the input checked, assuming it was a character the code is returned. (K_TEST), that is the second rom routine used.

Then the program calls the rom beep routine. - third rom routine used.

Not sure what it is doing beyond that, my guess is its part of a screen editor.

Very good, and quite close!

[dfzx]

Here's a question for you though: if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?

The routine scans the keyboard (the first rom call).
Then it checks if a key has been pressed, until there is keyboard input it goes into a loop.
Once there is key input, the input is debounced, then the input checked, assuming it was a character the code is returned. (K_TEST), that is the second rom routine used.

Then the program calls the rom beep routine. - third rom routine used.

Not sure what it is doing beyond that, my guess is its part of a screen editor.

Fair enough! I couldn't work it out, at least from a brief skim through.

My point was that, at least from my perspective, it needs a bigger comment at the top saying what the routine does, what its inputs and outputs are, what its side effects are. I find the line by line comments of what value is being moved between memory and registers, etc., less useful. If I'm trying to work out (or remember!) what a bit of code does I find comments on blocks of code, as opposed to lines of code, more useful.

Maybe it's just me.

[Nomad]

The rom calls are a big clue, if there had been custom routines it would have been more cryptic but then again you would have had more explanation so I guess it evens out.

My guess at the editor was because if there was a need for speed then the rom calls would have not been used so much. But that is pure speculation. On that point I could be wrong. There might have been a memory restriction that required the use of the rom routines instead of custom stuff. Hard to tell without knowing the situation the code was used in. Or it could have just been a time issue.

I find the line by line stuff useful, but having a general overview of what's going on is also useful. I think there is room for both at the table plus I doubt you would be looking at a snippet like that in isolation - you would have the rest of the program for context to give you an idea of what was going on.

I think where the line by line stuff comes into its own is when you need to debug something later and you can know exactly why you wrote a line such and such a way.

[Ast A. Moore]

The big reveal: it’s part of my Redefine Keys routine.

[Nomad]

The big reveal: it’s part of my Redefine Keys routine.

oooh nice the suspense was killing me.

[Nomad]

Books that are useful (to me).

After bemoaning the state of assembly books for the Spectrum I found a few that were great to quite good.. Figured it was only fair to showcase these pearls in a sea of muck to give some balance.

Lance A. Leventhal books are pretty good. Especially the subroutine one. Its more like a cookbook but I found it to be clear and explained well. I imagine people would say the problem with the book is its dry as a desert but its worth it for the amount of information that is pretty much instantly applicable to most projects. (and a whole lot of obscure/esoteric stuff that would be a pain to figure out alone.)



I prefer the z80 subroutine book to his assembly course as I think its more focused. But all his books are on another level quality wise compared to there contemporaries.

The Rom disassembly book (Dr Ian Logan & Dr Frank O'Hara) is also extremely useful, I wish there was something like that for the msx.

Other than that the 'Programming the z80' by Zaks is another book that stands above the crowd (however interestingly enough John Romero hated Zaks' books and thought they were useless. So I guess its a matter of individual tastes in many cases. But then again he was barely into his teens when he got the book so perhaps that is why. The content is much like Leventhal in that its very dry.

Looking through the other assembly books, for the most part the Ian Logan/O'Hara book and the Zaks book were most often recommended or at least referenced as sources/further reading. I would guess that these two books along with the Zilog manuals formed the basis for many of the spectrum assembly books and articles.

[Nomad]

Day 8: 357 days left..

Todays project time was taken up playing with the examples from the z80 subroutine book.

Code: Select all

; So one thing I never really though about before, but you can load a register into itself..
LD A,A ; A = A <- A  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD B,B ; B = B <- B  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD C,C ; C = C <- C  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD D,D ; D = D <- D  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD E,E ; E = E <- E  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD H,H ; H = H <- H  Nothing except the PC is changed (PC advanced). takes 4 T states.
LD L,L ; L = L <- L  Nothing except the PC is changed (PC advanced). takes 4 T states.

So it's the equivalent of a NOP. But looking at the opcode, you can do the same thing with register pairs... (But for greater T-state hit). Might be useful for precise timings that are not T4.

Can see why you wouldn't want to use HALT compared to the previous two (because of having to enable interupts).

The second interesting thing that came out of today's reading was concerning pushing single registers. According to Leventhal

Programmers generally prefer to combine byte-length operands or simply waste a byte of the stack rather than attempt to push a single byte..

He then goes on to show a number of ways to negate the lesser byte of the register pair. But I was curious why he says this. There is no explanation why its just stated as a axiom.

After that reviewed the various conditional calls, and returns. I was surprised how flexible these ops are. Would imagine that condition jumps vs condition calls are a matter of personal style preference or is there a reason to select one over the other?

How does this relate to the project - well all these will help the quality of my work. I figure the more techniques a fella has in his tool box the more flexible the approach to a problem can be.

One op code that will come in handy is the BIT instruction. being able to do bit manipulation like this will enable me to set options/states in the program. What page to display on the screen, what is the menu state, move state, stuff like that. I think it might be a little slow but would save on memory.

As an aside, today I discovered the rabbit hole that is contested memory spaces.

Progress wise I want to continue to get better at z80 so the project can be completed in a competent way - rather than just rushing something out or doing a copy pasta job. I want something I can be proud of. Even if it is a crap game it will be a crap game with style.

[Ast A. Moore]

According to Leventhal

Programmers generally prefer to combine byte-length operands or simply waste a byte of the stack rather than attempt to push a single byte..

He then goes on to show a number of ways to negate the lesser byte of the register pair. But I was curious why he says this. There is no explanation why its just stated as a axiom.

Are you sure? He must have explained that you can’t physically place a single byte on the stack—the operation always acts on two bytes.

Besides, the reasons might be obvious: speed, convenience. While reading general Z80 assembly books, always remember they weren’t written with the Spectrum in mind. Some of the techniques they describe are good general practice techniques, but they don’t always translate well to (or are not beneficial for) the Spectrum.

[Nomad]

Are you sure? He must have explained that you can’t physically place a single byte on the stack—the operation always acts on two bytes.

Besides, the reasons might be obvious: speed, convenience. While reading general Z80 assembly books, always remember they weren’t written with the Spectrum in mind. Some of the techniques they describe a good general practice techniques, but they don’t always translate well to (or are not beneficial for) the Spectrum.

p.122


Doh! Egg on my face... It was a direct quote from the book, but as you are correct he explains only register pairs can be used on the stack at the start of the book. Serves me right for skimming the introduction.

from the beginning (page 4 on the pdf)..

14. Only register pairs or index registers can be moved to or from the stack. One pair is AF, which consists of the accumulator (more significant byte) and the flags (less significant byte). The CALL and RET instructions transfer addresses to or from the stack; there are conditional calls and returns but they are seldom used."

I see what he's doing, a lot of the comments are comparing the z80 to other cpu's like the 6502 and the 6800, 8080/8085.

What are the pitfalls of the general z80 books regarding the Spectrum? Forewarned is forearmed and all that.

[Morkin]

Progress wise I want to continue to get better at z80 so the project can be completed in a competent way - rather than just rushing something out or doing a copy pasta job.

...Well, everyone wants to avoid spaghetti code don't they..?

[Ast A. Moore]

What are the pitfalls of the general z80 books regarding the Spectrum? Forewarned is forearmed and all that.

Like I already mentioned—speed and convenience. Most Z80 applications (especially early ones) were in embedded systems. RAM was scarce, so most optimizations were targeting size at the expense of speed. There’s merit in that, of course, but don’t get too fixated on it. On the Spectrum especially, the speed of execution is much more important that compactness for almost everything that concerns “creating the illusion of pixels dancing on the screen.”

[Nomad]

...Well, everyone wants to avoid spaghetti code don't they..?

They might get in to a pickle...



The majority of the project code was done on one evening in a single session lol. So yea its a analysis's nightmare. I looked at it a few days later and realised my ancestors would be displeased if I didn't do something about it.

Like I already mentioned—speed and convenience. Most Z80 applications (especially early ones) were in embedded systems. RAM was scarce, so most optimizations were targeting size at the expense of speed. There’s merit in that, of course, but don’t get too fixated on it. On the Spectrum especially, the speed of execution is much more important that compactness for almost everything that concerns “creating the illusion of pixels dancing on the screen.”

Ah yes I see what you mean, yea there is not so much focus on t-states and more on byte use. But in fairness to the guy the books seem to have everything but the kitchen sink as far as approaches go.

I probably am miss-remembering but was there something about the binary coded decimals that was not implemented on the spectrum?

[Ast A. Moore]

I probably am miss-remembering but was there something about the binary coded decimals that was not implemented on the spectrum?

Nothing I’m aware of. That’s part and parcel of Z80 itself, so anything it can do with them can be done on the Spectrum.

[Nomad]

I probably am miss-remembering but was there something about the binary coded decimals that was not implemented on the spectrum?

Nothing I’m aware of. That’s part and parcel of Z80 itself, so anything it can do with them can be done on the Spectrum.

That is good to know, I kept arguing with myself about it being impossible but it was like a niggling doubt in the back of my mind.

For people curious about the guys books most of them are on archive.org

This is the z80 subroutine book.
https://archive.org/details/bitsavers_o ... 3_24203802

The rest are here.
https://archive.org/search.php?query=La ... 0Leventhal

[Seven.FFF]

interestingly enough John Romero hated Zaks' books and thought they were useless.

I would pay good money* to read a John A. Romero zombie/z80 crossover book.

* not really

[Nomad]

interestingly enough John Romero hated Zaks' books and thought they were useless.

I would pay good money* to read a John A. Romero zombie/z80 crossover book.

* not really

a protagonist getting swarmed by C5s.

[Nomad]

Day 9: 356 days left..

JP DAY10 ; mostly just me playing with P Rak's and others rnd examples.

Day 10: 355 days left..

Got P Rak's code working, So that was a victory. That code will come in real handy in the future.

As far as the project goes today, been getting stuck trying to figure out how to pass values with included files.

I don't know why this does not work..

main.asm

Code: Select all

org 50000
include "test.asm"
Main:
	nop
	nop
	ld a,50
	call Wiggy
	ld (51000),a
	ret
end 50000

test.asm

Code: Select all

Wiggy:
	ld a, 100
	ret

Why can I not interact with the values passed in main.asm when the same program is calling test.asm?

How is a library function supposed to update main memory or a register?

What I want to do is have included files have functions that are called by the main program then they act upon the registers and memory as if they were in main.asm.

I must be missing something obvious.

Because when I run the program the value of 51000 is 0

However when i comment out the wiggy call, its 50 (as you would expect)

when I add a ld (51000),a in wiggy it shows 100 (again little bit weird...)

It seems every time I try and do things 'correctly', e.g splitting the project up into separate files whatever it seems to set me back days trying to get it to work. I must have a potato head. Part of me thinks if I had just done a imperative single file program it would have been complete by now.

[Seven.FFF]

You’re jumping straight into Wiggy, loading a, then returning immediately.

Try putting your includes after Main, or else write END Main instead of END 50000.