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

[tschak909]

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

 

-Thom

[_The Doctor__]

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.

 

 

[tschak909]

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

 

 

[+DrVenkman]

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. 

[tschak909]

@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

 

[Kyle22]

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

Thanks for your input.

 

[tschak909]

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

[phigan]

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.

[Tillek]

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!

 

 

[cathrynm]

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 February 19, 2021 by cathrynm
typo

[tschak909]

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 February 19, 2021 by tschak909

[_The Doctor__]

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...

[tschak909]

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

 

-Thom

[Kyle22]

@_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].

 

[tschak909]

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 February 24, 2021 by tschak909

[+David_P]

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...

[tschak909]

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 February 24, 2021 by tschak909