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 <firstname.lastname@example.org> 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 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 _______________________________________________ QL-Users Mailing List