Guys,

What are your thoughts about creating a new BBS program for the 128 ?

My thoughts :

* Although it should run on a stock 128, it should have the ability to take advantage of extra features available by using an emulator such as VICE.

* Ability to network with other like boards

* Fidonet ?

* Open source

* Modular to allow easy additions to the system

* Capable of integrating with an SQL DB if run under an emulator - this would allow such a system to easily mesh with forum software running on the host

* Backwardly compatible with other systems to give it some doors to start with

Just to start with.....


Lance

Im with ya

I think open-source is key. One other feature that I think is really important is BASIC program overlays for doors, much like CNet. And rather trivial to implement as well.  SQL would be rather interesting, but obviously make running on a stock 128 pretty difficult unless there is some kind of interface.  But, you could write a SQL-like driver that would utilize binary data and index files, so that it could be swapped out for real SQL.  Heck, if we layer it right, all BBS subsystems could be swappable.

I like the idea. Could turn out to be an awesome project. Count me in if you guys really want to do this.  Anyone looking to do some ML and BASIC coding, this would be interesting (and even some CC65 if we can work it in)....

Quote from: xlar54Im with ya

I think open-source is key. One other feature that I think is really important is BASIC program overlays for doors, much like CNet. And rather trivial to implement as well.  SQL would be rather interesting, but obviously make running on a stock 128 pretty difficult unless there is some kind of interface.  But, you could write a SQL-like driver that would utilize binary data and index files, so that it could be swapped out for real SQL.  Heck, if we layer it right, all BBS subsystems could be swappable.

I like the idea. Could turn out to be an awesome project. Count me in if you guys really want to do this.  Anyone looking to do some ML and BASIC coding, this would be interesting (and even some CC65 if we can work it in)....

To do this we need to assemble a team of programmers & then farm out different parts of the project. Obviously, VICE needs some re-hashing as well with the known RS-232 issues, but the groundwork there has already been partly done anyway.

Volunteers ? Comments ?

Lance

Agreed. I think the first steps would be to put together a project proposal/contract, outlining all the core features that the initial release should contain.  things like:

Core features of the BBS, taking into account current technologies (interfacing with WWW, etc)
Common code routines which should be accessible to all modules
Language standards (ML, BASIC, C) etc for each module
Disk access standards (How we will store/read data, format, etc)
Minimum system requirements (this becomes a performance target)
Protocols (CBM/CG, ANSI, file transfer protocols, 40/80 columns lines, etc)
Some idea of adminstration tools / user account groups and management

Where I work, we gather up this info as a simple top-level design document, and begin to expand on it, getting more and more detailed and granular until there is enough detail to start divying up the work load, and then people can usually begin coding.

This also gives us the opportunity to hunt down all those elusive hacks and tricks on the 128, in order to do some really cool things. (Such as using a RAM disk if the VDC has 64k, to cache various things - most people read newer posts rather than older ones, so why not cache them in RAM?) I also remember seeing some code which would allow you to have 2 VDC screens, each independant of each other - Im sure theres use that could be made of that.  CNet would even let you drop to a BASIC interpreter while INSIDE the BBS. The 128 can do some cool things for sure.

Just some thoughts. I think this would be a very good project.

Quote from: xlar54Agreed. I think the first steps would be to put together a project proposal/contract, outlining all the core features that the initial release should contain.  things like:

(much deleted)

I can put together a project CVS page, I think the main thing is getting people interested in the project first though, that'll be the main battle.

cheers,

         Lance

May I suggest a few things?  Good.

[ul]
[uli]Have the BBS use a protocol to communicate with the PC.  This protocol could be implemented a Java class that extends TCPSER4J and gives the BBS the capability to query the PC for data.  The BBS would not send data directly to the client, but instead send commands to the Java class that would then be interpreted and sent to the client.[/uli]
[uli]Write it in CC65 for speed[/uli]
[uli]Don't worry about how the BBS looks in the C128, it's just a traffic cop.  The Java class can be responsible for translating the codes into the correct output (PETSCII, ANSI, ASCII, ATASCII) based on the type of connecting client.[/uli]
[/ul]

Hmm, for some reason BBCode isn't working.

Quote from: plbyrdMay I suggest a few things?  Good.

Have the BBS use a protocol to communicate with the PC.  This protocol could be implemented a Java class that extends TCPSER4J and gives the BBS the capability to query the PC for data.  The BBS would not send data directly to the client, but instead send commands to the Java class that would then be interpreted and sent to the client.
Write it in CC65 for speed
Don't worry about how the BBS looks in the C128, it's just a traffic cop.  The Java class can be responsible for translating the codes into the correct output (PETSCII, ANSI, ASCII, ATASCII) based on the type of connecting client.

Sounds fairly much along the lines of what I have in mind - each display protocol could be a module that could be enabled by the individual sysop though so that if a particular protocol was not wanted/required by the sysop then it would not be swapped in (probably important on a limited memory setup on a real machine).

Lance

Is there a risk that the package might be developed soley for an emulator and end up locking out users of the real hardware ? If so, why not just develop a CSG BBS package for the PC ?

Quote from: plbyrdWrite it in CC65 for speed(

That might block out a few developers though, wouldn't BASIC be better, at least initially, then maybe port it later ?

There is no porting from BASIC to CC65.  And if you use BASIC you will have to write a bunch of it in ML.  CC65 would greatly reduce (if not eliminate) the need for ML.

Last year I took apart most of the Kwik Load program, all except for the complex disk routines.

So, if you guys like the interface and think it'd be cool to expand it - I'd love to have a project to work on.

You would have a menu screen, a track/sector hex/ascii editor, and a few other utilities to tweak right off the bat with commented source.

The menu uses a list of tokens and it's easily customizable.

I think it'd be really cool to set up a sql database backend for it.

Using basic would be too slow. I think ml would be the only way to go - at least for a core menu system.

Some opinions...

The code should be BASIC and ML, although CC65 could be used to write some ML portions (protocols, etc). Ive checked some of the assembly it emits, and its not too bad (having the assembly it emits is a major plus in using it).

We should include a BASIC overlay system like CNet.  Easily allows for "doors" and other subsystems. We can create wedge commands that call input and output functions in ML (2028 OUT "Press any key", etc)

I LOVE the Desterm windowing menu system. Getting around via the mouse rocks.  Id like to see the Sysop screens using something like this.

Least common denominator. The thing should run on a stock C128 16k VDC. BUT... the alternate subsystems (see above) should be written to take advantage of the various pieces of hardware out there, including harddrives, maybe even XE-type cables, and virtual ones like VICE.

So, if we are going to do this, I think we will need folks for:

1 - Development! ML, BASIC, C...whatever you speak. We also need folks who are knowledgable about the 128 in general such as memory management, disk routines, etc.  We will need to divy up the work based on knowledge, skillset, and desire.

2 - Testing.  If you arent too keen on coding, maybe you can help test.  This will keep development moving forward instead of being slowed down by double duty.

3 - Organization.  We will need folks to help organize gatherings so we can discuss the project and keep it moving, as well as maintain a development plan and status.  Additionally maintaining a website, etc for the project, and passing bug reports from the testers to the developers.

4 - Ideas! If nothing else, send in your ideas on what would make this THE best BBS for the 128.

5 - Ugh... Documentation.... Yeah, its not a glamour job, but no one appreciates documentation more than the user. Makes a good system a great one

6 - User Interface & Design.  The "stock" release, plain vanilla as it may be, will need nice menus, colorful screens, etc. What the sysop screens will look like, how it will flow, etc.

Sounds alot like work, and it is... but I think it would be well worth it.  Where do you think you could fit into the roles listed above?

As for me, Ive done a little of all, and could jump in where needed, although I dont have a vast knowledge of the inner workings of the 128 (memory management, etc).

We might want to set up a forum specifically for the new BBS. This thread is getting long...

Anyway, I started playing with some code, writing a config type of program for the BBS. Right now it doesnt do much of anything, except menuing routines.   Lance, can you also create an upload area for files specific to the BBS?  If so, Ill send what I have.

And it needs a name. In the config program, Im calling it "Red Dragon BBS", but its just a placeholder.  Anyone have any ideas for a name?

I wrote it on the c128, not an emulator, which was rather cool. Ben a loooooong time since I really sat down and coded on a 128.

Some other ideas for names:

Red Dragon BBS (mythical)
Omega BBS (the last BBS)
Citadel BBS (mythical)
128NET BBS (8 bit net)
InterCom BBS (obvious)
CBBS

Quote from: xlar54We might want to set up a forum specifically for the new BBS. This thread is getting long...

Done, file area to follow (will link directly to these areas).

Lance

Quote from: xlar54So, if we are going to do this, I think we will need folks for:

1 - Development! ML, BASIC, C...whatever you speak. We also need folks who are knowledgable about the 128 in general such as memory management, disk routines, etc.  We will need to divy up the work based on knowledge, skillset, and desire.

2 - Testing.  If you arent too keen on coding, maybe you can help test.  This will keep development moving forward instead of being slowed down by double duty.

3 - Organization.  We will need folks to help organize gatherings so we can discuss the project and keep it moving, as well as maintain a development plan and status.  Additionally maintaining a website, etc for the project, and passing bug reports from the testers to the developers.

4 - Ideas! If nothing else, send in your ideas on what would make this THE best BBS for the 128.

5 - Ugh... Documentation.... Yeah, its not a glamour job, but no one appreciates documentation more than the user. Makes a good system a great one

6 - User Interface & Design.  The "stock" release, plain vanilla as it may be, will need nice menus, colorful screens, etc. What the sysop screens will look like, how it will flow, etc.

Sounds alot like work, and it is... but I think it would be well worth it.  Where do you think you could fit into the roles listed above?

As for me, Ive done a little of all, and could jump in where needed, although I dont have a vast knowledge of the inner workings of the 128 (memory management, etc).

I can volunteer to help out on 2,3,4 & 5

Lance

I'll volunteer for 1 - ML.

I don't like c64 basic and I only know C from an intro course from a book.

I am getting around okay in VB.NET and SQL Server 2005, so server side / PC side apps are cake.

I assumed from the intro that this ware would be modularized. I'd like to see a diagram or list of all the components you can think of for a base system. That way we can split up the tasks and take on the ones we all feel are most important.

Desterm is cool but I figure I can ferret out the modules in the larger project to make my KL thingy work too.

Maybe we should tag name each module. That way if I want to use the KL interface I'd say something like - ' using module XYZ from the 128bbs project '.

Front End
- UI

Back End
- Server

and somewhere in the middle:

PC side I/O
C64/128 side I/O

Excellent.  I have the overlay code done, but it really needs translated into ML for speed.  Feel like taking a crack at it?  Ill post it on the board soon (Im out of town right now).

Overlay code?

The c64 i/o code? In basic?

Sure. I'd love to. However, what interface did you say you were using? rs232?

I have not used it yet and I don't have the hw. This is something else I was thinking about - what hw setups will be supported?

Anyway, it can be tested through VICE and someone with the real hw can test the code.

(I hope I understood your post.)

I'm getting a new apartment, so I'll be moving this coming week.

I'd also like to mention this thread:

http://groups.google.com/group/comp.emulators.cbm/browse_frm/thread/46aea5d56777321b?tvc=1&q=rs232

I have many books dealing with rs232, including the 'toolkit' books. I just haven't (until now) had reason to invest time learning it.

The overlay code is to allow us to load in different BASIC modules at runtime.  So, you can have an email subsystem, a message board subsystem, UD, etc, and each sub being its own BASIC module.  Doors / games can also be their own BASIC modules as well.  There is a main BBS BASIC module, that loads in and out these subsystems as the user makes menu choices.  This is the way CNet 64/128 work, along with some others, but I/O and other things that require speed are all done at the ML level.  There's still some discussion as to if this is how we want to go, so hang on until we can meet to talk things over.

As far as hardware goes, thats another thing we will need to refine - what are the basic hardware requirements for the BBS.

Quote from: xlar54The overlay code is to allow us to load in different BASIC modules at runtime.  So, you can have an email subsystem, a message board subsystem, UD, etc, and each sub being its own BASIC module.  Doors / games can also be their own BASIC modules as well.  There is a main BBS BASIC module, that loads in and out these subsystems as the user makes menu choices.  This is the way CNet 64/128 work, along with some others, but I/O and other things that require speed are all done at the ML level.  There's still some discussion as to if this is how we want to go, so hang on until we can meet to talk things over.

As far as hardware goes, thats another thing we will need to refine - what are the basic hardware requirements for the BBS.

Will it be 64/128 compatible or will there be two kernals?

Last year I had the ACE kernal and subprograms printed and bound. Now would be a good time to unearth those bad boys and see what applies as we develop.

Well, everything Im saying right now is opinion But, I would say that this will be a 128 specific system, in order to take advantage of the 128s advanced capabilities.  You could probably take it backwards and re-engineer it for the 64.  Is there a specific reason you want a 64 version?

Hello, I'd be more than willing to help out here:

1. C, C++, VB, Basic, dabbled in ML. (Been awhile since I played with my 128 though)

2. I love to test.

4. Ideas

5. Documentation - I can write, and I don't mind the tediousness of it. It's got to be done, and as an end user I'd want very good documentation so I can figure out how it works.

6. UI. Fun stuff!


Something just came to mind. Using the RS-232 routines and such -- we are planning to program to directly talk to a PC or some other ethernet-enabled device and not a modem, right? Would a stripped-down and simplified TCP/IP stack be too much of a hurdle for the 128 in fast mode? To talk to a local network, or dumb ethernet device, to talk to a gateway PC and let the gateway PC handle the heavy burdens of connection management?




-David

Quote from: christianlott1Will it be 64/128 compatible or will there be two kernals?

There aren't any plans to develop a 64 version (see my post elsewhere as regards that, it'd mean trimming it down & dumbing it down somewhat to fit the 64's lesser capabilities - this project is designed to take full advantage of the 128's more advanced capabilities - of course, being open source, there's nothing stopping someone from nuilding a 64 fork.

cheers,

Lance

Quote from: xlar54Well, everything Im saying right now is opinion But, I would say that this will be a 128 specific system, in order to take advantage of the 128s advanced capabilities.  You could probably take it backwards and re-engineer it for the 64.  Is there a specific reason you want a 64 version?

OK, guys - I like the 128 and the vdc just as much as everyone else. I also think it'd be a great setup just through VICE.

I think this is doable for the 64 though. I'm not sure all the features you have planned for a base implementation but what I see is this:

I/O module, UI module and some free memory for the data buffer.

I'm just waiting to see the I/O working.

The two I/O paradigms being - rs232 and IEC.