[Ql-Users] Small but in SMSQ/E Reference Manual

[Tobias Fröschle via Ql-Users]

(This is mainly to Wolfgang, but might help others as well who are confused as 
me)

The QDOS_SMS_Reference guide v4.7 has a small bug on section 22.5 (the entry 
for SETD, setting the HOME directory of a job):

The table says „A2: Pointer to parameter list“, while it should actually be A1, 
and A2 wants the Thing linkage. The parameter list example below has it 
correctly.
___
QL-Users Mailing List

Re: [Ql-Users] SMSQE instr_case QLIB

[Tobias Fröschle via Ql-Users]

> 
> The main reason, I believe, is that INSTR_CASE is a global setting and so 
> shouldnt be set by a program, but only by the user in the main console


That's actually not the problem: INSTR_CASE seems to work "local" to each 
instance of the SBASIC interpreter (I just checked).

Turbo happily compiles programs that contain INSTR_CASE statements,  but does 
seem to be using its own INSTR implementation (that will, obviously, not switch 
according to INSTR_CASE). So, compiled programs simply don't react on the 
INSTR_CASE settings. QLiberator does exactly the same.


___
QL-Users Mailing List

Re: [Ql-Users] QTImage 1.5

[Tobias Fröschle via Ql-Users]

François, 

the mailing list doesn't forward attachments - You need to put them somewhere 
else for us to see or describe textually.

Cheers,
Tobias

> Am 09.12.2021 um 17:04 schrieb François Van Emelen via Ql-Users 
> :
> 
> Op 9/12/2021 om 16:03 schreef Giorgio Garabello via Ql-Users:
>> Il giorno gio 9 dic 2021 alle ore 15:49 François Van Emelen via Ql-Users <
>> ql-users@lists.q-v-d.com> ha scritto:
>> 
>>> Op 8/12/2021 om 17:50 schreef Giorgio Garabello via Ql-Users:
> 
> 
> 
> About the problems running Qtimage from Ramx_. Just a thought, Why don’t
> you use the HOME-thing, that would make the program more versatile, I
> think,
> 
 I regularly use THINGS FOR THE HOUSE
 That's not the problem.
 
> I have merged 3 pic-files (2 large & 1 small) without a problem, It took
> minutes,,, but it worked.
> 
 Unfortunately we are pushing the QPC2 limit.
 Let's not forget that it emulates a 68020
 
>>> This wasn't a negative comment; I only meant that QTimage could do it.
> Tests
> 
> 
> Image
> 
> Zoom OK
> 
> Resize OK
> 
> Border OK
> 
> 
> Colours
> 
> 
> This is another kettle of fish,
> 
>>> This is another kettle of fish means 'much more difficult, more
>>> complicated'
>>> 
 I'm not sure I understand this part. I translated it with google
>>> translate
 but I didn't understand exactly what you mean (in that menu)
 My fault, unfortunately my English sucks
 
 
> To avoid a new menu popping up, you ought to replace all occurences of
> scale
> 
> -256 to +256 with -255 to +255 and keep the loose item ‘ok’ unavailable
> until the correct values are entered,
> 
> Entering wrong values are sometimes corrected by the program but not
> always. Wrong values allow the popup of a new menu ( see Filter →Pixel).
> But this behaviour seems unpredictable here, at least to me. So make it
> impossible to use values that are out of range .
> 
> Make it impossible to enter wrong values for all the other colour items.
> 
>>> I think I have found the problem: not that difficult after all.
>>> 
>>> Try this:
>>> 
>>> 1. load an image
>>> 
>>> 2. choose Colours
>>> 
>>> 3. choose Brightness
>>> 
>>> 4. put the mouse pointer over the editable loose item
>>> 
>>> 5. Press the right button of the mouse
>>> 
>>> 6. a new menu will pop up.
>>> 
>>> See attachment
>>> 
>> 
>>   Up to here, everything ok .. then? which attach? I do not understand..
>> 
>> 
>> 
>>> So, make sure the user can't leave the Brightness  with a   DO on an
>>> editable loose item.
>>> 
>>> This behaviour is the same for all Colours items.
>>> 
>>> There is another problem with Export/Save with name: you should add a
>>> '_' or a '.' before the extension, else the file will be saved without a
>>> valid extension.
>>> 
>> Yes this is easy
>> Thanks for your help
>> 
>> Giorgio
>> ___
>> QL-Users Mailing List
> 
> Sorry, I forgot the attachment
> 
> So, If press the right button of the mouse  without editing the loose item, 
> you will get a new menu that has nothing to do with Brightness. see 
> QTimge.jpg and Qtimge2.jpg
> 
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Select on

[Tobias Fröschle via Ql-Users]

That's probably the best solution for the problem - String$ SELECT has always 
been a half-baked solution in SuperBASIC.

Tobias

> Am 21.06.2020 um 13:38 schrieb Bob Spelten via Ql-Users 
> :
> 
> Op Sun, 21 Jun 2020 09:46:23 +0200 schreef Norman Dunbar via Ql-Users 
> :
> 
>> I have a vague recollection that Simon N Goodwin did something similar, 
>> maybe, in the DIY Toolkit.
>> 
>> I think it was passed a variable and a list of strings, and returned the 
>> position of the variable in the list. Something like that.
>> 
>> Maybe useful?
>> 
> That would then be the PICK$ function.
> It's on DIY disk 1, sub E, found on Dilwyn's site, where else?
> 
> Bob
> 
> -- 
> The BSJR QL software site at: "http://home.hccnet.nl/b.spelten/ql/;
> 
> -- 
> Deze e-mail is gecontroleerd op virussen door AVG.
> http://www.avg.com
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)

[Tobias Fröschle via Ql-Users]

Well, you can bring up the OS from ROM without working mass storage. That's 
definitely an advantage, especially for the early days, when we didn't have 
fast storage (i.e. floppy only).

Compared to the Atari, that's ROM-TOS vs. Disk-TOS (but not running from ROM)

Tobias

> Am 12.05.2020 um 19:12 schrieb Ralf Reköndt via Ql-Users 
> :
> 
> A simple bootstrap loader would do the trick, right? Why a complete SMSQ/E in 
> EPROM? As far as I remind, TT has written such one, having it it one of my TT 
> disks (for Atari).
> 
> Am 12.05.2020 um 18:28 schrieb Peter Graf via Ql-Users:
>> 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
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QL User grapic competition from 1985: Tree

[Tobias Fröschle via Ql-Users]

Rich Mellor should know the guy. A Andy Pritchard is named as the author of his 
"Spy" adventure game first published in 2016.

Tobias

> Am 16.04.2020 um 13:36 schrieb Dilwyn (gmail) via Ql-Users 
> :
> 
> I wonder if this could be the same Andrew Pritchard who wrote some QL 
> software such as QL Conquest, Reversi, SAM, SWIPE, ADVgen, Playwright and 
> Scriptwriter for CGH Services back in the 1980s? I'm afraid I don't have 
> contact details or know if he can be reached.
> 
> Some of his software is on my Games page and other pages on my site (use the 
> site search box on home page to find them by searching for "Pritchard").
> 
> DIlwyn
> 
> -Original Message- From: Michael Berger via Ql-Users
> Sent: Thursday, April 16, 2020 11:39 AM
> To: ql-us...@q-v-d.com
> Cc: Michael Berger
> Subject: [Ql-Users] QL User grapic competition from 1985: Tree
> 
> Dear all,
> 
> 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.
> 
> Does anyone here by chance know if A. Pritchard still can be reached?
> The reason I am asking: when I recently told a colleague from UK about
> this, it turned out he knew a person named A. Pritchard in the early
> 1980's, who was a fanatic of the ZX Spectrum at the time.
> 
> This is the (somewhat expanded for better readability) code:
> 
> 100 REMark *** QL USER 1985 ***
> 110 REMark *** Tree by A. Pritchard ***
> 120 PAPER 5:PAPER#2,5:WINDOW 512,256,0,0
> 125 WINDOW#2,512,256,0,0:MODE 8
> 130 INK 7:FILL 1:CIRCLE 80,60,10:FILL 0:INK#2,0
> 140 FOR i=1 TO 10:CIRCLE 80,2,i,.1,PI/2:NEXT i
> 150 FOR h=25 TO 12 STEP -1:d:NEXT h:INK 0:FILL 1
> 160 LINE 0,-3 TO 28,40 TO 36,40:ARC TO 50,-3,PI/2
> 170 FILL 0:tr 28,40,20,8:INK 3:AT 0,5:OVER 1
> 180 CSIZE 3,1:PRINT '"Shivering in the Wind"';
> 190 CSIZE 2,0:PRINT "AP85";
> 195 :
> 200 DEFine PROCedure tr(x,y,l,b)
> 205 LOCal i,f,g,b1
> 210 IF l<2 THEN RETurn
> 220 FOR i=1 TO 4
> 230 b1=b/2:IF b/2 >1 THEN FILL 1
> 240 f=x+(i*l-1.2*l-RND(1))*1.2:g=y+RND(l*2.3)-1/3
> 250 k=0:IF i=4 AND l=20 THEN k=3
> 260 LINE x,y TO f,g TO f+b1-1,g
> 270 LINE TO x+b-1,y-k TO x,y
> 280 FILL 0:tr f,g,l/2,b/2:NEXT i
> 285 END DEFine
> 287 :
> 290 DEFine PROCedure d
> 295 p=RND(150)-30:g=RND(160)
> 300 INK 3:FILL 1:LINE p,10 TO (p+g)/2,h TO g,10
> 310 FILL 0:INK 7:LINE (p+g)/2,h TO g,10:INK 3,5
> 320 FILL 1:LINE p,10 TO (p+g)/2,10-(h-10)/3 TO g,10
> 330 FILL 0
> 340 END DEFine
> 
> Thanks and best regards,
> 
> Michael
> 
> 
> ___
> QL-Users Mailing List
> 
> -- 
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.35

[Tobias Fröschle via Ql-Users]

Wolfgang,

that sounds like a corrupt file system on the web server. Have the hosing guys 
look after that - It's probably not the only glitch that you will see.

Tobias

> Am 09.02.2020 um 06:48 schrieb Wolfgang Lenerz via Ql-Users 
> :
> 
> 
> Hi,
> 
> >
> > Something's wrong, I'm afraid.
> >
> 
> yes it definitely is.
> 
> My local copy unzips OK.
> 
> I downloaded the file from my site, and indeed, no way you can unzip it, the 
> file has a length that doesn't even correspond to the real length of the file 
> (the real length, in bytes, is actually shown on the webpage). OK, I thought, 
> some file corruption happened during uploaded.. I re-upped the file. The 
> length of the file on the webpage was correct (the length is displayed via a 
> small php script, so it takes the length of the file as it actually is on the 
> site). Just to be sure, I downloaded the file again. And again, no way to 
> unzip it as again it's not a valid zip file.
> After some more re-up- and re-downloads, where I had the same problem, I 
> tried various other things. The result is that I renamed the file (on the 
> site, not locally!) to smsqe335b.zip (and edited the html page to point to 
> that). Now it works - but the file is called smsqe335b.zip - I think one can 
> live with that.
> 
> Isn't computing wonderful?
> 
> (Oh, and just to be sure that I wasn't dreaming, I then renamed the file to 
> smsqe335.zip again -and edited the html file-, re-downloaded - not a valid 
> zip file. Go figure).
> 
> Wolfgang
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Test email

[Tobias Fröschle via Ql-Users]

Done.

> Am 20.01.2020 um 22:02 schrieb Dilwyn (gmail) via Ql-Users 
> :
> . Ignore!

___
QL-Users Mailing List

Re: [Ql-Users] The Pawn adventure with graphics on the Q68

[Tobias Fröschle via Ql-Users]

In case you missed it:

The Magnetic Scrolls Adventurs are now available for _all_ QL platforms - See 
the QL Forum at https://qlforum.co.uk/viewtopic.php?f=3=3069 


The QL has received special graphics routines incorporating Markus's proposal 
(interlacing both screen pages). 

Tobias

> Am 19.11.2019 um 08:04 schrieb Wolfgang Lenerz via Ql-Users 
> :
> 
> Hi,
> 
> good news. I remember the Pawn being pretty difficult!
> 
> Wolfgang
> 
> 
> 
>> 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
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] The Pawn adventure with graphics on the Q68

[Tobias Fröschle via Ql-Users]

Markus,

Well, /technically/ yes (even if it would be quite a bit of work to make this 
proof-of-concept into a piece of distributable software for anyone, especially 
given the strong QL hardware speed dependency of dithvide).

It would, however, imply conversion and very probably also distribution of the 
converted original game/graphics files.

Due to the unclear legal situation of the original games, I have decided not to 
distribute them or any modified version thereof. They are freely downloadable 
from the internet, however, (which is apparently tolerated by the owners - link 
and statement provided). That means the software needs to make do with these 
unmodified pictures.

Tobias

> Am 17.11.2019 um 11:48 schrieb desin via Ql-Users :
> 
> Am 17.11.19 um 11:36 schrieb Peter Graf via Ql-Users:
>> 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
> 
> Hello
> 
> would this be a option ?
> 
> https://omega.webnode.com/products/sinclair-ql-dithvide-2/
> 
> 
> Greetings from Switzerland
> 
>   Markus
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Proposal about the file system

[Tobias Fröschle via Ql-Users]

Giorgio,

nothing dangerous here. DEC VMS, for example, does it in exactly in the same 
way.

The danger you seem to see (application sets a backup date, other app uses 
something different) is circumvented by supplying an old "full" backup to any 
incremental one for the programs to compare. In case you have none, the backup 
program will automatically do a full backup and initialise the time stamps.

Dangerous is when you use the backup timestamp for something else

Tobias

> Am 10.10.2018 um 00:38 schrieb Giorgio Garabello via Ql-Users 
> :
> 
> 2018-10-09 17:26 GMT+02:00, Jan Bredenbeek via Ql-Users
> :
>> On 9 October 2018 at 16:44, Giorgio Garabello via Ql-Users <
>> ql-users@lists.q-v-d.com> wrote:
>> 
>>> In the header file we have the backup date field from what is not used.
>>> Can not be used to insert us from file creation date?
>>> 
>> 
>> Wouldn't this break any backup software?
>> I've written HARDBAK back in 1989 which uses this backup date to determine
>> if files have changed since the backup.
> :-O
> May I ask you why did you choose such a dangerous option?
> 
>> And what do you mean with 'file creation date', the date when the file was
>> created on the medium or when it was last updated?
> 
> when the file was created
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] File header info

[Tobias Fröschle via Ql-Users]

Giorgio,

File access key: Don't know of any software that uses this.

For "data space" you didn't read far enough: It"s in the next sentence:

"In the case of file type 1, the first longword of type-dependent information 
holds the default size of the data space for the program." - The data space, if 
applicable, is in a long word at $6. "File type dependent info" is not used for 
anything but the data space, to my knowledge (even if it could, for 
non-executable programs).

"backup date" can be used by backup programs to store the date and time of the 
last backup. It is not used by the system.

"reserved" is, well, reserved, and not used for anything.

Tobias


> Am 28.09.2018 um 00:27 schrieb Giorgio Garabello via Ql-Users 
> :
> 
> On QDOS/SMSQ reference manual (Section 7) I've fond the following
> informations:
> 
> Each file is assumed to have a 64-byte header (the logical beginning of
> file is set to byte 64, not byte zero).
> This header should be formatted as follows:
> 
> $00 long file length
> $04 byte file access key (used by third parties software)
> $05 byte file type
> $06 8 bytes file type-dependent information
> $0E 2+36 bytes file name
> $34 long update date [EXT,DD2]
> $38 word version number [DD2]
> $3A word reserved
> $3C long backup date [DD2]
> 
> File access key  what is that?
> File type   dependant info  ..as above
> word reserved..for what?
> Backup date?
> 
> other question...where is the dataspace? maybe the "File type   dependant
> info"?
> 
> thanks in advance
> 
> Giorgio
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD order page

[Tobias Fröschle via Ql-Users]

And some more shameless advertising, because I forgot and the product is worth 
it:

That combination works flawlessly with GC SMSQ/E.

Tobias

> Am 31.08.2018 um 21:52 schrieb Tobias Fröschle via Ql-Users 
> :
> 
> Just a short note on my experiences with some (old) QL-SDs that were updated 
> with Marcel's PLD and new drivers plus a dual-slot card that I have been 
> using for some time now:
> 
> While the original PLD/Driver combination has always been a bit, say, 
> capricious, after the upgrade everything has been working just flawlessly. 
> QLSD is entirely transparent and just works now, I have never had the 
> slightest issue with it, and the possibility to exchange QLWA images with 
> QPC2 and Q68 is really a joy to use. The card change detection makes usage 
> much simpler, you can change SD cards like floppy disks now.
> 
> I have been using this setup now for a while in a SuperGold Card and a Gold 
> Card QL, and both work absolutely flawlessly. Be aware, however, that the 
> double-drive SD card holder fills the available space in the microdrive slot 
> completely - It needs a bit of patient fiddling to get the case to fit 
> properly around it, especially in my Samsung-made QLs that have SuperHermes 
> fitted - Here space is really tight, but with a bit of patient persuasion 
> everything fits nicely.
> 
> All in all, an absolute recommendation. I have been using my QLs much more 
> frequently during the last weeks, as they are pure joy to use now.
> 
> Thanks Marcel and Wolfgang!
> Tobias
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD order page

[Tobias Fröschle via Ql-Users]

Just a short note on my experiences with some (old) QL-SDs that were updated 
with Marcel's PLD and new drivers plus a dual-slot card that I have been using 
for some time now:

While the original PLD/Driver combination has always been a bit, say, 
capricious, after the upgrade everything has been working just flawlessly. QLSD 
is entirely transparent and just works now, I have never had the slightest 
issue with it, and the possibility to exchange QLWA images with QPC2 and Q68 is 
really a joy to use. The card change detection makes usage much simpler, you 
can change SD cards like floppy disks now.

I have been using this setup now for a while in a SuperGold Card and a Gold 
Card QL, and both work absolutely flawlessly. Be aware, however, that the 
double-drive SD card holder fills the available space in the microdrive slot 
completely - It needs a bit of patient fiddling to get the case to fit properly 
around it, especially in my Samsung-made QLs that have SuperHermes fitted - 
Here space is really tight, but with a bit of patient persuasion everything 
fits nicely.

All in all, an absolute recommendation. I have been using my QLs much more 
frequently during the last weeks, as they are pure joy to use now.

Thanks Marcel and Wolfgang!
Tobias

___
QL-Users Mailing List

Re: [Ql-Users] Qptr manual 6.04

[Tobias Fröschle via Ql-Users]

Wolfgang,

thanks for keeping these documents up-to-date.

Thanks especially for this sentence in the QPTR manual (that made it in a 
couple of releases ago)

>Note also that most device drivers, when requested to open a directory will, 
>if no such directory exists, open the next >existing higher level directory. 
>Most QL software expects this behaviour. 


which kind of was a revelation when I stumbled across it - That is, apparently, 
not documented anywhere else and gave an explanation why one of my drivers 
didn't work as expected with some programs.

Tobias


> Am 22.07.2018 um 11:47 schrieb Wolf via Ql-Users :
> 
> Hi all,
> 
> I updated the QPTR manual to version 6.04, some additional corrections and 
> information are now included.
> 
> wlenerz.com/qlstuff
> 
> Have fun!
> 
> 
> Wolfgang
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] FiFi

[Tobias Fröschle via Ql-Users]

Hi Wolfgang!

Great news, FiFi is one of the most useful things on a crammed hard drive. Now 
QMon is the last piece of commercial software I have that's not freely 
available.

Tobias

> Am 30.03.2018 um 06:48 schrieb Wolf via Ql-Users :
> 
> Hi all,
> 
> FiFi, my formerly commercial file finder can now be downloaded from my site.
> 
> www.wlenerz.com/qlstuff
> 
> Have fun!
> 
> Wolfgang
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] TK2 v2.32

[Tobias Fröschle via Ql-Users]

That is great! As one of the - apparently rare - QL-Net users a special thank 
you from the neighborhood.

Tobias

> Am 04.03.2018 um 16:59 schrieb Marcel Kilgus via Ql-Users 
> :
> 
> I have released a new (or actually two new) versions of TK2.
> 
> One versions only includes the timing critical parts of the QL-NET
> code and the rest can be LRESPRed afterwards.
> 
> The other versions included the complete QL-NET code and misses the
> "ED" SuperBasic editor instead, which can be LRESPRed afterwards.
> 
> Depending on your QL-NET affinity you can chose which version you like
> more, in the end both version have the same capabilities when the
> missing parts are loaded.
> 
> https://www.kilgus.net/2017/03/19/toolkit-ii-the-sequel/
> 
> Marcel
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Tobias Fröschle via Ql-Users]

> Am 16.02.2018 um 10:27 schrieb Jan Bredenbeek via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> On 15 February 2018 at 19:33, Tobias Fröschle via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
> 
>>> 1. Not called from an S*BASIC context: --> return with nothing done, d0
>> is what you put in, so not meant to report an error. Not really a valid use
>> case
>> 
>> This _is_ a valid use case for compiled programs - But here we should be
>> safe to assume that the compiler runtime environment has some space
>> reserved for us - We cannot expect QDOS/SMSQ/E to do that
> 
> 
> At least it could exit when an 'out of memory' situation occurs, rather
> than let the program continue assuming there's enough space where in fact
> there isn't.

Without some (valid or invalid) assumptions on how the compiler allocates space 
and where it stores the pointers, I'm afraid that would be a bit difficult. 
While I think it would be relatively safe to assume the compiler runtimes 
replicate the BV_RIP and BV_RIBAS variables that hold the current RI top and 
the base address of the RI stack. That pointers, however, could point to a 
dedicated heap block for the RI stack or just to somewhere in the compiled 
task's data space - trying to reallocate that would probably have varying 
results - Fiddling with a task's memory is apparently something that TT rather 
refrained from and said "I'd rather not care".

> 
> What puzzles me however is that, in case more space from the system is
> needed, this is done using a call to sms.achp (mt.alchp) rather than
> mt.albas. So the extra space seems to be allocated in the Common Heap
> rather than the S*BASIC area. Now I know that SMSQ/E has a memory
> allocation scheme that's different from good old QDOS in some respects, but
> I'm curious about the rationale behind this. When space for the RI stack
> (or any other S*BASIC area for that matter) is allocated from the Common
> Heap, there would be no problem extending this to compiled programs
> (assuming they won't expect their data to be somewhere in the TRNSP area).
> 

To my knowledge, QDOS knows TPA, CHP and SuperBASIC as memory areas - SMSQ/E 
has dropped the last one as it needs multiple of them and moved the "Program" 
part (As far as I can see, mostly pointers to expandable heap memory) into the 
TPA and the RI stack and all other areas that need to expand and shrink a lot 
to the common heap. But that's just a shoot into the dark.

The Turbo Manual mentiones some relatively strict limitations like
- Resident PROCs and FNs are not guaranteed to find more 100 bytes free on the 
Maths stack.
- BV.CHRIX cannot be relied upon to expand the RI stack as tasks have to run 
within fixed bounds

And it also supplies some code on how to check - This does, however, call 
BV.CHRIX - How this can expand the RI stack on SMSQ/E is beyond me, the job 
would need to disguise itself as SBASIC.

Tobias

___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Tobias Fröschle via Ql-Users]

Neet to reprase my below statement:



> Am 15.02.2018 um 16:26 schrieb Tobias.Froeschle--- via Ql-Users 
> :
> 
> Wolfgang,
> 
> (For some reason, I only seem to see half of the discussion, so bear with me 
> if I repeat something that was said already)
> 
> What I meant is that to me it looks like:
> 
> QA.RESPRI takes _one_ argument, and that is the amount of memory you want to 
> grow the RI stack by in D1. 
> 
> The other "needed" argument is the current top of the RI stack and that is 
> taken from BV_RIP(a6). In case your current value of a1 is different from 
> that (because your code might have fiddled with the stack), you are expected 
> to save a1 before the call to BV_RIP(a6).
> 
> As far as I can see, the vector has three possible exit points:
> 1. Not called from an S*BASIC context: --> return with nothing done, d0 is 
> what you put in, so not meant to report an error. Not really a valid use case

This _is_ a valid use case for compiled programs - But here we should be safe 
to assume that the compiler runtime environment has some space reserved for us 
- We cannot expect QDOS/SMSQ/E to do that

> 2. Space wanted is already there --> return with nothing done, d0 is what you 
> put in, so not meant to report an error
> 3. Space successfully allocated --> return with registers smashed as in docs, 
> new RI stack pointer in BV_RIP(a6)
> 
> There's a fourth exit that is taken on the "insufficient memory" case which 
> basically stops the program and enters the main interpreter loop - never 
> returns to the caller.
> 
> Wether a1 is preserved or not is relatively irrelevant for this call: If you 
> want to have a1 point at the RI stack, you are expected to reload a1 from 
> BV_RIP(a6) after the call anyways.
> 
> The expected use of the call to me seems to be like follows:
> 
> 1. If your local value of RI stack top (a1) is different from BV_RIP(a6), 
> store it there. If not, no need to care about a1
> 2. The vector will either return to you and you can assume the space is 
> there, or it will not return. Best ignore d0, it may have a non-meaningful 
> value
> 3. Re-load a1 from BV_RIP(a6) if you want to use it as RI stack pointer, 
> because the stack might have moved
> 
> 
> Tobias
> 
> 
> -Original-Nachricht-
> Betreff: Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
> Datum: 2018-02-15T14:46:20+0100
> Von: "Wolfgang Lenerz via Ql-Users" 
> An: "ql-us...@q-v-d.com" 
> 
> Hi,
> 
> (Tobias)
> 
>> Hmm. Are we sure about that?
> 
> Sorry I'm not sure I understand. Am I sure that, as I said, on SMSQ/E it 
> is not necessary to save the stack pointer in BV_RIP(A6) before calling 
> this vector. Yes, that seems quite clear to me from the code.
> 
>> When having a glance at the code, it looked to me as SMSQ/E would not 
>> use a1 at all, but rather use BV_RIP(a6) instead for the location of
>> the RI stack (just as QDOS does).
> 
> Ok, that doesn't invalidate what I said. I don't know about Qdos, though.
> 
> 
> (Per)
>> I think the whole thing bears further investigation, as there appears to 
>> be doubt about other aspects too. Jan Bredenbeek, for example, suggests 
>> that:
>> 
>> Call parameters Return parameters
>> ..
>> A1 A1 Preserved
>> 
> 
> True for SMSQE.
> 
>> He was going to investigate the various OS sources, and perhaps is still 
>> busy doing so.. Jan..?
>> 
>> What there seems to be general agreement on,  contrary to current 
>> documentation,  is that 1) what is in A1 is irrelevant to this call, and 
>> 2) that the routine doesnt return on the only possible error: IMEM.
> 
> Errm, yes and no.
> 
> One of the relevant parts of the code is:
> 
> sbr_dn
> cmp.l   #sb.flag,sb_flag(a6) ; SBASIC?
> bne.s   sbr_nop
> sub.l   0(a6,d2.l),d1; -(pointer - required)
> add.l   sb.loffp(a6,d2.l),d1 ; lower limit -(pointer - 
> required)
> bgt.s   sbr_alldn
> rts
> 
> ...
> sbr_nop
>   rts
> 
> What happens when using this from a compiled program? The BNE.S will be 
> taken, so the conditions codes will be not zero. The value in D0 will be 
> ... what '(whatever was in it when the vector as called)
> 
> Likewise, even in Basic, if there IS enough space, you'll take the rts, 
> with N set and D0 whatever it was when the vector was called...
> 
> How is handled in Qdos? I don't have a disassembly right now.
> 
>> Minerva, apparently, returns D0 = 0 on a successful return 
> 
> so does SMSQ.
> 
> 
>> 
>> Update:
>> After sribbling down the example above, I decided to "weaponise" it to 
>> test the following three premises:
>> 1) Is A1 preserved?: JS, Minerva and SMSQ/E all appear to do so
> 
> Thanks for testing these.
> 
> How big was the amount of memory requested? Big enough that a shift 
> would occur?
> 
> 
> Wolfgang
> ___
> QL-Users 

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Tobias Fröschle via Ql-Users]

Hmm. Are we sure about that?

When having a glance at the code, it looked to me as SMSQ/E would not use a1 at 
all, but rather use BV_RIP(a6) instead for the location of the RI stack (just 
as QDOS does).

Tobias


> Am 15.02.2018 um 05:08 schrieb Wolf via Ql-Users :
> 
> Hi,
> 
> thanks, Per, for pointing out the inconsistencies in the entry conditions in 
> vector QA.RESRI.
> 
> I'll make a note in the next version of the "QDOS SMS Reference guide" (ex 
> Technical Manual and ex QDOS SMS reference manual) that on SMSQ/E it is not 
> necessary to save the stack pointer in BV_RIP(A6) before calling this vector. 
> However, I'm going to leave the general requirement in, since I don't know 
> how this is handled in QDOS (AH, JM, JS etc), or in Minerva.
> 
> 
> Wolfgang
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD new driver

[Tobias Fröschle via Ql-Users]

Marcel,

that Schmidt-trigger is already there. Nice little SMD bug under the socket 
that sits in the ROMOEH line. Apparently, it doesn't help.

I have mixed experiences with GoldCards - One doesn't work at all, the other 
one (at least in one specific QL) rather well for days together with a QL-SD. 
But not well enough to go through the nuisance of destroyed file system every 
other week or so.

Tobias

> Am 22.01.2018 um 15:07 schrieb Marcel Kilgus via Ql-Users 
> :
> 
> pgraf--- via Ql-Users wrote:
>> Remark: This new driver can not be expected to resolve the signal
>> quality issue between (Super)GoldCard and QL-SD. This remains a 
>> hardware problem.
> 
> One beta release ALMOST worked with my Gold Card, it could read a
> directory half-way before outputting garbage.
> 
> As I've understood your chip is 3.3V and the lines (or GND) is too
> noisy so that logic level 0 could be interpreted as 1 before the lines
> settle, because the chip samples them faster as older chips would, is
> that about right? Would it help to put a 74-style Schmitt-trigger in
> front of ROMOEH or something like that?
> 
> Marcel
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Ql-Users Digest, Vol 167, Issue 2

[Tobias Fröschle via Ql-Users]

Jan,
with an FB-machine, you would probably have had much harder 30+ QL-years than 
you actually had ;)

Tobias

> Am 06.01.2018 um 12:06 schrieb Jan Bredenbeek via Ql-Users 
> :
> 
> On 5 January 2018 at 22:33, Dave Park via Ql-Users > wrote:
> 
>> I did have an FB dongle around here once upon a time, but I haven't seen it
>> in five years.
>> 
> 
> I once got my hands on an FB machine somewhere in autumn 1984. A local
> computer store had imported it from the UK (probably not officially). It
> didn't take long before the 'bad or changed medium' message popped up on
> loading Quill. So I decided to wait a little longer before buying a QL.
> Of course, with today's hindsight (and money!) I would have bought it...
> 
> Jan.
> 
> -- 
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Ql-Users Digest, Vol 167, Issue 2

[Tobias Fröschle via Ql-Users]

Yes, apparently it did:

TY - How creative ;)

Tobias

> Am 05.01.2018 um 16:33 schrieb Dave Park via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> Did the Tyche ROM ever get letters?
> 
> On Fri, Jan 5, 2018 at 8:49 AM, Tobias Fröschle via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> AF = Awfully faulty
>> JM = jerkily mended
>> JS = just stable
>> MG = mainly good
>> 
>> ;) (just joking)
>> 
>> Tobias
>> 
>>> Am 05.01.2018 um 12:56 schrieb Norman Dunbar via Ql-Users <
>> ql-users@lists.q-v-d.com>:
>>> 
>>> Hi Paolo,
>>> 
>>> as far as I remember, the code letters for the various QL ROMs have been
>> named after:
>>> 
>>> * Taxi Drivers used by Sinclair staff;
>>> * Engineers at Sinclair;
>>> * Women in the Sinclair offices.
>>> 
>>> There may bo other "uses", but the letters in JM and JS etc are the
>> initials of certain people from the above list. I have not seen a full list
>> of the various names actually used though, so I can't tell you who JM and
>> JS were. Sorry.
>>> 
>>> 
>>> HTH
>>> 
>>> Cheers,
>>> Norm.
>>> 
>>> On 04/01/18 18:30, Paolo Del Bene via Ql-Users wrote:
>>>> Today's Topics:
>>>>   1. Re: about JM and JS roms
>>>>(Paolo Del Bene)
>>>>34 years are passed, and I haven't
>>>>anymore a QL Sinclair from 27
>>>>years when my father before bought
>>>>it for me and then he sold without to
>>>>say nothing to me.
>>>>I am here only to ask for what stand
>>>>the name JM and JS in the roms.
>>>>I haven't found any information
>>>>   about, if you can help me I'll be
>>>>happy
>>>>Happy GNU Year 2018
>>>>Paolo Del Bene iw0fzw
>>> 
>>> 
>>> 
>>> --
>>> Norman Dunbar
>>> Dunbar IT Consultants Ltd
>>> 
>>> Registered address:
>>> 27a Lidget Hill
>>> Pudsey
>>> West Yorkshire
>>> United Kingdom
>>> LS28 7LG
>>> 
>>> Company Number: 05132767
>>> ___
>>> QL-Users Mailing List
>> 
>> ___
>> QL-Users Mailing List
>> 
> 
> 
> 
> -- 
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Ql-Users Digest, Vol 167, Issue 2

[Tobias Fröschle via Ql-Users]

AF = Awfully faulty
JM = jerkily mended 
JS = just stable
MG = mainly good

;) (just joking)

Tobias

> Am 05.01.2018 um 12:56 schrieb Norman Dunbar via Ql-Users 
> :
> 
> Hi Paolo,
> 
> as far as I remember, the code letters for the various QL ROMs have been 
> named after:
> 
> * Taxi Drivers used by Sinclair staff;
> * Engineers at Sinclair;
> * Women in the Sinclair offices.
> 
> There may bo other "uses", but the letters in JM and JS etc are the initials 
> of certain people from the above list. I have not seen a full list of the 
> various names actually used though, so I can't tell you who JM and JS were. 
> Sorry.
> 
> 
> HTH
> 
> Cheers,
> Norm.
> 
> On 04/01/18 18:30, Paolo Del Bene via Ql-Users wrote:
>> Today's Topics:
>>1. Re: about JM and JS roms
>> (Paolo Del Bene)
>> 34 years are passed, and I haven't
>> anymore a QL Sinclair from 27
>> years when my father before bought
>> it for me and then he sold without to
>> say nothing to me.
>> I am here only to ask for what stand
>> the name JM and JS in the roms.
>> I haven't found any information
>>about, if you can help me I'll be
>> happy
>> Happy GNU Year 2018
>> Paolo Del Bene iw0fzw
> 
> 
> 
> -- 
> Norman Dunbar
> Dunbar IT Consultants Ltd
> 
> Registered address:
> 27a Lidget Hill
> Pudsey
> West Yorkshire
> United Kingdom
> LS28 7LG
> 
> Company Number: 05132767
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Merry Christmas with SMSQ/E

[Tobias Fröschle via Ql-Users]

Doesn't crash here

but ends up in QMon signalling an Address error ;)

Tobias

> Am 27.12.2017 um 17:20 schrieb François Van Emelen via Ql-Users 
> :
> 
> Op 26/12/2017 om 18:31 schreef pjwitte via Ql-Users:
>> If you want a really miserable Christmas, you could try the following - 
>> without saving your work first:
>> 
>> 1 x% = 32000
>> 2 y% = x%
>> 3 z% = 1600
>> 4 t  = x% * y% * z%: REMark Kabm!!!
>> 5 PRINT "-- Im dead!"
>> 
>> The above crashes SMSQ/E 3.32 on QPC2 and SMSQmulator! Even the four-finger 
>> reset wont work. The following is, as youd expect, fine:
>> 
>> 1 x% = 32000
>> 2 y% = x%
>> 3 z% = 1600
>> 4 t  = x% * y%
>> 5 t  = t * z%
>> 6 PRINT "Yippi! - Im still alive!"
>> 
>> Per
>> ___
>> QL-Users Mailing List
> 
> Hi,
> 
> Same here.
> 
> 1) QPC2: screen fills with light brown colour up to bottom half of the screen 
> then QPC2 locks
> 
> 2) SMSQMumator:  locks immediately.
> 
> François Van Emelen
> 
> 
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] SMSQE 3.32

[Tobias Fröschle via Ql-Users]

That’s really great. Eager to try an IDE-to-SD Adapter and see how direct data 
exchange will work.

Tobias

This mail was sent from my mobile. Any typos are entirely its fault.

> Am 10.12.2017 um 15:37 schrieb duncan . via Ql-Users 
> :
> 
> Hi Wolfgang,
> 
> Fantastic news for Qx0 users, many thanks.
> 
> Duncan
> 
> On Sun, Dec 10, 2017 at 2:04 PM, Wolf via Ql-Users > wrote:
> 
>> Hi all,
>> 
>> SMSQE 3.32 is out now.
>> 
>> Below is a swmall account of what has changed.
>> 
>> - Bugfixes:
>> There are various bugfixes for network drive names resolution.
>> QPC & SMSQmulator use the correct SQRT replacement routines.
>> QPC better handling of removable drives.
>> 
>> Additional features:
>> 
>> - Filesystem for FAT16 disks of up to 256 MiB (currently only ysed in Q68).
>> 
>> - Filesystem for QUBide drives.
>> 
>> - Q40/Q60:
>> It is now possible to use IDE hard disks formatted with FAT32 and contining
>> QXL.WIN "drives" (see explanation in the extras_new directory).
>> The purpose of this is to allow easier data exchange between the Qx0 and
>> the rest of the QL world : Adapters exist which will plug into the Q40 IDE
>> connector and can read SDHC memory cards. If you format such a card on
>> FAT32, you can exchange QXL.WIN drives easily! You can, of course, also use
>> a FAT32 formmated hard disk with QXL.WIN files on it0
>> DISP_MODE command for Qx0 introduced.
>> Please note that this version cannot be burned into an EPROM.
>> 
>> - Q68
>> Q68 version of SMSQE introduced.
>> 
>> Find it at
>> 
>> http://www.wlenerz.com/smsqe/
>> 
>> 
>> Have fun.
>> 
>> Wolfgang
>> ___
>> QL-Users Mailing List
>> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Dock

[Tobias Fröschle via Ql-Users]

Failure or success might probably depend on whether you set an OUTLN on S*Basic 
in the BOOT or not.

Will do some further checks tonight.

Tobias

> Am 08.11.2017 um 14:17 schrieb pgraf--- via Ql-Users 
> :
> 
> On 8 Nov 2017 at 13:09, François Van Emelen via Ql-Users wrote:
> 
>> Here "dock" does its job correctly with QPC2, SMSQmulator and Black Phoenix.
> 
> Tobias reported the same problem on QPC2. Maybe you don't use the 
> latest version of SMSQ/E? That would make sense, because the "dock" 
> must have worked earlier.
> 
>> Error in line 1020: could it be that you didn't load the correct extension?
> 
> I seldom use BASIC other than for trivial tasks, and was not 
> prepared to debug the program. So I may do something stupid. But:
> 
> * There is no error, but a hang/crash! That should not happen when 
> using a BASIC command.
> 
> * What is the "correct extension"? Even with plain SMSQ/E, RPTR 
> seems there.
> 
> All the best
> Peter
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Dock

[Tobias Fröschle via Ql-Users]

That is why I proposed 2x2 - Depending on window position, the PE might round 
down the outline to the next even size, which is 0x0 when you have 1x1 ;) - So, 
you're back at the starting point.

Not really sure that is the problem, but might be it.

I did try to check the same, but on my system I seem to get a "bad parameter" 
error on the OUTLN command. Ned to check what's going on.

Tobias

> Am 07.11.2017 um 23:47 schrieb Peter Graf via Ql-Users 
> :
> 
> 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

___
QL-Users Mailing List

Re: [Ql-Users] Dock

[Tobias Fröschle via Ql-Users]

Peter,

you obviously seem to have a RPTR on your system, so that is most probably not 
the problem.

I would have a look at the OUTLN and WINDOW commands a bit up from there - They 
seem to be setting #0 to a zero size/outline (which is basically the whole 
point of the program) - This might possibly not work in every environment, 
because it is a rarely tested corner case - I'm not even sure if it should be 
considered legal, but must have worked at some point in time. Can you give that 
window a minimum size of say 2x2 and re-test?

And, just to mention it:
Doesn't work here as well in QPC2 and SMSQ/E 3.30

Tobias
> Am 07.11.2017 um 22:11 schrieb Peter Graf via Ql-Users 
> :
> 
> 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 Mailing List

Re: [Ql-Users] Dock

[Tobias Fröschle via Ql-Users]

Peter,

you obviously seem to have a RPTR on your system, so that is most probably not 
the problem.

I would have a look at the OUTLN and WINDOW commands a bit up from there - They 
seem to be setting #0 to a zero size/outline (which is basically the whole 
point of the program) - This might possibly not work in every environment, 
because it is a rarely tested corner case - I'm not even sure if it should be 
considered legal, but must have worked at some point in time. Can you give that 
window a minimum size of say 2x2 and re-test?

Tobias


> Am 07.11.2017 um 22:11 schrieb Peter Graf via Ql-Users 
> :
> 
> 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 Mailing List

Re: [Ql-Users] TYPE_IN

[Tobias Fröschle via Ql-Users]

Lee,

are you running on SMSQ/E? Are you maybe running PE with PE_BGOFF?

That will not allow your background program to run when it has (even partially) 
obstructed windows. So, if you "TYPE_IN" something into an obstructed S*Basic 
window, the job owning that window will not be able to digest your input, 
leading to such buffer overflows.

Try PE_BGON to activate background window processing.

Tobias


> Am 30.09.2017 um 15:43 schrieb Lee Privett via Ql-Users 
> :
> 
> Yes the string is about 60 characters long which is probably why it fails
> on the third TYPE_IN
> 
> tried using Pause to no effect :(
> 
> Lee
> 
> 
> 
> 
> 
> Virus-free.
> www.avast.com
> 
> <#m_2324895060461743699_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> Lee
> 
> 
> 
> 
> On Sat, Sep 30, 2017 at 12:38 PM, Wolfgang Lenerz via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi,
>> 
>> I have a slight problem with TYPE_IN
>>> 
>>> Using it to put some commands in #0, works well in an instance until I
>>> reach what appears to be a maximum set of characters, where the QL just
>>> hangs.
>>> 
>>> e.g.
>>> 
>>> 1920  TYPE_IN An&":"$(10)
>>> 1930  TYPE_IN (An+1)$$(10)
>>> 1932  TYPE_IN (An+2)$$(10)
>>> 1940  TYPE_IN (An+3)$$(10)
>>> 
>>> 
>>> An is an integer
>>> Final$ is just text
>>> Top$ is a string of asterisks
>>> 
>>> it locks up displaying halfway through 1940
>>> 
>>> Is there a buffer I can clear after using TYPE_IN?
>>> 
>> 
>> How long i the string in line 194?
>> 
>> IIRC, the Ql's keyboard buffer is 128 bytes long... You cannot increase
>> this, AFAIK.
>> 
>> I don't think you can clear this.
>> Perhaps a pause after the earlier TYPE_In instructions will leave the
>> system time to clear it.
>> 
>> 
>> 
>> HTH
>> 
>> Wolfgang
>> 
>> ___
>> QL-Users Mailing List
>> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] TYPE_IN

[Tobias Fröschle via Ql-Users]

You _can_ open a cONsole window with more than 128 bytes of input buffer 
("con_512x202a0x0_256", for example). But you _cannot_ tell S*Basic to open #0 
like that as default.

I just checked: 

close#0:open#0,"con_512x256a0x0_1024" 

seems to work. Unfortunately, I cannot check how large the keyboard buffer 
allocated might be.

Tobias


> Am 30.09.2017 um 13:56 schrieb Derek via Ql-Users :
> 
> Hi,
> Is it possibile to extend the 128 byte QL keyboard buffer.
> Was TYPE_IN an a attempt to do this?
> RegardsDerek
>  Original message From: Wolfgang Lenerz via Ql-Users 
>  Date: 30/09/2017  12:38  (GMT+00:00) To: 
> ql-us...@q-v-d.com Cc: Wolfgang Lenerz  Subject: Re: 
> [Ql-Users] TYPE_IN 
> Hi,
> 
>> I have a slight problem with TYPE_IN
>> 
>> Using it to put some commands in #0, works well in an instance until I
>> reach what appears to be a maximum set of characters, where the QL just
>> hangs.
>> 
>> e.g.
>> 
>> 1920  TYPE_IN An&":"$(10)
>> 1930  TYPE_IN (An+1)$$(10)
>> 1932  TYPE_IN (An+2)$$(10)
>> 1940  TYPE_IN (An+3)$$(10)
>> 
>> 
>> An is an integer
>> Final$ is just text
>> Top$ is a string of asterisks
>> 
>> it locks up displaying halfway through 1940
>> 
>> Is there a buffer I can clear after using TYPE_IN?
> 
> How long i the string in line 194?
> 
> IIRC, the Ql's keyboard buffer is 128 bytes long... You cannot increase 
> this, AFAIK.
> 
> I don't think you can clear this.
> Perhaps a pause after the earlier TYPE_In instructions will leave the 
> system time to clear it.
> 
> 
> 
> HTH
> 
> Wolfgang
> 
> ___
> QL-Users Mailing List
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Stupid AND

[Tobias Fröschle via Ql-Users]

That language definition (if it exists, I don't know) would only matter for 
functions - simple comparisons that have no side effect would be fine to simply 
omit.
Tobias


> Am 19.09.2017 um 23:42 schrieb Jan Bredenbeek via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> On 19 September 2017 at 23:36, Tobias Fröschle via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Neither Turbo nor QLiberator do short-circuit evaluation.
>> C68 does.
>> 
> 
> Because it's part of the language definition.
> 
> Jan
> -- 
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Stupid AND

[Tobias Fröschle via Ql-Users]

Neither Turbo nor QLiberator do short-circuit evaluation.
C68 does.

Tobias

> Am 19.09.2017 um 23:25 schrieb Jan Bredenbeek via Ql-Users 
> :
> 
> On 19 September 2017 at 21:27, Wolfgang Lenerz via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi all,
>> 
>> 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?
> 
> 
> Because all BASICs do. And more languages like Pascal (but not C).
> 
> Jan.
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

Lee,

in case your question is really only Turbo Toolkit specific, you can very well 
do away with a much simpler solution than WHEN ERRor clauses:

1000 IF TK_VER$ <> "" 
1010   REM do whatever you want to do when Turbo Toolkit is loaded
1020 ELSE
1030  REM Do whatever you want to do if it is not loaded
1030 END IF

This relies on the fact that the interpreter will interpret TK_VER$ as a 
FUNCTION returning a string in case the toolkit is loaded, and an unset string 
variable in case it is not. And unset string variables are by convention 
"empty".

Tobias


> Am 17.08.2017 um 12:37 schrieb Lee Privett via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> Perhaps I should clarify this a little further.
> 
> Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the same
> boot, I will always do this or use QPC2, I am not really looking for a BBQL
> solution as it is development for other things.
> 
> Where this
> 
> [code]IF VER$<>"HBA" THEN
>   LRESPR "WIN8_SMSQ_QEM"
> END IF[/code]
> 
> loads SMSQ and fails the second time around (as designed, so all good) as
> the same boot loads again, I then load (still in the same boot) the
> TURBO_SMS_CODE appropriate for SMSQ based system.
> 
> This is all fine, however, I am developing the boot for different setups
> and change them a lot depending on what project I decide to work on.
> 
> This means re-running the boot several times in the one session to test
> what I am trying to do and I don't want to keep using up space re-LRESPR
> the TURBO toolkit.
> Using another toolkit to test for the existence of a keyword in the TURBO
> toolkit would then mean using another method to test for that additional
> Toolkit, a catch 22.
> 
> So I may try the WHEN_ERR method as soon as I find the documentation on it.
> 
> Lee
> 
> 
> 
> 
> Lee
> 
> 
> 
> 
> On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi Tobias,
>> 
>> The WHEN solution is great, but on some version of QODS, the WHEN ERRor
>> did not work.
>> 
>> There are some people still using AH,JM, roms which may have problems with
>> WHEN ERRor
>> 
>> --
>> Regards,
>> 
>> Derek
>> 
>> 
>> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
>> 
>>> After I sent this, I realised a bit of explanation might be in order, as
>>> WHEN ERRor is not so well-known:
>>> 
>>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
>>> program execution, it doesn't do anything with the commands inside the
>>> clause but remembering "I should do this in case an error occurs". So, line
>>> 1020 is not executed if no error occurs in line 1050. But in case there is
>>> an error (the interpreter choking on the MANIFEST statement it doesn't know
>>> when TT is not loaded), line 1020 is executed, telling us TT is not loaded.
>>> 
>>> After 1020 was executed, the program is continued at the point /after/
>>> the error occurred.
>>> 
>>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
>>> processing back to "normal".
>>> 
>>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was
>>> executed without a problem, and set to 0 in case there was an error.
>>> Because we have made sure line 1050 is the only line that can be executed
>>> while error processing is active, we clearly know the only problem in 1050
>>> can only be "bad name". So it is important to pick a "test command" from
>>> the toolkit you are testing for that cannot choke on a different error than
>>> "bad name". MANIFEST is pretty ideal for this.
>>> 
>>> Tobias
>>> 
>>> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users <
>>>> ql-users@lists.q-v-d.com>:
>>>> 
>>>> Lee,
>>>> 
>>>> there are a number of toolkits that allow you to check for specific
>>>> other toolkit commands loaded or not - But this is a bit useless as it
>>>> leaves you with a chicken-and-egg problem: How to check whether the
>>>> checking toolkit is loaded?
>>>> 
>>>> Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in
>>>> front of a Toolkit command you are about to execute:
>>>> 
>>>> 1000 TurboTkLoaded = 1
>>>> 1010 WHEN ERRor
>>>> 1020TurboTkLoaded = 0
>>>> 1030 END WHEN
>>>&

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

After I sent this, I realised a bit of explanation might be in order, as WHEN 
ERRor is not so well-known:

When the interpreter passes a WHEN ERRor/END WHEN pair during normal program 
execution, it doesn't do anything with the commands inside the clause but 
remembering "I should do this in case an error occurs". So, line 1020 is not 
executed if no error occurs in line 1050. But in case there is an error (the 
interpreter choking on the MANIFEST statement it doesn't know when TT is not 
loaded), line 1020 is executed, telling us TT is not loaded.

After 1020 was executed, the program is continued at the point /after/ the 
error occurred.

The empty WHEN ERRor clause (1060-1070) simply de-activates error processing 
back to "normal".

Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was executed 
without a problem, and set to 0 in case there was an error. Because we have 
made sure line 1050 is the only line that can be executed while error 
processing is active, we clearly know the only problem in 1050 can only be "bad 
name". So it is important to pick a "test command" from the toolkit you are 
testing for that cannot choke on a different error than "bad name". MANIFEST is 
pretty ideal for this.

Tobias

> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> Lee,
> 
> there are a number of toolkits that allow you to check for specific other 
> toolkit commands loaded or not - But this is a bit useless as it leaves you 
> with a chicken-and-egg problem: How to check whether the checking toolkit is 
> loaded?
> 
> Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front 
> of a Toolkit command you are about to execute:
> 
> 1000 TurboTkLoaded = 1
> 1010 WHEN ERRor
> 1020TurboTkLoaded = 0
> 1030 END WHEN
> 1040 REMark Execute a Toolkit command
> 1050 MANIFEST : x = 100
> 1055 REMark de-activate error checker
> 1060 WHEN ERRor
> 1070 END WHEN
> 1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded
> 
> On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, 
> the only thing I could probably come up with is writing a BASIC program that 
> PEEKs the name list, which is not quite so simple.
> 
> Tobias
> 
> 
>> Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
>> <ql-users@lists.q-v-d.com>:
>> 
>> I originally posted this on the forum:
>> 
>> Hi community, I have searched for this on the forum but cannot find an
>> entry but I am sure this has been asked before.
>> 
>> I currently test for the presence of the HBA ROM in a boot program using
>> VER$ and would like to test for other toolkits, specifically the TURBO
>> toolkit. Is there a way to do this automatically in a boot so that when
>> subsequent runs of the boot it is not loaded again in one session?
>> 
>> e.g. for the HBA version I use:
>> 
>> Code: Select all <http://qlforum.co.uk/viewtopic.php?f=3=2063#>
>> IF VER$<>"HBA" THEN
>>  LRESPR "WIN8_SMSQ_QEM"
>> END IF
>> 
>> 
>> I feel there must be a way to test for TURBO toolkit, any ideas?
>> 
>> A reply from Derek suggested  the following:
>> 
>> There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
>> which is the same for the SMS and QDOS versions.
>> 
>> A simple way would be to add "SMS" in the version number. Which would mean
>> a new version of Turbo Toolkit.
>> 
>> The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
>> so maybe a test for SMSQ/E extended traps is the way, but I would favour
>> the about alteration to TK_VER$.
>> 
>> George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
>> message needs to be posted in the QL-USERS mailing list, George Gwilt reads
>> that list.
>> 
>> Any views at all?
>> 
>> Regards Lee Privett
>> ___
>> QL-Users Mailing List
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

Lee,

there are a number of toolkits that allow you to check for specific other 
toolkit commands loaded or not - But this is a bit useless as it leaves you 
with a chicken-and-egg problem: How to check whether the checking toolkit is 
loaded?

Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front of 
a Toolkit command you are about to execute:

1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, the 
only thing I could probably come up with is writing a BASIC program that PEEKs 
the name list, which is not quite so simple.

Tobias


> Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
> :
> 
> I originally posted this on the forum:
> 
> Hi community, I have searched for this on the forum but cannot find an
> entry but I am sure this has been asked before.
> 
> I currently test for the presence of the HBA ROM in a boot program using
> VER$ and would like to test for other toolkits, specifically the TURBO
> toolkit. Is there a way to do this automatically in a boot so that when
> subsequent runs of the boot it is not loaded again in one session?
> 
> e.g. for the HBA version I use:
> 
> Code: Select all 
> IF VER$<>"HBA" THEN
>   LRESPR "WIN8_SMSQ_QEM"
> END IF
> 
> 
> I feel there must be a way to test for TURBO toolkit, any ideas?
> 
> A reply from Derek suggested  the following:
> 
> There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
> which is the same for the SMS and QDOS versions.
> 
> A simple way would be to add "SMS" in the version number. Which would mean
> a new version of Turbo Toolkit.
> 
> The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
> so maybe a test for SMSQ/E extended traps is the way, but I would favour
> the about alteration to TK_VER$.
> 
> George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
> message needs to be posted in the QL-USERS mailing list, George Gwilt reads
> that list.
> 
> Any views at all?
> 
> Regards Lee Privett
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Function type error

[Tobias Fröschle via Ql-Users]

The type of a function is not determined by the function name ending in a $ or 
% sign, but rather by what it returns - You can even write a function STRING% 
that returns a string or a function a$ that returns an integer value. The name 
you give your function is simply a hint to yourselves on what it might return.

What you actually return in your original function is the result of an 
/expression/ - and numerical expressions in S*BASIC are of type floating point. 
If you assign the value to the expression to a LOCal integer value and return 
that, you will actually get your desired result.

1000 DEFine FuNction x% (param)
1010   LOCal x%
1020   x% = param / 10
1025  REMark assign to integer variable x% to make sure INT is returned
1030  RETurn x%
1040 END DEFine x%

Dilwin's proposal /looks/ like it would be doing the right thing, but actually 
isn't. INT in S*BASIC returns a long integer which cannot be properly 
represented in the language, so it's actually converted to a floating point 
value and returned (albeit with the proper value).

Tobias


> Am 10.08.2017 um 19:22 schrieb Dilwyn Jones via Ql-Users 
> :
> 
> The fact that the function name ends in % doesn't seem to make it an integer 
> function (although the QL user guide says that "the type of data returned by 
> the function is indicated by the type appended to the function identifier") 
> any more than  parameter names have no type until they are set, so parameter 
> x% could be float or integer, depending on what it is made when parameters 
> are passed.
> 
> As a workaround, add INT in line 160
> 
> 160 IF INT(x%) < i : RETurn INT(x%) : ELSE return INT(i)
> 
> Dilwyn
> 
> -Original Message- From: Michael Bulford via Ql-Users
> Sent: Thursday, August 10, 2017 5:54 PM
> To: ql-users@lists.q-v-d.com ; ql-users-requ...@lists.q-v-d.com
> Subject: [Ql-Users] Function type error
> 
> Hi all,
> I've no idea whether this has been mentioned before, but consider this … 100 
> :110 PRINT #0, Min_Int%(330.7, 440.7)120 PAUSE -1130 STOP140 :150 DEFine 
> FuNction Min_Int%(x%,i)160  IF x% < i : RETurn x% : ELSE : RETurn i170  END 
> DEFine The correct result should be 331, sincethis is an integer function.On 
> QPC2, SBASIC gives the result as 330.7QLiberator likewise also gives 330.7 
> Can anything be done? Michael
> 
> ___
> QL-Users Mailing List
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] R: R: R: QxlwinReader

[Tobias Fröschle via Ql-Users]

Davide,
dd is a utility program that allows you to dump raw file systems or partitions 
to image files and back. It is a standard program that comes with all Unix and 
Linux systems. 
It is available as near function-equivalent implementations on Windows systems 
as well:
http://www.chrysocome.net/dd
Is one example I have used successfully in the past.

Tobias

> Am 17.06.2017 um 20:17 schrieb via Ql-Users :
> 
> Of course I misunderstood and I thought Wolfgang was referring to a floppy
> disk transfer. Can you please provide the link for the download of this "DD"
> utility?
> 
> Thanks
> 
> Davide
> 
> -Messaggio originale-
> Da: Ql-Users [mailto:ql-users-boun...@lists.q-v-d.com] Per conto di Peter
> Graf via Ql-Users
> Inviato: sabato 17 giugno 2017 20:01
> A: ql-us...@q-v-d.com
> Oggetto: Re: [Ql-Users] R: R: QxlwinReader
> 
> Davide wrote:
> 
>> Having had to transfer a full QL system based on SGC/Qubide to .win 
>> with 150 Mb, using DD would have been quite a nightmare.
> 
> Why should dd be a nightmare? Are you aware that dd means a utility program,
> not floppies?
> 
>> [...]
> 
>> I understand the effort to write such sw might not be negligible, but 
>> a utility which could manage to read native Qubide hard disks on a PC 
>> and transfer files to a .win file (and maybe vicecersa) I think would 
>> be very useful.
> 
> If you have a PC with IDE port anyway, then where is the problem to use dd
> to get the image?
> 
> Peter
> 
> ___
> QL-Users Mailing List
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List