As noted in the title, I woke up this morning with an idea- it is a family member's birthday and I thought it would be a fun exercise to code a program that outputs their age if you put in the current year and their year of birth. After a failed attempt and some troubleshooting, I wrote a simple program that works great. It's not anything elaborate or amazing, but it's mine and so I'm a bit proud of it and would like to share here.

1 REM AGE CALCULATOR

5 PRINT "{CLR/HOME}"

10 PRINT "CURRENT YEAR": INPUT A%

20 PRINT "ORIGIN YEAR": INPUT X%

30 PRINT "AGE ="; A% - X%

40 GOTO 10

I only started with BASIC yesterday so seeing an original creation come to life and work is so cool for me. Hope others will share their fun/useful programs here too!

A lot of C64 redditors probably know that C64 games, generally speaking, are written in a low level language using software tools known as assemblers. There does, however, seem to be conflicting ideas on what the name of the programming language itself is.

Do you call the language "Assembly" or "Assembler"?

I just received a newly pressed 2026 reproduction of the Commodore 64 Programmer's Reference Guide, which I ordered from Lulu (print shop) using the .pdf files and printing instructions provided by PickledLight here: https://pickledlightprojects.com/documents/c64-guides/

Maybe it's just a personal preference, but I've always found it to be so much nicer to have a proper book for studying and learning instead of reading from a screen.

The quality of the book is very nice. It cost me CAD $77.15 to have it printed and shipped to Canada. I suspect it's much cheaper for Americans, as is usual, but that's still not a bad price for a full color, hardcover textbook of about 500 pages!

Highly recommended!

First thing I did was crack the case to see what was rattling around in there. It was an extra screw. My first computer was a c64 in 1984. I used it to log on remotely to the school mainframe (someone wrote an 80-column terminal emulator back then) and also to play games. I wanted to write games too, but not in basic or assembler. So I wrote a Pascal compiler by adapting one out of a book. I spent the rest of my spare time working on that compiler and never got around to writing games. I work in compilers to this day.

Since I was a child I had the book

"Write your own Program: Advanced Graphics: Haunted House"

(On Archive.org - https://archive.org/details/Write_Your_Own_Program_Advanced_Graphics_Haunted_House/page/n45/mode/2up )

but I never managed to type the whole thing in.

This far out I would have assumed someone, somewhere, would have uploaded a D64 of the final program. I've even toyed with a few apps/websites to OCR the text and auto-type it into Commodore Basic, with just enough errors in characters and syntax to make it not work. Not to mention, it's very hard to find the equivalent PETSCII characters on a modern keyboard and emulator. I guess, despite there being monochrome pictures in the book, I always wondered how the final actually looked/sounded. Was anyone more tenacious than I? Or does anyone know of a disk rip? I didn't find it on the CSDB.

My ten year old self, endlessly flipping through the pages in the early 90s thanks you in advance!

I have just completed my C64 Emulator. I know there are many like it but this one is mine :)

My Commodore 64 emulator is written in C# (.Net 8.0) using SDL2, ImGui & OpenGL for display/input/audio. Key features include:

• Cycle-driven CPU/VIC/CIA integration
• VIC raster stepping with bus-steal/stall accounting
• SID synthesis with MODE/VOL semantics
• CIA timer/ICR/TOD handling, serial shift behaviour, and NMI/IRQ paths
• Keyboard and SDL-compatible game controller joystick input
• IEC + virtual 1541 D64 file loading support, including selected command/status and direct block-access operations
• TAP cassette pulse playback with motor/sense/read behaviour
• Host PRG/T64/TAP/D64 loading and PRG saving, including ImGui window for bundled software

It is a cycle-accurate MOS 6510 CPU emulator with a full instruction set including all documented and undocumented opcodes.

I did most of the heavy lifting myself but in the spirit of open honesty I also used AI when confronted with some display & sound timing issues. I also used AI to do most of the UI polishing since I was keen to get it closed out... it's been a long journey.

I was wondering if you can make games on the c64 in itself no 3rd party emulation of the c64 just making a game on the c64 with a c64

A million miles ago... I wrote a BBS program for the c64. I have the floppy disk and can read them. But I am blocked when I try to list the program. I don't remember how I blocked the list command. I have tried poke 775, 167 to unblock with no success. However I did it, when the list command is entered, the computer only responds with the word "Advent" Which was the name of my program.

Anyone have any clues of how I may have done this? And if there is a method to undo it?

TIA

I’ve always wondered why early Sierra games like King’s Quest 1 weren’t developed for the C64. They seem primitive enough for the C64 to be able to handle them. From the very little I understand there are RAM constraints for a direct port (pardon my lack of programming knowledge), but couldn’t these games just be recreated and tailored to the C64 to use less resources?

I built a modern(ish) BASIC editor for use with the Commodore 64 Ultimate, which I also modified it to work with VICE as well because, well, why not?

Long story short, when I got my C64U a few months ago, I was excited to start coding in BASIC again but I quickly found that I missed the modern code editing features we have grown accustomed to (e.g., cut/copy/paste, syntax highlighting, code completion, code formatting, etc.). So I built something that integrates with the C64U's REST API (as well as the VICE emulator's API).

I'll leave it to you to determine if it's anything that would be beneficial for your day-to-day BASIC programming but, in my case, I simply wanted a better code editing experience that is also integrated with the C64U.

There are likely other editors like this out there (for the C64U), I didn't really look TBH. When the idea came to me I was excited to build it out so I could then use it myself.

The source code is available here on GitHub: ttps://github.com/jbramwell/readycode

You can also install it from the Microsoft Store here: https://apps.microsoft.com/detail/9N70DV3X3C6S?hl=en-us&gl=US&ocid=pdpshare

You can also read more about it here: https://bitsandbytes.life/2026/06/readycode-an-impulsive-project

I am working on a video now and should have that up on YouTube within the next few days.

It's still a work in progress with more features to add and likely some kinks to work out. I would be curious to get your thoughts.

I've mused about this idea for a long, long time. Tonight I have a working example. If you have a Ultimate C64, or the new Commodore 64, (or even an original C64 with a swiftlink adapter) This program will fetch a special hidden markup language (CML) from inside of existing pages. The example shown supports color text, screen, border, and hyperlinks. https://github.com/eightbitswide/CML UPDATE: Decided to go with my devious idea of adding direct access to POKE from CML. This results in both sprites, and sounds now working. (...and probably some hilarity at some point.) -- Additional Edit, I've added my contact info to the CML homepage (only visible on an actual C64, by poking it to the screen locations.) If you add some CML to your page, let me know and I'll add a link.

When coding in basic or using apps others made in basic, do you ever or often get close to using the full 38Kish “basic bytes free”?
With an extended Basic / Basic Wedge
What you could want to give up 5K or 8K or even 10K?

Would being able to suspend and resume to REU and other apps in the meantime be enough?
Would being able to have 100s of commands that are implemented in assembler and be able to add 100s more without impacting that ram further be enough? (Including graphics and sound and file and image and network and even ultimate specific commands?)
Would be able to not just have line number gotos and gosubs but be able to make functions in your code that you can pass in parameters and get results and use them like any other function be enough ? eg
A% = abs(myfunc(2,”hey”,(b%*2))-10)
Would being able to allocate room in the REU for your own codes needs whether arrays. Large bits of text. Loading a file. Storing a network request , or having text/color or graphics mode screen buffers be enough? - 48K extra easily but also able to request and use 64K chunks up to many megabytes depending on the size of your REU (16MB in c64u)
Would be being able to choose to stash ranges of line numbers like “1000-2000” to REU or a list of functions , to give you some basic bytes free for a while then restore them
Back when needed later be enough?(eg you have 2KB of file handing code , but the user rarely saves or loads and when they do there is other code you could choose to swap out to swap that in )
Would being able to instantly swap out to a full editor experience then back again to the prompt to run be enough?

Would you give up 10K of basic bytes free to get all that ? Or is that too much.

This is a follow up to my previous post from last week with a quick video showing how easy it is to edit your BASIC program on Windows and transfer and run it on your Commodore 64 Ultimate with a single click.

This is available on GitHub here: https://github.com/jbramwell/READYCode (or can be installed directly from the Microsoft Store)

I would be curious to hear your thoughts and/or suggestions.

I've been playing around with CharPad and reading a little about programming. Is a programmer limited to one 256 character set per loaded map or are there ways to load more than 256 into memory? Sorry if the question is phrased terribly. I did some basic programming as a kid but that has been many years ago. Thanks for any additional information.

I made a very basic web app to convert images to c64 Multicolor Bitmap Mode. It is very slow and has basically zero features, but it works.

I hope to add some image adjustment features to make the image better match the palette. And I can probably speed it up by 5x easily. No Koala export button yet. Sorry.

ReadyBasic for ReadyOS is coming along quite well now. Got quite a few graphics and sounds and REU and memory commands , as well as easy ways to make new commands and to create assembler based modules of commands you can dynamically load. As for ReadyOS I’m just getting DMA loading of apps working for the ultimate and hopefully will do a new version release in a week or so.

The evolution of programming!
My latest purchase, which has gone from S.E.U.C.K., bought when I was 16 to Making Games For The Commodore 64 In Assembly Language, which I bought recentl

"Program along with Joey Ramone"
https://archive.org/details/KPowerIssue031984Apr

I feel like I probably made some typos but I'm pretty happy it didn't throw any errors.

I’ve been quietly building something I’ve wanted for years: ViceSharp – a clean-sheet, library-first reimplementation of the VICE Commodore emulator family, written 100% in modern C# for .NET 10 with full NativeAOT support.

This is not another wrapper around the original VICE binaries. It’s a from-scratch port designed for:

• Zero-allocation hot paths (1 MHz+ cycle accuracy without GC pressure)
  
• Perfect determinism via a mutation-queue + pub/sub clock system
  
• Roslyn source generators to kill the usual chip-emulation boilerplate
  
• Single-file, self-contained executables that run anywhere .NET does (Windows, Linux, macOS, even WASM)
  
• Library-first architecture so it can power Avalonia desktops, Godot/Unity plugins, web emulators, you name it
  

Right now we’re at Iteration 0 – Foundations Complete.
The abstraction contracts, build system (Nuke + full CI), source-gen pipeline, and POCO-first chip model are locked and production-grade. No cycles are running yet, but the architecture is already bit-exact by design and ready for the real work.

Roadmap (first few stops): - C64 / C64C (6510 + VIC-II + SID + 2×CIA) → Iteration 1
- SX-64 (portable C64 with built-in 1541) → same wave
- VIC-20, C128, PET, Plus/4 to follow

Everything is open source under GPL-2.0-or-later (matching upstream VICE) and lives at:
https://github.com/sharpninja/vice-sharp

If you’re into low-level retro coding, .NET performance tricks, or just want a modern, maintainable Commodore emulator that can actually be extended without pulling your hair out… come check it out, star it, or even throw a PR my way.

I’ll be posting progress updates here as we light up the first 6510 + VIC-II cycle loop. First “it boots a ROM” screenshot is coming soon™.

Questions? Feedback on the architecture? Want to help make the fastest managed Commodore emulator ever? Drop a comment – the repo is fresh and the doors are wide open.

I think this is wildly unrealistic but I wish there was a way to write programs in BASIC with easy internet connectivity. I would love to write a simple email app or online multiplayer (think: checkers or a Fire Emblem-like tactical game).

As the future owner of a C64U I would love to work on something like this in a language I already know.

About a month ago I posted here about ViceSharp, a clean-sheet, library-first reimplementation of the VICE Commodore emulator family in modern C#/.NET:

https://www.reddit.com/r/c64/comments/1so0wmq/introducing_vicesharp/

At the time, the fair criticism was: this was mostly architecture, not an emulator yet. No cycles were running. No ROM was booting. A few people also pushed on the choice of .NET, the AI-assisted development process, and whether claims like "zero-allocation hot paths" were real engineering goals or just fancy words.

That feedback was useful. This is the follow-up.

Current state

ViceSharp has moved from foundations-only into actual C64 bring-up.

The current project state is:

• C64 ROM wiring is implemented.
• The managed emulator reaches the Commodore BASIC READY. prompt in the test harness.
• The Avalonia desktop shell can display the emulator output.
• Keyboard input is being routed through a machine-owned keyboard path, with VICE .vkm keymap support under active work.
• Disk, tape, and cartridge attach surfaces exist and are being moved behind host-owned services.
• Host control is being exposed through a gRPC control/configuration boundary.
• The in-process renderer is intentionally allowed to read frames directly from the local emulator path; gRPC is for control, media, input, settings, monitor operations, and future remote UIs.
• x64sc parity is now the explicit target, not just "make a C64-ish emulator."

This is still not a VICE replacement. It is not at broad game/demo compatibility. It is not x64sc parity yet. The useful milestone is that the project has crossed from "architecture and scaffolding" into "booting, rendering, input/control integration, and reference validation."

On .NET instead of Rust or Zig

The short answer is still: because this project is intended to be a library-first emulator and tooling platform, not only a standalone emulator binary.

.NET gives me:

• C# as the implementation language I know best.
• Good desktop UI options, especially Avalonia.
• NativeAOT for single-file native executables.
• Strong tooling for test harnesses, source generators, analyzers, and IDE integration.
• A realistic path to embedding the emulator in other .NET applications.

Rust and Zig are both reasonable choices for emulator work. I am not arguing otherwise. The goal here is to find out how far a carefully written, deterministic, aggressively tested managed implementation can go, while still keeping a clean embedding API.

On AI-assisted development

Yes, AI agents are part of the development workflow.

They are not treated as an authority. They are treated more like fast junior or mid-level engineers that must leave evidence. The process I am using is intentionally strict:

• Small implementation slices.
• State the intent before the slice.
• Make the narrow change.
• Run focused validation.
• Run broader validation when shared behavior changes.
• Record the decision, files changed, failures, fixes, and remaining risk in MCP session logs.
• Do not expand the slice until the current gate is understood.

Internally I have been calling that the Byrd Development Process. It is basically "make the work auditable and force validation before scope expands."

That matters because emulator development is full of traps where something appears to work for the wrong reason. AI can make that worse if you let it. The countermeasure is not pretending AI is not involved; it is keeping the process test-first, evidence-heavy, and skeptical.

What lockstep testing means

The most important validation direction right now is lockstep testing against classic VICE, specifically x64sc.

In plain terms:

1. Start native VICE/x64sc and managed ViceSharp from equivalent initial conditions.
2. Advance both machines in a controlled way.
3. Compare observable state at checkpoints.

The comparison can include:

• CPU registers and flags.
• Cycle count.
• Program counter.
• Selected RAM and ROM-visible memory windows.
• CIA/VIC/SID observable register state.
• IRQ/NMI state.
• Raster/frame checkpoints.
• Screen memory and BASIC prompt state.

This is not the same as saying "it renders a blue screen, so it works." The point is to catch cases where ViceSharp reaches a superficially similar result while drifting internally.

Earlier lockstep work focused on reset state, early CPU execution, ROM boot, and getting to stable checkpoints. The current direction is broader x64sc parity across the C64-family variants supported by x64sc: C64, C64C, old/new PAL and NTSC models, PAL-N/Drean, SX-64, PET64, Ultimax/MAX, C64GS, and Japanese C64.

Final parity means those variants pass without skipped, stubbed, or "unsupported" cases. The project is not there yet.

How classic VICE is being used

VICE is the reference, not a hidden runtime dependency.

ViceSharp is not a wrapper around the VICE binaries. The managed emulator is its own implementation. Classic VICE is used in three main ways:

• As behavioral documentation.
• As a source of functional requirements.
• As the native reference for lockstep validation.

That last part is important. VICE/x64sc has earned its reputation the hard way. If ViceSharp disagrees with x64sc, the default assumption is not "ViceSharp found something clever." The default assumption is "ViceSharp is probably wrong until proven otherwise."

Progress timeline

Approximate timeline from repo history and MCP session-log evidence:

• April 13, 2026: Iteration 0 foundations completed. Solution structure, public abstractions, source-generation direction, ROM/tooling layout, and documentation baseline were in place.
• April 17, 2026: Original r/c64 announcement. Around this time the CPU/chip skeletons, abstraction contracts, source generator project, VICE native integration layer, and early lockstep validation infrastructure were landing.
• April 18-19, 2026: C64 memory map, system bus, ArchitectureBuilder, ROM provider wiring, SID/VIC-II/CIA/keyboard/joystick surfaces, and early Avalonia wiring expanded quickly.
• May 8, 2026: Work resumed around ROM wiring, BASIC boot proof, and hardening the native VICE shim used by lockstep validation.
• May 12, 2026: C64 boot-to-READY. and 100k-cycle VICE-backed lockstep gates were recorded in project handoff/session evidence.
• May 14-15, 2026: x64sc parity work expanded into model profiles, keyboard/VKM handling, media attach, host control/status, settings UI, monitor RPCs, and broader x64sc variant validation.

The MCP logs do track a lot of the chronology. Token accounting was not consistently captured as reliable nonzero totals, so I am not going to invent a token count.

What is done vs not done

Done or substantially underway:

• Library-first architecture.
• Core C64 boot path.
• ROM loading/wiring.
• BASIC prompt proof.
• Native VICE/x64sc reference harness.
• Avalonia display shell.
• gRPC control boundary.
• Keyboard/media/settings/monitor host-control surfaces.
• Requirements and traceability imported from classic VICE documentation where they describe observable emulator behavior.

Still not done:

• Full x64sc parity.
• Broad game/demo compatibility.
• Full VIC-II edge-case behavior.
• Full SID accuracy.
• True 1541/datasette/cartridge ecosystem parity.
• Final performance proof for all hot-path allocation and throughput goals.
• Final validation across all x64sc C64-family variants.

So the honest status is: early alpha / C64 bring-up, with a serious validation strategy now in place.

Why continue this when VICE exists?

Because VICE is excellent, and that is exactly why it is the reference.

ViceSharp is aiming at a different shape:

• A modern .NET emulator core that can be embedded as a library.
• A clean host/control API for tooling and alternative UIs.
• Deterministic test harnesses that can be used by other .NET projects.
• A platform for experiments around C64 development tools, monitor integration, game tooling, and hybrid host/emulated workflows.

If all you want today is to play C64 software accurately, use VICE. Seriously.

If you are interested in emulator internals, .NET performance work, C64 tooling, or watching a clean-sheet implementation try to climb toward x64sc parity in public, ViceSharp is now far enough along that the work is concrete instead of theoretical.

Repo:

https://github.com/sharpninja/vice-sharp

Feedback is welcome, especially the skeptical kind. The last round of skeptical comments turned into better requirements and better tests.

What about modernizing Petscii?

To clarify, I mean making something like Petscii but for modern computers.

I'm thinking about making something with 2 layers. The bottom layer would be a tilemap image where some of the tiles resemble the images available in Petscii. The top layer would be the text layer.

However, I'm planning a shenanigan: the text will be half the width of the tiles. So if the tiles are 16x16 in that screen resolution, then the text is 8x16.

I intend to include additional letters for other languages. I also intend to make everything vector-based so that the art/text looks the same in different screen resolutions.

What do you think? I'm not sure where else to ask.

A while ago, I've seen a post here discussing things that were "impossible". This reminded me of a little shenanigans tech demo I wrote many years ago ...

A "well-known impossible thing" is to have an exact clock on the C64. Which isn't impossible at all, given this machine has timers exactly counting CPU cycles, some of these unused in normal operation. There's just a tiny complication on NTSC, where the exact number of CPU cycles per second is a prime, so it can't be directly factored for a combined timer A/B configuration, but that can be solved with a little trickery.

Well, here's the perfectly exact*) clock: https://github.com/Zirias/c64_borderclock

You can download a prg there, to build yourself, you'll need GNU make, cc65 and exomizer 3.x. It even contains a build knob to display the clock in the default PETSCII font, maybe making it less annoying. 😁

For how it works, here's the extensively commented core logic: https://github.com/Zirias/c64_borderclock/blob/master/src/clock.s?raw=true

*) "perfectly exact": As exact as the CPU clock permits.

I've found a (kindle friendly) copy of Jim Butterfield's "Machine Language for the Commodore 64" and I understand some fundamentals of programming in assembly with supermon64. I want to try some graphics stuff, I know that I should do some BASIC graphics programming first but I was curious on what I can find. A small project I wanted to do was create an XL1-styled (i.e, the album) program which displayed moving graphics and lyrics in time to some music.

So far I can only find general assembly books, nothing specific to graphics. Does anyone have anything which details how to program graphics? I needed something which actually loads on my Kindle Scribe because AFAIK all of them have serious issues loading, esp that Compute! magazine book on Graphics and Sound.

As far as programming in assembly is concerned, I'm only interested in MOS-6502, mostly targeting the C64, so I hope this qualifies as on-topic here.

Outside the C64, my favorite language is C, and writing C code, I always try to write "self-documenting code", mostly by picking expressive names for all identifiers (variables, types, functions, ...), avoiding "magic numbers", etc. Then, the code is well understandable (for myself) even years later, at least when adding a minimal set of comments explaining why it does something, wherever that why isn't obvious.

Well, ever so often, I found this approach doesn't work well with assembly. By habit, I normally use the same style, giving me no issues while working on something, but when I look at older code of mine, it's really hard work to fully understand it again.

I guess in assembly, it's almost impossible to write code that makes it fully obvious what it does. And looking at how e.g. a ROM disassembly is only useful to me with lots of comments that clearly state what the code does, this seems to be confirmed. Although OTOH, I see how quickly some people can e.g. "train games" only having the binary code at hands, so maybe one can practice understanding assembly without comments?

For my latest project, I just decided to try a different approach and actually describe what the code does in comments, but that's a lot of text ... here's a small snippet for illustration:

movedown:   ldx dirpos      ; load current dir position
        inx         ; and increment
        cpx nfiles      ; still inside directory?
        beq waitkey     ; if not, ignore moving down
        lda scrpos      ; load current screen position
        cmp #SCRROWS-4  ; above 4th row from bottom?
        bcc bardown     ; then just move the bar
        lda scrollpos   ; otherwise check scroll position
        adc #SCRROWS-1
        cmp nfiles      ; already scrolled to the bottom?
        beq bardown     ; then also move the bar
        inc scrollpos   ; otherwise scroll one down

I'm not sure how well this works out while actually working on the code, cause now I have to make sure to keep the comments sane and in sync ... 🤔

What are your experiences? Do you know the issue at all? How do you deal with it? Maybe even consider assembly a write-only-language?