ive been through this code and cannot figure out why it isnt working

[Alessandro]

Honestly, I fail to understand why people, on the threshold of 2023 of the common era, are still complicating their life trying to cope with ZX Spin's bug-ridden assembler (with due respect to Paul's overall great job) when there are more advanced and up-to-date possibilities available:

https://pasmo.speccy.org (also see here: https://www.spectrumcomputing.co.uk/for ... p?p=105958 )

https://github.com/z00m128/sjasmplus

https://github.com/EdouardBERGE/rasm

[PeterJ]

Agreed @Alessandro. If you really want to assemble directly within the emulator then take a look at InkSpector from.@Inky

[Alessandro]

I must say I don't like the emulator plus assembler combination that much. I think it could be good for some quick tests or short pieces of code, but it cannot be a substitute for a proper assembler program paired with a good text editor (Notepad++ in my case) especially if you have to assemble long programs combining several sources together.

[TMD2003]

I must say I don't like the emulator plus assembler combination that much. I think it could be good for some quick tests or short pieces of code, but it cannot be a substitute for a proper assembler program paired with a good text editor (Notepad++ in my case) especially if you have to assemble long programs combining several sources together.

About the only major problem I've had with Spin's assembler - other than when it turns completely mad and I have to restart it - is that it won't let me copy and paste text within the assembler. This is annoying, and if I have editing to do, I'll use Notepad++ - but usually, I'll opt for Spin because I can write a bit of code, assemble it, see if it works, and if it does, add a bit more, see if that works, and so on... and that's a lot faster than dealing with Pasmo as a middle-man. Then again, I'm never likely to be writing much more than a few bits and pieces of machine code to enhance BASIC programs with, and the assembler-in-emulator suits that job.

I'm now going to attempt to get to grips with machine code on a completely different computer, and I won't have any assembler at my disposal. Fortunately I only have just north of 100 bytes to deal with...

[PeterJ]

Hi @Alessandro,

InkSpector is a bit of a middle of the road solution. You still create your code in notepad or similar, then load the text file directly into InkSpector and it assembles it for you and spits out any errors.

[Seven.FFF]

Try JR 249 (i.e. 256-7) in the Spin assembler - that should do it.
Two bytes saved, one for not needing to clear the carry and one for not using SBC, which needs the ED-shift.

This is not right. The valid range of relative jump targets is between -126 and +129 bytes relative to the byte following the jr NN pair. Most assemblers support an instruction pointer symbol like $, and during assembly that points to the byte following the jr NN pair.

Lest you think that's a weird range for Zilog to support, the actual offset stored in the operand byte is a standard signed byte value between -128 and +127, specified relative to the jr opcode byte itself.

Most modern assemblers only use jr <Address> syntax, where address is calculated dynamically by a label, or an expression such as $+<Offset> or $-<Offset>. The McGraw-Hill Assembler the OP's book is written for, uses a jr <Offset> syntax:

https://spectrumcomputing.co.uk/entry/1 ... _Assembler

Code: Select all

3.  Relative jumps must be given a sign to indicate the direction of the jump.
The following are acceptable:
	jr -3
	jr z,+9

But their documentation is unclear whether those offsets are relative to the byte following the jr NN pair, OR to the jr opcode byte itself! If the latter, you'd have to subtract 2 from any replacement expression involving a $. You'd actually have to assemble the example with their assembler and look at the output to be sure.

Like other modern assemblers, Spin only accepts jr <Address> syntax, not jr <Offset> syntax. You really are better off jumping to labelled addresses, as others have pointed out - but only after you have figured out what addresses the McGraw-Hill assembler is calculating for this source.

And, while it's true that you can convert between signed and unsigned bytes as TMD2003 was suggesting, that only applies to the underlying byte representation, not to the semantic value of the expression in the source. Any decent assembler would throw an out of range error if you gave it a source expression that resolved to an offset of +249, just as Spin is doing here.

And, if it's not obvious, you can't just take a jr <Offset> expression and change it to jp <Address> plugging the value of Offset into the Address, because an absolute address isn't a relative offset. This is the main reason why assemblers have now standardized on using jr <Address>, so the addresses or labels you specify in the source can be interchangeable.

tl;dr: I suggest you revert to their original source, then take any jr <Offset> expressions and convert them to both jr $+<Offset>and jr $+<Offset>-2 form. One of those two options is going to work, and the other is not.

[Inky]

I must say I don't like the emulator plus assembler combination that much. I think it could be good for some quick tests or short pieces of code, but it cannot be a substitute for a proper assembler program paired with a good text editor (Notepad++ in my case) especially if you have to assemble long programs combining several sources together.

Yeah I can understand that. That's why I've not put an assembler editor in Inkspector. FWIW the way I use Inkspector's assembler (which, for me, has taken over from SjAsmPlus you'll not be surprised to hear ) is to edit the source in my own fave editor, external to Inkspector. Hit save in the editor after making changes and switch focus back to Inkspector and press Ctrl-F9 (Load Most Recent Source File to re-load the modified source). Or you could use the command line version of Inkspector to use in a more traditional assembler fashion, e.g. "incli my-ace-game.s" and then do whatever with the generated snapshot or tape. I'm writing big Spectrum programs this way.

FWIW #2 I'm hoping to get Inkspector 2.0.4 out before Xmas if I can fix a pesky bug in time.

[Mpk]

I must say I don't like the emulator plus assembler combination that much.

This is usually the part where I recommend Zeus and everyone ignores me.

Try Zeus everyone! It's an actual IDE! Inline debugging!

[Seven.FFF]

P

This is usually the part where I recommend Zeus and everyone ignores me.

Or a decent IDE and assembler used in conjunction with a makefile that will build and optionally launch the built file in your emulator.

When I'm not using Zeus, I use sjasmplus, where make builds the project, make emu builds and runs it in my emulator of choice, and make sync builds and sends it over wifi to my hardware Spectrum (and hitting reset on the Spectrum will load and run it).

There's literally no disadvantages compared with the horrendously buggy and quirky Spin assembler, and a ton of advantages.

[Alessandro]

FWIW #2 I'm hoping to get Inkspector 2.0.4 out before Xmas if I can fix a pesky bug in time.

I am waiting for it!

[777]

exactly 265 bytes, try

it doesnt crash but it doesnt work either. just starts to flood the screen then leave weird patterns on it

[azesmbog]

Well, let's have the full program. Preferably in TAP.
As a last resort, the BASIC part is in text format. Well, at least in the SNA.
Let's take a look at the patterns.
By the way, I compiled it in SJAsm assembler.

[777]

Well, let's have the full program. Preferably in TAP.
As a last resort, the BASIC part is in text format. Well, at least in the SNA.
Let's take a look at the patterns.
By the way, I compiled it in SJAsm assembler.

heres a sna of the offending code:

https://easyupload.io/r9f8lv

[azesmbog]

Found a couple more typos (at the end of the listing
In general, it is the author’s task to look for his typos)
Try again, it's a little better, even the menu appears and you can enter variables.
But still, something is not quite right.

[777]

@azesmbog,

ive found this program, which does the same thing, although it works in a different way according to the basic listing. unfortunately its in german.

https://spectrumcomputing.co.uk/entry/8 ... Plot-Print

Edited by PJ

[WhatHoSnorkers]

I've got that book, and a lovely ZX Spectrum assembler I typed in from BASIC. If I get a chance I'll give it a try on Boxing Day.

[WhatHoSnorkers]

This has been fun, and I can't get it working fully yet... but at least it doesn't crash any more. A lot of the problems were of my own making, and interoperation with the BASIC Assembly.

At the moment I can print one letter, and it is bigger, and looks a bit wonky. If I print TWO letters then they start to overwrite each other.

It is MOSTLY working though.

2 issues I had with the assembly were that

a) with JR, I have to put in the ABSOLUTE address and then the assembly "does the hard work" and turns it back into a relative offset. Cheers!

b) I had to move the code up 30,000 bytes and then "fix" the JPs and CALLs with POKEs, as otherwise it overwrites the assembly program itself.

I shall have another look when I've got a fresher head.

My current suspicion is that it compares the first variable, "x", with 176. Which seems...wrong. But I don't know how it works fully yet.

[777]

This has been fun, and I can't get it working fully yet... but at least it doesn't crash any more. A lot of the problems were of my own making, and interoperation with the BASIC Assembly.

could you send me a sna of it?

[WhatHoSnorkers]

I certainly can, or even a .TAP of what I've got that doesn't quite work. I'll do that with my second coffee.

[Einar Saukas]

If anybody finds any error in the original listing, please let me know so I can add a proper "known errors" comment to this book page.

[WhatHoSnorkers]

Will do. As far as I can tell, I've got the machine code in the computer properly.