Brent's World Forums

Ah HAH! I found your post on the subject: viewtopic.php?t=27507 - Which included instructions on where to download the rom image from. I will definitely give that a shot and let you know how it turns out! There is a lot of great information and posts here! I need to spend more time browsing...

That's alot of diagnosis in a short amount of time. You are either really patient or really stubborn, we shall see which of those is soon.

Let's start with WinVICE: You should be running v3.5, no later. As you found out they have done something vile with the modem handling, so my best results are found using this version and build: 3.5 (GTK3 3.24.24, GLib 2.66.3)
The TCPSer version I'm running (semi-successfully) is v1.1.4

So, for the local mode not working as expected, know that while running the same software version and the same (dsp.Modem x) file using real hardware, it will work as expected. It's routine is ALMOST like what you described in a previous post about missing the 8th (or 0th) bit from the expected response. In DS2's world, the seven bit is removed, translated into C64 basic's chr$, and the sum of 48 is removed from it, which gives you the expected ASCII character. This is why commonly DS2 has always preferred to use number codes instead of verbose (atv0 instead of atv1) so that something like the verbose response RING can be condensed to only one bit, in this case, the number 2.

You will see the routine peppered throughout the BASIC code as gosub94, which in version 11.60 was the actual resting place. Since version 2.0 it has been rerouted to line 364, as seen here:


The value of the received message from the modem is returned in 'a' as a decimal, most often times will be a Hayes result code when offline, or a handful of chatter when online but the user is idle. Image BBS does not behave this way, so as long as there is something to get#, that routine will just run until TCPser eventually craps out. But at least it doesn't report those characters to the BBS as user input, otherwise the IDLE would never work properly. As with any of the modem proxies I've used (comm2comm, TCPser, BBS Server, Ultimate64, etc) none of them have a true 100% Hayes compatible result or command set. The basics are there, yes, but advanced commands like DTR and DCD manipulation (&Cx, &Dx) are missed on them. Ultimate64 by Gideon is a prime example of this. The Swiftlink emulation layer is a beautiful thing, and for a user or caller, it needs nothing more than it already has. But for a sysop, or anyone desiring to host callers, it's highly problematic, and often needs some special workarounds.

In fact, I have made several modifications to the dsp.configure file that helps make sense of the modem stuff. There have been a few posts on Future World II about how to trick the carrier inversion, and how to select modem 3, change it, hold your mouth a certain way, or whatever, just to have it answer calls. I just added the corrected routines and fixed the logic on how telnet has changed the game, so now the user just needs to pick the appropriate modem (added Ultimate and proxy modems as an option). This is where new sysops are going to have the most trouble trying to figure out how to get these options, since the latest release of DS2 (as of this writing it's v2.6d) there has been added an entry for Strikelink modems, although it uses the same dsp.modem 7 file as the one found in Vendetta's 2.5 cracked version, loosely coined "v2.5c".
Config screen for modem selection: C-Net DS2 v2.6d
Config screen for modem selection: C-Net DS2 2.5 w/HVI-mod

There was no modem# higher than 5 on any DS2 release until v2.5 where dsp.Modem 9 made an appearance, but it's pretty much the same as #5 but with some new DTR routines that a fellow named Dave Grabowski was credited. The #5 file was made specific to the Supra24 modem, so any backward compatibility needs to be refer to what makes that particular modem so special that standard Hayes rules can't be followed. It is there that I started, and what model my late entries (and overall replacement of modem 9) are based on. So, did I write the routines? No, I just found some that worked from other trials and errors, and cobbled them together in an easier to understand method, because with my age and memory problems, be damned if I'm going to try to keep track of a little orphan Annie secret decoder ring for modem setup. (invert this, tweak that, lie about baud rate, etc.)

But at the end of the day this is no different from the maxi-compatibility issues that CNet has had with most manufacturers. That's why there are so damn many modem files (1 thru 5 for the user port alone), for things like the HESmodem, MiteyMo, 1670, and actual use of external modems with the Omnitronix RS-232 adapter. I have (in my deployments) added 3 more modem styles, and with rewriting some of DS2's config and startup routines, I managed to separate them into just two different categories, leaving me with dsp.Modem 8 (Ultimate64 / Ultimate1541-II+) and dsp.Modem 7 (Telnet w/proxy, such as TCPSer or BBS Server). Now keep in mind that I have been forced to keep my modified programs in their entirety to myself, and not distribute them. This was the actual spoken and written word from the new owner (Dan Fitzgerald) directly to me, so there was no room for misinterpretation. I've been abiding by that request (order). I am happy to share the knowledge that I've amassed over years of working with this product, and successfully running a BBS on it, but putting any of the dsp files up publicly for download is considered copyright infringement. Normally I'd be gravely apathetic about stuff like that, considering most of us sysops hosted cracked or copyrighted software by the boatload over the years. But with the title owner having your personal cell phone number, and already have utterances of words like "attorney", I tend to not rock the boat.

Now, stuff like online games, addon modules, dsp files that I've written, absolutely, they are available on 8-Bit Playground BBS for download, free of charge, and without need for validated registration. I want to contribute to the community, but my hands are rather tied when it comes to what I can and cannot share. I have fixed an immense amount of bugs in DS2 having to do with SD2IEC compatibility alone, but that is no fault of Jim Selleck's code, it is more or less the entrance of a new hardware manufacturer which, like the new modem products, does not follow the compatibility matrix of CMD file operations. It's what I call "CMD-like" file ops, but that is a whole different thread of posts. (I had a really insightful discussion with Jim Brain about that, and I took alot of notes!)

Cube Inc wrote: Thu Apr 21, 2022 5:19 pm That is exactly what is happening, I opened up the modem files and followed the code around, and in HB's cn file he helpfully commented several lines where he is trying to drop the DTR pin right before calling the hangup (ath) command. Even though I have the appropriate device set to use the ip232 protocol which should transmit the modem status line over the socket to tcpser, I do not see tcpser ever reporting that any of the pins are changing. Still digging...

The ML routines for ACIA/Swiftlink require the removal of about 15 lines of BASIC code in CN, mostly because they are not needed. Using the ACIA ML instead of the user-port ML presumes that you are going to be using DTR disconnect. (You actually don't have a choice, it's DTR or bust, unless you add those lines with conditions in CN at the ML drop point which is line 357.) From there you could, if you needed to, write in those manual print#131 modem commands for legacy +++ and ath disconnects.

Which brings me neatly to one of those OMFGZZZZ why didn't I think of that discoveries: USE LOWERCASE LETTERS WHEN ADDRESSING THE MODEM USING TCPSER!
I had to find every print#131 statement in any file that would call upon it and make sure everything was lowercase letters. By the time networking was introduced, most of those dsp modules were already done in lowercase, it was just the core files left over from 11.60 and 2.0 that needed to be fixed.

As you noted with ASCII -127 thru 127, without a proper translation table twice the size of what's already in ML, you can't pass uppercase characters to the modem. When you send "ath" in C-Net, your modem (TCPSer) is seeing "ATH". Since uppercase characters for a Commodore 64 are technically the graphics keys, TCPser ain't gonna speak that. That's why BBSes to this day still ask if the user can display lowercase characters and/or linefeeds, because the translation table takes up bytes for every language/conversion it needs to process. This is another reason why DS2 is so much lighter than Image. It can't even speak ANSI because nobody has created the xlat table for it. (I would, but I don't care about ANSI, let them eat cake)

BBS Server on the other hand, needs the opposite kind of babysitting. You'd think not since it contains it's own built-in (and in some cases, external addon) translation table, but alas anything you send to BBS Server needs to be in UPPERCASE. So you could technically run 11.60 on it and be fine, albeit very slow. I have also noted that the Swiftlink Wifi cartridge doesn't need any help at all, and is by far the most Hayes compliant new-age device that I've tested. It responds to, and properly executed all the advanced Hayes commands I threw at it, including profile writes. (Irrelevant since it all goes poof when you power off, but it's still damn nice.) Gideon's line of Ultimate ACIA-enabled products also runs like a tank and answers forever, but misses out on the simplest of Hayes command syntax: The frigging SPACE BAR. "ATDT address.com:port" does fuckall, so it needs to be "ATDTaddress.com:port" or you just aren't dialing. To be fair though, all Hayes compliant devices don't NEED the space, but they can at least ACCEPT it. This is the only part about the Ultimate64/U2+ ACIA emulation that frustrates me, but the BBS community is such a small audience that I don't want to pester the creator, he's got enough on his mind what with the chip shortage and all.

Where you are going to run into most of your trouble is timing and buffer. By the time you get#131 to find out what the LAST character from the modem was, it's still busy trying to tell you what the FIRST character was, which I suspect is responsible for many of my false-positive answerings that the BBS loves to do. It will pickup the line and echo back it's own output because it's somehow picking up the caller's duplex. I don't know, that's above my pay grade. What I've done to make the modem as optimal as possible, AND to recently fix the latency issue while using the editor, is to adjust the dsp.Modem x file to properly set the highest baud, which was mistakenly set at 10 (Hayes result code for 2400). I modified the dsp.configure file to allow the sysop the choice of how fast they want to be. (Not everyone can support the full 38.4k)
Config screen for system defaults - DS2 v2.5 w/HVI-mod
Config screen for idle baud rate - DS2 v2.5 w/HVI-mod
Based upon Hayes result codes (10=2400, 14=19200, 28=38400, etc.)

But like you, I still suffer from having to reset the connection with VICE and TCPser because after awhile it will just sit there and ring, but VICE never gets any input. One of my biggest gripes with TCPSer is that it has no "atz" command support. It does jack shit. Restarting TCPser without restarting VICE as far as I'm concerned serves no purpose, they both must be reset. (closed & re-opened) I am intrigued by your results of being able to reconnect the two once it decides to be broken.

Cube Inc wrote: Wed Apr 20, 2022 9:55 pm Also, when I try to enter local mode, it just immediately kicks me back to the Waiting for Call screen, as though I just logged off. It did the same when I had the two original disk images in 8 and 9, but *one* time I managed to get to the Local Mode menu - I just don't remember what I did. I can call into the board from another C64 or SyncTerm, and once there I can take over the call from the C64 running DS2 or I can do everything from the remote computer - it seems to work just fine, I just cannot enter Local Mode from the BBS Waiting for Call screen.

I suspect, again, that it is looking for a file of some sort that is missing based on the fact that it goes for disk access the moment I hit F7 when hovering over the LO tab(?). It seems like it can't find something and then it goes and resets back to waiting for call.

Can anyone more familiar with DS2 point me in the right direction? I checked that I do have dsp.Local Mode on the dsp disk (everything is in 8,0).

Ah, the old wish-I-could-be-inverted-on-the-fly issue for getting into local mode. Love it.
Before I fixed the issue that was causing that (mentioned in a previous post) I would press run/stop immediately after pressing F7 to enter LOcal mode. Then wherever the cursor is, type goto513: and RETURN. Be sure to leave on the trailing colon, otherwise it will pick up any text that is currently on the line the cursor dropped at. Neat little hack for those who don't feel comfortable modding their own DTR routines.

I'm 99% sure the reason tcpser "hangs" and just rings forever is because there are places in its code where the return values of key functions simply are not checked, so opportunities to handle exceptional circumstances are missed, resulting in an unusable socket that is still half open but fully useless. I used to do the same thing in my own code; many examples out there show no regard for return values, and almost all of the time ignoring the return values is going to work just fine, until it doesn't. My fixes to tcpser basically amount to managing the return values of the recv() and send() functions (or read() and write() as I think they use, which are practically interchangeable in almost every but the most nuanced occasion). This gives tcpser and Vice the opportunity to correctly handle the dropped connection in cases where the socket actually indicated that it was closed, but also it prevents false closures when it just needed you to call the send() function a second time because not all the data could be sent on the first pass - which is perfectly valid for it to do. I have tested this with both DS2 and now Image 3.0, and if I forcibly kill tcpser in the middle of a call, both BBSes immediately detect that the carrier was lost and return to the waiting for call screen, no differently than if my mother picked up the telephone line while I was on a board as happened so very often many years ago! Vice attempts to reconnect to tcpser with every byte that is directed at the modem, but it keeps DTR low so the BBS knows there's no modem there until the two actually connect. Start tcpser again and the BBS is ready to answer calls. I've also left both running overnight with no callers (because no one but me can reach the port yet) and it has yet to hiccup.

I know tcpser does handle at least one of the control line manipulating commands, off the top of my head I think it was the atcx series.

I imagine on other systems there are any number of operating system ]things[ that could trigger problems with the natural calls to recv(); any time your Ethernet or Wifi connection flaps or your dhcp client re-negotiates an IP, there's a possibility you might "drop" an established connection. I've seen issues occur when the computer (laptops are especially susceptible to this) activates the screen saver or goes into a "power optimized" mode, it can change some flags on your Ethernet chipset to try to conserve every ounce of energy it can, and sometimes this will quietly close an established connection (especially if the connection has not exchanged data in some while as would be expected between tcpser and Vice when the BBS is waiting for a call for hours on end.)

Anyway, all that to say, while I haven't cleaned up these patches yet (I want to "re-patch" them from clean sources again but without all the extra debugging output I had to inject to help me understand what was going on) - it's been rock solid so far on both DS2 and Image 3.0. I even tested Punter file transfers between two Vice-based C64's running CCGMS 2021 at 38400 and didn't have a bad block in either direction. (And this with Vice 3.6.1!) I am still testing other scenarios, for example, I have been unable to transfer from DS2 or Image 3.0 to SyncTerm using X-Modem, but to be fair I've never been able to transfer anything with SyncTerm successfully so I am starting to wonder if that isn't a problem in that terminal program more than in the BBS / Vice / tcpser side of the equation. It's all process of elimination as you well know.

<lament>

C-Net 64 Developer's System ][ v2.5 - All my life it has seemed tantilizingly just out of reach. Sure, I have my disks from back in the day, and have now been able to cobble together a mostly-working board out of files and disks found across years of searching the Internet - but it does not feel right all the same. I love the fact that Image is still so actively developed. X-Tec and Bucko have my everlasting appreciation and respect for what they have accomplished, running with the torch they were passed by those who started carrying it, resurrecting 2.0 and then creating 3.0 - And wow, I am blown away having spent some time with Image 3.0 now... I mean seriously - Choosing what CHARACTERS replace your password as you enter it during logon is just one of the many configuration options for the discerning Sysop to choose nowadays... That is attention to detail!

I just wish we could have the same opportunity to do something similar for DS2. Clearly there are people who are passionate about it; I've been blown away at all the mods I've seen on your board, Hoy Brothers; it goes way beyond modifying a few of the basic strings to say cute things as one logs on... You've poured blood, sweat and tears into it. I once asked Jim Selleck if he'd be willing to sell it to me, and the answer I got was not a no, but more of a "I'd help you if I could but I am not in a position to do so right now, unless you're prepared to offer a lot more money than you probably are." Fair enough. So I figured it was a lost cause, doomed to decay until I found out that Dan had succeeded where i had failed and had convinced Jim to preserve DS2 by passing it on. And if it cost him money he wants to re-coup, I respect that. I'm in a position now where I would happily buy a license from him to run a legitimate copy, if that is how he would like to manage the software. What I do not understand is the apparent lockdown on collaboration, on sharing modifications, bug fixes, improvements and enhancements. The only way these things have any hope of survival is through the community that uses and loves them, and if you are going to lock that community out ... then what? Let the community BE the community. Nobody's going to steal the credit from him, or you, or anyone else who has had a part in preserving this piece of Commodore Bulletin Board history. We want to celebrate it and use it, learn about it and enjoy it together.

</lament>

I have to pause here for a while. Thanks for the posts!

I don't compile, "make", or assemble any ML or executable. That's not my wheelhouse, all I do is BASIC programming and workarounds. I have literally untold riches of DS2 in my databanks, because I ran in those circles back in the day, and more to the point, I'm a digital packrat (to the lament of my wife) I throw away or delete nothing because I've lost tons of stuff due to hardware failure. Anytime I say "hey, I need to buy more hard drives" she always responds with "Why don't you delete some stuff you already have, you have several hard drives laying around" and you can imagine how that goes. (I eventually get my new drives).

Hackers and crackers tolerated me because I was decent with graphics, file manipulation, and I'm not too shabby with a sector editor, but I don't imagine that I'm much "use" to them, and I don't like to bother people. I reached out to Paul Vandolweerd a few years ago to see if he was still alive, but it took so long to hear back from him that I started working on the DS2 networking package that he originated. I was trying to get his blessing and/or help to remake it for post-modem era so that it would work decently with Telnet. I ended up releasing the 3.14 networking package on Dan's BBS, but I don't know if he ever approved the upload, I have not called back to his board once since that day.

I'd love to work with him because I'm passionate about the product, and I'm not really seeking credit, I'd just like to help the community grow. It's a nice light weight system to deploy and manage, but support is limited to what I can offer, and what people feel like asking on their own. Image is so damn big that it is intimidating to a new sysop, whereas Color64 and CBase is more of a "set it and forget it" type of environment. Hell just to check out the CBBS Outpost alone you can tell where the ease of setup (or brand worship, in some cases) plays into who all runs what:
There are 25 Color 64 boards, 18 C*Base boards, 9 Centipede, 7 C-Net Amiga, and 22 Image. There are only two DS2 boards that I know of, mine and Reign of Fire II (and perhaps Micro Mansion when it ever answers, but it's not listed). And frankly, I don't consider C-Net Amiga to be worthy enough to be considered an 8-Bit BBS. I've never been in the presence of an Amiga, nor have I launched the emulator other than to play Lemmings on my HyperSpin arcade. If it's not C64 or C128, then it's not C= in my opinion.

No, I feel like there's contention because of how I brand my board. I called it "Ultimate Edition" and am very vocal about which version I run (2.5), so he figured I was trying to take his creation and fork my own branch. I have since called it "C-Net DS2 v2.5 w/HVI Mod" more or less to appease Dan, and attempt to remove the sense of competition he presumes I have. My mods would be useless to the community since they were piecemealed together over the decades in my hack and slash modding manner, and would do no more than break a stock system. I would have to release the whole thing as a copy of my BBS, and folks would have to figure out how to un-hardcode all my 8Bit Playground or 13th Floor branding. (Yes, 13th Floor once ran in a DS2 environment. In fact if you look at the archived subs in 8-Bit Playground from the 90s, they are actually threads from 13th Floor. 8-Bit Playground didn't exist until 2019)

I have ideas, and I have presented them. When they didn't get the response I had hoped for, I backed down, returned to my cave, and maintained my private collection, sharing only what I'm legally entitled to. (Well, besides the array of cracked games that are still available for download in my UD section on both boards, but that's what we do, and have done for decades. Serve the community. We are sysops, severs if you will. We provide (basically) a dedicated Commodore hardware rig worth literally several hundreds of dollars for the use of the anonymous public. The moment I try to test or play a game on this hardware someone is sure to call, getting no answer, and removing my potential user base by one. And since 8BP only gets at most 3 calls a day, I can't have that. (Which is why I have 3 or 4 other rigs, lol)

Alas that my own hoarding habits were not confined to the digital realm... To the chagrin of my wife also... To be fair, I am (at least) a third-generation [recovering?] hoarder... I throw out some things, but rarely without serious internal debate, struggle of mind and will of adamant... It all stems from experience - a time when I once needed some widget and had to buy it or do without. So when I come across such a widget, my mind goes, "I've needed one of those before; I may need one again", or "I know what those are worth so I will grab one so I don't have to buy one later", and so my garage has become overrun with stuff.

Your story encourages me none the less, because it confirms that there are still like-minded people out there. Back around '95 or '96, my friend and mentor Greg Krisa - aka />amage Inc. - put out a demo titled "The Decline of Western Civilization". In it he lamented the deteriorating call volumes of the local bulletin boards and the increasing exodus of Commodore users migrating to the newer, more powerful PCs and leaving their 8-Bit machines behind. Sadly, he passed away a little over a year ago, but there has long been the threat of decline to this hobby, a threat that only increases as time goes on and [we] are not replaced by a new generation of users. I doubt very much if my own kids would ever get involved in Commodore BBSes - they've grown up in a different world and the wonder and appeal that keeps the likes of us coming back to the BASICs, does not exist for them who have never known life to exist without smart phones and the Internet. They were boggled to learn that I was around BEFORE even ancient artifacts like the flip phone were invented, and then dumbfounded to realize that cell phones have only been around for the last 40 years or so in one form or other.

I try to call boards whenever I can, and I am working in a lot of my spare time now to improve some of the tools that we all use to make it easier and more reliable for everyone to be able to connect to bulletin boards. That is my part to play at this stage, and I hope to play it well. What will happen tomorrow - no one knows.

Since you do not compile, would you be interested in helping test my patched versions of tcpser and Vice when they're more or less ready if I created binaries of them for you? At some point I hope to have them cleaned up to the place where I'd be comfortable submitting the patches back to the original maintainers so that they can [hopefully] be incorporated back into the mainstream versions (or at least they can consider the changes I made and maybe even come up with better solutions than what I have done.) I can only test so much on my own though, and you know the specific pains you've experienced in the past and so would be better equipped to determine if these changes resolve those issues or create new ones.

Since you do not compile, would you be interested in helping test my patched versions of tcpser and Vice when they're more or less ready if I created binaries of them for you?

Sure, I could do that. I have all but stopped using tcpser for my hardware deployments since I have more direct control over the connection with BBS Server.

(no hot key for tcpser to drop a call when things go awry)
However 8bit Playground remains on vice still because I've not had time to reconfigure the desk that it's going to end up on, I could test with one of those nodes.

Ok, let me see if I can figure out how to compile these two programs for Windows.

If you are at the host running Vice, to drop a call if you can't send "+++ ath" to the modem you could just close tcpser and re-open it. CTRL-C or ALT-F4 = Drop Call Hotkey.