Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
On Tue, 12 May 2020 07:34:08 +0200, Fabrizio Diversi via Ql-Users wrote: > I am in the middle of multiple tests with CF/IDE and SD/IDE readers with > different type/size of CF and SD > > Few words about the 2 machine I am using : > > - Q40 with 1 IDE controller card with primary channel (master/slave) and > secondary (master/slave) on the same Card so in total 4 IDE devices: Wow, you are lucky to have one of those !... They were pretty rare, even back in the 90s, when the ISA bus was reigning in PCs. I never could get my hands on any in France, and I did search a lot ! > as primary master I have a classic 80 GB IDE HD (2 atari partition), as > slave I have a CDROM. On the secondary channel as a master I have an > IDE/CF adapter. (StarTech 3.5 Drive Bay IDE to single CF SSD adapter > card reader). The second ISA slot is occupied by ethernet card. SMSQ/E > 2.92 on rom, then I load newer SMSQ/E (3.36) from primary master disk. > All the different combination of CF/SD I use on the StarTech are fine. > The system is working well and stable . Q40 is very tolerant with any > CF/SD reader I tried to used: I also replaced main primary (master) > classic 80 GB with a single SD reader (Kalea Informatique - Adapteur > Convertisseur IDE 3.5 40 pin vers SD Card) and also everything works > fine. Which makes me wonder whether this could be a problem with the IDE controller on the ISA card, since it is this controller that "speaks" with the IDE devices... Yours could be of better quality, or have a wider range/more tolerant timings than mine... I might give a try with another multi I/O card, and see if I get better results with it. So far, whichever CF Card I plugged into the passive CF-Card to IDE adapter failed with I/O errors and lost interrupts reported by Linux and corrupted data when using them under SMSQ/E. I also received and tried with these two items in chain: 1.- IDE to SATA adapter: https://www.amazon.fr/gp/product/B00EOJNGC2 2.- SATA to SDHC card adapter: https://www.amazon.fr/gp/product/B0033RB2KE Here again, a total failure... Note that the IDE to SATA adapter works just fine under Linux when a SATA HD is plugged in it, but causes immediate crash under SMSQ/E as soon as I try to access the HD in any way (even for reading a single sector). Truth to be told, the ATA driver is very loosely (with regards to the ATA protocol) implemented in SMSQ/E (I know first hand, for when I wrote the ATAPI CD-ROM driver for the Q60, I came across problems due to failures to respect the DRQ and BUSY bits by the ATA driver of SMSQ/E, and I had to recourse to slower transfer methods in atomic (supervisor only) mode in my own driver to avoid data corruptions and crashes). I returned #2 to Amazon, and kept #1 (I'll use it for the PC in which sits my QXL). > - Q60: SMSQ/E 2.98 on Rom, 2 IDE cards ESIO v2.1, no ethernet. I had > also in the past a 2 slot ISA riser card to use the 2 IDE controller at > the same time with ethernet card (used with linux Shoestring), but at > the moment I removed the riser card (and linux) and I use the 2 IDE > cards in the single ISA slotￜ with no Ethernet. An ISA riser/extender would be a nice thing to have... Sadly, they seem to sell at deliriously high prices, when you can find one on Internet. > as slave I have a toshiba 4GB SD inserted into a passive CF2SD adapter > type II (K komputer K Bay). Passive ?... I doubt it... SD cards got a serial interface, while CF cards got a parallel one (IDE-compatible). I could not find the "F2SD adapter type II K komputer K Bay" adapter on Internet. Probably not sold any more... :-/ Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
On Tue, 12 May 2020 10:27:07 +0200, Wolfgang Lenerz via Ql-Users wrote: > Just a question - what happens if you re-load (per LRESPR ,not > automatically at boot time) Yes, I was about to ask the same question, but you bet me to it. It is probably the same issue as the one I encountered with my HD that is too slow to show up on the IDE bus when SMSQ/E v3 is cold-booted from the ROM. LRESPRing again SMSQ/E v3.36 would definitely expose this, if the card is seen after such a warm reboot. I'm posting again here (but in-lined, this time, since the list does not propagate attachments) the (quick and dirty) patch I made for my HD and SMSQ/E in EPROM, and which introduces a 5s delay before querying the IDE drives on boot: --- diff -durN smsqe336src/dv3/q40/hd/init.asm smsqe336src-patched/dv3/q40/hd/init.asm --- smsqe336src/dv3/q40/hd/init.asm 2020-04-16 09:30:29.0 +0200 +++ smsqe336src-patched/dv3/q40/hd/init.asm 2020-04-21 21:47:22.0 +0200 @@ -83,6 +83,13 @@ jsr hd_1sec move.l d0,hdl_1sec(a3) + move.l d5,-(sp) + move.w #250,d5 ; wait 5 seconds (250 frames) +wait5s + jsr hd_1sec + dbrad5,wait5s + move.l (sp)+,d5 + lea q40_wn1+2,a0; configured name lea hdl_end(a3),a1 ; names lie after device defn (linkage) block bsr norm_nm ; copy & normalise name - Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
On Mon, 11 May 2020 15:38:42 -0500, Dave Park via Ql-Users wrote: > A small circuit can split the master/slave into two isolated masters > that would work in most or all cases. Is this of interest as a possible > solution? I thought about it but the problem is with finding all the deprecated 40 pins connectors, designing the circuit (that would probably mandate a double sided PCB), making it Lot's of troubles for a result that is not even guaranteed. Another, better solution, would be an ISA bus extender for the Q40/Q60, so that a second IDE controller card can be plugged (along the first one and the Ethernet card); I still have a couple such IDE (in fact IDE + serial + parallel ports) cards, but with the two slots already occupied on the Q60, I cannot use them. But I still don't despair to find a memory card adapter that will allow us to share the IDE bus and that does work... Thierry. ___ QL-Users Mailing List
[Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
On Thu, 23 Apr 2020 23:42:31 +0200, Peter Graf via Ql-Users wrote: > Fabrizio Diversi via Ql-Users wrote: > > - As a slave I have a 4 GB Toshiba SD HC with a CF adapter Type II. > > Ah! Very good idea! With the right passive CF-IDE adapters, those might > not suffer the same problem as the SD-IDE converters, which allow no > slave. I'm afraid things are not *that* simple... :-( Based on Fabrizio's report, I bought and tried this adapter: https://www.amazon.fr/gp/product/B06XD8ZP1P Sadly, when plugged into the IDE to CF Card adapter (duly configured as a slave and which does cause a genuine CF Card to indeed behave as an IDE slave device when plugged in this adapter), the SDHC+CF card adapter combo behaves like if it is alone on the IDE bus, masking any other device connected to it (in my case, an IDE HD configured as master). I also tried to configure the IDE-CF adapter as master and the DD as slave, but the DD is still not seen on the bus when the SDHC+CF card adapter combo is plugged into the IDE-CF Card adapter. I returned that device today since it's of no use at all to me... If Fabrizio could quote the brand and model of his working SDHC to CF card adapter, it would save us a lot of troubles finding one that works as intended... Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 22:02:36 +0200, Fabrizio Diversi via Ql-Users wrote: > this is the "device" I use on the Q60: > https://www.amazon.fr/Syba-SD-ADA45006-Interne-lecteur-m%C3%A9moire/dp/B0036DDXUM > The device can fit 2 CF, the master on one side, the slave on the other. Probably just another controller-less adapter, but with two slots for master and slave, and consequently without Master/Slave/Cable-select jumper, which would be superfluous. > - As a master I have an IBM microdrive (1gb) Ah yes... IBM Microdrives are not CF (memory) cards; they are 1" micro hard disks, so it is not a surprise it works like a charm when plugged on an IDE port (they were designed for it, and some even got a 40 pins IDE connector to plug directly into the connector of a motherboard). Sadly, brand new Microdrives cannot be found any more, or at astronomic prices only, and as a mechanical device, they are not more reliable than an old 3.5" or 2.5" PATA IDE drive... See: https://en.wikipedia.org/wiki/Microdrive > - As a slave I have a 4 GB Toshiba SD HC with a CF adapter Type II. Any pointer on such an adapter ?... That could be a good solution if it indeed can plug in IDE to CF adapters and let us use a SDHC card. Such an adapter would have an IDE controller inside, which would also explain why it works fine. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 15:39:39 +0200, Wolfgang Lenerz via Ql-Users wrote: > > I just coded a (very quick) and (totally) dirty 5s delay loop in the > > Q40 HD init code. The *proper* fix would require waiting in a loop > > (that would timeout after 10s or so) for a HD to show up and report > > as being ready on the IDE port(s). This won't need any parameter, but > > perhaps a disabling flag in the SMSQ/E config block, for people not > > using any HD (or IDE drive) and booting only from floppy (disabling > > that feature would allow for faster boot on floppy). > > I'll put this into the next version. Should the check be made on all 4 > possible disks, or only on the one in target 0? I doubt there are many systems with the boot drive on another target than 0... So, unless someone speaks against it now, I suggest you go the easy route. :-D > >> Well I am curious to know what you did, can be this module published ? > > > > Patch attached. I already reported the issue and transmitted the patch > > to Wolfgang as well, a few months ago. I suppose I'm the only person > > affected (with perhaps the only known configuration regrouping a low > > spinning drive and a fast (overclocked) Q60)... > > Unless I'm mistaken, nobody else raised that with me. > > I must have mislaid your previous fix, could you send it to me again? It is attached to the message you just replied now... I also sent it in my personal email to you, dated Mon, 7 Jan 2019 13:49:28 +0100, with subject "Re: QXL.WIN sur carte SDHC". Attaching the "quick and dirty" patch again to this message. But as I wrote, it's in no way a proper fix (it simply introduces a 5s delay, which happens to be needed and to suffice for my overclocked Q60 and my brand/model of HD). Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 14:57:11 +0200, Wolfgang Lenerz via Ql-Users wrote: > > I can vouch for this fact that, sadly and while implementing a "full IDE" > > compatibility mode, the Compact Flash cards (their "reader" is actually > > just a controller-less CF connector to PATA IDE connector adapter) are > > totally unreliable when used on an IDE bus, be it from SMSQ/E or Linux: > > they *might* seem to work, at first (at least some brands might look like > > they do), and as long as you copy files in a raw on a blank medium, but > > as soon as you start deleting files and writing others (i.e. for random > > access, and with fragmentation), you get immediate medium corruption ! > > Yes. > > BUT: > I have noticed more than once that, strangely enough, if you use the CF > Cards with a DOS partition scheme, and FAT32 formatted partitions with > QXL.WIN container files, then this works much better (normally > flawlessly) - on the same machine, with the same CF card, in the same > adapter and position. > > For example, copying the content of my main QXL.WIN file (formatted to > 200MB) from the SD card to the FAT32 formatted CF card, under SMSQE, > worked like a charm. drvchk and drvlink revealed no problems... > > With a direct QLWA disk, it is really hit and miss (I managed, once, to > compile SMSQE - but that is only a 25 MB file) and mostly miss rather > than hit... Atari partitions were always unreliable... Well, my experience would prove you wrong: I always used the CF cards with FAT32 partitioning, never in QLWA... and yet, they did get corrupted after a *first* flawless (file to file, using my good old TGBack_exe utility) backup from my HD to the CF card. After the first full HD backup succeeded with all three SMSQ/E partitions (it was with the Transcend 32GB CF card), I was happy, and replaced the HD with the CF card reader, and then proceeded to compile a SMSQ/E binary from sources on the CF card. BANG ! Full medium corruption (the CF card could not even be re-read from a card reader on a Linux PC: I had to repartition it and reformat it). I did several attempts, with or without a slave drive (a CD-ROM drive or the HD) on the same IDE port as the CF card, each time with the same result: first write on blank QLX.WIN (on a FAT32 CF card partition) is fine, then corruption as soon as I delete/rewrite files. With Q60 Linux, it was even worst and I could not even successfully partition a CF card under it. I later searched on the Web for similar experiences with CF cards and old computers, and found a few references on ATARI forums, some of them reporting better results with a SanDisk CF card... I bought one and tried it, and it's even worst than the Transcend (not working *at all* on the IDE port, while working 100% fine in a CF card reader in a PC). I suppose the issue is with how fast (or rather slow) the CF cards answer to the IDE controller. The timings are likely very relaxed in CF cards (and probably not very constant, when the NAND must be erased/rewritten, which are slow operations), and it might clash with the faster/tighter timings of the genuine IDE controllers. My conclusion is: do not loose your time with CF cards ! :-/ > > I might have found a solution, and I recently ordered a PATA IDE to > > SATA adapter (with master/slave jumper) and a SD card to SATA adapter. > > I should receive them by mid-June (COVID allowing), and will then > > report my luck (or lack thereof) with this setting... > > I'll be most interested to hear about that. You can count on it. ;-) Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 13:37:15 +0200, Fabrizio Diversi via Ql-Users wrote: > On 23/04/2020 13:08, Thierry Godefroy via Ql-Users wrote: > > > Err... I do need the corresponding sources, so that I can patch them > > (I need a delay on boot for the hard disk, else it won't cold-boot > > on it) > > Very interesting, is a common problem using compressed SMSQe Rom with > normal HD ? It is a problem with my HD (a 60Gb Maxtor) and my Q60 @ 66MHz: SMSQ/E boots so fast (from the ROM) that the HD does not have enough time to spin up (after a cold start or a software reset) and be ready by the time SMSQ/E tries and reads win1_boot, so SMSQ/E gives up on booting on the HD... > Could be this a value parametrized ? I just coded a (very quick) and (totally) dirty 5s delay loop in the Q40 HD init code. The *proper* fix would require waiting in a loop (that would timeout after 10s or so) for a HD to show up and report as being ready on the IDE port(s). This won't need any parameter, but perhaps a disabling flag in the SMSQ/E config block, for people not using any HD (or IDE drive) and booting only from floppy (disabling that feature would allow for faster boot on floppy). > Well I am curious to know what you did, can be this module published ? Patch attached. I already reported the issue and transmitted the patch to Wolfgang as well, a few months ago. I suppose I'm the only person affected (with perhaps the only known configuration regrouping a low spinning drive and a fast (overclocked) Q60)... > > I can vouch for this fact that, sadly and while implementing a "full IDE" > > compatibility mode, the Compact Flash cards (their "reader" is actually > > just a controller-less CF connector to PATA IDE connector adapter) are > > totally unreliable when used on an IDE bus, be it from SMSQ/E or Linux: > > they *might* seem to work, at first (at least some brands might look like > > they do), and as long as you copy files in a raw on a blank medium, but > > as soon as you start deleting files and writing others (i.e. for random > > access, and with fragmentation), you get immediate medium corruption ! > > it is more easy to find on the market CF to IDE adapter, only for my Q40 > I ordered recently from Amazon (should be here next week) an SD/IDE > adapter: Kalea Informatique - Adaptateur Convertisseur IDE 3.5" 40Pin > vers SD Card. I let you know . I already did that, months ago... Tried with 32Gb CF cards made by Transcend (first write on blank QXL.WIN works fine under SMSQ/E, then rewrites corrupt the whole media) and SanDisk (not working *at all* with the adapter). Note that both CF cards (totally) fail under Q60-Linux as well (so it's not SMSQ/E's fault). > On Q60 I have a single adapter CF to IDE, similar to 2.5 inch HD > enclosure, that can hold 2 CF, one per side, master and slave. It works. Lucky you ! Feel free to provide the community with the brands and models (especially the CF card brand/model, since this is the only thing which truly counts for a controller-less IDE/CF adapter). Also, perhaps your "2.5 inch HD enclosure" is in fact equipped with an actual IDE controller (is there any IC on its PCB) ? Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 12:10:13 +0200, Wolfgang Lenerz via Ql-Users wrote: > I don't feel it necessary to release a new version of SMSQE for this. Err... I do need the corresponding sources, so that I can patch them (I need a delay on boot for the hard disk, else it won't cold-boot on it) and burn the resulting re-compiled ROM in the Q60 EPROMs... Thanks in advance for publishing them. On Thu, 23 Apr 2020 12:03:58 +0200, Wolfgang Lenerz via Ql-Users wrote: > My advice: get rid of the CF reader, I have had nothing but trouble with > them. I can vouch for this fact that, sadly and while implementing a "full IDE" compatibility mode, the Compact Flash cards (their "reader" is actually just a controller-less CF connector to PATA IDE connector adapter) are totally unreliable when used on an IDE bus, be it from SMSQ/E or Linux: they *might* seem to work, at first (at least some brands might look like they do), and as long as you copy files in a raw on a blank medium, but as soon as you start deleting files and writing others (i.e. for random access, and with fragmentation), you get immediate medium corruption ! > Not so with SD cards. Sadly, I did not find a single SD card to IDE adapter that could be configured on a master/slave IDE port, i.e. they all grab the "stand alone" role and forbid using a second IDE drive as a slave (or master). I might have found a solution, and I recently ordered a PATA IDE to SATA adapter (with master/slave jumper) and a SD card to SATA adapter. I should receive them by mid-June (COVID allowing), and will then report my luck (or lack thereof) with this setting... Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Thu, 23 Apr 2020 09:16:36 +0200, Wolfgang Lenerz via Ql-Users wrote: > > Sadly, this change totally broke secondary partitions support for Atari > > partitioned hard disks. > > Just to make sure, this change broke things in 3.36 only, not in 3.35? Yep. v3.35 works like a charm in this respect, and I actually reverted to it for now... Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
On Sun, 19 Apr 2020 07:52:43 +0200, Wolfgang Lenerz via Ql-Users wrote: > The Qx0 can read container files from the first four FAT32 partitions > and has some new card related keywords (see extras_new_Q40_FAT32_txt) Sadly, this change totally broke secondary partitions support for Atari partitioned hard disks. On my Q60, the first 3 (Atari) primary partitions are used for SMSQ/E volumes (the rest is for Linux) and only the first one is still (thankfully) automatically recognized on boot, but the two others cannot be "mounted", i.e. WIN_DRIVE 2,0,1 that used (and ought) to assign the second primary partition of the first IDE hard disk to win2, simply assigns the first partition (the boot one) to win2... Reading extras_new_Q40_FAT32_txt I saw there are now 4 parameters to WIN_DRIVE, but using WIN_DRIVE 2,0,0,1 does not change the result at all... Any clue as to what went wrong (in the code, or in the documentation) ? Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.35
On Sun, 9 Feb 2020 09:16:58 +0100, Tobias Fröschle via Ql-Users wrote: > that sounds like a corrupt file system on the web server. No, the success after renaming shows without possible doubt that the file is not corrupt on the server. However, I suspect that the site goes through a CDN (which is nothing else than a proxy keeping local copies of files from the web servers it caches), and that the corrupted file is on that CDN. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.35
On Fri, 7 Feb 2020 07:04:44 +0100, Wolfgang Lenerz via Ql-Users wrote: > SMSQ/E 3.35 is out now (wlenerz.com/smsqe). When trying to unzip the archive I downloaded from your site (several times, from both a browser with cleared cache and with curl & wget), I get: Archive: smsqe335.zip warning [smsqe335.zip]: 13830 extra bytes at beginning or within zipfile (attempting to process anyway) error [smsqe335.zip]: start of central directory not found; zipfile corrupt. (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) Something's wrong, I'm afraid. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
On Thu, 16 Jan 2020 12:20:16 +0100, pgraf--- via Ql-Users wrote: > If the OSSC wasn't such an expensive, clumsy setup, I would also just > say: Issue solved. Period. All what matters for me is that it plain works and secures the usage of my Q60 in the future. "Clumsy" or not, the fact the OSSC is Open Source is also a big plus compared to other commercial "solutions" (that won't even work at all in the first place). > It's very good that you published your experience - I would never > spend the money without knowing that it actually works with the Q60. > For the BBQL, I have a better HDMI solution, so I have no other use > for an OSSC. If it has not happened yet, I would encourage you to > post your result on the QL forum also. In my case, the OSSC also allowed me to make use again of a QL and of the Thor XVI, both of which became unusable after my good old NEC Multisync 3D died. It also works nicely with my Atari 1024 STE and Falcon 030... > Or a different board that would run with the 68060 pulled out of the > Q60, hence my original question. While the 68060 is a wonderful CPU (much superior to *any* of its contemporary competitors), it is alas "dead" (no more produced, almost impossible to find, even as a second hand product, and when you find one, you must pay a fortune for it; I know it "first hand" for having bought a second hand MC68060RC50 a few years ago). So, a different board to host it sounds like a dead end project. However, and as you perfectly know, there are other solutions, based on "IP cores" and FPGAs. I recently stumbled upon: https://wiki.apollo-accelerators.com/doku.php/apollo_core:start That "68080" core (implemented with current FPGAs) is 3 times faster than a 68060 @ 66MHz ! Sadly it does not implement a MMU, so it won't be able to run Linux and some programs under SMSQ/E would pose issues (IIRC, QLiberated programs use the MSB of the address registers to store data, and the Q40/Q60 uses its MMU to "mask" it). Perhaps a cut-down MMU support (i.e. MSB address "masking") could be added to the "68080" core so to solve the issue under SMSQ/E... A hint for a successor to the Q68 ?... :-D Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
On Wed, 15 Jan 2020 23:07:53 +0100, Peter Graf via Ql-Users wrote: > Those are small PLDs, optimized almost to the last gate, not FPGAs, > and 800x600 is not doable. Surprising, since it's "just" a change in divisors/counters/ frequencies, but if you say so (I'm certainly no expert in PLD/FPGA programming). > I would find an answer to my original question interesting. As I already explained, the OSSC has brought to me the solution for the Q60 (and since a 800x600 mode is ruled out, I don't see any point in modifying it now). But you'd have to ask other Q40/Q60 owners about what they would prefer (i.e. the use of a scan converter (*), or a heavy modification of their Qx0 to output a higher resolution compatible with modern monitors). Thierry. (*) In fact, a "cut-down" OSSC (that would only be able to deal with the Q40/Q60 and QL video modes, and with just the VGA input and no LCD display, no remote) could be a cheaper and easier solution. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
On Wed, 15 Jan 2020 17:40:26 +0100, Peter Graf via Ql-Users wrote: > Thierry Godefroy wrote: > > In fact, I found out today that by increasing the sample rate to 1260 (from > > the 1200 I used so far) on the OSSC, I could get it to output a 1024x512 > > (without scan doubling) or 2048x1024 (with it) resolution in the 480p HDMI > > signal format... and the good news is that the monitor accepts it ! > > What does the OSSC do then... > > a) scale 512 to 480 vertical pixels? > b) somehow make the monitor display a 512 pixel signal? > c) just output 480 pixels, and 32 lines are lost? It's b) As you can see on the high res photos, the monitor menu displays the input resolution: 1024x512 (without x2 scan) or 2048x1024 (with it)... That's why with the 1260 scan rate I get a pixel-perfect picture (or very, very close to it, and certainly as good as, if not better than, what my old 17" CRT can display). > > Very interesting, since the best solution would indeed be to gain a > > standard resolution output on the Q60. > > My personal preference would be a solution that includes more VRAM, so > it is not interpolated, but an actually usable resolution. > > Besides lack of time and the BGA soldering issue, I remain unsure if > such a massive board modification is appropriate for a historic computer. > > A lot depends on the question, what do we actually prefer today: Keeping > the historic machine alive, or any 68060 machine that has decent video > and runs SMSQ/E? That's why I always suggested a 800x600 SVGA mode to replace the 1024x512 one... Granted, you loose 44288 pixels, but 800x600 is totally decent and workable (under both SMSQ/E and Linux), and won't require any additional VRAM, "just" needing a reprogramming of the FPGA(s) (or so is my wild guess). You then get both of "keeping the historic machine alive" and a "68060 machine that has decent video and runs SMSQ/E"... :-P It might as well be possible to "cheat" a bit with nowadays' LCD monitors, and see if they can be persuaded to display a 800x640 mode (i.e. to sync 640 lines in each frame with timings close enough to a true 800x600 mode), which would be only 12288 less pixels when compared to 1024x512... This said, the OSSC totally does the job for me, and I'm not worried any more about the remaining lifetime of my last CRT (which I repaired myself twice already, so I don't expect it to survive much longer)... Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
On Tue, 14 Jan 2020 01:16:14 +0100, Peter Graf via Ql-Users wrote: > Many thanks for taking a highres picture. It is nice to get the screen > filled, still single pixels can not be distinguished in every area. The > picture is significantly clearer on my 1024x768 monitor using the "black > bar" CPLD workaround. Hard to tell what I'd actually prefer, unless I try. In fact, I found out today that by increasing the sample rate to 1260 (from the 1200 I used so far) on the OSSC, I could get it to output a 1024x512 (without scan doubling) or 2048x1024 (with it) resolution in the 480p HDMI signal format... and the good news is that the monitor accepts it ! Here are the new high resolution pictures I took: http://qdos.free.fr/images/Q60-1024x512.dng http://qdos.free.fr/images/Q60-2048x1024.dng They are almost pixel-perfect. For a comparison between the OSSC+LCD solution with a CRT 17" monitor, here are a couple more pictures (at a lower resolution so that you can compare them side by side): http://qdos.free.fr/images/OSSC-Q60.png http://qdos.free.fr/images/CRT-Q60.png As you can see, the OSSC and LCD monitor perform quite well... > I have been generating 1024x768 @ 60 Hz DVI/HDMI directly from $5 FPGA > with only moderate overclocking, maybe that leads to a better Q60 > solution one day. Very interesting, since the best solution would indeed be to gain a standard resolution output on the Q60. > At the moment I still struggle with manual BGA soldering. I never tried that myself... There are a few interesting videos on Youtube about it, in particular this one: https://www.youtube.com/watch?v=L8EWqWj2srg Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] FGPA Anyone (Mister)
On Mon, 13 Jan 2020 20:59:40 +0100, Peter Graf via Ql-Users wrote: > Thanks for trying it with the Q60. If it nicely converts the Q60 signal, > that would be a big point despite the very high price. Well, everything is relative... You can find a built OSSC with its remote and power supply for 160-180 euros. Given the amount of money I spent in the QL hardware over years (not counting 2 scan converters that never worked properly and costed as much), that's peanuts to keep that costly QL hardware usable in the coming years (and till it dies... or I do). :-D > Is the native resolution of your monitor 1920x1080? I tested it on a 1680x1050 LCD monitor (Hyundai W220D) and on a 1920x1200 one (Eizo FlexScan EV2455). The photos were taken with the W220D (that is likely to get dedicated to the task when my last CRT will die, the other, newer LCD monitor being used with my PCs). In the case of the Q60, the OSSC must be configured to output a 480p HDMI video, but the actual HDMI resolution can be set to either 980x512 or 1960x1024 (via scan doubling on the OSSC side; an equivalent result may be obtained with picture scaling by the monitor, but I prefer to keep my monitors in 1:1 mode, i.e. without scaling at all). The sampling must be increased to 1200 pixels per line and the H/V back-porch and delays must be appropriately adjusted to get the Q60 screen to fit the HDMI frame. > The published Q60 screen appears a little blurred, but that might be a > matter of taking the photo. A close-up would be interesting. The photo I published was probably a tiny bit blurry, but the blur is indeed also the result of a scaling (the lines doubling is not a problem but there are actually 980 pixels per HDMI video line where the Q60 displays 1024). Here are two new photos (full resolution, untouched: 30Mb each !) in DNG format, with and without scan lines doubling: http://qdos.free.fr/images/Q60-1960x1024.dng http://qdos.free.fr/images/Q60-980x512.dng Without scan lines doubling, only a small portion of the screen is used, of course (in 1:1 monitor mode, and scaling at the monitor level gives the same result as with scan lines doubling at OSSC level), but looks almost pixel-perfect (and actually better than on my CRT monitor, which thinks the Q60 video signal is 640x400). Note that the screen looks much nicer when seen with your eyes than on the photos (you won't see the monitor pixels when your eyes at 50cm of the screen, while the camera got them all); for example, the blue strip of the QPAC2 "Things" window looks perfectly smooth when seen with your eyes. Frankly, I'm quite satisfied with the result, even if it won't match what could be done (without the need for a scan converter) with a native 800x600 mode on the Q60... ;-P Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] FGPA Anyone (Mister)
On 8 January 2020 21:58:23 GMT, Marcel Kilgus wrote: > In case anybody is still lurking here and has not jumped ship to > Facebook or the forum, I made a new post about my QL-VGA hardware I don't want to undermine your (nifty) project or discourage you to pursue it, but I recently found a solution for hooking my QL and compatible computers (including the Thor XVI and the Q60), to a LCD monitor (as long as it got an HDMI input). See it here: http://qdos.free.fr/monitors.html Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] QXL 3.33, DOS and W98
On Mon, 21 May 2018 00:41:47 +0200, Davide Santachiara via Ql-Users wrote: > While it seems with my old SMSQ 2.90 I managed to run SMSQ under the Windows > 98 DOS (i.e. starting DOS inside W98, which allowed with ALT TAB to move to > Windows back and forth), Bad idea... I never ran my QXL from within Windoze, only DOS: memory management under DOS (and Windows) are bad enough as they are already. What you might be experiencing is a lack of sufficient "low mem" (that 640Kb first block of addresses that the totally retard x86 16 bits CPUs can only address via one 64Kb segment at any given time and that all DOS executables must fit). > with the last SMSQE.EXE version 3.33 I had to force to run in as pure DOS > program following a W98 reboot to have a proper QL boot. Since newer SMSQ/E executables are much larger, and since W98 is already using the low memory in part, it is not a big surprise that it cannot work under W98. You *might* be successful if using DOS memory optimizers (such as QEMM) before launching W98, depending on the amount of DOS drivers you load on boot. > Linked to #1 after instructing W98 to restart in DOS mode there is a > drawback: I did not find a way to kill SMSQE.EXE (like e.g. QPC_EXIT in QPC2 > in Windows mode of course). You don't "kill" SMSQ/E in the QXL, you kill (or rather exit) the DOS process that communicates with it, and this is done by hitting CTRL ScrollLock under SMSQ/E. You can return back to SMSQ/E by relaunching the SMSQE.EXE executable (i.e. SMSQ/E keeps running on the QXL even while you are doing other stuff under DOS). Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.33
On Sat, 19 May 2018 11:06:08 +0200, Wolf via Ql-Users wrote: > Hi, > > I've also re-uploaded the source code. Thank you ! ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.33
On Thu, 17 May 2018 06:12:44 +0200, Wolf via Ql-Users wrote: > Hi, > > thanks Thierry and Marcel for pointig this out. > > Re-uploaded with thr missing chunk inserted. I am sorry, but the SMSQ/E v3.33 source file archive (http://www.wlenerz.com/smsqe/333/smsqe333.zip) is always the same, and it also got an issue with the QXL (it does not allow to produce a functional QXL binary)... I could however, after applying Marcel's patch to smsq_smsq_wman_link, produce a configurable Q60 SMSQ/E file. Also, the current smsqe333.zip file contains the compiled binaries in excess of the sources (and should probably be removed). Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.33
On Sat, 12 May 2018 06:48:27 +0200, Wolf via Ql-Users wrote: > Hi all, > > I re-upped the binaries zip file for SMSQ/E, the Aurora & QXL problems > should be gone now. I am faced with a problem in v3.33: the "WMAN system colours" config block is gone (!) and as a result, most of PE programs (especially old ones) are affected and only display in the ugly (and CRT screen killing) white background/green borders/black text default. Is that a bug, or (I barely even dare making such a silly supposition) something that was done on purpose ? Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q40 and Q60 video controller for flatscreen monitors
On Tue, 1 May 2018 19:26:56 +0200, Peter Graf via Ql-Users wrote: > Most flatscreens misunderstand the signal as 800x600, leading to bad > interpolation. Among the 3 LCD monitors I own, only the latest is able to (badly) sync the Q60 video signal and it does as if it would be a 640x480 VGA mode with 38.3KHz horizontal and 71.4Hz vertical frequencies, so the sampling of the pixels is extremely bad, and it fails to display the last 32 lines... Interestingly, my last functionning CRT monitor, that displays the Q60 mode just fine (thanks to the 100% analogous processing of the signal), also reports a 640x480 38KHz/71Hz mode. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] QMenu v8
On Thu, 21 Sep 2017 09:19:10 +0200, Giorgio Garabello via Ql-Users wrote: > QMenu 7.66 has a lot of problem, ink color in view_file remains always > black, extension filter don't work and some other problems... Qmenu 8, > works well.. Yes, v7.66 is buggy, but v8 is not much better... In my experience, the only valid QMenu version is 7.64. v8.00 got several annoyances and compatibility issues and, IIRC (that was many years ago), removed things from its configuration that broke the way I always used QMenu, so I rejected it years ago, and religiously (for an atheist, that's quite a superlative !) kept v7.64 on all my systems. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] For Thierry Godefroy
On Tue, 25 Oct 2016 17:59:46 +0200, Giorgio Garabello wrote: > Hello Thierry, you are the author of two of the most used of the QL > software, ACP and FileInfo2 > There 's the possibility that these software are updated to the new > possibilities offered by EasyPTR4 (system palette and resizable > windows)? I ceased developing for QDOS/SMS* around 2002, after it became evident that the (exponentially increasing) gap with other OSes and hardware would never be resorbed, and that I could not any more dedicate some (rare) free time to it. The answer to your question is therefore, and alas: no, sorry... I wish each day would count 72 hours, so that I could enjoy the many old hobbies of mine that I abandonned by lack of time... Beside, I don't see the point in updating FileInfo2 (which is an OS extension, and not a windowed software): FileInfo2 doesn't make use of EasyPtr (its configurator does, but you don't run it every day, or even every week: do you ?). Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 2.20
On Tue, 25 Oct 2016 15:48:33 +0200, Wolf wrote: > Same players, try again... We have winners ! This time, it works ! :-) ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 2.20
On Tue, 25 Oct 2016 07:06:19 +0200, Wolf wrote: > Hi all, > > SMSQmulator 2.20 is out. When started (Java 8 SMSQmulator), I get an error dialog: "Your SMSQE file is too old .../...". I tried the SMSQE file from both the Java 7 and Java 8 bundles, to no avail. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Sat, 12 Mar 2016 17:27:37 +0100, Peter Graf wrote:
> > I therefore (and I don't think I'm alone with that feeling) don't
> > consider "genuine QDOS" (and QL hardware) compatibility as a requirement,
> > especially not when it involves forbidding myself to use more modern
> > hardware or simply to keep my systems up to date with modern peripherals
> > (such as a monitor).
>
> Then let me understand, why do you still want native hardware at all?
Perhaps because I want to keep the computers I got (in order of
acquisition: ZX-81, QL, Thor XVI, PC+QXL, Atari 1040 STE, SGC+Aurora,
Falcon 030, Q60, several PCs, and a few more "minor" computers) fully
functionnal, even if I won't use some of them more than once a year ?
Call me nostalgic or conservative... :-D
> You seem to want native hardware as up-to-date as possbile. Wouldn't it
> be better then to concentrate efforts on the FPGA-based Q68 approach?
Perhaps because I spent a lot of money for the Q60 ?
Perhaps because the Q60 is still the fastest native hardware I can run
SMSQ/E onto and which, as a bonus, can also run Linux ?
> I mean the Q68 is based on a 8 year old chip and reaches QXL speed
> without caching already. It is only a matter of time, when FPGAs will
> surpass the Q60.
I'd love to see this happening: I could then consider adding a new
computer to my collection. ;-)
> I understand this, but reading such a statement from one of the last QL
> developers who are at least reachable, is a bit depressing. I ask myself
> wether the only way I can bring forward a piece of QL hardware, is to do
> EVERYTHING on the software side myself?
Alas, the QL world lost a load of excellent programmers to pragmatism,
lack of time, lack of incentive, financial constraints, etc...
One programmer (or even ten very competent and proficient programmers)
can't fill the gap which now separates the QL-compatible computers with
modern computers. Now is a time of networking, 3D real time rendering,
video streaming, etc, all of which can't be done (or only in an
extremely rudimentary way, e.g. for networking) with a QDOS/SMS machine.
Back in 2001, when I released the ATAPI driver for the Q60 (and Qubide,
but it was really originally developed for and on the Q60), I still had
plenty of projects (I first wanted to finish the CDROM driver and make
it into a proper, full fledged level3 SMS driver, then I wanted to write
an Ethernet driver and port a C-written lightweight TCP/IP stack to
SMSQ/E... among other projects).
But professionnal and life constraints decided otherwise, and when I
could again get access to my Q60, two years later, things already
dramatically changed, both in the QL world, and in the PC world...
That's when I realized that the way of the pragmatism was, sadly, the
only way for me...
Believe me, I'd like that each day would count 72 hours: then, perhaps
I would be able to do everything I want to do, including programming
old computers, even if just for the fun of it.
So, yes, it's kind of depressing. But I'm not really someone who wallows
in depressive mood. ;-D
> The first QL-SD drivers were developped by myself, I was at least
> capable to understand the code and to change it. I moved to Adrians
> drivers, because I was glad for the help, but he suddenly left the
> scene, and now I don't have the time to learn and debug his code. His
> driver seems to have an issue which conflicts the Pointer Environment -
> on both Qemulator and the Q68. I tried to motivate others to debug this,
> but failed.
>
> Do you think your decision "pragmatism over passion" is final? If not,
> what could be an incentive?
I learned by experience, over the past 5 decades, that "you can never say
never", and neither I. I just don't see things changing favorably in a
foreseeable future.
The problem is not as much the incentive (I'd really love to develop again
under QDOS/SMS on 68K hardware, just for the fun of it) as the lack of
free time.
> > Again, I don't see why you exclude the possibility to bring the necessary
> > signals to the daughter board via "flying" wires soldered on the
> > corresponding pads under the Q60 PCB... I'd rather use a solder iron once
> > and for all than loose performances with a kuldgy display driver.
>
> Because the wiring is HF-critical,
66MHz is not *that* high a frequency, and using short, flat wires ("câbles
en nappe" in French: I don't remember the name in English) would likely do
just fine.
> and because I would have to organize a service who does it in a
> professional manner! A normal user could not just buy and insert a board,
> but would need to remove the Q60 mainboard from his system, ship it
> somewhere with risk of damage and loss, etc.
I was more seeing it as a hobbyist DIY mod... Time for a poll among Q60
owners ?
> > Problem: as I understand it, you'd use additional RAM on the daughter
> > board, but that RAM won't be dual ported, like the Q60 VRAM is, so the
> > access to it would be much slower... Not really
Re: [Ql-Users] Q60 aging problems
On Sat, 12 Mar 2016 10:52:38 +0100, Peter Graf wrote: > Derek Stewart wrote: > .../... > > If the Jamma GBS8220 board is connected to the Q60 VGA port, this does > > make the display better, but still needs a little tweaking to get full > > screen display. I got no result at all (no sync) with a GBS8220 v3, and no amount of sync signals tweaking resulted in anything for me... :-( > > Maybe solution would be to signal condition the VGA signal coming out > > of the Q60 VGA connector. > > > > This is also difficult, but non-destructive on the Q60 board. Since most of the work of a converter is to reconstitute the pixel clock and deduce the resolution to also reconstitute proper line and frame clocks, it would be indeed easier if we could get all these clock signals right from the Q60 (or any other QL compatible: I'm thinking about the Q40, the Thor XVI, the QL itself...), especially knowing the exact format of the picture (resolution, number of colours). The "converter" would then just have to store a full frame (or two) in memory and output them back as a SVGA signal. > The problem with most VGA converters is that they detect 800x600 from > the Q60's signal. I'm sure that in many cases, 1024x512 would be > possible if the converter just knew about the existence of this mode. Possibly, depending whether the converter is using "standard" chips (designed for standard EGA/*VGA resolutions) or not... > Maybe if we can find someone who has connections to a smaller converter > manufacturer, they would do a change if we commit to buy a certain > number of devices. That would be great, yes... Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Sat, 12 Mar 2016 01:00:17 +0100, Peter Graf wrote: > > Frankly, such old pieces of software are probably best ran from emulators > > if they can't cope with variable size/address display... They would also > > fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't > > call this an issue and I think this kind of "incompatibility" should not > > limit and forbid us to get a better Q60 display... > > Well the Q60 is a retro computer now, and QDOS Classic running old > software is part of the heritage. I'm reluctant to restrict the Q60 to > newer QL software - the whole combination is no longer modern anyway! Frankly, I never ran QDOS Classic short of one quick test. SMSQ/E is so much better (and now even Open Source and thus free, just like QDOS Classic), that it makes no sense whatsoever for me to run any old- fashioned QDOS "flavour" (my QXLs, SCG+Aurora systems and the QPC2 and SMSQmulator emulators are also all running SMDQ/E). I therefore (and I don't think I'm alone with that feeling) don't consider "genuine QDOS" (and QL hardware) compatibility as a requirement, especially not when it involves forbidding myself to use more modern hardware or simply to keep my systems up to date with modern peripherals (such as a monitor). > Also, some software like PQIV was optimized for the Qx0 aspect ratio and > screen size. The aspect ratio has always been a (quite minor) issue with all modern QL compatible hardware (QXL, Aurora, QPC2, etc), so it's not a show stopper either as far as I am concerned. > [Q68] > > Sounds and looks good... The small size would make it an ideal "portable" > > QL... > > Thanks. Who would best be able to port SMSQ/E? Good question... Several people could (Tony, Wolf, Marcel, myself, Adrian for the SD driver, probably a few others), but the relevant question is: who would be ready/capable of spending time porting it ? I cannot answer for the others but I'm myself involved in several large pieces of software (mostly under Linux, mostly in C++), under various nicknames (for privacy purpose: we are no more in the 90s, when Internet was only used by scientists, programmers and geeks; Big Brother(s) is(are) indeed watching us nowadays) and can't afford spending time any more programming seriously under QDOS/SMS, alas... I love SMSQ, I love the 68K, I love(d) programming (especially in assembler) for them, but pragmatism won over passion: I just can't miss all the things modern OSes and harware can do nowadays, even if it's shitty hardware (PCs and x86 CPUs: what a pile of dung !) and poor OSes (in my view, even Linux sucks). :-/ On Sat, 12 Mar 2016 11:19:58 +0100, Peter Graf wrote: > Hi Thierry, > > your persistance wanting 800x600 resolution for the Q60, I'd prefer "pargmatism" over "persistance": I'm open to any other solution that would provide proper display on modern monitors... > combined with your optimism about the OS changes The software changes for a simple display size change are indeed totally trivial (just a few constants to modify in the SMSQ/E and Linux sources). See: - smsq/iod/con2/q40/disp_size.asm (q40_sizes label) for SMSQ/E - drivers/video/fbdev/q40fb.c for Linux. And that's it ! > has inspired a new idea in my head. I didn't know I was a muse... :-D > The memory area accessible on the Q60 ROM sockets is 1048576 bytes long, > but 800x600 requires only 96 bytes, leaving 88576 bytes free. > > I could make an FPGA, which places bootloader code into the free area > (at address 0) on reset. That bootloader could load an SMSQ/E or QDOS > Classic Binary from SD card into RAM. Later on, the OS could overwrite > the bootloader with it's own exception vectors. I wrote similar FPGA > bootloader code for the Q68 already. > > The board would require not much more than the connectors, one FPGA, one > RAM, and some resistors/capacitors. No additional wiring. > > Disadvantage: No 8 bit or 16 bit access possible - there are no such > signals on the ROM sockets. Again, I don't see why you exclude the possibility to bring the necessary signals to the daughter board via "flying" wires soldered on the corresponding pads under the Q60 PCB... I'd rather use a solder iron once and for all than loose performances with a kuldgy display driver. > It would be up to the driver to use only 32 bit wide access! (This might > be achievable by making the screen area copyback-cacheable and force a > flush with every 50 Hz interrupt.) Kludgy... > The normal video circuitry of the Q60 would remain intact, a second > 800x600 screen would be added, with separate VGA connector. I would be > mapped into the ROM address area. Problem: as I understand it, you'd use additional RAM on the daughter board, but that RAM won't be dual ported, like the Q60 VRAM is, so the access to it would be much slower... Not really appealing... Best regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Fri, 11 Mar 2016 23:22:40 +, derek wrote: > I would be careful desoldering a PLCC chip, Actually, the socket, not the chip... ;-) > the D Q60 was soldered correctly under the correct soldering > temperature. > > I have repaired some Qbranch Q40 boards, which had issues with the > over heating of the soldering, resulting in detachment of the through > hole plating. Yes, I do agree that it won't be for the faint hearted... A "dirty" but safer (for the PCB) solution, since the PLCC socket will be trashed anyway, is to use a small cutting pliar to (carefully) destroy the socket, then to unsolder each pin individually once all the plastic parts have been removed. This said, an adapter is still the best solution. A quick search on the web lead me to this: http://www.ironwoodelectronics.com/catalog/Content/Templates/PartGrids.cfm?StartRow=21=PL-PLCC44-H-01=PL-PLCC_TABLE http://www.ironwoodelectronics.com/catalog/Content/Drawings/PL-PLCC44-H-01Dwg.pdf Not sure how mush it costs, but maybe not much more than the RTC+battery chip as sold by Farnell... ;-P Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Fri, 11 Mar 2016 23:17:52 +0100, Peter Graf wrote: > .../... > > No chance to get a "larger" (i.e. with more gates) CPLD that would fit > > the same socket ?... Or perhaps by using a modern and larger (in both > > size and number of gates) CPLD that would piggy-back on the old CPLD > > socket via a small adpater printed circuit ?... > > I have considered that, but adaptors which fit into PLCC are > prohibitively expensive and hard to get. Well, the mod could also involve unsoldering the PLCC (correct me if I'm wrong but IRC, it's a through-holes one) and replacing it with pinheads, for example, that would plug into the add-on board. > > A native 800x600 resolution would be a definitive (and probably the > > best) solution to the problem, so I think it would be worth investigating > > some more its feasability... > > Still 800x600 would require change of all three operating systems These are extremely *minor* and *easy* changes (and SMSQ/E can already cope with 800x600 screens)... > and several pieces of application software! Moreover, software that directly > writes into QL 512x256 would fail, like the beloved QL Chess. Frankly, such old pieces of software are probably best ran from emulators if they can't cope with variable size/address display... They would also fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't call this an issue and I think this kind of "incompatibility" should not limit and forbid us to get a better Q60 display... > .../... > > However, another issue with this solution could be the lack of room to > > piggy-back a daughter board on the EPROM slots, especially with the 2 > > ISA slots occupied and a heat-sink+fan on the 68060... > > It depends. Using SMD components, the board could be about as small as > the ROM socket area. In this case, I think it's still worth a solution... > Q68 runs about QXL speed, even without the cache I am working on. Not bad at all. > Features > > - Plain 68000 core, 68020 nearly complete > - 32 MB SDRAM > - PS/2 keyboard and mouse > - Two fullsize SD card interfaces > - SER > - Ethernet > - Battery buffered RTC (and yes, the battery is separate!) :-D > - Stereo sound > - Up to 1024x768 VESA VGA, QL modes in hardware > - 8x10 cm board size, fitting existing nice case > - Single 5V power supply > > I demonstrated my Q68 at the "QL is 30" show, where someone took a picture: > > http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10 > > Meanwhile I replaced the wired components you see on that picture by SMD > for machine manufacture. QDOS Classic and Minerva are running, but > issues with QL-SD driver and Pointer Environment. Sounds and looks good... The small size would make it an ideal "portable" QL... Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Fri, 11 Mar 2016 21:37:15 +0100, Marcel Kilgus wrote: > Thierry Godefroy wrote: > > That would be nice too: I'm worried that the EPROMs contents will end > > up ebbing away with time (I saw this happening many times, even on > > military grade systems), and these EPROMs are so large that they don't > > fit any of my EPROM programmers (which are limited to 27C512 for the > > largest EPROM). > > Same here, but 27C010 and 27C256 have basically the same pins, except > the 2 additional address lines. I built a simple adapter board which > includes DIP switches to toggle A15 and A16. This way I can program > the chips in 4 parts. The Q60 EPROMS are 27C1024 (16 bits data bus): such a trick won't work for them. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Fri, 11 Mar 2016 21:16:08 +0100, Peter Graf wrote: > > Strange... I'd have expected that the problem was the video memory, > > but 800x600 pixels consume less memory than 1024x512 pixels... > > Yes it is strange. Has to do withe the fact that neither 800 nor 600 are > powers of two and the CPLDs are manually optimized to the last gate. No chance to get a "larger" (i.e. with more gates) CPLD that would fit the same socket ?... Or perhaps by using a modern and larger (in both size and number of gates) CPLD that would piggy-back on the old CPLD socket via a small adpater printed circuit ?... A native 800x600 resolution would be a definitive (and probably the best) solution to the problem, so I think it would be worth investigating some more its feasability... > .../... > > I can display it without scaling here also, but it looks crazy with only > about a quarter of the screen area covered. True, but better than a blank screen... :-P > .../... > > Well, depending on how many are "a few", this could be done with > > manual wiring... > > If I remember correctly, it was 6 wires. That's definitely not a problem then: I've seen (and did) hardware mods with more "flying" wires than this... However, another issue with this solution could be the lack of room to piggy-back a daughter board on the EPROM slots, especially with the 2 ISA slots occupied and a heat-sink+fan on the 68060... > .../... > He owns a multisync *flatscreen*. Built into a self designed case. > Remarkable. I'm jealous now... :-D > .../... > > It would be another machine... Not sure you'd find a "market" for it. > > I guess not, but I'm not looking for a market anyway. The fewer people > want it, the less work I have. The two things that still motivate me, is > to have fun and to keep the QL alive. > > So the best thing will probably be to concentrate on the Q68. This cute > piece of hardware is in working condition for more than 8 years now, > only struggling with "soft" issues and my notorious lack of time. Any picture/spec sheet ? Regards, Thierry. ___ QL-Users Mailing List
[Ql-Users] Q60 RTC chip (was: Re: Q60 aging problems)
On Fri, 11 Mar 2016 16:50:10 +, Derek Stewart wrote: > Hi Thierry, > > I can get the RTC Chip for under 10 Euro It was already pretty obvious to me that Farnell was making big money with the components they sell, but I didn't know this reached this level... O.O Count me for one RTC chip then and let me know via a private email when you'll have some available. :-) Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 aging problems
On Fri, 11 Mar 2016 16:53:56 +0100, pg...@q40.de wrote: > On 11 Mar 2016 at 14:41, Thierry Godefroy wrote: > > > [...] > > This problem was (apparently) due to the lack of poper system date setting > > before starting the build process (my Q60 RTC's battery is alas dead, and > > given it's a built-in battery inside the RTC package itself, it can't be > > replaced); > > The Q60 RTC with integrated battery should be available > off-the-shelf for about 12 € from the usual electronic distributors > like Mouser, Digikey, etc. See my last message: 20€ + VAT (+ postage) from Farnell... > To my surprise, the RTC in my own Q60 has been working for about 18 > years. Mine lasted 12 years or so (it's been dead for alreay a couple of years and started loosing *minutes* per day when the Q60 was not powered two years earlier). Not bad, but still economically silly when compared with a RTC+quartz chip and independent battery (or supercap: I love those and use them in all my RTC-fitted electronic projects). > My much bigger concern is the flatscreen monitor issue. I have troubled > my mind about that for years, and if it wasn't for the QL-SD project, > I might have designed a solution. Now that my own CRT monitor faded, > the pain level is growing. Agreed, this is *the* weak point of the Q40/Q60: without a monitor to connect it onto, the Qx0 is just a dead part... :-( > Basically, I see five options: > > 1) Create a 1024x768 signal with a modified CPLD, generating > 1024x512 plus a black bar at the bottom of the screen. 800x600 does > not fit the PLD. Strange... I'd have expected that the problem was the video memory, but 800x600 pixels consume less memory than 1024x512 pixels... > This solution seems to work with recent flatscreen monitors. For me > on a 1920x1080 LG. But 1024x768 does not interpolate nicely, and the > black area is annoying. Would it be possible to have black areas (lines) both above and below the Q60 screen, instead ?... It would look nicer. As for scaling, some monitors can have it disabled; mine, a Hyundai W220D, can display any standard EGA/*VGA resolution below its own (1680x1050) without scaling and centered on the screen (of course, displaying a 320x200 screen without scaling on such a monitor gives a tiny picture, but 1024x768 would be quite OK). > 2) Design a Q60 graphics card. An ISA card would be slower than the > onboard graphics, And both slots are already taken: one for the I/O board, the other for the Ethernet card... > so the only socket where a graphics card could go > (without modifying the mainboard) is the ROM sockets. This would > have the nice side effect to replace the UV EPROMs by Flash. That would be nice too: I'm worried that the EPROMs contents will end up ebbing away with time (I saw this happening many times, even on military grade systems), and these EPROMs are so large that they don't fit any of my EPROM programmers (which are limited to 27C512 for the largest EPROM). > Unfortunately, a few additional address and byte select lines are > required, which are not present on the ROM sockets. Well, depending on how many are "a few", this could be done with manual wiring... > 3) Find a converter which can handle the Q60's 1024x512 resolution > and does not misinterpret it as 800x600 like most VGA converters. Good luck with that !... Forget about the Ambery and Jamma Boards products: bought them and they don't work with the Q60... Neither with the Thor XVI in 512x256 resolution (or very badly). > 4) Find a flatscreen monitor with true multisync. A fellow QLer here > in Germany owns such a rare monitor and the results are nice. It is > sort of an industrial monitor. Unfortunately my attempts to get > hands on a batch of similar devices failed yet. Same here. True multi-sync monitors are History (I'm still so sad and annoyed that my NEC-3D died, 8 or so years ago). > 5) Design a Q60 successor. I had seriously considered this, because > debugging the FPGA-based CPU core inside the Q68 took so long. It > would be a piggyback 68060 board on top of the Q68 hardware. The Q68 > board providing video circuitry and peripherals, while the 68060 > board holds the CPU, main RAM and glue logic. But this solution > leads away from the original. Considering the Q60 is a vintage > machine worth preserving, this has limited appeal. It would be another machine... Not sure you'd find a "market" for it. I'd personally vote for solution 1 (preferred) or 2. :-) Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.24
On Fri, 11 Mar 2016 14:54:48 +, Derek wrote: > Hi Thierry, > > The Q60 / Q40 clock chip is a ST M48T02-150PC1 Timekeeper battery. It > plugs into a 24 pin socket on the Q60 board. It is still available, Yes, I can see it is still available from Farnel/Element14: at 20 euros + VAT, it is not exactly cheap; most common RTC+quartz chips (e.g. the DS3231) come at a quarter of this price and don't use that silly integrated battery concept that forces you to replace the whole shebang every 10 years (or even sooner, depending on how long the RTC+battery package was stored by the supplier before you buy it from them: I'd bet Farnell don't sell such a RTC everyday...). I might get one from Farnell next time I buy some electronic components from them (it will save the postage fee). I am also wondering if it would be possible to open the package (probably by abbrasing its top side with a file) to get access to the battery and replace it... I might try that with the old chip after replacing it... > Regards > Derek Regards, Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.24
On Wed, 9 Mar 2016 17:39:25 +0100, I wrote: > There's something fishy with v3.24: once compiled for the Q40/Q60, when > trying to configure SMSQ with MenuConfig, the "Initial display mode" value > does not show and it is impossible to configure it. When booting with the > resulting SMSQ/E binary, I find mywelf with mode 4 consoles displayed in > mode 8 colours... This problem was (apparently) due to the lack of poper system date setting before starting the build process (my Q60 RTC's battery is alas dead, and given it's a built-in battery inside the RTC package itself, it can't be replaced); I retried today (after checking with Wolf that I did have the proper sources, which was indeed the case), this time after a proper SDATE, and the resulting binary works fine. Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.24
On Tue, 8 Mar 2016 06:50:54 +0100, Wolf wrote: > Hi all, > > SMSQ/E 3.24 is out. There's something fishy with v3.24: once compiled for the Q40/Q60, when trying to configure SMSQ with MenuConfig, the "Initial display mode" value does not show and it is impossible to configure it. When booting with the resulting SMSQ/E binary, I find mywelf with mode 4 consoles displayed in mode 8 colours... Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] BogoMIPS benchmarks
On Tue, 09 Feb 2016 10:36:02 +0100, Peter Graf wrote: > Am 08.02.2016 21:19, schrieb Thierry Godefroy: > > > > Q60 @ 66MHz (overclocked 68060RC50): > > 127.82 BogoMips > > Writethrough cache mode: 24.937 VAX Mips/43813.5 Dhrystones/s (5M runs) > > Copyback cache mode: 47.812 VAX Mips/84005.4 Dhrystones/s (5M runs) > > A 68060 with fully activated caches should deliver (almost) exactly > twice the clock frequency in BogoMIPS. And for my machines, it did, at > least under Linux. The memory cache mode (write back or write through) is irrelevant for BogoMips since no data is written to the memory during the timing loop: only the pipeline and execution units number count, and the 68060 indeed can execute two simple instructions per clock. > I can't explain myself why it is 127.82 and not 132.0 BogoMIPS. The maximum accuracy of the measure is determined by the granularity of the timer (for BogoMips, it's the 50Hz frame timer, so the maximum error is 2* 1/50th of a second on the timing, and since the timing loop lasts for 10 seconds, the accurracy of the final measure is of 0.5% or so. There's also the problem of the linked frame timer routines: at each tick of the 50Hz timer, even in supervisor mode, QDOS/SMS executes those routines. Depending on how long they are and how many have to run, they induce a (small, but measurable) overhead on any running job. I said I made the measures with no other job running, but I got many extensions loaded by default on my QDOS/SMS systems, some with scheduler loop routines (mostly used by device drivers), so there's a slight overhead (but it's the same overhead for all systems, since I booted with the same extensions for all of them). In fact, what surprises me, is that you got exactly twice the clock speed in BogoMips... You should get slightly below that value, because even with the default device drivers, there's a slight OS overhead... Are you running BogoMips v1.5 ? Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] BogoMIPS benchmarks
On Tue, 09 Feb 2016 15:51:54 +0100, Peter Graf wrote: > Am 09.02.2016 14:14, schrieb Thierry Godefroy: > > On Tue, 09 Feb 2016 10:36:02 +0100, Peter Graf wrote: > > > >> Am 08.02.2016 21:19, schrieb Thierry Godefroy: > >>> > >>> Q60 @ 66MHz (overclocked 68060RC50): > >>> 127.82 BogoMips > >>> Writethrough cache mode: 24.937 VAX Mips/43813.5 Dhrystones/s (5M runs) > >>> Copyback cache mode: 47.812 VAX Mips/84005.4 Dhrystones/s (5M runs) > >> > >> A 68060 with fully activated caches should deliver (almost) exactly > >> twice the clock frequency in BogoMIPS. And for my machines, it did, at > >> least under Linux. > > > > The memory cache mode (write back or write through) is irrelevant for > > BogoMips since no data is written to the memory during the timing loop: > > only the pipeline and execution units number count, and the 68060 indeed > > can execute two simple instructions per clock. > > As you wrote below, there is a little interrupt overhead, so it's better > if they are on copyback. Not really, because the interrupt routines don't write that much to the memory either... The problem with the copy back mode on the Q60, is that it crashes all QLiberated programs, so... > That probably explains it. I must have seen it under Linux as suspected. > But even there I got only 159.8 BogoMIPS when I retried under Linux. > 157.9 under QDOS Classic. The Linux boot-time bogomips benchmark happens very early in the kernel initialization process, long before device drivers, interrupts and kernels daemons are started, so it's normal that you got almost no overhead at all. > Can not work on my Q60 anymore since my CRT Monitor just died. That's one of my fears: I've got one CRT left: when it will die, the Q60 will become unusable since, alas, I could not get any modern monitor or even any rescaler board/box (Jamma board & Co) to sync its video signal... It would be great if we could get a 800x600 Q60 GLUE chip to replace the 1024x512 one (not more video memory needed, and full SGVA compatibility). Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] BogoMIPS benchmarks
On Mon, 8 Feb 2016 19:15:43 +0100, Marcos Cruz wrote: > Some interesting BogoMIPS benchmarks from the Spanish QL Forum > (http://foro.speccy.org/viewtopic.php?f=15=4687): > > QL with GoldCard (1): > 1.62, 1.62, 1.62, ... > > QL with SuperGoldCard (2) : > 5.83, 5.83, 5.83, ... > > QemuLator (3): > 96.55, 97.25, 96.55, 97.61, 97.08 > > QPC2 (3): > 123.56, 123.98, 123.56, 123.56, 123.70, 123.27 > > SMSQmulator (3): > 52.32, 49.98, 49.43, 50.45, 49.43 > > Notes: > (1) GoldCard -> Motorola 68000 16 MHz. > (2) SuperGoldCard -> Motorola 68020 24 MHz. > (3) PC - Intel Core2 Quad 2.33 GHz - Windows 10. More benchmarks, with even more exotic machines, for the fun of it: QPC II v4.02/Linux 4.1/Wine 1.7.42 (*): 270.46 BogoMips 121.458 VAX Mips/213401.6 Dhrystones/s (10 millions runs) QPC II v4.02/VirtualBox 5.0.14/Windows XP Pro SP3 (*): 267.09 BogoMips 120.481 VAX Mips/211685.0 Dhrystones/s (10M runs) SMSQmulator v3.15/SUN Java 7 (JRE 1.7.0.80) (*): 131.26 BogoMips 54.579 VAX Mips/95895.7 Dhrystones/s (5M runs) Q60 @ 66MHz (overclocked 68060RC50): 127.82 BogoMips Writethrough cache mode: 24.937 VAX Mips/43813.5 Dhrystones/s (5M runs) Copyback cache mode: 47.812 VAX Mips/84005.4 Dhrystones/s (5M runs) QXL @ 35MHz (overclocked 68040RC33): 21.47 BogoMips 13.169 VAX Mips/23137.4 Dhrystones/s (1M runs) (*) PC using an overclocked Core-i5 2500K, perma-locked in turbo mode (i.e. only the C0, C1 and P0 CPU/Package states are allowed: frequency stepping is fully disabled) at 4.6GHz, running under Linux v4.1 (32 bits + PAE mode). All tests were done without job running under SMSQ/E, with SMSQ/E v3.21 for all but QPC II (v3.19) and SMSQmulator (3.23), all at a resolution of 1024x768 (but for the Q60, which resolution is 1024x512). Note that the Dhrystone/VAX Mips figures come from GCCdhrystone v2.1: they are more relevant of the actual power you can get from a machine since BogoMips only represents the maximum instructions per second throughput of a CPU executing the simplest instructions in its set (increment-test-branch loop). However, the performance reported by Dhrytstone v2.1 depends on what compiler optimizations the C compiler that was used to compile it is capable of. The cross-compiled GCC version (GCCdhrystone) is therefore (much) faster than the C68 one (dhrystone). Thierry. ___ QL-Users Mailing List
Re: [Ql-Users] [QL-Users] CPU/OS differences.
On Sat, 16 Mar 2013 11:16:42 -0500, Dave Park wrote: Hi all, It's been mentioned that vanilla QDOS/Minerva doesn't run happily on 68EC020 due to CPU differences. The GC/SGC copies and patches the OS to work with the EC020 CPU, and to relocate certain resources. My questions are: what are the differences? For all 680x0 CPUs above the 68000/8 (ie. for 68010/012/020/030/040/060s), the MOVE from SR instruction is priviledged while it is not for the 68000/8. This is the usual cause of incompatibilities for software written for the 68000 and ran on a newer processors. You therefore have to patch those pieces of software to invoke the MOVE from SR instruction only from supervisor mode. There's also the VBR but it should be initialized to 0 on reset, so this should not cause an incompatibility. With the VBR, however, you can move the exception vectors (which are normally held in ROM, at address 0 ownwards) to RAM (in the SGC example, this is probably what happens: it might change the VBR to point to the start of the patched QDOS/Minerva copy in RAM, with modified vectors pointing to the patched exception handlers). Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Compatible LCD monitor for Q40/Q60 ?
Greetings, My last CRT SVGA monitor just died (HV transformer fried: no hope of repair) and my current LCD monitor is unable to display the Q40/Q60 resolution (1024x512) properly (it apparently tries to interpolates the 1024 columns into 640 and it displays only the first 480 lines). Is anyone using a recent (must be available for sale now in shops) LCD monitor able to properly display the Q40/Q60 screens ? Many thanks in advance ! Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] QPC2 v3 under Wine
Greetings everyone ! I recently upgraded to QPC2 v3 since I read that it was now possible to run it under Linux with Wine. It works fine under Linux using VirtualBox and a WinXP Pro virtual machine, however, I have serious troubles with the keyboard table when trying to get it to work under Wine... I'm using a French keyboard, and whichever table I tell QPC to use (normally 33, but I tried others), the upper key row (numbers and special characters), the lower keyrow after the m (where punctuation characters normaly are), and the four keys (2x2) left of the Enter key are all screwed up ! I can't even find an underscore key (which makes it pretty much imposible to use the SBASIC console to try and investigate further)... I tried Clavier_obj (but it is too old for SMQSQ/E v3, obviously), as well as an old keyboard definition table I made a while ago and that I am still using successfully with QPC2 v3 under VirtualBox, but to no avail. I also tried to export LC_ALL=C and export LANG=C (instead of letting the default fr_FR locale) before launching QPC under Wine, but it did not change anything Any clue on how to get it to work properly with Wine ? Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MD5 algorithm in SuperBASIC or 68K assembler?
On Sun, 1 Mar 2009 17:34:43 +0100, Urs Koenig (QL) wrote: Hi all, did somebody implement the MD5 algorithm in S*BASIC? http://en.wikipedia.org/wiki/Md5 Or is there a 68K assembler implementation? This could be the base for a Toolkit-command. Best regards, Urs I ported libmhash v0.8.2 a very long while ago. It might be worth having a look at it: you could reuse the c68 (or better: gcc) assembler outputs for the hash algorithms to turn them into SBASIC functions... http://morloch.hd.free.fr/qdos/download.html http://morloch.hd.free.fr/qdos/files/libmhash082.zip Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] New QMENU on Aurora
On Wed, 22 Oct 2008 10:13:41 +0200, SMSQ wrote: Hi Thierry, yes, it is true I put Trap #$e and Trap #$f as debug brakepoints and sometimes forget to remove them. However, they should be ignored if no debugger exists - otherwise there would have been massive problems in the past. I checked QMENU 8.01 for these traps but I did not find anything. The one I used at Eindhoven for debugging has been removed. It is possible that there is still a Trap in one of the many libraries I use, but again, without debugger (and activated Trap check) every system should ignore them. Sorry to contradict you, but ARGOS (Thor XVI) is one such system that would halt the job on such a uninitialized TRAP, dumping all the registers to the screen and setting the priority of the offending job to 0... Also, it would cause problems on systems with a monitor loaded. Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] New QMENU on Aurora
On Tue, 21 Oct 2008 16:10:38 +0200, Bob Spelten wrote: Recently JMS announced here an update for Qmenu. As recent as last saturday in Eindhoven, he added some changes (I made him do it). Happy with my new update I went home and tested it on my machines. But in my case it only workes poperly under QPC2. My Aurora and QXL refuse to LRESPR correctly, no error is reported but the version prompts are missing and no Things or keywords are added. Only the licensed for SMSQ/E prompt is shown. Some of you may have downloaded the update. Can anyone confirm my findings on Aurora, QXL or maybe Qx0? Both Jochen and I are confused about this. All my tests were done with SMSQ/E 3.13 and menu_rext 7.67 to 8.01, some with 3.03 but the results were the same. Bob Check for break points (TRAP #14, IIRC) in the code... and replace any with a NOP. I saw this happening countless times with many QMENU versions in the past on my QXLs and Thor XVI. I did report it to Jochen too, but saw it happening again in later versions. Maybe Jochen simply forgot again to remove the debugging code... ;-) The problem is that such TRAPs are ingored (i.e. lead to a RTE) in QPC but not in other QDOS-SMSQ systems in which they stop the job instead. Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QMon under QPC2 - SMSQ/E
On Sat, 4 Feb 2006 12:22:21 +0100, Ralf Reköndt wrote: Hi Thierry, does not work with v2.11 under QPC. If I start qmon, then g it stopped with an illegal instruction in Supervisor mode. What version do you use? v2.11, but on a Q60... Note that, IIRC, QMON used to work fine when unpatched on QPC, despite the fact the latter identifies its processor as being a 68010 (i.e. -with- VBR support), like shows a peek($280A1) which returns $10... Thierry. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Re: [ql-developers] In search of a 68060RC 60MHz with 0E41J mask
On Tue, 24 Aug 2004 14:04:19 +0200, [EMAIL PROTECTED] wrote: but my free time is too precious to loose it trying to distinguish what is the processor's fault and the software's one, and review the machine code of hundreds of kilobytes of OS extensions, toolkits and the like to spot the (correct !) line which fails to execute on my buggy processor... If you had actually placed your promised order for a Q60/80 in time, even that scenario (which I still find pretty unrealistic) wouldn't exist. Also you could have asked me, but I gather that you prefer to stir up the public first. ??? What the Hell are you speaking about here ??? The fact that I finally didn't bought a second Q60 (lack of time, move due to my work, and see below for the reasons of my absence from the QL scene) has nothing to do with the fact that the first Q60 is still fitted with a buggy processor. Moreover the [EMAIL PROTECTED] would probably have had the same buggy masks (see below as well). As for stiring the public first, I simply asked for someone with an available bug-less 060. I coudln't do it without saying why I was searching for one, and it is in my opinion important that people know that the Q60 they have is perhaps fitted with the same buggy processor. I my case the only catastrophic accident is an added expense in order to end up with a 100% working system. I can deal with it. You should deal with your mistake too, like I do with mine. No need to whine. I don't. I clearly reject your claim not to have a fully working system. Working needs to be defined by the normal purpose of a good, which is 100% fulfilled by your Q60. I deny you any right to judge me based on mere opinions. Your -opinion- is that my Q60 is 100% fulfilling my needs. Mine is that it doesn't, period. If I can't run some programs because they crash on my Q60 and if I can't use the full optimisations of the 060 to get the maximum of its speed, then the system is not 100% working for me. Yes, I'm a perfectionist... so what ? Your hypothetical added expense (please let me know if a RC60 with the mask revision you want exists on the market at all) would just provide you an extravagance that other mainstream 68060 systems have not. Chip documentation (including errata) has to be accepted if you're a specialist dealing with lowest level software. That's about all. While it is possible to take into account such bugs when designing a -new- system and writting -new- software for it, it is not when the said system is used to run software which was designed to run on bug-less processors, which is exactly the case for QDOS/SMS. I don't see why I would bother with a buggy processor when I can have a bugless one. And if I want to spend some more money to get it, it is MY business, not yours. On Tue, 24 Aug 2004 15:55:55 +0200, [EMAIL PROTECTED] wrote: Thierry, I just read in the ql-users archive and saw that Fabrizio has the problem with crashing Qliberated programs, too. Since he has a 68LC060RC75, he must have a newer mask revision. I conclude that the CPU errata can hardly be the cause of problem you experience. Your dramatic public Q60 blame look even more inappropriate now. READ and DOCUMENT YOURSELF ! http://www.freescale.com/files/32bit/doc/no_sub_type/MC68060DE.pdf (already cited twice in my messages...) The 68060, 68EC060 and 68LC060 were produced as well with the same buggy 1F43G and 1G65V masksets until the XC68060 became the MC68060, at which point the 68LC060 and 68EC060 were produced with maskset 2G59Y while the 68060 was produced with the 0E41J maskset. For your information, the recent fix in Linux also cured a bug that caused xterm to make X11 crashing under certain conditions (moving its window under IceWM until the lower right corner hits the corner of the screen). A long time ago, I discussed about this bug with Richard and none of us could understand from where it came (and yes, I had extensive gdb sessions to try and find out)... Finally, and once again, there is no dramatic public Q60 blame in my message: I simply stated FACTS: FACT: the XC68060 is a buggy processor. FACT: my Q60 is fitted with that processor. FACT: the bugs were corrected in the MC68060. FACT: these bugs do make some software to crash, and some don't even have a workaround (I11, for example, which is quite likely to be triggered by some QDOS/SMS software given how common it is in this OS to switch to supervisor mode and manipulate the USP) The result is that I am searching for a MC68060 to replace my XC68060. I didn't blame YOU, I just said I was upset (and explained why in my second message). If you are paranoid, go see a shrink. I'm fed up of useless fights in the QDOS/SMS community, and for your info, the reason for my long absence and silence was precisely the previous flame war about SMSQ/E... I guess I'll just return to the lurking and passive/unproducive mode. Thierry Godefroy. PS
[ql-users] In search of a 68060RC 60MHz with 0E41J mask
I'm quite upset !... I just discovered that my Q60 was fitted with a buggy 68060 ! Yes, a pre-1996 mask 060 (1G65V mask), while my Q60 was built as bought in 2001 !!!... This makes me wonder how many among the Q60s have that same buggy processor fitted... I discovered this because Linux v2.4 got a recent fix for the I14 errata of these buggy processor, and logs the activation of the fix when the kernel boots. This fix consists in setting the bit 5 in the PCR (Processor Control Register), which disables one of the optimisations of the 060. But there are no less than 21 bugs in the maskset of my 060 !!!... No wonder why I get weird results each time I try to modify SMSQ/E and QLib_run in order make them work properly in copyback mode (currently, QLiberated programs hang/crash/loop randomly when copyback is enabled). For the ones interested in the details about these bugs, they will find the 68060 device errata document here: http://www.freescale.com/files/32bit/doc/no_sub_type/MC68060DE.pdf Anyway... I'm now in search for a bug-less and full blown 60MHz 68060... Is anyone, by any luck, selling one ? Thierry Godefroy. ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
