New Atari BBS software.

[TXG/MNX]

Can you use a sqllite or something like that in the engine to make. It quick on a large messageboard?

[tschak909]

No, Don't make me hurt you.

[phaeron]

XML, then?

[tschak909]

gonna ignore that.

 

In the mean time, sometimes you have to write strange routines, in order to get things done, things you would never think of writing at the outset. In this case, I needed a Lorem Ipsum generator, so I could create random message bodies, to work out the message board code.

 

This works just fine in CC65:

 

 

void loremIpsum(unsigned char minWords, unsigned char maxWords,
      unsigned char minSentences, unsigned char maxSentences,
      unsigned char numParagraphs, char *output)
{
  const char* words[] = {
    "lorem", "ipsum", "dolor", "sit", "amet", "consectetuer",
    "adipiscing", "elit", "sed", "diam", "nonummy", "nibh", "euismod",
    "tincidunt", "ut", "laoreet", "dolore", "magna", "aliquam", "erat"};
 
  int numSentences = rand() % (maxSentences-minSentences)+minSentences+1;
  int numWords = rand() % (maxWords-minWords)+minWords+1;
  int p,s,w;
 
  srand(clock());
 
  for(p=0; p<numParagraphs;++p) 
    {
      strcat(output,"\n");
      for(s = 0; s < numSentences; s++)
{
 for(w=0; w < numWords; w++)
   {
     if (w > 0) 
{
 strcat(output," "); 
}
     strcat(output,words[rand() % 20]);
   }
 strcat(output,". ");
}
      strcat(output,"\n");
    }
}

 

It generates something like:

 

[kogden]

Can you use a sqllite or something like that in the engine to make. It quick on a large messageboard?

 

SQLite might seem small on your 64-bit multicore desktop with 2GB+ of RAM. On a 64K machine it's positively gigantic and even if it could be rewritten in ASM and pared down severely to squeeze in, it would be slow as hell and leave little for BBS software. An XML parser would be pretty nuts too and wasteful when it comes to disk space.

 

If you want to play with ancient machines from this era and still run a full relational database engine, you should be looking at a MicroVAX or PDP11, not an 8-bit.

[tschak909]

kogden, I seriously hope I was being punked. At least I hope I was...

 

-Thom

[Android8675]

OK, bulletin menu rings the Atari bell locally, and it's enough to wake my sleeping daughter. Good to know.

 

Made a logo screen, it's big, I like it, maybe i'll put it somewhere, still getting used to mattEd. I like the other editor a little more, but it's buggy and I can't figure out how to clearscreen to start a break movie.

[tschak909]

OOPS, sorry

 

As for Matt*Ed, yeah, that's what I'm using at the moment...

 

Would love to see what you've drawn.

 

-Thom

[Android8675]

nothing special, just getting my toes wet... I tried to commit the file, but it's not showing up (a8-logo.ata) in the screens folder. I forgot to set my user.name first though so it may of been rejected or something. May try again in a bit.

[tschak909]

I don't have any collaborators set up on the github project, so dunno if you can do that.

 

-Thom

 

p.s. added you.

[Android8675]

Just got the email, gonna see if I can remote to my home system and commit.

[tschak909]

Yup, was able to pull it down just fine. Took me a moment to read it, a little sideways isomorphic action, nice.

 

-Thom

[tschak909]

FLATMSG is starting to breathe, message put is working:

 

 

 

 

As you can see there, there are two files:

 

.HDR - containing the message headers.

.MSG - containing the message bodies.

 

The one file you don't see there yet, is the .IDX, which are 4 byte records (with a 4 byte preamble), containing offsets into the headers, so that they can be loaded into memory, and hopefully searched quickly.... maybe...

 

Still far too much to do... far...far...far too much.... but that's status, for now.

 

-Thom

[Android8675]

*cough* b-tree *cough*

 

Kidding, so want to spend more time on this, but my home/work life is crazy busy. Looks like the frame is getting there, curious if you've designed the file structure layout and made it so you can specify file locations in bbs.cfg for different things, my OCD is eager to start moving different files into sub-folders.

 

telnet://shodan.synchro.net:9000

 

still running, press 1 or 2 at the bulletin menu. A/B sets off my Atari's system bell.

[tschak909]

Sure, B-tree, but what KEY to do you use to sort?

 

My focus is to get ALGORITHMS working, to get the individual parts at least functional, with the menus/UI being last, THEN figure out how I want to expose the bits as an API, this will allow me to determine the module format, and how to load pieces in. This is the _HARD_ part for me, so I am punting it until I can get enough data to understand the picture more cleanly.

 

-Thom

[Android8675]

Figured you had a plan...

 

b-tree, don't think you need to sort anything, just need pointers to point to the messages around the one you are reading. Don't worry about it, you got other things to worry about for now. Will revisit it later.

[tschak909]

dude... you _have_ to sort the tree, to balance out the node/leaves. that's why the search is fast. Go read some CS textbooks.

 

-Thom

[Android8675]

dude... you _have_ to sort the tree, to balance out the node/leaves. that's why the search is fast. Go read some CS textbooks.

 

-Thom

it has been a while...

[tschak909]

Implementing msg_get() tonight in flatmsg. I really have no idea what i'm doing, I'm just guessing my way through.

 

Essentially, right now, FLATMSG boards consist of a set of files, with the same base name, one set for each board to create:

 

BOARD1.MSG - for the message bodies.

BOARD1.HDR - for the message headers.

BOARD1.IDX - for the message index (providing offsets into both of the above files).

 

and i'm considering adding a FOURTH, BOARD1.LRD, which would be a simple mapping of user hash, to last read message #, for things like quick scan.. This won't be added until I actually start using user data...)

 

Right now, to give an idea of board storage, I have a test fixture (which you can run if you compile FLATMSG), which generates 255 random messages from different random people, with varying body content.

 

Each message header takes up 152 bytes, at present, each message index entry takes up approximately 8 bytes, with four bytes at the top for number of messages in the board, and the message bodies I am generating take up approximately anywhere from 200 bytes to 6700 bytes. Extrapolating over 255 messages, that gives something like:

 

 

MSGTEST  HDR  35190 27-08-14 19:33
MSGTEST  MSG 629436 27-08-14 19:33
MSGTEST  IDX   3319 27-08-14 19:33

[tschak909]

I dropped a dirt simple utility, CONVTXT.COM, into the tree, which alters ASCII line-endings into ATASCII, for quick and dirty text conversion.

 

-Thom

[evilmoo]

 

Implementing msg_get() tonight in flatmsg. I really have no idea what i'm doing, I'm just guessing my way through.

 

 

Have you tried looking at the JAM message base stuff? I'm sure it's too complicated for you to reuse all of it, but you could at least look at their design and see what's worth stealing: http://defsol.com/news/jammbp-the-joaquim-andrew-mats-message-base-proposal/

[tschak909]

No, I haven't.

 

I'm kicking myself for writing too much code, before testing.. Now I have to peel back and debug and make sure I am actually seeking to, and reading/writing the right file data (whether I am fucking up at the write, or the read, or both... ugh.)

 

-Thom

[TXG/MNX]

Would it be possible to compress the message base? A flat message base could become very large quick or you get many files.

The message base does it allow to grow over 65535 sectors ?

[tschak909]

each message base is three files, just three files...maybe 4 if I implement last read, and there will be no restriction as to where they are placed. SpartaDOS X has 15 drive slots, 512 byte sectors, 32 megs a piece.

 

I am not implementing any of that, at this time. I am just trying to get it functional, and correct. Those bridges will be crossed, when they are come to.

 

-Thom

[+bf2k+]

for last read, you could assign each msg a unique number, increment it when a msg is added and store that number when the user reads that msg for each user in the user record.