Sunday, April 25, 2021

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)).  Sorry, there is no port to Commodore 128 80 column screen as that would require additional handling for pushing values to the non-memory mapped VDC chip, and porting to the TED (C16, Plus/4) series systems is also left as an exercise for the reader.

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

Monday, February 22, 2021

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).

Sunday, January 17, 2021

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.


  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 

Thursday, August 6, 2020

Commodore 64 BASIC CRUNCH Routine Commented

The disassembled code here is from
Commodore 64 ROM.

The comments and intermediate labels
are mine.

Together they are useful.

Placing this here as is for reference.
I found this exercise necessary when
implementing my hires extensions for C64
including a patch of this routine.

        ; C64 crunch is A57C-A612
        ; C64 tokens are A09E-A19D
crunch ; from C64 ROM
       ; INPUT: PETASCII of entered line is at buffer $0200, ending with #$00 null character
       ; OUTPUT: tokenizes in place entire line, ending line with #$00 null character
       ; HINT: because of tokens, result is smaller than original so can modify in place
         LDX $7A        ; source buffer index
         LDY #$04       ; storage index starts at 4 (4+$1FB+1 = $200)
         STY $0F        ; set not DATA flag (4=NOT, 0=DATA)
.go      LDA $0200,X    ; retrieve next character from input buffer
         BPL .lowch     ; branch if 00-7F
         CMP #$FF       ; PI?
         BEQ .store     ; branch if PI, already tokenized
         INX            ; advance source index
         BNE .go        ; always skip initial character 80-FE, as X shouldn't ever wrap to 0
.lowch   CMP #$20       ; compare to ASCII space
         BEQ .store     ; branch if space, store literal
         STA $08        ; no, store character, non-zero = not REMark
         CMP #$22       ; compare to ASCII quote
         BEQ .literal   ; branch if string, store literal characters instead of matchng tokens
         BIT $0F        ; test if in DATA statement
         BVS .store     ; branch if in DATA statement, store literal characters instead of matching tokens
         CMP #$3F       ; compare to ASCII question mark
         BNE .chkzero   ; no, skip next part
         LDA #$99       ; replace question mark with token PRINT
         BNE .store     ; unconditional branch, store token
.chkzero CMP #$30       ; compare to ASCII zero digit
         BCC .scantbl   ; branch if less
         CMP #$3C       ; compare to ASCII less than
         BCC .store     ; branch if less, so branch if numeric or colon or semi-colon, store literal character
.scantbl STY $71        ; save storage offset index
         LDY #$00       ; initialize token table byte index to zero
         STY $0B        ; initialize token number to zero
         DEY            ; cancel out the next increment for loop beginning with decrement
         STX $7A        ; save source index
         DEX            ; cancel out the next increment for loop beginning with decrement
.advance INY            ; advance token table index
         INX            ; advance source index
.scanch  LDA $0200,X    ; retrieve character from buffer
         SEC            ; prepare for subtraction
         SBC $A09E,Y    ; compare to Commodore token table
         BEQ .advance   ; branch if character match, look for more matches
         CMP #$80       ; end of token?
         BNE .scannxt   ; branch if not end of token, mismatch, so get ready to check next token
         ORA $0B        ; match! combine zero based token number with $80 high bit set for storage
.storaty LDY $71        ; retrive storage offset index
.store   INX            ; advance input index
         INY            ; advance output index
         STA $01FB,Y    ; store token or character
         LDA $01FB,Y    ; set Z flag if end of line
         BEQ .endline   ; branch if end of line, finish up
         SEC            ; prepare for subtraction
         SBC #$3A       ; subtract ASCII colon
         BEQ .setf      ; branch if colon
         CMP #$49       ; DATA?
         BNE .skipset   ; skip setting flag if not DATA
.setf    STA $0F        ; $49 if DATA, or $00 if colon
.skipset SEC            ; prepare for subtraction
         SBC #$55       ; REM?
         BNE .go        ; branch if not REM to get next character
         STA $08        ; store flag zero = REM
.litloop LDA $0200,X    ; retrieve next character from input
         BEQ .store     ; branch if end of line
         CMP $08        ; compare to token that got us in this loop (e.g. 0x22 quote), or 0x00 (REM)
         BEQ .store     ; branch if REMark end of line
.literal INY            ; advance destination index
         STA $01FB,Y    ; store in buffer
         INX            ; advance source index
         BNE .litloop   ; repeat getting next character
.scannxt LDX $7A        ; retrieve source index
         INC $0B        ; advance token number
.endtok  INY            ; advance destination index
         LDA $A09D,Y    ; retrieve character from token table
         BPL .endtok    ; loop until find end of token
         LDA $A09E,Y    ; retrieve next character from token table
         BNE .scanch    ; branch if not end of token table
         LDA $0200,X    ; re-retrieve character from input buffer
         BPL .storaty   ; branch if character 00-7F, should be if got here, no token match
.endline STA $01FD,Y    ; store end of line nul character $00
         DEC $7B        ; update TXTPTR
         LDA #$FF       ;  to point to
         STA $7A        ;  $01FF
         RTS            ; done

Monday, July 13, 2020

Commodore 64 running in web browser

Open full size window:

  • Coded in TypeScript(/JavaScript) with some HTML of course
  • Portable (got a web browser right?)
  • Keyboard driver works best with Firefox
  • Works on Mobile and TV too (click on screen for configuration, help)
  • F9 to toggle Help
  • Recommend use wired or bluetooth keyboard instead of onscreen keyboard
  • This is based on my earlier efforts (see previous posts)
I coded this as a learning experience with TypeScript.  Go ahead and try it out!

Included features:
6502 Emulation, machine code
 Commodore 64 Text Screen
 Commodore Fonts: Uppercase/Graphics, Lowercase/Uppercase
 Commodore Colors: Foreground, Background, Border
 Commodore BASIC v2 (Microsoft)
 64K RAM
 20K ROM
 Attach D64 image
 Load directory from D64
 Restart with PRG image
 JavaScript speedloader to bypass slow C64 disk access
 Save/Download PRG
 Great wired/wireless keyboard support
 Keyboard scan code support - press/release, multiple keys support, separate left/right Shift
 Standard to Commodore keyboard symbolic mapping, add/remove Shift
 Special key mappings: Stop, Home, Restore, F1-F8, Ctrl, Commodore
 Mobile/TV browser keyboard support (but minimal)
 Clipboard paste support
 IRQ 60 times per second
 NMI on Restore key
 Works best with Firefox

Missing features or limitations:
6502 undocumented instructions
 Accurate, regulated instruction timing
 6502 emulation battery drain (one thread always running 100%, no idle sleep)
 VIC-II register support
 Device register support
 Programmable timers
 Serial Port - User Port
 High Resolution 320x200 and 160x200 graphics
 Multi-color text mode
 Programmable characters
 Joysticks, Paddles
 Cassette Tape
 Save to D64
 SEQ, RND, etc. files
 LOAD PRG from running program
 Positional keyboard mapping
 On-screen keyboard
 Clipboard copy
 A few graphic character key strokes (punctuation keys) may not be mapped yet
 Known issues with Google Chrome

Sunday, April 12, 2020

Commodore 64 for STM32F429 Discovery board

So here is a Commodore 64 emulator I built for STM32F429 Discovery board:

Yeah, the LCD is tiny at 2.4", and the emulation runs about 15% slower than an NTSC C64.  But it's running on a small embedded board that's available for under $30 US (DigiKey, Mouser, ...) including mounted LCD display and USB OTG jack.  Just add keyboard, OTG USB adapter, and power supply.

This is a port of my portable C64/6502 emulator for terminal console, which was a port of my Commodore/6502 emulator for Windows Console.   But this time, I dropped the console part, and went for real video (LCD) and USB keyboard support.   Hello PETSCII!

Keyboard mapping (showing my Dell keyboard):
   STOP(ESC) F1 F2 F3 F4 F5 F6 F7 F8            Restore(PrtScr/SysRq) Run/Stop(Pause/Break)
             1! 2@ 3# 4$ 5% 6^ 7& 8* 9( 0) -_ += Del/Ins(Back)    Ins Hme/Clr     / * -
   Ctrl(Tab) Q  W  E  R  T  Y  U  I  O  P  [  ]  £ (\)            Del           7 8 9 +
             A  S  D  F  G  H  J  K  L  ;: '" Return(ENTER)                     4 5 6
   LShift    Z  X  C  V  B  N  M  ,< .> /?  RShift                     Up       1 2 3
   C=(Ctrl)           SPACEBAR              C=(Ctrl)              Lft Down Rt   0 .   Enter

  • 320x200 text screen on graphics LCD, with top/bottom border.
  • USB Keyboard (e.g. PC-103) support (symbolic, not positional)
    • Tab maps to C64 Ctrl key
    • Ctlr maps to C64 Commodore key
    • Esc key maps to C64 RUN/STOP key
    • PrtScr/SysRq maps to C64 RESTORE key (supports STOP+RESTORE)
    • PgUp also maps to C64 RESTORE key
  • Full 6502 emulation.  Go ahead, run some machine language on it.
  • Commodore character set
  • Text video at $0400 (address 1024)
  • Text color at $D800 (address 55296)
  • Keyboard scan by writing to $DC00, reading from $DC01
  • Full 64K RAM.  Update 2020-04-14: RAM/ROM/IO/Charset banking is implemented!  And 1K color nybbles
  • 1/60 second IRQ.  So we've got the software clock: TI, TI$
  • Upper/lower case switch ($D018), and reverse characters.
  • Border color ($D020) and background color ($D021).
  • Approximately 85% cpu speed of a real C64
  • No NMI.  No Restore key.  Update 2020-04-15: implemented, see keyboard above.
  • No other device support.  No tape, no disk, no serial, no cartridges, no joysticks, no printer.
  • VIC-II support is limited to getting system booted.
    • No full register support.
    • Text address can't be moved.
    • No graphics support.
    • No programmable characters.
    • No raster interrupts.
    • No sprites.
    • No left/right side border displayed.  Ran out of pixels.
  • No CIA1/CIA2 (except for keyboard data ports, but no data direction registers)
  • No SID.
  • In progress.  There are bugs lurking (for example, the IRQ and USB keyboard stops working exactly at 35 minutes, 38 seconds from start, maybe a resource leak in third party libraries, so we'll call that time limited I guess)
  • Keyboard support may need tweaks for more complete PETSCII key support
  • No CAPS LOCK or SHIFT LOCK supported
  • Doesn't utilize full capabilities of the STM32F429 MCU and discovery board components including 2.0MB of Flash (uses 110KB), 256KB of RAM (uses 83KB), 8MB SDRAM, motion sensor, user leds, user button, or other expansion capabilities.  Opportunity awaits!

Monday, March 30, 2020

6502 emulator for terminal, Commodore Edition

(Update: Commodore 64, VIC-20, PET, Commodore 16, Plus/4 aka TED series)

This is a simple 6502 emulator.  And a very simple Commodore emulator.  If you like console windows and command lines, this may be your emulator, especially if you like both 6502 and BASIC.  And if you prefer C#, check out the emulator sources (link at end).


How simple is it?  It is so simple!  It turns out you can craft a 6502 emulator, hook just the character in/out routines, do a little memory management, feed it Commodore ROMs, and you've got a retro computer in a terminal (Windows Console in this case).  If you implement the 6502 accurate enough, it just works.

Commodore 64 and VIC-20 ROMs don't really care if there is any real hardware I/O available or not.  All memory is zeroed to begin with, and I've treated the I/O areas as RAM so the I/O values can be retrieved.  And it seems to work for booting the system.

The only two kernel JMP table entries patches are CHRIN ($FFCF) and CHROUT ($FFD2).  By intercepting CHRIN completely, the screen editor is bypassed, but by allowing the CHROUT to continue, screen memory is updated simultaneously to the Windows console.  Note that this emulation has lazily not implemented hooks to writes to screen memory, though you are free to implement this as you desire adding code to the SetMemory() method within the C64Emu, Vic20Emu, or other appropriate class.

The goal was to access the BASIC command line.  And using the Windows Console ReadLine(), we now get those history and editing features instead:  Home, End, Del, Backspace, Cursor Up/Down/Left/Right, etc.

If you're itching for some simple BASIC command line, including entering programs line by line, you are all set.  Until you want to SAVE, LOAD, VERIFY.  Sorry, not implemented (yet?  use the Windows clipboard for now).   Full LOAD/SAVE implementation exercise left to the reader.  ;-)   Yet, since it is a faithful 6502 emulator, if you can get your own machine code loaded, you can run that too.

Commodore PET 2001 series, Commodore 16 and Plus/4 (TED) emulators are available too, required some additional changes including RAM banking for the TED series.

I suspect additional emulation will be necessary for the Commodore 128, like the MMU, and the 8502 memory mapping, and hopefully can do without a Z80.

Want to work with another system like an Atari 400/800 series, Apple II, BBC Micro, Atari 2600 cartridge, or NES ROM?  I'm not going to stop you.  The 6502 emulation is here to use.  Though the video game systems probably won't work well in a console.  Not sure what the minimal emulation is required to get BASIC working on the others.


  • Only keyboard/console I/O.  No text pokes, no graphics.  Just stdio.  No asynchronous input (GET K$), but INPUT S$ works.  No special Commodore keys, e.g. function keys, cursor keys, color keys, STOP/RESTORE, etc.  (Could improve this.)
  • No keyboard color switching.  No border or border color.  Text and background colors are implemented, but disabled by default because mapping to the standard console colors results in some fairly horrible color combinations.
  • No screen editing (gasp!) Just short and sweet for running C64 BASIC in terminal/console window via 6502 chip emulation in software
  • No PETSCII graphic characters, only supports printables CHR$(32) to CHR$(126).  But does support CHR$(147) for clear screen.  Now also supports Home/Left/Right/Up/Down output characters (not input).
  • No memory management or banking.  Not full 64K RAM despite what the startup screen says.  C64 has just 44K RAM, 16K ROM, 1K VIC-II color RAM nybbles.   VIC-20 has just 5K RAM including screen memory (you can add more memory at the command line).
  • No timers.  No interrupts except BRK.  No NMI/RESTORE key.  No STOP key.
  • No loading or saving of files implemented (but Windows clipboard works!)
  • No cartridges.
  • No joysticks.
  • No sprites.
  • No graphics (you know this is a terminal/console window right?)
  • Yikes, that's a lot of no.  Seriously, it is a simple emulator.  Emphasis on simple.
  • Lightly tested.  Bugs are lurking! 

Trace Execution:

It is possible to trace some or all of execution by setting the Emu6502.trace to true, and it will produce debug output (see in your IDE, or capture with DebugView).  Note that this slows down the emulation significantly, but provides very good insight.   Registers and flags are shown to the left of the statement's disassembly, in their states prior to executing the statement.  Currently, referenced memory is not shown, that would be a good enhancement for the future.

Walk a ROM:

Another feature is the ability to walk a ROM method without actually executing anything.  It traverses all subroutines, and both cases of branches (not taking the branch first, then when exhausted, taking the branch).  Each statement is disassembled exactly once.  Note that JMP($00FE) or similar will probably disassemble as BRK, unless you specifically code loading memory (see C64Emu for an example).   Pushing values to the stack (say from a table) and using RTS is not supported, as the walk isn't executing anything or remembering variable assignment, so dynamically pulling values from specific entries in a table is not supported directly (but see C64Emu.Walk() that implements a workaround).

If you initialize enough low memory, and walk all the entry points including addresses from tables, then the disassembly should be a view to the complete code coverage possible (and some impossible branches and paths too).  Note it is recommended to pass the output to sort (shown below) so the code is organized in memory order.  You could effectively get a ROM disassembly (without data tables).  More work could be done to show the data tables and/or unreferenced code/bytes.

simple-emu-c64 c64 walk | sort | more
simple-emu-c64 c64 walk FF3D
simple-emu-c64 vic20 walk FFCF FFD2

Development Environment:

Developed in beautiful C# using Microsoft .NET Framework 4 in Microsoft Visual Studio 2017.  Should be portable to other languages without much difficulty (it really is a simple implementation).  And should be able to recompile on Mac or Linux with a minimum of changes if any.  Submit your pull requests if you do something cool that would be generally useful.  Or just fork your own version. 


So in the process of my retro binge session the last year or so, I did come across another BASIC for the console.  I remember at least reading it, maybe even trying it out.  But time passed.  And I was recently puzzled on how it actually worked.  Problem was, I couldn't find it, which caused me to be even more puzzled.  I googled and googled, but the keywords are so common, it is hard to sift through the results to find exactly the solution I was searching for.   So I pieced together memories and thoughts of how one would approach a solution.  I wrote down steps.
  1. Use C64 BASIC in existing VICE emulator to test tokenizing, and execution - validate entry points, memory usage, define API subset
  2. Emulate 6502 code on Windows
  3. Graphing techniques - capture code paths, variables used
  4. Convert 6502 machine code to C or other using graphing information
  5. Add optimization techniques
I used Compute!'s Mapping the Commodore 64 and VICE to find and test the code to tokenize a statement: $A579, code for adding/replacing a line of a program: $A49C, and to execute a statement: $A7E4.  And I made notes about more Commodore 64 memory map entries.

I also found an Internet archived copy of the 6502 (65XX) Microprocessor Instant Reference Card (that I probably have filed away somewhere in a box in my garage) and I was itching real bad to implement the emulator.  Now, I've implemented the 6502 emulator before, but if memory serves correctly, it was a long time ago, and the moment I was ready to test it, I kinda gave up on it.  I was ready to return to this challenge.  I needed to get over that hill.  I was determined.  I was obsessed.

And then I happened to search for the original solution on github.  Huh, yeah, I should have thought of that first.  Brain fart!  I found mist64/cbmbasic.   The statically recompiled BASIC console program and loader.  Works great!

But my obsession was in full gear, so I wrote the disassembler Thursday night, March 26, 2020, and wrote the emulator Friday all day, March 27, 2020.  I had a miscommunication with other members of my family -- they thought I was working.  But I was on PTO.   Guess I forgot to tell them.  I was present for the family -- working at the dining room table -- but my mind was full bore into my laptop getting this emulator going.  And sure enough, I was able to post a screen shot to Twitter after midnight, barely into Saturday, March 28, 2020, just over 28 hours start to finish, including some sleep.  I am so lucky to get a successful result after such a short time.

Did it actually work first time?  Definitely not.  I had to fix my implementation of the BIT statement, somehow some opcodes got deleted, had to fix some instruction modes, and continuously fixing the flag assignments.  The challenge was fun.

Put in a bit more polish, separate out the Commodore 64 code from the 6502, and I was able to post the source to Github Saturday night, March 28.

Sunday I was able to test the VIC-20 ROMs, and wow, those work too.  Posted additional changes to formally support those, and have command line arguments checked in Sunday, March 29.

Then checked in backspace support early Monday, March 30 before heading to my real world job of working at home (how convenient!).  Yeah Coronavirus going on and all that.  All the more reason to keep my head low and focus on something else.

Monday night March 30 I created this blog entry.  Okay, time to get more sleep.

Sleep, maybe some, but TED was bothering me.  Turns out it needed memory banking (damn you TED!) so there you go, revised the memory scheme from an array, to a C# class that each machine type can handle those accesses including banking support.  Watch out 128, I'm going to get you next.

Saturday April 4 I was able to fix some I/O issues, and check in TED (C16, Plus/4) and PET 2001 support.

What's next?  I'm toying with replicating the static recompilation, to C would work best for me.  Then I could test on various or select embedded hardware platforms I have in my possession (or did I say obsession?).  

And maybe even use one with an LCD, and modify the emulation to support the screen editor and hi-res graphics support, either hooked or emulated, and support file loading from SD.  

Then probably on to something else newly retro and exiting.  Have fun!

[Update: ported to C, and tested on ARM boards with MBED and Arduino.  Skipped the static recompilation, because easier not to, and keeps all the machine code 6502 compatibility.]


Inspired by mist64/cbmbasic and RetroShield 6502
Compute!'s Mapping the VIC
VICE - the Versatile Commodore Emulator

External Links:

Open Source! (C#, follow links for C version)