tschak909 Posted July 27, 2014 Share Posted July 27, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
Albert Posted July 27, 2014 Share Posted July 27, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 28, 2014 Author Share Posted July 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted July 28, 2014 Share Posted July 28, 2014 Looking forward to this... Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted July 28, 2014 Share Posted July 28, 2014 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... Quote Link to comment Share on other sites More sharing options...
TXG/MNX Posted July 28, 2014 Share Posted July 28, 2014 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 :-) Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 28, 2014 Author Share Posted July 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
Android8675 Posted July 28, 2014 Share Posted July 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 28, 2014 Author Share Posted July 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 28, 2014 Author Share Posted July 28, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 29, 2014 Author Share Posted July 29, 2014 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. Quote Link to comment Share on other sites More sharing options...
TXG/MNX Posted July 29, 2014 Share Posted July 29, 2014 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 29, 2014 Author Share Posted July 29, 2014 I would like to, but have to get things bootstrapped, first. -Thom Quote Link to comment Share on other sites More sharing options...
kogden Posted July 29, 2014 Share Posted July 29, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 29, 2014 Author Share Posted July 29, 2014 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2014 Share Posted July 29, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 29, 2014 Author Share Posted July 29, 2014 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2014 Share Posted July 29, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
IndusGT Posted July 29, 2014 Share Posted July 29, 2014 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted July 30, 2014 Share Posted July 30, 2014 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 30, 2014 Author Share Posted July 30, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 30, 2014 Author Share Posted July 30, 2014 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 30, 2014 Author Share Posted July 30, 2014 A video showing the first breaths of this thing: 2 Quote Link to comment Share on other sites More sharing options...
ivop Posted July 30, 2014 Share Posted July 30, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 30, 2014 Author Share Posted July 30, 2014 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.