Sorry, I made a mistake (doing some dec to hex conversion in my head), and you only partially corrected it. The length should be $1b00 (6912 in dec). Copying 48 extra bytes is not super critical, but it’s best not to overwrite this area unless you really need to. On the Spectrum 48K, this is normally the printer buffer (but can also be reclaimed by certain peripherals).
Crap 0.1 first assembly project
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Crap 0.1 first assembly project
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.
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.
Re: Crap 0.1 first assembly project
Thanks; I will fix that now.Ast A. Moore wrote: ↑Thu Jan 04, 2018 2:42 pmSorry, I made a mistake (doing some dec to hex conversion in my head), and you only partially corrected it. The length should be $1b00 (6912 in dec). Copying 48 extra bytes is not super critical, but it’s best not to overwrite this area unless you really need to. On the Spectrum 48K, this is normally the printer buffer (but can also be reclaimed by certain peripherals).
Re: Crap 0.1 first assembly project
Day 5: (360 days left)
Progress was OK today, I managed to 'refactor' the code so now it is a little less of a mess. Next thing that got done, I created a table of all the possible positions for the graphics on the board. So now no more guess work - if I want A6 I know exactly where it is on the screen.
https://nofile.io/f/KC1XyR1ysc8/boardxy.pdf
This is my reference for figuring out the square positions on the board.
This was to help create my square highlighter, but I realised after I can use it for positioning of the chessmen on the board also. So it was more useful than I had imagined at first.
As you can see from the programming questions I kinda got stuck with the whole drawing the chessmen on the screen (or should I say, loading the data into the video ram). I moved on to a part of the program I knew I could complete and cracked on with that.
So today was spent working on the square highlighter functions. For each square of the board I want to be able to highlight the square. So I needed to know the positions for each of the squares on the board, so I could write the colour data to the attribute data of the memory.
Everything went to plan, however as I was coding the routines I realised that having a table and a single macro would have been a better approach. But for now will just finish the routines using the naive approach and figure out the lookup table/macro idea later.
Here is a taste of what I have been up to..
In this case I was highlighting H8, just to confuse the code below is for A8.. but you get the idea.
Now just have to finish the rest of the board... another immediate change is using a constant instead of hard-coding the purple highlight colour. That will be painful to go back and edit for all of the square otherwise...
Progress was OK today, I managed to 'refactor' the code so now it is a little less of a mess. Next thing that got done, I created a table of all the possible positions for the graphics on the board. So now no more guess work - if I want A6 I know exactly where it is on the screen.
https://nofile.io/f/KC1XyR1ysc8/boardxy.pdf
This is my reference for figuring out the square positions on the board.
This was to help create my square highlighter, but I realised after I can use it for positioning of the chessmen on the board also. So it was more useful than I had imagined at first.
As you can see from the programming questions I kinda got stuck with the whole drawing the chessmen on the screen (or should I say, loading the data into the video ram). I moved on to a part of the program I knew I could complete and cracked on with that.
So today was spent working on the square highlighter functions. For each square of the board I want to be able to highlight the square. So I needed to know the positions for each of the squares on the board, so I could write the colour data to the attribute data of the memory.
Everything went to plan, however as I was coding the routines I realised that having a table and a single macro would have been a better approach. But for now will just finish the routines using the naive approach and figure out the lookup table/macro idea later.
Here is a taste of what I have been up to..
In this case I was highlighting H8, just to confuse the code below is for A8.. but you get the idea.
Code: Select all
HIGHLIGHTBOARDA8:
ld hl, 22528+132 ; top left
ld (hl), 30 ; purple highlight
ld hl, 22528+133 ; top right
ld (hl), 30 ; purple highlight
ld hl, 22528+164 ; bottom left
ld (hl), 30 ; purple highlight
ld hl, 22528+165 ; bottom right
ld (hl), 30 ; purple highlight
ret
Re: Crap 0.1 first assembly project
Forgot the most important part, the tap! You can see the highlighter running along blacks back rank. R-tapes sounds are also present.
https://nofile.io/f/0qHvna9nbtC/test6.tap
https://nofile.io/f/0qHvna9nbtC/test6.tap
Re: Crap 0.1 first assembly project
Made a lot of progress this evening thanks to the help of all you kind fellows.
While you can't see them - there are 32 chessmen all on the board in the right place. The issue is I assumed that the chessmen would over write the board background but I was wrong. There is an attribute issue that I need to fix. (well that is my guess.) You can see the line of rooks at the top because the highlighter is showing the back row.
hunch there is probably a step I am missing.
Still its great to see the little blighter's on the screen even if I have to switch off the background to do it..
See... there hiding.
Now granted I still need to create the sprites for the rest of the chessmen. figure out the attribute issues but the major hurdle has been overcome.
While you can't see them - there are 32 chessmen all on the board in the right place. The issue is I assumed that the chessmen would over write the board background but I was wrong. There is an attribute issue that I need to fix. (well that is my guess.) You can see the line of rooks at the top because the highlighter is showing the back row.
hunch there is probably a step I am missing.
Still its great to see the little blighter's on the screen even if I have to switch off the background to do it..
See... there hiding.
Now granted I still need to create the sprites for the rest of the chessmen. figure out the attribute issues but the major hurdle has been overcome.
Re: Crap 0.1 first assembly project
Congrats! And you could just use the sprites you have as an innovative chess variant - RookPawn. Or something.
I don't follow - what's the crack with the attribute problem?
I don't follow - what's the crack with the attribute problem?
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Crap 0.1 first assembly project
Hint: All hail the mighty XOR.
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.
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.
Re: Crap 0.1 first assembly project
Nice one. This is already a non-crap game )))
I think the attribute problem is just that you have to merge the piece colour with the board colour when you draw them.
You'll have to pick a non-white colour for the white pieces, say red, so there are four permutations:
B = Bright
P = Paper
I = Ink
Your formulae for the attribute is Ink + (Paper * 8) + 64.
There's a number of ways you can do it, with additions or masking (and, or, xor, etc).
I think the attribute problem is just that you have to merge the piece colour with the board colour when you draw them.
You'll have to pick a non-white colour for the white pieces, say red, so there are four permutations:
Code: Select all
black piece on a white square = %01 111 000 = 56
black piece on a green square = %01 100 000 = 96
red piece on a white square = %01 111 010 = 122
red piece on a green square = %01 100 010 = 98
^ ^^^ ^^^
B PPP III
B = Bright
P = Paper
I = Ink
Your formulae for the attribute is Ink + (Paper * 8) + 64.
There's a number of ways you can do it, with additions or masking (and, or, xor, etc).
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Crap 0.1 first assembly project
Ahh so i end up with a 'cut out' from the background.. will need to figure out how to do that
Yes I guess it could be used for like a chess tutor / chess problems. Then there is always pawn apocalypse.
The problem with the attributes is ... well my theory really only works for the white squares as they would be the same colour.. I really am not sure what the issue is with the green squares...
Ahh Ok, so I will need to edit the background then...Seven.FFF wrote: ↑Fri Jan 05, 2018 7:18 pm Nice one. This is already a non-crap game )))
I think the attribute problem is just that you have to merge the piece colour with the board colour when you draw them.
You'll have to pick a non-white colour for the white pieces, say red, so there are four permutations:
Code: Select all
black piece on a white square = %01 111 000 = 56 black piece on a green square = %01 100 000 = 96 red piece on a white square = %01 111 010 = 122 red piece on a green square = %01 100 010 = 98 ^ ^^^ ^^^ B PPP III
B = Bright
P = Paper
I = Ink
Your formulae for the attribute is Ink + (Paper * 8) + 64.
There's a number of ways you can do it, with additions or masking (and, or, xor, etc).
Code: Select all
main: org $80e8 ; (33000)
jp start
start:
call SETHELPSCREEN
call SETMAINSCREEN ; calls the subroutine SETMAINSCREEN
call HIGHLIGHTBOARDA8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDB8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDC8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDD8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDE8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDF8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDG8
call SFX
call SETMAINSCREEN
call HIGHLIGHTBOARDH8
call SFX
call NEVERENDINGSTORY ; calls the subroutine NEVERENDINGSTORY
NEWGAMEPLACECHESSMEN:
ld b,4
ld c,4
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,6
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,8
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,10
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,12
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,14
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,16
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,4
ld c,18
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,6
ld c,4
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,6
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,8
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,10
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,12
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,14
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,16
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,6
ld c,18
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,18
ld c,4
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,6
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,8
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,10
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,12
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,14
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,16
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,18
ld c,18
call yx2cell
ld hl,tilegraphic_rook
call drawtile
ld b,16
ld c,4
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,6
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,8
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,10
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,12
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,14
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,16
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ld b,16
ld c,18
call yx2cell
ld hl,tilegraphic_pawn
call drawtile
ret
drawtile: ;arrive HL pointing at tile graphic, DE at screen memory
ld b,16 ;loop counter for 16 px high tile
drawtileloop:
ld a,(hl) ;get byte of graphic
ld (de),a ;plonk it in screen memory
inc hl ;next byte of graphic
inc e ;next column of screen
ld a,(hl) ;right hand side of tile
ld (de),a
inc hl ;next byte of graphic
dec e ;back to left hand side of tile
call nextlinedown ;move DE down one screen line
djnz drawtileloop
ret
;
nextlinedown: ;arrive DE at screen address, move it down one pixel line
inc d
ld a,d
and 7
ret nz
ld a,e
add a,32
ld e,a
ret c
ld a,d
sub 8
ld d,a
ret
yx2cell: ;arrive with b=y column 0-23, c=x column 0-31, point DE at corresponding screen address
ld a,b
rrca
rrca
rrca
and 224
or c
ld e,a
ld a,b
and 24
or 64
ld d,a
ret
tilegraphic_pawn:
db 0,0
db 0,0
db 0,0
db 0,0
db 0,0
db 3,192
db 7,224
db 7,224
db 7,224
db 3,192
db 1,128
db 1,128
db 1,128
db 3,192
db 7,224
db 0,0
tilegraphic_rook:
db 0,0
db 0,0
db 0,0
db 0,0
db 10,80
db 15,240
db 7,224
db 3,192
db 3,192
db 3,192
db 3,192
db 3,192
db 3,192
db 7,224
db 15,240
db 0,0
background_definition:
incbin "crapbkg2.scr" ; the background data is in this file
helpstring: defb 16, 8, 17, 0, 22, 3, 4, "If you have an issue, here is a tissue..."
defb 16, 7, 17, 0, 22, 4, 4, "If you have an issue, here is a tissue..."
defb 16, 6, 17, 0, 22, 5, 4, "If you have an issue, here is a tissue..."
defb 16, 5, 17, 0, 22, 6, 4, "If you have an issue, here is a tissue..."
defb 16, 4, 17, 0, 22, 7, 4, "If you have an issue, here is a tissue..."
defb 16, 3, 17, 0, 22, 8, 4, "If you have an issue, here is a tissue..."
defb 16, 2, 17, 0, 22, 9, 4, "If you have an issue, here is a tissue..."
defb 16, 1, 17, 0, 22, 10, 4, "If you have an issue, here is a tissue..."
defb 16, 8, 17, 0, 22, 11, 4, "If you have an issue, here is a tissue..."
defb 16, 7, 17, 0, 22, 12, 4, "If you have an issue, here is a tissue..."
defb 16, 6, 17, 0, 22, 13, 4, "If you have an issue, here is a tissue..."
infostring: defb 16, 2, 17, 6, 22, 21, 9, "White to move..." ; this is the information bar at the bottom of the screen
;this is the players moves - when the game is finished it will be updated from the input but for now its just placeholder stuff.
string: defb 16, 3, 17, 0, 22, 3, 21, "e4v bd6"
defb 22, 4, 21, "d4 Nf6"
defb 22, 5, 21, "Nc3 Nbd7"
defb 22, 6, 21, "Nf3 e5"
defb 22, 7, 21, "Bc4 exd4"
defb 22, 8, 21, "Nxd4 Ne5"
defb 22, 9, 21, "Be2 Be7"
defb 22, 10, 21, "O-O Bd7"
defb 22, 11, 21, "f4 Ng6"
defb 22, 12, 21, "Be3 O-O"
defb 22, 13, 21, "Qd3 c6"
defb 22, 14, 21, "h3 d5"
defb 22, 15, 21, "e5 Ne8"
defb 22, 16, 21, "g4 Nc7"
defb 22, 17, 21, "Nf3 Re8"
defb 22, 18, 21, "f5 Nf8"
defb 22, 19, 21, "g5 b5"
eostr: equ $
board: defb 2, 3, 4, 6, 5, 4, 3, 2
defb 1, 1, 1, 1, 1, 1, 1, 1
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 1, 1, 1, 1, 1, 1, 1, 1
defb 2, 3, 4, 6, 5, 4, 3, 2
SETTEXT: ; sets up the text on the main screen
call SETPLAYERMOVELIST ; calls the subroutine SETPLAYERMOVELIST
call SETPROGRAMOUTPUT ; calls the subroutine SETPROGRAMOUTPUT
ret ; return
SETBORDER: ; sets the colour of the border
ld a,d ; Set the colour to red (2).
call $229b ; (8859) Set permanent border colours.
ret ; return
CLEARSCREEN: ; clears the screen
ld a,71 ; White ink (7), black paper (0), bright (64).
ld (23693),a ; Set our screen colours.
xor a ; Load accumulator with zero.
call 8859 ; Set permanent border colours.
call 3503 ; Clear the screen, open channel 2.
; call $daf ; (3503) Clear the screen, open channel 2.
ret ; return
SFX:
zap:
ld d,16 ;speaker = bit 4
ld e,0 ;distance between speaker move counter
ld b,255 ;overall length counter
blp0: ld a,d
;and 248 ;keep border colour the same
out (254),a ;move the speaker in or out depending on bit 4
cpl ;toggle, so we alternative between speaker in and out to make sound
ld d,a ;store it
ld c,e ;now a pause
blp1: dec c
jr nz,blp1
dec e ;change to inc e to reverse the sound, or remove to make it a note
djnz blp0 ;repeat B=255 times
ret
HIGHLIGHTBOARDA8:
ld hl, 22528+132
ld (hl), 30
ld hl, 22528+133
ld (hl), 30
ld hl, 22528+164
ld (hl), 30
ld hl, 22528+165
ld (hl), 30
ret
HIGHLIGHTBOARDB8:
ld hl, 22528+134
ld (hl), 30
ld hl, 22528+135
ld (hl), 30
ld hl, 22528+166
ld (hl), 30
ld hl, 22528+167
ld (hl), 30
ret
HIGHLIGHTBOARDC8:
ld hl, 22528+136
ld (hl), 30
ld hl, 22528+137
ld (hl), 30
ld hl, 22528+168
ld (hl), 30
ld hl, 22528+169
ld (hl), 30
ret
HIGHLIGHTBOARDD8:
ld hl, 22528+138
ld (hl), 30
ld hl, 22528+139
ld (hl), 30
ld hl, 22528+170
ld (hl), 30
ld hl, 22528+171
ld (hl), 30
ret
HIGHLIGHTBOARDE8:
ld hl, 22528+140
ld (hl), 30
ld hl, 22528+141
ld (hl), 30
ld hl, 22528+172
ld (hl), 30
ld hl, 22528+173
ld (hl), 30
ret
HIGHLIGHTBOARDF8:
ld hl, 22528+142
ld (hl), 30
ld hl, 22528+143
ld (hl), 30
ld hl, 22528+174
ld (hl), 30
ld hl, 22528+175
ld (hl), 30
ret
HIGHLIGHTBOARDG8:
ld hl, 22528+144
ld (hl), 30
ld hl, 22528+145
ld (hl), 30
ld hl, 22528+176
ld (hl), 30
ld hl, 22528+177
ld (hl), 30
ret
HIGHLIGHTBOARDH8:
ld hl, 22528+146
ld (hl), 30
ld hl, 22528+147
ld (hl), 30
ld hl, 22528+178
ld (hl), 30
ld hl, 22528+179
ld (hl), 30
ret
HIGHLIGHTBOARDA7:
ld hl, 22528+196
ld (hl), 30
ld hl, 22528+197
ld (hl), 30
ld hl, 22528+228
ld (hl), 30
ld hl, 22528+229
ld (hl), 30
ret
HIGHLIGHTBOARDA6:
ld hl, 22528+260
ld (hl), 30
ld hl, 22528+261
ld (hl), 30
ld hl, 22528+292
ld (hl), 30
ld hl, 22528+293
ld (hl), 30
ret
HIGHLIGHTBOARDA5:
ld hl, 22528+324
ld (hl), 30
ld hl, 22528+325
ld (hl), 30
ld hl, 22528+356
ld (hl), 30
ld hl, 22528+357
ld (hl), 30
ret
HIGHLIGHTBOARDA4:
ld hl, 22528+388
ld (hl), 30
ld hl, 22528+389
ld (hl), 30
ld hl, 22528+420
ld (hl), 30
ld hl, 22528+421
ld (hl), 30
ret
HIGHLIGHTBOARDA3:
ld hl, 22528+452
ld (hl), 30
ld hl, 22528+453
ld (hl), 30
ld hl, 22528+484
ld (hl), 30
ld hl, 22528+485
ld (hl), 30
ret
HIGHLIGHTBOARDA2:
ld hl, 22528+516
ld (hl), 30
ld hl, 22528+517
ld (hl), 30
ld hl, 22528+548
ld (hl), 30
ld hl, 22528+549
ld (hl), 30
ret
HIGHLIGHTBOARDA1:
ld hl, 22528+580
ld (hl), 30
ld hl, 22528+581
ld (hl), 30
ld hl, 22528+612
ld (hl), 30
ld hl, 22528+613
ld (hl), 30
ret
SETMAINBACKGROUND: ; sets the main screen background
ld bc,$1b00 ;length of block to copy
ld hl,background_definition ;source address
ld de,$4000 ;destination address
ldir ;copy BC bytes from HL to DE
ret ; return
SETPLAYERMOVELIST: ; prints the player move list
ld a, 2 ; loads 2 into register A
call $1601 ; (5633)
ld de, string ; get the players moves
ld bc, eostr-string ; figure the length
call $203c ; (8252) make the rom call
ret ; return
SETPROGRAMOUTPUT: ; prints the program output (prompts)
ld a, 2 ; loads 2 into register A
call $1601 ; (5633)
ld de, infostring ; get the infomation to player
ld bc, eostr-infostring ; figure the length
call $203c ; (8252) make the rom call
ret ; return
NEVERENDINGSTORY: ; infinite loopin'
jp NEVERENDINGSTORY ; round and round and round we go...
SETHELPSCREEN:
ld d,2 ; sets register d to 2 (used to tell SETBORDER we want red)
call SETBORDER
call CLEARSCREEN ; calls the subroutine CLEARSCREEN
;call SETMAINBACKGROUND ; calls the subroutine SETMAINBACKGROUND
call SETHELPTEXT ; sets the help text
ret
SETMAINSCREEN: ; sets up the main screen
ld d,1 ; sets register d to 1 (used to tell SETBORDER we want blue)
call SETBORDER ; calls the subroutine SETBORDER
call CLEARSCREEN ; calls the subroutine CLEARSCREEN
;call SETMAINBACKGROUND ; calls the subroutine SETMAINBACKGROUND
call NEWGAMEPLACECHESSMEN
call SETTEXT ; calls the subroutine SETTEXT
ret ; return
SETHELPTEXT: ; prints the help screen text
ld a, 2 ; loads 2 into register A
call $1601 ; (5633)
ld de, helpstring ; get the infomation to player
ld bc, eostr-helpstring ; figure the length
call $203c ; (8252) make the rom call
ret ; return
end main
Ok I figured out what was up - as Seven-FFF pointed out my attributes were all out of whack...
still got to finish the white side pieces
Re: Crap 0.1 first assembly project
Yeah, Chess has an interesting problem from the point of view of the Speccy display because a white piece either has to have a different image or different attributes from a black piece on the same square. It's a lot easier on machines like the CPC where you can just use four arbitrary colours....
Re: Crap 0.1 first assembly project
Oh hell yes, I should have but didn't see the white INK/PAPER thing coming. If you're sticking with a green/white grid you'll need different graphics/colours for the white pieces depending where they land.
I guess this is the fork in the road between having to refund and not! Though an easy get out could be to make it a battle between black and red.
I guess this is the fork in the road between having to refund and not! Though an easy get out could be to make it a battle between black and red.
Re: Crap 0.1 first assembly project
Yea at the back of my mind there was a nagging doubt about the colours but I dismissed it, then boom. Will just have to be black/red.AndyC wrote: ↑Fri Jan 05, 2018 9:45 pm Yeah, Chess has an interesting problem from the point of view of the Speccy display because a white piece either has to have a different image or different attributes from a black piece on the same square. It's a lot easier on machines like the CPC where you can just use four arbitrary colours....
Yes you are right, Black and red is not so bad choice, I totally forgot about the colour issues with the spectrum until it happened haha. Even back of the magazine advert software needed visible graphics to avoid the dreaded refund request. Can't really do black and white graphics as people would quite rightly complain its not a zx80/zx81.R-Tape wrote: ↑Fri Jan 05, 2018 10:18 pm Oh hell yes, I should have but didn't see the white INK/PAPER thing coming. If you're sticking with a green/white grid you'll need different graphics/colours for the white pieces depending where they land.
I guess this is the fork in the road between having to refund and not! Though an easy get out could be to make it a battle between black and red.
Red and black seems a good way to proceed. mmmm going to look fabulous against a green square
Never mind I think even with a colour combination seemingly selected by a blind person people would still suck up the purchase and persevere with it.
I been trying to make heads or tails of the MACRO command for pasmo but the documentation is not so helpful. Are there any examples on how get the syntax to work? I been throwing , [ ( at it but pasmo is complaining its getting unexpected surprises)
so what I am trying to do is pass a value to the macro..
Code: Select all
STAMP_SQU MACRO [CONSTANT]
ld hl, 22528+CONSTANT
ld (hl), p2colour_WS
ld hl, 22528+CONSTANT+1
ld (hl), p2colour_WS
ld hl, 22528+CONSTANT+64
ld (hl), p2colour_WS
ld hl, 22528+CONSTANT+65
ld (hl), p2colour_WS
ENDM
Re: Crap 0.1 first assembly project
I remember butting up against pasmo macros too. I think I deleted all my working examples when I abandoned it and moved onto a different assembler.
There's a random example here that threatens to work...
Yours look right except you don't need the square brackets. It's markup to indicate optional parameters, rather than something you type.
There's a random example here that threatens to work...
Code: Select all
RESERVE MACRO wSize,IReg
PUSH IReg
LD IReg,-wSize
ADD IReg,SP
LD SP,IReg
ENDM
FREE MACRO wSize,IReg
LD IReg,wSize
ADD IReg,SP
LD SP,IReg
POP IReg
ENDM
...
RESERVE ADDFUNC_Size,IX
...
FREE ADDFUNC_Size,IX
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Crap 0.1 first assembly project
Lol - I tried with commas, without brackets, nothing is working. Lol these labour saving/efficiency steps seem to be a huge time sink with little pay off.Seven.FFF wrote: ↑Sat Jan 06, 2018 1:16 am I remember butting up against pasmo macros too. I think I deleted all my working examples when I abandoned it and moved onto a different assembler.
There's a random example here that threatens to work...
Yours look right except you don't need the square brackets. It's markup to indicate optional parameters, rather than something you type.Code: Select all
RESERVE MACRO wSize,IReg PUSH IReg LD IReg,-wSize ADD IReg,SP LD SP,IReg ENDM FREE MACRO wSize,IReg LD IReg,wSize ADD IReg,SP LD SP,IReg POP IReg ENDM ... RESERVE ADDFUNC_Size,IX ... FREE ADDFUNC_Size,IX
Is there an assembler for z80 that is extensively documented and has a less cryptic syntax that is full featured? That runs on linux natively?
Hang on... pasmo is expecting me to RESERVE and FREE those sound like you are priming a one shot operation.. from the stack won't that end up being slower? what's the point of the thing if it can't be used repeatedly. I must be missing the point totally. Ok I can see an edge case where you won't know some values until execution but that seems such a specific problem compared to letting a man have a function be passed values.
There must be an analogy to user functions that receive parameters somewhere...
hmm.. I must be missing something obvious. - EDIT Yes I was being a big dummy.
There is no spoon.
There is no spoon.
There is no spoon.
Lol - I forget that I can just write the subroutine to use either a memory location or a bunch of registers to achieve the result I want. Now I just need to figure out how to make it happen..
Last edited by Nomad on Sat Jan 06, 2018 3:28 am, edited 1 time in total.
Re: Crap 0.1 first assembly project
Yes, I've confused you even further, sorry FREE and RESERVE aren't anything important, just examples of some dude's macros with parameter syntax that presumably worked for the dude.
I just tried it, and hit the same problems you did. Investigating further...
My answer to all such questions is Zeus It has an inbuilt emulator and good macro support, and you can step through your source code. And it does run under Wine. Other brands are available...
Macros aren't really functions, they're expanded out into their full form at assembly time. What appears to be parameters is really hardcoded. For example, if you had this (assuming you got it to work properly!):
the assembler would actually generate
The illusion of a function is useful to make your code more readable and avoid unnecessary copypaste, but you have to retain a good sense of what code the assembler is actually generating, otherwise you'll run into problems. Another thing Zeus can do do is list out the hex values of the code it's assembling alongside your source code, so you always know what you're generating.
"Real" functions are usually done with call and ret, loading the parameters into registers (or memory addresses, as you said) before you call them. You could rewrite the previous example using a as the parameter:
Does that make sense?
I just tried it, and hit the same problems you did. Investigating further...
My answer to all such questions is Zeus It has an inbuilt emulator and good macro support, and you can step through your source code. And it does run under Wine. Other brands are available...
Macros aren't really functions, they're expanded out into their full form at assembly time. What appears to be parameters is really hardcoded. For example, if you had this (assuming you got it to work properly!):
Code: Select all
TEST MACRO Foo
ld b, Foo
MEND
TEST 1
TEST 2
TEST 3
Code: Select all
ld b, 1
ld b, 2
ld b, 3
"Real" functions are usually done with call and ret, loading the parameters into registers (or memory addresses, as you said) before you call them. You could rewrite the previous example using a as the parameter:
Code: Select all
ld a, 1
call Test
ld a, 2
call Test
ld a, 3
call Test
...
Test:
ld b, a
ret
Last edited by Seven.FFF on Sat Jan 06, 2018 3:31 am, edited 4 times in total.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Crap 0.1 first assembly project
Ha, we posted at the same time, but you got there first
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Crap 0.1 first assembly project
Day 6: 359 days left..
The story so far
So the plan tonight is to re-write some of the subroutines, and work on the rest of the chessmen graphics. After misunderstanding the use of macro's It was time to re-evaluate what I had done so far. Like a Spartan with a deformed baby, there was only one thing to do with such of-spring. leave it on the rocks to be eaten by the birds... Lol. Being serious - I want to rewrite what I have done so far to make it easier to read, reduce the amount of duplication and make it easier to cannibalize for later projects. I figure the time I spend now will solve a lot of potential issues later on.
Plus learning a bit more about z80 and the specy has the potential to make better choices in writing the program. That can't be a bad thing. I would say to anyone reading this who is keen to try assembly on the z80 systems. The best way to learn is to tackle a project that is just beyond what you can do. Compared to where I started I learned a lot. Now sure its not R-type or gift of the gods, but realistically nobody is going to make a good game straight from the jump start. Got to strive for something that is just beyond the current ability level. So what I am saying is pick a project that will test you, and give you a kicking. But there has to be a chance of you overcoming the problems it presents... The worst thing you can do as a beginner (in my shoes) is pick something so way beyond in terms of difficulty that no matter how good your progress you are just never going to overcome the problems the project presents. See what I mean...
The difficult projects come later, after the experience won from tackling the easy stuff (single screen, limited/no animation, limited interaction) and build upon that. One day I might get to making a scrolling rpg or a bullet shooter but that is just not a fesable idea for a first project. That is where I get frustrated with a lot of the tutorials or the books they will sell you a fantasy that as a beginner you will be able to create projects that are a near professional level. I understand marketing, nobody is going to buy a book or watch the adds of a tutorial that promises a guy the ability to write a game of battleship or tick tac toe. It has to be something impressive. These things tend to oversell what a beginner can realistically expect to do, while critically underselling/concealing that to go beyond the basics requires a very deep understanding of the platform to achieve the effects most people probably want for the games (scrolling, graphics, sound manipulation)..
The need for speed...
A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
I could just do a naive brute force approach (like what I was doing before, but that will result in 64 separate subroutines for the clear square alone..), this is in addition to all of the subroutines for placing the chessmen on the various squares of the board 64x12... That starts to become a nightmare to keep track of. So its got to the point where I need to move on from that and get to a stage where I can create subroutines that can be more flexible. So despite my dislike of the books that is the most logical option is to see what they have to say.
Once the code is less naive and repetitious I think it should have a speed improvement, if its still slow then I will need to look at the use of the rom routines. There are probably optimisations to be made with custom subroutines but I don't want to go down that particular rabbit hole until I have too. Plus at this stage have to be realistic about my skill level - I am barely getting by as is, trying to write custom subroutines to replace the rom stuff will probably not result in a significant speed increase just because the routines would be crap quality at the moment. Baby steps!
The story so far
So the plan tonight is to re-write some of the subroutines, and work on the rest of the chessmen graphics. After misunderstanding the use of macro's It was time to re-evaluate what I had done so far. Like a Spartan with a deformed baby, there was only one thing to do with such of-spring. leave it on the rocks to be eaten by the birds... Lol. Being serious - I want to rewrite what I have done so far to make it easier to read, reduce the amount of duplication and make it easier to cannibalize for later projects. I figure the time I spend now will solve a lot of potential issues later on.
Plus learning a bit more about z80 and the specy has the potential to make better choices in writing the program. That can't be a bad thing. I would say to anyone reading this who is keen to try assembly on the z80 systems. The best way to learn is to tackle a project that is just beyond what you can do. Compared to where I started I learned a lot. Now sure its not R-type or gift of the gods, but realistically nobody is going to make a good game straight from the jump start. Got to strive for something that is just beyond the current ability level. So what I am saying is pick a project that will test you, and give you a kicking. But there has to be a chance of you overcoming the problems it presents... The worst thing you can do as a beginner (in my shoes) is pick something so way beyond in terms of difficulty that no matter how good your progress you are just never going to overcome the problems the project presents. See what I mean...
The difficult projects come later, after the experience won from tackling the easy stuff (single screen, limited/no animation, limited interaction) and build upon that. One day I might get to making a scrolling rpg or a bullet shooter but that is just not a fesable idea for a first project. That is where I get frustrated with a lot of the tutorials or the books they will sell you a fantasy that as a beginner you will be able to create projects that are a near professional level. I understand marketing, nobody is going to buy a book or watch the adds of a tutorial that promises a guy the ability to write a game of battleship or tick tac toe. It has to be something impressive. These things tend to oversell what a beginner can realistically expect to do, while critically underselling/concealing that to go beyond the basics requires a very deep understanding of the platform to achieve the effects most people probably want for the games (scrolling, graphics, sound manipulation)..
The need for speed...
A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
I could just do a naive brute force approach (like what I was doing before, but that will result in 64 separate subroutines for the clear square alone..), this is in addition to all of the subroutines for placing the chessmen on the various squares of the board 64x12... That starts to become a nightmare to keep track of. So its got to the point where I need to move on from that and get to a stage where I can create subroutines that can be more flexible. So despite my dislike of the books that is the most logical option is to see what they have to say.
Once the code is less naive and repetitious I think it should have a speed improvement, if its still slow then I will need to look at the use of the rom routines. There are probably optimisations to be made with custom subroutines but I don't want to go down that particular rabbit hole until I have too. Plus at this stage have to be realistic about my skill level - I am barely getting by as is, trying to write custom subroutines to replace the rom stuff will probably not result in a significant speed increase just because the routines would be crap quality at the moment. Baby steps!
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Crap 0.1 first assembly project
You could simply invert the attributes of the selected square to make it stand out.Nomad wrote: ↑Sat Jan 06, 2018 8:30 am A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
ROM routines are very rarely (if ever) optimized for speed. We normally use them to save space. The printout routine is notorious for being utterly slow (but very flexible and universal). It takes approximately one whole frame to print a line of 32 characters on the screen. I can do the same in less than one-fifth of that time but at the expense of 19–40 bytes, depending on complexity.
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.
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.
Re: Crap 0.1 first assembly project
A man's reach must exceed his grasp or what is Devon for?
That's one way of doing it, another would be to make the position change in a 64 position map of the positions...Nomad wrote: ↑Sat Jan 06, 2018 8:30 am The need for speed...
A big part of the slowdown with the program at the moment is i and reloading the whole background between square highlights. That is wasteful. I want to write an attribute erase/reset subroutine to enable the program to just reset one square and not have to reload the whole background. I think that will improve the speed significantly.
chessmap:
db 8,9,10,11,12,10,9,8 ;black pieces tiles 7-12
db 7,7,7,7,7,7,7,7
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0
db 1,1,1,1,1,1,1,1 ;white pieces tiles 1-6
db 2,3,4,5,6,4,3,2
...and then just redraw all the pieces (pixels only) including empty spaces. Then you wouldn't have to worry about deleting this bit and redrawing the next. The tile method I provided does 64 tiles in less than 2 frames, 1 frame would be better (and with optimisation is possible), but the eye wouldn't detect the change in turn based game like this.
Re: Crap 0.1 first assembly project
I like the position map idea, that would a good way to keep track of the board. with a screen printer that just endlessly looped over the map using the tile code you showed would work a treat I think.What's a man's age? He must hurry more, that's all;
Cram in a day, what his youth took a year to hold:
Will get cracking.
In other news, inexplicably (well to me) Zeus decided it would run under wine on my machine. small mercy's indeed. Will make debugging much easier now.
Re: Crap 0.1 first assembly project
Day 7: 358 days left..
Progress: Have a much better understanding of the basics of z80 instructions, figure time spent getting the basics straight will pay dividends later on and lead to a better game. (and less bugs, mistakes). Thankfully I now have figured out how to use subroutines/functions within assembler. (I am not the sharpest pencil in the tin lol it took a while.)
With this revelation came the realisation I needed to re-factor what I had previously done with the game. Have all of the interesting ideas/suggestions on how to make the game better and get it finished from you fellows.
More preparation stuff went on today, set up a lab book, so I can record all of my noob experiments in z80 assembler so I can refer back to when either I forget or I screw something up later. Plus with this method I can clearly reference where I got such and such an idea from.. I think overall it will help keep my notes straight and make it easy to look stuff up later. Especially laying the groundwork for porting the software its going to be useful to have a clear set of notes for later. I don't want to go back and have to dig through hundreds of pages of notes when the time comes to port another game to say msx or cpc.
How do the rest of you guys keep your notes straight when writing programs for the microcomputers? Any tips or hints?
More on the research side, currently downloading the archive.org mirror of WOS. the TOSEC archive i'll get next. With those two I should have a fair chunk of all zx spectrum software and most of the magazines.
On more general z80 stuff, found some good articles on how the original calculator functions were written by HP. The journals are good sources for information on the thinking behind the development of the early software. Plus the journals are just full of vintage test equipment/calculator porn.
Game wise - today will start re factoring the code. It is boring but I think long term it will save a lot of time and make what finally does come out more useful in future projects. Stuff like a general menu system, stuff like that if its well written will be able to be used many times in my projects.
But overall not must progress to the game today. More storing up win for later.
Progress: Have a much better understanding of the basics of z80 instructions, figure time spent getting the basics straight will pay dividends later on and lead to a better game. (and less bugs, mistakes). Thankfully I now have figured out how to use subroutines/functions within assembler. (I am not the sharpest pencil in the tin lol it took a while.)
With this revelation came the realisation I needed to re-factor what I had previously done with the game. Have all of the interesting ideas/suggestions on how to make the game better and get it finished from you fellows.
More preparation stuff went on today, set up a lab book, so I can record all of my noob experiments in z80 assembler so I can refer back to when either I forget or I screw something up later. Plus with this method I can clearly reference where I got such and such an idea from.. I think overall it will help keep my notes straight and make it easy to look stuff up later. Especially laying the groundwork for porting the software its going to be useful to have a clear set of notes for later. I don't want to go back and have to dig through hundreds of pages of notes when the time comes to port another game to say msx or cpc.
How do the rest of you guys keep your notes straight when writing programs for the microcomputers? Any tips or hints?
More on the research side, currently downloading the archive.org mirror of WOS. the TOSEC archive i'll get next. With those two I should have a fair chunk of all zx spectrum software and most of the magazines.
On more general z80 stuff, found some good articles on how the original calculator functions were written by HP. The journals are good sources for information on the thinking behind the development of the early software. Plus the journals are just full of vintage test equipment/calculator porn.
Game wise - today will start re factoring the code. It is boring but I think long term it will save a lot of time and make what finally does come out more useful in future projects. Stuff like a general menu system, stuff like that if its well written will be able to be used many times in my projects.
But overall not must progress to the game today. More storing up win for later.
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Crap 0.1 first assembly project
I have three words for you: comments, comments, comments. Comment the bejeezus out of your code. Assembly is a tricky language. Source code can be very ambiguous, so you need to spend much more time writing comments than writing the actual code. And don’t rely on “oh, I know what I’m doing here, I don’t need to comment it”—you’ll forget it within a day or two.
Here’s a typical example of my code:
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.
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.
Re: Crap 0.1 first assembly project
Thanks for the tip, I see what you mean about commenting the code - its not just best practice its pretty essential for it to be of use later on. Will try and get my comments to that standard in my own work.
Re: Crap 0.1 first assembly project
Here's a question for you though: if you read that code that Ast A. Moore has posted above, either by reading the code or reading the comments, can you tell me what it does? i.e. not what each line does, but what the actual routine does?
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.