Well, whatever you guys choose to believe, please no one try to "fix"
it as this behaviour appears to be consistent across the board - at
least as far as JS, Minerva and SMSQ/E are concerned. If programmers
keep their indices in order the issue should never arise anyway.
Per
On 13/01/2024 13:42
I wonder if part of the reason that this arose is that some BASICs
from that era just returned a null string "" if string slicing errors
arose, without an error message and people remembered that?
While that was probably convenient for the casual programmer, it must
have made debugging difficult i
Norman Dunbar wrote:
I still think that returning "" for a specific string slice from (a to
a-1) is a bug!
I tend to agree. x$ (a to b) where b is smaller than a should rise an
error.The only way that would make any kind of sense to me would be if
this returned the array contents in the re
Morning Jan,
That matches with Jan Jones. Arrays index from zero, but simple strings from 1.
Cheers,
Norm.
--
Author of "Arduino Software Internals" and "Arduino Interrupts".
___
QL-Users Mailing List
Could the reference be the SBASIC/SuperBASIC reference manual?
That says
When a string array is set up with DIM, each entry is set to a nul string
(“”). The zero’th element of each string array
contains the actual length of that string, for example:
DIM a$(10,10): a$(1)='Hello': PRINT a$(1,0)
will
On 12-01-2024 16:20, Norman Dunbar via Ql-Users wrote:
If I remember correctly, all the way back to 1984-85, I'm almost
certain that the supplied QL manual, in the large, heavy, A$ folder,
mentioned that string lengths are indeed stored in a$(0)---or at
least, can be accessed from there.
C
On 08/01/2024 18:46, pjw via Ql-Users wrote:
> 100 a$ = "1234567890"
> 105 b$ = a$(4 to 3): REMark This works
> 110 REMark c$ = a$(4 to 2): REMark This fails with an error.
> 115 c$ = a$( to 0) : REMark no error returned
> 120 c$ = a$(0):: REMark no error returned BUT ERROR IF QLIBERATED
>
On 08/01/2024 16:51, Wolfgang Lenerz via Ql-Users wrote:
Line 120 is due to the fast that strings are not 0 based index. So what
would a$(0) be?
Under SMSQ/E at least, print a$(0) in the above example would give "10"
- which is the length of the string... Since this seems to be an
unorthodox b
Line 105: The construct a$(n to n - 1) represents the empty string
(even when n = 1). Since it is replicated in JS, Minerva and SMSQ/E Im
assuming it is by design. It also makes sense as there would be no
other way to represent a string slice of null.
Line 115: I guess a$( to 0) is read as a$(
Hi,
Line 120 is due to the fast that strings are not 0 based index. So what
would a$(0) be?
Under SMSQ/E at least, print a$(0) in the above example would give "10"
- which is the length of the string... Since this seems to be an
unorthodox behaviour, it's no wonder Qlib balks at it.
Line 1
Hi,
Some other anomalies
100 a$ = "1234567890"
105 b$ = a$(4 to 3): REMark This works
110 REMark c$ = a$(4 to 2): REMark This fails with an error.
115 c$ = a$( to 0) : REMark no error returned
120 c$ = a$(0): : REMark no error returned BUT ERROR IF QLIBERATED
125 pause:stop
The problem of
Hi,
ermm, I somehow forgot to link in the FLP driver into SMSQ/E.
Until I have time to replace this on my normal SMSQmulator website, you
can find the new SMSQE.zip file here:
www.wlenerz.com/148temppjw25KL/SMSQE.zip
(use copy & paste)
Replace the existing file with the one in the zip file
Thanks,
I'll check that.
Wolfgang
On 11/02/2017 11:24, David Gilham wrote:
setup smsqmulator version 2.22 SMSQE 3.29
I am using the java 7 version of smsqmulator on my linux thinkpad box
i have a usb floppy drive.
The problem is this
I was going through some old ql formatted floppies
and wan
Am 11.02.2017 um 11:24 schrieb David Gilham:
setup smsqmulator version 2.22 SMSQE 3.29
I am using the java 7 version of smsqmulator on my linux thinkpad box
i have a usb floppy drive.
The problem is this
I was going through some old ql formatted floppies
and wanted to check their contents
making
setup smsqmulator version 2.22 SMSQE 3.29
I am using the java 7 version of smsqmulator on my linux thinkpad box
i have a usb floppy drive.
The problem is this
I was going through some old ql formatted floppies
and wanted to check their contents
making a disk image of the floppy disc was easy
now i
On 2 May 2012, at 16:00, Norman Dunbar wrote:
>
> When I edit a string using this vector, and press ESC to terminate the edit,
> I'm seeing zero in D0 instead of a positive number. D1.W is correctly set to
> 27 for the ESC key.
>
> The docs state that:
>
> D0 negative is an error.
> D0 zero
I'm seeing a possible bug in WMAN's WM.ENAME.
When I edit a string using this vector, and press ESC to terminate the
edit, I'm seeing zero in D0 instead of a positive number. D1.W is
correctly set to 27 for the ESC key.
The docs state that:
D0 negative is an error.
D0 zero means ENTER presse
Rich Mellor wrote:
Here's an interesting little challenge - according to "The Designer"
program from Pyramide, there is a bug in the French MG ROM which it
patches -
see http://www.qlforum.co.uk/viewtopic.php?f=2&t=116
Anyone have any suggestions as to what this patch does?
I just know abozt
Here's an interesting little challenge - according to "The Designer"
program from Pyramide, there is a bug in the French MG ROM which it
patches -
see http://www.qlforum.co.uk/viewtopic.php?f=2&t=116
Anyone have any suggestions as to what this patch does?
--
Rich Mellor
RWAP Services
http://
On 17 Jan 2007, at 19:19, Marcel Kilgus wrote:
>
> There were bugs in the past of QPC that vanished when using a debugger
> (the instructions used by the debugger did by pure chance clear some
> internal register a normal code execution did not). But that was over
> 10 years ago, nowadays the QPC
Hi Marcel
I'm using 3.33. The problem now is that I can't reproduce the behavior.
At the time clearing the
data register before loading it with a word from memory solved the
problem. However removing
the moveq #0,dn does not bring back the problem. The compare operation
also had an offset i.e.
George Gwilt wrote:
> This works absolutely as expected on both a Q60 and QPC2 (latest
> version). That is, the branch does go to "equal". I assume you used
> QMON or whatever to step through the program else you can't see what
> is happening.
There were bugs in the past of QPC that vanished w
On 17 Jan 2007, at 10:17, Malcolm Lear wrote:
>
> Is this normal behavior for a 68K processor. I'm doing a word
> comparison
> between a memory location and a data register. It seems that data
> in the
> most significant word of the register is effecting the result. In the
> example
> below t
Malcolm Lear wrote:
> start move.l #$,d0
> lea test,a4
> cmp.w(a4),d0
> beq.sequal
> bra.snotequal
> test dc.w 0
> equal nop
> notequal nop
I have no idea what assembler you use, but just by looking at the code
le
Thanks Wolfgang, I'll investigate further. The code I've got problems
with is obviously
slightly more complex, but a group of comparisons that failed were fixed
by clearing
the data register before loading with a word from memory.
Malcolm
Wolfgang Lenerz wrote:
>On 17 Jan 2007 at 10:17, Malco
Malcolm Lear wrote:
> Hi
>
> Is this normal behavior for a 68K processor. I'm doing a word comparison
> between a memory location and a data register. It seems that data in the
> most significant word of the register is effecting the result. In the
> example
> below the test ends up at notequal. U
On 17 Jan 2007 at 10:17, Malcolm Lear wrote:
> Hi
>
> Is this normal behavior for a 68K processor.
Hmm, here (QPC) the test works OK, it branches to the equal label as
expected, the Z flag is set by the CMP.
Wolfgang
www.scp-paulet-lenerz.com
___
Hi
Is this normal behavior for a 68K processor. I'm doing a word comparison
between a memory location and a data register. It seems that data in the
most significant word of the register is effecting the result. In the
example
below the test ends up at notequal. Unfortunately I've not got access
George wrote:
>
> The point about all this is that the opcodes $32 up to $FF should
> produce the addresses $FF32(A6,A4.L) to $FFFE(A6,A4.L), or -206
> (A6,A4.L) to -2(A6,A4.L) by whatever means. If SMSQ/E sets $32 to
> $0032 instead of $FF32 then it is definitely wrong!
>
Hi George,
SMSQ/
On 24 Sep 2006, at 12:03, Marcel Kilgus wrote:
> George Gwilt wrote:
>> Dickens says that codes $31 to $FF are extended to a negative word
>> $FF31 to $ when used to determine the storage address. Apart from
>> the fact that $31 does not seem to be allowed, Pennel and Dickens are
>> saying th
George Gwilt wrote:
> Dickens says that codes $31 to $FF are extended to a negative word
> $FF31 to $ when used to determine the storage address. Apart from
> the fact that $31 does not seem to be allowed, Pennel and Dickens are
> saying the same thing in different ways, Pennel is in fact corre
On 22 Sep 2006, at 08:14, [EMAIL PROTECTED] wrote:
> Ok, A6,A1 was a typo, I meant A4 - apologies. On the other hand, my
> QDOS Companion (Pennell) has the load/save parameters as $32 to $ff
> and not $ff31 to $ as you state.
>
> I went on a doc hunt last night and Dickens has the negati
Marcel,
I don't disagree. The reason for the posting was that the previous
posting had misrepresented the contents of the Wikipedia article. I
don't think that I made any claims about the veracity of the article, or
of the theory.
However, the evidence from Sweden quoted in that article was not
Jeremy Taffel wrote:
> According to Wikipedia, the story about Napoleon is legend with no
> basis in fact.
I did look at Wikipedia. But I just consider it a "somewhat" reliable
source and in those cases I still always fact check with other
sources. And Wikipedia is pretty much the only source havi
In message <[EMAIL PROTECTED]>, Jeremy Taffel
<[EMAIL PROTECTED]> writes
>Jeremy (still lurking, rarely QLing these days)
What, not even QL emulating ... :-)
--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
According to Wikipedia, the story about Napoleon is legend with no basis
in fact.
However, what is interesting is that road traffic statistics seem to
suggest that driving on the left is safer. The theory is that the
preponderance of right eye dominance results in statistically faster
reaction
[EMAIL PROTECTED] wrote:
> You'd probably be surprised at just how much time is involved in
> writing an article, never mind a series.
As somebody who usually fact-checks every single sentence in every
single eMail I write, maniacally really, I'm not the least bit
surprised, no ;-)
>> Well, histo
Marcel,
> Well, I myself have never used this and only read up on it after your
> questions...
Much obliged - thanks !
> The idea of my own column commenting on all the things I read that are
> wrong or at least not-quite-right has already crossed my mind, but
> then I'm lazy and currently don'
[EMAIL PROTECTED] wrote:
> It's not exactly documented anywhere really. Well not until QL Toady
> prints my next article where I have a good rant on the subject :o)
Well, I myself have never used this and only read up on it after your
questions...
> Mind you, it allows someone more knowlegable th
Sorry, Norm,
Twas under that Subject I read Tony's French tour !
D
At 12:18 22/09/2006 +0100, you wrote:
>Thanks.
>(I think !!!)
>
>Cheers,
>norman.
>
>[EMAIL PROTECTED] wrote:
> > At 10:41 22/09/2006 +0100, you wrote:
> >
> > Probably, I can see no connection !
> >
> >
> > --
>
>
>
Hi Marcel,
> Yes, but nobody tells you that the data area is just for FP data.
True, but if I was setting up an area of storage I'd be sure (myself) to keep
my FP stuff well away from my other stuff purely because it's possible for the
FP stuff to wander all over my other stuiff if I get the off
[EMAIL PROTECTED] wrote:
> Not with the LOAD/SAVE op code as far as I can see, they always take
> 6 bytes from the A1 stack and load back 6 bytes. There is no way
> that I can see (using the maths package) to load and save a word for
> example.
Yes, but nobody tells you that the data area is just
[EMAIL PROTECTED] wrote:
> You must visit Minerve.
We probably will - I'll be driving and MrsD will be navigating in her usual
manner - "you should have turned left back there" ! (Only kidding)
> and wine around there is pronounced "Ving" with a hard end G -
> important to know (8-)#
Thanks.
(I think !!!)
Cheers,
norman.
[EMAIL PROTECTED] wrote:
> At 10:41 22/09/2006 +0100, you wrote:
>
> Probably, I can see no connection !
>
>
> --
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
At 10:41 22/09/2006 +0100, you wrote:
Probably, I can see no connection !
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.7/454 - Release Date: 21/09/2006
___
QL-Users Mailing List
[EMAIL PROTECTED] wrote:
I'm looking forward to hearing back from you all :o)
>
> PS. I'm off to France next week, so any replies after today will be delayed
> in being read. I've got to drive on the wrong side of the road for a week -
> that should be fun. If you are anywhere around Marseill
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> >>Not only that, but codes from -5 through to -1 will overwrite data at
> >>the top of your A4 stack.
>
> Ignore that. I'm a pillock. I've got my mental stack upside down again :o(
>
Actually, I may not be a pillok after all ! Correct me
[EMAIL PROTECTED] wrote:
Morning Derek,
>
> Many years ago I wrote many Hyperbolic function based on The Advanced
> QL User Guide, by Dickens. All seemed to work fine.
>
Funny that. I was just wondering if anyone had ever done that sort of thing
when I was looking at Dickens last night. Spooky
[EMAIL PROTECTED] wrote:
>>Not only that, but codes from -5 through to -1 will overwrite data at
>>the top of your A4 stack.
Ignore that. I'm a pillock. I've got my mental stack upside down again :o(
Cheers,
Norman.
___
QL-Users Mailing List
http://w
Hi Norman,
Many years ago I wrote many Hyperbolic function based on The Advanced
QL User Guide, by Dickens. All seemed to work fine.
The functions in the book only described the obvious functions, I
needed some other fuctions for a mechanical engineeriong problem I did
on the QL in Superbasic, fo
Morning Marcel, Wolfgang,
Thanks for your replies.
> Nope, that's where you differ with the documentation. First, the
> variable area is (A6,A4), typo I guess, and second, the opcodes $FF31
> to $ are for load/save, not $32 to $FF. Yes, the latter DO work,
> but it seems that's more an undocu
On 21 Sep 2006 at 18:36, Marcel Kilgus wrote:
>(...)
> Well, you can store other things in the variable area too, so it makes
> sense that you can address every individual word there.
Just to add to that some small explanation:
the load/save ops (and yes, there are negively indexed) are just t
[EMAIL PROTECTED] wrote:
> I was explaining the SAVE and LOAD op codes for RI_EXEC and RI_EXECB
> where the top of stack floating point value is saved to a variables
> area at (A6,A1.L) or a new TOS is created by loading back from said
> area. The op codes for save are even in the range $32 to $FF
Afternoon all.
I'm puzzled again. I'm writing an article on the use of the maths packags in
QDOSMSQ for our esteemed QL Toady magazine and I've hit a small problem that,
for the life of me, I can't figure out.
I was explaining the SAVE and LOAD op codes for RI_EXEC and RI_EXECB where the
top o
ptember 04, 2006 5:34 PM
Subject: Re: [ql-users] bug in qlib_h C68 support file
> Hi Guys,
>
> Three things were fooling me:
>
> 1) I was calling this using a C function so I 'assumed' that it was
> converting to C strings
>
> 2) when I grab the string, if under 3
unkins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2006 5:34 PM
Subject: Re: [ql-users] bug in qlib_h C68 support file
> Hi Guys,
>
> Three things were fooling me:
>
> 1) I was calling this using a C function so I 'assumed' that it wa
> floppy
> based systems. Those using hard disk based systems are better off
> using the
> commented versions
>
> Dave
> .
> - Original Message -
> From: "James Hunkins" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 04,
Rich Mellor wrote:
> However, ideally the minimum surely has to be 36+5?? (rounded up to 42) or
> does the library have a distinct device name string also??
No, the device name is not part of the directory/file name.
Marcel
___
QL-Users Mailing List
ht
On Mon, 04 Sep 2006 15:49:18 +0100, Marcel Kilgus
<[EMAIL PROTECTED]> wrote:
> James Hunkins wrote:
>> I think that I found a bug in the qlib_h include file used by C68.
>> Here are the details:
>>
>> In the 'qdirect' structure, the member 'd_name' is defined as:
>> char d_name[36];
>
>
On Mon, 04 Sep 2006 15:18:59 +0100, James Hunkins <[EMAIL PROTECTED]>
wrote:
> Guys,
>
> I think that I found a bug in the qlib_h include file used by C68.
> Here are the details:
>
> In the 'qdirect' structure, the member 'd_name' is defined as:
> char d_name[36];
>
> This works as long a
floppy
based systems. Those using hard disk based systems are better off using the
commented versions
Dave
.
- Original Message -
From: "James Hunkins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2006 3:18 PM
Subject: [ql-users] bug in q
James Hunkins wrote:
> I think that I found a bug in the qlib_h include file used by C68.
> Here are the details:
>
> In the 'qdirect' structure, the member 'd_name' is defined as:
> char d_name[36];
Your misconception is that d_name holds a null terminated string,
which it doesn't. The le
Guys,
I think that I found a bug in the qlib_h include file used by C68.
Here are the details:
In the 'qdirect' structure, the member 'd_name' is defined as:
char d_name[36];
This works as long as the directory/file name is 35 or fewer
characters and holds a properly terminated C st
63 matches
Mail list logo
