Crap 0.1 first assembly project

[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.

[Nomad]

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.

Weird now it shows 0..

main.asm

Code: Select all

org 50000

Main:
	include "test.asm"
	nop
	nop
	ld a,50
	call Wiggy
	;<---- shouldnt the pc return us here after wiggy is called? In that case why is a not 100?
	ld (51000),a
	ret
end Main

test.asm

Code: Select all

Wiggy:
	ld a, 100
	ret

Edit --- ok include should go before Main because I put end Main... it now works as I expected

[Ast A. Moore]

Where do you expect the assembler to assemble the included file to? I mean, how would it know where to insert that code?

I don’t know how your assembler works, so I can’t make any concrete suggestion, but I’d start looking into that. If I had to guess, the included file is assembled exactly where the include detective is. So when you run your code at 50000, it loads A with 100 and returns to BASIC. Since the address at 51000 is initialized to 0 after a reset, poking that location returns, well 0.

Either change the address you call to run your code from BASIC, or move the include directive after the last RET instruction in your main file.

[Ast A. Moore]

Also, young Nomad, it’s time for you to learn to use a debugger/monitor. It will answer many of your questions faster than any of us ever could.

[Seven.FFF]

As to why, think of include and incbin as being similar to macro expansion. Conceptually, the assembler replaces each include line with the contents of the file being included, until you have one giant single source file. (It probably doesn’t really do this, but the effect is the same.)

Generally it’s less crazy-making to have the entry point at a fixed address so you can always call it there without having to check your symbol list for the address. Putting includes before the entry point is unhelpful because you’ll push the entry point higher every time you add something to an included file.

[Nomad]

Also, young Nomad, it’s time for you to learn to use a debugger/monitor. It will answer many of your questions faster than any of us ever could.

Yes that is true, sorry for all the questions : if I could figure out how to generate a tap with Zeus I could use that. I still use the Pasmo because its easy to generate the tap, but the problem is unlike zeus I cant see whats going on.

As to why, think of include and incbin as being similar to macro expansion. Conceptually, the assembler replaces each include line with the contents of the file being included, until you have one giant single source file. (It probably doesn’t really do this, but the effect is the same.)

Generally it’s less crazy-making to have the entry point at a fixed address so you can always call it there without having to check your symbol list for the address. Putting includes before the entry point is unhelpful because you’ll push the entry point higher every time you add something to an included file.

Ah I see what you mean, so every time I add a library it 'moves the goalpoasts', sorry for such a dumb question but how can I force the include file to go to a specific memory location?

[Ast A. Moore]

sorry for all the questions : if I could figure out how to generate a tap with Zeus I could use that. I still use the Pasmo because its easy to generate the tap, but the problem is unlike zeus I cant see whats going on.

No worries. I suggest you look into emulators that offer built-in debuggers and use assemblers as, well, assembler. I know Fuse and SpecEmu have debuggers built into them. Windows users might chime in with more suggestions.

[Seven.FFF]

what you mean, so every time I add a library it 'moves the goalpoasts', sorry for such a dumb quehow can I force the include file to go to a specific memory location?

Yes indeed!

You can force that by having another org at the top of the included file. You can have as many org directives as you like, and they can appear anywhere in the code.

The problem with that is you end up with a sparse memory map. There will be holes between the blocks of code, and your tap file will be bigger than it needs to be, if you save the entire block including the holes.

Also, consider what happens if you hard code an org, but some code below it later grows so big it starts overrunning into the next block.

Writing tap files in Zeus is dead easy, I’ll make an example in a while.

[Nomad]

No worries. I suggest you look into emulators that offer built-in debuggers and use assemblers as, well, assembler. I know Fuse and SpecEmu have debuggers built into them. Windows users might chime in with more suggestions.

Sorry I am being a potato, I use linux and fuse, I just never took the time to look at fuse's menu options. Yea I got the debugger running now with it - thanks for the tip.

[dfzx]

Sorry I am being a potato, I use linux and fuse, I just never took the time to look at fuse's menu options. Yea I got the debugger running now with it - thanks for the tip.

OK, so, scroll the middle column (the disassembly) to address 50000 and tell us what you find there. How does the assembled (and now disassembled) code relate to your main and test ASM files?

The real question is "where does that 'ld a,100' get placed in memory"?

[Morkin]

Sorry I am being a potato, I use linux and fuse,

Have you tried using Spud?

<gets coat>