Crap 0.1 first assembly project

Show us what you're working on, (preferably with screenshots).
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Crap 0.1 first assembly project

Post by R-Tape »

Oh hell yes, I should have but didn't see the white INK/PAPER thing coming. If you're sticking with a green/white grid you'll need different graphics/colours for the white pieces depending where they land.

I guess this is the fork in the road between having to refund and not! Though an easy get out could be to make it a battle between black and red.

Image
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

AndyC wrote: Fri Jan 05, 2018 9:45 pm Yeah, Chess has an interesting problem from the point of view of the Speccy display because a white piece either has to have a different image or different attributes from a black piece on the same square. It's a lot easier on machines like the CPC where you can just use four arbitrary colours....
Yea at the back of my mind there was a nagging doubt about the colours but I dismissed it, then boom. :) Will just have to be black/red.
R-Tape wrote: Fri Jan 05, 2018 10:18 pm Oh hell yes, I should have but didn't see the white INK/PAPER thing coming. If you're sticking with a green/white grid you'll need different graphics/colours for the white pieces depending where they land.

I guess this is the fork in the road between having to refund and not! Though an easy get out could be to make it a battle between black and red.

Image
Yes you are right, Black and red is not so bad choice, I totally forgot about the colour issues with the spectrum until it happened haha. Even back of the magazine advert software needed visible graphics to avoid the dreaded refund request. Can't really do black and white graphics as people would quite rightly complain its not a zx80/zx81.

Red and black seems a good way to proceed. mmmm going to look fabulous against a green square :roll: :lol:
Never mind I think even with a colour combination seemingly selected by a blind person people would still suck up the purchase and persevere with it.

I been trying to make heads or tails of the MACRO command for pasmo but the documentation is not so helpful. Are there any examples on how get the syntax to work? I been throwing , [ ( at it but pasmo is complaining its getting unexpected surprises)

so what I am trying to do is pass a value to the macro..

Code: Select all

 STAMP_SQU  MACRO [CONSTANT]
	ld hl, 22528+CONSTANT
	ld (hl), p2colour_WS
	ld hl, 22528+CONSTANT+1
	ld (hl), p2colour_WS
	ld hl, 22528+CONSTANT+64
	ld (hl), p2colour_WS
	ld hl, 22528+CONSTANT+65
	ld (hl), p2colour_WS
        ENDM
My ancestors are getting restless all this code replication. I suspect its slowing down the program also.
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

I remember butting up against pasmo macros too. I think I deleted all my working examples when I abandoned it and moved onto a different assembler.

There's a random example here that threatens to work...

Code: Select all

RESERVE MACRO wSize,IReg
PUSH IReg
LD IReg,-wSize
ADD IReg,SP
LD SP,IReg
ENDM

FREE MACRO wSize,IReg
LD IReg,wSize
ADD IReg,SP
LD SP,IReg
POP IReg
ENDM

...
RESERVE ADDFUNC_Size,IX
...
FREE ADDFUNC_Size,IX
Yours look right except you don't need the square brackets. It's markup to indicate optional parameters, rather than something you type.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Seven.FFF wrote: Sat Jan 06, 2018 1:16 am I remember butting up against pasmo macros too. I think I deleted all my working examples when I abandoned it and moved onto a different assembler.

There's a random example here that threatens to work...

Code: Select all

RESERVE MACRO wSize,IReg
PUSH IReg
LD IReg,-wSize
ADD IReg,SP
LD SP,IReg
ENDM

FREE MACRO wSize,IReg
LD IReg,wSize
ADD IReg,SP
LD SP,IReg
POP IReg
ENDM

...
RESERVE ADDFUNC_Size,IX
...
FREE ADDFUNC_Size,IX
Yours look right except you don't need the square brackets. It's markup to indicate optional parameters, rather than something you type.
Lol - I tried with commas, without brackets, nothing is working. Lol these labour saving/efficiency steps seem to be a huge time sink with little pay off.

Is there an assembler for z80 that is extensively documented and has a less cryptic syntax that is full featured? That runs on linux natively?

Hang on... pasmo is expecting me to RESERVE and FREE those sound like you are priming a one shot operation.. from the stack won't that end up being slower? what's the point of the thing if it can't be used repeatedly. I must be missing the point totally. Ok I can see an edge case where you won't know some values until execution but that seems such a specific problem compared to letting a man have a function be passed values.

There must be an analogy to user functions that receive parameters somewhere...

hmm.. I must be missing something obvious. - EDIT Yes I was being a big dummy.

There is no spoon.
There is no spoon.
There is no spoon.

Lol - I forget that I can just write the subroutine to use either a memory location or a bunch of registers to achieve the result I want. Now I just need to figure out how to make it happen..
Last edited by Nomad on Sat Jan 06, 2018 3:28 am, edited 1 time in total.
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

Yes, I've confused you even further, sorry :( FREE and RESERVE aren't anything important, just examples of some dude's macros with parameter syntax that presumably worked for the dude.

I just tried it, and hit the same problems you did. Investigating further...

My answer to all such questions is Zeus :D It has an inbuilt emulator and good macro support, and you can step through your source code. And it does run under Wine. Other brands are available...

Image

Macros aren't really functions, they're expanded out into their full form at assembly time. What appears to be parameters is really hardcoded. For example, if you had this (assuming you got it to work properly!):

Code: Select all

TEST MACRO Foo
ld b, Foo
MEND

TEST 1
TEST 2
TEST 3
the assembler would actually generate

Code: Select all

ld b, 1
ld b, 2
ld b, 3
The illusion of a function is useful to make your code more readable and avoid unnecessary copypaste, but you have to retain a good sense of what code the assembler is actually generating, otherwise you'll run into problems. Another thing Zeus can do do is list out the hex values of the code it's assembling alongside your source code, so you always know what you're generating.

"Real" functions are usually done with call and ret, loading the parameters into registers (or memory addresses, as you said) before you call them. You could rewrite the previous example using a as the parameter:

Code: Select all

ld a, 1
call Test
ld a, 2
call Test
ld a, 3 
call Test
...
Test:
ld b, a
ret
Does that make sense?
Last edited by Seven.FFF on Sat Jan 06, 2018 3:31 am, edited 4 times in total.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

Ha, we posted at the same time, but you got there first :)
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Seven.FFF wrote: Sat Jan 06, 2018 3:21 am Ha, we posted at the same time, but you got there first :)
:D thanks for the reply, yes I understand :) Will try and get zeus running.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 6: 359 days left..

The story so far
So the plan tonight is to re-write some of the subroutines, and work on the rest of the chessmen graphics. After misunderstanding the use of macro's :lol: It was time to re-evaluate what I had done so far. Like a Spartan with a deformed baby, there was only one thing to do with such of-spring. leave it on the rocks to be eaten by the birds... Lol. Being serious - I want to rewrite what I have done so far to make it easier to read, reduce the amount of duplication and make it easier to cannibalize for later projects. I figure the time I spend now will solve a lot of potential issues later on.

Plus learning a bit more about z80 and the specy has the potential to make better choices in writing the program. That can't be a bad thing. I would say to anyone reading this who is keen to try assembly on the z80 systems. The best way to learn is to tackle a project that is just beyond what you can do. Compared to where I started I learned a lot. Now sure its not R-type or gift of the gods, but realistically nobody is going to make a good game straight from the jump start. Got to strive for something that is just beyond the current ability level. So what I am saying is pick a project that will test you, and give you a kicking. But there has to be a chance of you overcoming the problems it presents... The worst thing you can do as a beginner (in my shoes) is pick something so way beyond in terms of difficulty that no matter how good your progress you are just never going to overcome the problems the project presents. See what I mean...

The difficult projects come later, after the experience won from tackling the easy stuff (single screen, limited/no animation, limited interaction) and build upon that. One day I might get to making a scrolling rpg or a bullet shooter but that is just not a fesable idea for a first project. That is where I get frustrated with a lot of the tutorials or the books they will sell you a fantasy that as a beginner you will be able to create projects that are a near professional level. I understand marketing, nobody is going to buy a book or watch the adds of a tutorial that promises a guy the ability to write a game of battleship or tick tac toe. It has to be something impressive. These things tend to oversell what a beginner can realistically expect to do, while critically underselling/concealing that to go beyond the basics requires a very deep understanding of the platform to achieve the effects most people probably want for the games (scrolling, graphics, sound manipulation)..

The need for speed...

A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.

I could just do a naive brute force approach (like what I was doing before, but that will result in 64 separate subroutines for the clear square alone..), this is in addition to all of the subroutines for placing the chessmen on the various squares of the board 64x12... That starts to become a nightmare to keep track of. So its got to the point where I need to move on from that and get to a stage where I can create subroutines that can be more flexible. So despite my dislike of the books that is the most logical option is to see what they have to say.

Once the code is less naive and repetitious I think it should have a speed improvement, if its still slow then I will need to look at the use of the rom routines. There are probably optimisations to be made with custom subroutines but I don't want to go down that particular rabbit hole until I have too. Plus at this stage have to be realistic about my skill level - I am barely getting by as is, trying to write custom subroutines to replace the rom stuff will probably not result in a significant speed increase just because the routines would be crap quality at the moment. :) Baby steps!
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

Nomad wrote: Sat Jan 06, 2018 8:30 am A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
You could simply invert the attributes of the selected square to make it stand out.
Nomad wrote: Sat Jan 06, 2018 8:30 amif its still slow then I will need to look at the use of the rom routines.
ROM routines are very rarely (if ever) optimized for speed. We normally use them to save space. The printout routine is notorious for being utterly slow (but very flexible and universal). It takes approximately one whole frame to print a line of 32 characters on the screen. I can do the same in less than one-fifth of that time but at the expense of 19–40 bytes, depending on complexity.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Crap 0.1 first assembly project

Post by R-Tape »

Nomad wrote: Sat Jan 06, 2018 8:30 am Got to strive for something that is just beyond the current ability level.
A man's reach must exceed his grasp or what is Devon for?
Nomad wrote: Sat Jan 06, 2018 8:30 am The need for speed...

A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
That's one way of doing it, another would be to make the position change in a 64 position map of the positions...

chessmap:
db 8,9,10,11,12,10,9,8 ;black pieces tiles 7-12
db 7,7,7,7,7,7,7,7
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 1,1,1,1,1,1,1,1 ;white pieces tiles 1-6
db 2,3,4,5,6,4,3,2

...and then just redraw all the pieces (pixels only) including empty spaces. Then you wouldn't have to worry about deleting this bit and redrawing the next. The tile method I provided does 64 tiles in less than 2 frames, 1 frame would be better (and with optimisation is possible), but the eye wouldn't detect the change in turn based game like this.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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. :lol: small mercy's indeed. Will make debugging much easier now.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

Nomad wrote: Sun Jan 07, 2018 7:16 am 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:

Image
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Crap 0.1 first assembly project

Post by dfzx »

Nomad wrote: Sun Jan 07, 2018 1:20 pm 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?
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

dfzx wrote: Sun Jan 07, 2018 1:49 pm 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.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

dfzx wrote: Sun Jan 07, 2018 1:49 pm 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.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

Nomad wrote: Sun Jan 07, 2018 2:19 pm
dfzx wrote: Sun Jan 07, 2018 1:49 pm 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!
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
dfzx
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Crap 0.1 first assembly project

Post by dfzx »

Nomad wrote: Sun Jan 07, 2018 2:19 pm
dfzx wrote: Sun Jan 07, 2018 1:49 pm 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. :)
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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 :lol: 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.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

The big reveal: it’s part of my Redefine Keys routine.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Ast A. Moore wrote: Sun Jan 07, 2018 3:18 pm The big reveal: it’s part of my Redefine Keys routine.
oooh nice :lol: the suspense was killing me.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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.)

ImageImage

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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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 :lol: it will be a crap game with style.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

Nomad wrote: Mon Jan 08, 2018 11:11 am 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.
Last edited by Ast A. Moore on Mon Jan 08, 2018 2:14 pm, edited 1 time in total.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Post Reply