A proposal for a new BBS package

[Guest]

Christian,

The 64 is not feasible.  There's simply not enough usable RAM.  The 128 makes nearly four times as much RAM available to a programmer as the 64.

[David Nelson]

Christian,

The 64 is not feasible.  There's simply not enough usable RAM.  The 128 makes nearly four times as much RAM available to a programmer as the 64.

What about a 64 with ram expansion attached?

Same for the 128, can we make use of the ram expansion? The 512k is nice. This would speed up swapping in and out of modules.

[Blacklord]

Christian,

The 64 is not feasible.  There's simply not enough usable RAM.  The 128 makes nearly four times as much RAM available to a programmer as the 64.

What about a 64 with ram expansion attached?

Same for the 128, can we make use of the ram expansion? The 512k is nice. This would speed up swapping in and out of modules.

We gotta start off by saying a firm 'no' to a 64 implementation - outta scope for a 128 package! If someone wants to fork it off later, fine, but remember, we're developing for the 128 in it's *native* mode !

cheers,

Lance

[Guest]

Also, we need to keep the REU issue in scope.  It's not simply more RAM for the 128.  It sucks RAM to use it as a drive without a RamLink, and if we choose to use it as a DMA buffer, then we have to give up the ability to use a RamLink at the same time.  To me, a RamLink is far more important than using the REU as a buffer, so we shouldn't code the BBS to user the REU that way.

JMO.
Payton

[christianlott1]

Shees.

An IO module and a formating module will leave plenty of space for a data buffer. You guys are the ones who MUST have basic swapped in.

You still haven't listed features which make a 64 port impossible, so it's useless arguing.

OK. It's YOUR project, so we'll leave it at that. I can't find a power supply for my 128 so I'll have to follow your code in VICE.

I'm mainly interested in the I/O module anyway and plan to use the PC as server and data buffer.

Good luck.

[Guest]

I've got a box full of 128 power supplies.  If that's your only beef with using a 128 then I'll send you one for $10 (which should just about cover shipping).  This is a 128 forum.  Not a 64 forum.  This is a 128 project.  Not a 64 project.  Let's please stay on topic.

[Blacklord]

Hi Christian,

You still haven't listed features which make a 64 port impossible, so it's useless arguing.

Actually, we have - (two at least that are important) - 80 column mode & 2MHz mode - resolution & speed, neither of which the C64 can provide, a third is the greater memory available to the 128, this will ultimately allow us to code way more features into the system than the C64 would.

cheers,

Lance

[christianlott1]

Hi Christian,

You still haven't listed features which make a 64 port impossible, so it's useless arguing.

Actually, we have - (two at least that are important) - 80 column mode & 2MHz mode - resolution & speed, neither of which the C64 can provide, a third is the greater memory available to the 128, this will ultimately allow us to code way more features into the system than the C64 would.

cheers,

Lance

OK.

[David Nelson]

Hello all, I had a few wild thoughts come to mind that I thought I would throw out here. I'm not sure how easy or usable any of this might be so I'm just brainstorming.

I was first thinking back to the BBS's of yesterday and what features I liked the most about them. They all had online games, file areas, and message boards. There was also user to user messages (Private messages). Where I grew up, the only Commodore BBS was a Color64. I've heard many different names recently, and even telnetted to a couple DMBBS boards. There were some Tandy boards, an Atari board, an Amiga board, and plenty of PC based boards (Lighthouse, Renegade, Wildcat, and more). I ran a PC-based board for awhile (Renegade and then Wildcat). So I've seen it from both sides.

From the user stand point, I want it to be easy to understand and navigate. I don't like having to press return very often. Some boards that allowed multi-key commands (like Renegade) automatically recognized when I'd typed one in and I didn't have to hit return. This of course required unique commands (for example, no "T" and "TR"). But most multi-key commands started with a "/", such as "/R". Maybe that was just a PC-thing. I dunno. Anyway, I liked it when help was easy to call up and clearly (but consicely) explained what did what.

From the sysop stand point, I appreciated customization, expandability, and ease of use. I don't recall any of the PC-based systems allowing the sysop to go in and get dirty modfying code. Though there might have been one that had some kind of embedded script language you could use to modify. Kinda vague on that. They all had very good editing programs for their customizations. I think just about every string could be modified in Renegade. Wildcat was commercial, so it was polished and came with impressive manuals. A friend of mine had ordered Color64 and it, too, came with some very nice documentation.

I'd like to see the new BBS be easy for a non-programmer to set up and modify to some extent. I am in love with the idea of the sysop who likes to roll up his or her sleeves and dig into the program to really customize it beyond belief.

Some other wacky ideas that came to mind were inter-connectivity between systems. Back in the day there was the ol' Fidonet. Now with the internet, it'd be so much easier. But take it a step further rather than just bouncing messages between systems. What if a sysop could have a "bbs address book". A user on system A could list and see who was online on the other address book systems and maybe chat with one (or more?) of them. I guess this would only work best if there was a program on the PC-internet-gateway running to handle this. Well on the BBS the user would just enter the inter-connect model, which talks to the PC. A glorified chat client if you will? Similar thought with bouncing messages back and forth, the PC actually does the work and the 128 just gets fed the messages when it's doing nothing but waiting for a call. What with email, newsgroups. forums, irc, etc. this may not be worth investigating. It was just one of those cool what-if ideas brought on by remembering multi-line systems from back when. Had a blast going into a chat room. Before IRC.

Speaking of which, does VICE allow more than one instance to be running at the same time? In theory if somebody is running the new BBS on VICE on a PC, could he or she set up a five-node system? Imagine the online games could be real-time. Ah this could go with the previous idea, too.

Just some wild out there thoughts. But back to basics. What are good features for the message board and file libraries. It'd be nice if the message board could be a bit like newsgroup or email readers are these days, grouping messages by subject to make it easy to navigate. Or view by date/time. Or by sender. However the user chooses to read the messages. Ditto for the private messages.

The file libraries probably haven't changed in concept since the beginning of time. There's just basically a list of libraries or categories, and within the library or category is a list of files. View the list by name, date uploaded, uploader, however.

Of course we can't forget feedback to the sysop/cosysop/staff. Did anybody ever take the time to read bulletins or news or FAQ sections? I think I did once or twice.

On the Sysop side, did the Commodore BBS's blank the screen and just show a little one or two liner (like waiting for call or who was online and what module)? And the Sysop could then hit a key to view what was going on or so forth. Wondering if that'd help speed things along on the 128 if it didn't have to draw to the screen unless the Sysop wanted to watch.

I keep coming back to the games. That's where I remember spending most of my time second to the message boards. There's been plenty of games written, is it easy to support them or would they need re-tooling? Maybe two flavors: a "compatible" way to support old games, and a "new way" to support new and advanced features. Imagine the new games that could be designed with the new features and thoughts we're throwing out here. If even only a handful of these new ideas are feasible, it's still pretty dang impressive.

One thing that concerned me though was speed. I recall toying around many moons ago and basic was just too slow. Compiling the basic (like with Abascus) was lightning fast compared. The majority of the important routines for this are going to end up being in ML, right? Will the basic parts slow it down, or will it be better to have compiled somehow? Maybe with the 128 in fast mode this isn't even an issue. I honestly haven't thought about coding on the 128 in a very long time, though I certainly have the manuals for it. lol   Those were the days. Looking forward to getting my hands dirty on it again. My last coding project was a test "training" type program for Windows with Visual Studio 2005 in C++ and the MFC. It was a headache at first, but I got it done on time. Ironically, back in the day, I use to have to flip through programmers' reference books to find the info/help. These days it's the online help (F1 to the rescue). But I think it throws back so many matches that it was actually quicker in the old days of looking it up in the book than it is now online.

Sorry to ramble on. I'm a bit lacking in exposure to the other Commodore BBS systems that existed, so please share what you think were some of the best features of them to include. And if you recall a great feature from a non-commodore BBs, that's okay, too. Maybe we can incorporate it?

-David

[Guest]

David,

Your recollections on BBS systems is much like my own.  I also agree with most of what you said about what a BBS is good for.  I've been giving a lot of thought about it, and with my recent decision to shut down Da Bored due to the amount of work involved just keeping it up, I remember why I moved to Renegade on PC a long time ago:

1) Stability - This is the most important aspect of any bbs
2) User Experience - I loved the way Renegade and other PC BBS's handled user input
3) Storage Utilization - Again, the PC was all over C= systems.
4) Interoperability - FIDO and it's bretheren were just better

I think we accomplish all of these things on the 128 with a clean sheet design that uses modern tools and techniques.  I have some very specific ideas on how we can achieve each of these goals in ways that have never before been possible on C= machines.

[Blacklord]

I think we accomplish all of these things on the 128 with a clean sheet design that uses modern tools and techniques.  I have some very specific ideas on how we can achieve each of these goals in ways that have never before been possible on C= machines.

We really do need to arrange a 'round table' talk.

cheers,

Lance

[xlar54]

Ive given this some thought and have been talking with some other folks involved in open source projects.  I was told that we need a unifying vision, and that our differences in opinion, in some ways can actually be considered unifying in other ways... consider...

We need to stop first and ask ouselves the simple question : "Why are we writing a C128 BBS from scratch?"

Because the world needs another C= BBS? No. Theres plenty of systems out there.
Because the current BBSs are insufficient? No. Some of them are actually extremely powerful and complex.
The reason I would be part of the project is simply for fun and to learn more things about the 128.

I believe most of you would agree with the above statements.  So, in the spirit of open source, why not simply focus on a very core system, one that runs on a stock 16k VDC 128.  Modular by design, so that components can be written which support any kind of hardware.   If we do this right, then anyone who wants to code for a particular piece of hardware or configuration can simply create the appropriate module, and add it to the CVS tree.

So when we talk core system - we need to REALLY drill down into what constitutes a core system.  And I believe they really include:

Module / overlay code loading
Modem I/O
High level disk I/O
Memory usage

Im sure there are others, but I think you see the point.  By virtue of the fact that there is some disagreement in this thread as to what is wanted, it should be evident that we ought to stick to a very dynamic system that any and all can write for it.

Right off the bat, I dont think we should aim for "better" or "ultimate"... I think we should aim for "open" and "modular". Best and ultimate will follow very quickly.  So back to my original point - our differences in opinion ought to unify us into setting a goal of modularity.

My $.02

[Guest]

xlar,

Now we're on the same page.

[christianlott1]

Byrd, I would need a 128 ps and an rs232 serial port. I have an 80col monitor and c128.

When you say bullitin board, all I think of is a terminal which reads information from any source. If that's from the user port or iec, the i/o module would maintain a buffer for it in free memory and display it using the UI module.

[Guest]

Christian,

No, a bulletin board is not a terminal, it's the destination.  CCGMS is a terminal.  NovaTerm is a terminal.  Terminals are used to call other systems, such as bulletin boards and dialup shell accounts and telnet servers.

If you don't have an RS232 adapter then how do you expect to get your 64 online?  Sending you a 128 power supply would be pointless if you don't have one.  Luckily, if you have an RS232 adapter, it'll work just fine (probably better) on a 128.

[christianlott1]

If you don't have an RS232 adapter then how do you expect to get your 64 online?  Sending you a 128 power supply would be pointless if you don't have one.  Luckily, if you have an RS232 adapter, it'll work just fine (probably better) on a 128.

That's why I wrote:

Byrd, I would need a 128 ps and an rs232 serial port.

I know we've all been waiting on Brain to finish the uIEC. Maybe that can be mounted on both the PC and 64/128 at the same time?

[swordfish1030]

Bump!

[Golan Klinger]

tagging in

[airship]

Golan, I think he means "BUMP", as in "Is this still an active topic?"

[BigDumbDinosaur]

What ever happened to this project?  It seems to have died from apathy.   

[Pinacolada]

Sure seems like it.

[Blacklord]

Wouldn't mind getting it back on track again myself.

[BigDumbDinosaur]

Wouldn't mind getting it back on track again myself.

The question would be: would anyone use it?  Plus, would it be Commodore-specific or be able to accept connections from non-Commodore machines without giving rise to funky display issues?  Also, on what would the software and such be stored?  What about connectivity?  Is anyone still willing to devote a phone line to incoming traffic or would this strictly be a Telnet setup?

[quarkx]

Its a cool Idea, but let's face it, less and less people even have a land line anymore. I have not had one since 1999, since I got my first Cell phone. If there some way to have it on the web, but only have it accessible by 128, that would be cool.

[Mark Smith]

So why not skip doing a BBS and do a webserver ?   They are after all the modern day BBSs :-)

Could always use GEOS for the platform as it gives you the basic APIs for disk, REU, screen etc.
Develop in C using CC65 and you can "easily" (he says in an off hand manner) use uIP for the network access, ASM could then be used to optimise areas as required once the main framework is built.
Once the basics are in addressing the problem of more storage would be a case of doing a GEOS driver for the uiec or any of he other SD-card products (like MMC64/MMCReply, 1541U and so on) .. apparently there is a proof of concept driver in existence http://www.c64-wiki.com/index.php/sd2iec_(firmware)#Is_GEOS_supported.3F

Just a thought.

Mark