Ok, so today I finished up some overlay code, which will allow the BBS to load modules.  It works by changing the end of program pointers, and line->next line chain.  It works well, but I had to read the overlay in via GET#1,a$...whis is not the skippiest way to do it (I wanted to use BLOAD, but I needed to know when the end of file was reached, in order to manage the new end of program pointer).  Currently its set to always load an overlay at line number 10000, but that can be changed easily.  The overlay MUST be the last series of code (ie, you cant overlay in the middle of the main code, it must come at the end).

We should probably revisit it, and convert it to ML (prime candidate).  But now that this is done, we can divy out the subsystem modules that need written.

Heres how to call it:

F$="somemodulename":gosub 5000  (this is where the load/execute routine is currently)

The 128 puts variables in a different bank than the program code itself, so we dont have to worry about messing up program variables. Overlays have access to all the variables of the main program.  Ill upload a D81 image with some sample code tonight.

x

Quote from: xlar54Ok, so today I finished up some overlay code, which will allow the BBS to load modules.  It works by changing the end of program pointers, and line->next line chain.  It works well, but I had to read the overlay in via GET#1,a$...whis is not the skippiest way to do it (I wanted to use BLOAD, but I needed to know when the end of file was reached, in order to manage the new end of program pointer).  Currently its set to always load an overlay at line number 10000, but that can be changed easily.  The overlay MUST be the last series of code (ie, you cant overlay in the middle of the main code, it must come at the end).

We should probably revisit it, and convert it to ML (prime candidate).  But now that this is done, we can divy out the subsystem modules that need written.

Heres how to call it:

F$="somemodulename":gosub 5000  (this is where the load/execute routine is currently)

The 128 puts variables in a different bank than the program code itself, so we dont have to worry about messing up program variables. Overlays have access to all the variables of the main program.  Ill upload a D81 image with some sample code tonight.

x

Hang on, wanna create a CVS first!

Quote from: admin

Quote from: xlar54Ok, so today I finished up some overlay code, which will allow the BBS to load modules.  It works by changing the end of program pointers, and line->next line chain.  It works well, but I had to read the overlay in via GET#1,a$...whis is not the skippiest way to do it (I wanted to use BLOAD, but I needed to know when the end of file was reached, in order to manage the new end of program pointer).  Currently its set to always load an overlay at line number 10000, but that can be changed easily.  The overlay MUST be the last series of code (ie, you cant overlay in the middle of the main code, it must come at the end).

We should probably revisit it, and convert it to ML (prime candidate).  But now that this is done, we can divy out the subsystem modules that need written.

Heres how to call it:

F$="somemodulename":gosub 5000  (this is where the load/execute routine is currently)

The 128 puts variables in a different bank than the program code itself, so we dont have to worry about messing up program variables. Overlays have access to all the variables of the main program.  Ill upload a D81 image with some sample code tonight.

x

Hang on, wanna create a CVS first!

What modules are planned ? I'm guessing things like configuration data would be broken in to seperate modules, for example file areas, message areas, doorgames, user configuration, modem/telnet (?), events, etc, etc.

I'm for the idea of modules being able to be loaded while the BBS is active (ala Synchronet on the PeeCee) so that changes can be made on the fly.

Also, user data should be modifiable while a user is online as well, perhaps a pop-up box ?

Oz

I think you guys are getting way ahead of yourselves doing so much implementation work at this point.  You're going down a road that locks us into certain BASIC techniques before we've covered very important topics such as how to support protocols, modems, hard drives, etc.  I think we need a good project plan before we start writing any code.

Quote from: plbyrdI think you guys are getting way ahead of yourselves doing so much implementation work at this point.  You're going down a road that locks us into certain BASIC techniques before we've covered very important topics such as how to support protocols, modems, hard drives, etc.  I think we need a good project plan before we start writing any code.

Agreed.

Basic tasks first - I suggest a 'planning meeting' via IRC/MSN/whatever to belt out the simple stuff first with results posted back here for diswcussion  & refinement.

Lance

Certainly. The code that Ive been working on is just sample code.  As far as I know, the only way we can do external modules easily is by using BASIC as the core language.  All of the stuff that needs speed behind it (IO routines, etc) should be done in ML IMHO.  But yes, lets plan a discussion soon so we can talk these things out.

Actually, using CC65 we can VERY easily create overlays in C and load them in and out at runtime at will.  Plus, with a modern PC you can recompile and start testing an entire CC65/VICE project in less time than it takes the 128 to relink a basic program after adding a line of code.  If the RS232 routines in WinVICE really are fixed then that makes our lives about a million times easier for development and debugging.

Hmmm... I think using C code for anything more than those speed intensive routines (like I/O, text translation, UD protocols, interrupts, etc) would severly limit the sysops in writing for the BBS.  And, if we used BASIC as the module language, it would then be possible to have the ability to drop to a BASIC command interpreter within the BBS itself for on the fly testing and changing of modules (think about being able to modify the BBS remotely).  We can discuss the languages in our "kickoff" meeting, when we get one scheduled.  I like the BASIC overlay method myself, with C and ML in the very important roles of fast code.

Incidentally, just tonight I finished up overlay code in ML.  (whew).  So, you can have a main program that does the following:

100 a$="SOMEFILE" : sys 9000 : gosub 10000

After that line, it will call ML that will load in an overlay, and gosub to it.  All the main program variables are still available to the new overlay, so common routines can live in the main program.  Tackling this was my real first jump into ML and it was indeed educational. Here I was able to learn how to read BASIC variables from ML, opening and reading a file, and relinking a basic program.  Ill post a D81 image tommorrow (its really late, and i have to work tommorrow, ugh), including ML source and some BASIC programs and overlays as examples.

Even if we decide against using it, its some interesting code on variable access and BASIC merge/overlays of code.

Quote from: xlar54Incidentally, just tonight I finished up overlay code in ML.  (whew).  So, you can have a main program that does the following:

100 a$="SOMEFILE" : sys 9000 : gosub 10000

After that line, it will call ML that will load in an overlay, and gosub to it.  All the main program variables are still available to the new overlay, so common routines can live in the main program.  Tackling this was my real first jump into ML and it was indeed educational. Here I was able to learn how to read BASIC variables from ML, opening and reading a file, and relinking a basic program.  Ill post a D81 image tommorrow (its really late, and i have to work tommorrow, ugh), including ML source and some BASIC programs and overlays as examples.

Even if we decide against using it, its some interesting code on variable access and BASIC merge/overlays of code.

Did you upload it to the project page ?

Lance

Not yet.  It was really late last night, and I wanted to clean up the D81 image that I was working from, as well as include the source code for the ML. (Im doing cross development from the PC using TASS).  Ill put it there tonight.

Xlar,

Would you be willing to supply your assembler in CA65 format?  CA65 is the assembler for CC65 and if we do decide to allow C overlays and drivers, then we need to standardize on the CA65 assembler.

I sent a ZIP file to Lance in email; he can put in on sourceforge. It contains both a D81 image of working code and a text ASM file for the ML. The ASM file contains the assembly code in TASM format, but changing to CA65 should be very easy.  As long as CA65 doesnt change any of the needed locations (which it probably doesnt), it should work fine. Once its out there, check it out and let me know what you think.