I think I feel rather queezy now! Eugh!d2010 wrote: ↑Wed Apr 17, 2019 11:20 am VIEWport music
https://youtu.be/RdQ_unzeFy4
arkannoyed wrote: ↑Fri Feb 15, 2019 3:17 pm I am interested to know if the source makes an sense to anyone perhaps more familiar with source code listings?
I generally comment mine extremely badly or not at all. I'm probably not alone in the fact that when you write something, it reads just fine to you without lengthy explanations. I do appreciate however, that the older I get, the more helpful the comments are when I revisit some past projects.
If any parts do need further explanation, then I will oblige of course.
3D Chess 2K18
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Part 7: Print the Line
So, all of the construction of the line is now done and its there in HL and DE in a form that the following routines can interpret and print in the correct form.
First, we retrieve the Screen address to print to and swap it with the Left hand side data, so a single instruction handles that;
We also save the position of HL at the centre for doing the Left side in B
The masking is done by the Least Significant Bit (LSB) being detected and inverted (reset). In the case of the Right sided data, its already in the correct direction to print quite easily and calculate a mask on the fly as follows, whilst also checking whether we're doing 1 or 2 bytes.
The Left side data is residing on the stack, so we get it into DE. The problem is that its been created in reverse form, backwards. As we're at the centre of the line though and the first bit to place is at BIT 7 of H, then we just work our way left one bit at a time until we reach the last and then invert it and return after again restoring the screen address to the centre.
And that Ladies and Gentlemen is it! I could post the Graphics data next, though thats kind of pointless, so maybe just a link to the file or the asm. Any preferences? Any questions?
So, all of the construction of the line is now done and its there in HL and DE in a form that the following routines can interpret and print in the correct form.
First, we retrieve the Screen address to print to and swap it with the Left hand side data, so a single instruction handles that;
Code: Select all
print_line:
ex (sp),hl ;put HL Left buffer on stack and retrieve screen address
ld b,l ;save SCReen address LO byte
The masking is done by the Least Significant Bit (LSB) being detected and inverted (reset). In the case of the Right sided data, its already in the correct direction to print quite easily and calculate a mask on the fly as follows, whilst also checking whether we're doing 1 or 2 bytes.
Code: Select all
right:
ld a,e ;test if E=00
or a ;
jr z,r_yes ;if E>00 then just copy D to screen.
r_no:
ld (hl),d ;put full byte on screen, no need to mask
inc l ;next L to far right byte
ld d,e ;swap E into D so the routine that follows masks E instead
r_yes:
ld a,d ;mask
dec d ;and
and d ;print D
ld e,a ;
xor d ;
and (hl) ;merge with SCReen contents
or e ;
ld (hl),a ;place on SCReen
ld l,b ;restore SCReen address LO byte
Code: Select all
get_lhs:
pop de ;LHS data retrieve from stack
ld c,80h ;left bit mask set +1 right so that DEC L happens
left:
rlc c ;next left bit
jr nc,left_ovr
dec l
left_ovr:
ex de,hl ;swap data into HL
add hl,hl ;propagate MSB
ex de,hl ;swap back to SCReen in HL, data in DE
sbc a,a ;apply carry
xor (hl) ;XOR screen contents
and c ;mask current bit
xor (hl) ;XOR screen again to write the bit
ld (hl),a ;place byte
ld a,d ;check if data finished
or e ;
jr nz,left ;loop if not
left_end:
ld a,(hl) ;change the last bit to 0
xor c ;
ld (hl),a ;
ld l,b ;restore SCReen address
ret ;
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I need a lie down!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I knew this process would be useful!
I've just corrected the problem with losing bits in the Long Lines routine by changing at what point L gets its data by placing the instruction LD L,A at the start;
I've just corrected the problem with losing bits in the Long Lines routine by changing at what point L gets its data by placing the instruction LD L,A at the start;
Code: Select all
data_line:
ld l,a ;put data into L in case of Long Line so we don't lose any bits on the 4 shift cycle
add a,a
jr c,long_line
mini_ln_tst:
cp 3eh
jr c,bit5_test
inc ixl
bit5_test:
ld e,00h ;set the outer bytes to 00
ld l,e ;L=00
add a,a
jr nc,bit4_test-1
bit5_set:
add a,d
jr bit4_res+1
long_line:
and 0e0h ;mask upper 3 bits E0h
ld e,a ;into E
lllp_00:
ld a,(ix+00h) ;get White data
and c ;mask with B/W component
xor (ix+0feh) ;apply Black data switch
ld d,h ;roll result from H into D. Pass 1 is null
add hl,hl ;propagate 3 bits in L
ld h,a ;B/W result into A
inc ixl ;next
djnz lllp_00 ;loop x 4
jr print_line ;second byte here is 07=RLCA
bit4_test:
jr nc,bit4_res ;if bit ='0' then the data for BWRL is in the 4 bits remaining in A
bit4_set:
rrca ;re-use bit to fill BIT 7, creating a left orientated mask
and c ;mask with C BW byte to create 5 bit overlay mask of ccccc000
xor d ;create the Black or White Left and Right buffer bytes
bit4_res:
ld d,a ;load Right buffer
ld h,a ;load Left buffer
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Lastly, I need to send thanks to Einar, as he wrote the original initialisation routine that sets the board at the game start. It's only had very minor changes applied since as far as I can remember. The routine is totally separate to the board build/ display one and is 40 bytes. It does have a bug, in that it swaps the White King and Queens places with one another. So far, I haven't dedicated much time to trying to correct it or come up with an alternative, though I'm sure it can be done in fewer bytes.
Code: Select all
init_board:
ld de,0ffc0h
ld b,d
ld c,d
ld hl,data_17
ib_loop1:
ld a,(hl)
dec a
ld (bc),a
ldi
jr nz,ib_loop1
dec e
ld b,20h
ib_loop2:
ld (de),a
inc e
djnz ib_loop2
ret ;23 bytes
data_17:
db 05h,07h,09h,0bh,0dh,09h,07h,05h
db 03h,03h,03h,03h,03h,03h,03h,03h,01h
- Einar Saukas
- Bugaboo
- Posts: 3145
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
You are welcome!arkannoyed wrote: ↑Wed Apr 17, 2019 1:21 pmLastly, I need to send thanks to Einar, as he wrote the original initialisation routine that sets the board at the game start.
Ops!!!arkannoyed wrote: ↑Wed Apr 17, 2019 1:21 pmIt does have a bug, in that it swaps the White King and Queens places with one another.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Nevermind!
I do have a working version I knocked together in 41 bytes, but ideally I'd love 38, as theres 38 bytes spare between the end of the routine and the board matrix. However chances are I'll find somewhere to save a byte in the code at some point anyway in which case something bigger should fit.!
I do have a working version I knocked together in 41 bytes, but ideally I'd love 38, as theres 38 bytes spare between the end of the routine and the board matrix. However chances are I'll find somewhere to save a byte in the code at some point anyway in which case something bigger should fit.!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Ch-ch-ch-ch Changes!
I suppose I'll have to do the whole damn post again! Grrrrrr!
Only 1 byte improvement actually with a change to the square calculating routine allowing a saving in the routine that sets the counter for piece height.
Now down to 484 bytes.
I suppose I'll have to do the whole damn post again! Grrrrrr!
Only 1 byte improvement actually with a change to the square calculating routine allowing a saving in the routine that sets the counter for piece height.
Now down to 484 bytes.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Oh bugger, there goes another one!
Saved another byte in the same routine, so now 483 bytes
by changing the routine to this;
Or this, does the same thing;
Saved another byte in the same routine, so now 483 bytes
by changing the routine to this;
Code: Select all
get_height:
ld e,c ;DE points to the current square
ld a,(de) ;get the piece we need in A
ld b,a ;save temp in B
rra ;/2
ld e,a ;DE points to the heights table
ld a,(de) ;get the piece height
ld e,b ;E now holds the current piece
ld b,a ;B=height
ld ix,0fe44h ;IX = Graphics data entry address
Code: Select all
get_height:
ld e,c ;DE points to the current square
ld a,(de) ;get the piece we need in A
rra ;/2
ld e,a ;DE points to the heights table
ld a,(de) ;get the piece height
rl e ;put back th B/W bit into E
ld b,a ;B=height
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
And there is the possibly to save another byte by changing the first byte of the data to 96 instead of 9E so it can act as the jump vector for the loop.
Have to watch that though in case I save more bytes. I think I'll leave it for now.
Both routines now weigh in agonisingly at 257 bytes!
Have to watch that though in case I save more bytes. I think I'll leave it for now.
Both routines now weigh in agonisingly at 257 bytes!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
And another byte saved.
Silly me, never noticed that the first byte of both the Standard line and data line routines was LD L,A. So now that can be placed before we enter either of those.
Now 482 bytes
Silly me, never noticed that the first byte of both the Standard line and data line routines was LD L,A. So now that can be placed before we enter either of those.
Now 482 bytes
Re: 3D Chess 2K18
You make animations with demos.Why the pieces don't- move in table 8x8?arkannoyed wrote: ↑Thu Apr 18, 2019 12:45 pm And another byte saved.
Silly me, never noticed that the first byte of both the Standard line and data line routines was LD L,A. So now that can be placed before we enter either of those.
Now 482 bytes
https://youtu.be/3XMqizx-8RA
Please subscribe , please you click on like-on-youtube for more-fun.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Substance abuse is a strange pastime!!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Not had a great deal of time to dedicate to this lately, but a couple of quick changes I spotted were possible this afternoon.
The first is 3 bytes saved in the Graphics data, where they can be shared elsewhere with just the addition of an extra jump vector (2 bytes)
The second I've been puzzling over for a very long time, and now I've finally figured out the maths of it. Instead of the traditional next line up routine, I've replaced it and shared the correction part from the squares calculating routine with calculating the next line up on screen.
All bafflingly complicated, however, its saved 3 bytes, and also allowed me to move the (still not completely fixed) board initialising routine to just before the board data matrix. Now there are precisely ZERO free bytes wasted inbetween.
The main routine and data is now an impressive 479 bytes!
Thats actually only 7 bytes away from the ENTIRE project fitting snugly into 512 bytes (if you include the 40 byte initialise routine)
Thankfully there seems to be no drop in speed at all.
The first is 3 bytes saved in the Graphics data, where they can be shared elsewhere with just the addition of an extra jump vector (2 bytes)
The second I've been puzzling over for a very long time, and now I've finally figured out the maths of it. Instead of the traditional next line up routine, I've replaced it and shared the correction part from the squares calculating routine with calculating the next line up on screen.
All bafflingly complicated, however, its saved 3 bytes, and also allowed me to move the (still not completely fixed) board initialising routine to just before the board data matrix. Now there are precisely ZERO free bytes wasted inbetween.
The main routine and data is now an impressive 479 bytes!
Thats actually only 7 bytes away from the ENTIRE project fitting snugly into 512 bytes (if you include the 40 byte initialise routine)
Thankfully there seems to be no drop in speed at all.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Next line up changed from this;
to this;
Then the shared correct routine is just;
I realise that out of context it probably remains puzzing!
Code: Select all
nxt_line_up:
ld a,h ;fairly standard stuff
dec h ;I'm sure we're all
and 07h ;familiar with!
jr nz,piece_loop ;
ld a,l ;
add a,0e0h ;
ld l,a ;
sbc a,a ;
and 08h ;
add a,h ;
ld h,a ;
Code: Select all
ld a,h ;adjust to the next line up
sub 20h ;
ld h,a ;
jr nc,piece_loop ;if theres no Carry, then skip the next bit
ld de,0ffe0h ;this takes care of adjusting the line
add hl,de ;and SCReen 1/3rd adjustment.
Code: Select all
scr_crt:
ld a,h ;correct the SCReen address
rlca ;
rlca ;
rlca ;
ld h,a ;HL=correct SCReen position
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Oh, and it also means no having to reset the screen address to the centre of the line before calculating next line up.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Blimey, Friday afternoons!!
Because we no longer need to restore the screen address, the B register if freed up allowing the Left hand side bit placing routine to shrink by 1 byte and get a little quicker too;
from this;
to this;
Nice! and also saves yet another valuable byte, and in a very intensive routine too!
Now at 478 bytes
Because we no longer need to restore the screen address, the B register if freed up allowing the Left hand side bit placing routine to shrink by 1 byte and get a little quicker too;
from this;
Code: Select all
left_ovr:
ex de,hl ;swap data into HL
add hl,hl ;propagate MSB
ex de,hl ;swap back to SCReen in HL, data in DE
sbc a,a ;apply carry
xor (hl) ;XOR screen contents
and c ;mask current bit
xor (hl) ;XOR screen again to write the bit
ld (hl),a ;place byte
ld a,d ;check if data finished
or e ;
jr nz,left ;loop if not
left_end:
ld a,(hl) ;change the last bit to 0
xor c ;
ld (hl),a ;
ld l,b ;restore SCReen address
ret ;
Code: Select all
left:
rlc c ;next left bit
jr nc,left_ovr ;
dec l ;move left screen address
left_ovr:
ld a,(hl) ;get SCReen byte into A
or c ;set the current bit
ld b,a ;save result in B
xor c ;reset the current bit
ld (hl),a ;write the result back to (HL)
ex de,hl ;
adc hl,hl ;shift bit 7 of H into Carry
ex de,hl ;
ret z ;if the result of ADC HL,HL=0000 then end
jr nc,left ;if no carry, then we've already reset that bit, so loop
ld (hl),b ;otherwise write the bit set result to (HL)
jr left ;loop
Now at 478 bytes
Re: 3D Chess 2K18
Please , you do no more reduce size of tap/z80.You insert more animations between
the pieces.If can not insert chess-role-game, then you insert first move.
Other you play the Chess with other game.z80, you save all moves(.Eg. A4-A6.C3-C7..)
The 3DChess-2K18 read all moves.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
the pieces.If can not insert chess-role-game, then you insert first move.
Other you play the Chess with other game.z80, you save all moves(.Eg. A4-A6.C3-C7..)
The 3DChess-2K18 read all moves.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
arkannoyed wrote: ↑Fri Apr 26, 2019 3:56 pm Oh, and it also means no having to reset the screen address to the centre of the line before calculating next line up.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
But its size is eventually intended to be below 1k, so all this reducing is still of great importance.
Re: 3D Chess 2K18
Hi there, i know you may sometimes post some stuff and then get a lack of replies, but if many are like me, we sit and lurk and keep tabs on things. I'm quite keenly following your progress, i check in daily to see whats new here, and i have to say its astounding what you have squeezed into under 500 teeny itty bitty bytes.
We all know of the age old 1k chess that exists, ascii gfx, poor rule set and slow. But without doubt a marvelous achievement.
Is your ultimate goal to create a 1k chess game but with a 3d board and full rule set? If so, then that would be an even wilder achievement.
Anyway, back to lurking
We all know of the age old 1k chess that exists, ascii gfx, poor rule set and slow. But without doubt a marvelous achievement.
Is your ultimate goal to create a 1k chess game but with a 3d board and full rule set? If so, then that would be an even wilder achievement.
Anyway, back to lurking
I don't have anything cool to put here, so i'll just be off now to see a priest with yeast stuck between his teeth and his friend called Keith who's a hairpiece thief...
Re: 3D Chess 2K18
Sheesh, and your last message before mine states exactly that...
Well, good luck, i'm keeping tabs.
Well, good luck, i'm keeping tabs.
I don't have anything cool to put here, so i'll just be off now to see a priest with yeast stuck between his teeth and his friend called Keith who's a hairpiece thief...
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Yes, the ultimate goal is to create a chess game that’s as fully featured as will fit into the 1k limit. So although all this squeezing of the core display code might sometimes seem somewhat pointless, actually every byte saved allows more space to include more functionality. I already have the legal move checking etc pretty much done, and the method that the gui will adopt is between 2 options, both easy to implement within the structure of the display code.
As far as the code squeezing goes, I saved a further 2 bytes last night, both in key areas too, which is where it gives the biggest improvement results too.
The next line up routine is now a byte smaller, though perhaps a few clicks slower, but nothing significant.
Then I managed to save another byte with some nifty code recycling in the print the left part of the line routine. That came down from 24 to 22 bytes yesterday, which even I was astounded by.
Interestingly (well to me anyway!) the total size, which only a few months ago I thought would be impossible to get near 512 bytes, is now at just 516 bytes. I’ve managed to save 36 bytes in about 3 months.
I do STILL need to rewrite the board initialising routine, and attempts so far have not managed smaller than 41 bytes. I’m favouring a recursive approach where it’s created algorithmically. I have a version that dies that in 48 bytes, but that was an early attempt. I’m sure sub 40 is possible.
So far all this continual development has fortunately not made the code any harder to add the GUI functions into, which is lucky.
As far as the code squeezing goes, I saved a further 2 bytes last night, both in key areas too, which is where it gives the biggest improvement results too.
The next line up routine is now a byte smaller, though perhaps a few clicks slower, but nothing significant.
Then I managed to save another byte with some nifty code recycling in the print the left part of the line routine. That came down from 24 to 22 bytes yesterday, which even I was astounded by.
Interestingly (well to me anyway!) the total size, which only a few months ago I thought would be impossible to get near 512 bytes, is now at just 516 bytes. I’ve managed to save 36 bytes in about 3 months.
I do STILL need to rewrite the board initialising routine, and attempts so far have not managed smaller than 41 bytes. I’m favouring a recursive approach where it’s created algorithmically. I have a version that dies that in 48 bytes, but that was an early attempt. I’m sure sub 40 is possible.
So far all this continual development has fortunately not made the code any harder to add the GUI functions into, which is lucky.
Re: 3D Chess 2K18
I'm going to chip in and also state I'm a (gobsmacked) lurker in here too, and massively appreciated the time and effort you're putting into this, not only to code it, but also to share the process with the forum. My meagre z80 assembly efforts make me aware of his monumental a task you are setting yourself here. So on behalf of the silent onlookers I just wanted to say thanks, and say I'd welcome any further up updates as they come.
CLEAR 23855
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Very kind, thank you. I appreciate that this is very much a personal crusade so far, and perhaps not something everyone might even understand the point of. But it good to know people are still looking at any updates that trickle through. I must confess, my z80 skills have improved a whole heap since I started this process. Although I still have a lot of areas of the Speccy that I’m not entirely familiar with, I’d like to think that the screen handling is now one thing I understand pretty well.
Anyway, another 2 bytes saved yesterday evening.
Incredibly, the left side print routine managed to shrink by another byte, so that’s 3 in as many days!!
I also moved the piece heights table to FF80h to take advantage of using the carry always being set prior to finding the current piece height for the print loop.
I’ll have to re-comment the altered source before I can post any details as it’s got a bit messy with all the changes.
Main routines are now only 249 bytes
Including the data 474 bytes
Total size 514 bytes
Maybe, just maybe development might move on to the next stage once those final 2 bytes can be saved.
Anyway, another 2 bytes saved yesterday evening.
Incredibly, the left side print routine managed to shrink by another byte, so that’s 3 in as many days!!
I also moved the piece heights table to FF80h to take advantage of using the carry always being set prior to finding the current piece height for the print loop.
I’ll have to re-comment the altered source before I can post any details as it’s got a bit messy with all the changes.
Main routines are now only 249 bytes
Including the data 474 bytes
Total size 514 bytes
Maybe, just maybe development might move on to the next stage once those final 2 bytes can be saved.