[Ql-Users] Announcing availability of a QLNET driver for the Q68 (ND-Q68)

2019-06-16 Thread Martyn Hill via Ql-Users
On this Father's Day (in the UK, anyway), I am pleased to announce the 
availability of driver software that allows you to finally network the 
Q68 with other QL-compatible machines via the standard QLNET ports.


The ready-to-run driver as well as the source code and a short 
commentary are available at the *QL Forum* post here:


https://qlforum.co.uk/viewtopic.php?f=3=2881

I'll be focusing on updates in the Forum post rather than this mailing 
list, but wanted to ensure the broadest coverage - if you don't yet 
frequent the Forum, perhaps now's a good time to start :-)


Happy QL-Networking!

___
QL-Users Mailing List


Re: [Ql-Users] How do you find the Driver Definition Block (DDB) base-address from SBASIC for the NET device

2018-05-19 Thread Martyn Hill via Ql-Users

Hi again Wolfgang, Jan and anyone else still tuned-in :-)

I can confirm that by adjusting the timing-constants auto-calculated by 
the NET code in SMSQ/E for the QXL by a simple factor of 5% (x 1.05), I 
can now successfully send/receive between my QXL and QL.


Whether this is a more general issue for other users of QXL running 
SMSQ/E v3.33, I can't say, but it proved an interesting excursion 
nerver-the-less!


Thanks for the help!

M.


On 19/05/2018 15:52, Wolf via Ql-Users wrote:

Hi,


Glad I could help, I'll be interested to see how it goes!

Have fun.

Wolfgang

On 19/05/2018 16:31, Martyn Hill via Ql-Users wrote:

Great observation, Wolfgang!

So, that adjustment to a3 comes out to $1E (30) bytes /*later */in 
the DDB - so rather, once the ndt_ctab offset of $50 is added, we 
need to look at $6E through $8E for the timing constant table.


I now see:

$6E:    134
$70:  13570
$72: 19
$74:    328
$76:   2034
...

This looks more promising! Now I need to check against the expected 
values.


The calculations carried out in nd/initv take three words for each 
constant stored by the macros in qxl.asm (time,offset,scale), which 
for the first 5 values (assuming a 20MHz clock) are:


nqx_wgap:    200,28,28 =   141
nqx_bace:    2,28,28  = 14185
nqx_csct:    30,28,28 = 20
nqx_esct:    485,28,28    =   345
nqx_wsct:    3000,28,28   =  2141
...

Aha! We have accounted for the 5% difference between nominal QNET 
timings and what was measured down the wire from my QXL!


The actual clock-rate is empirically measured somewhere else in the 
initialisation code and stored in d1 ready for nd/initv to use, 
rather than a fixed 20Mhz scale-factor which is how the original 
scaling factor assumed in qxl.asm. Would seem that the measured 
clock-rate was slightly lower than it really is.


I'll go ahead and switch-out the stored values in the DDB constants 
table with the 5% higher figures and re-test.


I love a good detective-story!

Stand-by!
M.
On 19/05/2018 13:48, Wolf via Ql-Users wrote:

Hi,

This is what you can find in the NET driver i/o code:

nd_io
    pea ndd_test(a3)    push pseudo return address

    lea ndd.leni(a3),a3 normal linkage ***

    move.w  io.serio,a2 and do serial IO
    jmp (a2)

As  you can see, A3 is adjusted there, perhaps you sould look at the 
DDB with the same offset.


HTH

Wolfgang


On 19/05/2018 13:15, Martyn Hill via Ql-Users wrote:

Thanks Wolfgang (and Jan via the Forum)

Having now found what looks like the DDB - taking in to account the 
-$18 offset from the entry in the CDB - the resultant list of words 
at offset ndt_ctab ($50) looks suspicious, thus:


50:       0
52:     124
54:  -18236
56:       0
58:      36
5A:       1
...
6A:   20085
6C:       0
6E:     134

The '20085' at offset $6A in particular looks more like an RTS 
instruction than the timing constant for 'receive bit timeout'.


Anyway, I'll keep digging. Thanks!

Martyn.

On 19/05/2018 09:41, Wolf via Ql-Users wrote:

Hi,

The best way would be to get the channel definition block (CDB) 
for a channel to the device. I don't know offhand of a Basic 
keyword that will do it for you, Toolkit III used to have such a 
function, I don't know whether that still available, though.


If you have that, then the pointer to the driver definition block 
(DDB) lies at offset chn_drvr (=4) in the CDB - you can just 
PEEK_L that. Be careful, however, the pointer there normally 
points to offset iod_iolk (=$18) within the DDB, so all other 
offsets should be reduced by that same amount.


HTH

Wolfgang

On 18/05/2018 22:01, Martyn Hill via Ql-Users wrote:

Hi everyone

In the spirit of double-posting between here and the QL Forum :-) 
I thought I'd ask my question here, too...


I'm continuing to explore the QL network across a range of 
platforms - now with my refurbished QXL2 card (thanks, Derek!)


The bit-timings on the QXL under SMSQ/E v3.33 (and also on v2.76) 
prove to be slightly-out from the nominal 11.2us, resulting in 
failed/unreliable comms with both my Iss7 QL and my prototype 
QNET to USB adapter (still a work in progress.)


Given that the timings-constants for the NET device are exposed 
under SMSQ/E and stored ready for adjustment in the DDB of the 
NET device, I'm trying to find the base address of the DDB from 
SBasic.


Any help appreciated!

The original post appears here, with pictures :-)

 https://qlforum.co.uk/viewtopic.php?f=3=2462

Regards,
Martyn.

___
QL-Users Mailing List

___
QL-Users Mailing List



___
QL-Users Mailing List



___
QL-Users Mailing List


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

___
QL-Users Mailing List

Re: [Ql-Users] How do you find the Driver Definition Block (DDB) base-address from SBASIC for the NET device

2018-05-19 Thread Martyn Hill via Ql-Users

Great observation, Wolfgang!

So, that adjustment to a3 comes out to $1E (30) bytes /*later */in the 
DDB - so rather, once the ndt_ctab offset of $50 is added, we need to 
look at $6E through $8E for the timing constant table.


I now see:

$6E:    134
$70:  13570
$72: 19
$74:    328
$76:   2034
...

This looks more promising! Now I need to check against the expected values.

The calculations carried out in nd/initv take three words for each 
constant stored by the macros in qxl.asm (time,offset,scale), which for 
the first 5 values (assuming a 20MHz clock) are:


nqx_wgap:    200,28,28 =   141
nqx_bace:    2,28,28  = 14185
nqx_csct:    30,28,28 = 20
nqx_esct:    485,28,28    =   345
nqx_wsct:    3000,28,28   =  2141
...

Aha! We have accounted for the 5% difference between nominal QNET 
timings and what was measured down the wire from my QXL!


The actual clock-rate is empirically measured somewhere else in the 
initialisation code and stored in d1 ready for nd/initv to use, rather 
than a fixed 20Mhz scale-factor which is how the original scaling factor 
assumed in qxl.asm. Would seem that the measured clock-rate was slightly 
lower than it really is.


I'll go ahead and switch-out the stored values in the DDB constants 
table with the 5% higher figures and re-test.


I love a good detective-story!

Stand-by!
M.
On 19/05/2018 13:48, Wolf via Ql-Users wrote:

Hi,

This is what you can find in the NET driver i/o code:

nd_io
    pea ndd_test(a3)    push pseudo return address

    lea ndd.leni(a3),a3 normal linkage ***

    move.w  io.serio,a2 and do serial IO
    jmp (a2)

As  you can see, A3 is adjusted there, perhaps you sould look at the 
DDB with the same offset.


HTH

Wolfgang


On 19/05/2018 13:15, Martyn Hill via Ql-Users wrote:

Thanks Wolfgang (and Jan via the Forum)

Having now found what looks like the DDB - taking in to account the 
-$18 offset from the entry in the CDB - the resultant list of words 
at offset ndt_ctab ($50) looks suspicious, thus:


50:       0
52:     124
54:  -18236
56:       0
58:      36
5A:       1
...
6A:   20085
6C:       0
6E:     134

The '20085' at offset $6A in particular looks more like an RTS 
instruction than the timing constant for 'receive bit timeout'.


Anyway, I'll keep digging. Thanks!

Martyn.

On 19/05/2018 09:41, Wolf via Ql-Users wrote:

Hi,

The best way would be to get the channel definition block (CDB) for 
a channel to the device. I don't know offhand of a Basic keyword 
that will do it for you, Toolkit III used to have such a function, I 
don't know whether that still available, though.


If you have that, then the pointer to the driver definition block 
(DDB) lies at offset chn_drvr (=4) in the CDB - you can just PEEK_L 
that. Be careful, however, the pointer there normally points to 
offset iod_iolk (=$18) within the DDB, so all other offsets should 
be reduced by that same amount.


HTH

Wolfgang

On 18/05/2018 22:01, Martyn Hill via Ql-Users wrote:

Hi everyone

In the spirit of double-posting between here and the QL Forum :-) I 
thought I'd ask my question here, too...


I'm continuing to explore the QL network across a range of 
platforms - now with my refurbished QXL2 card (thanks, Derek!)


The bit-timings on the QXL under SMSQ/E v3.33 (and also on v2.76) 
prove to be slightly-out from the nominal 11.2us, resulting in 
failed/unreliable comms with both my Iss7 QL and my prototype QNET 
to USB adapter (still a work in progress.)


Given that the timings-constants for the NET device are exposed 
under SMSQ/E and stored ready for adjustment in the DDB of the NET 
device, I'm trying to find the base address of the DDB from SBasic.


Any help appreciated!

The original post appears here, with pictures :-)

 https://qlforum.co.uk/viewtopic.php?f=3=2462

Regards,
Martyn.

___
QL-Users Mailing List

___
QL-Users Mailing List



___
QL-Users Mailing List


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

___
QL-Users Mailing List

Re: [Ql-Users] How do you find the Driver Definition Block (DDB) base-address from SBASIC for the NET device

2018-05-19 Thread Martyn Hill via Ql-Users

Thanks Wolfgang (and Jan via the Forum)

Having now found what looks like the DDB - taking in to account the -$18 
offset from the entry in the CDB - the resultant list of words at offset 
ndt_ctab ($50) looks suspicious, thus:


50:       0
52:     124
54:  -18236
56:       0
58:      36
5A:       1
...
6A:   20085
6C:       0
6E:     134

The '20085' at offset $6A in particular looks more like an RTS 
instruction than the timing constant for 'receive bit timeout'.


Anyway, I'll keep digging. Thanks!

Martyn.

On 19/05/2018 09:41, Wolf via Ql-Users wrote:

Hi,

The best way would be to get the channel definition block (CDB) for a 
channel to the device. I don't know offhand of a Basic keyword that 
will do it for you, Toolkit III used to have such a function, I don't 
know whether that still available, though.


If you have that, then the pointer to the driver definition block 
(DDB) lies at offset chn_drvr (=4) in the CDB - you can just PEEK_L 
that. Be careful, however, the pointer there normally points to offset 
iod_iolk (=$18) within the DDB, so all other offsets should be reduced 
by that same amount.


HTH

Wolfgang

On 18/05/2018 22:01, Martyn Hill via Ql-Users wrote:

Hi everyone

In the spirit of double-posting between here and the QL Forum :-) I 
thought I'd ask my question here, too...


I'm continuing to explore the QL network across a range of platforms 
- now with my refurbished QXL2 card (thanks, Derek!)


The bit-timings on the QXL under SMSQ/E v3.33 (and also on v2.76) 
prove to be slightly-out from the nominal 11.2us, resulting in 
failed/unreliable comms with both my Iss7 QL and my prototype QNET to 
USB adapter (still a work in progress.)


Given that the timings-constants for the NET device are exposed under 
SMSQ/E and stored ready for adjustment in the DDB of the NET device, 
I'm trying to find the base address of the DDB from SBasic.


Any help appreciated!

The original post appears here, with pictures :-)

 https://qlforum.co.uk/viewtopic.php?f=3=2462

Regards,
Martyn.

___
QL-Users Mailing List

___
QL-Users Mailing List


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

___
QL-Users Mailing List

[Ql-Users] How do you find the Driver Definition Block (DDB) base-address from SBASIC for the NET device

2018-05-18 Thread Martyn Hill via Ql-Users

Hi everyone

In the spirit of double-posting between here and the QL Forum :-) I 
thought I'd ask my question here, too...


I'm continuing to explore the QL network across a range of platforms - 
now with my refurbished QXL2 card (thanks, Derek!)


The bit-timings on the QXL under SMSQ/E v3.33 (and also on v2.76) prove 
to be slightly-out from the nominal 11.2us, resulting in 
failed/unreliable comms with both my Iss7 QL and my prototype QNET to 
USB adapter (still a work in progress.)


Given that the timings-constants for the NET device are exposed under 
SMSQ/E and stored ready for adjustment in the DDB of the NET device, I'm 
trying to find the base address of the DDB from SBasic.


Any help appreciated!

The original post appears here, with pictures :-)

    https://qlforum.co.uk/viewtopic.php?f=3=2462

Regards,
Martyn.

___
QL-Users Mailing List

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

2018-02-27 Thread Martyn Hill via Ql-Users

My dear Marcel

Your write-up on the debugging process is so welcome!

I had been planning to try a monitor, but was unsure how to trap code 
running in ROM, seeing as you can't set breakpoints there.


So I meandered along in my own naive way instead comparing what source 
code I had available, disassembly of some parts of the working ROM 
version and empirical testing :-)


Is QMON yet available as freeware, or otherwise for purchase?

Yours, gratefully...

M.


On 27/02/2018 13:32, Marcel Kilgus via Ql-Users wrote:

Martyn's reply was also sent to the list but probably wasn't published
because it was HTML and my original replay wasn't published because it
came from the wrong sender address... so anyway, here it is once more:

Martyn Hill wrote:

OMGosh!

Do you know how long I have been staring at the serio/relio code -
but failed to see that potential flaw?

I shall test by recompiling Minnie an report back here...

Thank you, Marcel, bl**dy genius!!!

Thanks and you're welcome ;) It actually wasn't very difficult so I
have written up a short essay about how I go about debugging this kind
of stuff

https://www.kilgus.net/2018/02/27/debugging-minerva/

It also includes ROM images with the fix. I didn't increase the
version number for now because, well, Minerva is not my project and
we're running out of "sub 2.00" version numbers, which might have
compatibility implications in the future.

Marcel

___
QL-Users Mailing List


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

___
QL-Users Mailing List


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

2018-02-27 Thread Martyn Hill via Ql-Users

Thanks Marcel!


On 27/02/2018 13:33, Marcel Kilgus via Ql-Users wrote:

Martyn Hill via Ql-Users wrote:

I looked again at the other serio vectored routines that themselves call
io_pend and determined that it was wise to preserve /their/ serio key in
d0 before resetting to 0 for io_pend, to avoid hammering their ability
to locate the correct NET driver vector. This step may prove
unnecessary, but harmless.

The called routines do not rely on the value in D0 and they have to
overwrite it anyway with their result status. So yeah, it's harmless
but unnecessary ;)


Both with and without TK2 active, Minnie v1.98b was able to successfully
LBYTES the image from another QL across the QLNet.

:-)


As MK put it - back to '...more productive work' - aka, the QLNet to USB
Bridge adapter (QLUB) - just another couple of weeks before I complete
the SMSQ/E coding to talk to the uC...

Sounds like a much better use of your time, good luck :-)

Marcel

___
QL-Users Mailing List


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

___
QL-Users Mailing List


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

2018-02-25 Thread Martyn Hill via Ql-Users

Hi Per

That would be excellent - thank you!

I'll rely on Google to translate what I can't decipher of the German.

I'll PM you via the QL Forum with my personal email, if that's alright.

Thanks again!

M.


On 25/02/2018 18:56, pjwitte via Ql-Users wrote:
I have a commented (in German!) disassembly of V1.89, if thats of any 
interest. It seems quite thorough and detailed, but Ive not tried to 
reassemble it. Let me know where to send it if you want it.


Per
On 25/02/2018 15:51, Martyn Hill via Ql-Users wrote:

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

<>
___
QL-Users Mailing List


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

___
QL-Users Mailing List


Re: [Ql-Users] New hardware announcement...

2018-02-25 Thread Martyn Hill via Ql-Users

Thanks - just heard from DP via the Forum!

Can't wait to see this project come to fruition :-)

M.
On 25/02/2018 15:46, Graeme Gregory via Ql-Users wrote:

He did, you were a few hours late 

G

On Sun, 25 Feb 2018, at 2:53 PM, Martyn Hill via Ql-Users wrote:

Hi Dave

...and, did you? I was late joining the online Chat, so might have
missed it :-(

M.


On 20/02/2018 21:45, Dave Park via Ql-Users wrote:

Hi all,

I'll be making a new hardware announcement this Saturday 24th at 8pm UK
time.

To join in, see the videos/photos and ask questions, join us on the QL
Forum chatroom at 8pm.

This new piece of hardware is not a small thing*, it is not a clone of
existing hardware but is completely new hardware for the BBQL.

To get to the QL Forum chatroom, simply surf to qlforum.co.uk, then click
on "Online Chat" at the top of the page, choose a screen name, and click
join. Anything you type will be seen by everyone.


​*ok, it IS a small thing. 100x63mm, but that includes a through-connector,
but it packs a punch for the size!


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


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

___
QL-Users Mailing List

Re: [Ql-Users] New hardware announcement...

2018-02-25 Thread Martyn Hill via Ql-Users

Hi Dave

...and, did you? I was late joining the online Chat, so might have 
missed it :-(


M.


On 20/02/2018 21:45, Dave Park via Ql-Users wrote:

Hi all,

I'll be making a new hardware announcement this Saturday 24th at 8pm UK
time.

To join in, see the videos/photos and ask questions, join us on the QL
Forum chatroom at 8pm.

This new piece of hardware is not a small thing*, it is not a clone of
existing hardware but is completely new hardware for the BBQL.

To get to the QL Forum chatroom, simply surf to qlforum.co.uk, then click
on "Online Chat" at the top of the page, choose a screen name, and click
join. Anything you type will be seen by everyone.


​*ok, it IS a small thing. 100x63mm, but that includes a through-connector,
but it packs a punch for the size!



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

___
QL-Users Mailing List

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

2018-02-25 Thread Martyn Hill via Ql-Users

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

Re: [Ql-Users] New WIN/SDC driver: RENAME curiosity...

2018-01-29 Thread Martyn Hill via Ql-Users
...and, true to form, within hours of reporting the issue, Wolfgang has 
delivered a fix for me to test - and it works!


I understand that it may be another 24hours or so before he gets around 
to uploading the fixed version to the original site.


Thank you WL!
M.

On 29/01/2018 08:42, Martyn Hill wrote:

Hi WL!

Yes - that was just my typo :-)


Martyn Hill
Sent from my mobile - please excuse spelling errors...


On 29 Jan 2018 07:31, Wolf via Ql-Users <ql-users@lists.q-v-d.com> wrote:

sorry, this was meant for Martyn

On 29/01/2018 07:25, Wolf via Ql-Users wrote:
>
> Hi Martyn,
>
> thanks for pointing this out, I'll have a look.
>
> I presume that the difference between "targetPth$" and "targetPath$"
> below is just a typo here.
>
> Wolfgang
>
>
> On 28/01/2018 18:20, Martyn Hill via Ql-Users wrote:
>> Hi everyone
>>
>> Thanks to Wolfgang for his work on porting the WIN driver to QDOS and
>> merging with the SDC driver.
>>
>> As a result, I am now able to mount a number of .WIN container files
>> as WIN1_, WIN2_ etc and in the process, ease the transfer of files
>> from QPC to my QL(s).
>>
>> Loving it!
>>
>> One curiosity that I have spotted which worked as expected with the
>> original QubIDE/SDC driver but now throws an error under WIN/SDC is
>> use of RENAME. I've also posted this to the QL Forum, but as I
>> understand WL tends to hang-out here more than there, I'm posting to
>> this list as well:
>>
>> I'm running Minerva v1.98 on this QL, with the WIN/SDC driver burnt in
>> to the usual 16k ROM slot at 0c000.
>> Using my home-brew file-transfer app, I moved a file over to the QL,
>> as I do all the time from QPC. The app captures the file-fragments via
>> the SERial port in to a temporary file and, once the transfer is
>> complete, renames the tmp file to its final resting place on the SD
>> Card, with a given name.
>> The following worked fine under QubIDE/SDC, but errors-out with the
>> WIN/SDC driver (all else being equal):
>>
>>    RENAME tmpFile$ TO targetPth$ & fileName$
>>
>> The variables in question in this case were:
>>
>>    tmpFile$ = 'sdc1_tmp_1801281611'
>>    targetPath$ & fileName$ = 'sdc1_RMS_RMS_v4t4k_exe'
>>
>> The first 'RMS_' in the target file-path is a hard directory on SDC1_.
>> A WIN_USE 'sdc' appears in my Boot file, prior to running this app.
>> The error reported under WIN/SDC is 'bad name' and appears the same
>> whether using RENAME from the command line with explicit names in
>> place of the variables and even trying WREN in place of RENAME.
>> I can COPY the tmp file to its new name without problem (i.e.
>> replacing RENAME with COPY and keeping the rest as-is.) I can then
>> delete the original file manually as well.
>> When using WREN, the expected 'Do you want to copy xxx to yyy' prompt
>> appears and the error appears only after accepting with 'Y'.
>>
>> Any thoughts?
>> ___
>> QL-Users Mailing List
> ___
> QL-Users Mailing List
___
QL-Users Mailing List 


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

___
QL-Users Mailing List

[Ql-Users] New WIN/SDC driver: RENAME curiosity...

2018-01-28 Thread Martyn Hill via Ql-Users

Hi everyone

Thanks to Wolfgang for his work on porting the WIN driver to QDOS and 
merging with the SDC driver.


As a result, I am now able to mount a number of .WIN container files as 
WIN1_, WIN2_ etc and in the process, ease the transfer of files from QPC 
to my QL(s).


Loving it!

One curiosity that I have spotted which worked as expected with the 
original QubIDE/SDC driver but now throws an error under WIN/SDC is use 
of RENAME. I've also posted this to the QL Forum, but as I understand WL 
tends to hang-out here more than there, I'm posting to this list as well:


I'm running Minerva v1.98 on this QL, with the WIN/SDC driver burnt in 
to the usual 16k ROM slot at 0c000.
Using my home-brew file-transfer app, I moved a file over to the QL, as 
I do all the time from QPC. The app captures the file-fragments via the 
SERial port in to a temporary file and, once the transfer is complete, 
renames the tmp file to its final resting place on the SD Card, with a 
given name.
The following worked fine under QubIDE/SDC, but errors-out with the 
WIN/SDC driver (all else being equal):


  RENAME tmpFile$ TO targetPth$ & fileName$

The variables in question in this case were:

  tmpFile$ = 'sdc1_tmp_1801281611'
  targetPath$ & fileName$ = 'sdc1_RMS_RMS_v4t4k_exe'

The first 'RMS_' in the target file-path is a hard directory on SDC1_.
A WIN_USE 'sdc' appears in my Boot file, prior to running this app.
The error reported under WIN/SDC is 'bad name' and appears the same 
whether using RENAME from the command line with explicit names in place 
of the variables and even trying WREN in place of RENAME.
I can COPY the tmp file to its new name without problem (i.e. replacing 
RENAME with COPY and keeping the rest as-is.) I can then delete the 
original file manually as well.
When using WREN, the expected 'Do you want to copy xxx to yyy' prompt 
appears and the error appears only after accepting with 'Y'.


Any thoughts?
___
QL-Users Mailing List

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

2018-01-24 Thread Martyn Hill via Ql-Users

Is personal consumption legal in France ? :-)


On 24/01/2018 12:32, Wolf via Ql-Users wrote:

Hi,


Got anything cooking?


I've got my fingers in many pies that are a-cooking, but mostly for 
in-house consumption.


Wolfgang
___
QL-Users Mailing List


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

___
QL-Users Mailing List


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

2018-01-22 Thread Martyn Hill via Ql-Users

Hi WL

This is BRILLIANT - thank you so much for taking the initiative!

From reading the PDF, it also appears to bring the possibility of 
mapping multiple WIN drives (1..8) to distinct container files 
simultaneously, which - as far as I was aware - could not be achieved 
before with the original (and very effective, within its intended scope) 
SDC driver.


Do we have any understanding of the QL (Minerva) memory utilisation of 
WIN as compared to SDC? I'm thinking about the need with the SDC driver 
to keep container file-size small in order not to consume QL memory too 
aggressively for its (equivalent of) slave-blocks. E.g. for an 
unexpanded QL of 128k, about 1.5MB container size seems to be the limit 
before you take too much memory to run the machine effectively.


If only we could find another builder/supplier of the SD interface... :-)

Martyn Hill.

On 22/01/2018 13:41, Graeme Gregory via Ql-Users wrote:


On Mon, 22 Jan 2018, at 9:41 AM, Wolfgang Lenerz via Ql-Users wrote:

Hi all,

I've released a new driver for QL-SD that uses standard qxl.win drives
instead of Qubide ones.

It's for Minerva only, though.

You can download it from www.wlenerz.com/QLSD


And the next trick make qubide do the same :-D

Graeme
___
QL-Users Mailing List


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

___
QL-Users Mailing List


Re: [Ql-Users] Possible bug in the (experimental) QubIDE feature of QXLWinReader

2017-10-30 Thread Martyn Hill via Ql-Users

Hi everyone

Despite his busy schedule, Wolfgang made a new version of QXLWinReader 
available to me privately and I have tested the new behaviour. The issue 
appears to be addressed and FTYP is now returning the correct file-type 
for sub-directories copied from a WIN drive to a BDI image on my SD-Card.


Wow - that is a quick release-cycle! Working in the software industry 
myself, I know our customers would love that kind of service!


I'll leave it to Wolfgang to say when he's ready to upload the new 
version to his site for general release.


Thanks Wolfgang!

M.

On 30/10/2017 10:21, Martyn Hill wrote:


Hi Wolfgang!

For sure - no pressure - I can fix-up the issue on my SD-Card with a 
little script in the meantime.


As for on which FS the issue takes-place; it shows itself on the 
destination side (QubIDE/SD-Card image) - running FTYP on the source 
QLWA/WIN source returns the expected '255' against all 
(sub)directories, whereas after copying (en-masse) to a BDI image on 
my mounted SD-Card, the same sub-directories return '0' to FTYP once 
re-mounted on the SDC-equipped QL - but are still marked as 
directories in the parent (hence tagged with the ' ->' marker when 
DIRing the parent.)


Warm regards - and thanks again for a really valuable utility!

M.
On 30/10/2017 03:39, Wolf via Ql-Users wrote:

Hi,

thanks for pointing this out.

I'm a little short on time right now, but will check this as soon as 
possible.


Under which file system does this error arise, QLWA ou Qubide?

Regards

Wolfgang


On 29/10/2017 22:12, Martyn Hill via Ql-Users wrote:

Hi list and especially Wolfgang

Not sure the best way to report the issue, but as per my recent 
thread on the Forum (http://qlforum.co.uk/viewtopic.php?f=3=2146), 
I seem to have uncovered an odd behaviour when copying directory 
structures from WIN to a QL.BDI image file on SDC.


I know this feature is still experimental, but I already use it 
quite a lot - especially after corrupting my SD-Card sufficiently 
that it wouldn't get recognised on the QL, but QXLWinReader was able 
to read all the files and directories (somehow!), allowing me to 
recreate the QL.BDI image file and restore all the contents. At the 
moment, this valuable little program is my preferred way to transfer 
large amounts of data between QPC and my QL.


In short, whilst the directory structures are all copied across with 
their files (and further sub-directories), it would appear that the 
file-header copy inside each sub-directory file itself is not copied 
across intact. The effect of this is that, whilst a DIR listing 
shows the ' ->' against such sub-directories indicating that it is 
recognised as a directory-file, when you use FTYP to query the 
sub-dir path, it returns '0' as for a normal file.


I've tested this - as documented on the Forum - and think I've ruled 
out anything else (like the typical user-error that plagues most of 
my QL work!)


Would love to see this investigated and possibly addressed!

Regards,
Martyn.
___
QL-Users Mailing List



___
QL-Users Mailing List




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

___
QL-Users Mailing List


Re: [Ql-Users] Possible bug in the (experimental) QubIDE feature of QXLWinReader

2017-10-30 Thread Martyn Hill via Ql-Users

Hi Wolfgang!

For sure - no pressure - I can fix-up the issue on my SD-Card with a 
little script in the meantime.


As for on which FS the issue takes-place; it shows itself on the 
destination side (QubIDE/SD-Card image) - running FTYP on the source 
QLWA/WIN source returns the expected '255' against all (sub)directories, 
whereas after copying (en-masse) to a BDI image on my mounted SD-Card, 
the same sub-directories return '0' to FTYP once re-mounted on the 
SDC-equipped QL - but are still marked as directories in the parent 
(hence tagged with the ' ->' marker when DIRing the parent.)


Warm regards - and thanks again for a really valuable utility!

M.
On 30/10/2017 03:39, Wolf via Ql-Users wrote:

Hi,

thanks for pointing this out.

I'm a little short on time right now, but will check this as soon as 
possible.


Under which file system does this error arise, QLWA ou Qubide?

Regards

Wolfgang


On 29/10/2017 22:12, Martyn Hill via Ql-Users wrote:

Hi list and especially Wolfgang

Not sure the best way to report the issue, but as per my recent 
thread on the Forum (http://qlforum.co.uk/viewtopic.php?f=3=2146), 
I seem to have uncovered an odd behaviour when copying directory 
structures from WIN to a QL.BDI image file on SDC.


I know this feature is still experimental, but I already use it quite 
a lot - especially after corrupting my SD-Card sufficiently that it 
wouldn't get recognised on the QL, but QXLWinReader was able to read 
all the files and directories (somehow!), allowing me to recreate the 
QL.BDI image file and restore all the contents. At the moment, this 
valuable little program is my preferred way to transfer large amounts 
of data between QPC and my QL.


In short, whilst the directory structures are all copied across with 
their files (and further sub-directories), it would appear that the 
file-header copy inside each sub-directory file itself is not copied 
across intact. The effect of this is that, whilst a DIR listing shows 
the ' ->' against such sub-directories indicating that it is 
recognised as a directory-file, when you use FTYP to query the 
sub-dir path, it returns '0' as for a normal file.


I've tested this - as documented on the Forum - and think I've ruled 
out anything else (like the typical user-error that plagues most of 
my QL work!)


Would love to see this investigated and possibly addressed!

Regards,
Martyn.
___
QL-Users Mailing List



___
QL-Users Mailing List


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

___
QL-Users Mailing List


[Ql-Users] Possible bug in the (experimental) QubIDE feature of QXLWinReader

2017-10-29 Thread Martyn Hill via Ql-Users

Hi list and especially Wolfgang

Not sure the best way to report the issue, but as per my recent thread 
on the Forum (http://qlforum.co.uk/viewtopic.php?f=3=2146), I seem to 
have uncovered an odd behaviour when copying directory structures from 
WIN to a QL.BDI image file on SDC.


I know this feature is still experimental, but I already use it quite a 
lot - especially after corrupting my SD-Card sufficiently that it 
wouldn't get recognised on the QL, but QXLWinReader was able to read all 
the files and directories (somehow!), allowing me to recreate the QL.BDI 
image file and restore all the contents. At the moment, this valuable 
little program is my preferred way to transfer large amounts of data 
between QPC and my QL.


In short, whilst the directory structures are all copied across with 
their files (and further sub-directories), it would appear that the 
file-header copy inside each sub-directory file itself is not copied 
across intact. The effect of this is that, whilst a DIR listing shows 
the ' ->' against such sub-directories indicating that it is recognised 
as a directory-file, when you use FTYP to query the sub-dir path, it 
returns '0' as for a normal file.


I've tested this - as documented on the Forum - and think I've ruled out 
anything else (like the typical user-error that plagues most of my QL work!)


Would love to see this investigated and possibly addressed!

Regards,
Martyn.
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Advance Notice 3 - Delay

2017-10-20 Thread Martyn Hill via Ql-Users

Good morning Derek

What a nightmare for you - we wish you a speedy recovery.

If there is still room left on your first 20 for Q68, could I ask to be 
added (incl. the black case, but no need for the PS/2 splitter).


Regards,

Martyn.


On 20/10/2017 09:00, Derek Stewart via Ql-Users wrote:
There will be a slight delay in the availability of the Q68, which I 
stated in a previous message to be available on 09/10/2017


I have had medical problems, I went into hospital on 22/9/17, to have 
a throat operation. This should of been a one day operation.


But there was a problem with the procedure they used and I ended up 
having a Tracheotomy Tube inserted into my airway to keep me alive.


I stayed in The Royal Liverpool Hospital Intensive Care Unit for 12 
days attached to a ventilator, which was assisting my breathing.


The tube was removed and I was discharged home, to the care of a 
visiting District Nurse. The nurse changes the dressings daily.


I have been home for 2 weeks and just now, starting to regain my 
strength and concentration.


There was a notice posted on the QL Forum, regarding the delay, which 
obviously did not get to everyone.


The new date will be 06/11/2017.

Here is the link to the notice:

http://www.qlforum.co.uk/viewtopic.php?f=2=2120#p19180

I am sorry for the delay, I will try to update everyone on a regular 
basis.


With regards to availability of the Q68. I have created a list of 
people who showed interest in date order. Which I will contact to 
arrange the sale of the Q68.




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

___
QL-Users Mailing List