Re: [Ql-Users] Assembly Language eMagazine - new issue!
Am 14.04.2024 um 15:57 schrieb Jiri Dolezal via Ql-Users: > TenFourFox is not able to process the GitHub javascript. Ah, a MacOS 10.4 user? In order to still run 68K Mac programs? Did you still keep TenFourFox up-to-date be compiling it yourself? ___ QL-Users Mailing List
Re: [Ql-Users] hardware
Computer Research Centrum, Ltd via Ql-Users wrote: >> The Q60, was sold by me in 2003, which should be 66Mhz Q60 64Mb ram,. > > Battle of the Q60 upcoming? > Dear, so much of us will like one… > dex 27 years after design time... still unreached by any other QL hardware. And maybe the fastest 68060 mainboard forever, as the VME and chess mainboards were somewhat slower. Someone still compiles up-to-date Linux kernels for Qx0 ... so crazy. ___ QL-Users Mailing List
Re: [Ql-Users] hardware
Darren Branagh via Ql-Users wrote: > I don't have a Q60, so would be more than willing to pay postage to have it > sent to me? A Q60 for just postage would be a fantastic deal, it's easily worth a four digit sum these days... ___ QL-Users Mailing List
[Ql-Users] George Gwilt
Richard Gwilt wrote: > Hello everyone at the QL-Users group. I guess most of you knew of mu > father, George Gwilt - this is just to let you know that he passed > away this past Saturday. > > All the best, > > Richard Gwilt My heartfelt sympathy! I remember we privately met about a decade ago. Still have photos from us and the involved Q60, made with his huge reflex camera. Interesting discussions about floating point operations, 68060 specialties and his SMSQ/E port to GWASS. George was a fine person and one of the greatest QL developers. He will be missed! All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 3.00
Wolfgang Lenerz via Ql-Users: >>> Hmm, I always thought there was only one remaining user under java 8. >> >> I'm sure there would be several more, if you didn't hide the Java 8 >> version from the public ;-) > > Yes, and maintaining it is a PITA I only know PITA as a greek flatbread :) Reckon you were swearing, but: If you did the work for the single user, the pain already lies behind you. Allowing more users does not enlarge the pain gone by ;) ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 3.00
Hi Wolfgang, > Hmm, I always thought there was only one remaining user under java 8. I'm sure there would be several more, if you didn't hide the Java 8 version from the public ;-) Your Java 8 version runs like a charm, nicely supports 32 bit machines, and can live with a compact JRE engine instead of the huge JDK. Java 8 is still maintained and the official, most recent JRE available from Oracle. Especially on my older Laptop and Raspberry, I much prefer this version. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.40 (only for Qimsi users)
Wolfgang Lenerz via Ql-Users wrote: > I just uploaded SMSQE 3.40. > > This is ONLY of interest for those having a (Super)GoldCard with Qimsi: > the PS2 driver for that hardware is now integrated into the source tree. > The filename for that version of SMSQ/E is "gold_qimsi" and can be found > in the smsqe340_binaries.zip file, as referenced from my website. Many thanks Wolfgang! I'd like to clarify, that only the PS/2 keyboard driver is part of SMSQ/E. The PS/2 mouse driver for QIMSI still has to be loaded separatly. By the way, why did you separate it from normal GoldCard? To save binary length? All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Jan, > When I use a splitter and connect the keyboard to the corresponding > connector on the spiltter, the Q68 freezes at the boot loader screen > even if the mouse is not connected. The simple reason is that most (not all) splitter cables lead the mouse to the primary PS/2 port. This was to also allow a mouse to be used on a PC laptop without splitter cable. Which made sense, because Laptops have a builtin keyboard. But on the Q68 it is more important to have the keyboard on the primary PS/2 port, so it can be used without splitter. To achieve this, I swapped the ports, compared to most PC laptops. In other words, most splitter cables are not correctly labelled for a Q68. > I have to reverse keyboard and mouse plugs to make it work. Which is absolutely normal. > Of course this has no relationship with Minerva > or SMSQ/E (which hasn't even started up yet) but it might have something > to do with interrupts or firmware (which I'm not familiar with, it's > Peter's design). Not at all. The labelling of your splitter cable simply needs to be swapped to reflect the Q68 pinout. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Dilwyn Jones via Ql-Users wrote: > 1.05 - That's the version that caused me all the Minerva problems. A hardware problem seems more likely to me, because logic version 1.05 works with the latest Minerva elsewhere. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 3.00
Andrius V wrote: > Nevertheless, there's JRE available > from some of them, one I would recommend to try is eclipse temurin > https://adoptium.net/temurin/releases/?os=windows. Thanks for the hint. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 3.00
Derek via Ql-Users wrote: > I just install the runtime version of Java, on Windows and Linux, from > Oracle, who bought out Sun Systems. We just discussed the lack of exactly that. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 3.00
qlus...@sinclairql.net via Ql-Users wrote: > then googled for: java 17 windows 10 download > > and followed the search result which looks the best match (Windows is from > Microsoft, so let's use their Java): > https://learn.microsoft.com/de-de/java/openjdk/download So no standalone JRE and one needs to install the whole JDK? ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Wolfgang Lenerz via Ql-Users wrote: > In other words: SMSQE checks the version of hardware you have. If it > doesn't allow higher speed, SMSQ/E doesn't even try to use that - even > if it is configured to do so. Maybe statements like that have been misread. The FPGA knows nothing about the SD card. SMSQ/E can just find out, if the FPGA has the capability to generate a higher clock. But not if higher clock is actually allowed. A cards capability for higher clock - if it exists at all - is not checked and initialized by SMSQ/E in a theoretically correct way. And Wolfgang is really not to blame for that, as we were not even able to obtain the necessary documentation. So the higher clock speed is always simply outside the SD specs! Maybe hardware-wise, maybe software-wise, maybe both. We just "tried and it worked for some cards". >> A save feature to use is 16 bit access to SD cards introduced in FPGA >> version 1.02 and higher. SMSQ/E automatically detects this. > > In about the same way as for the higher speed... But unlike the higher clock speed, this is a safe feature! Tt never uses the SD card outside the specs. By the way, I regret that I did not make it 32 bits wide. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Jan Bredenbeek via Ql-Users wrote: > Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be > able to do more research... Please remind me prior to the QL meeting so I bring the equipment and FPGA data. As I wrote at several occasions, it turned out to make a difference on which operating system I had synthesized FPGA version 1.05. If synthesized under Windows 10, there was a stability problem that Martyn could reproduce. If synthesized under Windows XP, everything should be allright. Unfortunately, I never suspected such a problem with the FPGA toolchain, and it is now not traceable. Very unlucky. In any case, the fast SD card speed option of SMSQ/E is not an officially permitted way to access the cards. It should never ever be SMSQ/E default! It is a purely experimental feature used at own risk. I have warned about it all along. Also I'm not aware of an "auto-slow" feature. If SMSQ/E is configured to "fast", and for some reason there is a timing problem, card access will fail. A save feature to use is 16 bit access to SD cards introduced in FPGA version 1.02 and higher. SMSQ/E automatically detects this. Dilwyn Jones via Ql-Users wrote: > Mind you, my Q68 has never been able to run Jan's Minerva port either. If the latest Minerva and/or returning to FPGA version 1.02 does not help, I would suspect an actual hardware problem and your Q68 should be replaced. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Announcement for the 40th Anniversary of the Sinclair QL in Dormagen (Germany)
Wolfgang Lenerz via Ql-Users wrote: > Hi, > > I intend to come on friday and stay until early afternoon on sunday, if > possible. > > Wolfgang Fantastic! This tends to become the best QL meeting in more than a decade! ___ QL-Users Mailing List
Re: [Ql-Users] Announcement for the 40th Anniversary of the Sinclair QL in Dormagen (Germany)
Fabrizio Diversi via Ql-Users wrote: > I will attend, just for one day, most probably on Saturday Which is probably the only "full" day. Fantastic that you come from Italy! Great to meet you in person. I will also attend and show Qzero, QLbase, QIMSI plus some historic stuff like Q60. And with some luck also a new project. Did anyone consider to stay Sunday also? I know it was primarily meant for packing. But my experience is that one full day flies by so quickly. At least in Germany and the Netherlands, Monday is a holiday. We could spontaneously prolong. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Announcement for the 40th Anniversary of the Sinclair QL in Dormagen (Germany)
François Van Emelen via Ql-Users wrote: > Op 3/02/2024 om 14:17 schreef desin via Ql-Users: >> >> >>> The name of the hotel is Hoetche https://hoettche.de >> from Switzerland you get >> >> Connection denied by IP2Location Country Blocker >> >> dark times ... >> ___ >> QL-Users Mailing List > > No problem from here (Belgium) > > Frnçois Van Emelen The Website offers Croatian, Dutch, English, French, Italian, Polish and Spanish language - so the Hotel is obviously interested in international guests and did not intend geoblocking. Probably lack of competence from the consulting company that has set up the website. ___ QL-Users Mailing List
Re: [Ql-Users] QL Homepage
Hi Dilwyn, > As I'm getting a large number of "where's the QL homepage gone" type > emails despite my extensive efforts at publicising the change, I'm > assuming QL users don't read extensively published information (Forum, > ql-users list, blog, Facebook, redirect on old site for weeks for > example) It is a shame that people don't even try a primitive a web search before bothering you. Simply "Dilwyn QL" is enough to find the new place. Many thanks for keeping your homepage up! Peter ___ QL-Users Mailing List
Re: [Ql-Users] QL is worryingly nearly 40 do we get a midlife crisis party anywhere?
Am 14.03.2023 um 22:37 schrieb Graeme Gregory via Ql-Users: > We did discuss hooking this mailing list up to the forum! > > Not sure if thats possible with phpBB, it was on FUDforum that I used to use! Oh oh... FUD? Fear, uncertainty, doubt forum? ;-) ___ QL-Users Mailing List
Re: [Ql-Users] QL Homepage
Hi Dilwyn, > When my troublesome domain name comes to an end on 13th March, the > dilwyn.me.uk QL site will shut down. > > But thanks to the nice Mr Heaton who runs QL Forum, what is currently > the backup site will become the new QL Homepage. That is great news! Your homepage is absolutely essential for the QL and I'm happy it will stay alive. Many thanks for all the work and troubleshooting time you have invested over the years! All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Raspberry Pi Pico
Hi Graeme, > A C implementation of SuperBasic would be useful to some people it seems. > > But as Peter says it would not be SMSq/e based! > > So who is stepping forward to volunteer :-D This one looks similar: https://github.com/paladin-t/my_basic ___ QL-Users Mailing List
Re: [Ql-Users] Raspberry Pi Pico
Wolfgang Lenerz via Ql-Users wrote: > Short answer: > > "Could" it be ported? Yes. But not in a sense that it could run any existing SMSQ/E executables. Just BASIC programs would run. A port would be a rewrite of SMSQ/E in ARM assembler instead of 68K assembler. Derek via Ql-Users wrote: > It would be easier to port Linux to the Pico and compile sQLux... It is a small microcontroller without MMU and insufficient RAM. Not even a Linux port is possible. Has nothing in common with the normal Raspberry Pi, except the name. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Raspberry Pi Pico
I have luckily running SMSQmulator under Java on my Raspberry Pi Linux. But I guess the Raspberry pi pico has no SD card? - Try the project www.digikey.de/en/maker/projects/raspberry-pi-pico-rp2040-sd-card-example-with-micropython-and-cc/e472c7f578734bfd96d437e68e670050 regards Klaus-Peter Greiner Am 31.12.22 um 10:29 schrieb Simon Balderson via Ql-Users > Has anyone seen or used a Raspberry Pi Pico? It’s an incredibly cheap and > versatile microcontroller and a version of BASIC has already been ported to > it. That version is based on Microsoft’s GW-BASIC. See the Geoff’s Project > website, the link is below. > > PicoMite<https://geoffg.net/picomite.html> > > Could SuperBasic or SMSQ/E be ported to it? > > > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator
Wolf via Ql-Users wrote: > I've re-re-upped the version for java 8... re-thanks! ___ QL-Users Mailing List
Re: [Ql-Users] QL-SD ROM
Peter via Ql-Users wrote: > Do you cause the SGC to apply it's patches on > the emulated ROM, or just restart without patching? Sorry for asking impatiently, I see that answered in detail at https://github.com/janbredenbeek/QL-Customboot Good job! ___ QL-Users Mailing List
Re: [Ql-Users] QL-SD ROM
Jan Bredenbeek via Ql-Users wrote: > Based on your excellent blog post about the (S)GC boot process > (https://www.kilgus.net/2018/11/14/supergoldcard-boot-sequence/), I > managed to write a boot loader for custom QL ROMs using a (Super)Gold > Card. Turned out that the lower 48K RAM of the (S)GC isn't as > write-protected as we thought! This way you can change ROMs on the QL > without even having to open the case. Cool idea! And funny, I just posted something related in the forum before reading your email. Do you cause the SGC to apply it's patches on the emulated ROM, or just restart without patching? Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQmulator 2.30
Jan Bredenbeek via Ql-Users wrote: > It appears that most of the library files are missing in the Java 8 .zip > file. SMSQmulator refused to start and gave an 'INI file error' on the > Java 8 version. I could fix this by copying the files in the lib > directory from the Java 11 version. For me, the JAVA 8 version appeared to work immediately, but it could be that the lib directory still existed from the previous version. ___ QL-Users Mailing List
Re: [Ql-Users] Ql-Users Digest, Vol 196, Issue 7
Sent from Yahoo Mail on Android On Sun, 21 Jun 2020 at 21:04, ql-users-requ...@lists.q-v-d.com wrote: Send Ql-Users mailing list submissions to ql-users@lists.q-v-d.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.q-v-d.com/listinfo.cgi/ql-users-q-v-d.com or, via email, send a message with subject or body 'help' to ql-users-requ...@lists.q-v-d.com You can reach the person managing the list at ql-users-ow...@lists.q-v-d.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Ql-Users digest..." Today's Topics: 1. Re: Select on (Michael Bulford) -- Message: 1 Date: Sun, 21 Jun 2020 19:53:50 + (UTC) From: Michael Bulford To: ql-users@lists.q-v-d.com Subject: Re: [Ql-Users] Select on Message-ID: <100179.2817707.1592769230...@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 If we are talking about Selecting on single-character strings, such as when coding actions depending on some keypress, I would like to tell you about how I get around this problem.? At the very beginning, I would declare some constants of the codes of all the alphabetical characters, all 52 of them.? Underscores are used in the names to highlight these vars are constants and their initial values should not change.? I will give what the code would look like under Minerva, and then how this would look in SMSQ/E. Note that when Selecting on strings, both cases, capitals and lower case letters are considered equivalent.? This has to be taken into account. 100 :? 110 :120 REMark In Minerva SuperBASIC130 case$ = "" : REMark "a" == "A" - both cases140 SELect ON case$150 = "a" : PRINT 'Choice is "A"'160 = "b" : PRINT 'Choice is "B"'170 = "c" : PRINT 'Choice is "C"'180 = "d" : PRINT 'Choice is "D"'190 = "e" : PRINT 'Choice is "E"'200 = "f" : PRINT 'Choice is "F"'210 = CHR$(27) : PRINT 'Esc pressed'220 END SELect230 : 2000 REMark In SMSQ/E S*BASIC2010 REMark Note: MANIFEST is optional TURBO command for extra constant checking2020 :2030 MANIFEST : _a =? 97 : A_ = 652040 MANIFEST : _b =? 98 : B_ = 662050 MANIFEST : _c =? 99 : C_ = 672060 MANIFEST : _d = 100 : D_ = 682070 MANIFEST : _e = 101 : E_ = 692080 MANIFEST : _f = 102 : F_ = 702090 MANIFEST : ENTER = 10 : Esc = 272100 CLS2110 REPeat loop2120 PRINT 'Choose case: Press a letter between "a" and "F" ';2130 case = CODE(INKEY$(#1,-1)) : IF case <> ENTER : PRINT CHR$(case); " ";2140 SELect ON case2150 = _a,A_ : PRINT 'Choice is "A"'2160 = _b,B_ : PRINT 'Choice is "B"'2170 = _c,C_ : PRINT 'Choice is "C"'2180 = _d,D_ : PRINT 'Choice is "D"'2190 = _e,E_ : PRINT 'Choice is "E"'2200 = _f,F_ : PRINT 'Choice is "F"'2210 = Esc? ?: PRINT 'Esc pressed' : EXIT loop2220 = REMAINDER : PRINT 'Try again'2230 END SELect2240 END REPeat loop2250 PRINT 'Test complete'2260 PRINT #0,'Test complete' Michael -- Subject: Digest Footer ___ QL-Users mailing list -- End of Ql-Users Digest, Vol 196, Issue 7 Think this is a tidied/readable version.. ___ QL-Users Mailing List
Re: [Ql-Users] Q40i/Q60 board availability
Hi Jason, > I realize I'm 19 years late to the party, but does these boards exist > anymore? Nice to hear that my good old design is still of interest. The Q60 still exists and has a die-hard user base, but is no longer officially manufactured. The Q40/Q60 version of the SMSQ/E operating system is still maintained. It appears that your interest is not QL related, but more driven by the 68060 CPU as such. Can you tell us a little more about it? Would you want a QL operating system at all, or is 68K Linux preferred? > How hard would it be to get them made again? There is a slow-going effort to build a few more boards from leftover parts, on a hobbyist basis. The outcome is hard to predict. >From time to time, I vaguely consider designing a completely new 68060 mainboard with modern HDMI video output, and SDHC cards instead of floppy and IDE harddisk. Would such a machine come close to what you like? All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
> If it is the drives, well, that's the problem Thierry has mentioned. By the way I doubt the ISA bus reset is required, which is adding to the delay. Neither QDOS Classic nor my own Utility ROMs use it. Never seen any issue. ___ QL-Users Mailing List
Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
Ralf Reköndt via Ql-Users wrote: > Hmm, so why use it in an EPROM? You need some kind of ROM to boot the machine and load the OS. This can be a separate loader, like inside the Q68, but then it needs to access mass storage to load the OS. In case of the Q40 and Q60, the OS can boot completely without any mass storage, which is faster. ___ QL-Users Mailing List
Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)
Marcel Kilgus via Ql-Users wrote: > Fabrizio Diversi via Ql-Users wrote: >> This issue seems to address newer SMSQ/E in Eprom, I used second >> hand ST M27C1024 eprom 120ns. I ordered completely new eprom from >> China the same Brand but with 100ns.not sure where is the >> problem. > > SMSQ/E never executes from EPROM, it is always copied to RAM first. So > any problem with the EPROM would certainly result in an instant crash. Since the Q60 has no separate loader like the Q68, SMSQ/E has to execute from EPROM at first, to do the copying. If the EPROM has a timing problem on the borderline, it is possible that only very little data is corrupted during the copying process from ROM to RAM. Which could result in something that is not an immediate crash. (I'm not saying it is a timing problem.) ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
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. Also they are quite compact. Thanks for pointing to that! Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Fabrizio Diversi via Ql-Users wrote: > 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 . They work, but have the problem of not allowing a slave device on the same connector. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Thierry Godefroy via Ql-Users wrote: > 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). Same here, unfortunately. Except that, it seems a nice alternative with the full possible speed. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Wolfgang Lenerz via Ql-Users wrote: > The Qx0 uses the UV erasable 27c1024. > I don't remember whether other types of EPROM, especially EE ones will fit. The 27C4096 fits. Nowadays, most of them are OTP though. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Fabrizio Diversi via Ql-Users wrote: > New configuration I am approaching is to burn new ROM able to load > SMSQ/E 3.36 directly without need of at least one atari partition and > then have a single CF/SD (1 or 2 partition, doesn't care) to be able to > load until 8 QXL.WIN and to have the freedom to share them with Q68. Especially for sharing with the Q68, the new feature is useless, as it does not exist there. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Thierry Godefroy via Ql-Users wrote: > 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... For me the question is: Where is even the slightest practical benefit of the new feature? Up to eight QLWA containers can be used without it. I know it is hard to abandon code, after time was already invested, but in this case I'd vote for it. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.36
Hi Wolfgang,
> SMSQE 3.36 is out. You can get it as usual on wlenerz.com/smsqe
Many thanks for your maintainance work, covering so many different machines.
Not that I actually use the Q68 FAT driver, but by chance I noticed a
configration issue. The "Fat1_ is on card =>" entry exists, but can not
be selected. ("Fat2_ is on card =>" and higher numbers work.)
> For the Q68, cards need not be initialized for normal access (a
> CARD_INIT might still be necessary for the CARD_xx commands).
I have not enough evidence to actually blame this feature, but would
recommend a little caution. I had strange issues two times, since I
tried it instead of just rebooting. In both cases, problems appeared in
connection with overwriting existing files. I had to concentrate on
other stuff, so I didn't actually investigate. Reverting to a backup
image cured it. Could be just coincidence with something else.
> The
> keyboard may be handled via interrupts, which may help with certain
> USB-PS/2 adapters (this needs your FPGA to be updated, though). SER
> works again correctly.
Please note that the mentioned FPGA update not just adds keyboard
interrupt support, but also lowers the rate in which the PS/2 ports are
sampled. At the moment we wait on more testing. Since the Q68 has no
field update for the FPGA, persons who have those (not fully PS/2
standard conforming) adapters should ask Derek.
All the best
Peter
___
QL-Users Mailing List
Re: [Ql-Users] QL User grapic competition from 1985: Tree
Michael Berger wrote: > I have a 1985 issue of 'QL User', where the results of a graphics > competition were posted. Basic programs of limited length, to produce > some image. The contribution that impressed me most (by far!) was 'Tree' > by A. Pritchard. That was a random image with a tree in the foreground, > an island in the background. With the tree being painted by recursion. Very cool indeed, thanks for sharing! ___ QL-Users Mailing List
Re: [Ql-Users] QBOX BBS for TCP/IP released!
Am 04.03.2020 um 17:26 schrieb Jan Bredenbeek via Ql-Users: > I've just ordered Schottky diodes for the operation 'Q68-net'. > I followed the discussion on the QL forum about fitting network sockets to > the Q68 case. This doesn't look very straightforward. I think removing the > on/off switch and mounting the network socket there will be the best > solution with minimal impact (I only need one network socket). If you have no problem with network plugs on the front side, then I'd recommend drilling a hole to the front panel. > Or is there a simple way to convert the sound output socket to a network > socket with minimal damage? It is even possible without *any* damage, but you would lose sound. Some tinkering would be involved, drilling a hole is definitely easier. Peter ___ QL-Users Mailing List
Re: [Ql-Users] QBOX BBS for TCP/IP released!
Hi Jan, > I personally use a Linux machine or Raspberry Pi with tcpser and a> > USB-to-serial converter to exchange files to my BBQL. How about using a Q68 as bridge from Linux (SER) to QLNET (BBQL)? This way you could use higher baudrates. And network is much faster on the BBQL than SER. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
Thierry Godefroy wrote: >> 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). Those are small PLDs, optimized almost to the last gate, not FPGAs, and 800x600 is not doable. I would find an answer to my original question interesting. ___ QL-Users Mailing List
Re: [Ql-Users] Q60 + OSSC
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? >> 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. 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? >> 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 Using a hot air gun like in that video looks even more difficult than the IR lamp I'm experimenting with. All the best Peter ___ QL-Users Mailing List
[Ql-Users] Q60 + OSSC
Thierry Godefroy wrote: > 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 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. 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. At the moment I still struggle with manual BGA soldering. ___ QL-Users Mailing List
Re: [Ql-Users] FGPA Anyone (Mister)
Marcel Kilgus wrote: > Daniel Baum via Ql-Users wrote: >> I'm afraid your core doesn't seem to work on my Mister (or I've messed up >> somehow). I get a black screen with a white Minerva logo in the bottom >> right corner, which appears to be gradually overwritten with more blackness. >> I wonder if it's the problem that some cores have with 128MB SDRAM cards? > > When I did this thing there were no 128MB cards, so this could very > well be it, yes. Will have to see what's different with them. Maybe just an extra address or chip select line that needs a fixed level? ___ QL-Users Mailing List
Re: [Ql-Users] FGPA Anyone (Mister)
Thierry Godefroy wrote: > 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 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. Is the native resolution of your monitor 1920x1080? The published Q60 screen appears a little blurred, but that might be a matter of taking the photo. A close-up would be interesting. ___ QL-Users Mailing List
Re: [Ql-Users] QL-VGA
Norman Dunbar via Ql-Users wrote: > I get that it's a software description of some hardware. Not software. It is simply a hardware description, and the result is pure hardware, i.e. flipflops, gates, wires. You can as well describe he same hardware in a schematic rather than text. It is important to understand that no emulation is involved and there is no difference to other logic chips, except that an FPGA can be re-configured. Like GALs, just more complex. >From the same hardware description, is is also possible to manufacture customized chips, called ASICs, which have a fixed logic. ___ QL-Users Mailing List
[Ql-Users] The Pawn adventure with graphics on the Q68
Hi, just in case not everyone is on the QL forum, there is an exciting new software development underway. "The Pawn" and other "Magnetic Scroll" games are back. And this time not just text but with graphics! The first supported machine is the Q68, executables are already downloadable, on page 3: https://qlforum.co.uk/viewtopic.php?f=3=3033 Work for other platforms, even the BBQL, is ongoing. Definitely worth a look, impressive! Peter ___ QL-Users Mailing List
Re: [Ql-Users] QLTools - 2.15.5 available
Hi Norm, > One of the reasons I did some work was a recent almost total loss of over 300 > floppies going back many years. Oh my. That sounds similiar to my Q60 harddisk loss long ago. > I have qxltools on my laptop but haven't looked at it for ages, I think I had > problems compiling it - but I can't remember. It might well be in line for > some tittivation! Sounds good. I could compile qxltools, but that was long ago. My concern are image sizes over 16 MB and some strange characters in the commandline output. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] OT new 68k Core
desin via Ql-Users wrote: > > FX CAST cycle accurate Atari ST FPGA core > > http://www.atari-forum.com/viewtopic.php?f=117=34555 > and > http://atari-forum.com/viewtopic.php?f=28=34554 I don't find this off-topic at all. The logic seems to include a new 68000 CPU core, which is relevant for QL hardware. The core seems to be a cycle-accurate 68000 CPU, which could allow to implement a GoldCard on FPGA without repeating the difficult software timing adjustments for QL network and Microdrives. The 68000 CPU core used inside the Q68 is not cycle-accurate. For speed reasons this can be nice, like the single-cycle multiplier. But whenever there are timing loops, a cycle-accurate implementation helps a lot. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] QED v2.01 released!
Jan Bredenbeek via Ql-Users wrote: > I'm very pleased to present you release 2.01 of QED, my ever popular text > editor! > > This release comes exactly 30 years after version 1.01, which has been > included in many QL software distributions. Awesome! Many thanks, Jan! ___ QL-Users Mailing List
Re: [Ql-Users] BouQLder Qlash source code
Hi Wolfgang, > the source code for BouQLder Qlash is now available from my site. Amazing work. And a lot of comments. I like this one: "Normally, a sound is only played if the previous one is finished. An explosion, though, is always played" :-D Thank you very much Peter ___ QL-Users Mailing List
Re: [Ql-Users] BouQLder Qlash
Wolf via Ql-Users wrote: > thereTs a new game on my site called BouQLder Qlash. > It's an an arcade game inspired by an old 8 bit game called Boulderdash. > I programmed it initially to showase some of the capabilities of the Q68. Awesome!!! Looks like the first QL arcade game of this century! You make the impossible possible ;) Many thanks, great work! Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q40 and Q60 video controller for flatscreen monitors
Am 01.05.2018 um 20:55 schrieb Thierry Godefroy via Ql-Users: > 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. Sorry I wasn't precise. I was not referring to the original signal, but the general issue with 1024x512, after improving timings for flatscreen already. I generated more suitable 1024x512 signals (with relaxed front/back porch timings) that are accepted but misunderstood. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q40 and Q60 video controller for flatscreen monitors
Dave Park via Ql-Users wrote: > What are the frames per second and number of lines in the image? Originally 72 Hz, 512 visible lines. > What 'legal' signal is it most similar to? At design time it was fine to use any legal resoltion of a multisync CRT monitor. The idea was to stay at the QL-style 2:1 ratio on 4:3 screen, epscially for the QL modes 4 and 8. Most flatscreens misunderstand the signal as 800x600, leading to bad interpolation. > Is it possible to alter the frame rate Yes I did that, as I wrote. > and/or to supply a pixel clock signal? Yes, but it is at the very maximum. Otherwise I would of course have increased it already. > This could open up the option of DVI conversion. (I have never > owned a QX0 and don't know if it uses a card or custom logic.) There is a slight chance to generate a pseudo FullHD signal, but only at unusually low frame rate. I keep looking at that, but it is difficult, logic was already optimized extremely to fit the chip. And not all monitors would accept it. > I'm just trying to understand the problem and why the LCD monitor won't > sync the nonstandard signal. Some do sync, but usually blur the picture by sampling 800 points on a 1024 horizontal line. > If it's just one aspect of the signal it may > be easily fixable and retain full screen display. Not easily fixable, I would have done so. Peter ___ QL-Users Mailing List
[Ql-Users] Q40 and Q60 video controller for flatscreen monitors
Hello, I have developed an alternative video controller for Q40 and Q60: http://qlforum.co.uk/viewtopic.php?f=2=2434 All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.33
Hi, > But there are some confusing aspects about the Q68 files. > Both count 350.000 bytes, one .SYS and one .WIN. > When Viewed they look the same. Should the .WIN not be a valid QLWA file > containing the .sys? Both are wrong and can not be used by the Q68 Loader without changes. There should only be the .WIN Container and it should be 1 MB in size. (The .SYS File should be *inside* that container.) Peter ___ QL-Users Mailing List
Re: [Ql-Users] Probleme mit smsq_q40_boot_make_bas
Sorry that message was supposed to be private. ___ QL-Users Mailing List
[Ql-Users] Probleme mit smsq_q40_boot_make_bas
Hi Wolfgang, ich benutze das .WIN Archiv der SMSQ/E Sourcen. 1. smsq_q40_boot_make_bas führt menuconfig nicht sichtbar aus, ziemlich verwirrend, da man nicht weiss ob und woher er die Konfiguration dann nimmt. 2. Zeile 760 gibt ein "not found", weil komischerweise ofile$ seinen Wert verloren hat. Könnte man gzip, menu_rext und menuconfig nicht in das WIN File legen? LG Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.33
Hi Wolfgang, fantastic work, many thanks! Now all QL hardware platforms QL, GC, SGC, Q40, Q60 and Q68 share the same, stable filesystem on SDHC cards. And they can exchange it with emulators on the same medium. This was my original hope and vision, when I first started with SD cards on the SGC parallel port and Qx0, first based on mtools, later adapting the Steinkopf drivers, later the QL-SD interface with Qubide format, which then again was used for the first steps on the Q68, leading to QLWA support for all hardware in the end. I could only pioneer FAT32 and the basics of such drivers, and I'm glad that I did. But Wolfgang made everything so much more complete and well integrated. The QL world owes him a big thanks! All the best Peter Am 29.04.2018 um 11:40 schrieb Wolf via Ql-Users: > Hi all, > > SMSQ/E 3.33 is out, get it as usual from > www.wlenerz.com/smsqe > > What's new in this version : > > Final bugfix for LRESPR in procedures (means everybody should upgrade) > Better QL networking. > Gold card is configured not to use ABC keyboard. > Improvements in standard QL EE. > Q68 & SMSQmulator better handling. > > The sources for the stand-alone TK II are included in the SMSQ/E sources. > Moreover, whilst they aren't really part of SMSQE, the new QL-SD drivers > are built on the basis of the SMSQ/E "dv3" driver acihtecture, so their > sources are also included in the SMSQ/E sources (remember, the compiled > drivers are at wlenerz.com/qlsd). > > If you have a Qx0 machine and access to an EPROM burner, this may be of > interest to you : The Qx0 may now have a compressed SMSQ/E so newer > versions thereof fit in the standard EPROMs. There is a certain process > involved in making these EPROMs - but it is clealy described in the > "smsq_q40_boot_doc" or "smsq_q40_boot_txt" files in the SMSQ/E sources. > > Finally, Q68 has better handling of some slower SDHC cards. Also, and > that is an officially unofficial and undocumented feature, the Q68 may > also be able to read most older SD (not SDHC) cards. However, make sure > that this actually works with your cards before using them in earnest. > Offficially, the Q68 still only supports SDHC cards. > > Have fun! > ___ > QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] QL Video Card?
Am 29.03.2018 um 22:59 schrieb Marcel Kilgus via Ql-Users: >> (By the way, I wish Stuart had finished his QL Graphics Card, >> because all the video converters I tried with my QLs suck.) > > Yes, this is true. That's the reason I have built a prototype of a > bus-snooper that mirrors the QL screen on an HDMI monitor, but... damn > it, now that you know I will never finish it :-) Believe it or not, but when I wrote my remark this noon, I was actually thinking "that could be something for Marcel Kilgus" now that he started playing with FPGA. Really. My guess is that you'd use an FPGA with >=32 KB RAM, so why bus-snooping and not fully replace the video area? Just to keep the original video output alive? How would you work around the HDMI licensing costs issue? Personally, I still prefer VGA, because I also have some older monitors and converting VGA to HDMI can be done by small cheap dongles. Peter ___ QL-Users Mailing List
Re: [Ql-Users] QL-SD news
Am 30.03.2018 um 00:47 schrieb Marcel Kilgus via Ql-Users: > Peter Graf via Ql-Users wrote: >> Did you test your logic changes with a non-Tetroid GC inside a QL where >> the original logic did *not* work reliably? >> >> I'm asking, because IIRC you reported total failure of the original >> logic with the Tetroid GC, while my experience was, that non-Tetroid GC >> always basically worked, just not reliably in some QLs. > > As far as I could gather in my limited tests, INGOT 5 never worked > (which includes the Tetroid) and INGOT 6 worked or at least mostly > worked. That makes me a little sceptic, because I have one labelled "INGOT 5" which worked (with the original driver and not fully reliable). >> As for the daughter board, why do you want to re-design it? > > Using the push-to-eject style daughter boards is a lot cheaper and > easier to do than your original design. The card socket I used was around 2 € the last time I looked - no idea why it should be hard to solder. Well, matter of taste. > Besides, I don't have your original designs ;) There is also the option to ask ;) All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] QL-SD news
Am 29.03.2018 um 23:29 schrieb Marcel Kilgus via Ql-Users: > Speaking of only announcing stuff that basically already works, I have > made huge progress regarding my work on QL-SD that I was going to > write about today anyway: > > https://www.kilgus.net/2018/03/29/ql-sd-news/ Must have been a lot of work. Let's hope there will be no further issues, as there is quite a number of combinations to test. By the way, interesting to hear that you prefer my original idea of an internal version. Did you test your logic changes with a non-Tetroid GC inside a QL where the original logic did *not* work reliably? I'm asking, because IIRC you reported total failure of the original logic with the Tetroid GC, while my experience was, that non-Tetroid GC always basically worked, just not reliably in some QLs. That would mean conclusions from Tetroid to non-Tetroid is not possible. As for the daughter board, why do you want to re-design it? Will you upload your logic changes to the QL-SD section of Dilwyn's site? Good luck, Peter ___ QL-Users Mailing List
Re: [Ql-Users] Stuart Honeyball
Am 29.03.2018 um 20:13 schrieb Darren Branagh via Ql-Users: > Dont forget he also designed the ZX Spectrum issue 1 PCB by hand. And approximately 16000 of these machines were produced! Does anyone know how many GoldCards were sold? Peter ___ QL-Users Mailing List
Re: [Ql-Users] Quanta eMag
The printed QUANTA magazine for December/January arrived here today. Derek Stewart via Ql-Users wrote: > Hi, > > Has anyone received the recent Quanta eMags, the last one I received in > October/November 2017. My subscription is in date. > > I tried to email John Southern, but no reply, where he asked me to do an > article on the Q68. > > Is Quanta still running? ___ QL-Users Mailing List
Re: [Ql-Users] Sjef vd Molengraaf
This is very sad news indeed. At Eindhoven I also showed the first Q40 before it had any operating system, and later the first public appearance with QDOS Classic. It was there where Tony Tebby approved my machine and agreed to port SMSQ/E. The Eindhoven meetings in the middle between England and Germany were classic events that will long be remembered. Thank you Sjef van de Molengraaf! Bob Spelten via Ql-Users wrote: > > I am sad to inform you all that Sjef van de Molengraaf passed away earlier > this week at the age of 73. > As long time secretary of the Dutch SIN_QL_AIR foundation he will be > remembered by many international QL'ers. He was the driving force behind > many great Eindhoven meetings during the 90's and later, until they ended > in October 2008. > He seldom posted on this list but it kept him informed of what was going > on in the QL community. > > Our thoughts are with his family. > > Bob ___ QL-Users Mailing List
Re: [Ql-Users] Quanta eMag
Hi Derek, I have the same problem with the magazines. I thought it was because I could not pay QUANTA subscription for some time. QUANTA had difficulties to tell their bank account information. I paid in January. Maybe it is because of Lee Privett passing, which we all understand. All the best Peter Am 09.03.2018 um 10:23 schrieb Derek Stewart via Ql-Users: > Hi, > > Has anyone received the recent Quanta eMags, the last one I received in > October/November 2017. My subscription is in date. > > I tried to email John Southern, but no reply, where he asked me to do an > article on the Q68. > > Is Quanta still running? ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Baud
Hi Fabrizio, > I have done a sufficient number of experiment in copying and executing > files over the sernet@230400 to say that it is working. I'm glad it does, although SERNET alone can not prove the SER-USB adaptor handles 230 kBaud reliably in general. The problems usually pop up when you have no protocol splitting long transfers it into smaller chunks. > I copied also some files over the net, bigger than 1Mb, and then > compared byte by byte. I would like to say that @230400 sernet should > work:-). Thank you for testing and reporting. > The cable I used is coming originally from Laplink package and it is > clearly visible that the cable construction quality is excellent, the > usb/ser adapter is a Digitus one, the "PC" is a Mac Book pro using Win10 > with Parallels...and finally QPC. When I was testing USB-SER adaptors, it was PC to PC. It could be that not having USB-SER adaptors on _both_ sides improves chances. Also I seem to remeber that the "good" one I found back then was also Digitus. By the way, did anyone have success with SERNET on Qemulator? Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Baud
My experience is that internal SER cards for PC tend to work reliably at up to 230 kBaud without handshake, while most USB-SER coverters don't. Usually you notice it only during long file transfers. Am 21.01.2018 um 00:11 schrieb Dave Park via Ql-Users: > Once you're up into 230k territory, the quality of the cable starts making > an extraordinary difference, even if there is UART support for that speed. > > On Sat, Jan 20, 2018 at 3:25 PM, Peter Graf via Ql-Users < > ql-users@lists.q-v-d.com> wrote: > >> Hi Fabrizio, >> >>> configuring the driver in Win10 there are available different predefined >>> speeds, including 460800, so I assume it should work at least from PC >> side. >> >> I know, but that tells nothing about what the adaptor can physically >> hanlde. I have a lot of experience with that, unfortunately. Nine out of >> ten adaptors which allow to select such high speeds, can't even handle >> 230 kBaud PC to PC reliably. >> >> Peter >> ___ >> QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Baud
Hi Fabrizio, > configuring the driver in Win10 there are available different predefined > speeds, including 460800, so I assume it should work at least from PC side. I know, but that tells nothing about what the adaptor can physically hanlde. I have a lot of experience with that, unfortunately. Nine out of ten adaptors which allow to select such high speeds, can't even handle 230 kBaud PC to PC reliably. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Baud
Hi Fabrizio, > Now playing with SMSQ/E sources, according Wolfgang suggestion (Thanks) How do you come to the idea your SER-USB adaptor supports 460 kBaud, even PC to PC? The required RS-232 line drivers are very seldom! Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Baud
Hi Fabrizio, > Finally what is the theoretically max ser speed of the Q68 is? 460 kBaud for the hardware itself (UART and RS-232 driver). But for the overall system, max. 115 kBaud is specified in the Manual. Beyond that it has not been sufficiently tested. Please note that many USB-SER converters for PC start getting unreliable at 230 kBaud already. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Some QL Newbie Questions: Modern video and storage upgrades for QL
Hi Michael, > What is the easiest way to connect a QL to a modern VGA or HDMI monitor? The only converters which work for me at all, are the GBS-8220 and similar. These are VGA converters. I find picture quality poor compared to a suitable CRT monitor, but at least I can work. All my attempts with HDMI converters failed on my three QLs, although I tried several SCART cable wirings. The best I could get was picture going on and off all the time. Others have reported success. > Are there any servers that run on a PC that act as a file server to the QL > over the serial port that could be used in place of floppy/CF/SD hardware? In theory, you could run a PC emulator which accesses those media and connect your QL via a nullmodem cable and the SERNET software. Be aware the QL serial port is extremely slow. For example reading a complete floppy disk would take half an hour this way (if you have luck and there is no reliability problem). Peter ___ QL-Users Mailing List
Re: [Ql-Users] New document on DV3 drivers
Wolf via Ql-Users wrote: > I've added a small technical explanation of DV3 drivers for SMSQE to the > additional info and data section on the SMSQE site. Which is here: http://www.wlenerz.com/smsqe/DV3_Device_Drivers.zip Good stuff, thanks Wolfgang! Peter ___ QL-Users Mailing List
Re: [Ql-Users] How to reach QUANTA membership secretary?
Hi John, did you find the bank account information? What shall I do? All the best Peter Am 28.11.2017 um 15:58 schrieb John Southern via Ql-Users: > Hi Peter, > > I will dig out the details of the bank account and forward them on to you. > > Regards > John > > On 26 Nov 2017 1:54 p.m., "Peter Graf via Ql-Users" < > ql-users@lists.q-v-d.com> wrote: > >> Hi, >> >> I'm trying to pay my QUANTA subscription without Paypal. In the papers I >> received, bank transfer to QUANTA is offered, but the required account >> information was not included. >> >> I found no email address of the QUANTA membership secretary, neither in >> the papers, nor on the website. And using the form on the QUANTA website >> did not result in a response. >> >> What shall I do, write a postal letter, asking for the required >> information? Or is there an easier way? >> >> All the best >> Peter >> ___ >> QL-Users Mailing List >> > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] Mode 33 to 32
The least significant of the 6 green bits. Am 16.12.2017 um 19:12 schrieb pjwitte via Ql-Users: > Sorry for yanking your chain again so soon but, on going the other > way, ie from mode 32 to 33, what is the best value for W? g6, 0, 1..? > > Per > > On 16/12/2017 18:13, pjwitte via Ql-Users wrote: >> Aah! Perfect! Thanks Marcel, youre a star! >> >> So in fact I interpreted the input wrong. It should have been: >> >> GGGggRRR rrBBBbbW <- input >> >> and >> ggWBBBbb RRRrrGGG -> output >> >> Seems so obvious now ;) >> >> Per >> >> On 16/12/2017 15:30, Marcel Kilgus via Ql-Users wrote: >>> 320 c$ = c$(4 to 5) & c$(16) & c$(11 to 15) & c$(6 to 10) & c$(1 to 3) >> >> >> ___ >> QL-Users Mailing List >> >> >> > > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] Mode 33 to 32
pjwitte via Ql-Users wrote: > I havent tested your suggestion yet, Wolfgang, but what I found so far > was that gggbrgg0 appears (to my eye) to look cleaner than > gggbrggW. Is that so wrong? ;) It is right, because gggbrggW has the W at the wrong bit. It must be the least significant green, which is what Wolfgang an me wrote. ___ QL-Users Mailing List
Re: [Ql-Users] Mode 33 to 32
But the same as my proposal :) Wolf via Ql-Users wrote: > No, not the same as %gggbrggW, as suggested in the original post. > > Wolfgang > > On 16/12/2017 10:18, Peter Graf via Ql-Users wrote: >> Wolfgang Lenerz via Ql-Users wrote: >>> I'd do it this way >>> >>> %ggWbrggg >> >> Which is the same :) ___ QL-Users Mailing List
Re: [Ql-Users] Mode 33 to 32
Wolfgang Lenerz via Ql-Users wrote: > I'd do it this way > > %ggWbrggg Which is the same :) ___ QL-Users Mailing List
Re: [Ql-Users] Mode 33 to 32
> What do I do with 'w' in either case for best results? I would just use the RGB0 bit of mode 33 as G0 Bit of mode 32, which is what you probably do already. There is no perfect translation, since mode 33 has 64 clean grey levels, while mode 32 has only 32. There will be a minimal green tint in mode 32 where RGB0 of mode 33 was set, but almost not noticeable. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.32
Tobias Fröschle via Ql-Users wrote: > That’s really great. Eager to try an IDE-to-SD Adapter and see how direct > data exchange will work. The adaptor I use is called "Kalea Informatique Adapter IDE 3,5 Zoll 40 Pins auf SD-Card", available off the shelf from from amazon. I could directly use a card from the Q68. The new DISP_MODE command for Qx0 made it even easier, because the first 4 modes are the same. But don't forget a backup of your card, like I did :( Let us know your experience! Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQE 3.32
Wolf via Ql-Users wrote: > - Filesystem for QUBide drives. This is a very nice feature especially for native hardware, allowing direct data exchange between Q68 and QL with QL-SD. > - Q40/Q60: > It is now possible to use IDE hard disks formatted with FAT32 and contining > QXL.WIN "drives" A little background info: I was originally planning to design a Q68 compatible SDHC card interface for the Q40/Q60. But driver and hardware use SPI mode, which limits theoretical speed to 3 MB/s. On a Q60 that would not be optimal - even practical speed of a tradititional harddisk via the ISA bus was higher. It turned out that IDE-SD Adapters worked relatively well with SDHC cards, so I asked Wolfgang, why not use IDE instead. Saving the time and cost for hardware development and getting better performance. However these adaptors should be used with caution. Firstly, I could only find adaptors which expect to be IDE "master" and are not jumperable to "slave". This can be an ugly limitation, if you only have one ISA I/O card and it is only for two IDE drives. Personally, I have an ISA card for 4 IDE drives, but these days not easy to find anymore. Secondly, I have experienced severe problems installing "ShoeString" Linux. The original Q60 Linux installed, but did not "like" a "slave" present on the same IDE bus as the IDE-SD adaptor (similar issue with compact flash). It could be that Linux tries to use advanced ATA commands which are well supported by harddisks, but maybe not on those adaptors. If only SMSQ/E is used, I did not notice problems with a slave present on the same bus. However, testing was only minimal. Important: You can not use Tony Tebby's mkpart program to partition FAT32 IDE drives. Two major reasons: 1. The standard partition table was Atari style, but is DOS style for FAT32. 2. In order to make a card readable on x86 PC, the Q40/Q60 must swap all bytes on the ISA bus for DOS style IDE devices. This is because of the ugly little-endian number representation on x86 PCs. 68K represents numbers as they are normally read, and so does the traditional IDE driver of the Q40/Q60. Great job, Wolfgang!!! Peter ___ QL-Users Mailing List
[Ql-Users] How to reach QUANTA membership secretary?
Hi, I'm trying to pay my QUANTA subscription without Paypal. In the papers I received, bank transfer to QUANTA is offered, but the required account information was not included. I found no email address of the QUANTA membership secretary, neither in the papers, nor on the website. And using the form on the QUANTA website did not result in a response. What shall I do, write a postal letter, asking for the required information? Or is there an easier way? All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Hi Duncan, > the version of menuconfig I have is 3.36 and is dated 2003. Thank you. That's it! :) With menuconfig 3.36 it worked. > The version of menuconfig on Dilwyn's site is 3.34 Found even 3.36 when I searched again. Maybe it is stored at more than one location. All the best Peter ___ QL-Users Mailing List
[Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Hi, the original SMSQ/E 3.31 Q40 boots here on my Q60/80 with LRESPR. But if I do even the slightest configuration with MENUCONFIG, it crashes on boot. Just language settings, nothing else. Can anyone with Q60 reproduce this problem? All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q40 display mode
Am 11.11.2017 um 22:06 schrieb Derek via Ql-Users: > I will check on my Q60 the DISP_TYPE values and report back tomorrow. I looked already. Seems always 33. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q40 display mode
Am 11.11.2017 um 17:58 schrieb Giorgio Garabello via Ql-Users: > 64 – 24-bit colour mode (no hardware supports this at the time of writing) Hmmm... was there _software_ support at the time of writing? > DISP_TYPE > The DISP_TYPE function is used to find the type of display. For the Q40, > there are two values that may be returned. > 0 Original ST QL emulator (this value is returned on QL based hardware). > *1 16 bit colour mode.* The Q40 supports both original QL hardware modes and 16 bit highcolour. It depends on what you select. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Dock
Hi Wolfgang, > Concerning dock, this is supposed to be a program run in the background. I figured that, but started a second SBASIC and used LRUN from there - which didn't work. > Start with EX, not LRUN That, plus QPRT v0.14 does the trick. However, I'm still puzzled that the missing keyword from QPTR didn't return an error, and that a BASIC program can crash the machine. Thanks, really great idea. At least for my favorite 512x384 mode on the Q68 it runs smoothly. Just need to create smaller icons... Thanks, Peter ___ QL-Users Mailing List
Re: [Ql-Users] Dock
François Van Emelen via Ql-Users wrote: > RPTR is part of the pointer toolkit ‘qptr_rext’. Once loaded Dock does > what it is supposed to do. Not here, same hang/crash. At least with the 'qptr_english_bin' from Wolfgang's site. Not sure it really is because of RPTR, but in one of my debug attempts yesterday, the program seemed to get short before it, but never behind it. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Dock
Peter via Ql-Users: wrote: >> I would have a look at the OUTLN and WINDOW commands a bit up from there >> [...] > > Wow, you are really an ace! Setting OUTLN to 1 pixel cures the RPTR > crash. WINDOW can remain unchanged. Not under all circumstances... something is definitly buggy. And there seemed a difference between QPTR loaded or not loaded, but I can't reproduce at the moment. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Dock
Hi Tobias, > I would have a look at the OUTLN and WINDOW commands a bit up from there > [...] Wow, you are really an ace! Setting OUTLN to 1 pixel cures the RPTR crash. WINDOW can remain unchanged. However, an SBASIC command should not crash the machine by a wrong parameter. > Doesn't work here as well in QPC2 and SMSQ/E 3.30 Good to hear the Q68 is not at fault :) Thanks! Peter ___ QL-Users Mailing List
Re: [Ql-Users] Dock
Hi Fabrizio, RPTR does not seem to need QPTR, otherwise the keyword wouldn't exist. Anyway if I load QPTR, "dock" hangs/crashes the same. More ideas? Thanks, Peter Am 07.11.2017 um 21:35 schrieb Fabrizio Diversi via Ql-Users: > Peter , > > dock is a nice program that use QPTR toolkit (RPTR), you can find the > toolkit manual on Dilwyn web site. It work nicely on SMSQmulator, QPC > and Q60. > > Ciao > > > Fabrizio > > > On 07/11/2017 19:28, Peter Graf via Ql-Users wrote: >> Hi, >> >> I try to run this nice looking "dock" for SMSQ/E: >> >> http://www.wlenerz.com/qlstuff/dock_bas.zip >> >> It seems to crash or hang at the RPTR command in line 1020, which I can >> not find in the SMSQ/E Manual on Dilwyn's Website. >> >> Does anyone else use this program and can give me a hint? >> >> All the best >> Peter ___ QL-Users Mailing List
[Ql-Users] Dock
Hi, I try to run this nice looking "dock" for SMSQ/E: http://www.wlenerz.com/qlstuff/dock_bas.zip It seems to crash or hang at the RPTR command in line 1020, which I can not find in the SMSQ/E Manual on Dilwyn's Website. Does anyone else use this program and can give me a hint? All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] Possible bug in the (experimental) QubIDE feature of QXLWinReader
Hi Wolfgang, > the new version of QxlwinReader is on my website. Many thanks! If I had to vote for the "tool of the year", QxlwinReader would be it! :) Extraordinary useful for the development of the Q68! Without QxlwinReader, there was always an emulator or Wxqt2/qltools involved when transferring files to the Q68 over the internet. QxlwinReader proofed much easier to use for me and saved lots of time. Great work! Peter ___ QL-Users Mailing List
Re: [Ql-Users] QL MODE 8 Flash Bit
Hi Jan, > The flashing is up to and including the pixel which has the flash bit on > to turn flash off. Thanks for this precise info! > I've tested this on a real QL and it looks like the blink frequency is > 16/50th of a second which is a bit slower than the software-generated > blinking of the window's cursor (12/50th second). So a complete blink > cycle will be 32/50th second. Thanks. I just measured exactly the same with a stop watch. I alread have a hardware implementation now. Not just as easy when a pixel really consists of 12 pixels... I just noticed the work was in vain, because SMSQ/E does not seem to support FLASH in MODE 8. At least not if I test with SBASIC. All the best Peter ___ QL-Users Mailing List
Re: [Ql-Users] QL MODE 8 Flash Bit
Hi Jan, > It works in a serial fashion, much like the old Videotex/Prestel standard. > When you set the flash bit on a pixel, the colour of that pixel is used > as background flash colour for the rest of the line until another flash > bit on the same line is encountered. > E.g. when a pixel has red colour with flash on, the rest of the pixels > on the line will flash between the original pixel colour and red until > the next set flash bit. The "until" is ambiguous. When that next pixel occurs, does it still use the background colour of the previous pixels, or already the colour in it's own colour bits? Also, is there any exact info about the blink frequency? > Hope you'll find this useful. It is useful, thanks! But not yet sufficient for the implementation. Peter ___ QL-Users Mailing List
[Ql-Users] QL MODE 8 Flash Bit
Hi, today I noticed that my MODE 8 Flash Bit implementation in the Q68 was never completed. It is 11 years ago that I designed the video controller, and now I don't even remember how exactly the QL hardware used that bit at all. Especially, I don't know how the background colour for the flashing area is determined! Could anyone enlighten me? Quick reply would be nice, release date nearing quickly... All the best, Peter ___ QL-Users Mailing List
Re: [Ql-Users] Stupid AND
Wolfgang Lenerz via Ql-Users wrote: > Just a rant about the SBasic AND operator. > > Suppose this: > > 10 a=0 > 20 b=10 > 30 if (a<>0 AND b/a=5) > 40 do_something > 50 end if > > Run it and what happens? > > You get an "overflow" error at line 30. > You get this error because it is trying to evaluate the second condition > (b/a) and failing as a=0 and you can't divide by 0. > > BUT WHY IS IT TRYING TO EVALUATE THE SECOND CONDITION IN THE FIRST PLACE? Maybe this wise language includes Chinese or Persian philosophy? > The first condition (a<>0) is NOT met and so, in any other programming > language I use, the second condition isn't even tested, as the result > will be "false" anyway because of this. IIRC other languages also do not _guarantee_ to stop evaluation after a lefthand AND condition failed. Peter ___ QL-Users Mailing List
Re: [Ql-Users] Q68 Advance Notice 2 - Pricing
Hi Gerhard, >> 3. There can be no promise of ethernet software drivers, although >>I would like them for myself, building upon my QLwIP project. > > Tell me(us) more about your QLwIP project (no need of inventing diversity of > projects) QLwIP is a combination of - A QDOS native TCP/IP Stack - QDOS native drivers for SER (SLIP) and ethernet (Q40 & Q60) - Text mode Webbrowser - Mail client (SMTP & POP3) - Webserver I did most of the work about 15 years ago and have publicly demonstrated that QLwIP works, but never finished it to public release for various reasons. If I find the time someday, I could adapt it to Q68 and SMSQ/E. Since the Q68 ethernet hardware differs a lot from the Q40/Q60, this driver part must be rewritten. Also there are new difficulties, like the fact that most email providers no longer offer unencrypted SMTP & POP3 access. So, no promise. Peter ___ QL-Users Mailing List
