Files posted by Michael Parson
(full source available https://github.com/mparson/gridgame)
A game for the Commander X-16!
A 'C' implementation of a Flash game I used to play a lot of back in the days of Flash games.
Read about the original game here: https://jayisgames.com/review/gridgame.php
I'd say this game is ~95% faithful to that original game. Some of the limitations are due to my use of the so-called PETSCII character set for the graphics instead of custom graphics, which means there is no smooth animation of the pieces as they are activated. I've also not included any sounds, but that might come in a future version.
This is original code that implements the gameplay, I did not port the embedded ActionScript of the original SWF game.
New feature in v0.9.5:
Replayable boards, the "REPLAY" button will reset the board to where it was after the last "RESET", "EDIT" or "LOAD". Try it again, see if you can get a better score from the same starting board.
New feature in v0.9.
Click on the 'EDIT' button and you can edit the board.
Congratulations, you are now in the most frustrating and feature limited PETSCII drawing program ever.
The boarder changes to '*' from the line-drawing characters. You can now click on a piece to rotate it without triggering a chain reaction. If you click on one of the '*' on the boarder, it will change the entire row or column to match the adjacent piece.
When you 'SAVE' a board, it will not check for a previous file, it will silently overwrite it. Similarly, attempting to 'LOAD' a non-existent board will silently not load a board and return you to the editor.
Click on 'DONE' to play the board.
Why write this game?
Well, two basic reasons.
First, I decided to take another run at picking up the C programming language, and like learning any new language, it helps if you have a project in mind that you want to implement.
Why write for this platform? Being a fan of the Commodore 8-bit computers and following the development of the Commander-X16, I thought it would be a fun platform to target.
Compiling the code
This was developed with the cc65 compiler, so, you'll need it installed. I tend to work with the latest version out of git rather than one of the binary packages, so, YMMV with getting it compile if you use a potentially older version of the compiler suite.
Edit the `Makefile` and fix the paths to the various binaries at the top.
A simple `make` should give you a `GRIDGAME` that you can now load up on an X-16.
It should be a minimal effort to make a C-64 and C-128 version as well, probably coming soon.
Notes on the kwalitee of my code
Yeah, very intentional bad spelling there. I make no claims to my skills as a C programmer. This is probably not "good" C code and most definitely not optimized in the suggested ways you should when writing for `cc65` compiler and the 6502 CPU.
Potential features for future versions:
* Versions for the C-64 & C-128
* Sound - I'll need to read up on how to make cc65 generate sounds. It's documented, but I've not tried that yet. Step 1 was to get the basic game working.
* See if it will compile with KickC, then all dev work could even be done on the system it is played on!
I was reading @gavinhaslehurst's post about implementing floating point numbers based on an article in COMPUTE! magazine. So, I headed over to archive.org and looked up that issue and read the article. Then I flipped through the rest of the issue. On page 16, there was this program, LED - A Line-Oriented Text Editor, written by Arnie Lee of Abacus Software, in BASIC, for the Commodore PET (also mentioned is an APPLE II version, but I didn't see that listing in there).
So, I typed it in and ran it under VICE. Works on the PET, works on the C-64, works on the C-128.... works on the X-16!
The only changes from the original is to comment out the 2 POKEs to disable/enable RUN/STOP and changed the line-endings from CHR$(255) to CHR$(10) so the files would have regular UNIX-style newlines ending the lines.
Is it useful? Debatable.
Is it retro? For sure.
Vol. 3, No. 2
Someone asked for help creating new sdcard images to be used with the emulator, so I banged around in vim for a while and dug around in DDG until I found enough hints around using sfdisk and mtools to create a suitable file w/o needing any root permissions. Due to limits of the FAT32 filesystem, the smallest image you can format with FAT32 is 32 MB.
$ mkcard -f scratch.img -s 32 Checking that no-one is using this disk right now ... OK Disk scratch.img: 34 MiB, 35651584 bytes, 69632 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Created a new DOS disklabel with disk identifier 0x9983f409. scratch.img1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 33 MiB. scratch.img2: Done. New situation: Disklabel type: dos Disk identifier: 0x9983f409 Device Boot Start End Sectors Size Id Type scratch.img1 2048 69631 67584 33M c W95 FAT32 (LBA) The partition table has been altered. Syncing disks.
You'll need the mtools and util-linux packages installed to use the script. Unfortunately, this limits this to be only be usable by Linux users (maybe Windows 10 users with WSL as well, don't know, don't have a Win10 setup to try with), I don't see sfdisk in the macOS ported versions of util-linux packages.
To make things even easier to use these files with mtools, create a ~/.mtoolsrc file with something like:
mtools_skip_check=1 drive s: file="~/scratch.img" exclusive partition=1 drive x: file="~/basic-progs.img" exclusive partition=1 drive y: file="~/demos.img" exclusive partition=1
And now you can use mcopy to copy files to your s:, x: or y: drives. Just make sure you UPPERCASE the filenames so x16emu will display the filenames as you expect them to look.
CX16 port of the "MAD-COMPUTER" program published in the October 1985 issues of Mad Magazine