Save capability added to C64 version of VWAS6502 monitor

Save has been added to my 6502 monitor program for the C64 version.  The video above demonstrates creating a very simple 6502 program to output printable characters to the screen, and saving that program to disk.

Loading is not implemented, but you can easily use BASIC for that task as demonstrated.  Not explicitly shown is the X command to exit to BASIC.

The new save syntax is in the following form:

1000.2000 "FILENAME" 08 S

6502 Help References included in 6502 monitor

6502 mini-assembler help system

The help system recently added to the 6502 monitor (vwas6502) includes

• help commands
• monitor commands reference
• 6502 instruction set mnemonics
• 6502 addressing modes references, listing valid instructions
• opcodes with addressing modes available for a specific instruction mnemonic

In observation, that required a bit of ROM memory.  The monitor is currently at 4K with minimal features.  It is bursting at the seems without further space optimization, so will need to expand to 8K with the next feature additions.

Help commands

Monitor commands reference

6502 instruction set

6502 addressing modes

Help for a specific instruction

The references are possible, because the mini-assembler and disassembler is table driven.  There is a table of instructions in alphabetical order, an alphabetical index of the addressing modes, a table of addressing modes and an example for each in parsing (and number of bytes required) order, and tables of the opcodes: (ordered by) byte values, index to instruction name, and index to addressing mode.

By using the alphabetical indexes, the information can be displayed sorted when applicable.  This makes the information more easily accessible.

The 6502 specific references are generated by 6502 code on demand from the tables.  The commands reference and help about help are the only static help pages.  It would probably take a lot more storage if all the references were static, especially considering there are 56 separate instructions.

More information about this monitor is available in the previous article.

Mini-assembler with disassembler, display, edit, and run

 

Sample assembly entry and run example

Links

• Source at github
• D64 and PRG from github (Commodore 64)
• BIN for ROM (minimum system 6502 + MC6850 + RAM + ROM)

Everyone (in a small corner of the retro programming community) has their favorite machine language monitor.  Mine is HESMON for the Vic-20 which I got in the early 80s.  I probably also used TinyMon, and have used SuperMon in recent years.  The VICE monitor (ALT+H) is great, especially like the symbolic label support which I use to debug my programs assembled with ACME.  Also the Commodore monitors are great too, including Commodore 128 and Plus/4 (and family).

But recently I've been playing with WozMon, both in a a minimal emulated 6502 system, and compiled for Commodore.  But I didn't have a great disassembler and assembler to go with it.   I looked around a little (probably not enough).

My programming brain and fingers were itching to build my own.  So I set out to prototype the assembler portion in C#, the disassembler in 6502 using tables generated by the C# experience, and finally created a wozmon compatible monitor in 6502 with both disassembler and mini-assembler as we see here today.

Let's cover the syntax briefly.

Display memory is a single address (up to 4 hex characters) either by itself, or two addresses separated by a dot for a range of memory.  Below we are looking at the C64 jiffy clock by entering "A0.A2".   The result is the starting address followed by a colon and three bytes of memory from that range.

Modify memory is similar to the output of display memory, but you enter it.  (No I didn't implement the Woz's feature of showing the previous value of the first address.  Probably nice to add later.)   Either a single byte, or multiple bytes may be entered and stored into memory at the specified address.

Run program is a hex address followed by R.   Note that an RTS will usually return to BASIC.  And a BRK will perform the normal screen reset routine.   So best bet for now is to JMP $C000 to return to the monitor (if you wish).   Or if you want to reset the C64...

Those are the commands I stole from WozMon.   (To be clear, I didn't steal the code, just the syntax.  This is my code.)  To continue the excitement of working with WozMon.  With the interest of creating something bigger and better.  Oh joy, more generic machine language monitor commands.   Yes!  You guessed it!

Disassemble is similar to the run command, just change to a D

Assemble is where the exciting things start to happen.  Use A after an address to start writing your own programs in 6502 assembler.

And look what an exciting program this is!   Nearly(*) at the speed of light, it is outputting the first three numerals before restarting the monitor.   Wow!   I am speechless.   (*)I may be too excited about this.

There you have it!   An assembler, disassembler, memory display, editing, and running.   What else could you ask for?

Program loading and storing?

Oh excuse me, I must be going now.   Can't quite hear you.   Enjoying the spendor and excitement of new features.   Ah, while I bask in the glory of greatness.  Let me enjoy this, will you?

Later  dudes!

Update 2024-07-14 The project now also builds a ROM image for a bare-bones 6502 system with MC6850 UART.  The source code has conditional compilation for portions whether the system is first a Commodore 64 with full screen editing, secondly only using the get key routine terminal style (used as stepping stone to...), and lastly the minimum 6502+6850MC.  Also is an option whether to echo keystrokes back to the terminal.   The monitor with mini-assembler and disassembler is now available to more easily port to other 6502 systems!

6502+MC6850 emulated system debugging its own input line routine

Disassembler for use with WozMon

 

Disassembler disassembling WozMon

WozMon is a great little monitor program in 256 bytes which Steve Wozniak wrote for his Apple 1 release in 1976.  It was small but powerful allowing for memory inspection, entry of 6502 machine code programs and bytes, and launching of programs in ROM and RAM (jumping to address).

But being small, it is missing features that monitor users have learned to depend on, including a mini-assembler and disassembler.

So here I am today presenting a disassembler I wrote for 6502 which can be integrated with WozMon run command.  Once the disassembler gets control, the Y register contains a pointer to the last character read from the input buffer, and continues parsing for a hex address.  If not found, it simply returns to WozMon.  But if found, it will disassemble 20 statements starting at that address.  (Note: Vic-20 port above, changed to 17 statements due to the smaller screen size).

The syntax may be lengthier than other monitors, but it allows for an integration with the normally ROM based WozMon without modifications.  Plus you get what you pay for.   The disassembler is open source, so feel free to change it.

The disassembler came into being as part of developing a mini-assembler.  First I'd written a prototype in C# .NET. 

The assembler included tables of information for the 6502 instruction set and addressing modes that lent itself to be used as a disassembler (came second) which was prototyped as a 6502 program that disassembles itself.  Third came the disassembler compatible for use with WozMon.

Each prototype and program is one step along the way for the goal of creating a mini-assembler for my 6502 minimal system.  Not there yet, but getting closer with each step!

Also works with original WozMon in Apple 1 style environment

Also works on C64 and C128 systems

BANKTEST for C64

While adding banking support to my own C64 emulator back in the good 'ole days (April 14, 2020, maybe only good for hunkering down on retro stuff), I also wrote a test program to help verify the results.  This may help you visualize how you can access more RAM and ROM on the C64.

The program works by switching to the RAM only bank writing a signature high byte to four addresses, then cycles through the standard list of banks reading the value at those locations.  Of course the first line for bank zero shows the bytes as expected.  But the other banks tell a different story.

A000-BFFF is BASIC ROM.   Appears ROM is active in banks 3 & 7 only, otherwise is RAM.

C000-CFFF is always RAM.

D000-DFFF is usually I/O (banks 5-7) including color RAM at D8000 (notice the high nibble changes in this run).  May also appear as RAM (banks 0 & 4), CHAR ROM (banks 1-3).

E000-FFFF is BASIC ROM (banks 2, 3, 6, 7), otherwise RAM (banks 0, 1, 4, 5).

It is interesting to see the similarities and differences in this chart.

The key code to switching banks includes

        sei

        lda $01

        and #$f8

        ora #bank_selection

        sta $01

        rts

Only clear the interrupt flag (cli instruction) once you have returned to the normal bank (7) so IRQ vectors and the KERNAL/BASIC ROMs will work as expected.

I have also color encoded the banks in this chart to represent their effects:

Links

• Source: bank_test.asm
• Program: bank_test.prg

Running SWEET16, Steve Wozniak's "The Dream Machine" from WozMon

The story goes that Steve Wozniak was running out of space in Apple Integer BASIC, and out of necessity, determination, and will power, developed SWEET16 to do 16-bit operations in a more compact fashion.  There is already a great article on SWEET16, the interpretive processing 16-bit supplement to 6502 machine language programs, over at 6502.org.  The article tells the history, instructs how to port, and provides a tutorial on how to use it.  (And see article on Wikipedia, and Steve Wozniak's 1977 article in Byte magazine).

My article will follow the steps to produce a binary to run on my minimal 6502 with MC6850 UART, and run through a few examples to use it together with the Apple-1 Hex Monitor, ported from listings included in the Apple-1 Operation Manual (1976).  The Hex Monitor (or WozMon as people generally refer to it) is the original 256-byte ROM included with the Apple-1 computer.  It only needed to include display memory, edit memory, and run from memory operations to initiate control of that computer.

This article and efforts are inspired by videos produced by Ben Eater and his 6502 breadboard computer.  I wanted to do something similar, and followed instructions he provided to do something similar with my 6502 emulator, but simpler.   

I already had a 6502 emulator.  One version is in C++, is very cross-platform (Windows, Linux, Mac, Arduino, STM32, etc.).  But I had focused on Commodore emulation to match the computers I grew up with learning to program.  While that is working well, it is using Commodore ROMs and some I/O emulation. 

Also inspirational are similar videos produced by Michael Cartwright for his Hopper development environment and 6502 breadboard and PCB computer, inspired by Ben Eater's 6502 breadboard computer.  Michael (sillycowvalley on github) uses the MC6850 UART instead of the MC6821 PIA used in Apple-1, or MOS6522 VIA or MOS6551 UART used by Ben Eater.

I surely didn't want to bit bang serial, and wanted it as simple as possible.  Reviewing resources on the web, including datasheets, it was apparent the MC6850 has an advantage of being rather minimalistic.  It has one data register (read/write), one control register (write), and one status register (read).  While originally intended for use with 6800 series microprocessors, it can be used with others.  Only caveat is that the status is not designed for the 6502 BIT instruction.  But the advantage is that it doesn't have a status bug like the 6551 which intended to replace it.

So, I sat down and added a minimal emulation profile to my emulator including configurable RAM/ROM, and I/O address for the MC6850.  My initial implementation supports polling but not interrupts, which is fine for our purposes today.  It does not include a parallel I/O chip, so no hooking up virtual LEDs.  Wait, what?  Oh yeah, we don't need those (yet?), we exclusively have a terminal console.   But that also means we don't have a way to load or save programs.

Also imagine 60K RAM and 4K ROM here (oops!)

I ported WozMon to the 6502/MC6850 minimum profile so it will serve as our launching off point, similar to how it was utilized on the Apple-1.  Porting required changing the assembler syntax to match my 6502 assembler of choice (ACME), especially note that all the hex values in the file should include # for immediate mode (if extracting from Usenet article instead of Byte article), DFB must stand for define byte, and you do need to include some save/restore register routines.

An advantage of having a minimal system unlike Commodore, is that the 32 consecutive zero-page bytes necessary for SWEET16 are guaranteed to be available because it is a minimal system, addresses are not used by IRQ routines, keyboard handlers, timers, KERNAL I/O, etc.

Steps

1. Clone (or download Zip of) the emulator c-simple-6502-cbm.  Note it is not necessary to gather the Commodore ROMs this time around, because we don't need them.

2. Compile using Visual Studio, or make/gcc (Makefile included), or similar.

3. Look for wozmon.bin in the roms/minimal folder (its ported source is in child src folder).

4. Launch the minimal profile

    c-simple-6502-cbm.exe 1 roms/minimal/wozmon.bin

Now WozMon should be running.  You can review the Apple-1 Operation Manual (1976) for more detailed instructions on how to use WozMon.  But if you're quick, you can follow along with the required inputs here.

5. Paste SWEET16 binary into WozMon.   See copyright at start of article, included here for educational purposes, trusting this is fair use and for your own personal use.  Not for commercial use.

# SWEET16 compiled for EE80 start address

EE70: 20 EA EE 68 85 1E 68 85

EE78: 1F 20 7F EE 4C 79 EE E6

EE80: 1E D0 02 E6 1F A9 EF 48

EE88: A0 00 B1 1E 29 0F 0A AA

EE90: 4A 51 1E F0 0B 86 1D 4A

EE98: 4A 4A A8 B9 C8 EE 48 60

EEA0: E6 1E D0 02 E6 1F BD CB

EEA8: EE 48 A5 1D 4A 60 68 68

EEB0: 20 F6 EE 6C 1E 00 B1 1E

EEB8: 95 01 88 B1 1E 95 00 98

EEC0: 38 65 1E 85 1E 90 02 E6

EEC8: 1F 60 00 F7 02 9B 0B 9C

EED0: 23 AD 14 B0 45 B7 4F BE

EED8: 2D C7 59 D0 83 DB 6C 03

EEE0: 31 E6 6E 91 1C E5 63 E5

EEE8: E5 E5 85 20 86 21 84 22

EEF0: 08 68 85 23 D8 60 A5 23

EEF8: 48 A5 20 A6 21 A4 22 28

EF00: 60 10 B3 B5 00 85 00 B5

EF08: 01 85 01 60 A5 00 95 00

EF10: A5 01 95 01 60 A5 00 81

EF18: 00 A0 00 84 1D F6 00 D0

EF20: 02 F6 01 60 A1 00 85 00

EF28: A0 00 84 01 F0 ED A0 00

EF30: F0 06 20 64 EF A1 00 A8

EF38: 20 64 EF A1 00 85 00 84

EF40: 01 A0 00 84 1D 60 20 24

EF48: EF A1 00 85 01 4C 1D EF

EF50: 20 15 EF A5 01 81 00 4C

EF58: 1D EF 20 64 EF A5 00 81

EF60: 00 4C 41 EF B5 00 D0 02

EF68: D6 01 D6 00 60 A0 00 38

EF70: A5 00 F5 00 99 00 00 A5

EF78: 01 F5 01 99 01 00 98 69

EF80: 00 85 1D 60 A5 00 75 00

EF88: 85 00 A5 01 75 01 A0 00

EF90: F0 E9 A5 1E 20 17 EF A5

EF98: 1F 20 17 EF 18 B0 0E B1

EFA0: 1E 10 01 88 65 1E 85 1E

EFA8: 98 65 1F 85 1F 60 B0 EC

EFB0: 60 0A AA B5 01 10 E8 60

EFB8: 0A AA B5 01 30 E1 60 0A

EFC0: AA B5 00 15 01 F0 D8 60

EFC8: 0A AA B5 00 15 01 D0 CF

EFD0: 60 0A AA B5 00 35 01 49

EFD8: FF F0 C4 60 0A AA B5 00

EFE0: 35 01 49 FF D0 B9 60 A2

EFE8: 18 20 64 EF A1 00 85 1F

EFF0: 20 64 EF A1 00 85 1E 60

EFF8: 4C AE EE 00 00 00 00 00

Note: SWEET16 entry point for this port is $EE70, and the operations are in a single page $EF01-$EFFA.   A save registers routine is at $EEEA and restore registers is at $EEF6.   Zero page usage is $00-$1F for the SWEET16 registers, and $20-$23 for saving 8-bit registers.

6. Let's try it out.  Start by pasting the following to enter a program at 

1000: 20 00 FE A9 2A 20 70 EE 

1008: 11 12 34 12 56 78 21 A2

1010: 33 00 8D F8 FF 00

Which is equivalent to

20 00 FE JSR $FE00

A9 2A    LDA #$2A

20 70 EE JSR $EE70

11 12 34 SET R1,$3412

12 56 78 SET R2,$7856

21       LD  R1 

A2       ADD R2

33       ST  R3

00       RTN

8D F8 FF STA $FFF8

00       BRK

JSR $EE70 switches to SWEET16 interpretation, and these are SWEET16 instructions through RTN, before being back in 6502.  The vectors are set such that a BRK will return to WozMon. ($FE00 is my specific UART initialization routine for MC6850, and storing a byte to $FFF8 will send it across the UART).

All this program does is set the R1 and R2 16-bit registers to constant values, the LD instruction loads the 16-bit accumulator from R1, then ADD R2 adds R2 to the accumulator, and the result is stored in R3 by the ST instruction.   RTN returns to normal 6502 operation.

7. To run the program, enter the following into WozMon:

1000R

8. Display the results by entering

0.1FR

From the last two steps the output should look something like the following (blank lines added for separation)

1000R

1000: 20*\

0.1F

0000: 68 AC 12 34 56 78 68 AC

0008: 00 00 00 00 00 00 00 00

0010: 00 00 00 00 00 00 00 00

0018: 00 00 00 00 00 06 12 10

And the accumulator (R0) at addresses 0 and 1 now has the value $AC68 which appears to be the sum of the other two 16-bit values, with a copy also stored at R3 (addresses 6/7).  The asterisk is printed to demonstrate registers being saved/restored and 6502 operation returning to normal.

That's just a quick example.   Hopefully you've got a little taste of WozMon and SWEET16. 

Example run of SWEET16

But that's not all!  

I made a Commodore port of WozMon, so why not also port SWEET16 to Commodore and run it there too?

# Commodore port of SWEET16

1540: 85 22 86 23 84 24 08 68

1548: 85 25 d8 60 a5 25 48 a5

1550: 22 a6 23 a4 24 28 60 00

1558: 00 00 00 00 00 00 00 00

1560: 00 00 00 00 00 00 00 00

1568: 00 00 00 00 00 00 00 00

1570: 00 00 00 00 00 00 00 00

1578: 00 00 00 00 00 00 00 00

1580: 20 40 15 68 85 7e 68 85

1588: 7f 20 8f 15 4c 89 15 e6

1590: 7e d0 02 e6 7f a9 16 48

1598: a0 00 b1 7e 29 0f 0a aa

15a0: 4a 51 7e f0 0b 86 7d 4a

15a8: 4a 4a a8 b9 d8 15 48 60

15b0: e6 7e d0 02 e6 7f bd db

15b8: 15 48 a5 7d 4a 60 68 68

15c0: 20 4c 15 6c 7e 00 b1 7e

15c8: 95 61 88 b1 7e 95 60 98

15d0: 38 65 7e 85 7e 90 02 e6

15d8: 7f 60 00 f7 02 9b 0b 9c

15e0: 23 ad 14 b0 45 b7 4f be

15e8: 2d c7 59 d0 83 db 6c 03

15f0: 31 e6 6e 91 1c e5 63 e5

15f8: e5 e5 00 00 00 00 00 00

1600: 00 10 c3 b5 60 85 60 b5

1608: 61 85 61 60 a5 60 95 60

1610: a5 61 95 61 60 a5 60 81

1618: 60 a0 00 84 7d f6 60 d0

1620: 02 f6 61 60 a1 60 85 60

1628: a0 00 84 61 f0 ed a0 00

1630: f0 06 20 64 16 a1 60 a8

1638: 20 64 16 a1 60 85 60 84

1640: 61 a0 00 84 7d 60 20 24

1648: 16 a1 60 85 61 4c 1d 16

1650: 20 15 16 a5 61 81 60 4c

1658: 1d 16 20 64 16 a5 60 81

1660: 60 4c 41 16 b5 60 d0 02

1668: d6 61 d6 60 60 a0 00 38

1670: a5 60 f5 60 99 60 00 a5

1678: 61 f5 61 99 61 00 98 69

1680: 00 85 7d 60 a5 60 75 60

1688: 85 60 a5 61 75 61 a0 00

1690: f0 e9 a5 7e 20 17 16 a5

1698: 7f 20 17 16 18 b0 0e b1

16a0: 7e 10 01 88 65 7e 85 7e

16a8: 98 65 7f 85 7f 60 b0 ec

16b0: 60 0a aa b5 61 10 e8 60

16b8: 0a aa b5 61 30 e1 60 0a

16c0: aa b5 60 15 61 f0 d8 60

16c8: 0a aa b5 60 15 61 d0 cf

16d0: 60 0a aa b5 60 35 61 49

16d8: ff f0 c4 60 0a aa b5 60

16e0: 35 61 49 ff d0 b9 60 a2

16e8: 18 20 64 16 a1 60 85 7f

16f0: 20 64 16 a1 60 85 7e 60

16f8: 4c be 15

This SWEET16 entry point for Commodore changed to $1580 so the sample program has to change to call this entry point instead, to call $FFD2 for screen output instead of using the UART, and jump to WozMon entry at end instead of BRK.   Note that this Commodore port puts the SWEET16 registers at $60 (instead of $00) in zero page.   The Commodore port was trivial, disassembly will show there's nothing secret going on, mostly moving around stuff in zero page, and moving the save/load registers code.

1000: A9 2A 20 80 15 11 12 34

1008: 12 56 78 21 A2 33 00 20

1010: D2 FF 4C 00 14

 

Vic-20 running WozMon and SWEET16

C64 running WozMon and SWEET16

It appears there's a bug restoring the registers.  That is not an asterisk!!!   But an underscore.   Exercise left for another day...   Update: I had replaced the call to UART_INIT from the other system with starting SWEET16 followed by 6502 code.  Bad, so bad (see screenshot for bad code).  Have since updated the sample program to be correct.   Disassembling here to double check.   The asterisk is now showing up fine!  Would have been doing some crazy stuff interpreting 6502 opcodes as SWEET16.

A9 2A    LDA #$2A

20 80 15 JSR $1580

11 12 34 SET R1,$3412

12 56 78 SET R2,$7856

21       LD  R1 

A2       ADD R2

33       ST  R3

00       RTN

20 D2 FF JSR $FFD2

4C 00 14 JMP $1400

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

F2 - cursor color 

F3 - background color

F4 - character set 1 color

F5 - border color

F6 - character set 2 color

F7 - large pixel set color (editor)

F8 - large pixel cleared color (editor)

, - change titles color

. - change menus color

1,2,3,4,5,6,7,8,9,0 - select theme (colors and grid mode)

 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 be too challenging to 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 4 with characters at $F000-$FFFF, and video ram at $CC00-$CFFF.  Then move the start of BASIC to $0400, resulting in 39933 (39K) bytes available for BASIC, an increase of 1K the size of the video screen memory.

Leaving the editor, you have lost 4K of RAM from BASIC.  To reclaim 2K for the not visible second character set, POKE 44, 20: POKE 20*256, 0: 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!

Update 2024 April 27: raster interrupts implemented as described above, with two sets on screen, and working area using ROM font so doesn't change.  Second set is copied to $3800-$3FFF for display purposes, while the two sets remain at $0800-$17FF.

Update 2024 April 28: themes implemented (10) and grid mode added, new C64 keys updated above.  Themes allow quickly changing between color sets and grid options using the numeric keys.

Update 2024 May 1: wrote an article on moving video and programmable character memory.

Update 2024 May 4: have fixed many issues, and more enhancements, including moving programmable characters to $2000-$2FFF to make more usable, eliminate need to have separate edit/view copies.  But loses more BASIC RAM ($0800-$1FFF 6K now available for other uses) while reserving memory for characters.

Primary Color Theme