Sorry, I might have been misleading. I meant that the book was working in hexadecimal. Cauldwell is using decimal numbers in his code, so you want to look up 0DAF in your book.chilledgamer wrote: ↑Thu Jun 25, 2020 4:09 pm Ok I do understand hex quite well having played with NES roms for a long time.
I didn't see any prefix such as 0x & etc so assumed it was both decimal. So really I am 'calling' 13751?
Or am i looking for documentation reference to 13751?
EDIT: just found your link thank you very much
More Assembly/Spectrum confusion for me :D
- PROSM
- Manic Miner
- Posts: 476
- Joined: Fri Nov 17, 2017 7:18 pm
- Location: Sunderland, England
- Contact:
Re: More Assembly/Spectrum confusion for me :D
All software to-date
Working on something, as always.
Working on something, as always.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
ah i see now yes
Well thanks again for all your help. I must admit I am really struggling, but I can remember even when simple code like Java was all gobbledy goop and then suddenly I understood it so I am hoping the same will happen here eventually.
Still stuck on exactly why rst 16 is used in the example, and also my main challenge right at this moment is just creating a loop (in my own project) so that I can control when it ends. I'll have to try again after work
Well thanks again for all your help. I must admit I am really struggling, but I can remember even when simple code like Java was all gobbledy goop and then suddenly I understood it so I am hoping the same will happen here eventually.
Still stuck on exactly why rst 16 is used in the example, and also my main challenge right at this moment is just creating a loop (in my own project) so that I can control when it ends. I'll have to try again after work
Last edited by chilledgamer on Thu Jun 25, 2020 4:21 pm, edited 1 time in total.
Re: More Assembly/Spectrum confusion for me :D
This is my favourite instruction reference.
http://www.z80.info/z80code.txt
It gives you all the op-codes, the times they take to normally execute, the flags they affect and a shorthand description of what they do.
The flags thing is handy as you might do a SUB or compare or something that sets the flags according to the result (like an 'IF'), then normally you'd do something like a RET NZ or conditionaly jump straight away based on those flags (your 'THEN' action). But there are some instructions that don't affect the flags (e.g. DEC BC), so you can fit them in between your 'IF' comparison and your 'THEN' jump (to maybe tidy up a pointer or something) without affecting the outcome.
e.g. you might want to do CP (HL) // RET Z to exit your function if a comparison fails. But maybe you still want to INC HL, whether you find a match or not. So according to that table of instructions, you can actually do CP (HL) // INC HL // RET Z because that INC HL doesn't alter the flags between the CP and the RET Z.
Also worth noting the differences between all the bitwise shift and rotate instructions. e.g. RRC is 'Rotate Right Circular', which just shuffles the 8 bits along and wraps the right bit back round to the left. Whereas RR is 'Rotate Right (with Carry)' (not confusing at all ) which uses the 'Carry' flag as a ninth bit in the rotation, so you can daisy-chain the bit you rotate out of one byte and into the carry flag, then from the carry flag into the next byte you use RR on.
http://www.z80.info/z80code.txt
It gives you all the op-codes, the times they take to normally execute, the flags they affect and a shorthand description of what they do.
The flags thing is handy as you might do a SUB or compare or something that sets the flags according to the result (like an 'IF'), then normally you'd do something like a RET NZ or conditionaly jump straight away based on those flags (your 'THEN' action). But there are some instructions that don't affect the flags (e.g. DEC BC), so you can fit them in between your 'IF' comparison and your 'THEN' jump (to maybe tidy up a pointer or something) without affecting the outcome.
e.g. you might want to do CP (HL) // RET Z to exit your function if a comparison fails. But maybe you still want to INC HL, whether you find a match or not. So according to that table of instructions, you can actually do CP (HL) // INC HL // RET Z because that INC HL doesn't alter the flags between the CP and the RET Z.
Also worth noting the differences between all the bitwise shift and rotate instructions. e.g. RRC is 'Rotate Right Circular', which just shuffles the 8 bits along and wraps the right bit back round to the left. Whereas RR is 'Rotate Right (with Carry)' (not confusing at all ) which uses the 'Carry' flag as a ninth bit in the rotation, so you can daisy-chain the bit you rotate out of one byte and into the carry flag, then from the carry flag into the next byte you use RR on.
Re: More Assembly/Spectrum confusion for me :D
There are quite a few ROM disassemblies out there. Here's one (I put it on my own webspace. I think it's by Geoff Wearmouth, but I couldn't find his link. Am I allowed to do this?) If you search this text file for "0DAF" (3503 in hexadecimal), you'll see the CLS routine (or you can look at the memory address in your emulator debugger).chilledgamer wrote: ↑Thu Jun 25, 2020 3:50 pm Seems insane that after around 40 years there is not a table of detailed description, in order of all functions that exist in memory
RST 16 is the same, it's listed under "0010" (16 in hex). 'RST' is basically a CALL, but faster because it has special wiring (that phrasing will drive the hardware nuts wild ). So CALL 16 will do exactly the same as RST 16, but ever so slightly slower (there will be no noticeable difference though).
My advice at this is it: DO NOT TRY TO UNRAVEL THESE ROM ROUTINES YET! They are a nightmare and if you're anything like me, you'll get tangled in confused, hateful knots in no time.
I'd just use them for now, understand that CLS clears the screen & sets paper colours, and RST 16 prints stuff. Even though the ROM code is a mile long, you can write your own CLS, PAPERFILL and PRINT routines in tens of bytes. We can post some if you like.
Though IMO, starting off just using the ROM routines without worrying too much about their contents is a good way to get into coding.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
Thanks for the useful info. I will be reading all these threads back as I continue my learning, and hopefully will understand more soon. I understand most of what you've said here, except for the '//' parts. But I have plenty of time on my hands in evenings now and much will to learnJoefish wrote: ↑Thu Jun 25, 2020 4:21 pm This is my favourite instruction reference.
http://www.z80.info/z80code.txt
It gives you all the op-codes, the times they take to normally execute, the flags they affect and a shorthand description of what they do.
The flags thing is handy as you might do a SUB or compare or something that sets the flags according to the result (like an 'IF'), then normally you'd do something like a RET NZ or conditionaly jump straight away based on those flags (your 'THEN' action). But there are some instructions that don't affect the flags (e.g. DEC BC), so you can fit them in between your 'IF' comparison and your 'THEN' jump (to maybe tidy up a pointer or something) without affecting the outcome.
e.g. you might want to do CP (HL) // RET Z to exit your function if a comparison fails. But maybe you still want to INC HL, whether you find a match or not. So according to that table of instructions, you can actually do CP (HL) // INC HL // RET Z because that INC HL doesn't alter the flags between the CP and the RET Z.
Also worth noting the differences between all the bitwise shift and rotate instructions. e.g. RRC is 'Rotate Right Circular', which just shuffles the 8 bits along and wraps the right bit back round to the left. Whereas RR is 'Rotate Right (with Carry)' (not confusing at all ) which uses the 'Carry' flag as a ninth bit in the rotation, so you can daisy-chain the bit you rotate out of one byte and into the carry flag, then from the carry flag into the next byte you use RR on.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
R-Tape wrote: ↑Thu Jun 25, 2020 4:22 pmThere are quite a few ROM disassemblies out there. Here's one (I put it on my own webspace. I think it's by Geoff Wearmouth, but I couldn't find his link. Am I allowed to do this?) If you search this text file for "0DAF" (3503 in hexadecimal), you'll see the CLS routine (or you can look at the memory address in your emulator debugger).chilledgamer wrote: ↑Thu Jun 25, 2020 3:50 pm Seems insane that after around 40 years there is not a table of detailed description, in order of all functions that exist in memory
RST 16 is the same, it's listed under "0010" (16 in hex). 'RST' is basically a CALL, but faster because it has special wiring (that phrasing will drive the hardware nuts wild ). So CALL 16 will do exactly the same as RST 16, but ever so slightly slower (there will be no noticeable difference though).
My advice at this is it: DO NOT TRY TO UNRAVEL THESE ROM ROUTINES YET! They are a nightmare and if you're anything like me, you'll get tangled in confused, hateful knots in no time.
I'd just use them for now, understand that CLS clears the screen & sets paper colours, and RST 16 prints stuff. Even though the ROM code is a mile long, you can write your own CLS, PAPERFILL and PRINT routines in tens of bytes. We can post some if you like.
Though IMO, starting off just using the ROM routines without worrying too much about their contents is a good way to get into coding.
This is really helpful to me thanks!!!! Could I ask about RST 16 again. In the example (im sure your aware of it) he uses RST 16 to print, i get that no problem. But later he 'sets' the xy position of the character for player. After each set of accumulator, he does RST 16 with comment "set the player x coord". Nothing is printed with this action i assume?
code snippet:
Code: Select all
basexy
ld a,22 ; AT code.
rst 16
ld a,(plx) ; player vertical coord.
rst 16 ; set vertical position of player.
ld a,(ply) ; player's horizontal position.
rst 16 ; set the horizontal coord.
ret
; Show player at current print position.
splayr
ld a,69 ; cyan ink (5) on black paper (0),
; bright (64).
ld (23695),a ; set our temporary screen colours.
ld a,144 ; ASCII code for User Defined Graphic 'A'.
rst 16 ; draw player.
ret
Last edited by chilledgamer on Thu Jun 25, 2020 4:30 pm, edited 1 time in total.
Re: More Assembly/Spectrum confusion for me :D
Well, according to my favourite table, here's what those instructions do. RST 16 is RST 10H:chilledgamer wrote: ↑Thu Jun 25, 2020 4:20 pmStill stuck on exactly why rst 16 is used in the example, and also my main challenge right at this moment is just creating a loop (in my own project) so that I can control when it ends. I'll have to try again after work
Code: Select all
RST 0 1 C7 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=00
RST 8H 1 CF 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=08
RST 10H 1 D7 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=10
RST 18H 1 DF 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=18
RST 20H 1 E7 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=20
RST 28H 1 EF 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=28
RST 30H 1 F7 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=30
RST 38H 1 FF 11 ------ -SP,-SP,[SP+1,SP]=PC,PC=38
They're designed to make it easy to call operating system functions that may move around with different versions of the operating system. So you PUSH some instruction data onto the stack to say exactly what function you want and what you want it to do, then call the relevant 'RST' function.
Look at the first 11 entries under the ROM disassembly from 'Skoolkit':
https://skoolkid.github.io/rom/maps/all.html
e.g. at address $10 (16 in decimal) is a JUMP that takes you to the character print routine. You could call it directly at its address in ROM, but RST 16 is a lot simpler.
Re: More Assembly/Spectrum confusion for me :D
That's where I couldn't be @rsed to type out each instruction on a separate line!!!chilledgamer wrote: ↑Thu Jun 25, 2020 4:25 pmI understand most of what you've said here, except for the '//' parts.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
haha JoeFish, I thought so but wasnt sure!
Everyone thanks again for the help. I have to go work in 2 mins :[ Hence I cannot reply. But I will get home and get my head in the books again. After that I bet I will be here with more stupid questions
Everyone thanks again for the help. I have to go work in 2 mins :[ Hence I cannot reply. But I will get home and get my head in the books again. After that I bet I will be here with more stupid questions
Re: More Assembly/Spectrum confusion for me :D
Not sure what that print routine might be doing, but from BASIC you can PRINT special control characters that temporarily alter the INK and PAPER colour, and relocate the cursor. So I presume you can send these codes through the RST 16 print routine and it will happily obey.
That it wastes time with this sort of c@rp is another good reason for writing your own PRINT routine!
Here's a CLS example that you just give it the attribute you want the screen cleared to in 'A'. It's not the fastest in the world but it's pretty short and simple. You write one byte then use LDIR to copy it loads of times. Once to clear all the pixels, then again to set all the attributes.
Note it's handy to have the sort of constant definitions I give at the start of your code (or in an 'included' file) to save you having to remember all the relevant numbers.
That it wastes time with this sort of c@rp is another good reason for writing your own PRINT routine!
Here's a CLS example that you just give it the attribute you want the screen cleared to in 'A'. It's not the fastest in the world but it's pretty short and simple. You write one byte then use LDIR to copy it loads of times. Once to clear all the pixels, then again to set all the attributes.
Note it's handy to have the sort of constant definitions I give at the start of your code (or in an 'included' file) to save you having to remember all the relevant numbers.
Code: Select all
SCREEN EQU 16384
SCREEN_SIZE EQU 6144
ATTRS EQU 22528
ATTRS_SIZE EQU 768
LD HL,SCREEN
LD DE,SCREEN+1
LD BC,SCREEN_SIZE-1
LD (HL),0
LDIR
INC HL
INC DE
LD (HL),A
LD BC,ATTRS_SIZE-1
LDIR
Re: More Assembly/Spectrum confusion for me :D
If you need the 128k ROM, they are too in the net:
http://www.fruitcake.plus.com/Sinclair/ ... sembly.htm
http://www.fruitcake.plus.com/Sinclair/ ... sembly.htm
Re: More Assembly/Spectrum confusion for me :D
The BASIC Print command accepts a number of control codes that can be embedded within a string to do things like move the cursor position, change the current INK or PAPER etc. These control codes are documented in the manual.chilledgamer wrote: ↑Thu Jun 25, 2020 4:28 pmR-Tape wrote: ↑Thu Jun 25, 2020 4:22 pm There are quite a few ROM disassemblies out there. Here's one (I put it on my own webspace. I think it's by Geoff Wearmouth, but I couldn't find his link. Am I allowed to do this?) If you search this text file for "0DAF" (3503 in hexadecimal), you'll see the CLS routine (or you can look at the memory address in your emulator debugger).
RST 16 is the same, it's listed under "0010" (16 in hex). 'RST' is basically a CALL, but faster because it has special wiring (that phrasing will drive the hardware nuts wild ). So CALL 16 will do exactly the same as RST 16, but ever so slightly slower (there will be no noticeable difference though).
My advice at this is it: DO NOT TRY TO UNRAVEL THESE ROM ROUTINES YET! They are a nightmare and if you're anything like me, you'll get tangled in confused, hateful knots in no time.
I'd just use them for now, understand that CLS clears the screen & sets paper colours, and RST 16 prints stuff. Even though the ROM code is a mile long, you can write your own CLS, PAPERFILL and PRINT routines in tens of bytes. We can post some if you like.
Though IMO, starting off just using the ROM routines without worrying too much about their contents is a good way to get into coding.
This is really helpful to me thanks!!!! Could I ask about RST 16 again. In the example (im sure your aware of it) he uses RST 16 to print, i get that no problem. But later he 'sets' the xy position of the character for player. After each set of accumulator, he does RST 16 with comment "set the player x coord". Nothing is printed with this action i assume?
code snippet:Code: Select all
basexy ld a,22 ; AT code. rst 16 ld a,(plx) ; player vertical coord. rst 16 ; set vertical position of player. ld a,(ply) ; player's horizontal position. rst 16 ; set the horizontal coord. ret ; Show player at current print position. splayr ld a,69 ; cyan ink (5) on black paper (0), ; bright (64). ld (23695),a ; set our temporary screen colours. ld a,144 ; ASCII code for User Defined Graphic 'A'. rst 16 ; draw player. ret
Internally, this is handled by the RST 16 routine, so passing appropriate control code sequences to that will have the same effect as in BASIC. This is one of the reasons that the code behind it is incredibly complex and also not terribly quick.
Re: More Assembly/Spectrum confusion for me :D
Yep not every CALL/RST 16 prints a character.chilledgamer wrote: ↑Thu Jun 25, 2020 4:28 pm This is really helpful to me thanks!!!! Could I ask about RST 16 again. In the example (im sure your aware of it) he uses RST 16 to print, i get that no problem. But later he 'sets' the xy position of the character for player. After each set of accumulator, he does RST 16 with comment "set the player x coord". Nothing is printed with this action i assume?
If you LD A with numbers 32 - 127, RST 16 prints the corresponding ASCII), 128 - 165 is the blocks & then UDGS. So this code will print all the ASCII set and UDGS:
Code: Select all
org 32768
ld a,2
call 5633
ld a,32
loop: push af
rst 16
pop af
inc a
cp 165
jr c,loop
ret
Some other useful ones are:
LD A,16 ;INK colour
RST 16 ;it expects to next byte to be a viable colour 0-7
LD A,2 ;red = 2
RST 16 ;anything printed from now will be red
Others:
17 (does PAPER 0 -7)
18 (FLASH 0 or 1)
19 BRIGHT (0 or 1)
Have you got the BASIC manual? This info is listed on p183, "The character set"
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
Thank you all. I wangled the night off work haha I understand much better now about RST , which has helped me somewhat understand the whole thing a little better also.
Re: More Assembly/Spectrum confusion for me :D
You have a very understanding boss!chilledgamer wrote: ↑Thu Jun 25, 2020 5:52 pm Thank you all. I wangled the night off work haha I understand much better now about RST , which has helped me somewhat understand the whole thing a little better also.
Mr Pargeter? I'm afraid I can't come to work tonight; I need to unravel the convoluted wonders of the RST 16 instruction on the ZX Spectrum.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
R-Tape wrote: ↑Thu Jun 25, 2020 8:51 pmYou have a very understanding boss!chilledgamer wrote: ↑Thu Jun 25, 2020 5:52 pm Thank you all. I wangled the night off work haha I understand much better now about RST , which has helped me somewhat understand the whole thing a little better also.
Mr Pargeter? I'm afraid I can't come to work tonight; I need to unravel the convoluted wonders of the RST 16 instruction on the ZX Spectrum.
haha no he isn't understanding at all lol. But luckily for me (as I really didn't fancy working tonight) he had booked too many staff and needed one of us to go home (if we didn't mind lol).
By the way, I think I might have found a mistake on Skoolkid site https://skoolkid.github.io/rom/maps/all.html , here he lists "2294 The Border Command Routine" but in my example tutorial and all of my testing I have to use 229B. Anyone see if this is the website that is wrong, or yet again me being dumb lol?
- lister_of_smeg
- Microbot
- Posts: 145
- Joined: Thu Nov 16, 2017 1:44 pm
Re: More Assembly/Spectrum confusion for me :D
$2294 - $229a deal with handling the parameter passed from the BORDER command in BASIC. So if calling from machine code with your border value already in A you instead jump in after those instructions.chilledgamer wrote: ↑Thu Jun 25, 2020 11:00 pm By the way, I think I might have found a mistake on Skoolkid site https://skoolkid.github.io/rom/maps/all.html , here he lists "2294 The Border Command Routine" but in my example tutorial and all of my testing I have to use 229B. Anyone see if this is the website that is wrong, or yet again me being dumb lol?
Re: More Assembly/Spectrum confusion for me :D
No they're both correct for their purpose. The border control routine does start at hex 2294.chilledgamer wrote: ↑Thu Jun 25, 2020 11:00 pm By the way, I think I might have found a mistake on Skoolkid site https://skoolkid.github.io/rom/maps/all.html , here he lists "2294 The Border Command Routine" but in my example tutorial and all of my testing I have to use 229B. Anyone see if this is the website that is wrong, or yet again me being dumb lol?
At 2294, it checks that your are trying to set a viable border colour: 0 - 7, and if not, print the BASIC "K: Invalid colour":
Code: Select all
L2294: CALL L1E94 ; routine FIND-INT1
CP $08 ; must be in range 0 (black) to 7 (white)
JR NC,L2244 ; back to REPORT-K if not
Code: Select all
229B OUT ($FE),A ; outputting to port effects an immediate
; change.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
Ah i see. That makes more sense. A little challenge for me now then to change the border starting with call &2294
-
- Drutt
- Posts: 13
- Joined: Wed Apr 10, 2019 8:46 am
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
Ok I have been battling away alone trying to make some headway. I feel I now have an ok understanding of how many of the assembler functions/operations work.
But not good enough to put it into practice and make working code!
I now struggle displaying a sprite on screen. Using UDG's I can achieve this but I am trying to display sprites. Here I have an 8x8 sprite, but I am hoping my code will display sprites of much larger without much modification.
But why doesn't my 'sprite data' (ie. "face") seem to get output on screen, I just get a black square where I expected it to be.
But not good enough to put it into practice and make working code!
I now struggle displaying a sprite on screen. Using UDG's I can achieve this but I am trying to display sprites. Here I have an 8x8 sprite, but I am hoping my code will display sprites of much larger without much modification.
But why doesn't my 'sprite data' (ie. "face") seem to get output on screen, I just get a black square where I expected it to be.
Code: Select all
ENTRY_POINT EQU 32768
org ENTRY_POINT
;screen memory starts 16384 / 0x4000
call 0xdaf
ld b,2
ld c,5
call GetColourMemAddress
ld a,%00000011
ld (de),a
call GetScreenAddress
ld hl,face
ld b,8
; this function will take input in bc=xy position
; out hl= screen memory address
GetScreenAddress:
ld a,c
and %00111000
rlca
rlca
or b
ld e,a
ld a,c
and %00000111
ld d,a
ld a,c
and %11000000
rrca
rrca
rrca
or d
or 0x40 ;0x4000 = screen base
ld d,a
ret
GetNextLine:
inc d
ld a,d
and %00000111
ret nz
ld a,e
and %00100000
ld e,a
ret c
ld a,d
sub %00001000
ld d,a
ret
; input bc=xy (x in bytes, so 32 across)
; output hl=screen memory address
GetColourMemAddress:
ld a,c
and %11000000
rlca
rlca
add a,0x58
ld d,a
ld a,c
and %00111000
rlca
rlca
add a, b
ld e,a
ret
GetNextColoutLine:
ld a,e
add a,32
ld e,a
ret nc
inc d
ret
SpriteNextLine:
ld a,(hl)
ld (de),a
inc hl
call GetNextLine
djnz SpriteNextLine
ret
;include "face.asm" ;tried this and got black square only. Same when data is in this file as below.
face:
db %00000000
db %00100100
db %00100100
db %00000000
db %01000010
db %01111110
db %00111100
db %00000000
end ENTRY_POINT
Re: More Assembly/Spectrum confusion for me :D
You can't define functions in the middle of your code like that and expect them to be isolated.
In your case, the code is going to run to that LD B,8 and then just carry on running through your GetScreenAddress: function and RET at the end of it. It'll never get to the rest of your code further down.
Move your call-able calculation functions down the text file until after your main function has been completely defined.
Or do you mean to get to the LD B,8 and then do JP SpriteNextLine ? As again, I would copy your SpriteNextLine function up to just after the LD B,8 so it just flows right through.
This is not a smart compiler; it's an assembler. Every command you enter gets turned directly into a machine code instruction at the point where you wrote it, in the order you wrote it. It won't automatically allocate memory somewhere else for functions and variables and data. There's not really much difference between code and data anyway. It's all turned into a sequence of numbers poked into memory. If the processor is pointed at it then it'll execute it as if it's code. If you put DB 201 in the middle of your code it'll be treated as a RET instruction when the processor gets to it because 201 it the code for the instruction 'RET'. It doesn't care one jot that you defined it with a data statement. And there's no clear definition of a function either. There are just labels you can jump to, and if you use a 'CALL' instead of a 'JP', then a return address is put onto the stack for later. You can PUSH a memory address onto the stack and then do RET to jump to it, if you want to really go nuts.
In your case, the code is going to run to that LD B,8 and then just carry on running through your GetScreenAddress: function and RET at the end of it. It'll never get to the rest of your code further down.
Move your call-able calculation functions down the text file until after your main function has been completely defined.
Or do you mean to get to the LD B,8 and then do JP SpriteNextLine ? As again, I would copy your SpriteNextLine function up to just after the LD B,8 so it just flows right through.
This is not a smart compiler; it's an assembler. Every command you enter gets turned directly into a machine code instruction at the point where you wrote it, in the order you wrote it. It won't automatically allocate memory somewhere else for functions and variables and data. There's not really much difference between code and data anyway. It's all turned into a sequence of numbers poked into memory. If the processor is pointed at it then it'll execute it as if it's code. If you put DB 201 in the middle of your code it'll be treated as a RET instruction when the processor gets to it because 201 it the code for the instruction 'RET'. It doesn't care one jot that you defined it with a data statement. And there's no clear definition of a function either. There are just labels you can jump to, and if you use a 'CALL' instead of a 'JP', then a return address is put onto the stack for later. You can PUSH a memory address onto the stack and then do RET to jump to it, if you want to really go nuts.
- chilledgamer
- Dizzy
- Posts: 63
- Joined: Wed Jun 24, 2020 1:22 am
- Location: Torquay
- Contact:
Re: More Assembly/Spectrum confusion for me :D
thank you very much. I was copying a tutorial so I have no idea how the function ended up down there. I moved it up as you stated and it works great. Although it now displays strangely if I put in different values for xy position. But that is something I can work on myself. Cheers for the help again
Re: More Assembly/Spectrum confusion for me :D
You realise those functions seem to assume x-position is in whole bytes/characters, whereas y-position is in pixels? So the attribute address is divided by 8 and rounded down to the nearest character? That may mean you can't see all the pixels, if all the other attributes are set to something like black-on-black (attribute 0). Try clearing the screen to blue-on black attributes (1) first.