Combining Old School Code with New Found Games

Shogi in Pascal - Two skills in one project

The full project can be seen Here for download and contribution.

Dev Floppy Image

sha256: cb728b44de5f717ef50a9ef21e0d5f823ac20bf2252c801db70639e15ec5b689

As I get older, I find myself trying to keep busy. Whether it is with work, finding a job in the Computer Science field, making projects, or editing my website, I try to find a new challenge once the old one has been completed. Recently on my yearly vacation I chose to go to New York and while there I went into a chess shop. While looking at their chess sets I found something new. A beginner shogi board by KUMON.

After taking it home and practicing it for a while, I fell in love with the movement and the strategy. It requires more mental effort then chess and also has more interesting piece movements. After playing the physical game I also wanted to go online and have it on the go. With multiple online shogi applications and downloadable versions it was easy to continue practicing and enjoying the game wherever I was.I found websites like 81Dojo, Shogi Wars, and LiShogi, as well as github apps like shogihome, slack-shogi, and countless libraries for python and even Rust to quickly implement and make your own shogi game. I thought, I could do that, but I did not want to do yet another program in python. I wanted to do a language that I had not used before. It then came to me. I had an Amstrad PPC 512 that I was playing old school games like Kings Quest and Zork on. If I could get shogi running on that thing from the 1980s, that would be an amazing project and a chance to keep using an old computer to do new things that I love. After googling what languages were available to use on the Amstrad (as not all languages are going to run on a 'luggable' computer from close to 50 years ago) I found it could run early C, Pascal, Assembler, Basic, and some older ones as well. While I saw plenty of shogi programs in floavours of C, I could not find any even in archives that were written in Pascal. Thats when I decided to go forward with this idea and make a running shogi program in Pascal that not only could run on a half-century old computer, but also on modern hardware for anyone to use.

Starting Moves

What I wanted to make was a shogi game that could let someone play against an actual other human or against a computer opponent if you did not have someone to play against. I wanted the computer opponent (AI) to have different levels of difficulty as the player got better at the game. I wanted to have a general rules menu to help explain the value of each piece. Above all else I wanted to actually see the board and the pieces on screen rather then just text on the screen and have the player imagine the board. Lastly, and most importantly, it needed to fit on a 720 kB floppy disk as it needed to run on the Amstrad which meant size was everything. Nothing big and fancy, but still visually good enough to play for hours. Armed with that knowledge, I got to work.

The first thing I had to do was make sure I could compile Pascal in the first place on the Amstrad. The DOS disk that came with the computer had a basic setup from the previous owner that included BASIC but not Pascal. This lead me to find Free Pascal and also Turbo Pascal 4.0. While both are compilers for Pascal, Turbo Pascal was meant for the older systems and free pascal ran well on my newer hardware. What I decided to do was run Turbo Pascal on the Amstrad and Free Pascal on my modern computer. This way I could test and debug on my modern computer and then compile and run it on the Amstrad to see if it worked.

Handyman's Secret Weapon: Duct Tape it all together

The next issue was size. The pascal compiler needed to go onto a floppy disk but also not take up to many slots on the computer. The Amstrad 512 only has two floppy disk drives and while one of them ran the boot files like ms-dos, the other one I decided would be only the game. That way anyone could share and swap the floppy disk for a new one. That also meant more room on the game floppy if needed without the compiler taking up space. No where online had the Turbo Pascal compiler on the same drive as MS-DOS so I had to make my own. Using imaging software I took the files from the DOS disk I already had, removed uneeded files, loaded on the Turbo Pascal compiler, and also put on some other compilers on there for future projects I may want to do. The .img file of the Developer Floppy Disk is available at the top of the page as well as the sha256 hash to compare to make sure it wrote to the disk correctly.

Using two different compilers was not the main problem. It was making sure it compiled on both systems. While it would compile fine on the newer systems that could handle errors smoother and had better understanding of the files, older systems had limits on memory, limits on file name size, even limits on screen size and resolution. This was a bit of a problem but as development went on, The easiest solution was making sure it ran on modern hardware and looked polished, then sending it over to the Amstrad to check if there were any inconsistantcies at compile time. Doing this, I could scale back on the parts that needed it while keeping the rest of the code as modular and robust as possible. Also limiting the Dev Disk to one slot allowed for easier swapping of the game floppy between the laptop and the PPC for hot fixes and redesigns.

Style Points: What should it look like?

This is currently up for debate and ideas. The Amstrad did not have native Kanji as an option for writing. This meant instead of the traditional Kanji on the pieces, they needed to be labeled with their Latin letter counterparts. This could be a problem later in development when pieces need to be promoted and their is not a standard Latin letter translation for this besides one meant for a different piece. This could mean in a game, the pawn (like some other pieces) gets promoted to basically a gold general. This would be easy enough to code, just swap out a pawn "code" visually for a gold general piece "code" and continue. But then if it is then captured, it turns back into a pawn and can be used by the opponent as their piece. Not only would you have to then keep track of what piece it was before but also what it can turn into and also who owns it. This seems like a lot of extra work for what seems at the time as a quick fix. The other option is use non standard latin characters for promoted pieces so it is easier to track what piece is what on the board, switch between promotions easier, and also have an idea of what piece is more valuable to your opponent. Think of it this way, if you had the oppurtunity to take a piece that can still fly around the board after capture or take a piece that goes back to being a pawn that can only move one space forward, you probably want to take the higher value piece and also visually be able to tell the difference between the two. There is an option to bring Kanji into the game through some wizardry so I will be trying that out after I get more of the game rules and functions fleshed out. I do not want the project to get 'feature creep' and have to many moving parts at the same time. There is also a way to visually represent an actual shogi board and moving pieces but this also will have to wait. The game must be playable first fully before trying to make it look beautiful. Function over form.

AI: back when it was not scary and was easier to beat

Now before anyone freaks out, AI did not mean what it means now back in the day. AI used to be just the algorithms and logic that a computer would use to make a game challenging or solve a problem.The opponents in the original Mike Tyson's Punch out had an AI that made each character have its own move set. Deep Blue was an AI computer that went up against a grand master chess player in the 1990s. Even when I was a kid, Mario Kart Double Dash had AI to determine how hard the other racers would be. So when I talk about AI in this project it is not shoving Claude or ChatGPT into old hardware and saying look how good and smart my project is! The AI I am using to make the computer opponents are algorithms that progressively get more and more difficult as you go higher. The first level just choses a random move from a list of possible moves, sometimes making a smart one along the way. The next level uses a little bit of skill and searches the board and picks a better move then the previous algorithm. THe last one uses a minmax algorithm to see what the most profitable move would be and compares it to the lesser options to make its decision. This should give not only beginners a chance to feel out the play style and try out new stratagies, but also get harder as they become more used to the game. Any and all comments or improvements from human developers will be considered and I appriciate any forks and PRs to help make the game better. While these are the AIs that I chose for the primary build, I am not apposed to adding more layers and more sophistication to this project as it moves forward. It is also cool to be programming a computer player to a computer that was around before Deep Blue since that famous match happened in 1996-1997 and this hardware is a decade old by that point.

How to play: Learn Shogi to code Shogi

Youtube Link to Learn Basics of Shogi

As with chess, shogi has a lot of pieces that move in very different ways. Some move only in one direction for the whole game, some can move diagonally across the whole board in one go. Almost all pieces promote and are able to move even more spaces when getting into the promotion zone. All of this needs to be represented correctly and coded into the game without making mistakes. Pieces can not just take a detour outside of the board, like a knight, then appear back on the board for a sneak attack. Pieces also can be captured and used by the opponent which means they need to be stored and owned by a player as well even when not on the board. Pieces also need to be able to switch between their promoted versions and then back once captured. This can provide alot issues and will be the mainbrunt of the development cycle. Making sure all pieces move correctly, take other pieces correctly, change during promotion and capture, and then also are correctly owned by the correct player are very important. this gives me the most intrigue into this project as this would technically be the final stage. Once everything is working correctly and pieces act like they should, it can be considered a finished project and all that is left is polish and visual improvements. I am looking forward to what this project becomes.

In Conclusion - What I Learned

As this is an ongoing project, this section will be filled out at the projects conclusion.