Amiga Retro Brisbane

Retro Corner => General Retro Computing Chatter => NABU PC => Topic started by: intangybles on March 27, 2026, 10:37:39 am

Title: NABU BBS Project - Direction Notes and Questions for Users and Hosts
Post by: intangybles on March 27, 2026, 10:37:39 am
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:


In practice, those systems were usually built around:


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:


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:


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:


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:


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:


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:


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:


Advantages:


Disadvantages:


Option 2 - Native NABU plus IA TCP plus IA storage

This is the direction I have prototyped so far.

Advantages:


Disadvantages:


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

This is the compromise idea.

Advantages:


Disadvantages:


My current view

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

Why:


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:


We also now have a working native prototype that:


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

The IA TCP server API appears to expose:


What it does not appear to expose is:


That matters a lot.

At the moment, this strongly suggests:


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:


So my present answer is:

What about memory limits?

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

IA storage helps with:


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

The practical implication is:


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?


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


3. How important is serial support really?

Do people actually want:


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:


5. How deep should message boards go?

Should the first useful version have:


6. How important is private messaging?

Should private messaging be:


7. Should there be file areas?

If yes:


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:


ANSI advantages:


9. Should local-on-machine interaction matter?

Should the BBS support:


10. What matters more - authenticity or usability?

Should the project aim more toward:


or:


That one question probably decides everything else.

My own present recommendation

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


That feels like the best balance between:


Questions for potential users

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

[list=1]

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.