The Sinclair QL Forum

Hi,

the most established method of getting files to and from a Q68 from a PC is to use QXLWinReader by Wolfgang which allows to read and write to a Q68 (or QL-SD, for that matter) SD card directly from a PC (that's why you have 2 slots for SD cards on your Q68)

Another well-working method is to use QPC2 and mount the SD card file system from there, which gives you native-to-native transfer (without any chance to lose file headers)

Tobias

tofro wrote:Hi,

the most established method of getting files to and from a Q68 from a PC is to use QXLWinReader by Wolfgang which allows to read and write to a Q68 (or QL-SD, for that matter) SD card directly from a PC (that's why you have 2 slots for SD cards on your Q68)

Another well-working method is to use QPC2 and mount the SD card file system from there, which gives you native-to-native transfer (without any chance to lose file headers)

Tobias

Thanks Tobias, I usually use QemuLator, I suppose I'll have to learn QPC2 as well now.

Whopper

Whopper wrote:

tofro wrote: Another well-working method is to use QPC2 and mount the SD card file system from there, which gives you native-to-native transfer (without any chance to lose file headers)

Tobias

Thanks Tobias, I usually use QemuLator, I suppose I'll have to learn QPC2 as well now.

Whopper

The second method proposed should work with Q-Emulator (full version) as well.

Tobias

Hi,

You do not need a Serial Card, a USB - Serial adapter and a use a Null Modem lead to connect thePC to Q68.

The Q68 does not have any hardware flow control. So you need to software flow control.

I would not use Kermit, the QL implementation is not too good. Use QTPI on the Q68 side and any Terminal that supports Zmodem, so you can batch transfer zipped files.

But I mentioned earlier, set up Sernet with QPC2 or SMSQmulator and trabsfer using QPAC2 Files Thing.

Or just copy the files into a QWA container on the SD Card with QXLWINReader.

Personally, I insert the Q68 SD Card into my Linux laptop and mount the QWA file for WIN1_ into SMSQmulator WIN slot and copy files that way.

Zipped files can be read from a FAT16 directory on the Q68. The SD Card supplied has a FAT16 partitoon on the SD Card, which is defined by the FAT device using the FAT_DRIVE command.

The syntax is: FAT_DRIVE fat_no, card_no, partition_no

The FAT partition on the supplied SD CARD is on Partition 2, so the Fat Drive command is: FAT_DRIVE 1,1,2

Use standard file commands to acces the files with FAT1_

Pease read the Q68 SMSQ/E manual which detsils all this.

Thank you Derek.

Whopper

Hi,

Just had thought, if you put the software to be transferred to the Q68 in a FLP or MDV image, with QEMulator and copy these files to the FAT1 partition. Then copy the FLP/MDV images to a QWA partion and use FDI/MDI to ,ount the images as drives.

You could also leave the image file on the FAT partition and mount the image from there.

This save worrying about file headers.

I use FDI to run the DP collection as FLP images.

Whopper wrote:Does the Q68 have any ethernet access? Or is anyone looking at providing ethernet access?

Good and bad news. First the good news:

Last summer I have already accessed the internet with the Q68 over ethernet. I successfully used ICMP ping, TCP echo, webserver, textmode webbrowser, POP3 email.
This was achieved by modifying my QLwIP software for the Q40 and Q60, mostly by replacing the RTL8019 driver by a (still rudimentary) CP2200 driver.

Now the bad news:

1. I did the original QLwIP work two decades ago and forgot too much to continue in a "nice" way. I was discouraged from further work when I saw there would be no free operating system for the Q60 except QDOS Classic. At the time, I was in the middle of massive code changes toward OS integration. Unfortunately I forgot what exactly I did back then, and in which exact state various source branches were. I can not even exactly reproduce my binaries for the Q60 anymore. E.g. sending emails no longer works, although I had certainly tested that a lot. So my successful Q68 demo was a quick workaround, that went back to an early "all in one" QLwIP version, which had the whole TCP/IP stack, most of the ethernet driver, and several user applications included within the same exectutable.

2. Compatibility issue. The existing QL emulator TCP/IP interface is not usable for native hardware, because it includes no support to bring up/down interfaces and manage IP setup. Very easy for emulators, they can simply assume the host PC has everything already configured and running. (Beside the fact that no actual TCP/IP nor ethernet code is included at all.) Also, the emulator API is quite unsuitable for QLwIP and would add overhead if added "on top" of the native TCP/IP stack.

3. There are open fundamental questions on which I have no clear answer. How about all the encryption requirements nowadays (which are huge work to implement as QL code and would be slow) ? Would my QL side internet applications like webbrowsing and email still make sense today, even if they were improved? What exactly should a Q68 be able to do over the internet? Or do people only want to use Q68 ethernet in the LAN , mostly for file transfer? Is a decent TCP/IP API still worth the effort (there was practically no application development for two decades) or do I better release a simple "all in one" executable, so people have something that works at all?

Whatever I decide, it will take time... I can maybe demonstrate working Q68 ethernet and TCP/IP at a meeting like Mahlerts - I'm not talking vapourware. On the other hand, I have no plans for a public release yet, so QLwIP should not discourage other possible projects. For example, I could imagine sort of "QLNET over ethernet" instead of a full-featured multitasking TCP/IP suite like QLwIP.

Peter

By the way, the CP2200 chip is well suitable for the QL, it has a directly compatible, 5V tolerant 8 bit bus interface. Should Q68 ethernet software be released, the QL can benefit.

According to SiLabs and CMX page, there is "royalty-free MicroNet TCP/IP stack from CMX", for the "Freescale 68k" processor.
But they require registration for download.
http://www.cmx.com/cmx_dload.htm

Peter wrote:

Whopper wrote:Does the Q68 have any ethernet access? Or is anyone looking at providing ethernet access?

Good and bad news. First the good news:

Last summer I have already accessed the internet with the Q68 over ethernet. I successfully used ICMP ping, TCP echo, webserver, textmode webbrowser, POP3 email.
This was achieved by modifying my QLwIP software for the Q40 and Q60, mostly by replacing the RTL8019 driver by a (still rudimentary) CP2200 driver.

Now the bad news:

1. I did the original QLwIP work two decades ago and forgot too much to continue in a "nice" way. I was discouraged from further work when I saw there would be no free operating system for the Q60 except QDOS Classic. At the time, I was in the middle of massive code changes toward OS integration. Unfortunately I forgot what exactly I did back then, and in which exact state various source branches were. I can not even exactly reproduce my binaries for the Q60 anymore. E.g. sending emails no longer works, although I had certainly tested that a lot. So my successful Q68 demo was a quick workaround, that went back to an early "all in one" QLwIP version, which had the whole TCP/IP stack, most of the ethernet driver, and several user applications included within the same exectutable.

2. Compatibility issue. The existing QL emulator TCP/IP interface is not usable for native hardware, because it includes no support to bring up/down interfaces and manage IP setup. Very easy for emulators, they can simply assume the host PC has everything already configured and running. (Beside the fact that no actual TCP/IP nor ethernet code is included at all.) Also, the emulator API is quite unsuitable for QLwIP and would add overhead if added "on top" of the native TCP/IP stack.

3. There are open fundamental questions on which I have no clear answer. How about all the encryption requirements nowadays (which are huge work to implement as QL code and would be slow) ? Would my QL side internet applications like webbrowsing and email still make sense today, even if they were improved? What exactly should a Q68 be able to do over the internet? Or do people only want to use Q68 ethernet in the LAN , mostly for file transfer? Is a decent TCP/IP API still worth the effort (there was practically no application development for two decades) or do I better release a simple "all in one" executable, so people have something that works at all?

Whatever I decide, it will take time... I can maybe demonstrate working Q68 ethernet and TCP/IP at a meeting like Mahlerts - I'm not talking vapourware. On the other hand, I have no plans for a public release yet, so QLwIP should not discourage other possible projects. For example, I could imagine sort of "QLNET over ethernet" instead of a full-featured multitasking TCP/IP suite like QLwIP.

Peter

Peter had given me an early test of that driver for my Q40 (Btw: I still need to upgrade that to a Q60 ) and it worked great. I'd love to see QLwIP again and use it. Playing with the ESP the last few days to get it to connect to the nxtp server is working but it's a sub-optimal way to do thing; whereas I could just talk with an OPEN_IN #ch, "TCP_address:12300" I now need to send AT commands to the serial port which is very counter productive. Works though