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
Re: [Ql-Users] Theme file format
> Theme file format > I had a look at Theme file format on QL forum. Some > comments and questions: > > Rethorical question: Is it worthwhile to create a new > format to save some space (a few bytes, I suppose) > when we have (QPC2, SMSQmulator) 128MB at our disposal? Despite computers getting ever faster and bigger, the likes of Windoze still seem slow at times, and just as soon run out of space - as they always did.. That may partly be down to BLOAT and lazyness. In the case of the "QL", software might be expected to run on a wide variety of platforms, some fast and big, some slow and tight. IMHO, efficiency is rarely a bad thing unless achieving it is considerably more costly that what it is likely to save. I dont know where the current theme file format originated, but a few programs use that. It is sometimes (usually?) given the extension _thm. It is a pure text file that looks like this: $200 $FFC0 .. etc altogether 57 lines To load a palette (theme) youd use something like: .. FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2 INPUT#ch; it$ POKE_W addr + ofs, HEX(it$(2 to)) Whats not to improve? ;) I propose to use a binary format (see below) and use LBYTES instead. This cuts space and time, and would allow a number of such files to be concatenated. But instead of LBYTESing any kind of rubbish, I suggested we make a header that would give a strong indication, if not absolute certainty, that we were loading the right kind of file. A number of file formats on the QL scene dont have headers, and this sometimes causes confusion not to mention frustration and the potential for inelegant crashes unless preventive steps are taken by each and every program using them. The _scn extension, for example means widely different things.. > Not all palette files have 57 entries. Well, thats the current tally, as given by the Wman2 function SP_GETCOUNT. If that were to change, a file header might help to identify that fact quickly. > In fact, a complete palette should have 58 entries. > The original author forgot to reserve a slot for the > border of the error window. Doesn’t a new format imply > a rewrite of existing programs? No. > Will Qspread, QD, Files,... comply? I dont think any of them load external palettes. If they do, they will no doubt happily continue to use whatever standard theyre using now. > Afraid of having 57 entries filled with wrong data? Not afraid, as loading the wrong data will not crash the program, only display strange colours. POKEing or LBYTESing more data than ALCHPed would be seriously problematic. > Why not create a new type of file? I would suggest type > 84 (T for theme). File types are sadly not much supported in QL land. Defining a new file type could cause problems - for existing file managment programs, for example. > Just my two cents. Glad for your interest so this matter can be finalised. The current suggestion is for theme files to have an additional format to the existing one. It will be dead easy to convert theme files between "standards", so programmers can choose to support the new standard (if it becomes one) - or not. The reason Im bringing this up is to try to prevent a third and a fourth "standard" to emerge (unnecessary creating confusion and nonsense), by engaging anyone who has an opinion to "speak now or be forever silent" (as they say at the wedding ceremony in the C of E.) As mentioned, the file will be binary, but I describe it here in assembler for clarity: header dc.b "THM",57 data dc.w $200 dc.w $FFC0 etc.. Other suggestions have been made. This is V3.0, currently my preferred option, but Im open to improvements, including a header-less binary, considered earlier on. Per On 13 November 2017 at 15:50, François Van Emelen via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Hi, > > Theme file format > I had a look at Theme file format on QL forum. > Some comments and questions: > > Rethorical question: Is it worthwhile to create a new format to save some > space (a few bytes, I suppose) when we have (QPC2, SMSQmulator) 128MB at > our disposal? > Not all palette files have 57 entries. > In fact, a complete palette should have 58 entries. The original author > forgot to reserve a slot for the border of the error window. > Doesn’t a new format imply a rewrite of existing programs? > Will Qspread, QD, Files,... comply? > Afraid of having 57 entries filled with wrong data? Why not create a new > type of file? I would suggest type 84 (T for theme). > Just my two cents. > > Have a nice day. > > François Van Emelen > > > > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Hi Peter, the version of menuconfig I have is 3.36 and is dated 2003. I have configured both the keyboard and message language from English to German - still boots OK. And then the same from german to french and it boots normally and finally French back to English and it boots OK. The version of menuconfig on Dilwyn's site is 3.34 Cheers Duncan On Mon, Nov 13, 2017 at 10:21 AM, pgraf--- via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Hi Duncan, > > thanks for trying. > > > SMSQ/E 3.31 boots OK on my Q60. Just MenuConfiged keyboard language from > > english to german and still boots OK. Sorry can't reproduce the problem. > > Did you only change the keyboard, or also general language? > > Would be great if you can tell something about your MENUCONFIG > version also. My version from Dilwyn Jones' site at > > http://www.dilwyn.me.uk/config/index.html > > seems from 1999. Not sure that is up to date. > > Peter > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
[Ql-Users] Theme file format
Hi, Theme file format I had a look at Theme file format on QL forum. Some comments and questions: Rethorical question: Is it worthwhile to create a new format to save some space (a few bytes, I suppose) when we have (QPC2, SMSQmulator) 128MB at our disposal? Not all palette files have 57 entries. In fact, a complete palette should have 58 entries. The original author forgot to reserve a slot for the border of the error window. Doesn’t a new format imply a rewrite of existing programs? Will Qspread, QD, Files,... comply? Afraid of having 57 entries filled with wrong data? Why not create a new type of file? I would suggest type 84 (T for theme). Just my two cents. Have a nice day. François Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] Strange channel bugs?
Op Sun, 12 Nov 2017 18:11:57 +0100 schreef Per Witte via Ql-Users : Is this the sort of issue you mean? 100 CLS 110 FOR i = 0 TO 4 120 FOR j = 0 TO 4 130 AT i * 2, j * 6: PRINT i; ','; j; 140 END FOR 150 END FOR 160 : 170 PRINT 180 PAUSE RUNs fine under SMSQ/E, displays only the first line if compiled as a Qlib job (but no errors or warnings are given - either at compile time or when executing). Turbo, even under SMSQ/E, kicks up a fuss at parse time, and if you load it in SuperBASIC under Qdos or Minerva lines 140 and 150 show up as MISTake's. So its normally a good idea to try out problematic code in different environments. It doesnt necessarily have to work 100% before certain mistakes reveal themselves. That's exactly what I mean. Once fixed the compiler bug was gone and the compiled program did no longer freeze and produced it's windows. The call to my procedure with the END FOR line was even REM'd out but still QLIB got in trouble and messed up the _obj and SMSQE. On 12 November 2017 at 13:54, Bob Spelten via Ql-Users < ql-users@lists.q-v-d.com> wrote: Op Tue, 12 Sep 2017 18:47:35 +0200 schreef Bob Spelten : What's happening? I have successfully compiled a new version of my program. That's to say, there were no errors reported by BasicLinker or Qlibeator. But when the _obj is executed nothing seems to happen, no menu to act on. It's there in the JOBS list but no channels were opened for it. When I then kill this job it has the effect that the QD with the programs _bas can no longer produce lists of my Procs and FNs from the C-F6 to C-F8 buttons or keys. (...) It's been 2 month since I reported this problem. After many attempts to locate the problem Wolfgang Lenerz finally found the culprit. It was one missing index variable on an END FOR line. "Unnamed NEXT, EXIT and END statements" is a feature of SMSQ/E. Normally I am no fan of this as it can make the program more difficult to read, especially when start and end of the loop are far apart. This one (actually two) had escaped my proof reading. Now it turned out Q_Liberator also cannot deal with it and can, as was the case here, corrupt SMSQ/E in a sneaky way without a Sysmon alarm. So be warned, don't use this "feature" with Qlib! Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/"; ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Hi Duncan, thanks for trying. > SMSQ/E 3.31 boots OK on my Q60. Just MenuConfiged keyboard language from > english to german and still boots OK. Sorry can't reproduce the problem. Did you only change the keyboard, or also general language? Would be great if you can tell something about your MENUCONFIG version also. My version from Dilwyn Jones' site at http://www.dilwyn.me.uk/config/index.html seems from 1999. Not sure that is up to date. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure
Hi, SMSQ/E 3.31 boots OK on my Q60. Just MenuConfiged keyboard language from english to german and still boots OK. Sorry can't reproduce the problem. Duncan On Sun, Nov 12, 2017 at 12:19 PM, Peter Graf via Ql-Users < ql-users@lists.q-v-d.com> wrote: > 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 > ___ QL-Users Mailing List