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

2018-02-28 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> Is QMON yet available as freeware, or otherwise for purchase?

I don't think it's available yet, but should be eventually. Wolfgang,
did you by any chance talk to TT about it?

Marcel

___
QL-Users Mailing List


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

2018-02-27 Thread Norman Dunbar via Ql-Users
What Martin says about Qmon!

If/when you come to sell it, I'll have a copy please. I'm using QPC's 68020 and 
Gwass these days for the somrwhat irregular assembly eMagazine and Qmon2, 
standard, doesn't cope well with 68020 instructions. Obviously, that's exactly 
what I'm debugging now!

Cheers,
Norm.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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-27 Thread Marcel Kilgus via Ql-Users
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


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

2018-02-27 Thread Marcel Kilgus via Ql-Users
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


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

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

RESOLVED!

Well, after months and months of head-scratching and testing, thanks to 
Marcel, I now have a version of Minerva v1.98 running with TK2 v2.23 and 
FULL networking!


Just 3 instructions amounting to 6 extra bytes have corrected the issue 
- for the record:


In "io\serio_asm", I added the following based on MK's "quick look" at 
the Minnie v1.98 source:


* v1.98b
move.l  d0,-(sp) Preserve serio key (d0), in case io_pend has been 
called as part of another serio call

moveq   #0,d0 test routine is the first element
*
    bsr.s   vectest set up test routine address (io_pend)
* v1.98b
move.l  (sp)+,d0 Restore original caller's serio key in d0
    bra.s   callit  go do it

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. Hence the move.l d0 to/from the stack, in 
addition to uncommenting the moveq #0,d0 that seems to have been causing 
the trouble with LBYTES all along.


I recompiled the adjusted Minnie source code, according to PJW's 
exceptionally clear instructions (thanks Per for the earlier 
disassembly, BTW...) and re-burnt Min v1.98b + TK2 v2.23 to EPROM and 
tested using my favourite screen image (the "JetPac" SCREEN$ from the 
Spectrum, suitably converted to QL display format.)


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


I've got some more testing to perform before I know nothing else is 
hammered by this small change. Thereafter, I intend to document and make 
available (via Dilwyn's repository?) for anyone to use. That's a weekend 
job... I'll also update my original Forum posting at some point to close 
the loop.


Thanks again for everyone's patience and insights along the way.

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


*Martyn.*

On 27/02/2018 08:14, 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!!!

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


On 26 Feb 2018 23:00, Marcel Kilgus via Ql-Users 
 wrote:


Martyn Hill via Ql-Users wrote:
> 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.

I had a quick look and actually this was caused by Lau trying to save
2 bytes. When you look at io_serio_asm

io_pend
* moveq #0,d0 test routine is the first element
bsr.s vectest set up test routine address
bra.s callit go do it

you see that the moveq is commented out because "d0 is 0 anyway!".
Well, except in the case when io_pend is called through headr1, in
this case D0 has some other value and the whole thing will crash.

I hope you can now resume more productive work :-)

Cheers, 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-26 Thread pjwitte via Ql-Users

Well caught, Marcel :)
Per
On 27/02/2018 00:00, Marcel Kilgus via Ql-Users wrote:

Martyn Hill via Ql-Users wrote:

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.

I had a quick look and actually this was caused by Lau trying to save
2 bytes. When you look at io_serio_asm

io_pend
*moveq   #0,d0   test routine is the first element
 bsr.s   vectest set up test routine address
 bra.s   callit  go do it

you see that the moveq is commented out because "d0 is 0 anyway!".
Well, except in the case when io_pend is called through headr1, in
this case D0 has some other value and the whole thing will crash.

I hope you can now resume more productive work :-)

Cheers, Marcel

___
QL-Users Mailing List




___
QL-Users Mailing List


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

2018-02-26 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> 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.

I had a quick look and actually this was caused by Lau trying to save
2 bytes. When you look at io_serio_asm

io_pend
*moveq   #0,d0   test routine is the first element
bsr.s   vectest set up test routine address
bra.s   callit  go do it

you see that the moveq is commented out because "d0 is 0 anyway!".
Well, except in the case when io_pend is called through headr1, in
this case D0 has some other value and the whole thing will crash.

I hope you can now resume more productive work :-)

Cheers, Marcel

___
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 <ql-users-boun...@lists.q-v-d.com> on behalf of Martyn Hill via 
Ql-Users <ql-users@lists.q-v-d.com>
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


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

2018-02-25 Thread pjwitte via Ql-Users

Ok.
On 25/02/2018 21:05, Martyn Hill via Ql-Users wrote:

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




___
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] Source code availability for Minerva v1.92 or v1.89?

2018-02-25 Thread pjwitte via Ql-Users
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


[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