Edit Programmable Characters on Vic-20 and C64

 

The current release is considered fully functional and complete.

Links:

Vic-20 D64 (1541 image) and source

Commodore 64 D64 (1541 image) and source

The Commodore Vic-20 video chip added multiple features beyond what the original PET Model 2001 offered.  Besides color support, it also includes the ability to change to user defined character sets.  These can be used to customize the look and feel of a program, and also to provide bitmapped graphics.

Back in the 80s I was proud of my development of a character editor program that utilized a few machine language routines to perform quick operations via keyboard selections.   Unfortunately I don't have direct access to that program today (haven't been able to read the tape back into the computer yet).  So I decided to rewrite it again.

This time it is purely 6502 assembly code.  I started using the VICE monitor to write the initial functionality, and soon afterwards transitioned to ACME source to ease edits and additions.

After mocking up the look of the screen, identifying operations that would be nice to have, and testing out memory layout and configuring the video chip to use character images from RAM, I got to work.

1. Initial screen layout including editor and commands.

2. Navigation of character selection, displaying bit patterns for editing to screen, and displaying hex character value and byte values.

3. Editing the pixels in a single character.

4. Saving font to floppy disk.

5. Continuing to iterate with new features and enhancements

Description of key operations

pressing a key on the keyboard as shown below will perform an operation:

@ - toggle between RAM/ROM character sets

SPACE - toggle pixel on/off

B - navigate back one character

C - copy

F - flip upside down

M - mirror the image left to right, right to left

N - navigate forward to next character

R - rotate 90 degress to the right

S - save to FONT.BIN (WARNING: overwrites any previous saves)

V - paste

X - cut

Y - redo

Z - undo

- minus - navigate 16 characters back

+ plus - navigate 16 characters forward

< > - shift pixels left/right

↑ - shift pixels up (^ carrat on PC)

Shift V - shift pixels down

CLR - erase all pixels

CURSOR keys - move cursor left/right/up/down

HOME - move cursor to upper left position

RVS - inverse the pixels

STOP - exit (usually mapped to ESC on PC)

There are up to 24 levels of undo [Z] (25 levels of redo [Y]) when editing a character.  Navigating will clear the undos/redos.   And there is a virtual clipboard which you can copy[C]/cut[X]/paste[V] a single character.   Note in this program you do not use the Ctrl key for clipboard as you do on a PC.

Notes:

• When launching the program for the first time, the ROM font will be copied to RAM, including moving the start of programs up to $1800 past the RAM characters.   Subsequent runs from that address will not recopy from ROM.  If you want to restart fresh from ROM, either reset your computer and run again, or POKE 44,16:SYS 6157.  You don't have to memorize the entry point, you can also LIST the line of BASIC that calls into the entry point.
• Saving overwrites FONT.BIN.  So if you want to save your work permanently, it is recommended to rename your file to something else.
  OPEN 15,8,15,"R0:COOL=FONT.BIN":CLOSE 15
• To LOAD your font for editing, be sure to run the program at least once, then load before running to enter back into edit mode.  Be sure to include the ,1 otherwise you will wipe the font editor out of memory, then best to restart your Commodore and try again.
  LOAD "COOL",8,1
• Pressing COMMODORE+SHIFT while in programmable characters will shift to a second set of characters which we don't have room for in RAM, so you will see bitmapped images of the program and video memory.   Press the key combination again to return to the first set of characters. [Disabled in the C64 port]

Update 2024 April 20: also ported to Commodore 64

Update 2024 April 26: more documentation

Description of key operations since added to Commodore 64 version

H - hide UI except pixels and character for a minimalist experience

/ - swap between two RAM character sets (C64 version edits total of 512 characters) 

F1 - foreground color

F3 - background color

F5 - border color

 As the C64 has a different memory layout, video memory is at a lower address $0400 and more memory available, the memory map is a bit different.  The start of the program is still at $1800, but the programmable characters are now from $0800 to $17FF, a full 4K (512 characters). 

Note that only the first character set (256 characters) is visible at this address without moving the character set to another location (planned for future).  But the editor can handle this by swapping the character sets in RAM for editing, swapping them back and forth, so one set is always edited from the lower $0800-$0FFF range that is visible.  Just be sure to swap back to the first set before saving, otherwise the character sets will be out of order.

To use both character sets in your own programs, it is necessary to manually relocate them or load them at another address, unless you use the swapping technique used by the editor.

It is not presently possible to use raster interrupts to show both sets because the second set is at an address that is mapped to ROM characters instead.  Another reason it is planned to move these in the future, for example to $3000-$3FFF but in the middle of BASIC RAM it may not be useful to others.

Probably a better solution is to move both VIC-II memory to another bank of 16K, which also requires moving video memory.   Say bank 3 with characters to $9000-$9FFF, and video ram below it at $8C00-$8FFF.  Then move the start of BASIC to $0400, resulting in 34815 bytes available for BASIC, a reduction of 4K the size of the programmable characters.   This is only if you need both sets, otherwise use just a single set at $0800-$0FFF.

Leaving the editor, you have lost 4K of RAM from BASIC.  To reclaim 2K for the not visible second character set, POKE 44, 20: NEW but don't load any of your double character sets or you will wipe out the first 2K of your BASIC program.   Best to leave 4K lost at start of BASIC in that case, or resize your character sets to a single set.

We're in the weeds here.   Back to the fun -- please enjoy the programmable character sets and the graphical opportunities they provide!

Calculator for Commodore 64 and other CBM BASIC models

 

Introduction

Wow! A new desktop calculator for Commodore.  Programmed all by myself in BASIC.  Wow, so impressed!   Or not.  Doesn't even have decimals.

No, it's not the best thing since sliced bread, but it was fun.  And it's just a start -- there's a bigger goal I'll get to in a while...

This was a puzzle programming exercise I challenged myself with.  How to make the calculator, especially with the operator precedence feature.

Link: LOAD"CALC64",8

Implementation

Let's go through how it was implemented.

User Interface

First was the design of the user interface, by creating PRINT statements.  Used reverse text to make a rectangular box with the keys displayed.

How to click on a key?  I'm so used to a mouse or touch interface.  Oops, Commodore doesn't have that usually, or not so easy.  Ignoring the 1351 mouse for now.   Most Commodore users are used to using the keyboard or joystick.  Forget the joystick, this is not a game!  Keyboard entry one key at a time will do just fine.  Note that ENTER also acts as =, and DEL is equivalent to ←, and X is a synonym for *.

Entry of digits was the first processing, accepting up to the limit of the display.  This stored as a string (V$) with keyed entries appended.

I started with 7 digits, but outgrew that in testing and increased to 9 digits.

At first, only positive numbers were supported, then fixed it to support negative numbers, with the negative sign taking up a position in the display.   The N key toggles a number entry between positive and negative and back again.

Entries allowed by this calculator are interleaved numbers and binary (two argument) operators.  Note that immediate operators like C and N usually take effect immediately, whereas binary operators require multiple arguments and a finalization (another binary operator or =).

There are exceptions allowed in entries to overwrite the prior value or the prior operator.   Examples:

• 1+1=3 keyed entries will replace the 2 with a 3
• 2+x3 will replace the addition operator with multiplication operator

Precedence needs a Stack

One design requirement I set for myself was to include operator precedence.  This means that multiplication and division have the same higher precedence over addition and subtraction at the same lower precedence.  Usually math is evaluated left to right, but due to precedence issues, other operators may need to be done first.  In other words the expression 1+2x3 is equivalent to 1 + (2x3) and then 1 + 6 and finally evaluates to 7.   But 1 x 2 + 3 is equivalent to (1x2) + 3, then 2 + 3, and finally 5.

I simply put numbers and operators interchangeably on a stack in order of entry until enough information is present to start evaluating.

Rule 1 - if user presses =, then evaluate

Rule 2 - if first operator is multiplication or division, once the second number is finalized with a second operator, simply evaluate the first expression

Rule 3 - if first operator is addition or subtraction, defer until the second operator and third number is finalized (third operator present!), then figure out what to do - either evaluate first or second expression, reducing the work

The stack is implemented as a count C, and an array of strings S$, which is expected to only grow up to 6 items (0..5), example C=6, S$[0]="1" [1]="+" [2]="2" [3]="*" [4]="3" [5]="+"

This example 1+2*3+ is reduced to 1+6+ and then to 7+, with the display updated to show the 7, but then wiped to disallow appending to it.

And no, I'm not doing RPN.  I didn't grow up with an HP calculator, nor am I implementing one today.  I grew up with Texas Instruments, and that's how my brain works.   Keeping it in entry order keeps it orderly for me.  Sure, there are other was to approach it.   This is BASIC, not Lisp.  And this is MY calculator, so I'm doing it MY way.  Others can follow their own paths.

Expression evaluation includes handling the equals = operation.  In the context of this calculator, that finalizes a calculation, meaning the user wants the result now.

Subroutines

There are several subroutines: 1) Evaluate and reduce stack, 2) Update display, 3) Display stack, 4) Evaluate simple expression involving two numbers and an operator.

That last subroutine is a diagnostic useful most for development, but also shows work in progress compared to a regular simple desk calculator that usually won't show pending work.

Error conditions

Overflow is when the number to be displayed doesn't fit in the 9 digit display, when the string representation of the number is long than 9 characters and/or larger than the maximum whole integer value that can be displayed in that space.   Note that the number is still internally represented and can still be acted on.  If a resulting answer can be displayed it will be (example: divide a ten digit positive number by 10).

Error indicates that division by zero was attempted.

Limitations

Only integers are supported.  No decimal numbers.  No currency.   Workaround required to calculate a percentage -- multiply by one hundred first, then divide by whole percentage.  And division results in a whole number so 1/3= results 0, and 5/2= evaluates to 2.

Non-negative numbers are limited 0 to 999999999 (nine digits).  Negative numbers are limited -1 to -99999999 (note only 8 digits).

Scientific notation is not supported.

No paper tape, no printout, no record of operations.

Limited user feedback.  No keypress indicators.

Stack diagnostic is a little technical, especially with a count, then colon, and the entries.  (Could eliminate the count and colon, and/or show previous and pending operators before and after the display.)

Keyboard entry.

Extras

The program was saved with a starting address $400, to support PET, so you must not load with secondary address 1 on a C64!  And while the program assumes a screen bigger than a VIC-20, a few minor changes to the margin and startup text can remedy that.

Next

What does the future hold?  Who can predict with any accuracy?  I can say anything here, but doesn't mean I'll follow through.  I originally was contemplating near limitless number of digits (considering the 8-bit platform, probably some 16-bit limitation).   Maybe binary and hex?   Maybe a scientific calculator?   Fixed decimal?   Near limitless decimals?   Port to assembly for fun!   We'll see...

Have fun calculating!