More Assembly/Spectrum confusion for me :D

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
chilledgamer
Dizzy
Posts: 63
Joined: Wed Jun 24, 2020 1:22 am
Location: Torquay
Contact:

Re: More Assembly/Spectrum confusion for me :D

Post by chilledgamer »

R-Tape wrote: Thu Jun 25, 2020 8:51 pm
chilledgamer wrote: Thu Jun 25, 2020 5:52 pm Thank you all. I wangled the night off work haha :D I understand much better now about RST , which has helped me somewhat understand the whole thing a little better also.
You have a very understanding boss!

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?
User avatar
lister_of_smeg
Microbot
Posts: 145
Joined: Thu Nov 16, 2017 1:44 pm

Re: More Assembly/Spectrum confusion for me :D

Post by lister_of_smeg »

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?
$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.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: More Assembly/Spectrum confusion for me :D

Post by R-Tape »

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?
No they're both correct for their purpose. The border control routine does start at hex 2294.

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
Jonathan knows his onions, and has chosen to skip this, so that the chance of an error is avoided:

Code: Select all

229B       OUT     ($FE),A         ; outputting to port effects an immediate
                                ; change.
It skips some unecessary stuff, and also avoids a stoppage (the worst case scenario is a wonky border colour)
User avatar
chilledgamer
Dizzy
Posts: 63
Joined: Wed Jun 24, 2020 1:22 am
Location: Torquay
Contact:

Re: More Assembly/Spectrum confusion for me :D

Post by chilledgamer »

Ah i see. That makes more sense. A little challenge for me now then to change the border starting with call &2294
Profmyster
Drutt
Posts: 13
Joined: Wed Apr 10, 2019 8:46 am

Re: More Assembly/Spectrum confusion for me :D

Post by Profmyster »

User avatar
chilledgamer
Dizzy
Posts: 63
Joined: Wed Jun 24, 2020 1:22 am
Location: Torquay
Contact:

Re: More Assembly/Spectrum confusion for me :D

Post by chilledgamer »

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.

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
User avatar
Joefish
Rick Dangerous
Posts: 2042
Joined: Tue Nov 14, 2017 10:26 am

Re: More Assembly/Spectrum confusion for me :D

Post by Joefish »

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.
User avatar
chilledgamer
Dizzy
Posts: 63
Joined: Wed Jun 24, 2020 1:22 am
Location: Torquay
Contact:

Re: More Assembly/Spectrum confusion for me :D

Post by chilledgamer »

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
User avatar
Joefish
Rick Dangerous
Posts: 2042
Joined: Tue Nov 14, 2017 10:26 am

Re: More Assembly/Spectrum confusion for me :D

Post by Joefish »

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.
Post Reply