Re: [Ql-Users] SMSQ/E 3.39
On Monday, 11. March 2024 15:20:57 (+01:00), George Gwilt via Ql-Users 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 Hello Richard, thanks for letting us know, my sincerest condolences. He had a very sharp mind, even wrote the first draft of the 68020 emulation core for QPC in PC assembler. Also enjoyed meeting him on our trips to England. My last contact was probably over 10 years ago, but every few years he came to my mind and I wondered how he was, considering that he seemed to be a bit older even back then. Do you mind sharing his age? I hope his last years were good ones. Regards, Marcel P.S.: Sorry everybody, currently a bit out of the QL world, it was more luck than anything that I've seen the message today. I hope one day I can partake a bit more again. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Op 11/03/2024 om 15:20 schreef George Gwilt via Ql-Users: 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 May he rest in peace. François Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
I'm gutted to hear of George's passing away. I had a lot of dealings with George when I was writing Assembler articles for QL Today, there wasn't ever an article that George didn't have a comment on, but mostly he had ideas to improve things. For which I was grateful. My deepest sympathies to his family. He will be missed. Regards, Norman. -- Author of "Arduino Software Internals" and "Arduino Interrupts". ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Richard, My condolences on the passing of your father. I used all the software he wrote and he used some computer hardware I built. I always enjoyed talking to George at QL shows and found all his presentations, really interesting. I am really saddened by his passing. Regards, Derek On 11 March 2024 14:20:57 GMT, George Gwilt via Ql-Users 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 > > > > >> On 25 Feb 2024, at 20:54, qlus...@sinclairql.net via Ql-Users >> wrote: >> >> >> This is great news! >> >> It took me some time to do a first test run with QPC2 and QL/E v3.23 this >> evening. So far all is well. >> >> QL forever! >> Urs >> >> ___ >> QL-Users Mailing List > >___ >QL-Users Mailing List --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Richard, My condolences. Thank you for letting us know. George was one of the greats. He will be missed! Per On 11/03/2024 15:20, George Gwilt via Ql-Users 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 On 25 Feb 2024, at 20:54,qlus...@sinclairql.net via Ql-Users wrote: This is great news! It took me some time to do a first test run with QPC2 and QL/E v3.23 this evening. So far all is well. QL forever! Urs ___ QL-Users Mailing List ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
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 > On 25 Feb 2024, at 20:54, qlus...@sinclairql.net via Ql-Users > wrote: > > > This is great news! > > It took me some time to do a first test run with QPC2 and QL/E v3.23 this > evening. So far all is well. > > QL forever! > Urs > > ___ > QL-Users Mailing List ___ 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
Hi Jan This was posted on the QL Forum: https://qlforum.co.uk/viewtopic.php?t=2097=PS%2F2+Q68=160 Repeated here: Just a further note on the topic of PS/2 Splitter cables. I recently purchased a Genius DX-110 Optical Mouse, on connecting the mouse to the Q68, via Splitter cable, stopped the Q68 booting up at the Ram Test stage, or more specifically at the point where the Q68 detects the PS/2 Mouse. A Perixx Mouse 201-B PS/2 mouse works perfectly. I examined the Genius DX-110 PS/2 Connector, which has these connections, it seems that the mouse connections use the Keyboard Data and Clock connections.: Mouse Data connected to Keyboard Data 1 Mouse Clock connected to Keyboard Clock Pin 5 The Q68 expects the Mouse Data to be on Pin 2 and Mouse Clock on Pin 6 as per the so-called IBM standard: This is the probable reason of the failure of PS/2 Mouse(s) (...Mice) on the Q68, the PS/2 Mouse to be connected to a PC uses the Keyboard Data and Clock connections and the PC PS/2 Controller chip on the PS/2 Interface decides whether the data supplied is keyboard or mouse and sends the data to the correct port. In the case of the Q68, which uses Pins 2, 6 for Mouse Data and Clock signals will fail on the PC standard Mouse connections using Pins 1, 5 for Mouse Data and Clock signals. A possible solution is to interchange Pin 1,2 and Pin 5,6 for the Q68 to use a PC PS/2 Mouse. I have some PS/2 Splitter cables that do not work with the Q68, but interchanging 4 wires in the Mouse connector, get the splitter working. Regards Derek On 29 February 2024 22:58:09 GMT, Jan Bredenbeek via Ql-Users wrote: >Hi Dilwyn, > >On 29-02-2024 19:05, Dilwyn Jones via Ql-Users wrote: > >> I might agree with that, were it not for the fact that there has been >> no issue whatsoever with running SMSQ/E on it (apart from the fact I >> have to configure it not to try to do fast SD card access). >> >> Anyway, once Derek has been able to reprogram it, we'll know if it's >> the software version or something else. >> > >I'm curious as to how you have connected the keyboard to the Q68. Is it >keyboard only or keyboard + mouse via a spiltter? >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. I have to reverse keyboard and mouse plugs to make it work. >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). > >Also, you might check if the 5V power supply is sufficiently stable (the Q68 >itself runs at 3V but the keyboard at 5V). > >I've got a reply today from Mark, he still has the freeze issue you describe >so you're not the only one with this problem. > >Best Regards, >Jan >___ >QL-Users Mailing List --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Dilwyn, On 29-02-2024 19:05, Dilwyn Jones via Ql-Users wrote: I might agree with that, were it not for the fact that there has been no issue whatsoever with running SMSQ/E on it (apart from the fact I have to configure it not to try to do fast SD card access). Anyway, once Derek has been able to reprogram it, we'll know if it's the software version or something else. I'm curious as to how you have connected the keyboard to the Q68. Is it keyboard only or keyboard + mouse via a spiltter? 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. I have to reverse keyboard and mouse plugs to make it work. 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). Also, you might check if the 5V power supply is sufficiently stable (the Q68 itself runs at 3V but the keyboard at 5V). I've got a reply today from Mark, he still has the freeze issue you describe so you're not the only one with this problem. Best Regards, Jan ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
I might agree with that, were it not for the fact that there has been no issue whatsoever with running SMSQ/E on it (apart from the fact I have to configure it not to try to do fast SD card access). Anyway, once Derek has been able to reprogram it, we'll know if it's the software version or something else. On Thu, 29 Feb 2024 at 17:59, Peter Graf via Ql-Users wrote: > > 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 ___ 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] SMSQ/E 3.39
1.05 - That's the version that caused me all the Minerva problems. My Q68 is on its way to Derek to reprogram to another version, which should then tell me if all the problems are down to the Q68 version, or if something else is at play. Before sending it off, I gave it one fresh try of the most recent Minerva4Q68, still the same issues as the earlier problems (lockup at various seemingly random points during Minerva startup). Didn't get time to try Smsq/e 3.39 before sending it off. Dilwyn On Thu, Feb 29, 2024, 15:00 Jan Bredenbeek via Ql-Users < ql-users@lists.q-v-d.com> wrote: > > Hi Jan, > > > > I can do any upgrades if you want to send the Q68 to me. > > > > Regards, > > Derek > > I have upgraded the Q68 FPGA firmware to v1.05 last week and everything > is working fine, no lock-ups. However, using 40MHz SDHC clock gets > corrupted file reads, at least when using the original Q68 SDHC card. So > disabled that in SMSQ/E. > > But to stay on-topic: I noticed that the SMSQ/E 3.39 source zip only > contains the smsq branch. Does this mean the other branches have not > been changed since v3.38? > > Jan > -- > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Jan, I can do any upgrades if you want to send the Q68 to me. Regards, Derek I have upgraded the Q68 FPGA firmware to v1.05 last week and everything is working fine, no lock-ups. However, using 40MHz SDHC clock gets corrupted file reads, at least when using the original Q68 SDHC card. So disabled that in SMSQ/E. But to stay on-topic: I noticed that the SMSQ/E 3.39 source zip only contains the smsq branch. Does this mean the other branches have not been changed since v3.38? Jan -- ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
This is great news! It took me some time to do a first test run with QPC2 and QL/E v3.23 this evening. So far all is well. QL forever! Urs ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
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. I might be able to get a second hand FPGA programmer for cheap, I'll let you know when I get it. 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. I've discussed this with Mark, his Q68 was not affected by 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. I'm not sure whether the latest Minerva port will solve all problems. Mark and I managed to pinpoint some issues but so far we haven't been able to solve it completely. One point of interest remains the interrupt register at $18021. I know about the frame and external interrupt bits (3 and 4, respectively) which are emulated from a BBQL. The other bits are irrelevant to Minerva (in fact only bit 3 is checked for a frame interrupt call, else it treats it as external interrupt since early Q68s don't set bit 4). But does writing to this register have any effect? The only purpose would be to clear the respective interrupt by setting bit 3 or 4 (which Minerva does). Bits 0-2 and 5-7 were used for gap, IPC, and transmit interrupts respectively, which are irrelevant to the Q68 and should really be ignored. Minerva doesn't set these bits except when initialising the hardware. -- ___ 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
[Ql-Users] SMSQ/E 3.39
Hi, Please remind me prior to the QL meeting so I bring the equipment and FPGA data. I can bring this as well, if needed. 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. As I said, I never had a problem with it. 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. I never said the contrary. At the risk of repeating myself: If you have a version of the Q68 "Rom" THAT DOESN'T IMPLEMENT THE HIGHER SPEED, SMSQ/E will not try to use the higher speed. 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. 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... Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi I programmed last batch of Q68 with the updated version of FPGA code, which was given the code reference v1.05r I have not supplied any of Q68 with the problematic v1.05. If anyone has any problems or thinks they need a change in FPGA code, please contact me at: de...@q40.de to arrange a free change in FGPA code. With regards to the Fast or 40Mhz SD Card access, the limiting factor maybe due the quality of SD Card. I will have do some more research on the SD Card speeds. I'm the main in my personal use and tests, reports from other users, the 20Mhz works with the majority of SD Cards and I configure SMSQ/E with the Fast SD Card access to NO. If the Q68 can not reach the 3 Windows command line, then I would use SMSQmulator to mount the SD Card and Q68_SMSQ.WIN to a EIN drive and then configure the Q68 SMSQ/E to suit. This saves defragmentation of the FAT32 partition on the SD Card. I will update my Minetva4Q68 setup and see what I can find. --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
I will try the latest Minerva4Q68 as soon as I get time. Dilwyn On Tue, Feb 20, 2024, 07:44 Peter Graf via Ql-Users < ql-users@lists.q-v-d.com> wrote: > 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 > ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
On 19/02/2024 22:57, 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... Best regards, Jan Hi Jan, I can do any upgrades if you want to send the Q68 to me. Regards, Derek ___ 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] SMSQ/E 3.39
On 19-02-2024 15:03, Dilwyn Jones via Ql-Users wrote: My Q68 failed consistently with all SDHC cards I've tried here when configured for fast. It definitely did not slow down automatically when configured to fast (SMSQE 3.38) - the Q68 either crashed or failed to recognise the cards at 40MHz. Either I've been unlucky and NONE of the cards I have are capable of fast, or the "auto-slow" doesn't work at all. Mind you, my Q68 has never been able to run Jan's Minerva port either. Have you tried the latest version 1.64 on my GitHub page? https://github.com/janbredenbeek/Minerva4Q68 Mark Swift and I have spent many hours in researching this issue but so far I haven't got a response from Mark on this version. Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be able to do more research... Best regards, Jan -- Jan Bredenbeek | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
> > Mind you, my Q68 has never been able to run Jan's > > Minerva port either. > > H... > > Are you coming to Germany in May? > > > Wolfgang Afraid not. Already had something else planned for both the original and revised dates. BTW, my Q68 is the v1.05 ROM loader. Given some reports of issues with this version, Derek had offered on QL Forum a few months ago to reprogram that Q68 version back to an earlier one (I forget the details), although I haven't taken him up on the offer, as the "Minerva" problem was the only issue I was having at the time. Dilwyn ___ QL-Users Mailing List
[Ql-Users] SMSQ/E 3.39
Hi Derek, (...) My Q68, latest ROM, hasn't managed to use a single SDHC card at the highest speed. (...) plus a couple of unbranded cards. I have no card which works with Q68 configured for fast card speed. OK, that's certainly strange. Does anybody else here have this problem? Note that, if you have a version of the Q68 "Rom" that doesn't implement the higher speed, SMSQ/E will not try to use the higher speed My Q68 failed consistently with all SDHC cards I've tried here when configured for fast. It definitely did not slow down automatically when configured to fast (SMSQE 3.38) - the Q68 either crashed or failed to recognise the cards at 40MHz. Either I've been unlucky and NONE of the cards I have are capable of fast, or the "auto-slow" doesn't work at all. As I said, note that, if you have a version of the Q68 "Rom" THAT DOESN'T IMPLEMENT THE HIGHER SPEED, SMSQ/E will not try to use the higher speed > Mind you, my Q68 has never been able to run Jan's > Minerva port either. H... Are you coming to Germany in May? Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
> > Also the SD card speed is defaulting 40Mhz , which on normal SD Cards > > causes a lockup. Needs to be 20Mhz or NO in the defaults. > > Just what do you call normal SD cards? I have yet to find an SDHC card > that doesn't work with my Q68 at 40MHz. But, of course, YMMV. I'd be > interested in the make and model of your cards. My Q68, latest ROM, hasn't managed to use a single SDHC card at the highest speed. Kingston 32GB Verbatim 8GB Class 10 Verbatim 16GB class 10 Topesel 32GB micro SDHC with adaptor Qumox 8GB micrSDHC with adaptor plus a couple of unbranded cards. I have no card which works with Q68 configured for fast card speed. > Note that, if you have a version of the Q68 "Rom" that doesn't implement > the higher speed, SMSQ/E will not try to use the higher speed My Q68 failed consistently with all SDHC cards I've tried here when configured for fast. It definitely did not slow down automatically when configured to fast (SMSQE 3.38) - the Q68 either crashed or failed to recognise the cards at 40MHz. Either I've been unlucky and NONE of the cards I have are capable of fast, or the "auto-slow" doesn't work at all. Mind you, my Q68 has never been able to run Jan's Minerva port either. Dilwyn ___ QL-Users Mailing List
[Ql-Users] SMSQ/E 3.39
Hi Derek, (...) The Config Block values are: WIN1: QXL.WIN WIN2: SMS33Q.WIN So the Q68 may not find the WIN1 QWA container file. Fair enough - if you look at the source code, you will note that most of the changes were made there already. I now traced this problem to the program I use to make new versions of SMSQE, which reconfigures the resulting file wrongly. I've corrected this and the next versions will be configured to your taste. On the other hand all you need to do to update the file automatically is EW menuconfig;"\q\uQ68_SMSQ.WIN" which which I think isn't THAT hard. Also the SD card speed is defaulting 40Mhz , which on normal SD Cards causes a lockup. Needs to be 20Mhz or NO in the defaults. Just what do you call normal SD cards? I have yet to find an SDHC card that doesn't work with my Q68 at 40MHz. But, of course, YMMV. I'd be interested in the make and model of your cards. Note that, if you have a version of the Q68 "Rom" that doesn't implement the higher speed, SMSQ/E will not try to use the higher speed One other strange thing is the Q68_SMSQ.WIN file has the English Menu_Rext and German Menuconfig. Yes, that will be corrected also. I have already reported this to Wolfgang Indeed you have. Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi Great updates. One comment with regards to the Q68 update, the WIN1, WIN2 definition in the SMSQ/E config blocks, is defined as: Unfortunately, the file names in the SMSQ/E config blocks are not correct, as detailed in the Q68 Manuals. The Config Block values are: WIN1: QXL.WIN WIN2: SMS33Q.WIN So the Q68 may not find the WIN1 QWA container file. The Q68 will startup to the normal 3 SMSQ/E/QL windows, but will not find the WIN1 drive, normally the WIN drives are defined: WIN1: QLWA.WIN WIN2: QLWA2.WIN Just type LRUN "win8_boot" to run the Menuconfig programme to alter the SMSQ/E defaults. Also the SD card speed is defaulting 40Mhz , which on normal SD Cards causes a lockup. Needs to be 20Mhz or NO in the defaults. One other strange thing is the Q68_SMSQ.WIN file has the English Menu_Rext and German Menuconfig. I have already reported this to Wolfgang --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Totally agree! Per On 19/02/2024 12:38, Fabrizio Diversi via Ql-Users wrote: I would like to express my thanks to Wolfgang, Marcel, Peter and all the other developers, HW and SW, who continue to give QL a future and who allow QL to be not just a retro "phenomenon". Q68, SMSQ/E, Ethernet drivers, slowly and laboriously, keep the QL connected to the future, therefore not just a retro nostalgic memory. Well done everyone. Fabrizio On 17/02/24 13:58, Wolfgang Lenerz via Ql-Users wrote: Hi all, SMSQE 3.39 is out now. Various bugfixes by Marcel SMSQ/E for Q-emulator (by Daniele) EXEP_M EXEP_W keywords and related functions Name of JOB_NAME for Sbasic may now be 48 chars long Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it Q68 better serport handling Q68 allows for configuurable home/end keys SMSQmulator can handle serial ports (experimental feature) CKEYON/CKEYOFF could malfunction under some circumstances SER_FLOW no longer gives error every time it is used Recent thing bugs corrected This can get downloaded from wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
I would like to express my thanks to Wolfgang, Marcel, Peter and all the other developers, HW and SW, who continue to give QL a future and who allow QL to be not just a retro "phenomenon". Q68, SMSQ/E, Ethernet drivers, slowly and laboriously, keep the QL connected to the future, therefore not just a retro nostalgic memory. Well done everyone. Fabrizio On 17/02/24 13:58, Wolfgang Lenerz via Ql-Users wrote: Hi all, SMSQE 3.39 is out now. Various bugfixes by Marcel SMSQ/E for Q-emulator (by Daniele) EXEP_M EXEP_W keywords and related functions Name of JOB_NAME for Sbasic may now be 48 chars long Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it Q68 better serport handling Q68 allows for configuurable home/end keys SMSQmulator can handle serial ports (experimental feature) CKEYON/CKEYOFF could malfunction under some circumstances SER_FLOW no longer gives error every time it is used Recent thing bugs corrected This can get downloaded from wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Thanks Wolfgang, I updated my Q68 and QPC. D. On Sat, Feb 17, 2024 at 12:58 PM Wolfgang Lenerz via Ql-Users < ql-users@lists.q-v-d.com> wrote: > > Hi all, > > SMSQE 3.39 is out now. > > > Various bugfixes by Marcel > SMSQ/E for Q-emulator (by Daniele) > EXEP_M EXEP_W keywords and related functions > Name of JOB_NAME for Sbasic may now be 48 chars long > Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it > Q68 better serport handling > Q68 allows for configuurable home/end keys > SMSQmulator can handle serial ports (experimental feature) > CKEYON/CKEYOFF could malfunction under some circumstances > SER_FLOW no longer gives error every time it is used > Recent thing bugs corrected > > This can get downloaded from wlenerz.com/smsqe > > Have fun! > > Wolfgang > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Thank you, Wolf! :o) Per On 17/02/2024 13:58, Wolfgang Lenerz via Ql-Users wrote: Hi all, SMSQE 3.39 is out now. Various bugfixes by Marcel SMSQ/E for Q-emulator (by Daniele) EXEP_M EXEP_W keywords and related functions Name of JOB_NAME for Sbasic may now be 48 chars long Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it Q68 better serport handling Q68 allows for configuurable home/end keys SMSQmulator can handle serial ports (experimental feature) CKEYON/CKEYOFF could malfunction under some circumstances SER_FLOW no longer gives error every time it is used Recent thing bugs corrected This can get downloaded from wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hey Wolfgang! So, SMSQmulator now has (some level of) SERial port support - that's great! I can now test the QLUB Adapter with it :-) Anything I should know about this experimental feature? M. On Sat, 17 Feb 2024, 12:58 Wolfgang Lenerz via Ql-Users, < ql-users@lists.q-v-d.com> wrote: > > Hi all, > > SMSQE 3.39 is out now. > > > Various bugfixes by Marcel > SMSQ/E for Q-emulator (by Daniele) > EXEP_M EXEP_W keywords and related functions > Name of JOB_NAME for Sbasic may now be 48 chars long > Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it > Q68 better serport handling > Q68 allows for configuurable home/end keys > SMSQmulator can handle serial ports (experimental feature) > CKEYON/CKEYOFF could malfunction under some circumstances > SER_FLOW no longer gives error every time it is used > Recent thing bugs corrected > > This can get downloaded from wlenerz.com/smsqe > > Have fun! > > Wolfgang > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
[Ql-Users] SMSQ/E 3.39
Hi all, SMSQE 3.39 is out now. Various bugfixes by Marcel SMSQ/E for Q-emulator (by Daniele) EXEP_M EXEP_W keywords and related functions Name of JOB_NAME for Sbasic may now be 48 chars long Q68 setting date also sets it in the hardware clock, if PROT_DATE allows it Q68 better serport handling Q68 allows for configuurable home/end keys SMSQmulator can handle serial ports (experimental feature) CKEYON/CKEYOFF could malfunction under some circumstances SER_FLOW no longer gives error every time it is used Recent thing bugs corrected This can get downloaded from wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List
