This is my favorite. Except the selected piece should be moving higher above the board to make it more visible.
3D Chess 2K18
- Einar Saukas
- Bugaboo
- Posts: 3139
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I agree Einar, this is the effect I find the easiest to spot whats going on, and actually the one I first came up with some time ago. Achieving it isn't difficult either. The piece can go up to 12 lines higher than standard, whereas in this demo, its only 4 lines.
Although I had said earlier that I've deliberately not looked at other Chess games to not be influenced in any direction, thats no longer true, as I have been playing a few to get a feel of how it needs to run to be comfortable.
Raised pieces is common and perfectly ok. Also, colouring or shading the square or available squares to move to is mostly how its done, which is what I have working currently.
Something I'm working on at the moment is what to use the spare upper 4 bits available in each of the squares in the board data.
So far;
Currently selected piece
Pawn has its first move available still
King in Check
Can't think of anything else at the mo, but I'm sure there are further possibilities.
Although I had said earlier that I've deliberately not looked at other Chess games to not be influenced in any direction, thats no longer true, as I have been playing a few to get a feel of how it needs to run to be comfortable.
Raised pieces is common and perfectly ok. Also, colouring or shading the square or available squares to move to is mostly how its done, which is what I have working currently.
Something I'm working on at the moment is what to use the spare upper 4 bits available in each of the squares in the board data.
So far;
Currently selected piece
Pawn has its first move available still
King in Check
Can't think of anything else at the mo, but I'm sure there are further possibilities.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I've just realised that I must be an idiot!
I just spotted the most ridiculous sequence of instructions and saved a byte without any effort at all. Got the main thing down to 493 bytes now.
Work and experiments are still progressing on the game version.
I now have some rudimentary move options displayed. i.e. which squares the selected piece can move to. Surprisingly easy actually. All to do with offsets!
I just spotted the most ridiculous sequence of instructions and saved a byte without any effort at all. Got the main thing down to 493 bytes now.
Work and experiments are still progressing on the game version.
I now have some rudimentary move options displayed. i.e. which squares the selected piece can move to. Surprisingly easy actually. All to do with offsets!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I thought this bit might be tricky!
I've (almost) got the piece movement logic working and its 91 bytes, which actually doesn't feel too heavy.
Only 46 bytes of movement vector data tables, which are quite repetitive, so may well get smaller yet.
The piece selected then has all of its available squares that it can move to shaded, which can be scrolled through to select which move to perform, or select the piece and cancel that move.
The maths involved in checking which moves are legal is mostly quite easy, but from a few HUGE irritations.
So far En Passant and promotion aren't integrated, but should be quite simple to add. The initial state of the Pawns with their extra move availability works, but will interfere in other areas, so I need to alter that still.
Castling, maybe. Not sure on that one yet.
It is starting to take shape finally.
I've (almost) got the piece movement logic working and its 91 bytes, which actually doesn't feel too heavy.
Only 46 bytes of movement vector data tables, which are quite repetitive, so may well get smaller yet.
The piece selected then has all of its available squares that it can move to shaded, which can be scrolled through to select which move to perform, or select the piece and cancel that move.
The maths involved in checking which moves are legal is mostly quite easy, but from a few HUGE irritations.
So far En Passant and promotion aren't integrated, but should be quite simple to add. The initial state of the Pawns with their extra move availability works, but will interfere in other areas, so I need to alter that still.
Castling, maybe. Not sure on that one yet.
It is starting to take shape finally.
Re: 3D Chess 2K18
Yesterday I came across this great chess program ChesSkelet, some tribute to the famous zx81 1K chess, but even smaller in just 377 bytes!
The program doesnt support some of chess rules (castling, stalemates, repetitions draw) but is generally quite functional.
I think it can be useful as a reference for creating a "3D Chess 2K18" chess engine.
Alex Garcia has developed a program on the ZX-Spin emulator, assembly code is available as well as online emulation.
I also think that the program should be added to the ZXDB database, as another very valuable new title.
http://chesskelet.x10host.com/
The program doesnt support some of chess rules (castling, stalemates, repetitions draw) but is generally quite functional.
I think it can be useful as a reference for creating a "3D Chess 2K18" chess engine.
Alex Garcia has developed a program on the ZX-Spin emulator, assembly code is available as well as online emulation.
I also think that the program should be added to the ZXDB database, as another very valuable new title.
http://chesskelet.x10host.com/
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
This is absolute Dynamite!!!
Great explanations for how it was conceived and programmed, and enough detail about how it works for me to be reasonable happy that amazingly, many of the concepts and game mechanics I've coded so far are very close to his.
I'm astounded that I came to exactly the same conclusion regarding the off board testing, where there is a standard mechanism called 0x88 which checks if a square lies within the board boundaries. Without any online searching I came up with the same thing, but because of the alignment of my board, it won't work fully. I check top/ bottom and sideways moves with 0x48 and then there are 2 further checks for diagonal moves.
If I could adapt my board layout to be 128 byte, then perhaps this might be useful in other areas too.
The movement vectors and distances are almost the same as I came up with too. It's nice to know i'm on the right track!
Great explanations for how it was conceived and programmed, and enough detail about how it works for me to be reasonable happy that amazingly, many of the concepts and game mechanics I've coded so far are very close to his.
I'm astounded that I came to exactly the same conclusion regarding the off board testing, where there is a standard mechanism called 0x88 which checks if a square lies within the board boundaries. Without any online searching I came up with the same thing, but because of the alignment of my board, it won't work fully. I check top/ bottom and sideways moves with 0x48 and then there are 2 further checks for diagonal moves.
If I could adapt my board layout to be 128 byte, then perhaps this might be useful in other areas too.
The movement vectors and distances are almost the same as I came up with too. It's nice to know i'm on the right track!
Re: 3D Chess 2K18
Great, I'm really glad, to hear that.
I found it quite accidentally, I simply didnt believe it was possible to make a functional chess program in only 377 bytes.
The first thing I thought was that with this or similar engine, you can comfortably complete your chess within 1K.
I found it quite accidentally, I simply didnt believe it was possible to make a functional chess program in only 377 bytes.
The first thing I thought was that with this or similar engine, you can comfortably complete your chess within 1K.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
It does miss a lot of functionality in 377 bytes, but its been written well enough to allow extra features to be fairly easily added.
Although I've only read through the code briefly, I can already see a few areas where some little improvements could be made to the size based upon the way I've achieved the same thing. But its written in a very careful way to align 2 x 256 aligned pieces of code so that switching between them works correctly. Any changes would probably break that.
I've managed to make my original display routine read through and display a 128 byte left aligned board with the addition of only 6 bytes so far, which isn't too bad. Using that layout might assist with many calculations later on.
Although I've only read through the code briefly, I can already see a few areas where some little improvements could be made to the size based upon the way I've achieved the same thing. But its written in a very careful way to align 2 x 256 aligned pieces of code so that switching between them works correctly. Any changes would probably break that.
I've managed to make my original display routine read through and display a 128 byte left aligned board with the addition of only 6 bytes so far, which isn't too bad. Using that layout might assist with many calculations later on.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
One thing that puzzles me though is the reason for his numbering of the pieces, though that could be to do with their relative values in the game.
Pawn = 01
Knight = 02
Bishop = 03
Castle = 04
Queen = 05
King = 06
3D Chess 2k18 numbers as follows;
Pawn = 01
Castle = 02
Knight = 03
Bishop = 04
Queen = 05
King = 06
I guess it has to be a scoring thing.
Pawn = 01
Knight = 02
Bishop = 03
Castle = 04
Queen = 05
King = 06
3D Chess 2k18 numbers as follows;
Pawn = 01
Castle = 02
Knight = 03
Bishop = 04
Queen = 05
King = 06
I guess it has to be a scoring thing.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
the extended board architecture is now working with the addition of just +5 bytes to the original routine.
Reading, and checking the board and move legality just got a lot easier, so 5 bytes added there will hopefully save many more elsewhere.
Reading, and checking the board and move legality just got a lot easier, so 5 bytes added there will hopefully save many more elsewhere.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Its all gone a bit mad with work, so not had a huge amount of time to dedicate to this lately. A few experiments have given reasonable results and the size of the main routine has just reduced by a further -1 byte courtesy of a nifty swap from ix-hl to do some searchy stuff. Once things get past Easter I expect I'll have a little more time.
Routine now at 492 bytes
Routine now at 492 bytes
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: 3D Chess 2K18
If your job interferes with your Spectrum programming, I think it’s obvious you need to quit your job.
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.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes
I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: 3D Chess 2K18
Absolutely. I do my best coding while smoking, cooking, pacing around the room, and running errands around town. Staring at my code for hours on end usually leads to frustration and not much progress overall.arkannoyed wrote: ↑Fri Apr 12, 2019 4:48 pm I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
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: 3D Chess 2K18
I'd ask that maybe you'd add another sentence or two explaining, at a high level, what you spotted and how you optimised it. And how you spotted it, if there's a pattern or something which others might learn from.arkannoyed wrote: ↑Fri Apr 12, 2019 4:48 pm Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes
I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
Not that I mean to be impudent, demanding what you should tell us. But you're clearly an expert on optimising Z80 code, and I for one, as a beginner/intermediate level Z80 coder, could learn a huge amount from you if you'd ever care to share it.
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.
Re: 3D Chess 2K18
Extremely impressive what can be done in such a small amount of memory just goes to show how much is wasted within a PC.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I know, I’m trying my best to comment the source, then explanations will make sense. Maybe tomorrow!dfzx wrote: ↑Sun Apr 14, 2019 1:27 pmI'd ask that maybe you'd add another sentence or two explaining, at a high level, what you spotted and how you optimised it. And how you spotted it, if there's a pattern or something which others might learn from.arkannoyed wrote: ↑Fri Apr 12, 2019 4:48 pm Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes
I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
Not that I mean to be impudent, demanding what you should tell us. But you're clearly an expert on optimising Z80 code, and I for one, as a beginner/intermediate level Z80 coder, could learn a huge amount from you if you'd ever care to share it.
- Einar Saukas
- Bugaboo
- Posts: 3139
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
At the risk of going further off topic - Yeah, I had that when it came out. Quite an achievement, but nothing on the order of Quake as a game. And besides, that was four times bigger at 128k (compressed, with procedurally generated textures, levels and sounds).
It was more a jab at the idiocy of the zack4mac's assessment of the state of PC software.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Back on topic!
I’ve had a rather successful morning. I’ve been studiously tidying up source in order to try and make it suitable to post in snippets with explanations. Like a sort of mini series on what bits do what I suppose. Anyway, I have a few inspired moments, and I’ve only gone and saved 4 more bytes!! So the main code is now 486 bytes
Which is comprised of 260 code and 226 data
The initialise board routine had to sacrifice a byte as it was sharing the first byte (01 from ld BC) of the code as the terminating byte for its data. So that’s now back at 40 bytes. However, there’s a brand new method of calculating the screen address sort of cumulatively, whereas before it was done from a base address each time. This is obviously faster, though not noticeably. A few other tweeks here and there and voila!
Nearly there with tidying up source, even with the new bits, though it’s probably harder to understand now!!
I’ve had a rather successful morning. I’ve been studiously tidying up source in order to try and make it suitable to post in snippets with explanations. Like a sort of mini series on what bits do what I suppose. Anyway, I have a few inspired moments, and I’ve only gone and saved 4 more bytes!! So the main code is now 486 bytes
Which is comprised of 260 code and 226 data
The initialise board routine had to sacrifice a byte as it was sharing the first byte (01 from ld BC) of the code as the terminating byte for its data. So that’s now back at 40 bytes. However, there’s a brand new method of calculating the screen address sort of cumulatively, whereas before it was done from a base address each time. This is obviously faster, though not noticeably. A few other tweeks here and there and voila!
Nearly there with tidying up source, even with the new bits, though it’s probably harder to understand now!!
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
.....and another byte saved!! That’s over 1% size reduction today alone!!
Amazing the things that happen when you’re in the right frame of mind, and perhaps caffeine fuelled!!
Now 485 bytes
Amazing the things that happen when you’re in the right frame of mind, and perhaps caffeine fuelled!!
Now 485 bytes
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Part 1: The Graphics format
Before I start to try and explain the decoding and how the board is displayed, its important to cover the format that the graphics data takes.
The data is quite simple, but incorporates control codes along the way that decide when to jump to different parts of the data stream according to which piece is currently being printed.
The data entry point is the same for all, as the bases are all common.
The pieces are numbered as follows;
2/3 = Pawns
4/5 = Rooks
6/7 = Knights
8/9 = Bishops
A/B = Queens
C/D = Kings
Obviously these are Hex values. 00 = empty square.
What happens when we perform a shirt right on the piece number is that we get the following;
1 = Pawn
2 = Rook
3 = Knight
4 = Bishop
5 = Queen
6 = King
BIT 0 was indication whether it was a White (0) or Black (1) piece.
Accessing the graphics data is identical whether its a Black or white piece, but the difference in appearance is all down to that BIT 0 being used to alter the data.
There are two separate routines used to print the board. One handles the screen addressing, and searching through the board, along with printing the board squares (only Black are printed to save time)
The other routine is then called if a piece occupies the square. This builds the specific line of the piece and prints it. It also handles all of the graphics data addressing and handling the control codes within it.
The Graphics Data
There are 5 distinct types to graphics data for the build routine to handle. It was a long task to find a good balance between compact graphics data and the procramming to decode it.
1. Standard lines.
For all lines, the data is built in the HL and DE register pairs.
Standard lines are 1 byte long, and indicated by bit 7 being set to 0.
There are 4 bits of data which according to that Black or White bit (BIT 0) are either left as is (White) or inverted (Black)
The rest of the line is created using that colour bit to fill in.
The lower 3 bits of the data byte hold a counter to create the correct line length.
Depending upon whether its a Black or White line, the registers are swapped (EX DE,HL) before printing which swaps the shading (the 4 bits of data) to either side.
2. Mini lines.
These are also 1 byte of data where the lower 4 bits create a symmetrical line which is the same whether Black or white
3. BWL-BWR lines.
These lines consist of 2 bytes of data where the second byte is the Right side data and the lower 5 bits of the 1st byte are XOR'd onto it to create the Left side data. Same line for Black or White.
4. BLR-WLR lines.
These are again 2 bytes of data. They create a version of each other where the colour bit is XOR'ed to alter the data.
5. Long lines.
These are 5 byte lines which allow for complex lines where Black and White are often very different to one another (see Knights for example). The 1st bytes lower 6 bits hold bits 8-10 for each side. The lines can be a maximum of 22 bits long.
The 4 bytes folowing are arranged as follows
1 = Black data Right
2 = Black data Left
3 = White data Right
4 = White data Left
The Black data has the colour byte (FF=Black, 00=White) applied (AND) as a mask. Then the White data is XOR'ed onto it. This might seem odd, but in programming terms, it gives a simple (ish) cycle to get which data we need and keep the addressing simple. The Black data needs to be the XOR'ed result with White. Mindbending to hand encode I can confirm!
Black and White pieces are both the same size, so the same data is used and just changed according to some simple transforms to give the correct final resulting piece.
Originally the sprites and board were designed circa 1994-95. The data at that time was in the form of simple masked sprites at a size of 4000 bytes. The board again was a straight bitmap of 6144 bytes. Then there was a print routine and tables of all the piece print addresses and sizes and graphics data address too. All in it was about 11k.
Now nearly 25 years later its 485 bytes!
I'm not really sure what drove me to want to squash the size so dramatically, but its become quite a pleasing excercise in both encoding and programming, where my Z80 skills have really had to improve a lot.
Part 2 will examine the first part of the routine that handles creating the screen address of the squares and setting up the piece height for the print loop.
Hopefully as I go through the various parts, the process might become clearer to some. It has become far simpler as the routine has developed fortunately, and is now a very solid reliable thing. No nasty registers (IY, R, I etc) or any use of EXX that might interfere with things. Its also quite simple to add-in extra things as in what will need to be there to create the functionality of the GUI in the eventual playable entity.
Before I start to try and explain the decoding and how the board is displayed, its important to cover the format that the graphics data takes.
The data is quite simple, but incorporates control codes along the way that decide when to jump to different parts of the data stream according to which piece is currently being printed.
The data entry point is the same for all, as the bases are all common.
The pieces are numbered as follows;
2/3 = Pawns
4/5 = Rooks
6/7 = Knights
8/9 = Bishops
A/B = Queens
C/D = Kings
Obviously these are Hex values. 00 = empty square.
What happens when we perform a shirt right on the piece number is that we get the following;
1 = Pawn
2 = Rook
3 = Knight
4 = Bishop
5 = Queen
6 = King
BIT 0 was indication whether it was a White (0) or Black (1) piece.
Accessing the graphics data is identical whether its a Black or white piece, but the difference in appearance is all down to that BIT 0 being used to alter the data.
There are two separate routines used to print the board. One handles the screen addressing, and searching through the board, along with printing the board squares (only Black are printed to save time)
The other routine is then called if a piece occupies the square. This builds the specific line of the piece and prints it. It also handles all of the graphics data addressing and handling the control codes within it.
The Graphics Data
There are 5 distinct types to graphics data for the build routine to handle. It was a long task to find a good balance between compact graphics data and the procramming to decode it.
1. Standard lines.
For all lines, the data is built in the HL and DE register pairs.
Standard lines are 1 byte long, and indicated by bit 7 being set to 0.
There are 4 bits of data which according to that Black or White bit (BIT 0) are either left as is (White) or inverted (Black)
The rest of the line is created using that colour bit to fill in.
The lower 3 bits of the data byte hold a counter to create the correct line length.
Depending upon whether its a Black or White line, the registers are swapped (EX DE,HL) before printing which swaps the shading (the 4 bits of data) to either side.
2. Mini lines.
These are also 1 byte of data where the lower 4 bits create a symmetrical line which is the same whether Black or white
3. BWL-BWR lines.
These lines consist of 2 bytes of data where the second byte is the Right side data and the lower 5 bits of the 1st byte are XOR'd onto it to create the Left side data. Same line for Black or White.
4. BLR-WLR lines.
These are again 2 bytes of data. They create a version of each other where the colour bit is XOR'ed to alter the data.
5. Long lines.
These are 5 byte lines which allow for complex lines where Black and White are often very different to one another (see Knights for example). The 1st bytes lower 6 bits hold bits 8-10 for each side. The lines can be a maximum of 22 bits long.
The 4 bytes folowing are arranged as follows
1 = Black data Right
2 = Black data Left
3 = White data Right
4 = White data Left
The Black data has the colour byte (FF=Black, 00=White) applied (AND) as a mask. Then the White data is XOR'ed onto it. This might seem odd, but in programming terms, it gives a simple (ish) cycle to get which data we need and keep the addressing simple. The Black data needs to be the XOR'ed result with White. Mindbending to hand encode I can confirm!
Black and White pieces are both the same size, so the same data is used and just changed according to some simple transforms to give the correct final resulting piece.
Originally the sprites and board were designed circa 1994-95. The data at that time was in the form of simple masked sprites at a size of 4000 bytes. The board again was a straight bitmap of 6144 bytes. Then there was a print routine and tables of all the piece print addresses and sizes and graphics data address too. All in it was about 11k.
Now nearly 25 years later its 485 bytes!
I'm not really sure what drove me to want to squash the size so dramatically, but its become quite a pleasing excercise in both encoding and programming, where my Z80 skills have really had to improve a lot.
Part 2 will examine the first part of the routine that handles creating the screen address of the squares and setting up the piece height for the print loop.
Hopefully as I go through the various parts, the process might become clearer to some. It has become far simpler as the routine has developed fortunately, and is now a very solid reliable thing. No nasty registers (IY, R, I etc) or any use of EXX that might interfere with things. Its also quite simple to add-in extra things as in what will need to be there to create the functionality of the GUI in the eventual playable entity.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Part 2: The Beginning
So, swiftly on to the second part, and now for some actual code!!
This is the start of the routine, and a few parameters are set up.
The Board is stored as a simple 64 byte array at address FFC0h (65472). For easy end checking, when the end is reached, the lo byte address counter will reach 00.
The Screen address is calculated from a base value, then just incremented with each pass, taking into account when we need to reset it to the start of a row.
+0022 to go to the next square
+ff30 to reset to next row, square 0
then after the calculation we save that value on the stack for the next pass and correct it to give a valid screen address.
This involves 3 shifts left of the H register, done in a loop by setting the top 3 bits previously to '110' and checking for no Carry to end. simple!
Within the routine, B is set to FF for addressing the board. D is the line counter, used in a few places later in the routine.
HL now points to the bottom line of the square. The squares are all based upon 4 bytes width, and we're pointing to the 3rd byte along (second from the right).
So, swiftly on to the second part, and now for some actual code!!
This is the start of the routine, and a few parameters are set up.
The Board is stored as a simple 64 byte array at address FFC0h (65472). For easy end checking, when the end is reached, the lo byte address counter will reach 00.
Code: Select all
chess_build:
ld hl,0c9c0h ;initial value to calculate squares SCReen addr.
ld c,l
main_loop:
ld a,c ;current square into A
and 07h ;check row
ld de,0ff30h ;DE=next row add value
ld b,d ;B=FF
jr z,ovr_main ;if were still on the same row
ld de,0022h ;then add to go to the next square
ovr_main:
add hl,de ;add
push hl ;save cumulative square address
scr_crt:
sla h ;correct to create SCReen address
jr c,scr_crt ;loop 3 times
;square 00 address = 4810h
+0022 to go to the next square
+ff30 to reset to next row, square 0
then after the calculation we save that value on the stack for the next pass and correct it to give a valid screen address.
This involves 3 shifts left of the H register, done in a loop by setting the top 3 bits previously to '110' and checking for no Carry to end. simple!
Within the routine, B is set to FF for addressing the board. D is the line counter, used in a few places later in the routine.
HL now points to the bottom line of the square. The squares are all based upon 4 bytes width, and we're pointing to the 3rd byte along (second from the right).
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Part 2a:How High?
Next up is the little routine that checks which piece is occupying the current square and sets its height into the counter B. We also initialise IX with the entry point for the Graphics data.
The table of height vectors is stored at FF00h, so by altering the Lo byte to be the piece code, we can easily find the number we need.
The piece occupying the square is also placed into E for use a little later on in the routine, where the main check takes place to either leave the square empty or print a piece on it.
Next up is the little routine that checks which piece is occupying the current square and sets its height into the counter B. We also initialise IX with the entry point for the Graphics data.
Code: Select all
get_height:
ld d,c ;save C
ld a,(bc) ;A=piece occupying the current square
ld e,a ;into E for use later on
rra ;/2 to get rid of BIT 0 (B/W bit)
ld c,a ;adjust address to point to piece heights table
ld a,(bc) ;get height
ld c,d ;restore C
ld d,b ;D=FF reset line counter
ld b,a ;B=height
ld ix,0fe44h ;IX = Graphics data entry address
The piece occupying the square is also placed into E for use a little later on in the routine, where the main check takes place to either leave the square empty or print a piece on it.