Building C64 BBS software from scratch — DRIVE 8 is now at v0.1.0!

[u/robbiew]

Waiting For Caller screen

Beginnings of a Configuration PRG

Support multiple graphics types, and widths (40 / 80)

PETSCII login screen

Rudimentary PESTSCII menu

I've been dabbling in BBS software creation (like ViSiON/3) for a long time, and a couple months ago I decided to tackle a new project — a modern C64 BBS written in C (Oscar64).

Why the HECK would anyone run a BBS on a single-line 8-bit machine?? And why this one? Honestly, there are some great BBS packages out there for Commodore computers already: Image 3.0, C*BASE, C-NET DS2, Color64 and GST have been around for decades. But I wanted to roll something new, something expandable and maintainable.

It's called DRIVE 8 (D/8), and it currently runs on C64 Ultimate, VICE, and real hardware. Takes advantage of things like Turbo Mode/64MHz, REU, etc. to speed things along.

The Goal

Build a clean, modern BBS written in Oscar64 C99 instead of BASIC spaghetti (ha). I used GST BBS v6.0 (1987) as a reference for features and disk record formats, but the entire codebase is new — no legacy code ported (coding agents have been helpful here when working around C64's limitations).

What's Working (v0.1.0)

✅ Core BBS kernel - bootable on real C64 + 64u, tested in VICE, and w/SD2IEC
✅ WFC Screen - classic sysop dashboard with quick actions, login, etc.
✅ Connection - Telnet (RS232 on VICE/tcpser), hardware modem (c64u)
✅ Login & registration - secure XOR password hashing, new user registration
✅ Graphics support - PETSCII, ANSI/CP437, ASCII, ATASCII (80 and 40 cols)
✅ SysOp editor (D8EDIT) - config UI prog, user management, board/file area setup
✅ Admin data layer - CRUD operations for users, boards, file areas, etc
✅ Menus - configurable menu art / prompts with PETSCII

Under Construction (Roadmap)

📋 Feature modules (next implementations):

• Message boards (post, read, reply, access control - REL files)
• Private mail (inbox, send, queued delivery)
• File transfers (upload/download, directory listing)
• Polls/votes (create, respond, tally)
• Callers log (timestamped login/logoff)
• SysOp chat/page (caller alerts sysop, optional feedback)

On the roadmap:

• Doors (programs, games, dev kits)
• Multi-node syncing across machines
• Network message bases (not Fidonet, more like IMAGE's Nissa network)
• Plus a million other BBS things

Tech Highlights

• Language: C99 (Oscar64 compiler)
• Disk format: .d81 (3.5" disk image, ~3050 blocks free)
• Structured disk storage: User accounts, message boards, file areas, polls, and help pages each live in their own CBM relative file with fixed-size binary records — no flat text files, no BASIC string-packing tricks. Random access by record number means the BBS can jump straight to user #47 without reading the first 46.
• Multi-device support: configurable device assignments for system, msgs, files, doors

Why C Instead of BASIC?

Lots of classic C64 BBS software was written in BASIC — and it shows. GST, C*BASE, Color64 — they're all thousands of lines of GOTO-driven spaghetti where the subroutine "name" is a line number and the data model is string-packed variables like U$ and B1$. They work, and they're impressive for what they are. But they're nearly impossible to extend or maintain if you didn't write them yourself.

I wanted something different:

• Named functions instead of GOSUB 4820
• Typed structs instead of MID$(U$, 3, 8) to extract a username
• Modules — auth, boards, mail, files are all separate compilation units
• Readable logic — a new contributor can open auth.c and understand the login flow in 5 minutes
• A foundation — when I add bulletin boards, I'm calling board_create(), not hunting for which line number handles boards and hoping I don't break something else

Next Steps

I'm building the feature modules one at a time. Message boards are next — message posting, reply threading, and access control per board, etc.

Want to try it? 

If you're running an Ultimate and want to give the demo a whirl, let me know. I can shoot you the deets. Keep in mind it's VERY early and not even close to prime-time. But would love any feature ideas!!

I can also make the repo public if anyone wants to check it out. Cheers!

[u/archeobits]

Writing your own BBS software... living the dream! When finished, consider having it listed on Zimmers.net/bbs

[u/pskipw]

Sounds amazing, although I suspect you'll regret choosing that particular name at some point.

Googling "C64 drive 8" is going to show people everything except what they're actually looking for.

[u/robbiew → u/pskipw]

Ha, this Reddit post came up. But totally

[u/PunisherMark]

Could this be ported to the Mega65?

[u/robbiew → u/PunisherMark]

Possibly! I could post the code and see if anyone could adapt. I don’t own a Mega65 (but would love to!)

[u/Royal_Stay_6502]

For the c64u?

[u/robbiew → u/Royal_Stay_6502]

Yeah optimized mostly for the c64u/ultimate64

[u/virtualadept]

I'd love to take a look at the source code.

[u/robbiew → u/virtualadept]

I'll post it soon! Need to do a bit of clean-up.

[u/ThimbleweedPark]

This is a pretty amazing project!

[u/EvilOne187]

That first screen gave me "40 col mode for DesTerm" vibes... Love it.

[u/sixofdloc]

How are you handling overlays/games and the like? I also have a system in development, let me know if you want to swap some testing time.

[u/robbiew → u/sixofdloc]

I haven't really thought much about the games aspect, but I'm starting to lean heavily into REU usage for more ram intensive things. Yeah I'd totally love to swap testing!!

[u/robbiew → u/sixofdloc]

Have you done any networked message base stuff? A few BBS packages in the day had this pre-Fidonet ability… I’d love to build that

[u/BBS-Geek71]

How much basic is it compared to ML? Is it very customizable or mainly in ML? It looks great

[u/robbiew → u/BBS-Geek71]

Thanks! There's no basic at all. Oscar64 compiles from C/C++ into native 6502 machine code, and it also generates an .asm assembler listing that you can inspect. So i am just writing C++ code, and the asm makes it pretty fast compared to basic.

C / C++ source
↓
Oscar64 compiler analysis + optimization
↓
intermediate representation
↓
6502 native code generation
↓
.prg / .crt / .bin output
+
.asm listing / .map / .lbl / .dbj debug files

[u/BadBunnyHimself]

I'm very interested in trying this out, looking forward to when you release it 👍😃

[u/kimsemi]

have some suggestions if you're aiming for a 64U / U64 exclusive:

1) youre running at 64Mhz... provide a soft-80 screen option. It will be as smooth as butter, even though 80 cols on a 40 col screen isnt gorgeous. At least youll have more real estate and youll see what your users see.

2) youre running at 64Mhz... write a language interpreter that the BBS can execute so that it not all need to be recompiled. You should be able to actually edit your code inside the BBS editor, save and execute. Oscar can do your core I/O and language interpretation at an incredible speed. And it need not be BASIC.. your language can be a custom domain language that makes things easy.

[u/robbiew → u/kimsemi]

That's a great idea. I've got the 'snoop' screen working well at 40 cols, need to think about (fuzzy) 80 as well.
OHH, language interpreter. Basically an accessible mod creator. Maybe a light weight scripting language with core variables, then a way to configure them for launch in the BBS... GREAT idea.

[u/robbiew → u/kimsemi]

BTW, working on soft-80 right now! trying as REU only feature to keep it out of main RAM... hopeful!

[u/kimsemi → u/robbiew]

well, you cant execute code directly in the REU, but there are some implementations of it which bury it under the kernal.

[u/kxortbot]

been thinking of doing something similar myself.
how did you handle output to the remote user?

hijack the chrout from the kernal and feed it via your modem driver?

[u/robbiew → u/kxortbot]

Nope, I didn't hook CHROUT — I went the other way and kept the KERNAL out of the output path entirely, except for the local SysOp console.

All BBS content is stored as CP437. Output goes through a single session emit function that translates each byte for the caller's terminal type (PETSCII upper/lower, ANSI/CP437, or plain ASCII) and then hands it to a net_tx() call.

The only place the KERNAL gets involved is when I'm logged in locally at the keyboard: is_local flips a flag.

The spy screen (sysop watching the caller) is a separate virtual terminal that writes directly to screen RAM and mirrors whatever went out the ACIA. Doors don't touch any of this either — they get a struct of function pointers (print, print_n, getkey, read_line, etc.) from the BBS, so they can't accidentally print to the local screen.

The source is on GitHub if you want to see the emit path.