Re: transfer from pc to ql is it possible
Posted: Wed Apr 08, 2015 2:21 pm
any help please
RIP Sir Clive Sinclair 1940 - 2021
https://qlforum.co.uk/
Code: Select all
1360 IF LEN(port$)>5 AND port$(5) INSTR 'eoms'
Code: Select all
410 SBYTES (dest$),adr,length
Code: Select all
410 SBYTES dest$,adr,length
Nope, this is all perfect sir!ppe wrote: Step by step instructions, apologies if I'm being too verbose with the explanations:
I've even tried it at a slower baud (both 1200 and 600) to no avail.ppe wrote: 15) When you see the "Press enter to start receiving" prompt, go to TeraTerm and choose "File/Transfer/XMODEM/Send...". Make sure "Checksum" is selected as "Option" at the bottom of the file chooser dialogue box. Choose the qterm_cde binary file from where you unzipped it. Once you have selected the file you should see an "XMODEM Send" window pop up. Now press Enter at the QL prompt. If all goes well, you should see progress messages on the QL and the progress bar should advance in TeraTerm, speed should be around 220 bytes per second or so. The transfer will take around three minutes, I believe. Once the transfer is over, the receiver will save the received binary.
QL Service Manual wrote:
SER2 (J5) and J6 (SER1) are two RS232 connectors.
J6 is connected so that the device connected to it may act as the Data Terminal Equipment (DTE) which originates the Data Terminal Ready (DTR) signal. J5 connects to the Data Communications Equipment (DCE) i.e. the local QL assumes DTE status.
4.8
The RS232 interface uses an 11-bit ASCII data frame, viz. one start bit, eight data bits and two stop bits comprise one character. Two stop bits are always sent but the interface receives compatibly with one except at 9600 baud, where one and a half stop bits are required. Data is transmitted asynchronously in the full duplex mode.
4.9
Consider the QL as the DTE. Both DTE and DCE are switched on and have their DTR signals asserted. CTS and DTR (Clear to Send, Data Terminal Ready) do not form a handshake pair but are similar signals going in opposite directions. Serial data is transmitted by IC23 via driver IC25/6 and received by line receiver IC26/11. From IC26/11 data is fed to NAND gate IC27/9, pin 10 of which is set to the high state by the program, and input to IC24 pins 6 and 21 via IC27/11.
Thanks Dilwyn, appreciate the reply. I don't think it's a control code because I've got to the part where I'm running Petri's XModem code - so in theory that is handling any control codes now. Given that it seemed to work for other people, and obviously Petri too, I can only assume that there is something in the protocol that requires more from my cable than the simple ascii file transfer does (different kind of handshaking, any my cable not having all the right pins connected etc?) or that Petri's program is asking too much of an unexpanded JM machine. I will take a look at the XModem protocol tonight though and see if there is anything implicit in there that would indicate my problem Thanks again!dilwyn wrote:This is just a stab in the dark robsoft - since _bas files are essentially ASCII codes 32 to 127 most of the time, and _cde files could easily contain the entire ASCII range 0-255 is it possible that, say, a character with a code value of 0-31 somewhere in the file could be acting as a control code to prevent successful transfer (not knowing how the modem transfer software works, I can't be sure).
Hi Derek, and thanks. I did appreciate the ports were wired differently; I've had success transferring -bas files on SER1, but not on SER2. So I've been conducting the rest of my experiments strictly on SER1 (thus far).Derek_Stewart wrote:The problem you have is the QL SER ports are not wired the same, from memory, SER2 is a DCE and SER1 is DTR, see QL Service manual page 10, Figure 1 for QL RS232 schematic
I don't think that's how the comms protocol was set up in my experiment, I'm sure it was just the 1 stop bit, so I can have a look at that. Thanks for that!Derek_Stewart wrote:The RS232 interface uses an 11-bit ASCII data frame, viz. one start bit, eight data bits and two stop bits comprise one character. Two stop bits are always sent but the interface receives compatibly with one except at 9600 baud, where one and a half stop bits are required. Data is transmitted asynchronously in the full duplex mode.
Ah. A lightbulb goes on. At the moment, I've got my QL-RS232 cable plugging directly into the Proliant USB thing. I wonder if this is sufficient to work for something small/simple like the _bas file transfer, but that I do need a proper null modem cable in between the 2 connectors for anything more sophisticated to work. I'll jury-rig up some kind of pin breakout and try messing around with the connections a bit more tonight - thanks again, I appreciate your time and inputDerek_Stewart wrote:The maximum reliable Baud rate I used to get is 9600 Baud, connected with a standard Null Modem lead. Or swapping around the control lines at one, which more easy done at the PC end.