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
