Re: [ql-users] MDVs Versus FLPs
Those who suggested a serial lead link from blackbox to PC direct or to another blackbox - sounds great but where do I get the info on the link cable, plugs, pinouts etc and do I need to write some software to control it all? I once had two QL Aurora/SGC/QuBide rigs connected together via the network sockets with a twisted pair (that's the cable - not my wife and I !!) and although it was very slow, the results were positive. Is this the way to go? Once again, I plead for help. Now where are my back copies of QLToday? - thanks for the comments Dilwyn. Serial cables were also covered in Vol 7 Issue 1 (May/June 2002) page 28 of QL Today. (So grateful to Brian Kemmett for the QL Today indexes to help find these things!) Once you have the correct cable, keep the baud rate low (4,800 or 9,600 baud maximum) to connect to PC. No extra software should be needed, but you might need help with the PC side of things. Here's the basic wiring diagram from that QL Today. Best to use SER2 for QL to PC communication, as wiring is a bit easier since ser1 is basically wired as though it was a modem. If you do use ser1, simply swap pin 2 and 3 over, and swap pin 4 and 5 over. QL PCPCPC SER2Signal 25pin9 pin 2 (TxD) RxD 32 3 (RxD) --- TxD 2 3 4 (DTR=RTS) -- CTS 5 8 5 (CTS) -- RTS 4 7 1 (GND) - GND 7 5 I think (the article doesn't say this) that pin 6 of a QL serial port plug is the one nearest the latching pin. It is not connected for the purposes of these cables and file transfer, but I think it carries +12v, so might cause some damage to interfaces if wired wrongly, although you could test my assumption by using a tester to determine which pin is +12V since that will identify pin 6. Although ser2 pin 4 is shown in the QL manual as DTR, Tony Firshman told me a while back it is more like an RTS signal as far as making these cables is concerned. You can then see that making up a serial cable is a simple matter of cross connecting the relevant signals, i.e. RxD to TxD and vice versa, and RTS to CTS and vice versa, and connecting the two ground signal lines together. If you get the TxD and RxD wires connected up right but not the other two handshaking ones, one sympton might be that the transfer works for very short files only, or only at very low baud rates. Go to a Maplins store and get a serial port wiring tester, they save a lot of time and frustration with serial ports! As far as software is concerned you shouldn't need anything extra. On the QL, just a COPY MDV1_filename TO SER2 should work (if you have Toolkit 2 use COPY_H instead of the COPY command to force it to copy the header). If you are copying to DOS or Windows you will need the equivalent command from DOS command line on the PC (in Windows XP, go to All Programs, Accessories, Command Prompt). In Windows XP anyway you can get help on its copy command with the command COPY /? (the /? switch telling it to print some help). From memory, I can't remember the full command, but it's something like: COPY COM1: C:\directory\filename You can also include a switch in the DOS command to specify if it is an ASCII or binary file /A for ASCII (text) or /B for binary If you are copying using the QL emulator on the PC, simply use the COPY or COPY_H commands on the emulator as well: COPY ser1 TO win1_directory_filename (obviously use ser1 or ser2 depending on which serial port used ont he PC). I confess to being a bit of an idiot with serial links. Tony Firshman swears there is nothing hard about the subject, but I always seem to run into every problem possible when I try, so good luck. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.9.0/37 - Release Date: 16/07/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] QL Serial ports and null modem cables
Dilwyn Jones wrote: ... I think (the article doesn't say this) that pin 6 of a QL serial port plug is the one nearest the latching pin. It is not connected for the purposes of these cables and file transfer, but I think it carries +12v, so might cause some damage to interfaces if wired wrongly, although you could test my assumption by using a tester to determine which pin is +12V since that will identify pin 6. Just to confirm, pin 6 (+12v to be used to assert any control line, eg DSR, DCD) is next to the clip. Although ser2 pin 4 is shown in the QL manual as DTR, Tony Firshman told me a while back it is more like an RTS signal as far as making these cables is concerned. You can then see that making up a serial cable is a simple matter of cross connecting the relevant signals, i.e. RxD to TxD and vice versa, and RTS to CTS and vice versa, and connecting the two ground signal lines together. The DSR/DTR RTS/CTS handshake pairs have always been something of a confusion to me. As far as I understand these lines, they are: DTR - Data Terminal Ready: terminal is ready for input DSR - Data Set Ready: modem is ready to send data to terminal RTS - Request To Send: ... terminal wants to send data CTS - Clear To Send: . modem is ready to receive data from terminal. So logically, crossing RTS/CTS on a DTE-DTE null modem cable makes no sense: the Request To Send from one terminal is connected to the Clear To Send on the other; or to put it another way: If terminal A wants to send data (raises RTS), terminal B gets the signal telling it it's ok for it to send data to terminal A (CTS goes high), and terminal A gets no signal that terminal B is ready to input the data terminal A wants to send to terminal B - that would happen the moment terminal B decided it wanted to send some data to terminal A and raised its RTS line (causing terminal A's CTS line to go high). The serial ports on the QL were rather a cludge. They are both split into two halves, with the 8749 second processor handling the input side of both, and the ZX8302 ULA handling the output side of both. Output of data from the QL is fairly straightforward: The ZX8302 assumes the relevant request line is raised (use the +12v line if necessary) and awaits clearance on the relevant control line (Ser1.DTR or Ser2.CTS). Then it sends the data on the relevant data line (Ser1.RXD or Ser2.TXD) - shifting out the bits at the baud rate. Input of data to the QL is rather more complicated: The input lines (Ser1.TXD Ser2.RXD) are tied (via logic gates) together and appear on one data pin (port) of the processor (and the interrupt line). The start bit causes the processor to interrupt, which then shifts the data in at the relevant baud rate (I presume). Thus ONLY ONE serial port can receive data at any one time. Hardware handshaking is [almost] vital to ensure correct input of serial data - especially if both ports are being used. The way it is done is that the 8749 asserts the ready for input line (Ser1.CTS Ser2.DTR - of the port on which it is expecting data) for a short time and then clears it. If both serial ports are open, it then asserts the other one. This flip-flop nature of the control line(s) can be observed by a LED serial port tester. Thus, the QL uses the following: Ser1.CTS Ser2.DTR to control when it is ready to receive input Ser1.TXD Ser2.RXD to recive input from another device Ser1.DTR Ser2.CTS to control when another device is ready to receive input Ser1.RXD Ser2.TXD to send output to another device As the QL uses non standard connectors, perhaps it'd be better to rename the port pins: PinSer1Ser2 1 GND GND GND = signal GrouND 2 DTQ DFQ DTQ = Data To QL 3 DFQ DTQ DFQ = Data From QL 4 RFF RFT RFF = Ready For From 5 RFT RFF RFT = Ready For To 6 +12 +12 RFF is set by the other device saying it's ready for data From the QL RFT is set by the QL saying it's ready for data To the QL. Thus a QL to QL cable would cross DTQ/DFQ and RFF/RFT (for Ser1 to Ser2, this crossing would occur with a straight through 1-1, 2-2, 3-3, 4-4, 5-5 cable; with Ser1 to Ser1, or Ser2 to Ser2, the crossing would occur with crossed pairs: 1-1, 2-3, 3-2, 4-5, 5-4). Thus, I think a cable from the QL to a PC would connect: DTQ -- TXD = Data transmitted To QL DFQ -- RXD = Data received From QL RFT -- CTS = Clear To Send To QL RFF -- DTR = Ready to receive data From QL* GND -- GND = Signal ground *DTR would probably always be asserted by a PC as their serial ports can usually handle input at any time; thus the RFF control line could be looped to the +12 line (pin 6) so that the QL always thinks it can send data. The only vital line is the RFT control line - the QL _MUST_ be allowed to control the flow of data to the serial port otherwise framing, or other errors will occur. Is
Re: [ql-users] WMAN2 program
Dilwyn Jones wrote: Programs like the one you describe use the System Palette, a method of describing pre-defined colour schemes to help provide standardised appearances for program displays. Although this existed to some extent in older pointer environments (you can see the standardised appearances or 'colourways' in QMenu menus, QPAC2 menus and so on), Actually, there was no support for colour schemes whatsoever in the PE. All programs that supported colour schemes had to do them themselves. The rest sounds fine. Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL Serial ports and null modem cables
Robert Newson wrote: ... Hardware handshaking is [almost] vital to ensure correct input of serial data - especially if both ports are being used. The way it is done is that the 8749 asserts the ready for input line (Ser1.CTS Ser2.DTR - of the port on which it is expecting data) for a short time and then clears it. If both serial ports are open, it then asserts the other one. This flip-flop nature of the control line(s) can be observed by a LED serial port tester. Forgot to mention: the rate at which the control line flip-flops is dependent on the baud rate - the higher the baud rate, the faster the flip-flop; it must be syncronised with the baud rate clock? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Psephological Nerds
For the psephological nerds in our midst (and I suspect I am the only one!), I have posted the 2005 version of my election analysis program on my election page. You can also now download the complete archive from 1983 to 1997, http://members.lycos.co.uk/geoffwicks/election.htm Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MDVs Versus FLPs
On Sun, 17 Jul 2005 at 13:16:23, Dilwyn Jones wrote: (ref: [EMAIL PROTECTED]) Those who suggested a serial lead link from blackbox to PC direct or to another blackbox - sounds great but where do I get the info on the link cable, plugs, pinouts etc and do I need to write some software to control it all? I once had two QL Aurora/SGC/QuBide rigs connected together via the network sockets with a twisted pair (that's the cable - not my wife and I !!) and although it was very slow, the results were positive. Is this the way to go? Once again, I plead for help. Now where are my back copies of QLToday? - thanks for the comments Dilwyn. Serial cables were also covered in Vol 7 Issue 1 (May/June 2002) page 28 of QL Today. (So grateful to Brian Kemmett for the QL Today indexes to help find these things!) Once you have the correct cable, keep the baud rate low (4,800 or 9,600 baud maximum) to connect to PC. No extra software should be needed, but you might need help with the PC side of things. If you have Hermes, use 19200 (you will get a bit less than 14400 throughput). With superHermes you can use 57,600. Here's the basic wiring diagram from that QL Today. Best to use SER2 for QL to PC communication, as wiring is a bit easier since ser1 is basically wired as though it was a modem. If you do use ser1, simply swap pin 2 and 3 over, and swap pin 4 and 5 over. QL PCPCPC SER2Signal 25pin9 pin 2 (TxD) RxD 32 3 (RxD) --- TxD 2 3 4 (DTR=RTS) -- CTS 5 8 5 (CTS) -- RTS 4 7 1 (GND) - GND 7 5 This is exactly right Although ser2 pin 4 is shown in the QL manual as DTR, Tony Firshman told me a while back it is more like an RTS signal as far as making these cables is concerned. Indeed it is. You can then see that making up a serial cable is a simple matter of cross connecting the relevant signals, i.e. RxD to TxD and vice versa, and RTS to CTS and vice versa, and connecting the two ground signal lines together. As far as software is concerned you shouldn't need anything extra. On the QL, just a COPY MDV1_filename TO SER2 should work (if you have Toolkit 2 use COPY_H instead of the COPY command to force it to copy the header). If you are copying to DOS or Windows you will need the equivalent command from DOS command line on the PC (in Windows XP, go to All Programs, Accessories, Command Prompt). In Windows XP anyway you can get help on its copy command with the command COPY /? (the /? switch telling it to print some help). From memory, I can't remember the full command, but it's something like: COPY COM1: C:\directory\filename It is -much- better to use a comms program each end, and use a file transfer protocol. qtpi and zmodem are perfect the QL end. I confess to being a bit of an idiot with serial links. Tony Firshman swears there is nothing hard about the subject, but I always seem to run into every problem possible when I try, so good luck. (8-)# It helps having sold the Astracom modem and QuaLsoft file transfer. All my -hard- work was done by 1989! Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL Serial ports and null modem cables
On Sun, 17 Jul 2005 at 15:39:53, Robert Newson wrote: (ref: [EMAIL PROTECTED]) Dilwyn Jones wrote: ... I think (the article doesn't say this) that pin 6 of a QL serial port plug is the one nearest the latching pin. It is not connected for the purposes of these cables and file transfer, but I think it carries +12v, so might cause some damage to interfaces if wired wrongly, although you could test my assumption by using a tester to determine which pin is +12V since that will identify pin 6. a vast amount snipped *DTR would probably always be asserted by a PC as their serial ports can usually handle input at any time; thus the RFF control line could be looped to the +12 line (pin 6) so that the QL always thinks it can send data. The only vital line is the RFT control line - the QL _MUST_ be allowed to control the flow of data to the serial port otherwise framing, or other errors will occur. Yes indeed. That was the problem with receive and the 8049. It used to get totally out of sync if it, for instance, had to make a sound, and that was with correct RTS/CTS handshaking. Is this a load of twaddle, or does it make any sense? It is probably correct, but there is far too much for a poor mortal like me to digest (especially this late). Dilwyn's reply was 100% right, and doesn't add any more terms to try to remember! Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
