New Atari BBS software.

[tschak909]

Hey guys,

 

I've been deciding to give CC65 a work-out, and figure out exactly what it can and can't do.

 

To this end, I'm writing a BBS. One that isn't a pasta-fied mess of Atari BASIC or OSS BASIC XE; that runs atop SpartaDOS X, and can thus utilize setups like the Ultimate1MB, the SIDE interface, etc.

 

I am starting out small, right now doing all the menial tasks of writing the logger, wrappers for the serial routines, fleshing out the configuration structures (one byte at a time, lots of bit field packing), but hopefully this can grow into something useful.

 

Why CC65, and why not something like ACTION!?

 

Well, I wanted to use a modern language, with structs (with the ability to have pointers to structs), and all of the niceties of a decent C implementation, while having a linker that could output a _very_ flexible binary structure. This is being developed on disk, but it could potentially end up as a very large banked cartridge, when it's all said and done, who knows? I wanted the leg room...

 

...also the libraries for serial communication and extended memory addressing are pretty well defined, well enough to be able to write something like a BBS package, so who knows where this would go?

 

Does it have a name? Not yet. When it comes to me, i'll name it, until then, I code.

 

What features will it have? Who knows, I am writing this, one piece at a time, just seeing what's possible.

 

I am pushing code to github for it, here: https://github.com/tschak909/ataribbs

 

. o O (even my bits of mental cucumber, palette cleansers to distract from long running big projects, are in an of themselves, big...Am I insane? Only my cats know for sure.)

 

-Thom

[Albert]

This is of interest to me, since I ran an Atari 8-bit BBS for several years, using Carina and then Carina II software (which is, as you state, a "pasta-fied mess" of Atari BASIC and Assembly). You might be a bit insane, but that's okay.

 

..Al

[tschak909]

Cool.

 

I'm liking CC65, so far. It has hooks for serial drivers, which can be extended, or changed to be better (as all the source is available, and the drivers themselves are in assembler.).

 

There is also good extended memory support (Shawn Jefferson wrote a 130XE banked driver that I can extend to support up to the 1088K RAMBO XL on the U1MB, which, would be a lot of wonderful breathing room.)

 

Right now, I am trying to go slow and deliberate, as I am still very new to this compiler, and I've already had quite a few crashes as I stumble through writing the log and serial wrapper code (thankfully, I am developing on Altirra, I can drop into the debugger and see what happened..it's not as seamless as doing say, C++ in gdb or Visual C++, but it's good enough.)

 

Just what is on the github right now, compiles to about 8K, so I am _really_ gonna have to be careful. I may have to get rid of all my nice error messages for the console, and just use error numbers, for example, and a manual.

 

It's a wonderful challenge to try and keep things tiny, when I spend the majority of my time building multi-million line codebases either for a living, or for long term open source work. If anything, this will be a great mental cucumber.

 

-Thom

-Thom

[+bf2k+]

Looking forward to this...

[AtariGeezer]

If you want to take a look at some example code in cc65 for a BBS, check this out:

https://bridgebbs.codeplex.com/releases/view/116598

 

I stumbled across this yesterday while looking for other Atari BBS's, it's for the C64, Atari and Apple II...

[TXG/MNX]

This is a great topic.

 

Will you make an option to read/import PRO! BBS messages into this BBS ?

Secondly I just read that Altira 2.50 has DragonCart support, would you embed support for IP/65 (a small tcp/ip stack) in this BBS, modems and analog lines are getting outdated.

 

Is there a changelog / todo / bugfix list?

Are you planning to support plugins ? BBS PRO! and some other boards had something like that.

 

I got more questions but it's enough for now :-)

[tschak909]

Geezer: yup, I've been looking @ the Contiki BBS code that is in the git repo. Definitely interesting.

 

TXG/MNX: I need to put a task list/changelog somewhere. Under sourceforge, this was easy enough, not sure how to handle this under github... any ideas?

 

re: Dragon Cart: yup, Altirra has support for that now, it would be interesting to write a driver for it. As this is orthogonal to the CC65 serial drivers, it would definitely bulk things up a bit..but I would like to see this.

 

For myself, my original intent was to run R: emulation in Altirra, and connect to it via TELNET.

 

As for the features.. I really am taking this, one small step at a time. While I am a professional programmer, have worked on a few open source projects in my spare time, and have used and run more BBSes than I can count, for myself, this is very much a clean slate, I am trying to see what is ultimately possible with CC65, and lessons that have been learned, since the time of AMIS, FoREM, BBS Express! etc..

 

As such, I have no plans for conversion tools. The code for this BBS is completely open, and will always be open, both in terms of the code, and the collaboration process, so if somebody wants to make a conversion tool to deal with whatever sprouts out of this, awesome, i'll fold it in.

 

This is ultimately coming out of a want, for a BBS that isn't a massive pain in the arse to set up, or a pain in the arse to add features to. It came out of a reaction to seeing FoREM XE code after 25 years of being away from Atari BASIC, and shrieking in terror at just how unmaintainable it is.

 

It is also very much a learning experience for me, as I have to _make_ myself think small. I have already had to throw away chunks of code, because I made assumptions that don't fit well on an 8-bit machine (And I know this will continue)

 

Every individual BIT counts. And I've found that keeping things to a well defined feature set, and doing those features well, ultimately makes for something that people will enjoy to use, to take apart; to make better.

 

For now, I want this to get to a functional point. Then we can start thinking on what to bolt onto it. I'm glad that there are people excited. I just want to be able to sustain development and not have this thing collapse before I even get it running

 

(sorry, it's the old man in me speaking...)

 

-Thom

[Android8675]

Hey guys,

 

I've been deciding to give CC65 a work-out, and figure out exactly what it can and can't do.

 

To this end, I'm writing a BBS. One that isn't a pasta-fied mess of Atari BASIC or OSS BASIC XE; that runs atop SpartaDOS X, and can thus utilize setups like the Ultimate1MB, the SIDE interface, etc.

--snip--

What features will it have? Who knows, I am writing this, one piece at a time, just seeing what's possible.

 

I am pushing code to github for it, here: https://github.com/tschak909/ataribbs

 

. o O (even my bits of mental cucumber, palette cleansers to distract from long running big projects, are in an of themselves, big...Am I insane? Only my cats know for sure.)

 

-Thom

 

Don't know if you're open to suggestions, but I would like to put in a request for a Tree based messaging system (when/if you start taking requests). This is something I'd write if I could remember how to code, or if I ever decided to re-learn, but I'm a foster dad now, it's difficult to find free time.

 

Basically instead of a linear message forums you have 1 message that's the base of the tree, then you're topics appear as responses to that 1 message, then those x topics have responses that are more specific messages based on that topic, and all those messages have responses, etc.

 

As i recall the easiest way to implement is to have each message numbered, and pointers that point to the message above that message, as well as messages to the left and right.

 

So for example:

Message#:

      1
    / | \
   2  3  4
  /|\
 5 6 7

So message #2 would point Up to 1, Right to 3 (optionally Left to 4), and with replies to 5, 6, and 7.

 

Each user has a pointer that points to the highest message read so they can easily do a N>ew Scan to read messages posted since they last came on.

 

Seriously, if you want money to help with this, let me know.

 

http://en.wikipedia.org/wiki/B-tree

[tschak909]

Yup, a b-tree messaging system would be interesting...

 

On another note, I've had to switch to SpartaDOS 3.2g for testing the builds, because SpartaDOS X _DOES NOT_ like the way the current memory map is set up, once my binary gets past a certain size (9K), it goes off into the weeds and crashes horribly, the same binary works just fine on SpartaDOS 3.2, though.. I wonder if it's because of OSRAM vs BANKED, or what not... The only thing I will mention is that I am currently just using the Atari memory model, instead of the Atari XL memory model...this may change though.

 

http://cc65.github.io/cc65/doc/atari.html#ss3.1

 

Serial port is now loading, and port is being opened. Am now writing the first worker routine for serial port input, SendAndReceiveResponse(sendStr,recvStr).

 

Pretty simple and straightforward. Send String (serial driver behind takes care of switching on/off concurrent mode etc.), start timer, wait for bytes, throw each byte received into buffer until CR is reached, if timeout happens before then, kill timer, and error, otherwise when CR received, compare recvStr to what was received, if it matches, kill timer, return true, otherwise kill timer, return false.

 

-Thom

[tschak909]

I am stuck at the moment, debugging why I am getting garbage back in my responses:

 

it's acting like one of two problems:

 

* incorrect pointer math for string manipulation, or

* wrong baud rate...

 

I'll get it but..grrr..need to take a break

 

-Thom

[tschak909]

I had to adjust MEMLO on the linker configuration ,because with the RS232 driver loaded, it was bumping up against code.

 

Also, managed to verify that I was at least talking to the port correctly, just need to tweak the response comparator.

 

-Thom

 

btw, I am regularly pushing all my code changes to github, if anyone has comments etc, please let me know.

[TXG/MNX]

Would be nice when the software would detect certain hw setup and load the correct modules, this would save memory, instead of load drivers that are not needed.

Will the BBS support plugins? This would make it also possible for other people to write functionality that can be used. This way you can work faster on the BBS core engine.

[tschak909]

I would like to, but have to get things bootstrapped, first.

 

-Thom

[kogden]

CC65 doesn't seem like a bad choice. I wonder if it'll perform any better than compiled TurboBASIC? What was the advantage of using the BASIC XE/BASIC XL carts compared to compiled TurboBASIC with a lot of the BBS packages? Lower RAM usage?

 

--Kevin

Edited July 29, 2014 by kogden

[tschak909]

I can already tell you, the compiled results of average code are comparable to Action!, and if I need better performance, I can always drop straight to assembler.

 

The advantage? Turbo Basic XL wasn't really known at all, outside of Europe. And most everybody who wrote BBSes were not professional programmers, but hobbyists trying to make things work, so BASIC was the logical choice. Basic XE was ultimately used for FoREM XE because the programmer wanted a cheap way to get lots of program RAM.

 

I see a _lot_ of advantages with CC65, and a lot of work has gone into making something that would work well for this type of application, I hope I can figure out the various memory issues which prevent it from working well in SDX, as I _really_ want to use 512 byte sectors, and advanced SDX calls.

 

-Thom

[flashjazzcat]

Are you using "X" to disable the library (the ROM at $A000) when testing with SDX? This is the usual source of conflict.

Edited July 29, 2014 by flashjazzcat

[tschak909]

good point. Will try that. derp.

 

If I do 'X', do I not have access to SDX routines, etc? e.g. how would I handle 512 byte sector read/write?

 

-Thom

[flashjazzcat]

If I do 'X', do I not have access to SDX routines, etc? e.g. how would I handle 512 byte sector read/write?

 

Just call the CIO/SIO as you normally would. The library is only required for native SDX relocatable binaries (written in pure assembler) which make external symbolic references, none of which is particularly relevant to a CC65 executable. However, there are still ways to get at symbols from a regular "EXE" application. Drac030 and the SDX programming docs are the definitive points of reference.

 

I shouldn't think you'll need to worry about the sector size (i.e. make direct SIO calls) anyway in a BBS program. File system will handle it all transparently.

Edited July 29, 2014 by flashjazzcat

[IndusGT]

Still wish the Puff Board was around. Looks like the program is lost forever. it was multi line, written in basic but fast and also supported the multiplexer

[Alfred]

Still wish the Puff Board was around. Looks like the program is lost forever. it was multi line, written in basic but fast and also supported the multiplexer

 

I don't think it's gone. Bob might have a copy and I know I do on an old hard drive, assuming it's still readable. I still have the dongle in my desk drawer.

[tschak909]

Point of question, Altirra supports higher baud rates than 9600:

 

(a) What handler do I need to use to get these higher baud rates?

(b) What bits do I need to set to get the higher baud rates? The cc65 atari serial driver only does up to 9600 (As per the 850), but I can add the additional bitrates.

 

-Thom

[tschak909]

Committed working modem sanity check (ATZ), and modem initialization, probably only thing i will tweak here, is to retry the command e.g. 3 times, before accepting defeat.

 

My implementation of this, using the cc65 serial port API did reveal a deficiency with the ATRRDEV.SER driver:

 

While the ser_open call DOES push the R: device into concurrent mode, there is no way to push it back out from the serial API:

 

;---- open the device

do_open:
        jsr     my_findfreeiocb
        bne     init_err
        txa
        tay                     ; move iocb # into Y
        lda     #3
        sta     tmp3            ; name length + 1
        lda     #<rdev
        ldx     #>rdev
        jsr     my_newfd
        tya
        bcs     @doopen         ; C set: open needed / device not already open

        pha
        jsr     SER_CLOSE       ;** shut down if started  @@@TODO check this out!!
        pla

@doopen:tax
        pha
        jsr     my_clriocb
        pla
        tax
        lda     #<rdev
        sta     ICBAL,x
        lda     #>rdev
        sta     ICBAH,x
        lda     #OPEN
        sta     ICCOM,x

        lda     #$0D            ; mode in+out+concurrent
        sta     ICAX1,x
        lda     #0
        sta     ICAX2,x
        sta     ICBLL,x         ; zap buf len
        sta     ICBLH,x
        jsr     my_CIOV
        bmi     cioerr

        lda     tmp2            ; get fd (from newfd)
        sta     rshand
        ldx     #0
        stx     rshand+1
        txa
        rts

So on a real 850, or in Altirra with all emulation options enabled (6502 resident handler), my code gets stuck after spitting out the log file message to the disk drive and printer, because it gets kicked out of concurrent mode... Am wondering if I will need to implement a concurrent mode ON and OFF pair of functions, or if I can just patch the serial driver to kick itself back into concurrent mode on each serial get?

 

while it does look like Get does check a local variable that gets set on open to determine if concurrent mode is active, I'm not 100% sure that this gets un-set when outside disk i/o occurs (most likely NOT), and would probably like a pair of eyes to look over the ATRRDEV.SER code to see if we can fix this.

 

-Thom

[tschak909]

A video showing the first breaths of this thing:

 

[ivop]

I had to adjust MEMLO on the linker configuration ,because with the RS232 driver loaded, it was bumping up against code.

 

Also, managed to verify that I was at least talking to the port correctly, just need to tweak the response comparator.

 

-Thom

 

btw, I am regularly pushing all my code changes to github, if anyone has comments etc, please let me know.

 

I glanced over your code a few days ago and a few things came to mind. Programming in C for the 6502 is somewhat similar to programming in C for embedded systems that are memory constrained and have a CPU with limited capabilities. The same tricks apply here.

For example, I see you return values for most functions are int. With cc65, int is 16-bits and 16-bit operations are slow on a 6502. Everytime you evaluate the return value, it does 16-bit operations. It's better to use (unsigned) char. IIRC cc65 never promotes it to 16-bits, only when it is really needed (this is non-standard behaviour for a C compilers).

Also, bitfields are slow. I would just use char for each variable.

If I were you, I'd replace the global config structs and pointers and all, completely with separate variables. Loads and stores will turn into lda/sta combinations instead of indirect addressing.

Have a look at the static locals command line option. All functions that do not need to be re-entrant better not have their local variables on the stack (which is slow). Functions that really do need to be reentrant can be sandwiched between #pragma statements to override the command line option.

And for for-loops, if you do not exceed 255, also use an unsigned char instead of an int. Basically, use chars unless you really cannot.

There might be more, but this is just what came to mind

Good luck!

Edited July 30, 2014 by ivop

[tschak909]

I glanced over your code a few days ago and a few things came to mind. Programming in C for the 6502 is somewhat similar to programming in C for embedded systems that are memory constrained and have a CPU with limited capabilities. The same tricks apply here.

For example, I see you return values for most functions are int. With cc65, int is 16-bits and 16-bit operations are slow on a 6502. Everytime you evaluate the return value, it does 16-bit operations. It's better to use (unsigned) char. IIRC cc65 never promotes it to 16-bits, only when it is really needed (this is non-standard behaviour for a C compilers).

Also, bitfields are slow. I would just use char for each variable.

If I were you, I'd replace the global config structs and pointers and all, completely with separate variables. Loads and stores will turn into lda/sta combinations instead of indirect addressing.

Have a look at the static locals command line option. All functions that do not need to be re-entrant better not have their local variables on the stack (which is slow). Functions that really do need to be reentrant can be sandwiched between #pragma statements to override the command line option.

And for for-loops, if you do not exceed 255, also use an unsigned char instead of an int. Basically, use chars unless you really cannot.

There might be more, but this is just what came to mind

Good luck!

Yeah, I have had notes written down to address these, when I get more of everything working.

 

I am not concerned so much about performance for things like reading configuration values etc, because it doesn't really matter, I'm more interested on memory conservation in this case...but the changing of the return values to unsigned chars etc I will definitely do in the next day or so.

 

Thanks for looking, it'll get more interesting as features start to be written...

 

-Thom