Knight vs. Dragon prototype on Commodore 128

My son Ben (age 9) designed all the graphics, background and colors.  He edited the background screen strictly with inverse spaces.  Sprites were edited on the Commodore 128 with SPRDEF.  The programming manual has instructions on saving the sprite memory to disk.  And I was able to save both the text screen and colors to disk also using the dual screen capability of the Commodore 128 to enter the commands via the 80 column screen (ESC+X).  My memory is that I used MONITOR to save using hex addresses, whereas I'm showing BSAVE commands here for more symmetry with the program listing.

BSAVE "SPRITES",B0,P3584 TO P4096

BSAVE "BACKGROUND",B0,P1024 TO P2048

BSAVE "COLORS",B15,P55296 TO P56320

I wrote the BASIC demo to randomly move the characters, and flash the border red when the sprites collide.

My son and I made a great team on this project.   Thanks to his art and I am very pleased to have introduced him to the Commodore 128 and have him involved in computer animation.

Links: 

dragon.d64 disk image

Commodore 128 Programmer's Reference Guide 

Left hand keyboard template and AutoHotKey

  

Back in the day (decades ago), I purchased a Matias Half Keyboard (USB) at a computer show because it was so cool.   My plan was to mouse with my right and type with my left.   There was a bit of a learning curve, and the keyboard was so tiny.  Every key was overloaded so much, I found that using function keys, hotkeys, numbers, cursor keys, etc. was too tricky.  So I ended up putting it in a drawer.   Years later I resold it on Amazon for the same price I paid.

Then years later I missed the half keyboard, want to use it occasionally.  So I looked for an alternative, and while there are other hardware half keyboard solutions out there, often they are expensive.  Even the Matias one is now listed at $595.  I paid a sixth of that long ago, but it's a niche product that only a few will need, so that figures.

A few more searches and I found that someone had created an AutoHotKey script to do the basic trick in software to make the spacebar a key modifier.   The script is straightforward and well written!

In case you don't know AutoHotKey, it is software for Windows that allows you to remap keyboard and mouse events (and other similar things) for macros, and other automation operations.  It has its own scripting language for capturing key events and performing key sends, etc.   Like you could use it to disable the Caps Lock, launch, close, and reposition your Windows on the screen, copy and paste text on the screen, and all sorts of things.

To help me learn to use this simple one-handed keyboard script, I've drawn a keyboard with Microsoft Paint, printed it out, and taped to my monitor for easy reference.   While the script supports left or right hand operation, I only drew the left hand.

Skimming the script thread, it appears others have discussed displaying a reference on the screen, so that exercise is left to the reader.

Hope this is also useful to someone else.

Vic-20 HI-RES in progress - Memory Layout

Vic-20 Graphics Memory Layout

The Vic-20 doesn't have a native graphics mode.  But it can use a character set from onboard RAM, and double the size of character cells from 8x8 to 8x16 pixels.

A solution puts video memory at address 4096 ($1000), and character RAM at ($1000).  Notice they are the same?  Yes, there's only 5K onboard RAM in addition to color RAM.   The first 1K starts at address 0 ($0000), and the other 4K starts at address 4096 ($1000).   Regardless of any other RAM present in the system (can add 35K), only that latter 4K is accessible as video/character RAM to the video chip.  (Even if the earlier 1K is available, there's too many conflicts with BASIC and KERNAL use).

So bitmapped characters (graphics) and video RAM (characters on the screen) have to share the same section of memory.  The way bytes work, at most 256 characters could be displayed on the screen, but that would require a full 4K of RAM for their bitmaps (16*256), so something has to give.   By using only 240 characters on the screen, that reserves 16*16 = 256 bytes for video memory, and the remaining memory can be used for graphics.  For the bitmap to skip over screen memory and avoiding any overlap, the characters used on the screen are indexed starting at 16 ($10).

$1000-$10EF screen (240 bytes), values $10-$FF (16 to 255)

$10F0-$10FF unused (16 bytes)

$1100-$1FFF bitmap (3840 bytes)

BASIC RAM can be moved to either 3K expansion RAM ($400-$FFF) or 8K or greater expansion RAM ($2000 and later).

One layout that is possible is 20 characters wide by 12 characters tall = 240 characters = 160x192 resolution.

The easiest layout of characters is to store them consecutively in memory as shown above.   Character layout for the screen is left to right, then wraps to the next row.   This scheme matches color memory layout as well.   An additional advantage is that time sensitive updates to graphics can be more aligned with the raster line.

Another layout of characters is to line them up vertically as shown below.  This has the advantage that memory is contiguous vertically until advancing to the next column of 8 pixels.   This allows for optimizations in managing graphics memory at the disadvantage of working vertically instead of horizontally, thus fighting the raster line.  But color memory is still horizontally oriented, so the address calculation is different, the same as the earlier layout.

 
As the Vic-20 allows for configuring the number of character columns, character rows, and adjusting top and left margins, a variety of resolutions are possible.

Some notable resolutions include

160x192, 192x160, 200x144, 144x208, 160x160

The last is mentioned as it is the resolution used by the Super Expander cartridge.  But note it only requires 200 bytes of screen memory, so using that resolution leaves 696 bytes of onboard memory unused for graphics/screen that could be available for another use, maybe 506 bytes is still text screen memory. 

Links

Vic-20 open source hi-res support (github)

Built D64 disk image for Vic-20 is here and see Usage in README.md

Extending C64 BASIC Part Three - Poke multiple bytes

This example accepts one address value, followed by multiple byte values appended to the SYS command on Commodore 64.  

This could be useful for POKEing to screen memory, sprite data, programmable character data, consecutive I/O registers, etc. efficiently in a single statement.

Links:

ACME cross assembler (optional)

poke_bytes.d64

open source (github)

Extending C64 BASIC Part Two - Parse 16-bit unsigned integer

This example parses a 16-bit unsigned integer appended to the SYS command on Commodore 64.  

The number is added to the jiffy clock as the alarm time, and a busy loop is entered waiting for the jiffy clock to advance to the alarm time.

Links:
ACME cross assembler (optional)
delay_jiffies.d64
open source (github)

Slides for C64

Forget PowerPoint or Google Slides or Apple Keynote.   Here is a newer solution for the Commodore 64.   Simply use DATA statements in BASIC to define the layout of your slides.  What could be easier than that?

Links:

• Source on github
• README.md including instructions, references, and more details
• Slides.D64 disk image for Commodore 64

easymenu64 - directory and program launcher utility for C64

 

I originally wrote this somewhere between 1985 and 1987.  I submitted the program and an article to Compute! publications but was rejected, probably not unique or attractive enough of a submission.  Well, here it is for the public to see approximately 35 years later.  Not sure if I wrote this originally in assembler, or just machine code.  I suspect I used machine code for this one.  I have done a fair job now disassembling and crafting into assembler (using ACME cross assembler) for a more modern experience.

My typical use was to either see what was on the disk, or as a game launcher.  Imagine the possibility of many games packed on a 1581 disk.  It even supports launching cartridge images.

I have used it with 1541/1571/1581 but not sure if it works with fully populated large drives.  Seems to have trouble with some non-standard drives.  I plan to review that in the future.  (Update: some fixes have been applied to the original code starting with tagged version 1.1)

Keyboard and joystick(#2) controls are documented with the source README.

Links:
    open source
    easymenu.d64 (disk image)