Jump to content
tschak909

It's possible to write a BBS using N:, does anyone care?

Recommended Posts

Just as the subject says, it's possible to write a BBS using the N: device. Does anyone actually care?

 

-Thom

  • Like 2

Share this post


Link to post
Share on other sites

would this make the BBS faster or more reliable in some way?, I was considering the idea for file bases at first. I mean currently when you put all your files on and a person accesses your tnfs server they can pretty much get everything you have... which is ok... but putting this stuff behind a username and password, knowing who is getting what and having a u/l ratio is still the original experience.

Using a dragon cart I used the 8 bit to serve some web pages, and played about using the 8 bit as a telnet server, but never used it as the actual BBS communications device. I had considered using it to say who was online or if it were down or up, you know status readout provided to the web, showing bbs ip as well (for those who don't dns.

 

 

Share this post


Link to post
Share on other sites

Definitely easier to deal with, since we're dealing entirely with network sockets. No mess with switching to and from concurrent mode, etc.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Well, I can’t seem to get the N: device to work at all currently despite it formerly working when I first tested last summer so personally I don’t care until I figure out why it’s not working and how to fix it with my servers. 

Share this post


Link to post
Share on other sites

@DrVenkman we'll have to break that out into its own thread. I completely rewrote N: and right now, I do agree that the only things that work in N: stably are the TCP and UDP adapters. Everything else is in flux, and I keep getting pulled to handle other issues.. ;)

 

-Thom

 

  • Like 2

Share this post


Link to post
Share on other sites

This would be AWESOME. Could BBS Pro! modules work, or do we need to write a whole new system.

Thanks for your input.

 

Share this post


Link to post
Share on other sites
2 hours ago, Kyle22 said:

This would be AWESOME. Could BBS Pro! modules work, or do we need to write a whole new system.

Thanks for your input.

 

It works completely different from R: (it's packet driven, but has none of the problems of R:), so since the source code isn't available for BBS Express! in any form, a new BBS would need to be written.

-Thom

  • Like 1

Share this post


Link to post
Share on other sites
On 2/2/2021 at 7:32 PM, tschak909 said:

Just as the subject says, it's possible to write a BBS using the N: device. Does anyone actually care?

 

+1 for caring.

 

I started writing out all the requirements for a super simple BBS. Then I opened the N: wiki page. That's as far as I've gotten, though.

Share this post


Link to post
Share on other sites

The real questions is.... Will it have the nostalgia factor?  Everyone will say that they care.... as long as someone else is the one doing the work, right?

 

That's the main reason people love BBS's... the nostalgia factor.  Would a new BBS project that is "just the basics" really attract anyone's attention beyond the "that's cute, call once and never again"?

 

My personal opinion?  It would be more beneficial to focus on the R: device working with existing software.  Or more importantly, working with existing terminals.  It's something I've said over and over... the last thing the "Atari BBS Community" needs is MORE BBSs until we have a lot more "users" to actually call them.  Resurrecting "classic" BBSs from back in the day is also good, but new BBSs?  Just don't know.

 

It's not like we have a user base like Particles! ;)

 

 

Share this post


Link to post
Share on other sites

For server-side Atari 8bit,  R: and its 'concurrent mode' is kind of screwy, limited by its original design back in the 1980's.  I don't know, is there a way to fix R: so  it'd just ignore the concurrent mode calls and work normally?  I think so, but as Thom often says, someone will have to do that work.

Edited by cathrynm
typo

Share this post


Link to post
Share on other sites

Concurrent mode (SIO command 'X' - STREAM) is a trick that is handled at both the handler and firmware level.

 

When an 850 receives a STREAM command, as part of that stream command, it sends a dump of bytes back to the Atari that are expected to be written to POKEY. These set the appropriate baud clock rate. At this point, the handler immediately swaps out the serial IRQ routines for routines that are present in the handler, which take over the bus, with only the purposes of grabbing received bytes from the RX shift register into the RX buffer, and to send any pending TX byte(s) out to the TX pokey shift register. At this point, there is no SIO protocol, it's just raw serial data, and it acts very much like an R-Verter (just a level shifter on the SIO port). 

 

A LOW assertion on the COMMAND pin will immediately shift the 850 out of STREAM mode and put it back into SIO mode. Because only the Atari can assert this pin, this must be done from the handler by closing the IOCB.

 

BBS and comms software over R: must do a delicate dance of keeping track of whether concurrent mode is active or not, and to properly open, set stream, and close when needed.

 

You have to signal when the serial bus needs to just stream data from the modem, and when it needs to pay attention to the SIO traffic, which are also often at two different baud rates, and even if everything were at the same baud rate, you still have to signal when to act like a modem, and when not to.

 

The PBI based serial ports (e.g. MIO, Black Box, etc.) could afford to ignore all of this shit. As a serial device, I can't.

 

You could PROBABLY work around this with a totally rewritten handler. *shrug* :)

 

This is why I deliberately did not put a stream mode on N:, as in the end, we are dealing with packets, and I opted instead to use one of the interrupt lines (PROCEED) to signal to programs or handlers using the N: devices ($71 to $74) that there is received data to be dealt with. It does come at a price of  small bits of transmitted data incurring a high setup cost. (is this another solid reason for rewritten SIO routines?)

 

-Thom

Edited by tschak909
  • Like 1

Share this post


Link to post
Share on other sites

the sx212 and other r: verter handlers might be best folded int the 850 handler to correct and/or be shoehorned for some things... I think some folks also posted how to switch the 850 with methods of upload code or direct mode ... more than likely @warerat ? would have had something to say or post about it. Pretty sure he'd be able to comment one way or another, no one says you have to use the exact 850 handler. You might offer 850 strict mode and fujinet mode R: handlers...

Share this post


Link to post
Share on other sites

You're not understanding what I explained above... I guess I need to find another way to explain it...

 

-Thom

Share this post


Link to post
Share on other sites

@_The Doctor__ This isn't about the 850. It is about packets vs concurrent mode.

 

I would welcome a BBS based on the N: device. It has been too long since I have coded, and I have the store now, so not much time available.

If anyone wants to take this on, I'll test it on my Incognito [WHEN I get video fixed].

 

Share this post


Link to post
Share on other sites

Basically, if any N: based BBS would be done, I would implement it as a set of loosely coupled loadable files, under a simple "BYE" like handler. It wouldn't matter what they were written in. You'd pick a starting point and connect the pieces together as seen fit.

 

The only solid limitation would be that the Atari itself could only handle one caller, if for no other reason than memory and multitasking would be hell, but you could forward a connection. ;)

 

There really wouldn't be a need for something convoluted like AMP on FoReM XE Pro or MOE on Carina, everything would be done by just reading and writing to N:.

 

-Thom

Edited by tschak909
  • Like 1

Share this post


Link to post
Share on other sites

If you designed it from the ground up (and had chops I don't have) why not have $4000-7FFF for each user, paging between up to 5 simultaneous users (130xe)?  Master control program $8000-BFFF; scratch RAM from LOMEM to $3FFF?

 

Of course, you're limited to specific modules+user data not exceeding 16K combined, which would be a challenge...

  • Like 1

Share this post


Link to post
Share on other sites

That would make the resulting design and implementation extremely non-accessible, imho, but, take a whack at it. :)

 

I would be going for something simple, where the individual pieces could be written in whatever desired, and combined together as desired, with a simple supervisor.

 

-Thom

 

Edited by tschak909
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...