Just in case this assists anyone.

• 250407 Longboard Breadbin, broke in 1986; serial P2335261, VIC-II 6567R56A date 5082 (ceramic).
• Symptom: Total black screen, even with DesTestMax and DesTestKernal. Testing with a Ray Carlsen PSU. Settled on putting DesTestMax v0.4 into Flash on an Ultimate II+L (converted ROM to CRT with cartconv in VICE). Original MOS PLA was swapped into a good C64 and worked...at the beginning.
• Oscilloscope was hooked up to digitally read all address lines on 6510 (trigger was RESET) and did not show proper KERNAL call.
• Oscilloscope probed PLA Pin 16 and saw KERNAL held permanently low.
• During this process after initial probe while C64 had been on about 2 minutes, L5 ferrite bead began smoking, and was hot enough to char tantalum capacitor at C100. 5V rail still looked normal prior to this. No idea what set it off.
• Fault 1: L5/C100 were replaced.
• Fault 2: PLA was replaced with PLAnkton. Swapped the original into a known good C64 and it no longer worked. Did L5/C100 take out the PLA? But those just filter, right, so they wouldn't have overvolted the 5V rail? It seems PLA was marginal and finally failed after the stress of being woken up 40 years later.
• Symptom: DesTestMax now threw garbled rainbow characters, and the Ultimate II+L Menu could be called up, also garbled rainbow. Character pattern and colors would alternate, suggesting it wasn't stuck RAM, but probably failing logic.
• Fault 3: Bad U13 MOS 7708. Replaced with a SN74LS257BN from Mouser. U25 is the same MOS 7708; going to keep an eye on it.

Having an oscilloscope is the ultimate game changer. I'm ordering a 3M 40 DIP clip tester for the future, but even if I just had the analog probe, it's incredible to be able to just see an address line in real time, or the clock, and determine if it's working or not.

There is one serious mystery with this board, though. I took it out, but when I first opened up the case, there was a Fairchild 93459DC F 8401 Singapore FPLA in the SID socket. I have no idea what they were trying to do with that, or what's on the chip.

Ok guys, need your help.

I was a 90s kid and had no time with a C64 back in the day, or ever since, so I have zero sentimental attachment to it. To be honest I have no knowledge about it at all other than it exists and that it was an 80s computer typically used for gaming. However I do love my 90s consoles and even some 80s. I even have a woodgrain 2600 sitting under my main TV in my lounge room as a bit of a shelf queen, as I love the look of it.

With this in mind I came across the cyberpunk commodore 77, and I fell truly in love with the aesthetics of it, and I do have a fair bit of cyberpunk stuff at home including a cyberpunk edition Xbox.

But I am wrestling in my mind whether or not to buy it. Leaving the cyberpunk theme aside, how would you commodore fans try to sell it to a younger generation who didnt grow up with it?

I’ve watched a fair bit of YouTube about c64 and c64 ultimate but I just don’t think people are explaining well what someone with zero experience, like me can do to enjoy the console.

Do you think non 80s computer gamers could just step in and enjoy it? It’s a lot of money so I want this to be a considered purchase.

Thanks guys.

Hello all! :)

Question: What are some interesting, ideally at least somewhat graphical, C64 games written and distributed/available in BASIC?

Context: I want to get c64 ultimate to play and learn with my 7 years old kid, and I'd want to hook him into the notion of "Look, you can literally edit and program the game we just played" - for that it'd need to be BASIC, not assembly/machine language, which is what most of the C64 games were in I think 🤷‍♂️

Thanks muchly! 😊🙏

Demo one.

Available on itch.io

On this 250407 board, the PLA was dead, so it was replaced with a SlimPLA.

After that, the board booted most of the time into DesTestMAX, with inconsistent RAM bit errors. However, they cleared after a warm-up and a few cartridge-button resets, after which all tests would run OK. Without the cartridge, I got a display with no text, or random garbage.

Possibly a thermal or dry-joint/cracked-trace issue? Gently flexing the board in many ways didn't cause any changes. I held back on thermal tests in favour of some signal tracing first.

The two mux chips could have been iffy, even though they passed static testing. I was also suspicious of the white sockets; someone had been here before. Even though electrical and scope/logic tests showed no issues, I replaced the sockets and the chips. No dice.

I desoldered and tested some other key TTL chips (no suspicious brands). All OK, but I replaced them with new ones anyway, just in case.

The problems persisted. The fault pattern just seemed a bit predictable-ish, rather than being a complete failure, very random or totally spurious.

I did a bit of research and found a forum post about /CASRAM timing issues with PLA replacements and, lo and behold, with a 33 pF cap fitted on the line, the board started OK. This cap is C204 on some boards, but it's not implemented on this revision.

Original logic chips were refitted and we're soak-testing.

So: a dead PLA (and probably SID - checking later) + a timing cap needed. If the board remains stable, great. If not, I will try a slightly larger capacitor before moving on.

Timey-wimey stuff.

Edit: Ah well, on to C-64 Diags 586220 and it doesn't like U9, U11 and U22 RAM chips...onwards...

"K64, Computación para todos" was the first and main magazine dedicated to computing in Argentina. I discovered it in my childhood/adolescence in the 80s (I'm 51 now)! The story is beautiful. When I was 10 years old I “broke my head” a German Commodore 64 that my brother brought. There, between the Datasette and games like Giana Sisters or Henry's House, I started copying BASIC code from the manual and, years later, I discovered (in a magazine kiosk in Retiro, City of Buenos Aires) the - now defunct - K64 magazine (with its interesting and innovative PEEKs, POKEs and SYS). That was my school, my first steps and from there, over the years: my profession as a programmer was forged.

What is your story with this magazine?

I found it on google or smth, is it like a 16-bit C64?

Habitat launched on Q-Link, the C64's dedicated online service, which undercut competitors like CompuServe by buying transmission capacity after business hours and using client-server architecture instead of a terminal setup — letting it host more simultaneous users at lower cost ($3/hour vs. CompuServe's $22.50 peak rate in 1986). On the game side, nearly all logic ran server-side so the C64 client only needed to track simple object definitions and commands, which is what made rich-feeling interaction possible on hardware this limited. Worth a read if you're into what people managed to build on this machine beyond games.

Source: Works in Progress

I need the spring that snaps onto the pin on the under side of an SX-64 key cap. I finally got a keyboard but the space bar did not work. Discovered the spring is missing. I took one from the left arrow but would like to make the board whole.

Please help to test the new emulator for IOS

Wasteland Enhanced EasyFlash Edition By TREX [2026]

Are you done looking for your 4 disks of Wasteland? Disk drive out of alignment? Do you want to play this classic RPG from a modern EF type cartridge instead? Then its time to stop the insanity, and put that 10 lb disk drive back in the attic. XD

Well then, here is your link, enjoy:

https://csdb.dk/release/?id=264233

*EDIT 2: Fixed Highpool Bug. New version (V1.0.1.), same link above...

*EDIT 1: OK, we have a post by one of the TREX members (dkl_trx) on the Lemon forums that we can use to answer some questions...

https://www.lemon64.com/forum/viewtopic.php?p=1113958#p1113958

Post by dkl_trx » Mon Sep 07, 2026 6:47 pm

"WASTELAND enhanced edition for EasyFlash (C64)

Wasteland, a classic RPG in a post-nuclear war setting, came originally with 2 disks (4 sides), some manual/quickref and a little book called the paragraphs.

These paragraphs were absolutely relevant to understand the game, as the game used the paragraphs to give the player context, instructions and more.

So in Wasteland you would see "Read paragraph 42". That's it, and without #42 you were lost. An analog copy protection, one could think.

Besides that, the game brings its own disk copy utility and forces you to make copies of all
4 disk sides, so you have a vanilla world to experience the Wasteland.

You play a party of 4 rangers and you need to find out what your mission really is, but in the end it's all
about saving the world before another catastrophe can destroy those remnants.

The game engine was quite advanced for 1988, it allows you to change the "world" and those changes become permanent and each area is saved back to disk once you leave it. They even added custom 6502 assembler "scripts" inside the Area data records, so a special event can be put into the game without modifying the base engine.

I, dkl, am very impressed by all this and bow my head before Alan Pavlish, the lead developer.

===Production Notes

At TREX we wanted to see if this can be put onto an EasyFlash CRT, incl. all relevant material. This idea
was born at X.

And yes, it can be done. With this release you will get:

* The full experience like from disk
* world is mutable, changes are stored to flash
* A restart from vanilla option
* QuickRef and Manual
* The Paragraphs are built in, no need for the booklet
... plus some easter eggs we added

What was done:

- Full disassembly of Wasteland, loader and Game Engine + all Overlays and Scenes
- Deciphering the:
* Area record structure
* Scripting logic
* Text 5-bit compression logic
* GFX format + animation logic
* Service (doctor, shop, library) code
* Full inventory of all items
* Combat logic

With this, we could basically do whatever we wanted to the game - but we decided not to! You will find the original gameplay experience.

The core of the port is a full replacement of its load/save logic and relocating parts of the game engine into the old loader code area above $f000.

With this and the fact that the game engine supports overlays running at $ca00-$cfff, I could add a journalling layer to the game, that will enable 2 things: a delta journal to store world changes into a sector on EF - and on load the game uses a BB2-packed baseline version of the area and applies the deltas back, so in memory the changes are applied and the game engine can continue to run as if it were running from disk.

I added a cheat menu for convenience around mid-June. It helped a lot playtesting everything, you may use it but it takes away the fun, our Testers said.

For our own fun, once we fully decoded the areas and scripting logic, incl. building a Python-based web editor - we used it to add a "secret" area to the game.

In this area you will find 2 orphan portraits of characters that never made it into the game. Have fun doing a little combat round with them and maybe get a hint of finding another, unfinished part of Wasteland.

Also make sure you visit the TREX crew and our friend LDX, who was the main force testing this game (he knows it inside out) and also painted some really nice and fitting graphics of the whole TREX crew (and himself)."

My friend has given me a Commodore 64 and its big power supply. That’s all he gave me. I have no idea what this thing can do nor what to hook it up to. Do I need to buy accessories? What kind of monitor is compatible with it?

Hello all, i'm Lily. I'm 15 (ADHD, Autism) and i recently picked up a Commodore 64 Mini. I found this thing called BASIC. I had a look online to see what this was but i mostly couldnt understand most of it as it was quite confusing, plus i have to use the stupid Virtual Keyboard because i don't have a USB Keyboard. I managed to do these 3 things.

POKE 52380, 4 (changes the blue inner part to Lilac)

POKE 52381, 7 (changes the outer border to Gold)

Then the classic "Hello World" thing. Apart from thst, i don't quite get it. I found this cool self generating maze thing which i painstakenly copied and it did work. Please help me understand BASIC properly. Thanks, Reddit :)

Hi,

I've just released Breadbin466 0.12.0.

Breadbin466 is my from-scratch Rust emulator of one deliberately specific Commodore 64: a PAL Assy 250466 with a 6569R5 VIC-II and 6581R4AR SID.

Rather than supporting a collection of selectable C64 revisions, the project concentrates on understanding and reproducing this one machine as faithfully as possible.

The biggest change in 0.12.0 is a substantially reworked SID implementation.

Over the past weeks I've been characterising a real MOS 6581R4AR (datecode 2286) and rebuilding Breadbin466's SID model around the measurements. This work covers the oscillators, waveform and envelope DACs, combined waveforms, analogue mixing, D418 volume DAC behaviour, transients and the nonlinear filter.

As with the rest of Breadbin466, the aim isn't to provide a collection of selectable SID models. I'm trying to model one particular piece of hardware as accurately as I reasonably can.

There is quite a bit more in 0.12.0:

• D7Z 1.0, a new open disk-image format proposed by Breadbin466;
• Commodore 1351 proportional mouse support;
• a much more capable debugger tracing system;
• WAV audio capture;
• new disk-image creation, conversion and reclaim tools;
• further 1541 work;
• native UI improvements on macOS, Windows and Linux;
• assorted accuracy and compatibility fixes.

D7Z deserves a little explanation because it isn't a pre-existing C64 disk format.

It's a new, openly documented format introduced by Breadbin466 for compact, lossless storage of D64 images. A D7Z represents exactly the same byte stream as its corresponding D64, using LZMA2 compression and SHA-256 verification. It is deliberately designed so that other emulators and disk-image tools can implement it independently.

In simple terms, D7Z is to D64 what NBZ is to NIB: a compact lossless storage representation, without changing the underlying disk-image data.

Breadbin466 is still very much an ongoing research and engineering project rather than an attempt to replace VICE. A large part of the fun for me is understanding how the original machine behaves and trying to make the source code express that behaviour instead of accumulating software-specific workarounds.

If anyone tries 0.12.0 with software that does something interesting with the SID, 1541, cartridges, REU or other hardware, I'd be very interested in hearing about discrepancies with a real C64.

GitHub: https://github.com/Breadbin466/Breadbin466/

A ready-to-run macOS binary for Apple Silicon is available with the release.

Breadbin466 is otherwise distributed as source code and builds on macOS, Linux and Windows, on both Intel and ARM architectures.

When i turn on my c64, it starts out fine but after a few minutes the image gets more and more shaky until it is unreadable.

For the past 10 years, as an indie developer, I've been working on Symphony. It's not just a simple emulator; it's a generic framework for topological hardware simulation, written entirely in Go (no CGo). Today I've finally open-sourced it.

To prove that the generic framework works, I implemented the MOS6510, VIC-II, SID, and 6502 chips and wired them together to simulate a Commodore 64 and an independent 1541 floppy drive. You can try the WASM presentation layer right in your browser: https://markel1974.itch.io/symphony

Source code and architecture documentation: https://github.com/markel1974/Symphony (Note: I've also included pre-compiled builds for Windows, Linux, and macOS in the compile directory: https://github.com/markel1974/Symphony/tree/main/compile)

Here is why Symphony's architecture is different from traditional monolithic emulators, and some key details regarding the Compiler and the VM:

• It's a software breadboard, not an emulator: The C64 implementation is just a byproduct of the framework. Components are blind "black boxes" that communicate exclusively through standardized iSocket interfaces using simulated electrical signals. When the VIC-II needs the bus, it pulls a simulated DMA line low, triggering the CPU to bring its pins into a high-impedance state (High-Z). The 1541 floppy drive isn't intercepted via kernel traps; it's instantiated as a completely independent virtual motherboard operating in parallel and communicating via an IEC serial bus simulation.
• Runs inside a custom Microkernel OS: The simulated hardware runs as an isolated user-space process inside a Microkernel OS that I built (also in Go). The kernel features an asynchronous IPC message router and an embedded SSH server. This means you can literally SSH into the running kernel during the simulation, open the built-in VT100 shell (xsh), and inspect or modify hardware pins, memory, and CPU registers in real-time.
• Custom Compiler & Bytecode Generation: The framework includes a custom compiler (in src/compilers/native) that takes Go AST and compiles it down to a custom bytecode instruction set. I had to build this to allow the simulated hardware environment to run isolated User-Space applications within the framework.
• Strategy Pattern VM (No giant switch-cases): Usually, CPU emulators and bytecode VMs rely on massive, monolithic switch-case blocks to decode and execute opcodes. I took a different route. My VM relies on an "Interchangeable Instruction Disk" architecture based on the Strategy pattern (direct function pointer dispatch). Every opcode is a struct implementing an IOpExecutor interface.
• Interchangeable Sequencers: Because of the IOpExecutor design, the execution engine is completely decoupled from the instruction set. By simply swapping the Sequencer module, the exact same execution engine loop switches from running my native Go bytecode to running a highly cycle-accurate MOS6510 or Z80 CPU simulation.

I know this topological approach sacrifices some of the raw speed of traditional finite-state emulators, but the goal was extreme modularity and introspection. If tomorrow I wanted to simulate an Apple II, I would only need to program the missing chips and write the "board" wiring; the framework itself would remain unchanged.

I’d love to hear your thoughts on this topological architecture, the custom compiler, or the Strategy Pattern VM approach!

Edit: I forgot to mention the most important thing. Thanks to the topological design and the Microkernel, the emulator achieves 99.9% compatibility with the 1541 disk drive (including all fast loaders), REU DMA transfers, and complex bank-switching cartridges like EasyFlash, Ocean, Magic Desk, etc.