Lastic

I even tried now using the chr(m$,255) and then using it in a print, it keeps getting output twice , aaargh. 3 hours and a half been busy with converting my simple menu ASCII and VT52 to a menu from the ASCII set I am using. 3000 compilation erros, missing quotes, typo's and debugging prints + stop BBS , load UIP , transfer file , compile with MCL, start BBS, test using Hatari X repeat But we're not giving up , my target is still end of March , begin of April, heck at least before the next Zoom Call. Old menu code , the variables are empty when using ASCII or are VT52 escape sequences New menu code Old menu look in VT52 New menu look in VT52 ( the 2 offset lines are because of the repeating ALT-255 character) The original ASCII art ( Topaz Amiga Font)

So I went with using list() and still the ALT-255 character is shown twice in VT52. ALT-255 on an Atari is sort of a minus sign that floats a bit higher. see the bottom of this page http://www.kostis.net/charsets/atarist.htm In EVEREST (Text Editor on Atari) it is shown correctly , using Show in TOS it is shown correctly but MCL treats it as a special char ? On a PC it will display like an Y with an umlaut on it. 2p ÿ\___/ÿ\___/ÿ\_____/ÿ\/__/ÿ\___/ÿ\___/ÿ\___/ÿ\___/ b1q Any clue @Techman how I can display this character correctly using list() ?

Super that works, that might be actually the solution to the question I just asked in my Birth of a BBS topic also . In my editor , Sublime, I need to use a special character (non visible in normal view) <01xb> , but I could "borrow" from an ANS file .

Something that was bothering me since a while now . In that particular ASCII BBS-set that I am using there is an upperscore character which does not exist neither on IBM or Atari. But I found an equivalent in the Atari Characterset , ALT-255, off course then I ran into the issue that the print() statement of MCL treats it as a special character so I had to escape it using \ But if I escape it , it is shown twice ?? @Techman any clue how I can get this printed using the print() statement ? ALT-255 on an Atari is sort of a minus sign that floats a bit higher. In EVEREST (Text Editor on Atari) it is shown correctly , using Show in TOS it is shown correctly but MCL treats it as a special char ? On a PC it will display like an Y with an umlaut on it. print(r$,i$,": ÿ\\___/ÿ\\/__/ÿ\\___/ ÿ\\_____/ÿ\\___/ÿ\\___/ÿ\\___/ :",n$,b$,"\n"); But if I try to compile my M file , MCL fails stating that I am missing right colon at the end of my print statement , so probably it is not interpreting the ALT-255 character ?

I must have missed you by minutes, I got up an hour ago (06:00 AM here) . Just messed around with the download logo in order to reply to Techman. It will remain running now, I'm going to work on the file areas on my Linux machine first and that will take some time today before actually moving everything over to the BBS. Interesting to see it with another pallete, would you mind sharing a screenshot of your Xcontrol panel 4 color setup in medium res? Just so I understand what color is color0,color1,color2,color3 . Could you tell where I got the inspiration from to color the Graffiti Wall ?

There lies the issue, currently I'm jumping in MAIN.M via a gosub to FileXfer which has it's own while(true) loop . I guess in the long-run it would be better to put all menu items into a seperate MCL and execute them from MAIN.M and have an execute MAIN.MCL in them to return to the Main menu MCL. It's also a bit more logic on the practical side, if you want to make changes to a menu item , it sits in it's own MCL and hence can be modified/compiled independently from the MAIN.MCL If I'm correct you could then whilst the BBS is running force a reload of MAIN.MCL and tadaah instant changes whilst remaining online. Off course currently I have to stop the BBS, start UIP , do a transfer of my changed source-files, compile them and restart the BBS. (if I want to check the results on something other than the console) the somethingVT52.M uses variables which are assigned to the corresponding escape sequence. for ex Foreground color red r$ = \eb2. These are then used in a print statement to color the text. I picked this up from the VAN NEST example on the Demo disk. As such when viewing them in a VT52 capable terminal emulator , they will display the color. When I put the \e sequences into a txt file and use the list function it won't translate them just put them on the screen literally. These is no easy way around it, I have outgrown the MAIN.M demo example and will need to make seperate MCL files. It is what you do in every programming language , instead of having a huge main program and jumping around inside it to go to subroutines, put the subroutines into seperate files. And it will make my MAIN.M also a bit more readable 🤣

No matter what I put after the execute MCL it never gets LOL "executed" if(user_var1 == 1) /* Atari ST VT52 */ { execute("UPLDV52.MCL"); no matter which statement I put here it never is reached } From what I gather from the manual and the VAN_NEST examples and things I tried goto FileXfer doesn't work since I am already inside the FileXfer subroutine return does what the manual says and return right to the point after the last gosub,in other words since the last gosub to FileXfer was inside the Main subroutine, it will jump back to the Main and not stay in the loop of FileXfer break is not applicable since I'm inside an IF statement so looks like I will need to follow the VAN_NEST example and create a seperate MCL for the FileXfer which then executes MAIN.M when wanting to exit the FileXfer MCL. But that is an overhaul I'm not going to do today. So currently choosing upload or download in the File area menu will jump back to the Main menu after completion.

Yes it does and I have a return; statement at the end of my MCL script. To clarify the nested structure in the MAIN.M file MainMenu:; /* define a main label */ while(1) /* while forever */ { k = prompt("Main Menu:",p$); if(k == 'W') { /* show welcome msg */ print("welcome\n"); list("\\bbs\\welcome.msg"); } else if(k == 'F') { /* call file transfer subroutine */ print("File transfer\n"); gosub FileXfer; } } As such a bit further in the MAIN.M there is the FileXfer subroutine * FileXfer Menu this is how we interact with the file xfer system. */ FileXfer:; /* define a label */ while(1) /* loop forever */ { k = prompt("File Transfer:",p$); if(k == 'L') { /* list download */ print("Listing of files\n"); listdownload(); } else if(k == 'U') { print("Upload\n"); if(user_var1 == 0) { list("\\bbs\\upload.msg"); } if(user_var1 == 1) { execute("UPLDV52.MCL"); print("After executing UPLDV52.MCL \n"); } uploadmenu(); } else if(k == 'M') { /* here is the return from this routine the "return" command returns to the place of the last gosub command. I.e. called from the above loop. and the whole thing starts again. */ print("Main menu\n"); return; } } If thus in the File menu, the user presses U and user_var1 is set at 1 this means the user has selected VT52 and thus I execute a seperate MCL file containing the print statements with VT52 escape sequences embedded print(r$,i$," : : ",n$,b$,"\n"); uploadmenu(); print("After uploadmenu\n"); return; print("After return in UPLDV51.MCL \n"); 2 behaviours I have noticed else if(k == 'U') { print("Upload\n"); if(user_var1 == 0) /* Fantastic ASCII */ { list("\\bbs\\upload.msg"); } if(user_var1 == 1) /* Atari ST VT52 */ { execute("UPLDV52.MCL"); print("After executing UPLDV52.MCL \n"); WHEN USER_VAR=1 this line is never printed } uploadmenu(); THIS GETS ONLY EXECUTED WHEN USER_VAR1=0 } As such I have included it into the MCL file print(r$,i$," : : ",n$,b$,"\n"); uploadmenu(); print("After uploadmenu\n"); THIS LINE GETS PRINTED return; print("After return in UPLDV51.MCL \n"); THIS LINE DOESN'T GET PRINTED

@Tillek @Bikerbob @DarkLord I've currently finished with setting up ASCII and VT51 menu items and logo's. If anybody wants to have a try with a VT52 capable Terminal Emulator and give me some feedback, the colours might be a bit harsh. I've reconnected the public IP so it should be reachable again via Internet. Tomorrow (Sunday) I will be off the entire day and Monday I plan to work on gathering files and setting up File Areas so it should stay up unless I'm busy copying files over. So if on Monday you cannot connect give it a try a few minutes later. If I plan to take it down longer for bigger modifications , I will signal it here .

@Techman Maybe I need to look a bit further or in the morning with a fresh pair of eyes but I got a strange thing going on . Maybe you have an aha moment when I describe it From the mainmenu I do a gosub FileXfer FileXfer:; else if(k == 'U') { print("Upload\n"); if(user_var1 == 0) /* Fantastic ASCII */ { list("\\bbs\\upload.msg"); } if(user_var1 == 1) /* Atari ST VT52 */ { execute("UPLDV52.MCL"); } uploadmenu(); } When the user_var1 == 1 (user selected VT52) , I jump to execute UPLDV52.MCL which basically contain print statements with embedded VT52 coloring sequences. at the end of this MCL file I have a return; However it seems to jump back to the Main menu loop instead of staying in the while (1) FileXfer loop ? Is there a different proper way to return from an executed MCL ?

The Wall also has VT52 colouring now 🤩

Menu colouring with VT52 and switching between VT52 and ASCII now works ! Oh well calling it quits for today. Sorry fellow-Sysops, no Zoom call for me today at 02:00AM my time. Been changing my MAIN.M since 06:00AM this morning and it's 21:45PM now. Editing, saving, starting UIP, transferring, MCL compiling, starting BBS.TOS, logging on via Hatari, checking x 1000 Not complaining though, I once again gained a huge lot of knowledge and accomplishment today using Michtron.

Currently I'm using STALKER to logon and display the VT52 modes since I can run it in Hatari (linux) with the tcpser/socat connecting me to my BBS (which runs on the actual MegaSTe) Some cross-topic posting but this is were I'm at currently whilst testing VT52 at this moment. As stated before my focus lies on ASCII then VT52 and down the pipeline maybe ANSI (although I must just go with my ASCII screens with colors 😁 ) ESC c to change the background color doesn't seem to do much. ( dont' mind the typo in the text) Inverse video works. And for fun I cycled between foreground colors 0-F In Michtron syntax print("\0x0c"); print("VT52 test EXPERIMENTAL\n"); print("\f\n \eb0 Foreground Color 0 \eb1 \n"); print("\f\n \eb1 Foreground Color 1 \eb1 \n"); print("\f\n \eb2 Foreground Color 2 \eb1 \n"); print("\f\n \eb3 Foreground Color 3 \eb1 \n"); print("\f\n \eb4 Foreground Color 4 \eb1 \n"); print("\f\n \eb8 Foreground Color 8 \eb1 \n"); print("\f\n \eb10 Foreground Color 10? \eb1 \n"); pause("Press any key to continue..."); print("\f\n \ec0 Background Color 0 \eb1 \n"); print("\f\n \ec1 Background Color 1 \eb1 \n"); print("\f\n \ec2 Background Color 2 \eb1 \n"); print("\f\n \ec3 Background Color 3 \eb1 \n"); print("\f\n \ec4 Background Color 4 \eb1 \n"); pause("Press any key to continue..."); print("\f\n \ep INVERTED VIDEO \eq \n\n"); pause("Press any key to continue..."); print("\f\n\eb00\eb11\eb22\eb33\eb44\eb55\eb66\eb77\eb88\eb99"); print("\ebaa\ebbb\ebcc\ebdd\ebee\ebff \eb1! \n\n"); pause("Press any key to continue..."); print("\0x0c");

I found the PDF also and had a look at it whilst setting up my UDS. But the UDS is disconnecting me randomly altough in the meanwhile I have set longer idletime() using the built-in Michtron function. So currently back on the WimodemPRO and the transfer speed issue I will focus on later on. I thought switching to the UDS might give me an Eureka moment since Wired is a bit more predictable than Wireless but it didn't. Since I have an Wifi+router all-in-one ISP modem I will also probably go nag them to give me a Modem-only or Modem-bridged-router only. That way I have my OWN router setup , can fiddle with MTU and Jumbo Frames and have my own Wifi since now I'm limited to the ISP menu on it's device. And thanks for the thorough testing and constant feedback, it really helps if you get another person's view or perspective, something I frequently notice in my day-job also.

Today was VT52 experiment day so I needed something that actually can display it. As such I setup Hatari on both my Linux machine and macOS machine using this tutorial. https://breakintochat.com/blog/2020/09/03/tutorial-telnet-to-a-bbs-using-a-terminal-program-in-the-hatari-emulator/ it works perfectly in all terminal emulators except TAZ but I was able to connect to my BBS to test some VT52 setup I was expermenting with. Then I thought well what if I run the BBS in Hatari , and it looks like tcpser is sending a RING to Michtron (running in Hatari) , it is detecting a caller but not picking up. So maybe ... but not going to spend time on this now ... tcpser or socat could be told to do the ATS0=1 and then you would have a BBS running in Hatari (albeit on a Linux/macOS machine).

As I am playing learning/experimenting further , VT52 . From the VAN NEST demo example they use these variables to set VT52 colors h$ = "\eb1"; /* Color highlight */ i$ = "\eb3"; /* Color normal */ j$ = "\ep"; /* Inverse video */ k$ = "\eq"; /* Normal video */ which are then used in these print commands for example print("\f\n ",h$,"Atari ST VT-52 Graphics Screens",i$,"\n\n"); I found some VT52 animations here https://breakintochat.com/wiki/VT52 and thought a list() of such a file would execute the VT52 code they contain but helas , I either got partial screen output or none. I then looked into the contents of these files (FUJIBOIN.TXT in particular) and found all Escape sequences were started with <0x1b> , so I did a find and replace <0x1b> to \e (like used in the VAN NEST example). list() will just print out everything as it is, I then tried to take 2 lines of that same FUJIBOIN.TXT and use the print() function but then I got a syntax error when compiling the M file with MCL.TTP. So my question, maybe I'm on a stretch thinking that VT52 support in Michtron goes all the way to running VT52 animations also. Or maybe it needs an VT2MCL.TTP like for the ANSI conversion ? At worse , I can use these VAN NEST examples to highlight/inverse or color menu items using print() statements so 4 colors in MED res.

Tiny update while still running the BBS on my LAN only. The Wall now looks a bit neater, aligned and now I understand why Darklord was leaving empty messages ( good testing ), because you could just press ENTER and it would record a colon and your username. That has now been caught I also had a further troubleshooting session but even using the UDS , same results as the WimodemPRO 512 cps up to 800 cps (when using plain Xmodem) but nowhere up to stellar transfer speeds I was expecting. Will have to wait for later on . Continuing on the look,layout of the BBS first.

Bit the bullet and bought an UDS-100 fairly cheap on eBAY Germany, it should arrive today. *CORRECTION* it just arrived, but first continue work for another 4 hours. This might give me a clearer picture on wether my transfer speed issues are related to using Wireless versus Wired network. But main focus is look, file and message areas currently.

Regarding the disconnect, might be the timers , I do need to look further into that. Xmodem-1K also caps at 512 cps on my end. Xmodem-CRC goes al the way up to 707 cps on my end? That's more than Xmodem-1K and Ymodem. Even doing a 400K file download using Xmodem-CRC from the DVD-ROM it immediately goes up to 700 cps and fluctuates there between 706-707 cps. And I had the same thing happening to me, it was almost at the end of the download or it was at the end of the download and instead of showing press SPACE , which indicates the transfer completed, it disconnected me and I heard the DVD-writer spinning down. I found the command to set the idle-timer in the VAN_NEST demo so I will tweak that also, it couldn't have been my remaining time since I had 8 hours left. Thanks for testing the transfer speeds, something I will have to figure out further down the line but I'm going to refocus on enhancing the look and setting up the Message and File areas this week. I'm going to unlink the domain-name from the public IP so it will not be reachable via the Internet. Probably until next week, that should give me enough time to get some work done onto it.

My bad , I should really take your advice and set an "Maintenance" message, i've been fighting the past half hour in getting a decent Information page onto the BBS hence it was down. Finally figured it out and it's up and running again. Not going to tinker with it for the next hours, preparing dinner as I type. I got the English docs , yes. (and I'm half-German so I can read German too 🙂)

I am using the ICD driver. I totally forgot about HSMODEM, the drivers have now been installed, only feasible tuning it seems with the current Michtron 9600 BAUD limit was increasing the buffers from 256 to 512. Apart from that I pretty much left the MFP.PRG and SCC.PRG settings default. I also set the Wimodem PRO to AT*T0 (which I think was the default) so it should be in RAW mode. I uploaded a MOD file to File Signature 16 which is hosted on C drive not on the DVD-writer. I granted all current users access to this File Sig , could anybody test from their side and report the average CPS or total transfer time when using Syncterm ? Just to rule out any issues with my network on my side.

@Techman just to be sure that I am not on a wild goose chase, is there any setting in Michtron 3.0 or the source-code that caps the transfer speeds to 512 cps ?

One difference I notice is Ymodem-G downloads at Starfleet show me Streaming 16bit CRC whereas mine falls back to 16 bit CRC ? So a theory, could it be that I am sending blocks instead of a constant stream ?

So I looked into optimising my transfer speeds and possible bottlenecks. Wimodem PRO set at 9600 baud, connected to a 2.4Ghz Wifi network. I checked my Wifi channels and the one I'm using is only used by me , channel 6, SNR is 73% but yeah the modem sits behind a closed door from my living room. Changed my channel width from static 20 to 20-40. A 120Kb download via Ymodem in Syncterm directly from the BlueSCSI HDD ,starts at 500 cps , stabilizes at 512 cps (which seems to be the cap at the moment) and takes a whopping 4 minutes. In that same amount of time 4 minutes , using Syncterm 9600 baud I am downloading a file from Starfleet with an avg of 1890 cps using Ymodem-G of 400KB in size. I also had a look at the downloads from my BBS which are stored on the DVD writer, downloads at 9600 BAUD,cps starts at 309 , very slowly increments and reaches a stable 500-512 cps around the 70% download mark. So I do guess NetUSBee , Extendos, USB-DVD writer at 8xspeed does bring a bit of a bottleneck. I was thinking, are there any TOS 2.05 tweaks I could do on the MegaSTe ? I currently have in my AUTO folder , except for NetUSBee,Extendos,MouseAccelerator/a system clock , only FOLDR100.PRG Things like POOLFIX or CACHExxx ? Only other causes I can think of is Wimodem cap, ISP cap , ...

Correct regarding the graphics settings, last Zoom call Techman wasn't sure if ANSI was implemented or VT52. So in this past week he scanned the manual , found and updated that ansi2mcl tool and I found by digging into the VAN_NEST demo on the Michtron ST format demo-disk how to print the escape sequences for VT52. Also with the new found info gathered from the manual, I now have a way to store these user-settings which aren't in the default user-profile set. (the discussion on userflags user_var in the other topic) Which Terminal program were you using for the downloads , Syncterm or an Atari client ? Was your baud-setting fixed at 9600 ? I also noted from doing test downloads with Syncterm 9600 baud that a 400 Kb file using Ymodem-G takes about 14 minutes. Win10 laptop connected to Wifi I telnet to the external public IP. But since I have no baseline or knowing if that is really too slow on 9600 baud ,I must look further into it. Also the Extendos direct mapped USB-DVD-writer might be a factor also. I plan to populate a File Area on the BlueSCSI to check if there's a huge difference between the DVD-drive or the harddisk. And last but not least, yeah the ZIP's contain the entire directory structure , the DVD file area was setup to have something to test and the general function of a direct mapped Filesig to the DVD d: drive. I noticed it also afterwards regarding the ZIPs, so once I start rebuilding the file areas into a more permanent state , I'll check the ZIP option to exclude that. Thanks for your feedback and keep it coming, I might overlook things and since you guys have been thru the paces it's valuable input for a newcomer like myself.