ZXSpin Assembler

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
PeterJ
Site Admin
Posts: 123
Joined: Thu Nov 09, 2017 7:19 pm
Location: Surrey, UK

ZXSpin Assembler

Post by PeterJ » Mon Dec 04, 2017 8:00 pm

Evening,

I'm working my way through 'How to Write ZX Spectrum Games' by Jonathan Cauldwell, and I have tried this snippet of code in Spin 0.7S and 0.7Q with the same results. The code assembles fine, then when I try and run with a Randomize USR 24576 it I get a BASIC error 'Integer Out of Range'. It assembles fine with Pasmo, and I can run the .tap file created by Pasmo without problem.

Even though its very old in the tooth now, I like the integrated nature of Spin (and I'm secretly hoping @ZXDunny might update it one day) I'm using Windows 10.

Code: Select all

org $6000
	ld a,71
	ld (23693),a
	xor a	
	call 8859

	ld hl,blocks
	ld (23675),hl

	call 3503

	ld hl,21+15*256
	ld (plx),hl
	

	call basexy
	
	call splayr
	ret

basexy	ld a,22
	rst 16
	ld a,(plx)
	rst 16
	ld a,(ply)
	rst 16
	ret

splayr	ld a,69
	ld (23695),a
	ld a,144
	rst 16
	ret

plx defb 0
ply defb 0
blocks defb 16,16,56,56,124,124,254,254
0 x

Ralf
Microbot
Posts: 147
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZXSpin Assembler

Post by Ralf » Mon Dec 04, 2017 8:37 pm

I can't help you with this one but I would have an general advice. Remember that Spin is unfortunately a bit buggy :( It's really a pity as it without bugs it would be really, really great and now it's just good ;)
0 x

User avatar
Stefan
Berk
Posts: 14
Joined: Mon Nov 13, 2017 9:51 pm
Location: Belgium
Contact:

Re: ZXSpin Assembler

Post by Stefan » Mon Dec 04, 2017 8:38 pm

Compare the contents of memory at 24576 ($6000) with the contents of the Pasmo compiled source?

This post however seems to indicate that the ZX Spin assembler is just broken.
0 x

User avatar
R-Tape
Site Admin
Posts: 287
Joined: Thu Nov 09, 2017 11:46 am

Re: ZXSpin Assembler

Post by R-Tape » Mon Dec 04, 2017 8:44 pm

I use 0.666 and have never had any problems, but then I don't use assembly to its full potential.

The problem is this line:

ld hl,21+15*256

It loads HL with 9216 = 0,36 which is an impossible coord.

ld hl,21+(15*256) works.
0 x

namco
Berk
Posts: 2
Joined: Mon Dec 04, 2017 8:55 pm

Re: ZXSpin Assembler

Post by namco » Mon Dec 04, 2017 9:04 pm

@R-Tape Beaten me to it, I was just about to mention that line (but not the solution).

However, comparing this code to mine (from a earlier game):

Code: Select all

ld a,(plx)
rst 16
ld a,(ply)
rst 16
Are the x and y values the wrong way around?
0 x

User avatar
PeterJ
Site Admin
Posts: 123
Joined: Thu Nov 09, 2017 7:19 pm
Location: Surrey, UK

Re: ZXSpin Assembler

Post by PeterJ » Mon Dec 04, 2017 9:09 pm

R-Tape wrote:
Mon Dec 04, 2017 8:44 pm
I use 0.666 and have never had any problems, but then I don't use assembly to its full potential.

The problem is this line:

ld hl,21+15*256

It loads HL with 9216 = 0,36 which is an impossible coord.

ld hl,21+(15*256) works.
Interesting, so Pasmo is doing 15*256 = 3840 + 21 (3,861) which is correct and follows BODMAS (and Sinclair BASIC), whilst Spin is doing (21+15)*256 which is 9,216 as you say Dave.

Replacing that line with LD HL,3,861 works fine in Spin. I suppose its just a matter of getting used to each assemblers oddities.

I did try the Zeus assembler but can't make head nor tale of that.

Thanks everyone

Image
0 x

User avatar
R-Tape
Site Admin
Posts: 287
Joined: Thu Nov 09, 2017 11:46 am

Re: ZXSpin Assembler

Post by R-Tape » Mon Dec 04, 2017 9:14 pm

namco wrote:
Mon Dec 04, 2017 9:04 pm
Are the x and y values the wrong way around?
How do you mean the wrong way round?

This is where I get confused because Jonathan's documentation (and AGD) say X when they mean Y (the vertical axis) and Y when they mean X (the horizontal axis). Both ways work as long as the vertical axis is RSTd first followed the horizontal axis. I think that's why Jonathan uses them that was round, because we say X,Y and the ROM print uses the vertical cord first.

So as long as you mean Y when you say X, and X when you say Y, or whichever way you want X to be, Y can be X or X can be Y.

Do that make sense?

No, where am I? :mrgreen:
0 x

User avatar
Ast A. Moore
Dizzy
Posts: 79
Joined: Mon Nov 13, 2017 3:16 pm

Re: ZXSpin Assembler

Post by Ast A. Moore » Mon Dec 04, 2017 9:28 pm

I don’t think it’s the most logical approach in the long run, though. Restart at $10 is just a special case, and I don’t think it’s beneficial for a novice to think of the print coordinates as X and Y. Ideally, you should reserve these to refer to actual pixel coordinates, and stick to thinking “column, row” for anything print-related.

In my simplest (and fastest) printout routines, I don’t even bother with columns and rows—just use the attribute area of the display file directly. (Although, converting back and forth is trivial.)

And yes, each assembler has its own set of quirks. Some are quirkier than others. ;)
0 x
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.

namco
Berk
Posts: 2
Joined: Mon Dec 04, 2017 8:55 pm

Re: ZXSpin Assembler

Post by namco » Mon Dec 04, 2017 9:48 pm

Both ways work as long as the vertical axis is RSTd first followed the horizontal axis. I think that's why Jonathan uses them that was round, because we say X,Y and the ROM print uses the vertical cord first.
That's fine! :)

Oh and it's probably best to use brackets when seeing things like this:
ld hl,21+15*256

That way no assembler gets confused!
0 x

User avatar
R-Tape
Site Admin
Posts: 287
Joined: Thu Nov 09, 2017 11:46 am

Re: ZXSpin Assembler

Post by R-Tape » Mon Dec 04, 2017 10:21 pm

Ast A. Moore wrote:
Mon Dec 04, 2017 9:28 pm
I don’t think it’s the most logical approach in the long run, though. Restart at $10 is just a special case
I've often wondered* how feasible it would be for a complete beginner's guide to asm to not use ROM routines at all. It's easy enough to draw a char, but moving it around becomes tricky as you'd need a yx2cell routine that brings forth the intimidating display file layout far too early. Perhaps it could just be included with a note 'just CALL this routine to do this, don't worry about understanding it yet'. Then you could move onto sprites more fluidly. In fact I would have understood that more than I did the magic RST 16 at the time! (Not saying this applies to you Peter).

*But never done anything about.
0 x

Post Reply