Yet another XFer in C thread - Linux this time

[simmo1010]

Yes, I probably should be using UPURS, but I have a nice beeb->RS232 cable for terminal work and I'd like to use what I have. And I'm stubborn.

I'm using XFer 5.3b from Greg Cook's site (http://regregex.bbcmicro.net/) with a USB-Serial converter based on the Prolific Technology PL2303 on Arch Linux. The BBC->DB9 cable is in the DSR/DTR configuration ...

Code: Select all

Pin   Pin
(9 P) (25 P)    PC                              BBC           Pin
----- ------    --                              ---           ---
 5     7        0V (Ground)                     Gnd (Ground)   1
 2     3        RxD (Data in)   <-------------  TD (Data out)  5
 3     2        TxD (Data out)  ------------->  RD (Data in)   2
 1     8        DCD             <--+----------  RTS            3
 6     6        DSR             <--+
 4     20       DTR             ------------->  CTS            4
 7     4        RTS             ---+
 8     5        CTS             <--+

I'm finding that I can only get the initial handshaking to work if I force the baud rate to 1200 (-b 1200). Using Termulator on the BBC (set to 1200 baud) I can see that the initial sync message is corrupt (just a couple of random characters) at any other speed, but is fine when forced to 1200 baud. I'm no linux kernel programmer (or C programmer for that matter), but I can see from the source code that XFer sets the line speed to 1200 for the initial sync and then resets it to the requested speed. The change in line speed works - after the corrupt sync message Termulator receives valid commands from the XFer linux client when set to the transfer speed. I have tried the included binary, and a version compiled from source.

To test the cables I borrowed my wife's Windows 10 laptop and that works fine using the windows binary from the same download, so I'm assuming this is a Linux feature. I'm pretty sure it isn't a hardware issue with my Arch linux desktop/USB-serial cable as I use that all the time with ADTPro and my Apple II.

I've tried search the other XFer posts, but can't find any reference to this.

I should also say a huge thankyou to the contributors to XFer - I wasn't expecting it to be able to create CP/M disks, but worked first time (from the Windows laptop).

Cheers,

Ian.

[sweh]

Looking at the code at https://github.com/rhargreaves/bbc-xfer I can see linux.c, win32.c and xfer.bas all do this speed change; initially set to 1200 for handhake and then switch to the requested speed.

I wonder if there could be a timing issue; if one side switches speed and starts sending data before the other side has switched speed. Hmm. Dunno. Just guessing!

Anyway, a work around could be to change the speed to be the faster one. (If you're using a different code version then the line numbers might be different but the change should be the same.)

In linux.c change line 55 from

Code: Select all

  lconfig.baudrate = XFER_B1200 ;

to

Code: Select all

  lconfig.baudrate = XFER_B9600 ;

and in xfer.bas change

Code: Select all

 4170*FX 7,4

to

Code: Select all

 4170*FX 7,7

At least that'd be my guess at a kludge!

[simmo1010]

Thanks Stephen - that fixed it. I really should have been able to work that out for myself - what can I say, it was getting late!

Cheers,

Ian.

[simmo1010]

Hmmm - spoke too soon. That allows the sync message to work and I can use the * commands to get stuff back from the BBC, but gives CRC errors on track 0 when I try and transfer images.

I tried commenting out the lines in main.c that flush the com line and reset the line to the new speed, but still have the CRC errors on track 0. Also tried dropping the speed to 2400, but same issue.

I'm wondering if I am barking up the wrong tree - maybe my linux installation doesn't like DTR/DSR flow control on a USB serial adapter but Windows 10 has a better driver?? I'm not sure what flow control ADTPro uses (which works successfully from linux with this USB converter) - a quick google search suggests xon/xoff.

At least I can get disk images across using Windows, I might try and get a copy of kermit to see if it can manage larger transfers at 9600 with hardware flow control.

Thanks again,

Ian.

[sweh]

Yeah, there's a reason why MartinB recommends FTDI adapters for UPURS; they normally have working flow control. PL2303 have, historically, been problematic with hardware flow control but I'm not sure if that was linux drivers or a hardware problem.

[simmo1010]

Sorry to drag this out, but just for the record ... I dug out an FTDI USB serial converter, and had exactly the same results as the PL2303. I'd be interested to hear if anyone is successfully using XFer on linux with a USB converter and the DST/DTR cable - there is always the chance there is something weird going on with my Arch installation.

The best way to resolve this would be to build an RTS/CTS cable, but I decided that if I'm going to build another cable I might as well build a UPURS cable. Can I just say wow - much as I like XFer, UPURS is *amazing* ...

[sweh]

Oh, I'm sorry... I missed that first time round.

DTR/DSR is not meant to be used this way, especially on Linux. The kernel uses cts/rts for hardware flow control. DTR was used to assert "I'm powered on" so seeing that drop was a way of letting the other know it can hangup (e.g a modem seeing this would know it can hangup any call in progress).

(Well, things may have changed with modern kernels 'cos I recall a patch but I dunno if it ever made it to the mainstream; definitely when I was doing serial stuff as my day job this is how it was).

When connecting the Beeb serial port to a PC you should use CTS/RTS signalling for hardware flow control. And avoid the CH341 'cos they don't seem to do it all.

And a thread from 2013 - viewtopic.php?t=6146

[MartinB]

Can I just say wow - much as I like XFer, UPURS is *amazing* ...

You, my friend, are a great technical discerner and you will be going straight on my Christmas card list

[scruss]

And avoid the CH341 'cos they don't seem to do it all.

They don't usually break it out. If you're handy with the patch wire you can add those signals to a CH341. Or spend a little on the truly wonderful CH343, which does it all