Re: [Ql-Users] Quanta Library Guide
Ah, seems I am wrong. If e.g. win1_mach_ ist not found, I think, TK2 searches for win1_win1_mach_. I use the following (extract from S_Edit ;-)): SV_BASE is my keyword to return the base of the system variables: 12480 DEFine FuNction file_test(name$) 12490 LOCal default 12495 REMark Read the length of DATAD$ 12500 default=PEEK_W(PEEK_L(SV_BASE+176)) 12506 REMark set the length of DATAD$ to zero, the string itself remains 12510 POKE_W PEEK_L(SV_BASE+176),0 12520 ferr=FOP_IN(#5,name$) 12530 CLOSE#5 12535 REMark restore the length of DATAD$ 12540 POKE_W PEEK_L(SV_BASE+176),default 12550 RETurn ferr 12560 END DEFine file_test I set the data_default to , so I really know, if the file exists or not. Cheers...Ralf - Original Message - From: Ralf Reköndt ralf.rekoe...@t-online.de To: ql-us...@q-v-d.com Sent: Saturday, April 21, 2012 6:50 PM Subject: Re: [Ql-Users] Quanta Library Guide The FOP_xxx functions (and all similar TK2 things) always tried to use the Data default next, if a direct call was unsuccessful. So, if I try to check Win1_test_, and it does not exist, Win1_ is checked next (if Data default), which is very likely to be successful. So you can't be sure, that the correct device was opened. That's why it is better, to set the Data default to , then try, then set it back to where it was before. - Original Message - From: Bob Spelten b...@upcmail.nl To: ql-us...@q-v-d.com Sent: Saturday, April 21, 2012 5:43 PM Subject: Re: [Ql-Users] Quanta Library Guide Op Sat, 21 Apr 2012 16:10:15 +0200 schreef Ralf Reköndt ralf.rekoe...@t-online.de: Hmm, but the TK2 Manual states about OPEN_DIR, so, apart from Level 2, it should be possible. But what kind of directory, if not Level 2? Perhaps just the root one. Section 10 Open and Close The standard QL channel OPEN commands are redefined by Toolkit II to use the data directory. In addition, Toolkit II provides a set of functions for opening files either using a specified channel number (as in the standard QL commands), or they will find and return a vacant channel number. The functions also allow filing system errors to be intercepted and processed by SuperBASIC programs. Commands OPEN #channel, nameopen a file for read/write OPEN_IN #channel, name open a file for input only OPEN_NEW #channel, nameopen a new file OPEN_OVER #channel, name open a new file, if it exists it is overwritten OPEN_DIR #channel, nameopen a directory CLOSE #channelsclose channels The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). The Function FOP_DIR can be used but is not very reliable. I did a quick QDOS test on my demo Q-emuLator where win1_ is a W$ folder, win2_ is a QL floppy. chn= FOP_DIR (win1_): PRINT FTYP(#chn): produced 255. chn= FOP_DIR (win1_mach_): PRINT FTYP (#chn): also produced 255 while mach_ is part of a filename and not a directory! Even chn FOP_DIR (win1_ma): PRINT FTYP (#chn): returned as valid directory. This was not the case with win2_, there a FTYP returned zero for everything. But chn= FOP_DIR (usb1): opened a channel to win2_, PRINT FTYP(#chn): returned zero and DIR usb1_ gave the name of the floppy and the sector count. So this is here not a good level 1 test to see if a device or directory actually exists. Minerva gave the same results. Mind you, even under QPC2 I can happily FOP_OVER (a_file) to my win8_, which is a QXL.WIN on the cdrom! Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Op Fri, 20 Apr 2012 09:00:18 +0200 schreef Daniele Terdina danieleterd...@hotmail.com: SuQcess starts with testing the validity of devices and directories to prevent it from crashing later. For this the TK2 commands FTEST and FTYP are used but these don't seem to work on the device names used by Q-emuLator. Is this just an issue with the non-registered version? Is there any way to test for Q-emuLator from S*Basic so I can skip the test and hope for the best? The unregistered version tries to emulate the original file drivers, which are not level 2. SuQcess seems too big for this version anyway. On a registered copy of Q-emuLator, and with level 2 drivers enabled, FTEST(mdv1_) should return 0 and your check will succeed. On the unregistered version it returns -7, and I think that's the correct behaviour: Although I can't currently check, I believe FTEST(mdv1_) would also return -7 when run on a QL, even if there is a cartridge in the drive. It would be interesting to check. I have no working level 1 QL here, but a test on my SGC-QL (QDOS-TK2) confirmed your suspicion that FTEST(mdv1_) returns -7 even on a level 2 system, after reading mdv1 correctly. The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). There is no SuperBASIC keyword to test for Q-emuLator, but it would be easy to write one if needed, as there is a TRAP#1 command that can be used to detect Q-emuLator. Some years back QLToday wrote about testing the machine you are using by reading the sys_vars (PEEK (sv +167)). The test on Q-emulator returns zero, as the standard QL, so this could be used to assume there is no Level2 device. This number is held in the 5 lowest bits, I believe 14, 15, 18 to 23, 25 to 27 29 are still free. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Hmm, but the TK2 Manual states about OPEN_DIR, so, apart from Level 2, it should be possible. But what kind of directory, if not Level 2? Perhaps just the root one. Section 10 Open and Close The standard QL channel OPEN commands are redefined by Toolkit II to use the data directory. In addition, Toolkit II provides a set of functions for opening files either using a specified channel number (as in the standard QL commands), or they will find and return a vacant channel number. The functions also allow filing system errors to be intercepted and processed by SuperBASIC programs. Commands OPEN #channel, nameopen a file for read/write OPEN_IN #channel, name open a file for input only OPEN_NEW #channel, nameopen a new file OPEN_OVER #channel, name open a new file, if it exists it is overwritten OPEN_DIR #channel, nameopen a directory CLOSE #channelsclose channels The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Some years back QLToday wrote about testing the machine you are using by reading the sys_vars (PEEK (sv +167)). The test on Q-emulator returns zero, as the standard QL, so this could be used to assume there is no Level2 device. This number is held in the 5 lowest bits, I believe 14, 15, 18 to 23, 25 to 27 29 are still free. To check for level 2 drivers present or not, use the IOF.XINF trap #3 with D0=hex4F (QDOS Reference Guide, section 15, page13). Norman Dunbar uses this call for the LEVEL2 function in the djtoolkit, source of which is included with the package on toolkits page of my website showing how to use the test for Level2 drivers. Testing for QemuLator: This is a text which Daniele sent me some time back. As it was a while back, probably best to check with Daniele if this is still valid, or has been extended or whatever. == 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). == Daniele added at the time: 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). ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
On 21 Apr 2012, at 10:10, Ralf Reköndt ralf.rekoe...@t-online.de wrote: snip CLOSE #channelsclose channels What is the syntax? close #2,#3 ? Tony -- t...@firshman.co.ukhttp://firshman.co.uk Voice: +44 (0) 1442 828254 Fax: +44 (0) 1442 828255. Skype: tony firshman TF Services, 29 Longfield Road, Tring, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Yes. From: Tony firshman (Fom TK2 manual...) CLOSE #channelsclose channels What is the syntax? close #2,#3 ? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Op Sat, 21 Apr 2012 16:10:15 +0200 schreef Ralf Reköndt ralf.rekoe...@t-online.de: Hmm, but the TK2 Manual states about OPEN_DIR, so, apart from Level 2, it should be possible. But what kind of directory, if not Level 2? Perhaps just the root one. Section 10 Open and Close The standard QL channel OPEN commands are redefined by Toolkit II to use the data directory. In addition, Toolkit II provides a set of functions for opening files either using a specified channel number (as in the standard QL commands), or they will find and return a vacant channel number. The functions also allow filing system errors to be intercepted and processed by SuperBASIC programs. Commands OPEN #channel, nameopen a file for read/write OPEN_IN #channel, name open a file for input only OPEN_NEW #channel, nameopen a new file OPEN_OVER #channel, name open a new file, if it exists it is overwritten OPEN_DIR #channel, nameopen a directory CLOSE #channelsclose channels The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). The Function FOP_DIR can be used but is not very reliable. I did a quick QDOS test on my demo Q-emuLator where win1_ is a W$ folder, win2_ is a QL floppy. chn= FOP_DIR (win1_): PRINT FTYP(#chn): produced 255. chn= FOP_DIR (win1_mach_): PRINT FTYP (#chn): also produced 255 while mach_ is part of a filename and not a directory! Even chn FOP_DIR (win1_ma): PRINT FTYP (#chn): returned as valid directory. This was not the case with win2_, there a FTYP returned zero for everything. But chn= FOP_DIR (usb1): opened a channel to win2_, PRINT FTYP(#chn): returned zero and DIR usb1_ gave the name of the floppy and the sector count. So this is here not a good level 1 test to see if a device or directory actually exists. Minerva gave the same results. Mind you, even under QPC2 I can happily FOP_OVER (a_file) to my win8_, which is a QXL.WIN on the cdrom! Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
The FOP_xxx functions (and all similar TK2 things) always tried to use the Data default next, if a direct call was unsuccessful. So, if I try to check Win1_test_, and it does not exist, Win1_ is checked next (if Data default), which is very likely to be successful. So you can't be sure, that the correct device was opened. That's why it is better, to set the Data default to , then try, then set it back to where it was before. - Original Message - From: Bob Spelten b...@upcmail.nl To: ql-us...@q-v-d.com Sent: Saturday, April 21, 2012 5:43 PM Subject: Re: [Ql-Users] Quanta Library Guide Op Sat, 21 Apr 2012 16:10:15 +0200 schreef Ralf Reköndt ralf.rekoe...@t-online.de: Hmm, but the TK2 Manual states about OPEN_DIR, so, apart from Level 2, it should be possible. But what kind of directory, if not Level 2? Perhaps just the root one. Section 10 Open and Close The standard QL channel OPEN commands are redefined by Toolkit II to use the data directory. In addition, Toolkit II provides a set of functions for opening files either using a specified channel number (as in the standard QL commands), or they will find and return a vacant channel number. The functions also allow filing system errors to be intercepted and processed by SuperBASIC programs. Commands OPEN #channel, nameopen a file for read/write OPEN_IN #channel, name open a file for input only OPEN_NEW #channel, nameopen a new file OPEN_OVER #channel, name open a new file, if it exists it is overwritten OPEN_DIR #channel, nameopen a directory CLOSE #channelsclose channels The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). The Function FOP_DIR can be used but is not very reliable. I did a quick QDOS test on my demo Q-emuLator where win1_ is a W$ folder, win2_ is a QL floppy. chn= FOP_DIR (win1_): PRINT FTYP(#chn): produced 255. chn= FOP_DIR (win1_mach_): PRINT FTYP (#chn): also produced 255 while mach_ is part of a filename and not a directory! Even chn FOP_DIR (win1_ma): PRINT FTYP (#chn): returned as valid directory. This was not the case with win2_, there a FTYP returned zero for everything. But chn= FOP_DIR (usb1): opened a channel to win2_, PRINT FTYP(#chn): returned zero and DIR usb1_ gave the name of the floppy and the sector count. So this is here not a good level 1 test to see if a device or directory actually exists. Minerva gave the same results. Mind you, even under QPC2 I can happily FOP_OVER (a_file) to my win8_, which is a QXL.WIN on the cdrom! Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
SuQcess starts with testing the validity of devices and directories to prevent it from crashing later. For this the TK2 commands FTEST and FTYP are used but these don't seem to work on the device names used by Q-emuLator. Is this just an issue with the non-registered version? Is there any way to test for Q-emuLator from S*Basic so I can skip the test and hope for the best? The unregistered version tries to emulate the original file drivers, which are not level 2. On a registered copy of Q-emuLator, and with level 2 drivers enabled, FTEST(mdv1_) should return 0 and your check will succeed. On the unregistered version it returns -7, and I think that's the correct behaviour: Although I can't currently check, I believe FTEST(mdv1_) would also return -7 when run on a QL, even if there is a cartridge in the drive. It would be interesting to check. The problem is related to the FTEST command trying to open a file rather than a directory to verify its existance. In SMSQ/E a directory can be opened as a file, but in QDOS I don't think it can. The correct way to check for the validity of devices and directories would be to attempt to open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than D3=1). There is no SuperBASIC keyword to test for Q-emuLator, but it would be easy to write one if needed, as there is a TRAP#1 command that can be used to detect Q-emuLator. Daniele ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Op Tue, 17 Apr 2012 07:55:38 +0200 schreef Daniele Terdina danieleterd...@hotmail.com: My tests were done on a W$-Vista with Q-emuLator 2.5 and 3.1., with JS and both the old DATA_bin and latest 2.13. Only 3.1 JS produces the errors, the DATA_bin version makes no difference. I looks like something changed between Q-emuLator 2.5 3.1 to stop DBAS from working. Bob I've looked into this and there is a change in behaviour in version 3.0 which causes this issue. The change was for compatibility reasons to allow some old games to run. DATA_BIN is patching the directory device drivers to be able to intercept a special new I/O command. On a (JS) QL, I think this would _not_ work for the MDV driver as the device driver definition is in ROM and can't be patched (actually, it could still be patched, but only by using a different method). But it works for other device drivers like FLP that are defined in RAM. Up to version 2.5, the additional Q-emuLator device driver definitions (additional definitions are necessary as a JS ROM doesn't know about 'FLP' and 'TCP', for example) were in RAM and DATA_BIN used to work fine, but later I changed the definitions to be in ROM and DATA_BIN is not able to patch the drivers anymore. The reason for the change is that the RAM definitions were causing incompatibilities with some old software that expected to find some QDOS data structures at fixed addresses in the QL memory, but the extra memory used by Q-emuLator's device drivers was causing these addresses to be off by a few bytes. Finally, I only activated this change for Sinclair ROMs, as those old QL programs wouldn't work on Minerva anyways, and this explains why DATA_BIN still runs fine under Q-emuLator 3 when using a Minerva ROM or SMSQ/E. I'll think about ways of mantaining compatibilities with both DATA_BIN and the old software that doesn't like extra drivers to be in RAM. In the meantime, the workaround on Q-emuLator version 3 is to use the Minerva ROM. Daniele Thanks for this explanation Daniele. During my testing I tried to get my SuQcess front end for DBAS to run but ran into another problem. SuQcess starts with testing the validity of devices and directories to prevent it from crashing later. For this the TK2 commands FTEST and FTYP are used but these don't seem to work on the device names used by Q-emuLator. Is this just an issue with the non-registered version? Is there any way to test for Q-emuLator from S*Basic so I can skip the test and hope for the best? Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Morning all, A few comments, it seems to have been busy on here over the weekend. ;-) On 15/04/12 13:47, Dilwyn Jones wrote: The bad parameter error is related to a file system TRAP#3 call with D0=$44. Do you know what this trap is supposed to do? The trap in question is the only trap introduced by the DBAS author. It sets up a vector for all the DBAs syscalls. It needs to be executed AFTER the directory driver(s) in question are first used. Maybe, just maybe, a dir flp1_ before running the system will help? I'm assuming of course that the system runs from a hard drive but the file is on flp1_ otherwise, the directory drivers for flp1_ should be set up when the libguide was booted from flp1_. I originally developed this on a QL system, JS ROM, running with a Miracle Hard drive. That gave me win1_ and win2_ for developing. I've tried to recompile with the actual return from the open as database call, but because I'm now on QPC without a miracle hard drive, win1_ and win2_ are not what they were when I built this system originally. Hopefully, at lunch time, I'll have time to fix my make files to make them work again! I think, also, that the database_h file #includes a file from C68 named ansi_h but I don't see that file any more. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Op Mon, 16 Apr 2012 12:35:15 +0200 schreef Norman Dunbar nor...@dunbar-it.co.uk: Morning all, A few comments, it seems to have been busy on here over the weekend. ;-) On 15/04/12 13:47, Dilwyn Jones wrote: The bad parameter error is related to a file system TRAP#3 call with D0=$44. Do you know what this trap is supposed to do? The trap in question is the only trap introduced by the DBAS author. It sets up a vector for all the DBAs syscalls. It needs to be executed AFTER the directory driver(s) in question are first used. Maybe, just maybe, a dir flp1_ before running the system will help? I'm assuming of course that the system runs from a hard drive but the file is on flp1_ otherwise, the directory drivers for flp1_ should be set up when the libguide was booted from flp1_. I originally developed this on a QL system, JS ROM, running with a Miracle Hard drive. That gave me win1_ and win2_ for developing. I've tried to recompile with the actual return from the open as database call, but because I'm now on QPC without a miracle hard drive, win1_ and win2_ are not what they were when I built this system originally. Hopefully, at lunch time, I'll have time to fix my make files to make them work again! I think, also, that the database_h file #includes a file from C68 named ansi_h but I don't see that file any more. I have copied Libguide_exe _dbs to win3_, a hard drive map, and ran it from there. Doing a dir win3_ doesn't make a difference in producing the error. I also tried DBAS's own DBPTR_exe, this just died when trying to open a dbs file from win3_. My tests were done on a W$-Vista with Q-emuLator 2.5 and 3.1., with JS and both the old DATA_bin and latest 2.13. Only 3.1 JS produces the errors, the DATA_bin version makes no difference. I looks like something changed between Q-emuLator 2.5 3.1 to stop DBAS from working. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
On 16/04/2012 12:19, Bob Spelten wrote: Op Mon, 16 Apr 2012 12:35:15 +0200 schreef Norman Dunbar nor...@dunbar-it.co.uk: Morning all, A few comments, it seems to have been busy on here over the weekend. ;-) On 15/04/12 13:47, Dilwyn Jones wrote: The bad parameter error is related to a file system TRAP#3 call with D0=$44. Do you know what this trap is supposed to do? The trap in question is the only trap introduced by the DBAS author. It sets up a vector for all the DBAs syscalls. It needs to be executed AFTER the directory driver(s) in question are first used. Maybe, just maybe, a dir flp1_ before running the system will help? I'm assuming of course that the system runs from a hard drive but the file is on flp1_ otherwise, the directory drivers for flp1_ should be set up when the libguide was booted from flp1_. I originally developed this on a QL system, JS ROM, running with a Miracle Hard drive. That gave me win1_ and win2_ for developing. I've tried to recompile with the actual return from the open as database call, but because I'm now on QPC without a miracle hard drive, win1_ and win2_ are not what they were when I built this system originally. Hopefully, at lunch time, I'll have time to fix my make files to make them work again! I think, also, that the database_h file #includes a file from C68 named ansi_h but I don't see that file any more. I have copied Libguide_exe _dbs to win3_, a hard drive map, and ran it from there. Doing a dir win3_ doesn't make a difference in producing the error. I also tried DBAS's own DBPTR_exe, this just died when trying to open a dbs file from win3_. My tests were done on a W$-Vista with Q-emuLator 2.5 and 3.1., with JS and both the old DATA_bin and latest 2.13. Only 3.1 JS produces the errors, the DATA_bin version makes no difference. I looks like something changed between Q-emuLator 2.5 3.1 to stop DBAS from working. Bob I agree - I have also tried running the program on a JS ROM QL without any problems. I have forwarded the files and details to Daniele so that he can investigate further. -- Rich Mellor RWAP Services Specialist Enuuk Auction Programming Services www.rwapservices.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
On 16/04/12 12:56, Rich Mellor wrote: I have forwarded the files and details to Daniele so that he can investigate further. Aha, this means I'm off the hook, for now! ;-) Cheers, Norm. PS. I have downloaded Q-Emulator and I've also tested it with JS and Minerva ROMS. Same problems as everyone, JS fails. One thing is exceedingly clear, we didn't half put up with really slow responses back in 1984 didn't we? God it's slow in QL mode! ;-) -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Hi Lee, ... Tolerance and expectation are the norm Norm. Nah, it's just I'm used to faster now that I have QPC. I remember the days of loading programs off microdrive. It was ok until I got a Trump card, then it was far too slow! Then I upgraded to a Gold Card, QXL, QPC and so on, getting faster and faster all the time. Students we get from school nowadays have a very short attention span and activities have to be in 10 minute bursts otherwise bordem and pandemonium become the issue you then have to deal with. I have a friend who is a teacher, she says the same thing. Plus, they want instant gratification. As in: What do you want to be when you grow up? Famous! Famous for what? Just famous. And I don't want to have to work at it! Sounds more like Big Bloody Brother, X Factor or Pop Idol has a lot to answer for. What gets on my lady bumps is the dumbing down of everything, to cope with this lack of attention span. When I was 18, I could follow a decent program on Quantum Physics - say Horizon - without needing reminded every two minutes what was said two minutes ago. Watching Horizon nowadays is painful. My personal feeling on this point is this i sa result of fast food (content of chemicals not the name) fizzy drinks and all the chemicals it entails affecting 2nd 3rd generation people. I couldn't say to be honest, you could well be right. The BB QL emulated or not, is still faster than a Windows PC booting up from power on, isn't it? It is, yes, booting even from hibernation too. But you only boot once, unless you are running Windows and/or you are Dilwyn (!) it's how responsive it is when it's running that counts. Cheers, Norm. On Mon, Apr 16, 2012 at 2:10 PM, Norman Dunbarnor...@dunbar-it.co.ukwrote: On 16/04/12 12:56, Rich Mellor wrote: I have forwarded the files and details to Daniele so that he can investigate further. Aha, this means I'm off the hook, for now! ;-) Cheers, Norm. PS. I have downloaded Q-Emulator and I've also tested it with JS and Minerva ROMS. Same problems as everyone, JS fails. One thing is exceedingly clear, we didn't half put up with really slow responses back in 1984 didn't we? God it's slow in QL mode! ;-) -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 __**_ QL-Users Mailing List http://www.q-v-d.demon.co.uk/**smsqe.htmhttp://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Norman Dunbar wrote: The BB QL emulated or not, is still faster than a Windows PC booting up from power on, isn't it? It is, yes, booting even from hibernation too. But you only boot once, unless you are running Windows and/or you are Dilwyn (!) it's how responsive it is when it's running that counts. Ahem, excuse me!!! _*sulk*_ :o) Dilwyn ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
My tests were done on a W$-Vista with Q-emuLator 2.5 and 3.1., with JS and both the old DATA_bin and latest 2.13. Only 3.1 JS produces the errors, the DATA_bin version makes no difference. I looks like something changed between Q-emuLator 2.5 3.1 to stop DBAS from working. Bob I've looked into this and there is a change in behaviour in version 3.0 which causes this issue. The change was for compatibility reasons to allow some old games to run. DATA_BIN is patching the directory device drivers to be able to intercept a special new I/O command. On a (JS) QL, I think this would _not_ work for the MDV driver as the device driver definition is in ROM and can't be patched (actually, it could still be patched, but only by using a different method). But it works for other device drivers like FLP that are defined in RAM. Up to version 2.5, the additional Q-emuLator device driver definitions (additional definitions are necessary as a JS ROM doesn't know about 'FLP' and 'TCP', for example) were in RAM and DATA_BIN used to work fine, but later I changed the definitions to be in ROM and DATA_BIN is not able to patch the drivers anymore. The reason for the change is that the RAM definitions were causing incompatibilities with some old software that expected to find some QDOS data structures at fixed addresses in the QL memory, but the extra memory used by Q-emuLator's device drivers was causing these addresses to be off by a few bytes. Finally, I only activated this change for Sinclair ROMs, as those old QL programs wouldn't work on Minerva anyways, and this explains why DATA_BIN still runs fine under Q-emuLator 3 when using a Minerva ROM or SMSQ/E. I'll think about ways of mantaining compatibilities with both DATA_BIN and the old software that doesn't like extra drivers to be in RAM. In the meantime, the workaround on Q-emuLator version 3 is to use the Minerva ROM. Daniele ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Have you tried a more recent version of DATA_BIN? The supplied one is so old there is no version number, now 2.13 (21/2/98). Bob Have tried v2.13 of DATA_BIN dbase handler on Q-emuLator, and got the following results: 1. works ok on version JM ROM 2. fails on version JS supplied with QemuLator 3. Fails on version JS-4M ROM (the 4MB RAM version) 4. fails on standard JS ROM from my website (just in case of outside possibility ROM supplied with QemuLator was corrupt) 5. fails also on jsu.rom 5. works OK on Minerva 1.97 Unfortunately my JS QL is boxed up in the attic and I can't get at it. Can anyone try the library guide on a JS ROM QL which then ought to help us try to ascertain if it is a JS ROM or q-emulator-with-JS-rom problem, and then pin it down to what in DBAS is happening. Dilwyn ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Quanta Library Guide
Daniele has looked at this issue and to quote his comments: The bad parameter error is related to a file system TRAP#3 call with D0=$44. Do you know what this trap is supposed to do? Here's the Trap #3 d0=$44 notes for the DATAREF_DOC document from DBAS. Dilwyn 2) EUSING THE DATABASE TRAP To find out the database version number and the vector base address (pointer to list of vectors), a trap must be used. The trap is only available on DIRECTORY DEVICE DRIVERS (these are devices which can produce a directory, ie: respond to a DIR procedure from BASIC) that were linked in when the CALL procedure or the DATA_EXT procedure was issued. So make sure all the Device Drivers that you are going to use are installed before the package is CALLed or DATA_EXTed. DIRECTORY DEVICE DRIVERS include things like MDV, FLP, WIN, RAM, and N, but not NET, PIPE, CON, SCR, SER, and PAR. To use the package with the network file server, any machine that wishes to use it, must have the package in memory, or a crash will certainly occur. Eg: QL net no. 1 has DATA_BIN in memory, and a hard disk. QL net no. 2 has neither. If QL 2 accesses the trap (see below) on QL 1's hard disk, then the operation may be successful. If it then tries to access vectors at the address returned, a crash will almost certainly occur. However if QL 2 has DATA_BIN in memory, and QL 1 has or has not, then: All accesses by QL 2 to the package will not crash, provided no duff values (eg: Database ID) are supplied. The trap: FS.DBASE TRAP #3 D0=$44 Call parameters Return Parameters D1 D1.L Ascii version number D2 D2.L Preserved D3.W TimeoutD3.L Preserved A0.L Channel ID A0.L Preserved A1 A1.L Vector base address A2 A2.L Preserved Error return: ERR.BP Not implemented ERR.NO Channel not open ERR.NC Not complete ERR.NI Not implemented The vector base address should never change, so it should be safe to do this trap once only. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
