|
Post by atolle on Jun 18, 2006 14:11:26 GMT -5
You can download everything at gcns.comHere's a quick tutorial on getting started: Start the new version of tcpser with something like the following command line: tcpser -v 25232 -s 38400 -p 6400 -l 4 This will set up an ip232 port at 25232 (more on this later), report speeds as 38400bps, and listen for connections on port 6400. It also sets up level 4 logging, which I find to be the most helpful for monitoring the current status. In VICE, configure RS232 device 1 with the ip address and ip232 port of the system running tcpser. For example, if you are running tcpser on your local system and its IP address is 192.168.0.1, then you would use 192.168.0.1:25232 (this is why you ran tcpser using -v 25232). In WinVICE, you access these via Settings -> RS232 settings... In VICE, enable the ACIA device and configure it to use RS232 device 1. The default recommended ACIA interrupt mode is NMI. In WinVICE, you access this via Settings -> Cartridge I/O settings -> ACIA settings... Save your VICE configuration, and then reset the emulator for good measure. Now boot your favorite SwiftLink compatible software and configure it for a SwiftLink at address $DE00. Novaterm v9.6c works well. In fact, on the website, I included a .d81 image with novaterm pre-configured for SwiftLink. Just attach the disk image and do a LOAD "*",8,1 RUN
|
|
|
Post by atolle on Jun 18, 2006 14:28:00 GMT -5
A little background information: The modified versions of tcpser and VICE use a custom protocol to communicate changes to the DTR and DCD lines. The protocol is similar to telnet, in that commands are preceded by an IAC (interpret as command) byte, with a value of 255. But no sort of negotiation occurs, and all commands are two bytes in length. tcpser is responsible for telling VICE the statis of the DCD line, and VICE is responsible for telling tcpser the status of the DTR line. To indicate DCD status, tcpser will send an IAC byte followed by a 0 or 1 byte. 0 indicates DCD is high (not detected), and 1 indicates DCD is low (detected). To indicate DTR status, VICE will send an IAC byte followed by a 0 or 1 byte. 0 indicates DTR is high (which tells tcpser to disconnect any current call), and 1 indicates DTR is low (active). For either side to send a literal 255 byte, it will send an IAC byte followed by a 255 byte (basically two 255s in a row). I found that DCD and DTR were the minimum signalling to make things work. I found that handling flow control wasn't really necessary, since the ACIA emulation in VICE handled hardware flow control internally by simply not checking for incoming data. Also, since the SwiftLink hardwires the DSR line internally, it wasn't necessary to handle DSR signalling either. A bit of trivia: Something tricky about the 6551 ACIA chip used in the SwiftLink, is that the DCD bit in the status register is 0 for low (detected), and 1 for high (not detected). But the DTR setting uses 0 for high, and 1 for low instead. Seems sort of schizophrenic to me
|
|
|
Post by atolle on Jun 18, 2006 14:35:47 GMT -5
One last note: Only the SwiftLink ACIA emulation in VICE is supported at the moment. The userport emulation is *not* supported yet, but I'll be looking at the VICE code to see if that can be accomplished.
|
|
|
Post by Golan Klinger on Jun 18, 2006 23:46:50 GMT -5
I'm very interested in what you're doing and I don't want you to take this the wrong way but you seem to have overlooked that VICE is released under the GPL. You can't just distribute a compiled version of x64 without providing source and all the appropriate accreditations. I'm currently working on binary distribution of VICE for Mac OS X and I'm trying to wrap my brain around those issues. It's complicated.
|
|
|
Post by atolle on Jun 18, 2006 23:58:31 GMT -5
I'm very interested in what you're doing and I don't want you to take this the wrong way but you seem to have overlooked that VICE is released under the GPL. You can't just distribute a compiled version of x64 without providing source and all the appropriate accreditations. I'm currently working on binary distribution of VICE for Mac OS X and I'm trying to wrap my brain around those issues. It's complicated. I understand your concerns, and no offense taken. However, I've noticed that on the quantum-link.org site, they provide a link to a compiled version of x64.exe, and I haven't seen any complaints about that. I also include the source code for all the changes I made right there under the compiled files, and also provide a link on the page to where the full source code can be obtained (viceteam.org). I suppose I could just provide a copy of the original source for download on the same page, but it does seem a waste when I can link to viceteam.org's site. Note that the compiled executable I provide could not even be used without having already downloaded the entire package provided on the viceteam.org site.
|
|
|
Post by Cyberjank on Jun 19, 2006 10:32:12 GMT -5
Just an update.
I asked Atolle to set me up with a X128.exe version for a test. Well it works perfectly. No problems at all, that I can tell. I will test it further, later on.
The main thing with this is that one can now run a Centipede BBS via vice now.
I had it running last night, with my special 1571 version of Centipede. It worked like a charm. If anyone is interested, this slimmed down 1571 Version is located on my BBS - feel free to download it.
By default It will need a blank disk in device 9 for the accounts file, and you will need to load"bbs-setup",8 and get the account file created, and change the baud rate to 38400 before it will work.
I tried to change the TCPser settings to take 57600, and it ran pretty slow, so Im not sure why that would be. 38400, is plenty fine.
Anyway, Congrats once more to Atolle for a job well done.
CJ
call a real Commodore BBS today. telnet://madworld.bounceme.net
And for grins, try the Vice Test BBS I do not know how long it will be online, its slow and lame, only for a test.
telnet://madoworld.bouncme.net:6400
|
|
|
Post by Excalibur on Jun 19, 2006 14:09:28 GMT -5
Probably something with the high speed routines. Maurice posted somewhere that the swiftlink routine max at 38400 but the turbo232 routines allow more. So if centipedes routines are fashioned after swiftlink and not the t232 that might explain it.
|
|
|
Post by atolle on Jun 19, 2006 14:15:05 GMT -5
<snip>... I tried to change the TCPser settings to take 57600, and it ran pretty slow, so Im not sure why that would be. 38400, is plenty fine.... <snip> VICE currently doesn't support speeds above 38400, because it doesn't emulate the extra functionality found in the Turbo232 hardware. If you try to set the speed above 38400, it will default to something like 300bps.
|
|
|
Post by Cyberjank on Jun 19, 2006 14:20:11 GMT -5
That sounds about right, but then again, we need nothing faster than 38400 baud anyway...
Excalibur: Centi takes Turbo-232's or Swiflinks all the way up to (234000? - may not run that fast, but claims to), so its definately the limitation in Winvice.
|
|
|
Post by atolle on Jun 19, 2006 18:06:15 GMT -5
Good news everyone (especially you Excalibur)... I've fixed the userport code in VICE. Now it even with programs that use the Hug Wedge routines.
It turns out there was a bit that wasn't being set in the interrupt control register. They commented out the code in one part of the source, but forgot to add it back in at other parts.
The only thing I wasn't able to get working right was DTR signaling. DTR is basically always on for tcpser. So hopefully whatever program you are using knows how to send a break (+++) and hang up that way, rather than hanging up via DTR.
I'll post the new files when I get home tonight.
|
|
|
Post by atolle on Jun 19, 2006 20:47:20 GMT -5
The new versions are up now at gcns.comGood news everyone (especially you Excalibur)... I've fixed the userport code in VICE. Now it even with programs that use the Hug Wedge routines. It turns out there was a bit that wasn't being set in the interrupt control register. They commented out the code in one part of the source, but forgot to add it back in at other parts. The only thing I wasn't able to get working right was DTR signaling. DTR is basically always on for tcpser. So hopefully whatever program you are using knows how to send a break (+++) and hang up that way, rather than hanging up via DTR. I'll post the new files when I get home tonight.
|
|