Extending C64 BASIC Part One - Parse String

This example parses a string appended to the SYS command on Commodore 64

Link: reverse.d64

GO 128 enhancement for Commodore

 

One wonderful feature of the Commodore 128 was its compatibility with the Commodore 64.  It was an evolution of the Commodore 64 and still supported all the software and hardware from before.  For me it was a no-brainer to buy.  80 columns, plus new features, plus CP/M.   Adding a mouse, GEOS 128, REU 512K, and 3.5" floppy, and I thought it was the best place to be this side of heaven.

There were multiple ways to go into Commodore 64 mode.

1. Start with a Commodore 64 cartridge
2. Boot/reset with the Commodore key held
3. Commodore 128 boot disk that switched to Commodore 64 mode
4. Switch MMU to Commodore 64 mode
5. GO 64 command

But the only way to get back into Commodore 128 BASIC 7.0 was to reset the system.

Fast forward a few decades or so, and now we can add GO commands to the other BASIC systems to switch between them.  Links: cross-platform source, Windows binary release.

How does it work?  This is emulation.  Sorry purists.   The Commodore 128 MMU was built so there is no going back out of C64 mode.  This was by design to keep 64 mode on the 128 very close to 100% compatibility.  But emulation?  Anything goes.  The GO command is hooked, the argument is checked for a number, and if the number is right, it goes to that Commodore model by restarting the emulation for that system.  And thus, when running the BASIC for one system, can quickly switch to another other system (or even reset the system) using the GO command.  It even prompts for amount of RAM to allocate (except 128 is fixed at 128).

PET 2001 2K to 64K supported 

Vic-20 5K to 39K supported in hardware supported increments, not all available to BASIC

64 RAM 3K to 64K supported not all available to BASIC

Commodore 16 and Plus/4 support 16K, 32K, or 64K

Commodore 128 fixed at 128K (KERNAL does not do RAM test) 

Limitations?  Oh, sorry.  This emulator is text only.  No full screen editor.  Doh!   No screen pokes either (well not displayed).  Nor PETSCII and commodore graphics characters.  But does support console history editor on Windows.   Linux and MAC builds (you can build from my open source project) provide only simple line editing capability.   Does provide accurate 6502/6510/8502 emulation, RAM banking, etc. according to the platform.   So pop into the MONITOR on C128 or C16, Plus/4, or SUPERMON on other platforms to write and edit machine code.   And because using console window, the text display size is not as limited, 88 columns for Vic-20 and 160 columns for C128.

Save and Load from .PRG is supported as well (except PET at this time, some other limitations).  Disk device is ignored, so defaults to local file system.  Even use absolute and relative paths.

So for simple programs, and just playing around in BASIC, it's not too bad.   Text background and foreground color for Vic-20 is enabled because that color palate is more compatible with the Windows console default colors.  Reverse text should work on all systems.  Home, clear, cursor positioning may work in programs only, not for editing.

Now prompts for RAM size going to 64

Going to Vic-20 from 64

Going to PET 2001 from Vic-20

Going to Plus/4 from Vic-20

Going to Commodore 16 from Plus/4

Going to 128 from Commodore 16

Resizable text console - 132x50 text screen on Commodore 128

Bil Herd, Ted/C128 hardware design project lead (left) and Dave Van Wagner, geek (right)

Links: 

• cross-platform source 
• Windows binary release

C128 model support added to simple 6502 Commodore emulator

The Commodore 128 is a favorite system of mine.  I've owned a DCR model (cost reduced with embedded disk drive, the metal case) since around 1987.  And it still works fine!

But this article is about emulation.  I already wrote a C#/.NET based emulator that supports PET/Vic-20/64/16/Plus/4, and just recently have added 128 support.   I thought it would be difficult with the C128 custom MMU and VDC.  There was a learning curve.  And I faked enough of it to boot and work (even with no Z80).

This simple emulator is a text based emulator run from a console window.  It provides only text input and output, in addition to LOAD/SAVE support to the local disk as .PRG files (just a common extension for Commodore program files, unformatted binary data). 

Feed the emulator some Commodore ROMs (not included, recommend grab these from Vice) and it can map ROM/RAM into the 6502 memory space and execute 6502 instructions. There are some common KERNAL entry points for character in, character out, check for stop, and load/verify/save operations.   These calls are hooked to redirect console input/output to the emulated 6502.  Effectively the Commodore computers are running in software.

These emulated systems don't do the fancy video games.  There is a long list of things they don't do, including no PETSCII graphics either.  No graphics.  No sound.  No timers.  No color.  They don't even do full screen editing.  They are stuck using the console editing features.  Not great, but it works -- cursor up to recall a previous command in the current screen line editor.  And the Windows console editor even survives restarting the program or restarting the Commodore.  Please note it is best to use Caps Lock as the Commodore expects uppercase commands most of the time.

What this does function as is a good text BASIC interpreter, and 6502 machine language environment.   Some of the Commodore systems such as the C128 and Plus/4 include their own machine language monitor (MONITOR command).  On the PET, Vic-20, and C64, you can load the appropriate SUPERMON for that system.

Since we're using a Windows console in this case (or Linux or MAC... .NET supports them too!), it can be sized to screens larger than 40x25 as well.  Imagine the capability of full screen text written in BASIC!   Or a long disassembly listing in the monitor.  Wow!

Here's how to get started.

1. Grab the sources from github

2. Grab the roms from vice, (a much larger more complete and more accurate emulator, but why would you want that much fun?).   Put these in a c128 directory from which you will run the simple emulator.  While you're at it, create subdirectories and copy roms for the other systems too.

c128: kernal, basiclo, basichi, chargen

c64: kernal, basic, chargen

vic20: kernal, basic, chargen

ted: kernal, basic

pet: basic1, edit1g, kernal1

3. Compile using Visual Studio or dotnet.

4. Run with the command line argument: c128

Why do this?  To me this was a challenge to first emulate the 6502, and a challenge to minimally support Commodore BASIC.  I thought what is the least amount of support that is needed to have a useful Commodore computer?  I knew about the Kernal jump table definition by Commodore.  I had seen others do it successfully.  And I wanted to do it my way.   It was just a mountain to climb, and since I love 6502 and Commodore computers, it is an enjoyable part of my hobby.

What's next?  Probably more blogs and videos documenting and demonstrating this stuff.  My goal is to help others learn and in this case specifically enjoy Commodore systems.   The source code is open so you're free to inspect and modify it (giving credit where credit is due of course).

Links: 

• cross-platform source 
• Windows binary release

Trace C64 I/O Kernal Jump Table Calls

See what your C64 programs are up to!   Debug, or help transition from BASIC to assembly language I/O programming.

c64-io_monitor is a program that allows monitoring or tracing input/output calls on the Commodore 64.  It can show counts or a trace log of what calls have occurred.   

The screenshots show the initial copyright screen, with usage hints, and status (includes trace log bytes available), followed by an example program, and the counts and trace log from running this program.

Basic usage includes loading io_monitor program from disk at absolute address $C000.   It is recommended to lower BASIC by poking to memory address 56 (e.g. POKE 56, 128).  Then NEW to both clear variables and reset BASIC program pointers.  And use SYS 49152 to initialize the trace/monitor.

    LOAD "io?monitor",8,1
    POKE 56,128
    NEW
    SYS 49152 : REM START MONITOR

The monitor copies BASIC/KERNAL ROMs to RAM, patches them to hook the I/O entry points in the Commodore 64 kernal jump table at the end of ROM within the $FF00-$FFFF range.  The hooks take care of counting calls, and logging trace information in available RAM.  While each call is made, the border color is incremented to show it is working.

At this point, you may make any I/O calls including keyboard input (plus RETURN), screen output, disk/tape I/O, etc.   The I/O calls will be counted/logged.

When you are finished with the monitoring session, it is recommended to press STOP+RESTORE to reset back to the KERNAL ROMs, then the counts and tracing is turned off.

Counts can be displayed with SYS 49155, and the trace log can be displayed with SYS 49158.

The trace log can be sent to a file with statements like the following:

    OPEN 1,8,3,"@0:TESTLOG,S,W"
    CMD 1
    SYS 49155: REM COUNTS
    SYS 49158: REM VIEW LOG
    PRINT#1
    CLOSE 1

Why did I create this?  I have been developing some simple (text only) 6502 Commodore emulators (one, two, three, four, five) for multiple targets (web, Windows console/terminal, Linux terminal, Mac terminal, Arduino UART, ESP32 UART, Teensy LCD, STM32F4 LCD, and more embedded targets) and am looking at supporting file I/O emulation (open, input, get, print, close, etc.) above and beyond my D64 emulation.  One step along the way is understanding Commodore I/O some more from the machine language level.  Seeing a trace log provides a closer in-action view of the kernal I/O routines.

Links

The D64 disk image contains the machine code for io_monitor (also available as PRG), and some sample programs that can be used to demonstrate the functionality, including viewlog which opens and displays a sequential file (e.g. testlog saved to disk like above).  The source code posted to github is open source (MIT Licensed meaning free to use/alter/distribute, giving credit where credit is due, with no warranties).

Hackaday linked to this article

Low Resolution Graphics for Commodore

Commodore systems come with a graphical character set that can be used for low resolution graphics.

PETSCII low resolution 80x50 example

All the Commodores include block patterned graphics that can be used to display 2x2 pattern blocks, to double both the horizontal and vertical text resolution, for example from 40x25 to 80x50.  Like 4K for the day!  

PETSCII block characters including inverted

In the back of our high school math classroom was an original PET 2001.   This system had a chicklet keyboard, built-in cassette drive, and 40 column white on black monochrome screen.  This system has no graphics modes beyond the PETSCII capabilities.

One of the exercises in my Algebra 2 class was to graph mathematically functions.  I successfully challenged myself back then to plot the graph on the PET using this block graphics method.

Using 8 PETSCII characters, and the inverse of those characters, all 16 combinations of the patterns can be achieved by setting (POKE) the correct value onto the screen (see the A array in the source).  Also achieved is reading (PEEK) the current PETSCII value, converting that into pixel data, and combining existing plotted pixels with a new pixel (see the B array in the source).

LORES PET 40COL listing

My handwritten PET listing from 1982

I found my handwritten program listing that dates back to 1982.  It's beautiful to see that graphics could be achieved with PETSCII with only a few lines of code.  From my positive experiences with the PET, I purchased a Commodore Vic-20, and the Super Expander later in 1983 and switched to high resolution graphics at that point.

A disk image (D64) of samples for PET/Vic-20/C64 is available.  Screen memory locations for PEEK/POKE are different for all the systems, and sizes are adjusted with variables for the 80 column PET, and 22 column Vic-20.  The Vic-20 and C64 also have color memory, so an additional POKE is included to match the current text foreground color (PEEK(646)).  

Update [5/13/2022] there are ports for both Commodore 128 40 column screen, Commodore 128 80 column screen (including SYS calls to read/write VDC 8563), and a port to the TED (C16, Plus/4) series systems showing a color gradient possible with those systems.

Disk Listing for different Commodore Models

Vic-20 low resolution 44x46 plot

Contrast with 320x200 high resolution from C64

PET 80 column screen 160x50 sample

[Change:] 80 P=COS(I)*SIN(I)*2

Commodore 16, Plus/4 screen 80x50 sample (TED)

C64 Emulator for Teensy 4.1 LCD/USB/SD(D64)

Here is my Teensy 4.1 on a breadboard pretending to be a Commodore 64.  USB keyboard, color text, background, border, and D64 (1541 image) support for LOAD/$/SAVE.  6502 emulation supports machine language, and Commodore 2.0 BASIC programs.   Sorry text only, no games, no graphics, no sound, no joysticks, just simple stuff for now.  But that simple stuff works! (mileage may vary, lightly tested, please try this at home under controlled conditions).

My Open source: https://github.com/davervw/c-simple-emu6502-cbm/tree/teensy_lcd

Also see link from Adafruit's blog!

How to Build Vice 3.5 (x64sc, etc.) on Raspberry Pi 400

Raspberry Pi 400

The Raspberry Pi 400 invokes a sense of nostalgia back to the all-in-one systems of the past, such as those commonly available in the 80's (about 40 years ago!) of having the keyboard and computer all in one, with connections at the back of the enclosure, and expansion at the back of the enclosure.

My favorite system released January 1982 was the Commodore 64.

So why not have both?  With emulation, let the Raspberry Pi 400 become a Commodore 64 as well.

Vice 3.5 built, running on Raspian

One way to do this, is using Vice (the Versatile Commodore emulator).  Of course you can use a prepackaged solution like Retropie and Emulation Station.  But since it is open source, you can also just download and build the source yourself.

As vice 3.5 was just released Christmas Eve, 2020, it makes a lot of sense to build yourself, so you can have the latest build relatively easily.  Just think of all those new features!!!

I've attempted this myself on my Raspberry Pi 400 (and expect should work on others fine too) with Raspian.  I've tested with both the latest 32-bit ARM, and beta 64-bit ARM builds.

Following are the steps I took to accomplish building the default configuration.  I followed the basic instructions, and when configuration or build failed due to a dependency, researched the dependencies necessary (thanks Google and all those who have built before me and posted their solutions).  

Grab yourself your favorite beverage, power up your Pi, and get building!   And once you're done, feel free to test my hires.d64 image.  Maybe even pick up some keyboard stickers.   And also can run Pet, Vic-20, Commodore 128, etc.

Summary

1. Install dependency packages
2. Download three archives from web: vice 3.5, SDL2, SDL2_image
3. extract the archives to their respective directories
4. configure, build, and install each iteratively in the order: SDL2, SDL2_image, vice 3.5

Full Steps (note versions may change, these were the ones available January 2021):

• sudo apt-get install flex bison xa65 libgtk2.0-dev texinfo libxxf86vm-dev dos2unix libpulse-dev libasound2-dev
• sudo apt-get install texlive-latex-base texlive-fonts-recommended texlive-fonts-extra texlive-latex-extra 

• http://libsdl.org/download-2.0.php Download SDL2-2.0.14.tar.gz - GPG signed
• cd ~
• tar xvfz ~/Downloads/SDL2-2.0.14.tar.gz
• cd SDL2-2.0.14 
• ./configure
• make
• sudo make install

• https://www.libsdl.org/projects/SDL_image/ Download SDL2_image-2.0.5.tar.gz
• cd ~
• tar xvfz ~/Downloads/SDL2_image-2.0.5.tar.gz
• cd SDL2_image-2.0.5 
• ./configure
• make
• sudo make install

• https://vice-emu.sourceforge.io/ Download tarball: vice-3.5.tar.gz
• cd ~
• tar xvfz ~/Downloads/vice-3.5.tar.gz
• cd vice-3.5
• ./configure
• make
• sudo make install