New Atari BBS software.

[tschak909]

Good idea...

[tschak909]

 

Pouring through a hex dump, debugging file reading/writing routines...

 

-Thom

[TXG/MNX]

Do you support xep80 aswell would be nice to see how that would perform

[TXG/MNX]

Its getting time to dust of my blackboxes and muxes hopefully multinode mux support will there in the end aswell:-) nive project

Is there already a driver structure so people can write drivers without changng the bbs code base? Same for plugin modules because that could help you alot i think.

Also it would be awesome if it could run under the new gui (multi thread) ... Memory should not be an issue these days with 1mb

[tschak909]

Dude, you are _SERIOUSLY_ pissing me off.

 

XEP80 does work, however, the performance of the hardware with the driver _SEVERELY_ impacts serial communication, so I do not recommend using it.

 

As for a "driver" structure. It's nowhere near that point, yet. I am developing modules, so I can DETERMINE an API structure to adhere to, as well as a loading and banking technique.

 

I have been patient with you, but it is wearing _very_ thin, with your uninformed comments. How about you actually GRAB the code, LOOK at it, and provide some CONSTRUCTIVE thoughts?

 

-Thom

 

and (oh, but I don't code in C, is not an excuse, nor is 'i dont code'), This is a new environment for me, and I am trying _very_ hard to see what will be possible, much less what I will actually wind up doing.

[TXG/MNX]

As i told you i dusting of my blackbox will install the bbs and look at the code.

 

From xep80 i didnot know it was such issue.

 

I will not reply to this thread anymore. The last thing I want is to make you feel that way.

 

Good luck ...

[tschak909]

As i told you i dusting of my blackbox will install the bbs and look at the code.

 

From xep80 i didnot know it was such issue.

 

I will not reply to this thread anymore. The last thing I want is to make you feel that way.

 

Good luck ...

 

Sorry, did not mean to snap. This BBS is still at a _VERY_ early stage, and is barely breathing. It's only of use to those who want to build the code and look around. This will change.

 

-Thom

[Android8675]

I don't code, but I still admire your work Thom, and I understand code well enough that I could probably debug/troubleshoot. Gonna go do a git pull now.

[tschak909]

Ok, so. Whew.

 

FLATMSG is starting to breathe. I have test harness code that generates 255 complete messages, with headers and index, and I've verified that the files are being written to correctly. msg_put() takes care of the meat of this, provided a header struct, and a char* body.

 

There is also a corresponding msg_get() which, passed in a msg id, returns a matching header, and body. This is a fairly quick operation, as the offset is made into the index, and the seek offsets are then read from the index, and the requisite reads are done in the header and body files.

 

The Index file, contains at the beginning, a 32 bit value of the # of messages in the database. I am writing this here, because yours truly DIDN'T take this into account when calculating the offsets in the index file to read the seek values. So, to get the appropriate MsgIdxEntry:

 

 

seekValue = sizeof(MsgIdxEntry) * msgId + sizeof(long);

 

That little oversight of + sizeof(long); cost me almost three days of debugging.

 

With that bug fixed, I was able to do some cursory tests of seeing how long it takes to retrieve 255 message headers, and their bodies, into memory, one at a time, clearing memory after each entry. These tests were done in standard 1.79mhz mode, using SIDE 2 as part of the emulated Ultimate 1MB. A standard 6502C was used running at 1.79MHz.

 

With a standard 40 column display, the whole process took 58 seconds.

Turning on the VBXE, and using the SDX 80 column display driver, that time went down to 40 seconds. Boy, ANTIC DMA takes a nice chunk, doesn't it?

Getting rid of the memset() after each entry, shaved that down to 30 seconds.

 

So all in all, not bad, at all.

 

Now I'm writing functions to do a quick scan of headers.

 

-Thom

[tschak909]

Implemented quickscan of headers. That is, given a message ID, provide a cursor to step through headers quickly.

 

No search yet, but it's coming..

 

This is just a linear scan function for all headers on a message board. You specify the starting message ID, and you get a cursor back (seek offset), that you can use for the header_quickscan_next() function, just keep passing in for the next header...

 

It takes 2 seconds to retrieve all 255 of the test headers for a board, one by one, in a for loop.

 

-Thom

[tschak909]

Today, continuing on coding, but before I do any new code, am refactoring flatmsg into several pieces:

 

msg.c - functions for dealing with the whole board, as well as body text.

header.c - functions for dealing with the message headers

idx.c - functions for dealing with the index

test.c - the testing harness, compiled if DEBUG is set.

 

This is not optimizing, but just cleaning up the clutter, so I can see things a bit better... Am still debating whether this will become a library, whether it will become an overlay, or...what... but at least for now, I just want to write the algorithms, and make sure they work...

 

-Thom

[tschak909]

Hi guys, I checked in the test harness code to FLATMSG, so you can compile FLATMSG, and you will get a menu where you can write out a test message board, and do various exercises with it.

 

The Write msgtest appends, so you can keep adding messages in 255 message sets, to observe the disk space and effects on searching.

 

Right now, all searching happens linearly, this will change later.

 

Video will come tomorrow, once my camera battery charges...I want to show this without any RDP latency.

 

-Thom

[tschak909]

And now, a status video showing off the test harness:

 

 

-Thom

[tschak909]

Victory! Thanks to drac030, I was able to get the needed kernel vector to read time and date from SpartaDOS X's KERNEL vector.

 

 

	
	void timedate(TimeDate *td)
	
	
	{
	
	
	  struct regs r;
	
	
	  assert(td!=NULL);
	
	
	  r.pc = 0x703; // KERNEL
	
	
	  r.y = 100;    // GETTD
	
	
	  _sys(&r);     // Do Kernel Call.
	
	
	 
	
	
	  td->day     = *(byte*) 0x77B;
	
	
	  td->month   = *(byte*) 0x77C;
	
	
	  td->year    = *(byte*) 0x77D;
	
	
	  td->hours   = *(byte*) 0x77E;
	
	
	  td->minutes = *(byte*) 0x77F;
	
	
	  td->seconds = *(byte*) 0x780;
	
	
	 
	
	
	  return;
	
	
	}
	

 

This returns a struct containing 6 bytes, each byte a component of the time and date (not BCD), simple enough to deal with.

 

-Thom

[tschak909]

31 day streak! https://github.com/tschak909

 

-Thom

[tschak909]

Well, SHIT.

 

Looks like I may have to abandon this approach, as it seems that calling SDX kernel routines and the serial port routines literally causes a crash. FUCK. ...maybe the Z: handler will work...

 

-Thom

[tschak909]

Welp, paint me all derpy...

 

I didn't read the SDX manual close enough, where it states:

 

Page Seven "Kernel" Values

Several page seven locations allow for "kernel" operation to be accessed. While it is beyond the scope of this manual to document all of these loca- tions, a few may prove to be of interest.

Name Address sparta_flag $700 sparta_version $701 kernel $703 block_io $706 misc $709 device $761 name $762 date $77B time $77E dateset $781 path $7A0

Function
'S' if SpartaDOS
version in hex; $32 = 3.2, $40 = 4.0, etc. jump (JMP) to "kernel" entry
see below
jump (JMP) to "misc" entry
"kernel" device number
filename and ext (11 bytes)
see below (3 bytes)
see below (3 bytes)
see below
path only string (64 bytes)

The "kernel" routine is called by doing a jump subroutine (JSR) to address $703 with the desired command in the 6502 Y register and the desired device number previously stored in the memory location "device". For ex- ample, with a $10 in device, a value of 100 in the Y-register will cause the current time and date to be placed in the variables 'time' and 'date'. A 101 will cause the current time to be set to the values contained in the variables 'time' and 'date'.

kd_gettd 100 get current time and date kd_settd 101 set time and date.

 

I have now amended the timedate() function appropriately:

 

 

 
void timedate(TimeDate* td)
{
struct regs r;
assert(td!=NULL);
r.pc = 0x703; // KERNEL
r.y = 100; // GETTD

*(byte*) 0x0761 = 0x10; // DEVICE

_sys(&r); // Do Kernel Call.

td->day = *(byte*) 0x77B;
td->month = *(byte*) 0x77C;
td->year = *(byte*) 0x77D;
td->hours = *(byte*) 0x77E;
td->minutes = *(byte*) 0x77F;
td->seconds = *(byte*) 0x780;

return;
}

 

And the result is:

 

[tschak909]

Letting you guys know, am going to be bolting on the user module within the next couple of days, to allow user log on, and at least keep a log of when he's logged on. I'll be firming up the user file format, to handle timestamps etc.

 

For the record, timestamps will be stored, as they're represented by SDX, 6 bytes, YY-MM-DD HH:MM:SS, where YY is a 2 year date which is now skewed for post-Y2K.

 

I'm also running the FLATMSG test harness, adding as many messages as I can, to fit on a 32 megabyte disk, to see what the numbers will be like. Photo coming soon.

 

-Thom

[tschak909]

Looks like approximately 6700 large messages can fit in a single flatmsg file. 16 megabyte maximum.

 

 

Which produces MSGTEST files of the following size: I present to you, the largest file of real data stored on an Atari 8-bit, 16 MEGABYTES in size

 

 

That produces an index file, roughly 88K in size, and a header file roughly 943k in size.

 

For roughly 6900 messages.

 

-Thom

[Albert]

I wonder if we can write a conversion utility to get all the messages from the AtariAge forum into the BBS.

 

 

..Al

[tschak909]

Probably, it would mean I would need to support multi-segmented body files.

[tschak909]

To give an idea of how insane the linear search can get, doing a from search on a single name, against 6885 messages takes 98 seconds on a 6502. Versus 15 seconds on a 65816 running at 21MHz.

 

I definitely need to b+tree, this bitch.

 

-Thom

 

p.s. holy shit! It's taking over 5 minutes to DELETE this file running 65816 21MHz!

[+bf2k+]

 

For roughly 6900 messages.

 

-Thom

Are you running SDX w/512 byte sectors?

[tschak909]

Yes, I am. keep in mind, that I am not storing each message individually.

 

-Thom

[tschak909]

Well guys,

 

I've attached the User code to the BBS core for testing. You can log into the BBS at telnet://96.226.245.101:9001 and create a new user account, and subsequently log in again using the chosen username and password.

 

Here's a status video:

 

 

Feel free to try.

 

-Thom