X16 Impressions, 2022 Feb
X16 Impressions, 2022 Feb
So I started writing BASIC on the X16 in Nov. 2019. Then I started writing C via cc65 in Nov. 2020. I've done only a tiny amount of assembly (I'd like to do more).
Here are my impressions of coding on the X16.
THE 6502
I understand (and feel) the pull to use a 65816, but I'm fine with the 6502.
THE MEMORY MAP
The memory map is fine. VERA access feels a little strangulated, but I abstract that with functions, and we can load data "directly" into VERA, which helps. I no longer fret over accessing VERA for anything except the PSG.
As I mentioned, the single-byte ports feel tight, and I've written abstraction functions to manage it. A larger window might be nice, maybe. 4 bytes could point to the X,Y registers of a sprite, or a single PSG voice. 8 bytes gets a full sprite definition.
THE RAM BANKS
RAM banks are perfectly fine and extremely useful for storing piles of data. They're especially effective with C, where I can cast structure pointers to hunks of memory in a bank.
The 8K bank size seems fine. 8K is plenty for storing chunks of string data (like instructions or lists). Multibank maps require simple math hidden in a macro or short function to swap through banks. The one place that a bank memory manager would be useful would be if I'm storing a heap or hashtable in banked RAM, and if I'm tokenizing and parsing input into banks for temporary storage. In those cases, I think fiddling with banks is kind of bothersome.
SPRITES
Sprites are reasonably easy to handle -- especially with a light library that wraps the registers used. The tricky part (for me) is creating the sprites which fit the palette and bit depth. One person helpfully wrote a Python script which converts a PNG to a C-style array of bytes. I've written a Perl script which uses that script and actually generates the loadable binary.
PSG
The PSG is almost beyond my ability right now. I think the lack of ADSR envelopes is (mostly) the reason. I will have to adapt assembly code, such as Dusan's simple sound players, to add sound to anything I write. And I'm not ready to attempt that.
BASIC
BASIC 2.0 is good as a "batch" language, for orchestrating more complex tools. Its extensions (e.g. supporting hex notation) makes it even more useful for this purpose.
BASIC is fast, for Commodore equipment. It's still too slow for arcade-style games. BASIC's speed and power is fine for rogue-like games. I think simple versions of Ultima IV-like games *could* be done with BASIC and a few assembly routines. And some patience and carefulness.
BASIC 2.0 is most effective for programs that are 8K or smaller. As your code grows past 8K, the mental load on its limited variable space and near-nonexistent structure makes it not worth your time. I find it significant that BASIC thrived in the 1980s with machines limited to 4K-16K of RAM.
BASIC 2.0 is not very fun to program in. Very early on I wrote a Perl script that lets me write in a slightly better "BASIC" on my Mac, and transpiles down to BASIC 2.0. Essentially I stopped programming in actual BASIC 2.0 within a couple of months.
C
C is effective for writing code that fills up "main RAM". It's expressive enough and seems parsimonious enough to allow sane usage of memory. Pointers to structures are really a great way to use banked RAM.
X16 Impressions, 2022 Feb
On 2/24/2022 at 1:22 PM, rje said:
The PSG is almost beyond my ability right now. I think the lack of ADSR envelopes is (mostly) the reason. I will have to adapt assembly code, such as Dusan's simple sound players, to add sound to anything I write. And I'm not ready to attempt that
I wrote a little PSG tester in BASIC, and I'm pretty pleased with the PSG. Obviously, you have to manually control the volume level, pitch, and square wave duty cycle for the ADSR envelope, but it's pretty straightforward once you have a timer operating.
I'm fairly pleased with the computer as a programming platform - we already have basic C compilers, assemblers, and a capable text editor. There are lots of little things I'd like to see added or fixed (such as an 80x25 screen mode, better BASIC functions for memory management, etc), but the platform itself is pretty solid.
X16 Impressions, 2022 Feb
On 2/24/2022 at 4:01 PM, TomXP411 said:
I wrote a little PSG tester in BASIC, and I'm pretty pleased with the PSG. Obviously, you have to manually control the volume level, pitch, and square wave duty cycle for the ADSR envelope, but it's pretty straightforward once you have a timer operating.
I, too, wrote PSG code in BASIC -- it plays Invention No. 13 of course.
Hmm maybe you're right about the timer.