Brent's World Forums

Since this technically does not have anything to do with Image BBS, I wasn't sure if I should post it in the Image BBS forum or not and opted not.

I've got my CMD hard drive set up, but I am having some strange behavior from DS2. This is stock, and I copied both disks into the same partition of the CMD. However, no matter what I have tried, when I try to set/change default parameters (Option 3 from the configure menu) I can make the changes, but it throws a File Not Found error when I try to save the changes. I don't know what file it is trying to modify here, but whatever it is - I don't have it. It also seems like whatever it is looking for, which is not there, also makes the board enter the configure program every time I boot, even though Users, access levels, subs, UDs, etc. are all configured.



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).

Cube Inc

I managed to reinstall DS2 from a different set of source disks that were not "cracked by Vendetta", and this time it seemed to work and I could save the general settings & parameters. When I tried to use Modem 7 from Hoy Brother's update pack though, it never attempts to access the ACIA modem. Same result in C-Term. I'm going to try applying all of his ml patches to this uncracked edition and see if that does the trick.

Ok, so two steps forward, one step back. When I replaced the "stock" files with Hoy Brother's swiftlink & Y2K patches, the ACIA modem works again as expected, and I can type into the terminal at full speed without losing any characters on the board. In fact, it seems to be more reliable than typing into the emulator window itself, which drops keys if typed too quickly.



However, as before - I can no longer access the local mode menu - whenever I try to log into local mode, it immediately drops back out of local mode and returns to the waiting for call screen.

Really, for the purposes of testing Vice / tcpser this setup should suffice though, since the modem functionality is what I actually needed to replicate more than actually setting up and running a board...

I've modified some of the debugging output of tcpser to be a little more specific to what I am trying to find. I got it to hiccup once where it worked itself into a state where apparently looks like it "lost" the socket descriptor for the connection to vice, leaving vice without a modem, but remained still connected to the telnet client. However, since adding the extra debugging output now it's been working perfectly, dialing, hanging up, answering etc. all being tested with C-Term. I have to use C-Term at the moment, because it also looks like the modem driver in DS2 is not sending the +++ break sequence to the modem when trying to log a user off after they've called the board. In fact, you can see the ATH command in the telnet client's window. Looking at the output in the DS2 window, you can see it sent the ath command but there was no break in front of it.



Maybe it is looking for one of the signal lines and assumes the modem is already in command mode? I might have to dust off my Basic hat and peek around in the dsp.Modem 7 file to see if anything stands out there that might be amiss. I guess that there is some flag that lets DS2 know when (it thinks) the modem is in command mode vs. data mode, and if it thinks it is already in command mode it may forego sending the break sequence.

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...

Here is what I have learned / figured out so far, and if anyone can correct items I may have wrong or can fill in more details on any of this, please feel free to do so.

I have figured out the DCD / DTR issues and it was partly my own misunderstanding of the way Vice works and partly a bug in tcpser (at least in how it operates under Linux). As it turns out, like many things, it's actually pretty simple when you know how it's done. On real hardware, DS2's swiftlink drivers rely on the modem status lines (or pins) to inform it when a connection has been established and when the other side of the connection has disconnected (IE: Hung up.) For this, it uses the DCD line, or Carrier Detect. Since we are not using physical hardware in this case, both the C64 and the modem are pieces of software, and the telephone line is the packet-switch Internet which, of course, has no Carrier Detect lines.

To overcome this architectural different, enter ip232. This protocol "listens" to the bytes that are being sent through the emulated phone line from one modem to another, and any time one modem needs to let the other modem know that one of it's signal lines has changed, it sends an 0xff byte (255 in decimal) followed by another byte indicating the new status flags. If the caller meant to send an actual 0xff byte, the ip232 protocol simply sends 0xff as the status byte and this is interpreted on the receiving end as a literal 0xff so that the in-band data does not get corrupt. Interestingly, if tcpser is not handling these status bytes correctly, they will show up as garbage in the stream, usually the little checkerboard character. Watch for this the next time you connect to a BBS - if you see a little checkerboard character when you first connect, that is Vice trying to tell tcpser that its DTR pin has gone high, (Terminal Ready) and tcpser has missed this byte and passed it along inband to the other end (hence the bug in tcpser).

The part of all this that I did not understand was that in order for Vice to engage its ip232 protocol, it needs to be configured for RS232 Network mode. Every version of Vice I've ever used and most of the tutorials I've seen on the matter show you configuring the rs232 device as "|nc hostname port" - What this does is it pipes the outgoing data through the Swiss Army knife tool Netcat (nc) to host hostname on port port. This works, but when running like this, Vice (at least the version I tested, 3.6.1) does not include any of the ip232 data - even if you've checked the box saying that this device uses that protocol. Instead, what you have to do is leave netcat out of it and simply put in the ip address or hostname, a colon and the port number as the "device", like this: localhost:25232 Now, Vice uses an entirely different set of code internally for communicating with the device, and it does include the ip232 signalling bytes.

On the other end, in tcpser, the problem there comes from this chunk of code from ip232.c: (I've taken out the parts not strictly relevant to the problem)
Here we see the incoming data buffer is declared as an array of 256 char's, (which are signed), and when evaluating each byte, a variable ch is declared as an int (also signed.) The problem is that we are trying to compare a numeric constant, 255, to a signed byte. In an unsigned 8-bit byte, if all bits are zero you have a value of 0, and if all 8 bits are 1s, you have a value of 255 giving the range of 0-255 in decimal, or 0x00 to 0xff in hex. However, when you are using one of those bits for a sign bit, when all bits are zero you still have a value of zero, but you only have seven bits available for the value now, so at most you can have the least most significant bits as 1s and a value of 127. From there, if you twiddle the MSB, that value becomes -127, so the effective range of a signed byte is -127 to 127. Therefore, it is impossible for the "if (255 == ch)" expression to ever evaluate as true since the signed byte can never actually equal 255. Now, this would be different if recv() captured 16 bits per byte or higher, because then you would have enough bits to represent 255 in a signed integer. In every instance I've ever worked with though, recv() deals in 8-bit bytes of data.

To fix this is easy enough, we simply declare buf to be an array of uint8_t bytes (unsigned 8-bit integers) and the same for the comparing variable ch. I prefer this method because it removes any ambiguity between platforms as to the size of the type; on some systems, char might be 8 bits long but on others, it could be 16 or even 32. On all platforms, a uint8_t will be an 8-bit unsigned integer, so there is no guesswork and the code behaves identically wherever it is used.

The only other thing we need to do to avoid a compiler warning is to cast buf back to char * for the log function. For good measure, I also like to write the comparison values in hex (so 0xff instead of 255) but this is a personal preference. Typically when looking at any raw dumps of data you are going to see the bytes written in hex, and it is more compact and consistent - in my opinion.

That's all for now, time to read some Lord of the Rings to the kids.

I found and fixed a bug in Vice, and now it will reconnect to tcpser automatically, instantly (well, as soon as tcpser is available again), AND without having to make any changes to DS2 or any other C64 program for that matter! What I've been doing to test is to start tcpser, fire up DS2 and wait till it gets to the Waiting for Call screen, and then restarting tcpser and trying to call the board through tcpser. By adding a whole bunch of debugging output to Vice I was able to track down exactly what is happening, because it detects the loss of connection to tcpser immediately but was not automatically reconnecting to it. In fact, after a dozen or so instantaneous attempts to retry the connection, vice would claim that "127.0.0.1:25232" was not a valid IP address, and would then open it up as a file and started directing all modem output to a file called "127.0.0.1:25232"!

Long story short, there's a function in Vice's src/rs232drv/rs232.c file called rs232_is_physical_device() which attempts to determine whether or not you've got a "real" serial port or a virtual one. It does so by attempting to allocate a vice_network_socket_address_t with vice_network_address_generate(). If this succeeds, the modem must be a network device and if it fails, then it must be a physical device - but this function never frees this socket allocation. Eventually, Vice runs out of sockets to hand out from it's memory pool, which is why eventually it gives the misleading (and quite incorrect) error message about 127.0.0.1:25232 not being in the correct format for an ip address and port. To fix, simply add the missing call to vice_network_address_close(). Here is the complete (fixed) version of the function, along with some of my comments and debugging code (commented out):

Cool that you got it working!!!

With the "Offical" version of DSII now being released and support by K-Guide, from C-Net BBS.net, I would download and install a copy from there, and work off that version..

My two cents looking from your Screen shot, it that for some reason the Config program was running a conversion routine, and since you were setting up the BBS from scratch the input/source file was not present, hence the "File Not Found" error.

The link to the C-Net home page, for C-64, C-128, and Amiga versions can be found here.

http://www.cnetbbs.net/

Additionally, I do not mind that the topic was posted here, after all it is the "General" technical forum.. IF enough people come over and start talking C-Net, then I can create a separate C-Net 64/128 Technical Forum..

The link to the C-Net home page, for C-64, C-128, and Amiga versions can be found here.

http://www.cnetbbs.net/

I looked around that web site and it seemed to be entirely centered around C-Net Amiga. Is there a secret knot I need to find in order to locate the 64/128 C-Net information / files? I found this page: https://www.cnet64.com/software-area/ which looked like exactly what I was looking for, but unfortunately none of the "links" on that page are links at all; all appear to be mere text.

As for being unable to enter local mode, I found that if I disconnected tcpser and set the "Invert DTR line" parameter in Vice, I can enter local mode just fine. I'm just not sure if it needs to think DTR is high or low for local mode to work though... It just needs to be the opposite of whatever the default, non-connected DTR value is. I continue to plug away at it...