Re: [ql-developers] HTTP server speed test
Tony Firshman wrote: Unfortunately I have no second PC so I can only measure from PC to Q60 and vice versa. I am sure I have such a card. I will fit it in one of the nine PCs here tomorrow (5 run 24/7!) and test. It may not be until the evening. Many thanks! I did have an NE2000. However I am haivng trouble under W98. It is not pnp but W98 found and installed it with NE2000 compat driver. It though did not show up on my switch. I connected the 'default' jumper, and it now show the 10mbps conneciton LED, which flashed reassuringly on startup. It also show up as working under device mgr. However it is not finding my network. Any ideas? I have played with a few IRQs. Default was 3, and it is now: IRQ 9 I/O 0300-031F All was fine with the existing pci card, which I removed. Maybe selecting TCP/IP protocol under network bindings? However tinkering with your Windows settings looks like more trouble than this test is worth. I don't want you to waste too much precious time. Many thanks, Peter
Re: [ql-developers] HTTP server speed test
Tony Firshman wrote: I have not managed to get my debian system to install a mouse successfully, so only have command line. Is there a command line ethereal? Not that I know. If you only have a commandline, you could transfer the file with curl, which I remember to have a useful speed display. But it displays the payload rather than the raw data, so it will not directly compare to my figure. If it works I can measure with curl for comparison. Peter
[ql-developers] HTTP server speed test
Hi, is somebody out there who owns two networked PCs, one with a 10 Mbit/sec ISA NE2000 (or clone) card, and could do a speed test using this PC as HTTP server? With the Q60/QLwIP as server I currently get average 854 kBytes/sec HTTP throughput, measured with Ethereal, transferring a file larger than 10MB. It would be interesting how far from the optimal value this is still away. My test setup: Server: Q60/80, Realtek RTL8019AS ISA, QDOS Classic 3.25 Beta R, QLwIP Client: Athlon 1.2 GHz, Realtek RTL8029AS PCI, RedHat Linux 9.0, Netscape browser Unfortunately I have no second PC so I can only measure from PC to Q60 and vice versa. Thanks, Peter
[ql-developers] HD max size (was: Re: Linux Q40 Update)
On Mon, 15 Dec 2003 23:37:44 +0100, Richard Zidlicky wrote: !!! WARNING !!! Kernel 2.4.18 (probably anything 2.4.21) will eat filesystems on disks137GB. Read in Documentation/ide.txt of the Linux kernel sources: == How To Use *Big* ATA/IDE drives with Linux -- The ATA Interface spec for IDE disk drives allows a total of 28 bits (8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing individual disk sectors of 512 bytes each (in Linear Block Address (LBA) mode, there is still only a total of 28 bits available in the hardware). This limits the capacity of an IDE drive to no more than 128GB (Giga-bytes). All current day IDE drives are somewhat smaller than this upper limit, and within a few years, ATAPI disk drives will raise the limit considerably. == I suppose your 'Gb' was 10^9 bytes one (the one HD manufacturers use in their spec to make your believe that you got a bigger HD) and not the -true- 1024^3 bytes Giga-byte, so I guess you simply hit the 128Gb limit as described in the doc... Thierry.
Re: [ql-developers] Linux Q40 Update
On Wed, Dec 17, 2003 at 01:19:47AM +0100, Thierry Godefroy wrote: On Mon, 15 Dec 2003 23:37:44 +0100, Richard Zidlicky wrote: Hi, a short roundup of issues I am messing with: !!! WARNING !!! Kernel 2.4.18 (probably anything 2.4.21) will eat filesystems on disks137GB. * chuckles * I didn't even figured out how to get this damned atari_fdisk to properly enable and setup extended partitions, so my 20Gb HD is pretty much underused already... strange, that was not the slightest problem for me.. currently there are 2x60GB disks under the hood. At least you dont have to think about the 137 GB problem. plenty of updated user packages and libs gcc issues: - libgcc_so in gcc3.3 is incompatible with previous versions due to a change (a real improvement actually ;) in m68k exception handling and version number wasnt bumped accordingly.. this makes system upgrades not practical for average user. No chance to install the two libraries in parallele ? would work, but each approach has some drawbacks: - different so-numbers, also different than the rest of the world, forgetting to patch a new gcc release would result in problems. I am not really sure if the version numbers could ever meet again. - different libdir, different loadpath. Default ld.so cant do that without help.. supposedly it is possible to hardcode ldpath into the old binaries but I have never tried. Even worse, having 2 versions of libgcc_so would probably mean to keep 2 version of some other c++ libs. So far I simply ignore the few hundred c++ programs that are broken by the new libs in the hope to get them recompiled soon. So a gcc v3.2 or 3.3 for the Q60 soon ? :-) perhaps 3.4, the coreutils/sha1 problem turned out to be very likely another 3.3.x bug.. one of those really nasty to debug ones. On an obscure sidetrack of development, I have a functional but slightly buggy native ocaml compiler for m68k (http://www.ocaml.org/).. needed a fast and reliable RAD language to update the dated, slow and insecure cgi scripts in the Q40 distribution. RAD ? rapid application development, buzzword but you get the idea. It beats most other langauages when comparing lines of code length while still beeing slightly more readable than APL or perl. Ocaml is also one of the few high level languages that can beat the speed of compiled c on many tasks. Richard
Re: [ql-developers] News RPMs for Q60-Linux
On Sun, Dec 14, 2003 at 11:40:14AM +0100, Thierry Godefroy wrote: Hello all ! I'm in the process of updating my Linux-Q60 website. New RPMs have already been made available: - Patches for Linux kernel v2.4.23. - Linux kernel v2.4.23 (with cryptoloop and supermount patches). wrt supermount, did you look at http://submount.sourceforge.net/? - losetup/mount v2.11z: crypto-API aware, compatible with the old International kernel crypto patch. Should also work with loop-AES (untested). it may work only partially with loop-AES, iirc some options are different - dillo v0.8.0-pre: CVS pre-release (expect many core dumps !) with patch for frames support ! very good news! Richard
Re: [ql-developers] News RPMs for Q60-Linux
Welcome back ! Fabrizio - Original Message - From: Thierry Godefroy [EMAIL PROTECTED] To: ql-developers [EMAIL PROTECTED] Sent: Sunday, December 14, 2003 11:40 AM Subject: [ql-developers] News RPMs for Q60-Linux Hello all ! I'm in the process of updating my Linux-Q60 website. New RPMs have already been made available: - Patches for Linux kernel v2.4.23. - Linux kernel v2.4.23 (with cryptoloop and supermount patches). - losetup/mount v2.11z: crypto-API aware, compatible with the old International kernel crypto patch. Should also work with loop-AES (untested). - dillo v0.8.0-pre: CVS pre-release (expect many core dumps !) with patch for frames support ! In the pipeline (i.e. being compiled right now): - gnupg v1.2.3 (fixes a critical security hole in previous gnupg versions). - nedit v5.4RC2. Enjoy ! Thierry Godefroy. __ Tiscali ADSL SENZA CANONE: Attivazione GRATIS, contributo adesione GRATIS, modem GRATIS, 50 ore di navigazione GRATIS. ABBONARTI TI COSTA SOLO UN CLICK! http://point.tiscali.it/adsl/index.shtml
[ql-developers] PD
Hi, does anybody know a working email address from Phoebus? The usual p h o e b u s AT d o k o s - g r DOT n e t is down. Private reply, please. Thanks, Peter
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Sun, Sep 07, 2003 at 10:48:50PM +0200, BRANE wrote: - Original Message - From: Peter Graf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 9:53 PM Subject: Re: [ql-developers] Massive amount of job state transitions and re-scheduling Simple example: A M$ or Unix machine sends a file to the QDOS machine via TCP. It will send one or two packets, then stop and wait for ACK. Further packets will only be sent after further ACKs. Your ACKs can only be generated in 50 Hz rhythm, so packets will crawl one-by-one in 50 Hz rhythm. (Or two-by-two, if you're lucky.) AFAIK with TCP/IP this is negotiable. There is no need for such small window... don't forget this is a rather simple TCP/IP implementation and apparently it is already hard enough to make the simplest variant working reliably with the garden variety of TCP/IP implementations out there. Richard
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
Richard Zidlicky writes: Plus, I'm a bit surprised that you are apparently using jobs to fetch the data from the ethernet card... It should be done via an interrupt handler instead... Actually, the best design would be to have the Q60 fast interrupt handler to fill a buffer, and a frame interrupt task to move the data from that buffer into a bigger one for your job to fetch it in big chunks...). this was discussed a while ago here, the big problem is that neither QDOS nor SMSQ will attempt to reschedule after interrupt handling and there is no way to deal with the complexities of the TCP/IP protocol inside the interupt handler. That means sending of protocol replies would be very often delayed by 1/50s which would make especially TCP crawl.. The last words you wrote the last time we discussed this topic was: Otoh checking for sys_rschd after isr processing looks really trivial and top priority now. Did you ever get round to it? And Peter, did you try out the suggestions that were made at that time? Could the effects Peter mentions have anything to do with the cache? Per
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Sat, 06 Sep 2003 00:24:18 +0200, Peter Graf wrote: Thierry wrote: .../... Plus, I'm a bit surprised that you are apparently using jobs to fetch the data from the ethernet card... It should be done via an interrupt handler instead... At first sight it looks like that of course. QDOS/SMS reality is different though. Actually, the best design would be to have the Q60 fast interrupt handler to fill a buffer, and a frame interrupt task to move the data from that buffer into a bigger one for your job to fetch it in big chunks...). Wrong. 1. TCP is not a linear flow of data into one direction, even if the purpose is file transfer. Yes, this I know, thanks... I'm perfectly aware of the fragmentation and of out of order receipt of TCP packets... That doesn't change the fact you could use the fast interrupt to store as many TCP packet as needed (i.e. when they come in), into a buffer (organized as a linked list of recieved packets), then to transfer the whole lot of packets to the higher level layers of the TCP/IP stack at once and every 1/50th of second... QDOS (and likely SMSQ/E, too) is so primitive that an interrupt service routine can _not_ trigger immediate rescheduling of jobs after it has completed. The time until the next rescheduling can be 20 ms (worst case) so the user job has to wait that time until it can process the data. The effect is that the other TCP endpoint in the network has to wait 20 ms + processing + transfer time until it can react to the response packet. Given MTU=1460=1.5KB your interrupt driven approach can not guarantee more than a throughput of 1.5 KB / 20 ms = 75 KB/s with TCP, even if the other endpoint needs zero time to process it's packets. (75 KB/s is not quite what I want.) Wrong... With my method, you simply get a 20ms penalty (at worst) on the acknowledgment of all the packets that were bufered... I.e. you'll have a (worst case) 20ms penalty when pinging a Q60 on a network, compared to another computer... Unlike an ISR, a job _can_ trigger immediate rescheduling! You don't need to always poll the NIC, a clever approach can lead to full TCP throughput during network activity, but zero polling waste (except for a a few tens of instructions per 50 Hz) when the network is inactive. You don't need to poll the hardware as long as you can use an interrupt to signal the arrival of each new packet. Is the Q60 able to trigger an extrenal interrupt on such conditions ? If yes, then the lowest layer of the TCP/IP stack (actually of the Ethernet driver) could be implemented as the external interrupt handler... The details are somewhat complex, but as long the OS isn't changed, I have no better choice. 2. You waste response (and processor) time by your second copying level. Imagine running the TCP/IP stack on a SuperGoldCard. Copying or not copying about 1 MB every second _does_ matter. Well, aren't we speaking about the Q60 (or Q40) here ? I mean, there's not even an Ethernet I/F on (S)GCs... 3. The idea of collecting fragments into larger buffers is not feasible, unless you implement the TCP/IP stack itself within ISRs. (There are good reasons not to do that!) This is wrong... The low level part is only responsible for moving the data from the hardware into an area of the memory wher it can wait until it's processed... I see no problem at all... Thierry.
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilation error with gcc v3.1)
On Monday 01 of September 2003 19:09, Richard Zidlicky wrote: On Sun, Aug 31, 2003 at 08:04:05PM +, Branko wrote: simply doesn't work if ide-cd is compiled into the kernel, ide-cd claims the driver and ide-scsi can't be activated. This can't be m68k specific but strangely I have't seen anything about it in the linux-kernel ml. Richard At least on Wintel, ide-cd and ide-scsi should always be compiled as a modules... this does work, slightly impractical as it makes it more difficult to use the same kernel for rescue/installation and production use. Richard Except that on the latest 2.4.22 and later it should be possible to use writer as a ATAPI device directly and on kernel 2.6 one should be able to write to /dev/hdx with cdrecord 2.x ... Branko
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilation error with gcc v3.1)
On Sun, Aug 31, 2003 at 08:04:05PM +, Branko wrote: simply doesn't work if ide-cd is compiled into the kernel, ide-cd claims the driver and ide-scsi can't be activated. This can't be m68k specific but strangely I have't seen anything about it in the linux-kernel ml. Richard At least on Wintel, ide-cd and ide-scsi should always be compiled as a modules... this does work, slightly impractical as it makes it more difficult to use the same kernel for rescue/installation and production use. Richard
Re: [ql-developers] ide-scsi option in Linux 2.4.21
On Mon, Sep 01, 2003 at 12:01:39PM +0200, Thierry Godefroy wrote: So you must compile as a module either the ATAPI CD-ROM driver or the ide-scsi driver. I, for one, always built the IDE-ATAPI into the kernel and the ide-scsi as a module, allways do it that way. Apparently stopped working now. But then again, ide-scsi can do everything ide-cd does so appart of saving a few bytes it should work fine to leave out ide-cd and have ide-scsi hardwired. Actually makes installation procedure simpler as CD will be always scd0 then ;) Richard
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linuxv2.4.21 compilation error with gcc v3.1)
On Sun, 31 Aug 2003, Thierry Godefroy wrote: I have been using it since December last and have not noticed any difference, on both my Q60 Q40 On Sat, 30 Aug 2003 11:30:21 +0200, Richard Zidlicky wrote: Btw, did someone notice that hdX=ide-scsi is handled differently in 2.4.21? Hmm... Didn't notice any difference on ix86 plateforms where I use this option (I don't use it on the Q60, for I got no CD-R writer on it)... What's wrong with it ? Thierry ([EMAIL PROTECTED]). John Rawden ([EMAIL PROTECTED])
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilation error with gcc v3.1)
On Sunday 31 of August 2003 16:57, Richard Zidlicky wrote: On Sun, Aug 31, 2003 at 10:36:07AM +0200, Thierry Godefroy wrote: On Sat, 30 Aug 2003 11:30:21 +0200, Richard Zidlicky wrote: Btw, did someone notice that hdX=ide-scsi is handled differently in 2.4.21? Hmm... Didn't notice any difference on ix86 plateforms where I use this option (I don't use it on the Q60, for I got no CD-R writer on it)... What's wrong with it ? simply doesn't work if ide-cd is compiled into the kernel, ide-cd claims the driver and ide-scsi can't be activated. This can't be m68k specific but strangely I have't seen anything about it in the linux-kernel ml. Richard At least on Wintel, ide-cd and ide-scsi should always be compiled as a modules...
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, Aug 23, 2003 at 08:55:28PM +0200, Thierry Godefroy wrote: I got no compatibility problem with the crypto API but for when they changed from 2.2 to 2.4 kernel (the data had to be transfered to a new encrypted volume, but that's all). it will change again for 2.6, probably a few times yet. Also, the crypto API is to become the standard, so I'd recommend starting to get used to it right now instead of using a third party software which seems pretty much incompatible with the crypto API (as far as I could see by reading the loop-AES documentation). the standard is just emerging, it had 2 versions with incompatible disk formats last 2 weeks and mount options are still subject of discussion.. not a good time to get used to it. So far it seems loop-AES can encrypt or decrypt all formats except perhaps some of those with broken IV keys. that looks very strange. Perhaps I can make some sense out of it when I see the patch. Alas, there's some weirdness in the rc.sysinit script of ShoeString: it looks like a line in fstab such as: /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 no idea. What would mount -a do if that line is in /etc/fstab? Mine simply complains no such fs and that's it but I have newer version of the script. I don't see anything in the script itself. # Source functions . /etc/init.d/functions action $Super-Mounting the CD-ROM: mount /mnt/cdrom /mnt/cdrom -t supermount -o fs=iso9660,dev=/dev/cdrom,ro action $Super-Mounting the floppy: mount /mnt/floppy /mnt/floppy -t supermount -o fs=vfat,dev=/dev/fd0 this is a good idea, much easier to provide as fully configured but optional addon. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Thu, 21 Aug 2003 09:58:01 +0200, Richard Zidlicky wrote: On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote: Hi, I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). Serpent is distributed in the ciphers package of loop-AES. It is an extra download but no hassle compile. Btw some recent cryptoanalysis suggests AES is actually less susceptible to a certain type of attack then Serpent so it is far from easy which one is weaker. Still no immediate threat. Actually, this is not quite exact. It is true that more cryptoanalyis was done on Serpent (which algorythm is easier to analyse). But so far more rounds have been broken in AES (Rinjdael) than in Serpent (unless I missed one of the lastest articles about thos algorythms, which is possible). The reason why Rinjdael was choosen as the AES instead of Serpent is unclear and even highly suspicious to me... It is admitedly a little faster than Serpent, but was pointed out as less secure than Serpent too (and as it was not as much crypto-analyzed as Serpent, one may find a shortcut attack on day or another...). My thought is that the NSA is probably quite interested in having an AES algorythm which is not too difficult to break... I personally use Serpent with 256 bits keys for the encrypted partitions on my PCs. It's of course probably too slow for the Q60 though (128 bits keys seem more reasonable for a poor 68060 @ 66MHz to deal with...). What is the advantage of SuperMount over autofs? It's 100% automatic, doesn't need for any demon, and it doesn't hog the processor/drives by checking every few seconds that a new medium was inserted... As soon as an access is requested to a supermounted medium, then a check for changed/absent medium is made transparently for the user. It's the standard 'automounter' for Mandrake and I just love it. :-) appart of the extra demon this sound really very much like what autofs does for me. How does it work to release a medium, eg CD or floppy? With autofs I have to wait until it timeouts. No wait with SuperMount. It's just like if you were using the medium under DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the driver level... The problem is that its author doesn't maintain it anymore and all the maintnance is now done by the Mandrake developers, and scattered in numerous patches to each kernel... There are times were you just can't find a proper (set of) patch(es) applying cleanly to a given kernel... Well, I could make one out of Mandrake's patches for Linux-vanilla v2.4.21 and I use it since v2.4.21 is out without a single problem. I'll put the patch on my q60linux website. ;-) How do you configure it? It's like a filesystem driver. You configure it in fstab, example: /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 More option can be passed to the underlying driver. A doc short is supplied in the patch and appears in the patched Linux sources tree as: Documentation/filesystems/supermount.txt Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't got this problem on i586 Linux... Perhaps would it be worth rebuilding the Mandrake gcc package for Linux-Q60 ? probably not, the problem is m68k specific afaics and Mandrake gets much less non-x86 testing than RedHat or Debian does. Mandrake doesn't develope at all for the m68k architecture, alas... I looked deeper into it, it is the assignment to error.all which barfs the compiler. Translated to RTL this assignment is apparently too complicated for the register life analysis to grok and it won't set a REG_DEAD note to error.all where it should.. somewhere the strict_low_part is in the way. As a workaround try to declare char xerr assign to xerr and return xerr. I patched the sources and I'm trying to compile them as I write this message... Do you know if the same problem would arise with older gcc version (I was thinking to compile it with gcc-2.95.3...) ? If you got a file server (ftp, sftp, web) where to get them, I'd prefer that way (faster now that I got an ADSL link ;-)... well I didn't get ADSL, the sourceforge site is still available of course. There are no SRPMS in it though... Or do I look in the wrong place ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, 20 Aug 2003 10:55:50 +0200, Richard Zidlicky wrote: On Wed, Aug 20, 2003 at 01:22:19AM +0200, Thierry Godefroy wrote: Hi ! In an attempt to bring more pre-compiled packages for the ShoeString distribution, I tried to compile the latest Linux kernel (with the crypto API patch and the SuperMount patch). I was using loop-AES with additional ciphers which worked reliably for the last few months. I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). What is the advantage of SuperMount over autofs? It's 100% automatic, doesn't need for any demon, and it doesn't hog the processor/drives by checking every few seconds that a new medium was inserted... As soon as an access is requested to a supermounted medium, then a check for changed/absent medium is made transparently for the user. It's the standard 'automounter' for Mandrake and I just love it. :-) Alas, the compiler stops with an internat error; I tried twice, to check it was not due to a corrupted memory or processor overheating error (unlikely as my 060 is quite cool, equiped as it is with a heatsink+fan). I assume it's a gcc bug... Did anyone else encountered it ? Did anyone compiled a newer gcc version (Richard, perhaps ? :-) it is a compiler bug, the new ide core included since 2.4.21-rc6 triggers it and I didn't succeed to fix it in gcc-3.2. Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't got this problem on i586 Linux... Perhaps would it be worth rebuilding the Mandrake gcc package for Linux-Q60 ? I am currently testing gcc-3.3.1. The gcc in ShoeString is not very good anyway. I have compiled gcc-3.2 and glibc-2.2.x (as well as 2/3 of RH 8.0) which appeared to work remarkably well (with patches) but something got terribly screwed up just before I could made a release - the compiler no longer bootstrapped :( Eeeps... ;-( I can mail you a CD with many new packages If you got a file server (ftp, sftp, web) where to get them, I'd prefer that way (faster now that I got an ADSL link ;-)... which would be useful for development purposes only, I can't spend any time to create update or installation routines when a few essential packages are broken (gnome-2.x) or have strange quirks (rpm-4.x) Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my PCs... This stupid new Gnome is not only utterly broken, but it's a Hell to configure (they made the configuration 'simpler' by removing most of the options: the net result is that you can't get it to work your own way. If the default behaviour is fine with you then it's alright, else, you can spend hours trying to figure out what to do to obtain what you want !). Plus it eats 24Mb more memory than Cnome 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a Q60, forget it altogether and stick with Gnome v1.4... or better, use a lighter, standalone WM, like Icewm (v1.0.9 available on my website), Blackbox or the like... I never had problems with rpm 4.0 on Mandrake, but they pretty much changed everything compared to rpm v3... Even the databases are incompatible... Who said upward compatibility ? It looks like this concept was lost and forgotten a couple of years ago already... :-( Thierry ([EMAIL PROTECTED]).
[ql-developers] QLwIP Mail in action
Hi, this is just a quick test of the QLwIP Mail client. If it works, you receive this mail from my Mini Q60 running QDOS Classic and QLwIP. I use the Ethernet interface, my local network is connected by an ISDN router. Thanks goes to Jonathan Hudson, QLwIP Mail is based on his POP3 client. I have added SMTP and local folder support. QLwIP Mail has a graphical user interface and supports offline and online operation (e.g. deleteing spam before download), mail viewing, saveing, editing, sending (with local copy). Each operation works on multiple selectable messages. There is also support for selection of different user identities. View/Edit is by external programs. Reply has yet to be implemented, as well as many other improvements and bugfixes. All the best Peter
Re: [ql-developers] Ethernet card for Q60
Thierry ([EMAIL PROTECTED]) wrote: I'm trying to configure an ISA PnP card (RTL8019AS based) for use on my Q60. The card got a jumperless mode (i.e. a mode where PnP is disabled) that may be enabled via a DOS software (on a PC) and its parameters (I/O address, IRQ, Duplex/Simplex modes) can be set via this software too. The parameters are retained in a flash memory on the Ethernet card. I tried several configurations, but only IRQ 10 seems to allow the Q60 to boot properly (IRQ 5, although theorically available, makes the Q60 unstable and it crashes either at SMSQ/E boot time, or at the Linux loader execution time). The problem is: Linux (Shoebox v1.0a) hangs when trying to bring up eth0 at boot time... The configuration of the card is: IRQ 10 I/O 300h Full duplex It is connected to a 10/100Mbps switch and the network parameters are properly set in Linux. Any idea of what happens and the way to fix this ? Known problem, I had published several lengthy explanations about it. I first discovered the problem with some Longshine LCS-8634PTB ethernet cards, but it applies to some other RTL8019AS based cards as well. The problem was that these cards produce unwanted IRQ signals, even when in jumpered mode. Other cards of exactly the same type, and apparently the same PCB layout, behaved OK. The RTL8019AS chip is responsible for this problem. The chips which have the IRQ problem are labeled with different production codes than those which work, but I can not give a comprehensive specification which range of codes has the problem and which has not. After long debates with technicians from Longshine they had to admit that it is a hardware problem with the chip. If someone buys a new ethernet card with the RTL8019AS for Qx0, other than from DD Systems, he should be prepared to deal with cutting the IRQ10+11 lines on the Ethernet card near the ISA connector. The corresponding pins on the ISA connector are D3 and D4. Soldering side of the ethernet card, ISA connector: B1B31 D1 D2 D3 D4..D18 No guarantees. Please don't cut something you don't really want to cut :-) To be on the save side, there are tested new cards available from DD Systems. I can also provide one for you if you find it more convenient. For use with Qx0, it is strongly recommended to use jumpered mode, IRQ5 and iobase 0x300. All the best Peter
Re: [ql-developers] Ethernet card for Q60
On Tue, 12 Aug 2003 12:21:31 +0200, [EMAIL PROTECTED] wrote: On 12 Aug 2003 at 4:59, Phoebus R. Dokos wrote: I have just ported qemu (http://fabrice.bellard.free.fr/qemu/) for linux-m68k so it should be possible to do it on the Q60 just as well :) Haven't tried dosemu or wine yet. I wonder if that will work with the Intel 100Mbps ISA adapters that I had found Peter is it possible for you to test it? You mean a DOS program on dosemu on qemu on Linux on Qx0 on your card? Right now I'd prefer to leave tests like this up to you :-) I would but I don't have the card anymore ;-) Oh well, I will try to locate another one and try again! (But it may take three to four weeks) Phoebus -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: [ql-developers] Ethernet card for Q60
On Wed, 13 Aug 2003 12:21:32 +0200, [EMAIL PROTECTED] wrote: On 12 Aug 2003 at 22:01, Richard Zidlicky wrote: snip? wasnt that a hardware problem? It wont go away with software. No hardware problem known. The card isn't recognized as an ordinary NE2000 compatible, and I had no time to look further into it. I don't think that it *EVER* was NE2000 compatible... The reason why I got that card was that Shoestring Linux says that with the new kernel *ALL* cards should work. I thought it was only a IRQ/Address problem. Theoretically (and I cannot really remember now) the card should have an EPROM on it that retains settings. Practically however (as I have seen on other cards that claim to have that), once you remove it from the host system, the EPROM is cleared () Phoebus -- Visit the QL-FAQ at: http://www.dokos-gr.net/ql/faq/ (Still uploading stuff!) Visit the uQLX-win32 homepage at: http://www.dokos-gr.net/ql/uqlx.html Visit the uQLX-mac home page at:http://www.dokos-gr.net/ql/uqlxmac.html
Re: [ql-developers] Ethernet card for Q60
On Tue, 12 Aug 2003 10:14:31 +0200, Richard Zidlicky [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2003 at 05:06:15PM +0200, Thierry Godefroy wrote: Hi all ! I'm trying to configure an ISA PnP card (RTL8019AS based) for use on my Q60. The card got a jumperless mode (i.e. a mode where PnP is disabled) that may be enabled via a DOS software (on a PC) ^ I have just ported qemu (http://fabrice.bellard.free.fr/qemu/) for linux-m68k so it should be possible to do it on the Q60 just as well :) Haven't tried dosemu or wine yet. I wonder if that will work with the Intel 100Mbps ISA adapters that I had found Peter is it possible for you to test it? Phoebus
Re: [ql-developers] uQLx-macOSX version available!
On Sun, 10 Aug 2003 19:05:57 -0500 (CDT), Dave P [EMAIL PROTECTED] wrote: On Sun, 10 Aug 2003, [iso-8859-7] Phoebus R. Dokos ( . ) wrote: thanks to the efforts of James Weatherly, uQLx now also runs on Mac OS X!. (And better than it does on Win XP). I am expecting to have a separate page ready by tonight, in the meantime I am going to flood Dave Park's mailbox contrary to his wishes ;-) That's about right! ;) If I can get this going on my Mac, will I be the only person using uQLx on OS X? If not, who else would be? That would be the guy that actually did the port ;-) To run, get the Windows archive from my page and grab everything exept for the executables (ie folders and files and such). Update your .uqlxrc file... You have to start it through Apple's X11... Use the xgui program for easy setup and run... It DOES use btw with TCP and can use the Mac's disks so there... have fun Phoebus -- Visit the QL-FAQ at: http://www.dokos-gr.net/ql/faq/ (Still uploading stuff!) Visit the uQLX-win32 at: http://www.dokos-gr.net/ql/uqlx.html For mail reply to: ql PUNKT css AT dokos MINUS gr DOT net
Re: [ql-developers] New uQLx-win32 distro availble
Mon, 04 Aug 2003 15:38:28 +0200,() [EMAIL PROTECTED] /wrote: On 4 Aug 2003 at 8:18, Phoebus R. Dokos wrote: New uQLx-win32 distribution is available. Changed since the previous distribution 1. Added Copyright messages for JS and Minerva Roms 2. Recompiled under new CygWin 3. Corrected some problems with XWin 4. Included instructions for recompilation under Windows XP 5. Repackaged as RAR archives... (Zip was to big, Tar.bz2 too difficult for many WIndows users to unpack) You better not completely remove the option start XWin -multiwindow -trayicon from the uqlx.bat batchfile. If you have problems on your XP system, please comment it, but leave the line for others to see. I'd also recommend REM Try this if you have a different version of Cygwin installed REM PATH=. at the beginning. That was left in by mistake and it is now fixed There are other problems as I found out. The distribution NEEDS other files as well (I was put off by the original distro). I found out that the directory misc from /usr/bin/X11R6/lib/X11/fonts I am also trying to figure out which other exact files are missing that will : a. Give back the correct window title (It got lost somewhere in the way) and b. Restore the colours :-) (Black is now a nice purple). Thanks to Jimmy Montesinos and Rich Mellor for pointing the problem out... I hopefully will have a solution in a bit. On another note a MacOS X port was just completed. The binaries will soon be on the website as well :-) Phoebus
Re: [ql-developers] New uQLx-win32 distro availble
Mon, 4 Aug 2003 12:38:39 -0500 (CDT),() Dave P [EMAIL PROTECTED] /wrote: On Mon, 4 Aug 2003, Phoebus Dokos wrote: On another note a MacOS X port was just completed. The binaries will soon be on the website as well :-) Wahey! I could do a lot with this. Dave I will be sending it over when I have the binaries in my hands okay? Phoebus -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: [ql-developers] New uQLx-win32 distro availble
On Mon, 4 Aug 2003, Phoebus Dokos wrote: I will be sending it over when I have the binaries in my hands okay? That's okay. Post a link and I'll get it when I am in front of my Mac. Dave
Re: [ql-developers] K68 Core
Phoebus wrote: That's excellent news... I was under the impression... or at least talk and Motorola's own press releases gave me that impression, that the situation was very bleak. Will see also how Motorola will go ahead with the publicised full compatibility with the 68K (and the ultra high speeds they have in their roadmap (Trendy word this one these days ;-) Almost the ColdFire V4e had been released in spring. Motorola decided to change some of the peripheral units on the chip, hence the delay. Don't expect more than 333 MHz, maybe 266 MHz for the first silicon. V4e still won't be able to properly trap out *all* 68k instructions that are not equivalently implemented. But it is much better than all previous versions, and the number of oddities is so small that I guess only handwritten assembler code will be affected. Can you point where Motorola publicised full compatibility with the 68K? All the best Peter
Re: [ql-developers] K68 Core
Phoebus wrote: Legality is a big issue. I came across this while I was reading about a ZX81-on-a-chip clone (T80 core). I thought that it would be a good alternative when Motorola gives up the 68K family. As for the new Coldfires... have you seen : a. Their prices?, b. That Motorola won't make them really available in anything less than batches of 1000? a. From the prices which were suggested to me, the Coldfire version 4e controllers will have one of the best price/performance ratios for chips with FPU on the market. I'll tell you more, once they are released, which should happen in a few months. b. Yes. All the best Peter
Re: [ql-developers] K68 Core
On Mon, 14 Jul 2003 08:59:26 +0200, Peter Graf [EMAIL PROTECTED] wrote: Phoebus wrote: Legality is a big issue. I came across this while I was reading about a ZX81-on-a-chip clone (T80 core). I thought that it would be a good alternative when Motorola gives up the 68K family. As for the new Coldfires... have you seen : a. Their prices?, b. That Motorola won't make them really available in anything less than batches of 1000? a. From the prices which were suggested to me, the Coldfire version 4e controllers will have one of the best price/performance ratios for chips with FPU on the market. I'll tell you more, once they are released, which should happen in a few months. b. Yes. All the best Peter Hi Peter, That's excellent news... I was under the impression... or at least talk and Motorola's own press releases gave me that impression, that the situation was very bleak. Will see also how Motorola will go ahead with the publicised full compatibility with the 68K (and the ultra high speeds they have in their roadmap (Trendy word this one these days ;-) Phoebus -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA
Re: [ql-developers] K68 Core
SNIP StrongARM? IMHO not nearlz powerfull enough for this and not so easily obtainable. Only Intel makes those 200+ MHz chips, others like Atmel etc make much slower units
Re: [ql-developers] K68 Core
Yeah. I have seen it. A couple of questions/remarks: -is this legal ? I remember contacting MC regarding making MC68000 in FPGA some years ago and their answer was a firm NO- they would not allow me to use 68000 ISA. - there is a related project somewhere, called IIRC V68000, which has the same instruction set as 68000 but it isn't binary compatible. -even if guy gets his off the ground and even if he uses the newest Spartan-3 FPGA, he will never reach the speeds even comparable with Coldfire 5307, let alone 5407 or the newest, yet-to-be-out 5471 or 5472. branko - Original Message - From: Phoebus Dokos [EMAIL PROTECTED] To: QL Developers Mailing List [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 10:54 PM Subject: [ql-developers] K68 Core Anybody seen this? Phoebus URL:http://www.opencores.org/projects/k68/ -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA
Re: [ql-developers] K68 Core
I didn't know anything about the price. I plan to finally buid a decent homebrew machine and I had my eyes on 5407.Nice machine, but nothing really spectacular and no MMU. Just the other day I have posted the question to their support service, when will the 5471 be available, since it has MMU also (besides having enhanced core etc). I have got no answer still... But while searching around, I have stumbled on to superb alternative: MIPS. Decent core in several versions, supoported by several sources in all flavours and main sources seem to be hardworking, modest japanese guys instead of selfimportant pricks at MC. Check out NEC's offer and even more importantly PMC-Sierra. These guys rock. Latest incarnation is a 64 bit machine, has a decent FPU, 256 Kb of L2 cache, works on up to 1 GHz AND IS STILL IN QFP ! Oh, and it churns some 3.5W typicaly ! This thing would run Linux and emulate QL at the same time, even while powered down ;o) They have also the faster models, but those are in BGA packing :o) I'm thinking about using this one and also having smaller, slower, 32 bit version with FLASH at hand for those microcontroller jobs, where speed is not so critical, but space, cost and money are... Also, Hitachi makes nice things, but those are AFAIK not MIPS-compatible Branko - Original Message - From: Phoebus Dokos [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:09 AM Subject: Re: [ql-developers] K68 Core On Sun, 13 Jul 2003 23:50:51 +0200, BRANE [EMAIL PROTECTED] wrote: Yeah. I have seen it. A couple of questions/remarks: -is this legal ? I remember contacting MC regarding making MC68000 in FPGA some years ago and their answer was a firm NO-they would not allow me to use 68000 ISA. - there is a related project somewhere, called IIRC V68000, which has the same instruction set as 68000 but it isn't binary compatible. -even if guy gets his off the ground and even if he uses the newest Spartan-3 FPGA, he will never reach the speeds even comparable with Coldfire 5307, let alone 5407 or the newest, yet-to-be-out 5471 or 5472. branko Legality is a big issue. I came across this while I was reading about a ZX81-on-a-chip clone (T80 core). I thought that it would be a good alternative when Motorola gives up the 68K family. As for the new Coldfires... have you seen : a. Their prices?, b. That Motorola won't make them really available in anything less than batches of 1000? Phoebus - Original Message - From: Phoebus Dokos [EMAIL PROTECTED] To: QL Developers Mailing List [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 10:54 PM Subject: [ql-developers] K68 Core Anybody seen this? Phoebus URL:http://www.opencores.org/projects/k68/ -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA
