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. :P
[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. :P
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.
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.
Quote from: plbyrdChristian,
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.
Quote from: dnelsonflQuote from: plbyrdChristian,
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
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
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.
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.
Hi Christian,
Quote from: christianlott1You 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
Quote from: adminHi Christian,
Quote from: christianlott1You 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.
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
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.
Quote from: plbyrdI 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
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
xlar,
Now we're on the same page.
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.
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.
Quote from: plbyrdIf 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:
QuoteByrd, 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?
Bump!
Quote from: swordfish1030tagging in
???
Golan, I think he means "BUMP", as in "Is this still an active topic?"
What ever happened to this project? It seems to have died from apathy. :)
Sure seems like it. :(
Wouldn't mind getting it back on track again myself.
Quote from: Blacklord on November 09, 2009, 12:49 PM
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?
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.
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 (http://www.c64-wiki.com/index.php/sd2iec_(firmware)#Is_GEOS_supported.3F)
Just a thought.
Mark
Quote from: quarkx on November 10, 2009, 03:39 PM
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.
You can use a Lantronix or similar serial to ethernet device to get it online. That is how some old BBS software was connected to the Internet and able to take incoming "calls" as well as place outgoing "calls". Takes a little effort of reading the instructions to get it set up the first time, but it works very smoothly once configured.
Quote from: BigDumbDinosaur on November 10, 2009, 02:13 PM
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?
It would not break any traffic records for world's busiest site. It would probably only be visited occasionally by die-hards such as ourselves. Your other questions come down to what is available and affordable. Maybe something as simple as a C128 with a disk drive and serial to ethernet adapter to be available online. Dynamic DNS can be used to set up a path to the computer.
-David