This weekend, I decided to play with X16 BASIC using the emulator and wound up making an X16 adaptation/extension of a short program for the Plus/4 that appeared in 'The Transactor' journal decades ago. The program uses three parameters: "S" (squiggles/spokes/segments), "W" (wave factor), and "A" (amplitude). Using X16 BASIC's extensions in terms of bitmap drawing commands, it outputs a neat design with lots of color and a surprising amount of visual variety.
The original Plus/4 program just plotted in black and white and had some built in limitations (and at least two bugs), but I decided to extend the program, add a menu, and upload it after I added color and decided these were fairly cool looking results from such a short simple BASIC routine.
It strikes me as a cool demo because with just three core parameters, you can get an astonishing range of outputs. Of course, like many graphics demos based on stacking transcendental functions, there are combos of inputs where the functions will sort of fall apart and produce something akin to a kiddo scribbling with crayons , but there are also weird "islands" in the domain of possible parameter combinations where order re-asserts itself, both in terms of what gets drawn and how the colors play out.
There are 4 'modes' of operation you can pick from the menu. You can specify inputs for S, W and A manually; the program can run a sequence with fixed S and A while incrementing W; there is a mode that tries to picks random parameters within several domains where the program produces nice outputs; and there's one that just reads the inputs from some "presets" in DATA statements. (You can of course add your own 'best of' examples by adding data statements between lines 432 and 499).
I always considered myself a passable BASIC programmer, but this weekend showed me I'm really sort of rusty so please go easy on me if I did something inefficiently or especially 'dumb' in my implementation. The main output routine is extremely crunched (sorry, not sorry) and I did some further things to optimize from the original program for purposes of getting a bit more performance out of the main routine. Although it absolutely crawled on the Plus4, I think its fairly impressive on the X16 especially if you look at the sheer amount of sines, cosines, multiplications, and variable fetches /updates that occur during an entire cycle through the primary output drawing loops.
The X16's 40 column mode (SCREEN $00) was used to key this in and format it, so its probably best if listed/ displayed/reviewed in that mode, Tested on emulator r.38, and I don't see anything in the pending updates for the next emulator release that would break anything here.
If there are questions about why/how I did something I'll be happy to answer. In fact, if there's any interest in a more detailed write-up of this short and fairly simple program (e.g., section by section, and line-by-line), I would be happy to give it a shot, especially if there are folks new to Commodore BASIC that might find it useful. It seems to me there are many highly advanced programmers for the X16 posting on this site who are using assembly, C, and even languages they are developing themselves. Its amazing! However, its surely the case that part of the mission of the X16 is to get some newbies involved, and from where I sit, that really does mean getting some more content up here written in BASIC. Keeping that in mind, I'll probably be diving back into more old issues of The Transactor to do more conversions for the X16 and will continue to upload as long as I'm still having fun with BASIC. Cheers.
By DrTypoThis is a simple voxel demo written in 65c02 assembly. It has been tested in the r38 emulator.
Press W A S D to move around.
Press SPACE to quit.
By ZeroByteThis demo uses the real music data from Wolfenstein3d to play back on the X16's YM2151 FM synth chip.
Some features of the audio translation are not yet implemented, but the program now plays correct pitch in R38 of the emulator. I will update this posting to my R39 build when that is released officially.
The "Try It Now" feature works, but at least for me, the playback is quite choppy - the emulator itself has no problem with the playback, though.
Next update will be to make the songs selectable at runtime.
By CursorKeysWhat is double PETSCII?
What is PETSCII you may ask first.
PETSCII is the extended commodore text character set.
This character set has been designed in such a way that it would enable simple graphics on the screen.
Which would make it easy for would be programmers on the system, to make card games and so on.
However easy to use, it is not easy to create very nice graphics with it....
But... This has changed somewhat. If you search for PETSCII art, you see people are trying to get cooler and cooler graphics out of PETSCII.
Double Petscii is using the Commander 16's native graphics modes to overlay two layers of PETSCII graphics.
This demo is an experiment in how that may be used.
-It was made with the cc65, in C.
-The PETSCII mode used is lores text mode, with two layers. (40x30 chars)
-All colors are standard colors.
-1 Color is used as a color to be sacrificed for non black transparency, so there are 15 colors to work with, not 16.
-Pictures drawn in hyperpetscii petscii online drawing program. https://hyperpyxel.com/?p=229
By desertfishHow many sprites does the Commander X16 have? Let's find out, shall we!
Written in Prog8. Source code is here: https://github.com/irmen/prog8/blob/master/examples/cx16/bobs.p8
By rjeI was missing Bach's "Invention 13", and so here's the first 13 bars that Commodore Business Machines used in the early 80s for Commodore product promotions.
This is a shoot'em up game in progress. Gradually I'll update this game as it progresses, but currently this is a non-playable game. This demo for the moment documents the tile engine.
This lava planet is under attack! The player will defend the planet using an evolving ship configuration, and will need to use various landing stations on the background for repaing, refuelling and recharging weapons.
The background will also contain various defense capabilities but will also contain enemy attack sites deployed on the planet!
I use various softwares to create the graphics of the game myself (which is a lot of work!). But to speed-up the work, and to make the graphics modular, this method is the way to go!
The base software for graphics modelling is Blender (blender.org - Home of the Blender project - Free and Open 3D Creation Software). This allows me to create 3D models and to generate the graphics in retro style, pixel perfect! Tiling is done using Pyxel Edit (Pyxel Edit: pixel art and tileset creation tool) to create the tiles used for the background, based on the generated background from Blender. Sprite animations and graphics fine tuning (like palette creation and remapping), using done using Aseprite (Aseprite - Animated sprite editor & pixel art tool). The background tile engine generates a random generated background, which will result in the player needing to be tactical or strategical in his choices as time evolves.
The placement of the tiles is dynamic, based on a weighted system, so the randomness can still be "tuned" over time.
The idea is that on this background, through further weighted randomness, more and more enemy installations will appear, (and less friendly installations) and that the player will need to be careful when to recharge, repair or refluel!
Different levels will of course make this game more difficult, but that is the future ...
You can find the complete code of this game here: X16_Code/cx16-tileengine at main · FlightControl-User/X16_Code (github.com)
This program MUST be started from an sdcard, as it uses proprietary loadroutines that only work on the emulator using an sdcard configuration.
These load routines are necessary to have complete control of the memory in the X16!
Download the files into a folder, Unzip the x16.zip file, which creates an x16.vhd file. Run x16emu -sdcard x16.vhd -prg tileengine.prg -run to run the demo. Please try it out and let me know if you think this start and concept has potential and what I would need to be careful of or change.
By JeffreyRaycaster demo (written in c and assembly)
This version is a big improvement in performance: it now runs at 10+ fps! 🙂
I am quite happy with the speed. The demo plays quite nicely now.
See below description of version 1.3.0 for details.
This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster.
Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! 😉
This is how it looks now:
Speed improvements in 1.3.0:
Now running at 10+ fps! 🙂
- Using zero page addresses for pretty much all my variables
- Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication
- Inlined the fast multipliers, so less copying of values, no jsr and rts
- Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done)
- Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray
- The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused
- Cleaned up the main loop and several other parts
- Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) 🙂
New in this version 1.2.0:
- draw functions have been ported to assembly. Much faster!
- dda casting functions have been ported to assembly. Much faster!
- drawing textures!
- automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel)
- automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel)
- using joystick controls (you can use arrow keys and alt to control, you can hold down keys)
- a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup)
- changed the map to look like the first level in Wolfenstein 3D
- added a border around the render area, just like Wolfenstein 3D
Unpack the zip. Make sure you have the .BIN files in the same folder as the source files.
To compile: (this assumes cc65 is installed)
cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3
x16emu.exe -prg RAY.PRG -run
up - move forwards
down - move backwards
left - turn left
right - turn right
alt-left - strafe left
alt-right - strafe right
p - turn on log screen
o - turn off log screen
t - turn on test ray
l - rotate test ray left
j - rotate test ray right
Known issues (1.2.0)
- Sometimes there is a corner of a wall not drawn correctly
- Since there is no real V-sync you get "shearing" in the screen (requires double buffering)
- Lots of speed improvements
- Lots of cleanup of code (its messy now)
- Add a time-per-frame indicator (using a vsync interrupt counter)
- Mooaarr wall-textures!
- Double buffer to prevent shearing
- Show a map on the screen
- Bigger map (limit is now 16x16)
- Opening doors
- Add (scaled) "sprites"
- Lamps (scaled) hanging from ceiling
- Stats in lower part, gun visible
- AI, enemies
Having fun! 🙂
By x16tialVariation of the quick sort demo, but this one using the 320x240x8bpp mode, which uses double the memory, and is that much cooler to watch 🙂
Tap any key to progress from:
Random Slowed down sort Random Full speed sort Back to Basic Note: that band of "non random" pixels below the middle of the screen is the default location of character tiles at $0f800 = $0ffff. This gets moved to right after screen memory at $04000 - $047ff (which is probably where it *should* default to, if you ask me :))
By x16tialKind of a fun demo of Quick Sort on the CX16, using the random "static" of the startup VERA memory and using the 640x480 bitmap screen.
Tap any key to progress from:
Initial static Slow sort, so you can see what's going on, kind of satisfying to watch Re-randomize Full speed sort, this is 37.5k, which the CX16 sorts in a couple seconds Back to Basic Written in assembly
By CunnahThis is an early concept based upon the ideas and code shown here https://www.8bitcoding.com/p/tiles-in-assembly-ii-line-interrupt-for.html
The PARA.PRG is my first attempt recreating the psudo parallax seen in games from the 16bit and 8 bit era. This is all on the same layer the same as in the above mentioned blog. The difference here was to make the background reactive to the foreground movement. Although this is hardcoded to move 1 pixel per frame forward all the slower sections are all based on how fast the foreground is moving.
I'm hoping to expand upon this to also support vertical perspective tricks.
copy the PARA.PRG file to your emulator location or run the x16emu from the files location.
run x16emu and type the following commands
By YazwhoJust a fun small intro put together to play around with the X16 emulator.
I'm looking forward to the next iteration of the hardware and emulation, especially around the audio.
Thanks for looking!
A little demo of rendering giant text in assembly. It takes the data from the Lower/Upper character set in ROM and renders it in a large, "LCD-style" font. You can use .asciiz in CC65 for letters, or use a zero-terminated array of bytes to reference the character codes, as below (thanks to https://www.commanderx16.com/forum/index.php?/profile/5-jimmydansbo/ for the character set reference).
By desertfishVertical "raster" bars, also known as "kefren bars" from the old school demo scene.
Written in Prog8. No sprites used, it's bitmap graphics (with a trick...).
Source is here https://github.com/irmen/prog8/blob/master/examples/cx16/kefrenbars.p8
By SlithyMattThis is the example program for my video that introduces how to control the VERA using assembly language:
1-5: Set Foreground Color
0,6-9: Set Background Color
I: Zoom In
O: Zoom Out
R: Toggle Character Set
S: Convert @→🙂
T: Toggle Layer 1
P: Toggle Layer 0
C : Toggle Color 1 White/Black
The source code is available on GitHub: https://github.com/SlithyMatt/x16-assembly-tutorial/blob/main/Lesson9/vera.asm
I have been playing with the VERA chip in assembly, and have come up with a cheeky little demo screen that is reminiscent of some 80s demos I can remember as a kid. No music or fancy interactive stuff, but some of you might find it amusing.
Warning: As a GP I feel I ought to point out this demo contains flashing / strobing effects!
Thanks to the excellent tutorials of SlithyMatt - Commander X16™ Community, especially the latest one demystifying the VERA chip. I have used a lot of his code from the latest tutorial to create this demo.
By JeffreyThis is a demo to try out how far VERA can be pushed: it is quite hard to have vertically (independently) scolling bars using VERA.
What this demonstrates is that it is in possible. But only just.
It turns out I had to use 80 sprites in combination with a lot of LINE-interrupts.
Here is what I did:
- Create a 64 pixel by 5*64 pixel colored data rectangle (in this example filled with 4x4 pixel squares)
- Place 80 sprites (of 64x64 pixels) from left to right, overlapping mostly, but showing the 4 left pixels of each sprite
- These sprites are (vertically) grouped in pairs, so that each pair is placed one pixel lower than the pair next to it on the right
- The data address of each sprite (where they get their colored pixels from) are initially set to the same point (they all start with an vertical offset of 0)
- For each low-res LINE-interrupt (that is: 240 times per frame) we do the following:
- move one pair of sprites (that are *just* out of view) 64 pixels down
- change the data address so that it matches it individual vertical-offset
- At the end of all the LINE-interrups (after the 240 lines) we do the following:
- Adjust the vertical offsets with the individual change-per-frame numbers
- Move all sprites back to the top, with negative y-coordinates (according to their offsets)
It runs a maximum fps: every frame there is an update.
Warning: this demo contains (what amounts to) flashing / strobing effects.
# Known issues
- There are small horizontal lines visible at certain places. This is probably because the LINE-interrupt code is not fast enough
# Comparing hardware with emulator
I think this demo will probably not work (exactly) the same on real hardware. It's probably a good way to check whether the emulator is accurate (for certain aspects of the VERA board).
# To Compile:
cl65 -t cx16 -o VBS.PRG -l vbs.list vbs.asm
# To Run:
x16emu.exe -prg VBS.PRG -run
By rjeA demonstration of the use of BASIC, sprites, and banks to create a tiled map.
Everything is quite primitive right now. The response time is slow.
The map is 256 x 256 and stored in banks 10-17 (it's 64k). My plan is of course to make it larger.
Use the cursor keys to move about the map.
By AndyMtThis demo shows the full 4096 color palette of the X16 by using the raster line interrupt.
The matrix is 64x64 colors. Due to limitations of available CPU cycles I had to add black gaps in between the lines.
But I still thought it to be nice to look at. And it works in the Web-Emulator.
By SlithyMattThis is a demo of 26 different encodings for PCM audio playback, from the maximum bitrate (48.828 kHz, 16-bit stereo) the minimum (381 Hz, 8-bit mono) using the same non-copyright music track and fitting as much data as possible into 63 RAM banks (504 kB).
Just press different letters to hear different samples.
As seen on YouTube:
By JimmyDansboA small demo of the save_rect and rest_rect functions from the VTUI (VERA Text User Interface) library.
For more information see https://github.com/jimmydansbo/vtuilib/
It is still very much work in progress, but I thought I would share this little demo with you.
This is a quick demo of a 2D graphics library I've been working on recently. It's written in assembler, and aims to make life a bit easier when it comes to drawing vector graphics. You can define individual polygons which can be moved about and rotated. The source code looks fairly daunting, but when it comes down to it, building, transforming and rendering the polygons is very straightforward. Hopefully this will form the basis of a game at some point soon. (Perhaps an Asteroids clone?) Once I sink my teeth into interrupt handling, I should be able to "vsync" everything so it's flicker-free.
All comments and suggestions welcome!
Short screen capture of this demo on YouTube (featuring my tunez!!):
Commander X16 Demo - Vector Graphics in 6502 Assembly - YouTube
WARNING: For those who are sensitive to flickering/strobing, please be aware that this may cause problems for you.
See below for a quick preview of the game I'm working on, retro flickering and all!
By rjeThis simple demo loads five 64x64 8-bit sprite images into VRAM, each an ancient sailing ship. Sprite 0 is turned on to point at them; press spacebar to cycle through the images.
Use the cursor keys to move the sprite around the screen. The spacebar will also stop the movement.
By desertfishI needed a test program for the graphics routines in Prog8 that now also work in highres 4 color screen mode.
I thought it would be fun to replicate a classic Amiga Workbench desktop screen, using just the graphics drawing commands.
Note that the text font is actually the built-in iso charset. It is fairly similar to the Amiga's topaz font, so I just went with it and didn't bother to replicate the font pixel-perfect.
Also I didn't bother to make a nice white/red sprite mouse cursor, maybe I'll try to add this in a later version.
Here is a screenshot of a real Amiga workbench that I used as inspiration https://patric-sokoll.de/Museum/Computermuseum/Amiga_Kickstart/Amiga_Workbench_3.1_Vorschau.jpg