Re: [Ql-Users] Select on

2020-06-20 Thread Jan Bredenbeek via Ql-Users
Op za 20 jun. 2020 14:01 schreef Dave Park via Ql-Users <
ql-users@lists.q-v-d.com>:

>
>
>
> ooGyebd = Goodbye
> goodbye <> Goodbye
>
> Use a hash algorithm like CRC-16 or CRC-32? ;-)

Jan
___
QL-Users Mailing List


Re: [Ql-Users] IOB.FLIN strips CR from lines ending in CR/LF

2020-03-24 Thread Jan Bredenbeek via Ql-Users
On Tue, 24 Mar 2020 at 06:59, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Jan,
>
> On what machine?
>

It does occur on QPC2 too and appears to be connected to WIN-devices
(doesn't occur on ram and dos, only win).

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] IOB.FLIN strips CR from lines ending in CR/LF

2020-03-23 Thread Jan Bredenbeek via Ql-Users
I recently discovered that the IOB.FLIN trap on SMSQ/E, when called to read
a line from a file, strips any CR from lines ending in CR/LF.
However, this seems to happen ONLY with files on the WINx device!
I've tried several versions of SMSQ/E, even ones as old as v3.05, and they
all show the same symptom.

Is this a bug or a feature?

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-10 Thread Jan Bredenbeek via Ql-Users
Hi Peter,

On Tue, 10 Mar 2020 at 09:03, pgraf--- via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> > Anyway, it's working now... got about 30Kbit throughput between the Q68
> and
> > a BBQL with GC, which is about the expected rate given the fact that
> QLnet
> > is half-duplex. SERnet between Q68 and PC is about twice as fast at
> 115200
> > baud, but as I said it's easier to do bulk transfers by swapping SDHC
> > cards. At least my BBQLs now have easy access to real mass-storage :-).
>
> Glad it works for you. Only 30 Kbit sounds a bit low, was that with
> mass storage or ramdisk?
>

This was by copying a file (unzip) of 58 bytes from ramdisk on Q68 to
ramdisk on BBQL+GC, which took about 29 seconds from Q68 to BBQL. The other
way round was a bit faster, 22 seconds so about 5000 cps. But copying from
Q68 to BBQL with Trump card took 41 seconds, so processor speed does play a
role. On my Issue 5 (JM) QLs I couldn't get the network to work.

I apparently made a mistake in converting cps to bps, as the bytes on QLnet
seem to be sent with a gap of 5 bits so I should multiply by 13 to get bps,
which yields around 65Kbps. The theoretical limit would be 1bit/11.2us =
90Kbps but the network protocol will have a significant overhead caused by
the small packet size (256 bytes) which means you lose a lot of throughput
since the sender has to wait for an ACK every 256 bytes. Even on SERnet
(which is full-duplex) this is an issue and also the reason why protocols
like XMODEM has a poor performance on high-speed modem lines. On the other
hand, streaming protocols like ZMODEM perform very well if there is proper
flow control on your serial link but fail miserably when there isn't...

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-09 Thread Jan Bredenbeek via Ql-Users
On Wed, 4 Mar 2020 at 18:05, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> If you have no problem with network plugs on the front side, then I'd
> recommend drilling a hole to the front panel.
>

For the moment I have removed the on/off switch as I pull out the mains
plug of the power supply anyway to save energy.


> > Or is there a simple way to convert the sound output socket to a network
> > socket with minimal damage?
>
> It is even possible without *any* damage, but you would lose sound. Some
> tinkering would be involved, drilling a hole is definitely easier.
>

>From what I can see I have to remove the capacitors(?) in the PCB tracks to
the socket, which is quite a challenge given their small size, the crowded
PCB area and my aging eyes :-(. So I have mounted the resistors and diode
in the area for the expansion connector and used the ground hole on the
reset connector for ground (I did not dare to use the ground hole on the
expansion connector as it's very close to the +3.3V and a short-circuit is
easily made.

Anyway, it's working now... got about 30Kbit throughput between the Q68 and
a BBQL with GC, which is about the expected rate given the fact that QLnet
is half-duplex. SERnet between Q68 and PC is about twice as fast at 115200
baud, but as I said it's easier to do bulk transfers by swapping SDHC
cards. At least my BBQLs now have easy access to real mass-storage :-).

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-04 Thread Jan Bredenbeek via Ql-Users
On Mon, 2 Mar 2020 at 18:56, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Jan,
>
> > I personally use a Linux machine or Raspberry Pi with tcpser and a>
> USB-to-serial converter to exchange files to my BBQL.
> How about using a Q68 as bridge from Linux (SER) to QLNET (BBQL)?
>
> This way you could use higher baudrates. And network is much faster on
> the BBQL than SER.
>

>From PC or RPi to Q68 it's just a matter of swapping SDHC cards ;-).
I've just ordered Schottky diodes for the operation 'Q68-net'.
I followed the discussion on the QL forum about fitting network sockets to
the Q68 case. This doesn't look very straightforward. I think removing the
on/off switch and mounting the network socket there will be the best
solution with minimal impact (I only need one network socket).
Or is there a simple way to convert the sound output socket to a network
socket with minimal damage?

For users without a Q68, QBOX's FidoNet technology network utilities might
be a better way to exchange files without having to log in to a BBS and
manually downloading each file. I'll upload them asap. This way you could
transfer files by putting them on hold as attachments and use POLL/MAIL to
get them off the BBS. Oh well, I first thought the FidoNet utils would be
useless these days but now there still seems to be a use case for them :-).

Jan
-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-02 Thread Jan Bredenbeek via Ql-Users
On Mon, 2 Mar 2020 at 13:10, Fabrizio Diversi via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Yep, it is pretty cool.
>
> I am already using it to update files on different Ql machines.
>

It's definitely a solution to transfer files from emulated environments to
a BBQL if you can't use floppydisks or QL-SD.


> What I think is under estimated and not fully understood it is the
> possibility to use  Qbox not only with emulator that have tcp/ip built
> in but also by BBQL, Q6x with Simulant retro WIFI Rs232 adapter. The
> adapter is a very small box that connect to SER1 (powered by usual phone
> mini usb)
>

I personally use a Linux machine or Raspberry Pi with tcpser and a
USB-to-serial converter to exchange files to my BBQL. It has Hermes fitted
so the theoretical speed would be 19200 bps. In practice, your mileage may
vary depending on whether flow control (CTS/RTS) is working on your serial
link. Please read the QL-client.md file on the GitHub repository for more
info on how to use a BBQL.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] QBOX BBS for TCP/IP released!

2020-02-29 Thread Jan Bredenbeek via Ql-Users
 On this (Quantum) Leap day, I proudly present the re-release of QBOX. And
not just the version that's been laying around for years in scattered
files, but a complete ready-to-run WIN container that works over TCP/IP on
QPC2, SMSQmulator and UQLX! It also contains the complete QL file archive
of my BBS from 1987 to 2003, which is about 48MB.

You can find the complete repository (including source files) on GitHub:
https://github.com/SinclairQL/QBOX . Just download the QBOXRUN.ZIP file,
unzip it in the directory where your .WIN files reside, and make win8_
point to the QBOXRUN.WIN container. Enter EX win8_QBOX;'-D win8_' (or
PROG_USE win8_ followed by EX QBOX) and then telnet to the machine where
your BBS runs *on port 5000*.
N.B.: The default login and password are 'Sysop' and 'QBOX' [image: ;)]

Happy BBS'ing!

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.35

2020-02-08 Thread Jan Bredenbeek via Ql-Users
On Sat, 8 Feb 2020 at 06:47, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Brian, Jan
>
> Strangely enough, I can't reproduce the version problem here.
>
> To be extras sure, I downloaded the version uploaded yesterday and
> tested them of Q68 and QPC.
>
> All files should have the date of 07.02.2020 06:41 and, at least here,
> correctly identify as 3.35.
>

My fault - I copied the SMSQE.bin file to the wrong directory :-/


> > Speaking of the Q68, it appears that the SER_ commands like SER_BUFF
> > etc. still don't work. I discovered some months ago that this is caused
> by
> > an incorrectly named Thing ('ser_prt' while the SBASIC commands search
> for
> > 'ser_par_prt'). I'm not sure whether I've reported it here (I did so in
> the
> > QL forum but Wolfgang doesn't read that).
>
> I don't remember seeing it, but thanks - that'll be fixed in a new version.
>

Thanks in advance.

> So far I haven't been able to fix
> > this myself as SMSQMake stops with an 'invalid name' error at line 11330
> > when I try to build it.
>
> Load the menu extensions first, then it will work. I'll probably remove
> that anyway, but I'll have to check first if I use other parts of the
> menu extensions.
>

Okay, it assembles well now, thanks.


> > Another issue I've run into is the TCP device which, unlike UQLX, doesn't
> > report EOF when the other end has closed the connection, you'll just keep
> > waiting forever for input. (Yes, I've been doing a few networking
> > experiments lately, you'll see the results soon :-) ).
> >
>
> On what machine? (I presume SMSQmulator and will check).
>

It definitely does on QPC2 but I remember SMSQmulator had the same problem.


> > Well so far for the bug reports, thank you Wolfgang for keeping SMSQ/E
> > alive!
>
> Luckily enough, I'm not alone in that. Simply building SMSQ/E is now a
> fairly well automated process (SMSQEMake - when it works...) and making
> all of the new version files is, too - see the file "new_versions_bas"
> in the extra directory - it even makes the html files (I once even
> had the idea of building an ftp client, so that the upload to my site
> could be made automatically, but never actually started that,the main
> reason being that I know next to nothing about networking, let alone the
> ftp protocol).
>

And ftp is rather obsolete now and considered insecure :-).
I'm nearly finished implementing the Telnet protocol for QBOX, but I should
really have had to implement SSH with AES-256 and 4096-bit keys :(.
Fortunately there is an easy way to let the host OS do the SSH stuff and
forward the plain text to QBOX using Telnet.


> What is much more important than the build process is the people who
> make changes to SMSQ/E or find (and report!) bugs.
>
> Keep on QLing! (Somehow "keep on SMSQ/Eing" doesn't have the same ring
> to it).
>

Well, "keep on QDOS'ing" also doesn't sound very well, a bit too much like
"keep on DDOS'ing" :-)

Jan
-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.35

2020-02-07 Thread Jan Bredenbeek via Ql-Users
On Fri, 7 Feb 2020 at 17:49, Brian Kemmett via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Wolfgang.. Just downloaded and installed the latest SMSQE... A
> question.. When I ask the version (Ver$(1)) it prints "3.34" and not
> "3.35", even though the download file is named smsqe/335/SMSQE.bin.zip.
>

Interestingly, on QPC2 it reports 3.34 although the SMSQE.bin file is
slightly (20 bytes) larger. But the Q68 version reports 3.35.

Speaking of the Q68, it appears that the SER_ commands like SER_BUFF
etc. still don't work. I discovered some months ago that this is caused by
an incorrectly named Thing ('ser_prt' while the SBASIC commands search for
'ser_par_prt'). I'm not sure whether I've reported it here (I did so in the
QL forum but Wolfgang doesn't read that). So far I haven't been able to fix
this myself as SMSQMake stops with an 'invalid name' error at line 11330
when I try to build it.

Another issue I've run into is the TCP device which, unlike UQLX, doesn't
report EOF when the other end has closed the connection, you'll just keep
waiting forever for input. (Yes, I've been doing a few networking
experiments lately, you'll see the results soon :-) ).

Well so far for the bug reports, thank you Wolfgang for keeping SMSQ/E
alive!

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Magazine Articles page

2019-11-26 Thread Jan Bredenbeek via Ql-Users
On Sun, 24 Nov 2019 at 14:50, Dilwyn Jones via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Pleased to announce a new page containing scanned magazine articles.
> Thanks to the work of individuals like Klaus Frank who've been busy
> scanning articles for me, the first draft of the page is ready with a few
> articles from various magazines.
>

Great!  However I noticed that
http://www.dilwyn.me.uk/docs/magarticles/ComputerShopper/ShopperApril1988.pdf
is
a dead link. After a bit of URL guessing I found out that the correct link
is
http://www.dilwyn.me.uk/docs/magarticles/ComputerShopper/sinclairsceneapril1988.pdf
 .

regards, Jan.
-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Q68 serial buffers

2019-06-25 Thread Jan Bredenbeek via Ql-Users

On 22-06-2019 21:30, Jan Bredenbeek wrote:
I also noticed that the SER_BUFF command which can be used to set the 
buffer size in SMSQ/E is present in the Q68 version, but it always 
gives a 'not found' error message irrespective of the arguments I 
specify.

Is this a bug or a 'feature''?

Jan.

--
*Jan Bredenbeek*| Hilversum, NL | j...@bredenbeek.net 
<mailto:j...@bredenbeek.net>


Found the bug. All the SER_* commands set the parameters through a Thing 
called 'ser_par_prt'. However, in the Q68 version it is called 'ser_prt' 
for some reason (because the Q68 has no PAR prt?). So the SER_* commands 
cannot find the Thing anymore.
Now the next challenge is to rebuild SMSQ/E (for some reason SMSQEMake 
crashes at line 7810 with a 'not found' error).


Jan.

--
Jan Bredenbeek | Hilversum, NL | j...@bredenbeek.net

___
QL-Users Mailing List


[Ql-Users] Q68 serial buffers

2019-06-22 Thread Jan Bredenbeek via Ql-Users
 I've been doing some tests with the Q68's serial port.

It's well known that it doesn't support flow control. So this means that if
you receive data at, say, 38400 bps or higher, you need a buffer large
enough to hold all the incoming data to give the Q68 a chance to digest it
(for example to write a BBS page to the screen or save a block to SDcard).
I know that the Q68 uses external interrupts to transfer incoming data from
the UART to the input buffer so this shouldn't be a problem as long as the
buffer is large enough.

I noticed that at 38400 bps, the Q68 could keep up with a page of ANSI-BBS
graphics in QL MODE 4, but missed out in display mode 6 (512x384x65536). So
I'm wondering what the size of the Q68's input buffer is under SMSQ/E.

I also noticed that the SER_BUFF command which can be used to set the
buffer size in SMSQ/E is present in the Q68 version, but it always gives a
'not found' error message irrespective of the arguments I specify.
Is this a bug or a 'feature''?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QMac source code

2018-12-14 Thread Jan Bredenbeek via Ql-Users
On Fri, 14 Dec 2018 at 10:52, Marcel Kilgus via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Jan Bredenbeek via Ql-Users wrote:
> > QLINK has some serious issues compared to the GST version. The symbol
> table
> > dump in the _MAP file looks strange and the generated binary output file
> is
> > not executable.
>
> I've used QLink 1.03 for years on many many projects including SMSQ/E
> without any problems. You need to supply the FILETYPE option on the
> command line or linker file if you want the result to be executable.
>

I know I should have read the docs (and use CONFIG) 

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] QMac source code

2018-12-13 Thread Jan Bredenbeek via Ql-Users
On Thu, 13 Dec 2018 at 08:37, Urs Koenig (QL) via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Marcel wrote:
> > Does anybody know who has the source code to QMac? The Quanta version
> > doesn't look like simple patches to the GST binary, so I guess somebody
> must
> > have had it at some point. I'd like to make a few small updates myself.
> From my records Phil Borman maintained the QUANTA edition of QMAC (latest
> version 1.06) and QLINK (latest version 1.03). From memory I've met Phil at
> one of the QUANTA workshops in the early 1990s.
>

QLINK has some serious issues compared to the GST version. The symbol table
dump in the _MAP file looks strange and the generated binary output file is
not executable. I tested with v1.01 (from Dilwyn's archive) and v1.03 from
QLE 3.18.

Jan.
-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.34

2018-12-03 Thread Jan Bredenbeek via Ql-Users
One small issue for Q68 users: the file Q68_SMSQ.WIN is incorrectly named
Q68.SMSQ.WIN.
Also the SMSQE binary in this container is standard configured for German
keyboard layout, which is a bit of a challenge to find the underscore
character if you have US or UK keyboard (it's on the key left beside the
right shift key).

Jan.

On Sat, 1 Dec 2018 at 09:39, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> problem solved...
>
> Have fun.
>
> Wolfgang
> > Hi,
> >
> >
> >>> I tried to download the binary zip which the web site says temporary
> >>> unavailable.
> >>>
> > sorry about that, it's fixed now.
> >
> > I changed the website yesterday so that it would be reachable via https
> > instead of http.
> > Whenever I make a new version of smsqe, I have a small utility that
> > makes an index.php file automatically, I then just have to copy that to
> > the website.
> >
> > For some reason which I haven't had time to figure out, since the change
> > from http to https, I can no longer use the index.php file, but need an
> > index.html file. So I remade the html file by hand - and somehow
> > introduced a wrong link. I **thought** I had checked them all out...
> >
> >
> > Regards
> >
> > Wolfgang
> > ___
> > QL-Users Mailing List
> >
> >
> ___
> QL-Users Mailing List
>


-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2018-10-09 Thread 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.
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?
In Windows (and probably Unix too), when you copy a file the creation date
on the copy will be set to the date it was copied but the update date will
be the same as the original (at least when using cp -p on Unix). Thus when
you copy a file which was last changed 20 years ago, the update date on the
copy will be 20 years behind the creation date!

It's a pity that many copy utilities (like TK2's WCOPY and IIRC QPAC2's
File utility) don't preserve the update date when copying files. Many of my
source files I lastly touched more than 30 years ago got their time stamp
smashed to somewhere in the new millennium :-(.
(Yes I know you need V2 drivers to avoid this, but these have also been
around since 1990 or so).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] QED v2.02 released

2018-10-03 Thread Jan Bredenbeek via Ql-Users
 QED v2.02 has been released and can be downloaded here
<https://github.com/janbredenbeek/QED/releases/download/v2.02/QED202.ZIP>.

New features


- The RC command can now be used to load a file in cooked mode. It is
equivalent to the R command, except that CR/LF line endings are converted
to LF and TABS compressed or expanded according to the TAB compression
and expansion settings.
Note that both R and RC commands currently do not accept a filename
containing spaces as parameter. These files can be loaded by using the R
or RC command without a parameter and then entering the file name at the
'File Name:' prompt.

- Help file didn't mention the F6 key (toggle Auto Indent), F7 key (toggle
Word Wrap), F9 key (toggle TAB expansion), and F10 key (toggle TAB
compression). Their status is now shown in the status line.

- The manual has (at last!) been updated for version 2.

Bug fixes
-

- Using the R command without a file name caused QED to crash with an
invalid file name. It now asks for the file name as expected.

- After using the QF or XF command, the status line was garbled.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] File header info

2018-09-28 Thread Jan Bredenbeek via Ql-Users
On 28 September 2018 at 11:01, Giorgio Garabello via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> on dbas manual i've found an alternative description of the header..
>
>Type  Length   Name  Contents
>2 -LENGTHFile Length
>1 -TYPE  File access *256+ file type
>2 -DATA  Dataspace size - EXECutable type
>2 -OFFSETGST Linker "OFFSET" value
>0 36 char  NAME$ File name
>2 -UPDATEUpdate date
>1 -VERSION%  Version number
>1 -FILE% File number
>2 -BACKUPBackup date (not used)
>
> I'm more and more confused…. :-(


The longword at $0A is spare and can be used by applications to store extra
info (it can be read using the TK2 FXTRA function).
The word at $3A is the file id used in QLWA-type container files.

There is an excellent explanation of this format by Norman Dunbar:
http://qdosmsq.dunbar-it.co.uk/doku.php?id=qdosmsq:fs:qlwa

Jan

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

[Ql-Users] QED v2.01 released!

2018-09-25 Thread Jan Bredenbeek via Ql-Users
 I'm very pleased to present you release 2.01 of QED, my ever popular text
editor!

This release comes exactly 30 years after version 1.01, which has been
included in many QL software distributions.
New features include:

* Support for TK2 Data Default directories
* Editing multiple files simultaneously
* Auto-indenting of lines
* TAB compression and expansion supported
* Raw and cooked LOADing and SAVing of files for CR/LF conversion
* Can be configured for high-resolution screens (the standard configuration
will fit in 512x256 [image: ;)] ).

The HELP file has been updated to include the new commands. There is no
updated manual yet - you can use the Quill document in the 1.01 archive (I
still need to convert it to a more common format).

The .ZIP file containing the binary, help file and configuration program
can be downloaded from my GitHub page
<https://github.com/janbredenbeek/QED/releases>. As usual, the source code
is available from this repository and on the SinclairQL GitHub page.
Maintainers of QL software distributions are encouraged to update their
versions too.

Happy QL'ing,

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Odd behavour of the DIR command?

2018-07-26 Thread Jan Bredenbeek via Ql-Users
This has always been the problem with substitution devices. One solution
would be to rewrite the io.fstrg/fs.headr/etc code to substitute the
filenames read as well (essentially chop off the directory path
substituted). In case of io.fstrg this means checking if the channel is
opened for directory access, then check if the data read would be a file
header (length=64), then change the filename read accordingly. In your own
example when using INKEY$ from BASIC this would fail because INKEY$ reads
one byte at a time (using io.fbyte).

Another solution would be to make the DIR command 'substitution-aware' so
it would recognise a substituted device and act accordingly. I've written a
S*BASIC 'ls' like command (see
https://github.com/janbredenbeek/QL/tree/master/SBASIC) which has
implemented this (and it lists the contents of substituted subdirectories
correctly).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Jan Bredenbeek via Ql-Users
On 21 June 2018 at 15:21, Dave Park via Ql-Users 
wrote:

> > SuperBASIC is quite unique in that it stores the *difference* in length
> of
> > a line compared to the previous line, along with its line number. This
> way,
> > because the current line length is also stored in a system variable, it
> can
> > search for lines in both backward and forward direction. So a proc/fn
> call
> > will be faster when the definition is closer to the calling line. This is
> > also mentioned in the Minerva documentation.
>
> ​Hmmm. Are they stored in a known order, eg: alphabetical or order of
> creation/declaration
>

They are stored in order of line number (it's Basic, after all...).


> > You cannot define a proc/fn multiple times but you can check the type and
> > usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
> > functions in TK2 and act accordingly. An example of this is in my 'ls'
> > procedure which uses an extra parameter as a flag for recursive directory
> > searches. When this parameter is empty it only lists the current
> directory.
>
> ​I suppose it does reduce these stresses that while sBASIC has "strict"
> typing of variables, it allows easy transfer between variable types.​ It
> also has the concepts of undefined variables and defined but unset
> variables.
>

It's not as strict as it seems. What's also unique in S*BASIC is
'coercion'. You want to assign a numeric value to a string variable and
S*BASIC will happily do this, by converting the number to a string (in
other BASICs you would have to use STR$). And the other way round assign a
string value to a numeric variable (provided the string contains a valid
number).
The type of a parameter in a procedure or function is determined when the
function is *called*, not when it's defined. In a machinecode function you
can find out what type a parameter is and choose to evaluate it as a
number, string or name (in a BASIC function you can use the four TK2
functions mentioned above though you're probably a bit more restricted by
parameter types).
Also, variables are never undefined (they're defined as soon as you enter
their name in a program line) but they can be unset...


> Quite amazing for a language that fit in a very small part of 48K.


 And all written in 68K assembler in a few weeks time...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Jan Bredenbeek via Ql-Users
On 21 June 2018 at 00:43, Dave Park via Ql-Users 
wrote:

> My reason for asking was, I was wondering if an analysis of how frequently
> functions were called, and from where, could affect how quickly they would
> be stepped to. I have seen this behavior in SuperBASIC on JM/JS and
> achieved often useful gains in improvements by placing the most frequently
> called functions at the beginning or the program.
>

SuperBASIC is quite unique in that it stores the *difference* in length of
a line compared to the previous line, along with its line number. This way,
because the current line length is also stored in a system variable, it can
search for lines in both backward and forward direction. So a proc/fn call
will be faster when the definition is closer to the calling line. This is
also mentioned in the Minerva documentation.


> I was wondering if this was still true with the BASIC on SMSQ/Minerva.
>

AFAIK, Minerva is not very different in the way data structures are stored
compared to Sinclair ROMs, but SMSQ is.


> That let to the overloading question, which would allow the collapsing of
> many functions into a single function using polymorphism.
>

You cannot define a proc/fn multiple times but you can check the type and
usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
functions in TK2 and act accordingly. An example of this is in my 'ls'
procedure which uses an extra parameter as a flag for recursive directory
searches. When this parameter is empty it only lists the current directory.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-20 Thread Jan Bredenbeek via Ql-Users
On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?


SuperBASIC (JM/JS/Minerva) stores line numbers along with proc/fn names in
the name table and can search backward and forward for them in the program.
So it merely depends on how far away the proc/fn definition is from the
calling code in terms of lines.
I don't know how SBASIC handles this but as it is said to be more a
compiler than an interpreter it could be very well different (the most
efficient way would of course be to store addresses rather than line
numbers but this could break if the program is changed and then
CONTINUEd/RETRYd).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QA.RESRI info incorrect

2018-06-08 Thread Jan Bredenbeek via Ql-Users
On 8 June 2018 at 15:52, pjwitte via Ql-Users 
wrote:

> When loading this into RESPR and then doing CALL base+4 I get an
>> 'insufficient memory' error. But PEEK_L(base) returns 0 so the code never
>> got to the point where it stores the result.
>>
> Sure, but this is not the whole story. For example when I ran your code
> just now in a daughter SBASIC, with no free memory, it returns ok, but
> peeking result I get an err.ipar!
> Depending on circumstances, there are a number of possible paths this
> routine can take. From my own investigations (I wish Id written up what I
> did, not only the conclusion!) in some cases this routine forgets to set
> error code on a successful return.


Well the source code starts in
https://github.com/SinclairQL/SMSQE/blob/master/smsq/sbas/ressb_asm at line
40 (actual entry point at line 46):

;+++
; reserve stage posts SuperBASIC d1 bytes (optional), d1/d2/d3 smashed
;---
sbs_rar32
moveq #32,d1 ; the order of these instructions
; ; is critical for compatibility
moveq #sb_arthp,d2 ; with some QL software
bra.s sbs_dn

Then it jumps via a long jump to sbr_dn:

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
Somehow the test for SBASIC at sb_flag(a6) failed and the routine returned
at sbr_nop, leaving D0 unmodified. Since on entry to a CALLed routine it
contains -15 (err.ipar), this is probably what happened.
Strange enough, when I tested this on a SBASIC daughter job, I got the same
result as before ('insufficient memory', no normal return), even when
running the commands in a program.
So when does the test for sb.flag at sb_flag(a6) fail? I think it's
probably a test for compiled (i.e. Qliberated or Turbo'ed) SBASIC?

Jan.

(I hope the assembly listing is readable, I copy-pasted them from GitHub).

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QA.RESRI info incorrect

2018-06-08 Thread Jan Bredenbeek via Ql-Users
On 8 June 2018 at 13:26, pjwitte via Ql-Users 
wrote:

It appears that, on an error, QDOS doesnt return here at all!
>

Correct.


> Under SMSQ/E it may return an error (IMEM), but the error code is not
> always set! That implies that you could get a wrong result, depending on
> what was in D0 before the call.
>

I've tested this earlier using this code on SMSQmulator:

result   dc.l 0
 move.l   #16*1024*1024,D1
 move.w   $11a,a2
 jsr  (a2)
 lea  result(pc),a1
 move.l   d0,(a1)
 moveq#0,d0
 rts

When loading this into RESPR and then doing CALL base+4 I get an
'insufficient memory' error. But PEEK_L(base) returns 0 so the code never
got to the point where it stores the result.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread Jan Bredenbeek via Ql-Users
On 29 March 2018 at 11:40, Dilwyn Jones via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> I regret to have to report that I heard this morning of the death of
> Stuart Honeyball of Miracle Systems.
>
> He passed away peacefully last night (28th March) at 23:45 of cancer,
> according to his wife, Karin.
>
> I’m sure you’ll all want to join me in extending our condolence to his
> wife and family and express our great admiration and gratitude for all the
> work he did for the QL over the years.
>

Very sad news :(

He and his colleagues came to Eindhoven many times, sometimes even on
folding bikes backpacked full of Gold Cards.

My condolences to his family, the QL community will remember him as the
Miracle guy who gave the QL a second life...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] Sjef vd Molengraaf

2018-03-09 Thread Jan Bredenbeek via Ql-Users
On 9 March 2018 at 16:35, Bob Spelten via Ql-Users <ql-users@lists.q-v-d.com
> wrote:

>
> I am sad to inform you all that Sjef van de Molengraaf passed away earlier
> this week at the age of 73.
> As long time secretary of the Dutch SIN_QL_AIR foundation he will be
> remembered by many international QL'ers. He was the driving force behind
> many great Eindhoven meetings during the 90's and later, until they ended
> in October 2008.
> He seldom posted on this list but it kept him informed of what was going
> on in the QL community.
>
> Our thoughts are with his family.
>

Very sad to read this :(
I still got Christmas wishes from him every year.
The international QL community owes him a lot. Tony Tebby, Nasta, Jochen
Merz, Tony Firshman, Laurence Reeves and many other QL VIPs, without Sjef
there wouldn't have been such great opportunities to meet them.

May he rest in peace.

Jan Bredenbeek.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2018-02-16 Thread Jan Bredenbeek via Ql-Users
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.

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).

Does anyone have a clue?

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

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

2018-02-15 Thread Jan Bredenbeek via Ql-Users
On 15 February 2018 at 11:45, pjwitte via Ql-Users <ql-users@lists.q-v-d.com
> wrote:


> 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
>

Correct as far as I can see.


> 2) Is D0 set to 0 after BV_CHRIX?: JS: No. Minerva & SMSQ/E: Yes
>

Correct. I've done a short test on SMSQmulator to see if it does return
from an 'out of memory' condition (assumed it has no more than 16 MB
available):

result   dc.l 0
 move.l   #16*1024*1024,D1
 move.w   $11a,a2
 jsr  (a2)
 lea  result(pc),a1
 move.l   d0,(a1)
 moveq#0,d0
 rts

When I LBYTES this followed by CALL A+4, I get 'insufficient memory'. The
long word at 'result' was still zero afterwards. So it doesn't return when
an error occurs (unlike other claims).


> 3) Are items on the stack preserved after BV_CHRIX (as described above)?:
> JS, Minerva & SMSQ/E: Yes
>

Yes, but don't forget to set BV.RIP(A6) to current TOS beforehand. The
Minerva doc says that only the active part of any area is moved (unlike
JS). So anything below BV.RIP(A6) that is still part of the RI stack area
will not be moved (and probably overwritten).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2018-01-06 Thread Jan Bredenbeek via Ql-Users
On 5 January 2018 at 22:33, Dave Park via Ql-Users <ql-users@lists.q-v-d.com
> 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


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

2018-01-05 Thread Jan Bredenbeek via Ql-Users
On 5 January 2018 at 15:49, 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


FB - Full of Bugs (has anyone this ROM around? Would be a collector's item
;-))

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

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

2018-01-02 Thread Jan Bredenbeek via Ql-Users
Hi Norman,

On 31 December 2017 at 19:43, Norman Dunbar via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Happy New Year one and all.
>
> I started pcb design a while back too. I use Fritzing and/or Kicad for
> mine. Manually routing a pcb can seriously use up a good few hours of your
> life! But it's [still] fun.
>
> I will probably live to regret this but, let me know how/where to get the
> DISA source and I  will take a look and try to understand it. I must say in
> advance that time, as ever, is probably limited as my wife and I are in the
> middle of dealing with a severe case of dementia affecting my mother in
> law. This, as you can imagine, is a bit of a time killer, and the worst of
> it is, she'll never get better.
>

I'm sorry to read this. Well we've come a long way already commenting
MultiMon so DISA would be a nice GitHub project to do next ;)

Best wishes for 2018,

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2017-12-28 Thread Jan Bredenbeek via Ql-Users
On 28 December 2017 at 13:10, Wolf via Ql-Users <ql-users@lists.q-v-d.com>
wrote:

> Hi,
>
> ok,  ok, but I didn't even use the word "odd"!
>

:)

In any case, if you jump to an odd location (whether strange or not even)
on a QL you will usually be in big trouble...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2017-12-28 Thread Jan Bredenbeek via Ql-Users
On 28 December 2017 at 12:59, Wolf via Ql-Users <ql-users@lists.q-v-d.com>
wrote:

>
> Hi,
>
> To my mind, a "jump to a strange address" is not an address error which
> would give rise to that exception.


He he that's a language thing :). 'Odd' in English can mean 'strange' but
also 'not even'. What I meant was the latter of the two so it really should
have been an address error...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


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

2017-12-28 Thread Jan Bredenbeek via Ql-Users
On 28 December 2017 at 07:43, Wolf via Ql-Users 
wrote:

> Hi,
> yes that's a bug.
>
> Somehow the return stack gets confused/overwitten (stack overflow!),
> causing a jump to a strange address where you then will get an illegal
> instruction error.
>
>
> I've checcked that, under SMSQmulator this isn't due to the replacemnt FP
> routines, which it isn't.
>
> On the Q68 it also freezes, but other jobs keep running (probably with
corrupted OS).
It looks like the processor in the Q68 behaves somewhat differently, as I'm
unable to get an address error exception even when jumping to an odd
address...

Jan.
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

2017-11-14 Thread Jan Bredenbeek via Ql-Users
On 14 November 2017 at 13:03, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> yes Jochen told me on sundcay that it's OK to be distributed.
>

Great, now I can finally convert my programs to use the QL config standard
rather than having to write my own :).
(I've always found the user interface of the standard config program a bit
awkward to use...).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

2017-11-14 Thread Jan Bredenbeek via Ql-Users
On 13 November 2017 at 18:27, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> 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.
>

I'm wondering whether menuconfig is now freeware or not. According to this
thread http://qlforum.co.uk/viewtopic.php?t=1025 it is still commercial
software by Jochen Merz. Does anyone have an idea?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Jan Bredenbeek via Ql-Users
On 27 October 2017 at 21:51, Peter Graf <pg...@q40.de> wrote:

> I just noticed the work was in vain, because SMSQ/E does not seem to
> support FLASH in MODE 8. At least not if I test with SBASIC.
>

Indeed SMSQ/E on a QL with Gold Card doesn't flash :(.
It also seems to work only when PRINTing something, not with graphics
commands (even not with BLOCK and CIRCLE).
It should be fairly easy to implement when PRINTing text since only the
flash bit of the first and last pixel of the printed pattern in each line
has to be set.

I've written it myself back in the '80s in a Videotex terminal program.
Since this uses block graphics which use the full 6x10 character matrix I
couldn't use the QL's screen driver and had to write one myself. One of the
challenges indeed was to implement flash when there was no 'spare' pixel
available for the background colour (which could occur in 'graphics hold'
mode) - in that case the only option was to clear the leftmost pixel which
was a slight deviation from the standard, but fortunately very rarely
visible.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Jan Bredenbeek via Ql-Users
On 27 October 2017 at 21:03, Peter Graf <pg...@q40.de> wrote:

> > E.g. when a pixel has red colour with flash on, the rest of the pixels
> > on the line will flash between the original pixel colour and red until
> > the next set flash bit.
>
> The "until" is ambiguous. When that next pixel occurs, does it still use
> the background colour of the previous pixels, or already the colour in
> it's own colour bits?
>

The flashing is up to and including the pixel which has the flash bit on to
turn flash off.
This can be seen when PRINTing something with flash on. Each character is 6
bits wide, but only the least significant ('rightmost') 5 bits are used as
the leftmost bit is always 0. This is the bit used to turn flash on, and
when flash is on the flash bit of the LSB (rightmost) bit is also on so
flash is turned off after each character (even when you print multiple
characters on the same line).


> Also, is there any exact info about the blink frequency?


I've tested this on a real QL and it looks like the blink frequency is
16/50th of a second which is a bit slower than the software-generated
blinking of the window's cursor (12/50th second). So a complete blink cycle
will be 32/50th second.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Jan Bredenbeek via Ql-Users
On 27 October 2017 at 19:01, Peter Graf via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> today I noticed that my MODE 8 Flash Bit implementation in the Q68 was
> never completed. It is 11 years ago that I designed the video
> controller, and now I don't even remember how exactly the QL hardware
> used that bit at all. Especially, I don't know how the background colour
> for the flashing area is determined!
>
> Could anyone enlighten me? Quick reply would be nice, release date
> nearing quickly...
>
> It works in a serial fashion, much like the old Videotex/Prestel standard.
When you set the flash bit on a pixel, the colour of that pixel is used as
background flash colour for the rest of the line until another flash bit on
the same line is encountered.
E.g. when a pixel has red colour with flash on, the rest of the pixels on
the line will flash between the original pixel colour and red until the
next set flash bit.
It does not propagate across pixel lines so at the beginning of a pixel
line flash is always off.

Hope you'll find this useful.

Regards, Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Stupid AND

2017-09-19 Thread Jan Bredenbeek via Ql-Users
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

Re: [Ql-Users] Stupid AND

2017-09-19 Thread 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


Re: [Ql-Users] Maximum length of files on QL file-system

2017-07-23 Thread Jan Bredenbeek via Ql-Users
On 23 July 2017 at 15:47, Andrea Carpi via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>   Hello everybody
>
> Trying to transfer large files between Windows 10,
> QPC2, and QL-Aurora-SGC-Qubide I have noticed that there are big
> limitations in the maximum length of the files.
>
> I mean:
> - On QXL.WIN
> hard drive in QPC2 I'm not able to generate files longer than 50Mb (End
> Of file error)
> - On the Qubide hard drive the limit is 19Mb (ROM 2.01),
> but perhaps also depends on the partition creation choices
>
> - On Ram
> Disk (in QPC2 maximum RAM 128 Mb) I did not find any limits unless the
> size of the RAM
> - I did not find limits on DOS devices from QPC2 except
> those of the file system in use on Windows (NTFS)
>
> Specifically for
> QXL.WIN and QUBIDE do anyone know the exact length limits and
> why?
>

The QDOS file system stores the file position in the channel definition
block as two 16-bit words - one for the block number and one for the byte
position within one block. So, when using 512-byte blocks, the maximum file
length will be 65535*512 bytes or just under 32MB (or 16MB when using
signed arithmetic). When using 2K byte blocks, the limit will be 128 or
64MB respectively.

I know mdv and flp use 512-byte block size and ED flp have 2K byte sectors
but I'm not sure if the latter also uses 2K blocks. The same goes for
(virtual) win drives - sectors are usually grouped to keep the map within
limits but I don't know off-hand if that also affects the block size (it
might as well be 512 bytes, depending on the driver).

This use of word-sized block numbers within QDOS is an unfortunate design
flaw - as is the standard FS.MDINF trap which returns word-sized sector
counts - but could TT back in 1984 foresee that within five years there
would be a storage medium for the QL that surpassed the 32MB limit? In the
PC world there are multiple examples of this - remember the 32MB partition
size limit in DOS 3.3, then the 528MB limit on CHS-addressed hard disks,
and the initial 128GB limit on LBA which was supposed to 'fix' CHS.

Storage capacity has grown so much that any 'X MB ought to be enough for
everybody' design decision has proven wrong eventually...

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QL Forum online chat

2017-05-15 Thread Jan Bredenbeek
On 15 May 2017 at 12:35, Graeme Gregory <gra...@xora.org.uk> wrote:

>
> And to answer original question, the headers are intact and show it
> passing through yahoo.com SMTP server so its route matches its From:
> address.
>
> If you look at the headers your spam filter should tell you why it
> selected an email as spam.


There are a lot of headers but this is probably the interesting part:
(I use Gmail on my own domain)

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=neutral (body hash did not verify) header.i=@yahoo.com;
   spf=neutral (google.com: 69.163.254.50 is neither permitted nor
denied by best guess record for domain of
ql-users-boun...@lists.q-v-d.com)
smtp.mailfrom=ql-users-boun...@lists.q-v-d.com;
   dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yahoo.com
Return-Path: <ql-users-boun...@lists.q-v-d.com>
Received: from diego.dreamhost.com (diego.dreamhost.com. [69.163.254.50])
by mx.google.com with ESMTPS id o3si6247470pld.210.2017.05.13.12.18.44
for <j...@bredenbeek.net>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Sat, 13 May 2017 12:18:44 -0700 (PDT)
Received-SPF: neutral (google.com: 69.163.254.50 is neither permitted
nor denied by best guess record for domain of
ql-users-boun...@lists.q-v-d.com) client-ip=69.163.254.50;
Authentication-Results: mx.google.com;
   dkim=neutral (body hash did not verify) header.i=@yahoo.com;
   spf=neutral (google.com: 69.163.254.50 is neither permitted nor
denied by best guess record for domain of
ql-users-boun...@lists.q-v-d.com)
smtp.mailfrom=ql-users-boun...@lists.q-v-d.com;
   dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yahoo.com

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QL Forum online chat

2017-05-15 Thread Jan Bredenbeek
On 13 May 2017 at 21:18, Dilwyn Jones <dilwy...@yahoo.com> wrote:

> This is unplanned and short notice, sorry, seven of us are already on
> Online chat tonight (now) if anyone else would like to join in!
>

Didn't miss it, but your mail ended up in my spam box (which happens with
more of your mails). Are you sending mail with a Yahoo-address from Yahoo
itself or through your own server?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Graphics aspect ratio

2017-05-01 Thread Jan Bredenbeek
On 1 May 2017 at 15:04, Andrea Carpi  wrote:

>
> Il 28/04/2017 16.01, Marcel Kilgus ha scritto:
>
> > I added that
> feature at the request from Jens who paid for the development of the
> 8-bit driver. It was at a time when the SMSQ/E documentation was pretty
> much unmaintained...
>
>  Is there a complete list of system variables in
> SMSQ / E 3.xx?
>
> It's not a system variable but a variable in the CON device driver linkage
block. The list of variables is in the SMSQ/E source code tree (in the
keys/con file).

Jan.
___
QL-Users Mailing List


Re: [Ql-Users] Graphics aspect ratio

2017-05-01 Thread Jan Bredenbeek
On 1 May 2017 at 12:08, Tobias Fröschle 
wrote:

> Jan,
>
> SMSQ/E change log (http://www.wlenerz.com/smsqe/versions.html <
> http://www.wlenerz.com/smsqe/versions.html> , which comes in handy at
> times) says
> Implemented in 3.00
>

Thanks. I've taken a look at the changes.txt in the source and couldn't
find anything initially, however a search for 'aspect' revealed it was
implemented in 3.03.

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

2017-05-01 Thread Jan Bredenbeek
On 28 April 2017 at 16:01, Marcel Kilgus  wrote:

> > Am 28.04.2017 um 15:30 schrieb Tobias Fröschle <
> tobias.froesc...@t-online.de>:
> >
> > Right. Somewhere there ;)
> >
> > I seem to recall I saw that variable referenced somewhere in the
> "official" documents - But when I looked for it, I couldn't find it either
> and had to refer to the sources as well
>
> I added that feature at the request from Jens who paid for the development
> of the 8-bit driver. It was at a time when the SMSQ/E documentation was
> pretty much unmaintained...
>

From the code of G-RATIO I gather that it only exists in v3.x versions of
SMSQ/E (else it returns 'not implemented'). Can you confirm this?

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

2017-04-28 Thread Jan Bredenbeek
Thanks for the answers! The variable pt_asprt is actually in the CON device
linkage block which is pointed to by the sys_clnk system variable (I
couldn't find it in the QDOS/SMS Reference Manual, only in the SMSQ/E
source code.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] Graphics aspect ratio

2017-04-28 Thread Jan Bredenbeek
I'm sorry if this question has been answered before, but I've run into an
issue with SMSQ/E's graphics system.
When you use the CIRCLE command on a window with an aspect ratio of, say,
3:2 (on the screen, not in pixels since the graphics coordinate system is
pixel-independent!) and type:

CIRCLE 75,50,50

you get a circle exactly in the centre of the window which exactly fits the
window in vertical direction (assuming standard SCALE setting of 100,0,0).
But when you enter this command on SMSQ/E, assuming a window with exactly
the same aspect ratio, the circle becomes an ellipse which partly falls off
the right edge of the window.

I'm aware of the fact that the native QL screen has non-square pixels (the
width/height ratio of a pixel is 0.738; combined with the 512x256
resolution this yields an aspect ratio of about 3:2 or 1.476 to be exact).
QDOS and Minerva compensate for this in the graphics routines so that the
scale in horizontal direction is the same as in vertical direction (the
Minerva source code is in fig.asm).
However, on PC-emulated screens pixels have a different aspect ratio (I
guess mostly 1:1). It appears that the graphics coordinate system on SMSQ/E
still tries to adjust for the native QL pixel aspect ratio, leading to
incorrect X/Y scale ratio on the graphics screen.
AFAIK there is no way to adjust for this error, short of changing
application programs. The SCALE command doesn't help, as there is only one
SCALE parameter that sets the scale for both X and Y directions.

Anyone got an idea?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E and unset variables

2017-04-24 Thread Jan Bredenbeek
On 24 April 2017 at 18:27, Dilwyn Jones <dil...@evans1511.fsnet.co.uk>
wrote:


> When SBASIC was first mooted, I remember that there was at the time
> discussion that other BASICs gave variables default zero value rather than
> stopping with an error - "why couldn't the QL do this?"
>
> Don't know if that influenced Tony Tebby to make SBASIC variables behave
> in this way or not, or was that just coincidence?
>

I've been struggling with this issue too when adapting the Spectrum's BASIC
for BASICODE, which was largely based on M$ BASIC. This allowed default
values for variables, which broke computers like the Spectrum and BBC. The
official BASICODE spec required proper initialisation of variables but this
was a common mistake among programmers that went undetected many times
because of poor testing before airing (obviously they used a C64 as testing
machine ;)). Since my adapted BASIC was expected to be used mainly to run
existing programs I decided to allow defaults (and leave out syntax checks
at entry too).

So, default variable values might probably be a good thing to run BASIC
programs converted from other platforms, but a bad thing when developing
your own.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Marcel has done it again - SMSQE 3.31

2017-04-11 Thread Jan Bredenbeek
On 11 April 2017 at 10:07, Derek Stewart <de...@q40.de> wrote:

Hi Marcel,
>
> Do you think it is possible for the SMSQ/E internal compiler produce a
> compiled version of the SBASIC programme?


You can EXEC a SBASIC program in the same way as a 'normal' executable
program on SMSQ/E (which actually starts another instance of SBASIC).
But the code produced by the real-time compiler is not real 68000 code but
pseudo-code and needs the SBASIC environment to work. So it cannot be a
stand-alone EXECable program unless the SBASIC runtime environment also
comes with it.
Nevertheless it would be a great idea if you could write a procedure in
SBASIC and LRESPR the compiled code as SBASIC extension so you have it
always available. AFAIK there is no higher-level language compiler capable
of producing SBASIC extensions - or perhaps Qliberator?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Marcel has done it again - SMSQE 3.31

2017-04-10 Thread Jan Bredenbeek
Hi Marcel,

On 10 April 2017 at 00:28, Marcel Kilgus <ql-us...@mail.kilgus.net> wrote:

> Wolf wrote:
> > Marcel has done it again - SMSQE 3.31 is out now.
> >
> > Marcel has fixed the LRESPR bug. LRESPRing sbasic extensions in a
> > procedure no longer crashes the machine.
>
> Thank you Wolfgang. I have actually written down part of the journey
> in fixing this bug, so if this sort of technical thing interests you,
> here it is:
>
> https://www.kilgus.net/2017/04/10/sbasic-bug-boogie/
>
> It includes a rough description of how SBasic works internally, partly
> so I can read it myself if I ever need it again. The rest I still
> consider pure Voodoo ;-)
>

I've been doing a lot of disassembling on the original QL ROM but
understanding the SuperBASIC parser was a bridge too far for me, so I found
it a very interesting read. It raises one question though - is SBASIC an
interpreter or a real-time compiler?

I'm still working on BASICODE and hit upon another 'feature' which works
differently in SBASIC: the vector at $138 can be used to LIST a number of
lines (from D4 to D6), but in the original ROMs and Minerva it can also be
used to execute a DLINE when called with D7<>0 (I believe the TK2 ED
command makes extensive use of this). However in SBASIC the DLINE feature
doesn't work, and from examining the code I could deduce that D7 isn't
being tested at all!

I discovered this when I testing my BCLOAD extension which should delete
all lines from 1000 to the end and then read in a BASICODE program,
translating it to S*BASIC on the fly so it heavily depends on the S*BASIC
vectors. On JM/JS/Minerva it worked as expected but in SBASIC it actually
merged the old and new programs! It looks like I have to write this code
myself now (which is not too difficult as it's merely scanning the program
for line 1000 and then set BV.PFP to the end of the line just before it).

regards, Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Smsqe vs Minerva Basic

2017-04-05 Thread Jan Bredenbeek

On 5-4-2017 14:38, desin wrote:

hi all


i stumbled yesterday on something odd

two programs in development under SMSQE

gave errors under the emulators (q-emulator,uqlx) with Minerva ROMS

under SMSQE it is possible to have on$,on%,to%,to$,for$,for%,end$,end%

as variables. These are rightfully rejected under Minerva 


On the other hand, JS/Minerva allows operator names such as MOD to be 
defined as functions. I have used this to write a floating point version 
of MOD, but discovered later that SBASIC rejects MOD as a function name 
(I had to rename it to FMOD).


Another difference which I discovered today is the behaviour of S*Basic 
vector $138 which is used for LIST or DLINE. You call this using:


MOVE.W #startline,D4
MOVE.W #endline,D6
MOVEQ #function,D7 ; D7=0 for LIST, <>0 for DLINE
MOVE.L #chanid,A0 ; for LIST
MOVE.W $138,A2
JSR $4000(A2)

On JS and Minerva, this works as expected but on SMSQ/E you can't use it 
to DLINE lines from SBASIC. You can use it to LIST lines if you set 
BV.PRINT ($AB(A6)) to nonzero though, but the value in D7 is ignored.


Jan.

--
Jan Bredenbeek | Hilversum, NL | j...@bredenbeek.net

___
QL-Users Mailing List


Re: [Ql-Users] toolkit-ii-the-sequel

2017-03-24 Thread Jan Bredenbeek
On 24 March 2017 at 00:43, Marcel Kilgus <ql-us...@mail.kilgus.net> wrote:

> Jan Bredenbeek wrote:
> > QMAC can do conditional assembly outside macros using the GENIF and
> ENDGEN
> > keywords. Check the updates textfile for details.
>
> Ah, I only checked the manual, how foolish of me ;-) Great, thanks, I
> will check that out.


I discovered it only a week or two ago ;-).
I've always found this a major omission in the otherwise great GST
assembler.
It's a bit awkward to use though as QMAC doesn't let you define symbols via
the command line. I had to create two _ASM files, one for the ROM version
and one for the RAM version with a variable set to 1 or 0 (using EQU or
SETNUM) and then INCLUDE the target _ASM file from there.
So you can use GENIF  = 0 or 1 as appropriate. Beware: there MUST
be a space around the equals sign and when you use SETNUM to set the
variable you have to use brackets around its name (i.e. GENIF [variable] =
1), which isn't necessary when defining a symbol with EQU...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] toolkit-ii-the-sequel

2017-03-23 Thread Jan Bredenbeek
On 24 Mar 2017 00:28, "Marcel Kilgus"  wrote:


The problem is that QMAC cannot do conditional blocks for some dammed
reason outside of Macro calls, so it's difficult to conditionally
enably the ALTKEY keyword depening on which version was compiled. In
any case, ALTKEY should be dead really, HK II does it better (and
replaces ALTKEY with its own version).


QMAC can do conditional assembly outside macros using the GENIF and ENDGEN
keywords. Check the updates textfile for details.

Jan.
___
QL-Users Mailing List


Re: [Ql-Users] SuperBASIC parser vectors

2017-03-08 Thread Jan Bredenbeek
On 8 March 2017 at 17:46, Marcel Kilgus <ql-us...@mail.kilgus.net> wrote:

The ED command build into SMSQ/E addresses pa..table therefore thus:
>
> move.l  pa..table*3+qlv.off+2,a2 graph table address
>
> So strictly speaking the pa..table thing is not QL compatible anymore.
> This could easily be resolved by pa..graph/sb_parse resolving the JMP
> itself, however, if it sees a JMP at the given location.


Thanks, so I can probably leave the original code 'as-is' with a minor
modification and it should work again on SMSQ/E...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SuperBASIC parser vectors

2017-03-08 Thread Jan Bredenbeek
On 8 March 2017 at 13:54, Marcel Kilgus <ql-us...@mail.kilgus.net> wrote:

> Jan Bredenbeek wrote:
> >  MOVE.W$12C,A0
> >  JSR   $4000(A0) call pa_graph to parse line
>
> Wow, the old and new names are mightily confusing.
>
> What once was called pa_graph is now sb_parse.
> What once was called pa_table is now sb_graph.
>

I got the names from the Minerva source. Obviously they were 'invented' by
Laurence since they are not documented in the original QDOS documentation
:-)


>
> > Like I stated earlier, this code has been shamelessly copied from the TK2
> > ED command :-/.
> > Now the interesting question is whether this will work under SMSQ/E.
>
> I don't think anything has changed.
>
> > The vectors are indeed present and point to several JMP instructions
> > to the actual code. However the pa_table vector at $12E is not
> > really the address of a subroutine but a pointer to a syntax table
>
> That is true for Minerva, too.
>
> > (as is pa_expr at $130 which is not used here)
> > That, too, is as, which is needed for pa_graph. Interestingly, on
> > SMSQ/E it still points to a JMP (but it might as well be ignored by
> > pa_graph).
>
> According to the source there is no JMP?
>

The vector which is supposed to point to a syntax table points to a JMP in
SMSQ/E (like all vectors, because the real code is in high memory where it
can't be reached from a word-sized vector). I'm quite sure that there is no
JMP in QDOS/Minerva. So is this vector going to work?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] SuperBASIC parser vectors

2017-03-08 Thread Jan Bredenbeek
This is the code I used for entering a line into SuperBASIC. It should of
course be called from a SuperBASIC environment.

* Enter line into SuperBASIC system
* The SuperBASIC text should be in the buffer (BV.BFBAS(A6) to BV.BFP(A6))

P2_ENTMOVE.LA5,-(A7) Save A5
  QDOS  MT.INF Get QDOS version
  MOVE.W$13A,A2 If >1.03, pa_init is vectored
  CMPI.L#'1.03',D2
  BHI.S P2_E_2
  MOVE.W$12C,A2 If <= 1.03, we get the address from
  ADDA.W#$138,A2 an offset from pa_graph
P2_E_2JSR   $4000(A2) call pa_init to reset SB tables
  MOVE.W$12E,A2 pa_table vector
  ADDA.W#$4000,A2 add offset $4000
  MOVE.W$12C,A0
  JSR   $4000(A0) call pa_graph to parse line
  BEQ.S P2_E_3 syntax ok?
  MOVE.W$134,A2 no, insert "MISTake"
  JSR   $4000(A2)
P2_E_3MOVE.W$132,A2 pa_strip
  JSR   $4000(A2) strip forced spaces
  MOVE.W$136,A2 ed_nwlin
  JSR   $4000(A2) enter line into SB program
  NOP error return point; ignored here
  MOVE.L(A7)+,A5 restore A5
  RTS

Like I stated earlier, this code has been shamelessly copied from the TK2
ED command :-/.
Now the interesting question is whether this will work under SMSQ/E. The
vectors are indeed present and point to several JMP instructions to the
actual code. However the pa_table vector at $12E is not really the address
of a subroutine but a pointer to a syntax table (as is pa_expr at $130
which is not used here), which is needed for pa_graph. Interestingly, on
SMSQ/E it still points to a JMP (but it might as well be ignored by
pa_graph).
Another interesting vector might be ed_liste at $138, which is used to
execute a LIST (D7=0) or DLINE (D7<>0) lines from D4 to D6.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] German Minerva ROM

2017-03-07 Thread Jan Bredenbeek
Just a (maybe silly) question: Is there a way to execute an SBASIC job from
another (non-SBASIC) job on SMSQ/E? I know it is possible on Minerva with a
special vector call and in SBASIC you can simply EXEC another SBASIC
program, but I couldn't find any info on how to do this from a non-SBASIC
job...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] German Minerva ROM

2017-03-07 Thread Jan Bredenbeek
On 7 March 2017 at 21:29, Wolf <w...@wlenerz.com> wrote:

I could be wrong, but AFAIK SBASIC doesn't put a MISTake keyword in front
>> of a 'bad line' which has been loaded from a file. Which makes it harder
>> to
>> debug...
>>
>>
>
> But it does.
> Try this nonsense "10 print print r=25" and load it.
>

I stand corrected, sorry. I got confused by the error messages displayed on
#0 when loading the file (which doesn't occur on JS or Minerva) but the
program indeed gets loaded with MISTakes.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] German Minerva ROM

2017-03-07 Thread Jan Bredenbeek
On 7 March 2017 at 16:56, Dilwyn Jones <dil...@evans1511.fsnet.co.uk> wrote:

Apart from the obvious historical interest of BASICODE and the sofware you
> wrote, it would be useful to document vectors etc concerning editing basic
> programs and syntax checking. And if you have gone as far as to do a
> commented disassembly of the TK2 ED command, for example, that might be
> very useful too. For example, comparing the code in SMSQ/E might help show
> the differences and where common code could be used too if the structure of
> SuperBASIC and SBASIC is not too different.
>

There is little documentation in the source I'm afraid, as I did little
commenting in those years :-(. However it should not be too difficult to
understand the working of these vectors from a JS or Minerva disassembly.
I'm also not sure whether the reason why it did not work on SBASIC is due
to the usage of these vectors or other hardware-dependent code (in fact I
got a nice lockup, probably due to corruption somewhere).


> The reason this springs to mind was that on the QL Forum online chat last
> night, we were discussing Tim Swenson's SSB (Structured SuperBasic system).
> While it's a nice, simple little development system for BASIC programmers,
> one thing it doesn't do is check syntax.
>

I could be wrong, but AFAIK SBASIC doesn't put a MISTake keyword in front
of a 'bad line' which has been loaded from a file. Which makes it harder to
debug...


> Dare I say it (I can live in hope) that such documentation might one day
> help us get some form off IDE (a development environment) for better Basic
> program development. ED and even using a text editor is absolutely fine,
> but when it comes to developing the larger BASIC programs I do sometimes
> feel we are in need of some form of integrated development environment. OK,
> I'll accept that probably if I'm talking in terms of such major programming
> effort, I'm probably using the wrong language in the first place, but hey,
> if the information is there, let's keep it and use it.


Yes an IDE would be great. It could probably be something in the form of a
shell like W*nd*ws Explorer or a 'Norton Commander' lookalike, which can
execute an editor or SBASIC job. I could probably adapt QED if I'd had the
time, but interfacing with SBASIC will be difficult as that is a
self-contained environment (you cannot call the parser from another job,
unless perhaps when it's also an SBASIC job.

Jan.


-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] German Minerva ROM

2017-03-07 Thread Jan Bredenbeek
On 7 March 2017 at 10:36, Tobias Fröschle 
wrote:

> Peter, Marcel,
>
> I have yet to discover a program that doesn't run on SMSQ/E, provided it's
> set to mimic a QL memory map, and does on Minerva (but I'm open to
> suggestions). Weird programs are normally sooo weird that they won't run on
> either...
>

Back in 1987 I wrote a BASICODE translator for the QL which included lots
of hardware-dependent code, including a cassette device driver for use with
the network ports. It had to be run from EPROM because of necessary exact
timing (after all the network port is an ordinary bit-banging interface).
Also, it used the SuperBASIC vectors $12C through $13A which are hardly
documented (I used the code for the TK2 'ed' command as documentation).
This software runs on Minerva but NOT on SMSQ/E.
I have plans to put it on GitHub as it might still be useful since a lot of
BASICODE programs have been put on GitHub recently. Moreover, I'm planning
a new release which doesn't depend on original QL hardware. There's no need
for using cassette interfaces now ;-) but you will still need to convert
the BASICODE programs in ASCII form to SuperBasic. The old code achieved
this by loading the program directly into SuperBASIC (using the
'undocumented' vectors) but this doesn't appear to work on SBASIC, so the
new code will write the translated BASICODE as an ordinary S*BASIC program
which you can LOAD or MERGE...

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Problem loading extensions

2017-02-23 Thread Jan Bredenbeek
On 23 February 2017 at 08:44, Giorgio Garabello 
 wrote:

> Ok, many thanks to all
> Wolfgang i suggest you to explain this LRESPR's "limit" in the next version
> of the SMSQ/E manual.
>

The simplest solution would be to return an error from BP.INIT (or the
equivalent SMSQ vector) when called from inside a procedure. It's not the
LRESPR itself that causes the problem (it's perfectly valid to load and
init something into RESPR/ALCHP from a procedure as long as it doesn't
contain S*Basic extensions).
However not all extensions recognise this error return and thus would not
report this to the user. I don't expect this to cause any harm though, the
only effect would probably be that the new keywords would not work.
Right now the same error occurs when your new extensions have invalid
names. I got caught once when I wrote a function 'MOD' which does the same
as the MOD operator but with floating-point numbers, which all QDOS
versions up to JS (and probably Minerva) happily accepted but SMSQ
rejected...

Jan
___
QL-Users Mailing List


[Ql-Users] New releases on GitHub

2017-02-19 Thread Jan Bredenbeek
MultiMon - QL Monitor and disassembler -
https://github.com/SinclairQL/QL-MultiMon
QED - Fast and compact text editor - https://github.com/SinclairQL/QED

These packages include the source code in 68000 Assembly.

regards, Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SBASIC 'ls' procedure

2017-02-12 Thread Jan Bredenbeek
>> To save you reinventing the wheel Jan, Norman Dunbar's DJToolkit has an
> extension called LEVEL2 which tests for a Level 2 filing system. The
> assembler source djtoolkit_asm is included with the toolkit - just search
> for 'level2' in that source.
>
> http://www.dilwyn.me.uk/tk/djtk.zip
>
Hmm, I should have explained a bit more rather than leaving you to do it.

Just call trap #3 D0=$4F IOF.XINF after reserving a 64 byte block (call
with d1=0, d2.b=0, d3.w=timeout, a0=channel ID, a1=pointer to the 64 byte
buffer.). If no info block is returned (check d0 on return), there is no
level 2.


I'm aware of that, but just want to avoid having to load SB extensions. Oh
well, I'm already CALLing SD.CHENQ code from SB so it shouldn't be much
hassle to implement.
___
QL-Users Mailing List


Re: [Ql-Users] SBASIC 'ls' procedure

2017-02-12 Thread Jan Bredenbeek
On 12 February 2017 at 15:29, RWAP Software <r...@rwapservices.co.uk> wrote:

> Hi Jan,
>
> That is great - it is a nice function which can be useful.
>
> Could I ask you to consider moving (or Forking?) the repository to the new
> SInclair QL Github, as this is intended to keep all of the QL stuff
> together -
>

Done that - the directory structure is a bit strange now but I'll correct
that asap.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] SBASIC 'ls' procedure

2017-02-12 Thread Jan Bredenbeek
I've updated the code with various improvements and fixes:

- Listing now adjusts to window size and can be aborted by pressing 'Q' or
ESC, even when recursing directories;
- Redirection by DEV device is now handled correctly (so long as you don't
rename the DEV device itself ;))
- SMSQ is no longer required; it will now also work on native QL with TK2
and Minerva fitted.
- NOTE: On non-V2 drivers which don't support subdirectories, ls will fail
because the FNAME$ function stops with 'bad parameter' on directory
channels. This can be avoided by adjusting line 1710 in the code (as
indicated in the REMarks). I'll probably have to design another machine
code call to find out whether a device is V2 or not :(

https://github.com/janbredenbeek/QL/blob/master/SBASIC/ls_bas

Jan.

On 3 February 2017 at 11:31, Jan Bredenbeek <j...@bredenbeek.net> wrote:

> Hi Wolfgang,
>
> On 3 February 2017 at 05:01, Wolf <w...@wlenerz.com> wrote:
>
> Are you aware of the SUB device by Phil Borman? It does the same thing,
>> and there is no copright problem since it's on Dilwyn's page (
>> http://www.dilwyn.me.uk/tk/index.html)
>>
>
> Thanks, I can vaguely remember it (it might as well be in my BBS archive).
> Pity it has no source code but indeed a nice thing to learn using DISA. As
> for the copyright issue, I only do it out of curiosity but it might be
> useful inspiration to improve the DEV device ;).
>
> regards,
>
> --
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
>



-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QPC2 and a few more surprises

2017-02-02 Thread Jan Bredenbeek
On 2 February 2017 at 16:35, Dilwyn Jones <dil...@evans1511.fsnet.co.uk>
wrote:

> There is a  manual for Disa v2 on the Assembler page on my website, but I
> don't know how much the program has changed in v3.
>
> http://www.dilwyn.me.uk/asm/Disa2_Manual.pdf
>
> Thanks!

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QPC2 and a few more surprises

2017-02-02 Thread Jan Bredenbeek
Hi Derek,

On 25 January 2017 at 09:37, Derek Stewart <de...@q40.de> wrote:

Disa was one of the best programmes I bought when v3.00 came out, I still
> use it today looking at 68000 code.


I've never used it before but it looks very promising. However I find it
hard to use without a manual. Anyone?

I currently use my own monitor/disassembler (MULTIMON) which is also in The
Distribution archive, but with a Dutch manual. I have translated the manual
into English and will put it online asap. I guess it's not as sophisticated
as DISA as it was written in 1986/87; hence no Pointer Interface. On the
upside, I still have the source code so it can still be improved...

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] SBASIC 'ls' procedure

2017-01-29 Thread Jan Bredenbeek
Okay, here it is. Merge this into your BOOT file and you'll have a
Unix-like 'ls' command, and even a 'lsr' command to list directories
recursively. It lists one file per line, with type, size and date info, and
without the subdirectory names in front of each filename (unlike DIR and
WSTAT).

The current version requires SMSQ because it uses LGET and DMEDIUM_DRIVE.
It can be made to work on native QLs without these commands but I couldn't
work out a way to separate the device+dir and file wildcard without it. On
JS and earlier it will probably crash the machine because it has more than
10 LOCal variables...

Here is the link:
https://github.com/janbredenbeek/QL/blob/master/SBASIC/ls_bas

Have fun,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] QPC2 and a few more surprises

2017-01-25 Thread Jan Bredenbeek
On 25 January 2017 at 00:04, Marcel Kilgus <ql-us...@mail.kilgus.net> wrote:

> I'm too tired to write much more, but I just released a bunch of stuff
> on my web site. You can read about it here:
>
> https://www.kilgus.net/2017/01/25/new-qpc2-disa-and-more/
>

Thanks Marcel for maintaining this great software!
Unfortunately I now have to update some code in my SBASIC 'ls' procedure
since it relied on the 'slicing feature' of earlier versions (meaning
"abcd" (5 to) returning empty string). Incidentally, Minerva offered the
same feature (which is also documented) but not the original Sinclair ROMs.
For those of you interested, I wrote this procedure to give a directory
listing like the Unix 'ls' command as I became dissatisfied with the DIR
and WSTAT commands, especially when listing hard subdirectories - I don't
want the full pathnames in front of all file names, and I made the date
format 'smart' so all info could fit in one line. I'll put it on github
when I've done fixing the code.

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Smsqe 3.28

2017-01-23 Thread Jan Bredenbeek
On 22 January 2017 at 17:41, Wolf <w...@wlenerz.com> wrote:

> Hi all,
>
> Marcel Kilgus has fixed a bug in SMSQ/E.
>
> You could write:
>
> a$="1243"
> PRINT a$(5 to)
>
> without any error, which was wrong.
>

Is this really an error? You could simply return an empty string (as it
does now). Recently I wrote an 'ls' procedure which does a lot of string
slicing, I may have to add another boundary check now...
(incidentally, PRINT a$(6 to) does give an error in the example above).

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] Behaviour of DIV with negative numbers in SBASIC (QPC2)

2017-01-09 Thread Jan Bredenbeek
On 6 January 2017 at 17:07, Bob Spelten <b...@upcmail.nl> wrote:

A word of warning!
>
> It may be true that SMSQ/E supports Long INTs for DIV/MOD but I do
> remember that QLIB does not.
> I tried this in SQRview and it worked fine in SBasic but needed a
> workaround for QLIB to avoid an "overflow" error.
> It's possible that QLIB uses its own DIV/MOD routines.


This is also true for plain interpreted SuperBASIC. Only SBASIC supports
DIV/MOD with long INTs.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List