Re: [Ql-Users] Q-emulator

2024-03-20 Thread Daniele Terdina via Ql-Users
Feel free to add more OS constants!

From: Ql-Users  on behalf of Graeme Gregory 
via Ql-Users 
Sent: Tuesday, March 19, 2024 2:25 PM
To: ql-us...@q-v-d.com 
Cc: Graeme Gregory 
Subject: Re: [Ql-Users] Q-emulator



On Tue, 19 Mar 2024, at 1:30 PM, Dilwyn Jones via Ql-Users wrote:
> I was given this file a few years ago. I'm sorry, I don't know if it's
> still accurate. Hope it helps.
>
> Dilwyn
>
> Q-EMULATOR TRAP CALL
>
> Use Trap #1 with D0.L = -26 to get some emulator info. The trap is
> designed to be usable by other emulators, but I don't think anybody
> else is using it, so it works only with Q-emuLator.
>
> In systems where the trap is not implemented you will get an error
> in D0.L (bad parameter, I think), in Q-emuLator you get 0 in D0.L.
> There are three commands, identified by the value in D1:
>
> ==
>
> D1.L = 0
>
> Currently returns 0 in both D1.L and D2.L. I don't remember anymore
> for sure what the intended meaning was :(. I think D1 was the version of
> the D0=-26 TRAP implemented by the emulator (for example in the future
> there might be a version 1 TRAP that returns extra info, or allows more
> values in D1.L), and D2 is probably reserved for future use. Just ignore D1
> and D2 and look only at D0 (0 = trap is supported, error = it is not),
> or directly call
> with
> D1.L = 1 or 2.
> ==
>
> D1.L = 1
>
> Returns in D1.L info about the host system:
> D1.L = $00aabbcc, where
>   aa = host OS
>0 = Windows
>3 = Mac OS
>   bb = host OS variant (for example, if aa was Unix, bb would
>identify whether it is BSD, Linux, etc.). Currently always
>zero.
>   cc = emulator ID
>1 = Q-emuLator
>
> Returns in D2.L the version of the emulator:
>   D2.L = $xxyyzzww, where
>  xx = major version number
>  yy = middle version number
>  zz = minor version number
>
> ww was supposed to be a global incremental number, but a 0-255
> range is probably too little, so you can just ignore it.
>
> D3.L = type of build
>   0 = alpha
>   1 = beta
>   2 = release
>
> For example,
>D2.L = $02010005 and D3.L = 2 means version 2.1
>D2.L = $01030218 and D3.L = 1 means version 1.3.2b
>
> ==
>
> D1.L = 2
> A1.L = pointer to memory buffer
> D2.L = length of buffer
>
> Fills the buffer with a short QL string identifying the emulator
> (for example "Q-emuLator 2.2").
>
> Returns a buffer full error in D0 if the buffer is smaller than the
> string (and the buffer content is not valid in this case).
> ==
>
> Hope this helps. Most of this is untested so you may find some bugs.
> The only piece of software currently using one of these traps is the
> Q-emuLator's mouse driver (it refuses to install and prints an error
> if it's not running in Q-emuLator).
>
Should be pretty simple to implement this in sQLux, just need documentation for 
the missing values for all the OSes sQLux runs on.

Graeme
___
QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Q-emulator

2024-03-20 Thread Daniele Terdina via Ql-Users
Hello,


I have now created a SuperBASIC extension here:

http://www.terdina.net/ql/soft/qemu_version_bin


It defines two functions:

IS_QEMULATOR returns 1 if running on Q-emuLator, 0 otherwise.

QEMU_VER$ returns a string with the emulator name and version. Currently only 
Q-emuLator supports it (but that could change) and on other platforms it 
returns an empty string.


Thanks,

Daniele



From: Ql-Users  on behalf of Urs Koenig (QL) 
via Ql-Users 
Sent: Tuesday, March 19, 2024 1:05 PM
To: ql-us...@q-v-d.com 
Cc: Urs Koenig (QL) 
Subject: Re: [Ql-Users] Q-emulator

Have a look at QL/E's QLEhelper_bas (or boot_verbose which uses the compiled
QLEhelper) where the command line option \QEMU does exactly this.

Inside QLEhelper_bas look at the PROCedure QemuLator_detect which uses that
Trap call. Feel free to copy, (amend) and use what you need in SuperBASIC.

> -Ursprüngliche Nachricht-
> Von: Ql-Users [mailto:ql-users-boun...@lists.q-v-d.com] Im Auftrag von
> Daniele Terdina via Ql-Users
> Gesendet: Dienstag, 19. März 2024 20:48
> An: ql-us...@q-v-d.com
> Cc: Daniele Terdina
> Betreff: Re: [Ql-Users] Q-emulator
>
> I can write you an extension for that later today.
>
> Thanks
> Daniele
> 
> From: Ql-Users  on behalf of desin via
> Ql-Users 
> Sent: Tuesday, March 19, 2024 12:24 PM
> To: ql-us...@q-v-d.com 
> Cc: desin 
> Subject: Re: [Ql-Users] Q-emulator
>
>
>
> Am 19.03.24 um 19:25 schrieb Daniele Terdina via Ql-Users:
> > This is correct, thank you Dilwyn!
> >
> > If you'd like to test whether you are running on the Q-emuLator-specific
> version of SMSQ/E (file named SMSQ_QEM, that can only run on Q-
> emuLator), you can use MACHINE and check for code 26.
> >
> > On any version of QDOS or SMSQ/E, you can test whether you are running
> on Q-emuLator by setting D0=-26 (notice the minus sign), D1=1 and calling
> TRAP #1. On return, if the error code (in D0) is zero and D1.B is 1, you
are
> running on Q-emuLator.
>
> Thanks Daniele
> but how do it in basic ?
>
> Background
>
> A boot file that runs on most systems (native/emulated)
> on Q-emulator it must check what version of SMSQE
> is necessary
>
> Greetings from Switzerland
> Markus
>
> ___
> QL-Users Mailing List
> ___
> QL-Users Mailing List

___
QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Q-emulator

2024-03-19 Thread Daniele Terdina via Ql-Users
I can write you an extension for that later today.

Thanks
Daniele

From: Ql-Users  on behalf of desin via 
Ql-Users 
Sent: Tuesday, March 19, 2024 12:24 PM
To: ql-us...@q-v-d.com 
Cc: desin 
Subject: Re: [Ql-Users] Q-emulator



Am 19.03.24 um 19:25 schrieb Daniele Terdina via Ql-Users:
> This is correct, thank you Dilwyn!
>
> If you'd like to test whether you are running on the Q-emuLator-specific 
> version of SMSQ/E (file named SMSQ_QEM, that can only run on Q-emuLator), you 
> can use MACHINE and check for code 26.
>
> On any version of QDOS or SMSQ/E, you can test whether you are running on 
> Q-emuLator by setting D0=-26 (notice the minus sign), D1=1 and calling TRAP 
> #1. On return, if the error code (in D0) is zero and D1.B is 1, you are 
> running on Q-emuLator.

Thanks Daniele
but how do it in basic ?

Background

A boot file that runs on most systems (native/emulated)
on Q-emulator it must check what version of SMSQE
is necessary

Greetings from Switzerland
Markus

___
QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Q-emulator

2024-03-19 Thread Daniele Terdina via Ql-Users
This is correct, thank you Dilwyn!

If you'd like to test whether you are running on the Q-emuLator-specific 
version of SMSQ/E (file named SMSQ_QEM, that can only run on Q-emuLator), you 
can use MACHINE and check for code 26.

On any version of QDOS or SMSQ/E, you can test whether you are running on 
Q-emuLator by setting D0=-26 (notice the minus sign), D1=1 and calling TRAP #1. 
On return, if the error code (in D0) is zero and D1.B is 1, you are running on 
Q-emuLator.

From: Ql-Users  on behalf of Dilwyn Jones via 
Ql-Users 
Sent: Tuesday, March 19, 2024 6:46 AM
To: ql-us...@q-v-d.com 
Cc: Dilwyn Jones 
Subject: Re: [Ql-Users] Q-emulator

I think I forgot to mention that under the QemuLator specific version
3.38 from Daniele's website, the MACHINE function in SBASIC returns 26
for QemuLator. I don't know if the Gold Card and Aurora versions also
do this, sorry.

Dilwyn

On Tue, 19 Mar 2024 at 13:30, Dilwyn Jones  wrote:
>
> I was given this file a few years ago. I'm sorry, I don't know if it's
> still accurate. Hope it helps.
>
> Dilwyn
>
> Q-EMULATOR TRAP CALL
>
> Use Trap #1 with D0.L = -26 to get some emulator info. The trap is
> designed to be usable by other emulators, but I don't think anybody
> else is using it, so it works only with Q-emuLator.
>
> In systems where the trap is not implemented you will get an error
> in D0.L (bad parameter, I think), in Q-emuLator you get 0 in D0.L.
> There are three commands, identified by the value in D1:
>
> ==
>
> D1.L = 0
>
> Currently returns 0 in both D1.L and D2.L. I don't remember anymore
> for sure what the intended meaning was :(. I think D1 was the version of
> the D0=-26 TRAP implemented by the emulator (for example in the future
> there might be a version 1 TRAP that returns extra info, or allows more
> values in D1.L), and D2 is probably reserved for future use. Just ignore D1
> and D2 and look only at D0 (0 = trap is supported, error = it is not),
> or directly call
> with
> D1.L = 1 or 2.
> ==
>
> D1.L = 1
>
> Returns in D1.L info about the host system:
> D1.L = $00aabbcc, where
>   aa = host OS
>0 = Windows
>3 = Mac OS
>   bb = host OS variant (for example, if aa was Unix, bb would
>identify whether it is BSD, Linux, etc.). Currently always
>zero.
>   cc = emulator ID
>1 = Q-emuLator
>
> Returns in D2.L the version of the emulator:
>   D2.L = $xxyyzzww, where
>  xx = major version number
>  yy = middle version number
>  zz = minor version number
>
> ww was supposed to be a global incremental number, but a 0-255
> range is probably too little, so you can just ignore it.
>
> D3.L = type of build
>   0 = alpha
>   1 = beta
>   2 = release
>
> For example,
>D2.L = $02010005 and D3.L = 2 means version 2.1
>D2.L = $01030218 and D3.L = 1 means version 1.3.2b
>
> ==
>
> D1.L = 2
> A1.L = pointer to memory buffer
> D2.L = length of buffer
>
> Fills the buffer with a short QL string identifying the emulator
> (for example "Q-emuLator 2.2").
>
> Returns a buffer full error in D0 if the buffer is smaller than the
> string (and the buffer content is not valid in this case).
> ==
>
> Hope this helps. Most of this is untested so you may find some bugs.
> The only piece of software currently using one of these traps is the
> Q-emuLator's mouse driver (it refuses to install and prints an error
> if it's not running in Q-emuLator).
>
> On Tue, 19 Mar 2024 at 12:54, desin via Ql-Users
>  wrote:
> >
> > Hello
> > how can a basic program check if its running on Q-emulator ?
> >
> > Greetings from Switzerland
> > Markus
> > ___
> > QL-Users Mailing List
___
QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.33

2018-05-10 Thread Daniele Terdina via Ql-Users
I decided to give a try to the Aurora version on Q-emuLator, but it stops when 
it encounters some "jsr $FE83" instructions... anybody knows what those are 
supposed to do?

Daniele

From: Ql-Users  on behalf of Wolf via 
Ql-Users 
Sent: Sunday, April 29, 2018 2:40 AM
To: ql-us...@q-v-d.com
Cc: Wolf
Subject: [Ql-Users] SMSQ/E 3.33

Hi all,

SMSQ/E 3.33 is out, get it as usual from
www.wlenerz.com/smsqe

What's new in this version :

Final bugfix for LRESPR in procedures (means everybody should upgrade)
Better QL networking.
Gold card is configured not to use ABC keyboard.
Improvements in standard QL EE.
Q68 & SMSQmulator better  handling.

The sources for the stand-alone TK II are included in the SMSQ/E sources.
Moreover, whilst they aren't really part of SMSQE, the new QL-SD drivers
are built on the basis of the SMSQ/E "dv3" driver acihtecture, so their
sources are also included in the SMSQ/E sources (remember, the compiled
drivers are at wlenerz.com/qlsd).

If you have a Qx0 machine and access to an EPROM burner, this may be of
interest to you : The Qx0 may now have a compressed SMSQ/E so newer
versions thereof fit in the standard EPROMs. There is a certain process
involved in making these EPROMs - but it is clealy described in the
"smsq_q40_boot_doc" or "smsq_q40_boot_txt" files in the SMSQ/E sources.

Finally, Q68 has better handling of some slower SDHC cards. Also, and
that is an officially unofficial and undocumented feature, the Q68 may
also be able to read most older SD (not SDHC) cards. However, make sure
that this actually works with your cards before using them in earnest.
Offficially, the Q68 still only supports SDHC cards.

Have fun!
___
QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-25 Thread Daniele Terdina via Ql-Users
In case you are using a ROM expansion, latest versions of Minerva have trouble 
with that.

Daniele

From: Ql-Users  on behalf of Martyn Hill via 
Ql-Users 
Sent: Sunday, February 25, 2018 6:51 AM
To: ql-us...@q-v-d.com
Cc: Martyn Hill
Subject: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

Hi everyone!

I'm looking to get a hold of the *source *for either of *Minerva v1.92
*or *v1.89*. We have v1.98 source available, which I have poured over
for /many /an hour...

Is anyone able to contact the QView team to ask, or else has a copy to
hand of either version of source code and has permission to release to a
enthusiastic tester?

Whilst I can continue using Min v1.92 +TK2 with full & reliable
networking, my aim is to run the latest Minerva**available - possibly
after hacking v1.98 or TK2 to restore /full /QLNet
compatibility**between them**- see below.*
*

*Context:*
In my on-going exploration and testing of the network on the BBQL, I
discovered an apparent incompatibility between Minerva v1.97 and 1.98
whenever TK2 (any version) is loaded when it comes to using LBYTES
specifically. Other uses of the NET driver work as more-or-less as
expected (OPEN, LOAD, SBYTES, etc), albeit with some additional latency
sometimes observed.

I posted a thread on the forum a while back but, at that time, I had
reservations about the hardware state of my own 2x QL motherboards (an
Iss7 and an Iss5 - both 'hacked' quite a bit.)

Since then, I have tested with other QL motherboards (Iss6 and another
Iss5 - no hacks) and made adjustments to the TK2 code to validate and
now have a degree of confidence that there really is something odd with
Minerva + TK2 /after /Minerva v1.92.

Specifically, when receiving via LBYTES (and SBYTES at the remote end),
Minerva 1.97+ on its own receives perfectly, but once the NET driver is
effectively replaced with TK2 (upto v2.23), issuing LBYTES will
completely hang the /receiving /QL - immediately and regardless of
whether the sending end has even started.

It doesn't seem to make a jot of difference what is running at the
/sending/ end - nor which issue of motherboard are at either end...

ROM (Rx)w/o TK2with TK2
-     ---
JS and MG  OK  OK
Min v1.89   OK  OK
Min v1.92   OK  OK
Min v1.97   OK  Hangs on LBYTES
Min v1.98   OK  Hangs on LBYTES

(I don't know how well that table will render...)

I have already hacked the TK2 (v2.23) NET driver source to allow both
the Minerva NET and the TK2 NET driver (renamed to 'TNT') to co-exist,
and also to allow both Minerva's LBYTES and TK2's equivalent procedure
(again, renamed.)

When using the Minerva NET driver, but still with TK2 loaded, normal
service resumes. The moment LBYTES is issued (again on Min v1.97/1.98)
but against the renamed 'TNT' driver, the receiver hangs again. As one
might expect from the above, Minerva v1.92 and 1.89 execute LBYTES
perfectly well using /either /NET or the TNT variant.

I suspect some combination of register or stack usage/dependencies that
are no longer as TK2 expects /after /Min v1.92, but after literally
man-days of cross comparing the various source codes available, I can't
nail it down and its bugging me :-)

What I am missing is a decent disassembly of one of the 'working'
Minerva versions, or better still, the source. Hence my request.

If I can't lay my hands on the source, I'll resort to running DEA or
IDIS against the Minerva v1.98 ROM, but that's tedious as hell :-)

Any takers?

Regards,
*Martyn Hill.*

--
"There are 10 types of people in this world. Those who understand binary and 
those who don't."

___
QL-Users Mailing List
___
QL-Users Mailing List