Re: [Ql-Users] SMSQ/E 3.39

[Jan Bredenbeek via Ql-Users]

Hi Dilwyn,

On 29-02-2024 19:05, Dilwyn Jones via Ql-Users wrote:


I might agree with that, were it not for the fact that there has been
no issue whatsoever with running SMSQ/E on it (apart from the fact I
have to configure it not to try to do fast SD card access).

Anyway, once Derek has been able to reprogram it, we'll know if it's
the software version or something else.



I'm curious as to how you have connected the keyboard to the Q68. Is it 
keyboard only or keyboard + mouse via a spiltter?
When I use a splitter and connect the keyboard to the corresponding 
connector on the spiltter, the Q68 freezes at the boot loader screen 
even if the mouse is not connected. I have to reverse keyboard and mouse 
plugs to make it work. Of course this has no relationship with Minerva 
or SMSQ/E (which hasn't even started up yet) but it might have something 
to do with interrupts or firmware (which I'm not familiar with, it's 
Peter's design).


Also, you might check if the 5V power supply is sufficiently stable (the 
Q68 itself runs at 3V but the keyboard at 5V).


I've got a reply today from Mark, he still has the freeze issue you 
describe so you're not the only one with this problem.


Best Regards,
Jan
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.39

[Jan Bredenbeek via Ql-Users]

Hi Jan,

I can do any upgrades if you want to send the Q68 to me.

Regards,
Derek


I have upgraded the Q68 FPGA firmware to v1.05 last week and everything 
is working fine, no lock-ups. However, using 40MHz SDHC clock gets 
corrupted file reads, at least when using the original Q68 SDHC card. So 
disabled that in SMSQ/E.


But to stay on-topic: I noticed that the SMSQ/E 3.39 source zip only 
contains the smsq branch. Does this mean the other branches have not 
been changed since v3.38?


Jan
--
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.39

[Jan Bredenbeek via Ql-Users]

Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be
able to do more research...


Please remind me prior to the QL meeting so I bring the equipment and
FPGA data.


I might be able to get a second hand FPGA programmer for cheap, I'll let 
you know when I get it.



As I wrote at several occasions, it turned out to make a difference on
which operating system I had synthesized FPGA version 1.05. If
synthesized under Windows 10, there was a stability problem that Martyn
could reproduce. If synthesized under Windows XP, everything should be
allright. Unfortunately, I never suspected such a problem with the FPGA
toolchain, and it is now not traceable. Very unlucky.


I've discussed this with Mark, his Q68 was not affected by this.


Dilwyn Jones via Ql-Users wrote:


Mind you, my Q68 has never been able to run Jan's Minerva port either.


If the latest Minerva and/or returning to FPGA version 1.02 does not
help, I would suspect an actual hardware problem and your Q68 should be
replaced.


I'm not sure whether the latest Minerva port will solve all problems. 
Mark and I managed to pinpoint some issues but so far we haven't been 
able to solve it completely.


One point of interest remains the interrupt register at $18021. I know 
about the frame and external interrupt bits (3 and 4, respectively) 
which are emulated from a BBQL. The other bits are irrelevant to Minerva 
(in fact only bit 3 is checked for a frame interrupt call, else it 
treats it as external interrupt since early Q68s don't set bit 4).


But does writing to this register have any effect? The only purpose 
would be to clear the respective interrupt by setting bit 3 or 4 (which 
Minerva does). Bits 0-2 and 5-7 were used for gap, IPC, and transmit 
interrupts respectively, which are irrelevant to the Q68 and should 
really be ignored. Minerva doesn't set these bits except when 
initialising the hardware.


--
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.39

[Jan Bredenbeek via Ql-Users]

On 19-02-2024 15:03, Dilwyn Jones via Ql-Users wrote:


My Q68 failed consistently with all SDHC cards I've tried here when
configured for fast. It definitely did not slow down automatically
when configured to fast (SMSQE 3.38) - the Q68 either crashed or
failed to recognise the cards at 40MHz. Either I've been unlucky and
NONE of the cards I have are capable of fast, or the "auto-slow"
doesn't work at all. Mind you, my Q68 has never been able to run Jan's
Minerva port either.


Have you tried the latest version 1.64 on my GitHub page? 
https://github.com/janbredenbeek/Minerva4Q68


Mark Swift and I have spent many hours in researching this issue but so 
far I haven't got a response from Mark on this version.


Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be 
able to do more research...


Best regards,
Jan

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

___
QL-Users Mailing List

Re: [Ql-Users] bug in String handling

[Jan Bredenbeek via Ql-Users]

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.


Cheers,
Norm.



Page 46 of the Concepts section mentions that 'under certain 
circumstances' it is possible to refer to more than one element in an 
array (i.e. slice the array), and that the term 'array' in this context 
can include a numerical array, a string array or a simple string. It 
also mentions that the slice (0 TO) means the full range of elements.


Whilst it is indeed possible to slice an array (which includes element 
0), this is not true for simple strings. Using slice (0 TO) of a simple 
string always produces an 'out of range' error.
Under Minerva and SMSQ/E, a$(0) indeed returns the length of a$. At 
least version JS returns an error when trying to access element 0 of a 
simple string.


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

___
QL-Users Mailing List

Re: [Ql-Users] CONFIG Manual

[Jan Bredenbeek via Ql-Users]

2023-12-07T17:55:41Z Norman Dunbar via Ql-Users :

> Evening all.
> 
> I was reading through the latest version of Wolfgang's SMSQ/E Reference 
> Manual, looking for some information on Config blocks and usage. It wasn't 
> there!
> 
> I was sure that a previous manual, possibly the old A5 printed one I bought 
> from Jochen years ago, but no longer. I searched the PDF for any references 
> and eventually found a note that "Config has its own manual" and "You should 
> be able to get it from the same place as this one" (or words to that effect.)
> 
> I searched Wolfgang's Documentation area, to no avail. I don't see the Config 
> manual anywhere. Does anyone know if there is a manual? and if so, where I 
> can lay my hands on it please?
> 
> Thanks.
> 
> 
> Cheers,
> Norm.
> 
> -- 
> Norman Dunbar.
> ___
> QL-Users Mailing List
Hi Norman,

There is a lot of information about Config blocks at 
https://dilwyn.qlforum.co.uk/config/index.html

Best regards, Jan.
___
QL-Users Mailing List

Re: [Ql-Users] QBOX

[Jan Bredenbeek via Ql-Users]

Hi Fabrizio,

It looks like opening a TCP channel for listening doesn't work in these 
cases. But which port are you using for listening? Windows allows 
privileged ports (below 1024) but Linux doesn't. I don't know about 
MacOS but I believe it's more Unix-like and might prevent opening 
privileged ports for user space programs.


I'm just following the QDOS TCP specs here so I have no idea what could 
otherwise be the cause...


Jan

On 10-03-2022 21:30, Fabrizio Diversi wrote:

Hi,

thank you, your answer solved the issue I had, Qbox work fine.

This is true for QPC2 under MS win10 but not for my main QPC2 system 
under MacBook M1 using Crossover where, when Qbox start, I got an 
error QSPILTCP: bind socket failed, retrying in 60 msec.



Same using SMSQmulator under MacBook M1(Monterey): QSPILTCP: cannot 
set TCP_NODELAY option: not implemented - io.open in sp.wtcall 
returned error: not implemented


Quite obvious this is an issue linked with Macbook and Crossover 
emulation, not a big issue for me as the Qbox server is on Qpc2 hosted 
on Win10 and Qterm client work fine under MacBook/Crossover/Qpc2


Thank you again for your support

fabrizio 


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

___
QL-Users Mailing List

Re: [Ql-Users] QBOX

[Jan Bredenbeek via Ql-Users]

Hi Fabrizio,

Just start QBOX with the -T option, i.e. EX QBOX;'-T'. This bypasses the 
clock check. Then log on and log off, this will correct the time stamp 
on the USERS_BBS file. After this, you won't need the -T option if your 
clock is set correctly (QBOX only complains when the time stamp of 
USERS_BBS is in the future or more than 1 year in the past :)).


Jan

On 09-03-2022 15:13, Fabrizio Diversi via Ql-Users wrote:

Hi,
sorry if this topic was discussed elsewhere, but, after I updated my 
Qbox Server system (Raspberry/SMSQmulator) with latest programs/os etc 
(SMSQ/E 3.38), Qbox refuse to start with the error "QBOX: wrong Clock 
setting" and cannot find why. this happen..either I cannot find 
any document that explain QBOX errors messages meaning

Any help will be appreciated :)

Thanks
Fabrizio
___
QL-Users Mailing List



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

___
QL-Users Mailing List

Re: [Ql-Users] QBOX

[Jan Bredenbeek via Ql-Users]

Hi Fabrizio,

Just start QBOX with the -T option, i.e. EX QBOX;'-T'. This bypasses the 
clock check. Then log on and log off, this will correct the time stamp 
on the USERS_BBS file. After this, you won't need the -T option if your 
clock is set correctly (QBOX only complains when the time stamp of 
USERS_BBS is in the future or more than 1 year in the past :)).


Jan

On 09-03-2022 15:13, Fabrizio Diversi via Ql-Users wrote:

Hi,
sorry if this topic was discussed elsewhere, but, after I updated my 
Qbox Server system (Raspberry/SMSQmulator) with latest programs/os etc 
(SMSQ/E 3.38), Qbox refuse to start with the error "QBOX: wrong Clock 
setting" and cannot find why. this happen..either I cannot find 
any document that explain QBOX errors messages meaning

Any help will be appreciated :)

Thanks
Fabrizio
___
QL-Users Mailing List



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

___
QL-Users Mailing List

Re: [Ql-Users] QBOX

[Jan Bredenbeek via Ql-Users]

Hi Fabrizio,

Just start QBOX with the -T option, i.e. EX QBOX;'-T'. This bypasses the 
clock check. Then log on and log off, this will correct the time stamp 
on the USERS_BBS file. After this, you won't need the -T option if your 
clock is set correctly (QBOX only complains when the time stamp of 
USERS_BBS is in the future or more than 1 year in the past :)).


Jan

On 09-03-2022 15:13, Fabrizio Diversi via Ql-Users wrote:

Hi,
sorry if this topic was discussed elsewhere, but, after I updated my 
Qbox Server system (Raspberry/SMSQmulator) with latest programs/os etc 
(SMSQ/E 3.38), Qbox refuse to start with the error "QBOX: wrong Clock 
setting" and cannot find why. this happen..either I cannot find 
any document that explain QBOX errors messages meaning

Any help will be appreciated :)

Thanks
Fabrizio
___
QL-Users Mailing List



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

___
QL-Users Mailing List

Re: [Ql-Users] QBOX

[Jan Bredenbeek via Ql-Users]

Hi Fabrizio,

Just start QBOX with the -T option, i.e. EX QBOX;'-T'. This bypasses the 
clock check. Then log on and log off, this will correct the time stamp 
on the USERS_BBS file. After this, you won't need the -T option if your 
clock is set correctly (QBOX only complains when the time stamp of 
USERS_BBS is in the future or more than 1 year in the past :)).


Jan

On 09-03-2022 15:13, Fabrizio Diversi via Ql-Users wrote:

Hi,
sorry if this topic was discussed elsewhere, but, after I updated my 
Qbox Server system (Raspberry/SMSQmulator) with latest programs/os etc 
(SMSQ/E 3.38), Qbox refuse to start with the error "QBOX: wrong Clock 
setting" and cannot find why. this happen..either I cannot find 
any document that explain QBOX errors messages meaning

Any help will be appreciated :)

Thanks
Fabrizio
___
QL-Users Mailing List



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

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD ROM

[Jan Bredenbeek via Ql-Users]

On 29-04-2021 19:45, Marcel Kilgus via Ql-Users wrote:

An update on the progress of the external QL-SD variant:

https://www.kilgus.net/2021/04/29/ql-sd-rom-tiny/


Hi Marcel,

Based on your excellent blog post about the (S)GC boot process 
(https://www.kilgus.net/2018/11/14/supergoldcard-boot-sequence/), I 
managed to write a boot loader for custom QL ROMs using a (Super)Gold 
Card. Turned out that the lower 48K RAM of the (S)GC isn't as 
write-protected as we thought! This way you can change ROMs on the QL 
without even having to open the case. Of course, this will need a (S)GC 
unlike your solution and it provides no mass storage. I still like the 
idea of QL-SD as floppies are too limited and getting unreliable as they 
age, and using a Q68 as QLnet file server is quite slow.



The code for the boot loader is on my GitHub page: 
https://github.com/janbredenbeek/QL-Customboot



Cheers, Jan.

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

___
QL-Users Mailing List

Re: [Ql-Users] SMSQE 3.37

[Jan Bredenbeek via Ql-Users]

Hi Wolfgang,

I noticed that I cannot configure the fat1_ drive on the Q68. Menuconfig 
simply skips this entry when I try to.

Strange enough it does work with the other fat drives...

Jan

On 24-01-2021 08:55, Wolfgang Lenerz via Ql-Users wrote:

Hi all,

SMSQE 3.37 is available on my site now.


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

___
QL-Users Mailing List

Re: [Ql-Users] SMSQmulator 2.30

[Jan Bredenbeek via Ql-Users]

Hi Wolfgang,

It appears that most of the library files are missing in the Java 8 .zip 
file. SMSQmulator refused to start and gave an 'INI file error' on the 
Java 8 version. I could fix this by copying the files in the lib 
directory from the Java 11 version.


A more serious bug is that the tcp device now doesn't appear to work. 
When I tried to start QBOX as telnet server it failed to open the tcp 
channel with a 'not found' message. Using tcp as client also failed.

Could it be that implementing udp support has broken the tcp device?

Regards, Jan.

On 24-01-2021 08:57, Wolfgang Lenerz via Ql-Users wrote:

Hi all,

Hot on the heels of SMSQE 3.37, SMSQmulator 2.30 is out now.

Mainly for UDP support, and also the ROXL instruction is corrected
(thanks to David Westbury for pointing that out).

wlenerz.com/smsqmulator



--

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







___
QL-Users Mailing List

Re: [Ql-Users] Select on

[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

[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

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

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

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

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

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

[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

[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

[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

[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

[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 



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

[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

[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

[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

[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

[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

[Jan Bredenbeek via Ql-Users]

 QED v2.02 has been released and can be downloaded here
.

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

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

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

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

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

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

[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

[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

[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

[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

[Jan Bredenbeek via Ql-Users]

On 9 March 2018 at 16:35, Bob Spelten via Ql-Users  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

[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

[Jan Bredenbeek via Ql-Users]

On 15 February 2018 at 11:45, pjwitte via Ql-Users  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

[Jan Bredenbeek via Ql-Users]

On 5 January 2018 at 22:33, Dave Park via Ql-Users  wrote:

> I did have an FB dongle around here once upon a time, but I haven't seen it
> in five years.
>

I once got my hands on an FB machine somewhere in autumn 1984. A local
computer store had imported it from the UK (probably not officially). It
didn't take long before the 'bad or changed medium' message popped up on
loading Quill. So I decided to wait a little longer before buying a QL.
Of course, with today's hindsight (and money!) I would have bought it...

Jan.

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

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

[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

[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

[Jan Bredenbeek via Ql-Users]

On 28 December 2017 at 13:10, Wolf via Ql-Users 
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

[Jan Bredenbeek via Ql-Users]

On 28 December 2017 at 12:59, Wolf via Ql-Users 
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

[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

[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

[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

[Jan Bredenbeek via Ql-Users]

On 27 October 2017 at 21:51, Peter Graf  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

[Jan Bredenbeek via Ql-Users]

On 27 October 2017 at 21:03, Peter Graf  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

[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

[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

[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

[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