What is Cbmish?

 

Is this Commodore?

If it looks like a Commodore, acts like a Commodore, and feels like a Commodore, is it a Commodore?  Not always.  This cbmish is not a Commodore, and not made by Commodore Business Machines (CBM).  But it is like a Commodore, thus the "-ish" (means like).  

Cbmish is like a Commodore.  This web software solution provides the feel of a Commodore in a web browser.  There's a retro look and feel.  But with a more modern programming language.

READY.

But it says "READY."  Is that BASIC?  No, it is lying to you.  It is not ready for commands.  It won't PRINT or GOTO.  It is only ready for typing at this point.   You can navigate the screen with cursor keys and typing letters, numbers, punctuation, and other symbols.  You can change colors, type PETSCII, change to upper/lowercase, switch to reverse characters. It does feel like a Commodore.

Mouse

It also responds to mouse motion and clicks.  That's not a Commodore I ever owned.  Those rounded corners and text are buttons, and there are links too.  Clicking on a rounded button will present the user with a relevant sample screen, or navigate to another web page.  Colors may change, graphics may be drawn, text will display, and sprites may move.  

Why?

So why do this?  The about screen goes into some detail.  I'm ready to move on from BASIC (gasp!) and 6502 Assembly (gasp!) and I don't really want to program on my Commodore (gasp!), but I do want to continue the look and feel of Commodore.  My current efforts are web based and I have been using TypeScript from some years now.  My skill is mostly is C languages (C, C++, C#) and while I had shunned web development for sometime, my professional and hobby efforts have collided with doing full-stack development including C# and also TypeScript.

While interpreted languages aren't usually my thing (though I love me some AWK) I have seen features of JavaScirpt and functional programming influencing C#, and of course there are underpinnings of C in TypeScript too, and similar functional programming in JavaScript/TypeScript too.  While they are all quite distinct languages, there is enough familiarity between them, also also gotchas that keep them interesting when they are different.  It's fun to know multiple languages!

This is stuff you could do with your real Commodore, but it's done here using TypeScript written code.  TypeScript that is transpiled to JavaScript so it runs in the user's web browser.  A combination of HTML, CSS, and TypeScript results in code to provide the cbmish interfaces to present things like one of the favorite 80s retro systems.

You can code interactively using the browser developer tools, or you can launch Visual Code (or similar) with typescript compiler dependency to have code transpiled as soon as you save.  Instructions for both are on github in the README (see link below). 

10 PRINT "Hello ";: GOTO 10

So do you really want the equivalent of PRINT/GOTO? Well this will have to do, see immediate mode JavaScript entered into the console of the development tools of Google Chrome web browser.

PRINT/GOTO equivalent

Conclusion

So long story short, it's a fine time to do Commodore like programming on the web, in a modern language.  Take the best of modern languages and pair that with the look and feel of a great retro computer.   Are you keeping up with the Commodore?  Because cbmish is keeping up with the web.

Links

    open source (MIT License) at github.com

    live demo (try it now!)

Samples

mouse over button

Colors

petscii

chr$()s

Maze

Keyboard

lores

sine wave

dissolve

knight vs. dragon
sprite animation

about

HIRES for Vic-20 (BASIC 2.0 extension) is READY.

 

The BASIC commands are implemented, small font created, and demonstrations implemented.   Please enjoy this Space War and Omega Race inspired flying ship.

Source, disk image, and more details are on github for Commodore Vic-20 with memory expansion.

BASIC extension command syntax is:

COLOR [foreground[+8][,[background][,[border][,auxillary[,inverse]]]]]

COLOR [foreground[+8]] @ x1,y1 [TO x2,y2]

TEXT

HIRES xresolution, yresolution [,fillbyte]

DELAY jiffies

PLOT COLOR ON|OFF

PLOT [NOT|CLR] (@ x1,y1)|(TO x2,y2)...    **

PLOT 0|1|2|3 (@ x1,y1)|(TO x2,y2)...

PLOT "ABC" @ x,y [,addr [,width,height [,bytes]]]

RECT [NOT|CLR] [@] x1,y1 TO x2,y2

RECT 0|1|2|3 @ x1,y1 TO x2,y2

SHAPE GET|PUT|OR|XOR|AND|NOT|CLR addr @ x1, y1 TO x2, y2

** only first @ optional, when not multi-color

Vic-20 Hi-Res BASIC extension progress

 

Shape operations are functional, and work has begun on leveraging BASIC keyword extensions (borrowing from my own HIRES for C64).

4UPART program listing

While the SYS syntax is implemented, the BASIC keyword work has just begun.

Current vs. Proposed Syntaxes

Source and disk image are on github

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)