NABU BBS Project - Direction Notes and Questions for Users and Hosts

[intangybles]

NABU BBS Project - Direction Notes and Questions for Users and Hosts

Date: 2026-03-27

Why I am asking

I have now proven that a simple native NABU BBS can work over the Internet Adapter TCP server. We can connect from a telnet client, identify the caller, post a message, read messages back, and keep the data on the IA storage.

That is enough to start building something real, but not enough to know what users actually want this BBS to become.

I have a lot of possible directions in my head, and I would rather ask the people who may actually use it before I push too far in one direction.

How almost all old CP/M BBSes worked

Roughly 90 percent or more of the old CP/M BBS world followed the same basic configuration:

• one machine
• one caller at a time
• one serial port or modem path
• one compiled binary built for a very specific target machine and hardware setup
• local disk files for users, messages, uploads, downloads, logs, and configuration
• text-only or very simple terminal interaction

In practice, those systems were usually built around:

• a specific modem
• a specific BIOS
• a specific I/O port layout
• a specific CP/M machine
• a specific storage arrangement

That is why old BBS backups are so often machine-specific. A restored BBS may be "the same software", but the actual binary might be built for a Kaypro 10, an H89, an Osborne, or some other exact machine and port arrangement. The source may exist, but the running system was often tightly coupled to its target hardware.

This is exactly what I have with backups of my old BBS. They were all set up for a Kaypro 10 and were very limited in the way file access worked. In some cases the user effectively had to drop to the operating system and manually run XMODEM-style tools to upload or download files.

Many of them also depended on front-end and helper programs:

• sign-on programs
• hangup or "bye" utilities
• file transfer helpers
• external door runners
• utility programs that rebuilt indexes or user records

So even when an old CP/M BBS looked simple on screen, the working system around it often was not.

Why that old model is not a practical NABU path today

There are several reasons.

1. They are too machine-specific

The classic CP/M BBS packages that I know and have researched are not "generic CP/M BBSes" in the modern sense. They often assume:

• direct serial hardware access
• specific modem control
• carrier detect
• hangup control
• BIOS-specific console or port behaviour, as many CP/M terminal programs also do

For example, the Citadel BBS software explicitly expects custom modem port, carrier-detect, hangup, and port-init routines to be provided in the local configuration. That is exactly the kind of machine binding that makes straight reuse difficult on the NABU.

2. They were built for a phone-line world

The classic model assumed:

• auto-answer modem
• caller dials in
• one live serial path
• carrier loss means disconnect

That world is mostly gone. In Australia especially, many people simply do not have access to a standard analogue telephone line suitable for the classic dial-up model. Yes, serial-to-WiFi bridges and similar workarounds exist, but they add another hardware hurdle before someone can even try the system.

3. They are very simplistic by modern expectations

That simplicity is part of the charm, but it is also a limitation. Many classic CP/M BBSes offer:

• very basic user records
• very basic message storage
• very limited private messaging
• limited or external file transfer support
• very little flexibility without recompiling or running utilities

That may still be fine if the goal is a museum-perfect recreation, but it is probably not the best starting point if the goal is "a NABU BBS people will actually use now".

4. Their support tooling is awkward today

A lot of old systems rely on helper programs and installation assumptions that are annoying now:

• external utility chains
• special submit files
• rebuild steps
• local disk layout assumptions
• front-end "bye" or sign-on programs

That is not impossible, but it is a lot of friction for a small retro community project.

5. The NABU has a better native networking story

The NABU has an important advantage many classic CP/M machines did not have:

• direct TCP support through the Internet Adapter

That changes the design space completely. Instead of pretending we are still in a modem-only world, we can build around what the NABU actually does well today.

The major architectural choice

The biggest question is not "Can we copy an old BBS?"

It is:

"What is the best BBS for the NABU as people actually use NABUs now?"

Right now I see three broad paths.

Option 1 - Serial / CP/M / old-style BBS direction

This would mean aiming more toward:

• local serial hardware
• CP/M environment
• possibly local disks or CF storage
• maybe RomWBW-based operation

Advantages:

• closer to traditional BBS architecture
• easier to think in old BBS terms
• more naturally aligned with machine-local CP/M file systems
• could potentially run from a CF card or RomWBW environment

Disadvantages:

• very limited real user base with suitable serial hardware
• not every NABU has a serial add-on or RomWBW card
• actual RS232 users are a minority compared with IA users
• connecting over real dial-up is not realistic for most people now
• it moves away from the NABU's strongest modern advantage, which is IA TCP access

Option 2 - Native NABU plus IA TCP plus IA storage

This is the direction I have prototyped so far.

Advantages:

• works with the setup most NABU users already have
• uses the IA TCP server directly
• no need to recreate the old modem world
• storage through the IA is effectively much less constrained than a tiny CP/M disk image
• easier to make the software feel NABU-native rather than like a forced port

Disadvantages:

• we are writing more original code, although the old code would still need considerable work regardless
• the IA storage model is not the same as a classic CP/M local disk environment
• if we want to support later non-IA environments, we need to design for that consciously

Option 3 - CP/M app, but front-ended through the IA

This is the compromise idea.

Advantages:

• preserves some CP/M structure
• still uses IA networking
• could potentially support more than one deployment style later

Disadvantages:

• highest complexity
• easiest to get trapped in translation layers and front-end glue
• may end up being the worst of both worlds if not done carefully

My current view

My current lean is that the project should stay native NABU and IA-first unless the community strongly wants otherwise.

Why:

• almost every NABU user already uses the RS422 path and some form of Internet Adapter
• direct TCP via IA is a major advantage
• native NABU plus IA avoids pretending we still live in the old single-modem phone-line world
• it gives us far more freedom in storage and UI design

That does not mean serial or CP/M should be ignored forever. It just means they should not dictate the first design unless there is a strong community reason.

Current technical limits from NABU-LIB and current testing

This is the part where I most want feedback, because it influences design scope heavily.

What NABU-LIB clearly gives us now

From the current NABU-LIB TCP server API and existing tests, we clearly have:

• the ability to know how many clients are connected
• the ability to read incoming data from the IA TCP server
• the ability to write data out to connected clients
• practical telnet-style access through the IA server
• IA-backed storage for files

We also now have a working native prototype that:

• accepts a remote caller
• prompts for a name
• stores messages on the IA
• reads them back
• shows local status on the NABU

Important practical limitation - multi-user support looks weak right now

The IA TCP server API appears to expose:

• client count
• available data
• server read
• server write to all connected clients

What it does not appear to expose is:

• a per-client handle for incoming data
• a per-client write target
• a session object per remote user

That matters a lot.

At the moment, this strongly suggests:

• a single active user is the realistic target
• or a shared group console / chat style service

It does not currently look like a clean foundation for a true multi-node BBS where each caller has an independent session.

So can we run multi-user?

In theory, maybe in some limited sense.

In practice, with the current visible NABU-LIB API, I would say:

• true independent multi-user BBS sessions are probably not practical right now
• one caller at a time is the safe target
• two or more simultaneous telnet connections would likely share output or otherwise behave badly unless the IA layer provides more than the current API suggests

So my present answer is:

• safe answer: single user
  
• possible but doubtful: a small shared experience
  
• not something I would promise: proper multi-node BBS operation
  

What about memory limits?

The NABU is still a 64K machine, and that matters even with IA storage.

IA storage helps with:

• message files
• user files
• logs
• file areas

But it does not change the RAM limit for live program logic.

The practical implication is:

• a simple single-user native BBS is realistic
• a feature-rich multi-user server would be much less realistic
• large in-memory message or user structures should be avoided
• file-backed, sequential, small-buffer designs are the sensible path

So even if the networking layer allowed more, the machine itself still argues for modest scope.

The real design questions I need help with

These are the questions I think matter most now.

1. What should the primary connection model be?

• IA TCP only?
• IA TCP first, with serial support later?
• CP/M/serial first for authenticity?

2. Should the first real target be native NABU or CP/M?

• native NABU with IA storage
• CP/M with virtual drives
• CP/M with optional CF / RomWBW deployment

3. How important is serial support really?

Do people actually want:

• real serial / RS232 support
• WiFi modem style support
• RomWBW card operation

Or is that interesting but not important compared with direct IA TCP access?

4. What level of user account system is actually wanted?

Should the BBS have:

• no real accounts at first, just caller names
• simple name plus password
• persistent user records
• access levels / sysop / co-sysop style permissions

5. How deep should message boards go?

Should the first useful version have:

• one public message area
• multiple boards or conferences
• replies / threading
• message deletion / editing
• sysop moderation tools

6. How important is private messaging?

Should private messaging be:

• not present initially
• very simple mailbox style
• a core feature from day one

7. Should there be file areas?

If yes:

• only later?
• basic upload/download areas?
• public libraries only?
• should it aim for XMODEM, YMODEM, ZMODEM, or something else?

This matters because protocol choices change how much telnet handling, binary safety, and client compatibility work is needed.

8. Should the BBS aim for plain text first, or ANSI support early?

Plain text advantages:

• simpler
• more compatible
• faster to finish

ANSI advantages:

• more "real BBS" feel
• takes advantage of the NABU terminal work already done
• more visually distinctive

9. Should local-on-machine interaction matter?

Should the BBS support:

• only remote use
• remote use plus local sysop console
• local chat with remote caller
• local moderation tools

10. What matters more - authenticity or usability?

Should the project aim more toward:

• "what an old NABU-era BBS might have been"

or:

• "what is the best practical BBS for NABU users today"

That one question probably decides everything else.

My own present recommendation

If I had to choose the path today, I would say:

• native NABU
• IA TCP first
• IA storage first
• single-user design
• plain text first, ANSI later
• simple accounts first
• public messages first
• private mail later
• file areas later
• serial support only if there is strong real demand

That feels like the best balance between:

• what the NABU can do well now
• what the active user base is most likely to have
• and what can actually be built and maintained on a 64K machine

Questions for potential users

If you might actually use a NABU BBS, I would love your thoughts on these:

[list=1]

• Would you prefer an IA TCP based BBS, or is serial / CP/M compatibility more important to you?
• Do you care about running the BBS from CP/M, CF, or RomWBW, or is native NABU plus IA perfectly fine?
• Is one active remote user at a time acceptable for a first real release?
• How important are user accounts and passwords?
• Do you mainly want public message boards, private messaging, file areas, or some combination?
• Should the first real version stay plain text, or should ANSI / colour support be an early goal?
• Is local sysop interaction on the NABU itself important?
• Would you actually use serial hardware for BBS access, or would IA TCP cover almost all real use?
• If file transfer support is added later, which protocol should be the target?
• In one sentence: what would make this feel like the "right" NABU BBS to you?

Final note

I have so many possible directions in my head at the moment that I do not really know which way to go yet.

So this is not just me asking "what feature should I add next?"

It is me asking:

"What kind of BBS should this actually be, given the NABU hardware people really use now?"

I would especially like feedback from both potential BBS users and people who may want to run a NABU BBS themselves.