RE: [cc65] loadable module API for AtariBBS

From: Shawn Jefferson <sjefferson1shaw.ca>
Date: 2014-08-15 04:20:04
Hi,

Here's what I would do, if I were designing it:

- Keep $4000-7FFF for loadable modules.
- Load those modules at runtime of the BBS, from some sort of INI file (ini file format could specify what command launches them, if they should be cached in extended RAM or just loaded from disk, etc..)
- Load as many modules as you can into extended RAM, leave the others on disk, you'd have to keep track of what's in RAM already of course, and what BBS command launches what module.
- The loadable modules shouldn't be executables really, just binary blobs, perhaps with two vectors at $7FFC and $7FFE, one for init (ran at load time), and one for run (vector to load the module when a user chooses a certain menu function).

I also think a Vector table for functions of your main BBS is a good idea, that way you can move the code around more easily.  You'll also need well-defined variables too, for username, etc... for the modules to use.

Problems I can for-see:

- if the modules are also cc65 programs, you might need to duplicate the runtime library, as using the main runtime library will cause all sorts of complications (and mean that you will have to compile all the loadable modules with the main program.  It would save space to use the cc65 functions in low memory however... that will be a tough call.  Duplicating the library you will have to make sure to provide/build a linker config file for module writers, otherwise you will have zeropage conflicts-that's pretty simple though.

- will 16k be enough for each module?  I suppose a system of linked modules may work to get around that limitation, or some other clever arrangement.




-----Original Message-----
From: owner-cc65@musoftware.de [mailto:owner-cc65@musoftware.de] On Behalf Of Thom Cherryhomes
Sent: Wednesday, August 13, 2014 7:13 PM

Hi.

I'm thinking through a particular problem that I will eventually need to solve.

I want people to have the ability to implement loadable modules for my BBS engine. They shouldn't need to have to build the code with the knowledge that particular modules will be used in a specific order.
Maybe this is possible, maybe it isn't...but....

Based on what I see with the overlay and multi demos, you can indeed specify different code and variable segments be written out into seperate files and/or memory spaces, a consequence of the flexibility of the linker...

Could we have a situation where you could spit out executables that load themselves into a bank of extended memory e.g. on the Atari there is a 16KB window set aside for bank switching in the most common extended memory configuration (the second PIA does the requisite bank switching), and loading an executable would load itself into high memory, and leave a little chunk of memory just below MEMHI as a sort of vector table that the main engine and other modules can bolt onto to call functions?

The idea would be to have a known API that anything could include and call for functions like:

user_get()
last_menu_selection()

These would be abstract functions that the different modules (a user module, a menu module, a display module, a message board module) would implement, and could be swapped out for other modules, while still adhering to this basic framework, this would allow for a certain amount of modularity and flexibility when building a BBS.

In the end, I don't care if it's an executable (it would be nice, as e.g. a SpartaDOS batch file would load the requisite modules in place, and start the BBS), or if its some sort of binary blob that gets loaded into place, I'm just trying to think of a way forward, after I write all these little functions to be able to have a parser read through a map of the BBS and load/unload/reload specific modules in response to things happening...


----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Aug 15 04:20:06 2014

This archive was generated by hypermail 2.1.8 : 2014-08-15 04:20:08 CEST