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

[777]

i got this type in from assembly language for games and other fast programs. ive double checked all the code, basic and assembler and it just does nothing. its supposed to display large or small characters depending on what variables you give it.

its on page 13:

https://ia800604.us.archive.org/view_ar ... ograms.pdf

i did have to change some of the jr z,-* 's to jp z -* 's to get it to assemble as it was giving me an out of range error, and also remove the + symbol from the positive numbers on jp z,* . so maybe this has something to do with it.

id really like to get this to work as it stretches the characters more than any other text manipulation program

https://easyupload.io/2pwzzm

https://easyupload.io/9odbcf

[Morkin]

i did have to change some of the jr z,-* 's to jp z -* 's to get it to assemble as it was giving me an out of range error, and also remove the + symbol from the positive numbers on jp z,* . so maybe this has something to do with it.

JP takes up an extra byte compared to JR so maybe. It might be chucking the RANDOMIZE USR address in the BASIC program (32393) out of kilter.

Could be wrong though.

[Einar Saukas]

i did have to change some of the jr z,-* 's to jp z -* 's to get it to assemble as it was giving me an out of range error

I only noticed 2 instructions "jr z" in this listing, none of them is out of range. You must be modifying them incorrectly.

[Morkin]

Oh - you can do JR..., -7 but I don't think you can do 'JP, ...-7' can you?

[777]

Oh - you can do JR..., -7 but I don't think you can do 'JP, ...-7' can you?

it wont assemble in spin with jr.....,-7. it only works as jp,....-7

[777]

I only noticed 2 instructions "jr z" in this listing, none of them is out of range. You must be modifying them incorrectly.

well, thats what it says in spin assembler. and theres more than 2, take a look at the original listing.
what do you mean by modifying them incorrectly?

[TMD2003]

it wont assemble in spin with jr.....,-7. it only works as jp,....-7

Try JR 249 (i.e. 256-7) in the Spin assembler - that should do it.

Similarly, if you're fanatical about saving bytes, I've seen examples similar to:
LD DE,65530 / ADD HL,DE
instead of
LD DE,5 / AND A / SBC HL,DE

Two bytes saved, one for not needing to clear the carry and one for not using SBC, which needs the ED-shift.

[777]

Try JR 249 (i.e. 256-7) in the Spin assembler - that should do it.

no, it still says jump out of range

[Morkin]

I think you may have to revert the JPs you've changed, put them back to JRs, to begin with.

If you do JR Z, +2 it'll jump forwards a couple of bytes (as it's a relative jump).

If you do JP Z, +2 it'll jump to address 0002, in the Spectrum ROM.

[Edit: or something similar]

[TMD2003]

I'm going to type this in myself and see if I can get what's happening. I'll uploaded a snapshot when I'm done.

One thing I have found with Spin's assembler is that sometimes it will not accept a label - usually if it's interpreted as a command. The JR L1 and JR L2 in this listing might throw it. Usually if I change it to JR L1_ or similar, it'll be OK.

[777]

I think you may have to revert the JPs you've changed, put them back to JRs, to begin with.

If you do JR Z, +2 it'll jump forwards a couple of bytes (as it's a relative jump).

If you do JP Z, +2 it'll jump to address 0002, in the Spectrum ROM.

[Edit: or something similar]

ah, ok. there must be something going on with spin, that i dont understand. maybe it uses a different syntax?

[777]

I'm going to type this in myself and see if I can get what's happening. I'll uploaded a snapshot when I'm done.

One thing I have found with Spin's assembler is that sometimes it will not accept a label - usually if it's interpreted as a command. The JR L1 and JR L2 in this listing might throw it. Usually if I change it to JR L1_ or similar, it'll be OK.

theres a .s file i uploaded to save yourself time...

changing jr l1 to jrl1_, etc doesnt seem to make a difference

[Einar Saukas]

well, thats what it says in spin assembler. and theres more than 2, take a look at the original listing.

There are several "jr' instructions, but I only noticed 2 "jr z" instructions, at addresses 32363 and 32373.

The only problems you mentioned were "jr z" with negative offsets, and removing + from "jp z" which is odd since all "jp" in the listing use labels instead of numeric offsets. Unless you made other changes you didn't mention?

what do you mean by modifying them incorrectly?

You mentioned your assembler didn’t recognize this syntax so you modified these instructions. It seems your changes broke the program. How did you change them exactly?

[Morkin]

ah, ok. there must be something going on with spin, that i dont understand. maybe it uses a different syntax?

I'm not sure, whenever I've used SPIN I tend to use JR with labels rather than offsets.

Maybe instead of 'JR Z, -7' try 'JR Z, $-7'?

(Just a guess!)

[777]

There are several "jr' instructions, but I only noticed 2 "jr z" instructions, at addresses 32363 and 32373.

The only problems you mentioned were "jr z" with negative offsets, and removing + from "jp z" which is odd since all "jp" in the listing use labels instead of numeric offsets. Unless you made other changes you didn't mention?




You mentioned your assembler didn’t recognize this syntax so you modified these instructions. It seems your changes broke the program. How did you change them exactly?

i changed 2 jr c instructions and a jr +8 instruction, also. sorry.

[TMD2003]

I've just noticed your downloadable files and it is telling me that the jump (JR Z,-6) is out of range - and still does so if I change it to JR Z,249. I've also noticed you've changed the label SET to SET1 - that's what I mean about Spin's assembler choking on potential instructions, because it's expecting something like SET 7,A and if it just sees SET, it'll flag it as an error.

If you look in Spin's debugger, JRs always reference an absolute address as if they were JPs, and I think that's what it's looking for. The best thing to do is count the jump yourself and label it. So, instead of:

Code: Select all

l1:	bit 6,(hl)
	jr nz,l3
	inc hl
	ld a,(hl)
	bit 7,a
	jr z,-6          ; here's the problem
	ld de,6
	add hl,de
	jr l2

Do this:

Code: Select all

l1:	bit 6,(hl)
	jr nz,l3
l1minus6:	inc hl
	ld a,(hl)
	bit 7,a
	jr z,l1minus6          ; fixed
	ld de,6
	add hl,de
	jr l2

Every time there's a JR, fix it this way, and check in the debugger that the byte matches the one in the listing.

Also note:
- you've put LD BC,8 instead of LD B,8 in the LP3 subroutine.
- near the end you've put LD A,(23768) and it should be LD A,(23728).
- the last of the block of four uses of A and (NN) at the end, you've put LD (23792),A and it should be LD (23729),A. Easy mistake to make, that one...

[777]

I'm not sure, whenever I've used SPIN I tend to use JR with labels rather than offsets.

Maybe instead of 'JR Z, -7' try 'JR Z, $-7'?

(Just a guess!)

ok, that assembles, ok. weird, i thought id already tried that...

but now it crashes when i run the program

[TMD2003]

but now it crashes when i run the program

See my "Also..." notes above. I've been checking through the MC listing.

EDIT: it's locking up at the start for me as well.

At times like this, it's a good idea to go through the machine code listing with a fine-toothed comb and make sure that the assembly instructions match the bytes. I found a few examples in Hewson's "40 Best Machine Code Routines" that needed correction this way.

EDIT EDIT: I've saved the snapshot and reloaded it in Spectaculator, because it shows the debugger in hex. The first troublesome jump (JR -6) should be "28 FA" in the debugger, and it says "28 F8" instead. The next jump (JR -10) should be "28 F6" and instead says "28 F4".

When a jump is executed, the program counter starts at the next instruction after the jump, so JR -2 should jump back to the start of the jump instruction and cause an infinite loop. But in Spin's case it looks like the relative amount is being taken from the start of the jump instruction rather than the end of it, so "JR -4" should be entered as "JR $-2". Presumably, because I know there's a positive jump coming up, "JR 11" should be entered as "JR $+13".

Try that. Or, better still, do it using extra labels the way I did before.

EDIT EDIT EDIT: the machine code now exactly matches the hex bytes in the listing, so I'm going to check the BASIC as well. At the moment it's drawing odd shapes on the screen.

[777]

@TMD2003
where is jr -4 and jr 11 in the code?

Removed quoting - PJ

[TMD2003]

where is jr -4 and jr 11 in the code?

These were examples to illustrate what I was explaining. The actual jumps that need to be fixed are:

32363 JR -6 and 32373 JR -10

Code: Select all

l1minus6:	inc hl
	ld a,(hl)
	bit 7,a
	jr z,l1minus6
l3minus10:	ld de,6
	add hl,de
	jr l2
l3:	bit 7,(hl)
	jr z,l3minus10

32450 JR C,+6

Code: Select all

	jr c,startplus4		; jr c,+4
	ld h,a
	ld (23296),hl
startplus4:	ld (23728),hl

32543 JR C,+3
32546 JR +8
32551 JR NZ,+2

Code: Select all

	jr c,skipplus3		; jr c,+3
	ld (hl),a
	jr skipplus8		; jr +8
skipplus3:	ld a,(hl)
	cp 0
	jr nz,skipplus2		; jr nz,+2
	ld (hl),176
skipplus2:	dec (hl)
skipplus8:	pop bc

Now I will check the BASIC. I'll be willing to bet there's an incorrect USR call in there.

EDIT: the INK colour is wrong on the first line, not that this will affect the machine code, but are you going to see white on yellow?
- y=79 in line 10, not y=29
- a number of weird errors in the introductory text

...it's these kind of basic (if you'll excuse the pun) errors that really need to be eliminated before saying "why won't this work?"

What I will let you off with is this: lines 255 and 257, z$ and v$ are supposed to be 32 spaces and you've put 31 - however, and it needs a very sharp eye to notice this, the printer for the listing has printed 33 characters per line, which is a very strange choice.

[Mpk]

Surely you should always jump to a label?

If you hard code in a value ( e g. JR +6 ) then you'll break everything if you change the intervening code. It goes away at compile time anyway, so no reason to do it.

And while I'm at it, labels should mean something. You won't know what 'L22' means as week from now.

Also, get off my lawn.

[TMD2003]

Surely you should always jump to a label?

Yes.

The BASIC listing has no dodgy USR calls - it only ever starts at 32393, and the code is not doing what it says in the text. And while I may cast doubt on 777's ability to type in a listing accurately, there is a noticeable amount of slop in the original listing which suggests it was bashed out without the kind of attention to detail that machine code needs. And if it doesn't do what it should when I've ensured that the bytes in memory exactly match those in the listing, it is probably beyond my ability to debug it.

Also, there's something that properly bugs me about these early listings, even though the authors had no way of knowing that it would be a problem in the future: so many of them use the printer buffer as an unused area for storing variables and small amounts of data for manipulation, thus rendering the routine incompatiable with 128K models. Still, that's what assemblers are for... replace these with labels as well and make sure there's enough space at 60000-and-something, and we're good to go.

[777]

Yes.

The BASIC listing has no dodgy USR calls - it only ever starts at 32393, and the code is not doing what it says in the text. And while I may cast doubt on 777's ability to type in a listing accurately, there is a noticeable amount of slop in the original listing which suggests it was bashed out without the kind of attention to detail that machine code needs. And if it doesn't do what it should when I've ensured that the bytes in memory exactly match those in the listing, it is probably beyond my ability to debug it.

ok, thank you for all your help though...

[TMD2003]

If you hard code in a value ( e g. JR +6 ) then you'll break everything if you change the intervening code. It goes away at compile time anyway, so no reason to do it.

There's an example in this listing. Using my code with labels:

Code: Select all

	jr skipplus8		; jr +8
skipplus3:	ld a,(hl)
	cp 0			; BATMAN SLAPS ROBIN
	jr nz,skipplus2		; jr nz,+2
	ld (hl),176
skipplus2:	dec (hl)
skipplus8:	pop bc

Batman is annoyed with his sidekick because CP 0 uses two bytes when OR A will do the same job in one (and Robin isn't using self-modifying code). In this case, changing CP 0 to OR A also wrecks that JR +8 instruction because the jump will then be too far forward; it will also need manually adjusting to JR +7. Use a label, even if it's SKIPPLUS8, it'll still go to the right address even if the jump is reduced to seven bytes.

[azesmbog]

exactly 265 bytes, try