FusiON BBS Back Up

[Shift838]

All,

 

After some a lot of thought and idea bouncing with others I have re-coded sections of FuSiON BBS to address issues that were identified in the first round of testing.

 

So, I have reset the message bases and the BBS is backup for additional testing.

 

If you already had a user account created then you still do. I only reset the existing user's last message number read flags. All your accounts/passwords should still work.

 

Direct IP : 99.122.140.172 PORT #: 9640

For users using real hardware or emulation and serial bridge with a UDS10:

99.122.140.172,9640

DNS : fusionbbs.ddns.net

Port : 9640

Updates:

With the code review and streamline I was able to free up 15 sectors of disk space and 1k of memory! 1k is a lot for our little beast.

 

• Listing of one liners and extended them to be up to 80 characters.
• Fixed the reply to message issue where when you were reading messages or scanning for new that after a reply it would start the scan completely over at the first message you read.
• I have also added 'EXPERT' menu mode at the main menu. This can be toggled on or off at the main menu. Default is OFF when you log on and the OFF setting will display the main menu before every prompt. Press 'X' to toggle the mode.
• Also added a "Press Any Key' at various areas like listing the message headers, user list, etc.
• Help File
• Menus with new 'EXPERT Mode' option

 

Let's give this round 2 testing now.

 

Also please remember this has been activated for User Testing to help me identify issues with the BBS that I may have not encountered in my testing.

 

If you find any issues please email me direct or PM me here with exact details of what the issue is.

 

Any other areas you think need to be addressed or would like to make comments on as well.

 

 

 

[Omega-TI]

I get a lot of NO CARRIER, which means busy. I'll try again later.

 

It's looking good Chris!

Edited March 7, 2016 by --- Ω ---

[Shift838]

All,

 

I have had to move the BBS to port 23.

 

I evidently have a quirky UDS10 or a setting that is off.

 

It seems a transfer over about 10k bombs on port 9640.

 

So until further notice hit the BBS on port 23.

 

Once I moved it back to 23 i was able to transfer a 130k file with no problem.

Edited March 8, 2016 by Cschneider

[Shift838]

update. I figured out a workaround so it's back on port 9640.

 

I was able to listen on my router on port 9640 and forward it over to port 23. that seems to work.

 

I was able to transfer the 130k file that way.

 

I did have issues with a v9t9 file, so make sure if you upload you are uploading a TIFILES header file. But that seemed to work just fine. I am sure its because I have it flagged for TIFILES in a call load statement. I need to double check that.

[+InsaneMultitasker]

update. I figured out a workaround so it's back on port 9640.

 

I was able to listen on my router on port 9640 and forward it over to port 23. that seems to work.

 

I was able to transfer the 130k file that way.

 

I did have issues with a v9t9 file, so make sure if you upload you are uploading a TIFILES header file. But that seemed to work just fine. I am sure its because I have it flagged for TIFILES in a call load statement. I need to double check that.

There isn't a TIFILES flag so to speak, at most you can force the TIFILES header (on DF128 files) when sending from the BBS. If a TIFILES header is present on a file being sent TO the bbs, the software will re-create the file based on those parameters.

 

The only time you may want to turn off TIFILES headers is if you have a non-TI section or files shared between machines. The files would be stored in DF128 format by convention, and to see them restored on the non-TI side, the header must not be transmitted. There can be no expectation of restoring the original non-TI file size at this point because the records will be in 128 byte increments and 256 byte sectors. That is to say, a 130 byte file will be transferred as 256 bytes, resulting in 126 bytes of trash or cleared data. (I forget how I handled that last record, though it should simply be cleared or filled with CTRL-Z IIRC). Even if Ymodem headers were used, the TI has no mechanism to store that exact file size with the fixed record transfer scheme currently in place.

 

Edit: One addition, if someone uploads a V9t9 file, it can be downloaded successfully so long as the TIFILES header is not sent. Of course, there is no good reason to do this and as you state, TIFILES format is 'expected'.

Edited March 11, 2016 by InsaneMultitasker

[budz2355]

Hmmm locked up my ti uploading a file..... First file I uploaded seemed to work fine? You might want to delete risk since I don't think the upload ever finished.

[David Baldwin]

I had no tubble on the BBS it was smooth looking around and login at 9600 bps.

[Shift838]

Hmmm locked up my ti uploading a file..... First file I uploaded seemed to work fine? You might want to delete risk since I don't think the upload ever finished.

 

was not a lockup but i had a power blip during a storm so it was down for a bit.

[+InsaneMultitasker]

Dropped you a note on your BBS regarding hotkeys that you might want to check into. For awareness, most menus and prompts in S&TBBS are hotkey enabled, although at high speeds, TIMXT spends most of its time buffering the incoming stream. I haven't found a good way around this (yet). PORT and the PC-based telnet should be fast enough to use hotkeys - type a key from one of the menu options while displaying.

[Shift838]

I am going to try to convert the OS to a linux distribution to take advantage of resource utilization. If you call the BBS and it doesnot connect that is why. I have made a backup of the bbs so no data will be lost.

[Shift838]

i'm still working on getting the PC on the OpenSuse OS. Well I have it installed, but I have to figure out how to get MAME to work.

 

all my drivers, serial and all is loaded.

[Shift838]

I did not have any luck getting OpenSuse working. Well.. I should not say that. I was able to get the OS loaded but getting MESS compiled was a different story for me. I will mess with it (no pun intended) at a later date.

 

Of course I'm a NOOB when it comes to Linux. I do like the OS and 'Konsole' command line in the KDE desktop i really like.

 

So I put Windows 7 back on it but I decided instead of running the latest version of MAME since it requires a lot more processing to run the last version of MESS64 for windows. It runs good for this little computer with no slow down. So MESS is a bit snappier than MAME for me.

 

Now I will be watching the RTC in the Geneve emulation as I observed and Michael Zapf verified that with MAME would launch it would pull the time/date from the PC as expected. But after that it was on it's own to keep the time up. I noticed after running the BBS for a few days that my date was off. Once checked it was due to the time. I was able to see that it would loose hours per day and i would have to exit to MDOS and reset it. I think this also had something to do with the amount of processing power required by MAME as well as all the disk access going on.

 

Anyways. the BBS is back UP!

Edited March 30, 2016 by Cschneider

[Shift838]

well the BBS has been running on MESS64 instead of MAME for the last 24 hours and checking the clock has revealed no loss of time compared to the real clock on the PC. So I now know that given the processor speed of this dedicated PC and the requirements MAME64 requires over MESS seems to be significant enough to cause time loss within MAME.

 

An fyi so all know what I have configured is:

 

Dual AMD Athold 64 X2 Dual core processors (3400+ ; 1.8ghz)

4GB ram

128mb SSD

USB Serial Interface

Windows 7 Home Premium 64 bit

USB to Atari Joystick cable for carrier detect routine.

UDS10

 

Running latest version of 64bit MESS and TIIMAGETOOL along with latest version of JAVA