Re: [Ql-Users] New QPC release ?
Op 9/04/2019 om 17:55 schreef pjwitte via Ql-Users: On 09/04/2019 12:51, François Van Emelen via Ql-Users wrote: Op 8/04/2019 om 14:58 schreef pjwitte via Ql-Users: What seems to be the problem? To me the only "problem" seems to be one or two small inconsistencies: DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..) The other relates to iof.xinf directly, but that is not wired up to any DMEDIUM_ command, namely: IOI_HDRL $28 Long File header length (per file storage overhead) - which returns 512b on DOS, while all other devices return 64b. The inconsistency here is that 512b doesnt relate to the actual file header size, as I always assumed was the intention.. Those two points also differ from SMSQmulator's NFA device, which returns the "expected" values, ie 2 and 64, respectively. Just my penny's worth.. Per On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote: Hi, There seems to be a new release of QPC2 in the pipeline. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. Have a fine day, François Van Emelen Hi, As my programming skills are limited to some easy basic, I can't argue about "DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..)" I noticed some months ago that some DMEDIUM-functions returned wrong values (see SBASIC/SuperBASIC Reference Manual Online Documentation Release 4.0.1 Rich Mellor). Not only wrong values but also differences between Smsqmulator and Qpc. And as there is a new release of QPC in the pipeline, I thought it was right time to try to convince Marcel to do some work on those DMEDIUM-functions . You could try this in QPC and SMSQMULATOR to see the difference. 90 REMark test for for some dmediium_xxx functions 100 OPEN_OVER#3,'ram2_rdonly_txt' ::datad_temp$=DATAD$ 110 REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1 120 REMark Why does 'dmedium_type(\dev$) return -1 instead of 3 130 REMark Why does 'line 240 return -23 WITH qpc2 (which seems correc)t BUT -7 with SMSQMULATOR 140 dev$='dos3_' :d$=DATE$ 150 REMark DOS3_ is an external USB CD DRIVE 160 DATA_USE 'dos3_' 170 fichier$=dev$$ 180 WHEN ERRor 190 IF ERNUM:PRINT#3,ERLIN,ERNUM:END IF 200 END WHEN 210 d= FTEST(dev$) 220 IF d<0:CLOSE#3:DELETE 'ram2_rdonly_txt' :DATA_USE datad_temp$:STOP:END IF 230 f=FOP_NEW(fichier$): 240 PRINT#3,240,' f=fop_new(fichier$) = ',f 250 PRINT#3,250,'dmedium_rdonly(\dev$) = '; DMEDIUM_RDONLY(\dev$),'rdonly' ,' 0= Read/Write 1=Read Only' 260 PRINT#3,260,'dmedium_type(\dev$) = ', DMEDIUM_TYPE(\dev$),'type' ,'0= Ram disk : 1= floppy drive :2= hard disk :3=CDrom drive' 270 PRINT#3,270,'dmedium_name$(\dev$) = ', DMEDIUM_NAME$(\dev$) ,'name' 280 CLOSE#3 290 DATA_USE datad_temp$ :PAUSE Thanks for your reply.. Have a fine day. François Van Emelen Hi François, I tried your program with different devices, this is what I found: ram1 flp2 win1 dos1/nfa1 win3 dos3/nfa3 SMSQmulator f=fop_new(fichier$) 4 4 4 -7 4 -7* dmedium_rdonly(\dev$) 0 0 0 0 0 0 dmedium_type(\dev$) 0 1 2 2 2 2 dmedium_name$(\dev$) RAM1 MyFlp Syst NFA DRIVE 1 Pics NFA DRIVE 3 QPC2 (V4.xx) f=fop_new(fichier$) 4 4 4 -23** 4 4 dmedium_rdonly(\dev$) 0 0 0 0 0 0 dmedium_type(\dev$) 0 1 2 -1 2 -1 dmedium_name$(\dev$) RAM1 MyFlp System C:\ Pics Temp * The reason NFA file returned -7 here is because the : in the date got translated to " on the drive: April 9th 2019 17:06:51 -> April 9th 2019 17"06"51, so it couldnt find the file it had just created! ** -23 => Access denied on system root. DMEDIUM_RDONLY reported 0.. The problem doesnt, IMHO, lie with DMEDIUM_xxx. Its down to the various driver implementations. It would, of course be good if the various drivers could all behave in a consistent way. With QPC2 and SMSQmulator there is still hope, but for many other systems, like the Falkenberg HDD interface (ref the SBASIC/SuperBASIC Reference Manual) that boat has probably sailed. Per ___ QL-Users Mailing List Hi, Thank you for your extended testing and comments. As I no longer have a reliable floppy drive I couldn't even use those DMEDIUM_xxx functions for it. In line 140 I replaced d$=date$ with d$="readonlytest.txt" for a more conventional file name. Line 240 still return -7 with SMSQMULATOR. This seems to tells that the the translation of Date$ is not the lone respondsible for returning -7 . The difference is perhaps due to the 'implementation' of SMSQMULATOR. I so, the bug could/should be called a
Re: [Ql-Users] New QPC release ?
On 09/04/2019 12:51, François Van Emelen via Ql-Users wrote: Op 8/04/2019 om 14:58 schreef pjwitte via Ql-Users: What seems to be the problem? To me the only "problem" seems to be one or two small inconsistencies: DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..) The other relates to iof.xinf directly, but that is not wired up to any DMEDIUM_ command, namely: IOI_HDRL $28 Long File header length (per file storage overhead) - which returns 512b on DOS, while all other devices return 64b. The inconsistency here is that 512b doesnt relate to the actual file header size, as I always assumed was the intention.. Those two points also differ from SMSQmulator's NFA device, which returns the "expected" values, ie 2 and 64, respectively. Just my penny's worth.. Per On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote: Hi, There seems to be a new release of QPC2 in the pipeline. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. Have a fine day, François Van Emelen Hi, As my programming skills are limited to some easy basic, I can't argue about "DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..)" I noticed some months ago that some DMEDIUM-functions returned wrong values (see SBASIC/SuperBASIC Reference Manual Online Documentation Release 4.0.1 Rich Mellor). Not only wrong values but also differences between Smsqmulator and Qpc. And as there is a new release of QPC in the pipeline, I thought it was right time to try to convince Marcel to do some work on those DMEDIUM-functions . You could try this in QPC and SMSQMULATOR to see the difference. 90 REMark test for for some dmediium_xxx functions 100 OPEN_OVER#3,'ram2_rdonly_txt' ::datad_temp$=DATAD$ 110 REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1 120 REMark Why does 'dmedium_type(\dev$) return -1 instead of 3 130 REMark Why does 'line 240 return -23 WITH qpc2 (which seems correc)t BUT -7 with SMSQMULATOR 140 dev$='dos3_' :d$=DATE$ 150 REMark DOS3_ is an external USB CD DRIVE 160 DATA_USE 'dos3_' 170 fichier$=dev$$ 180 WHEN ERRor 190 IF ERNUM:PRINT#3,ERLIN,ERNUM:END IF 200 END WHEN 210 d= FTEST(dev$) 220 IF d<0:CLOSE#3:DELETE 'ram2_rdonly_txt' :DATA_USE datad_temp$:STOP:END IF 230 f=FOP_NEW(fichier$): 240 PRINT#3,240,' f=fop_new(fichier$) = ',f 250 PRINT#3,250,'dmedium_rdonly(\dev$) = '; DMEDIUM_RDONLY(\dev$),'rdonly' ,' 0= Read/Write 1=Read Only' 260 PRINT#3,260,'dmedium_type(\dev$) = ', DMEDIUM_TYPE(\dev$),'type' ,'0= Ram disk : 1= floppy drive :2= hard disk :3=CDrom drive' 270 PRINT#3,270,'dmedium_name$(\dev$) = ', DMEDIUM_NAME$(\dev$) ,'name' 280 CLOSE#3 290 DATA_USE datad_temp$ :PAUSE Thanks for your reply.. Have a fine day. François Van Emelen Hi François, I tried your program with different devices, this is what I found: ram1 flp2 win1 dos1/nfa1 win3 dos3/nfa3 SMSQmulator f=fop_new(fichier$) 4 4 4 -7 4 -7* dmedium_rdonly(\dev$) 0 0 0 0 0 0 dmedium_type(\dev$) 0 1 2 2 2 2 dmedium_name$(\dev$) RAM1 MyFlp Syst NFA DRIVE 1 Pics NFA DRIVE 3 QPC2 (V4.xx) f=fop_new(fichier$) 4 4 4 -23** 4 4 dmedium_rdonly(\dev$) 0 0 0 0 0 0 dmedium_type(\dev$) 0 1 2 -1 2 -1 dmedium_name$(\dev$) RAM1 MyFlp System C:\ Pics Temp * The reason NFA file returned -7 here is because the : in the date got translated to " on the drive: April 9th 2019 17:06:51 -> April 9th 2019 17"06"51, so it couldnt find the file it had just created! ** -23 => Access denied on system root. DMEDIUM_RDONLY reported 0.. The problem doesnt, IMHO, lie with DMEDIUM_xxx. Its down to the various driver implementations. It would, of course be good if the various drivers could all behave in a consistent way. With QPC2 and SMSQmulator there is still hope, but for many other systems, like the Falkenberg HDD interface (ref the SBASIC/SuperBASIC Reference Manual) that boat has probably sailed. Per ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
Op 9/04/2019 om 0:12 schreef Marcel Kilgus via Ql-Users: pjwitte via Ql-Users wrote: DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..) Oh, that actually is a bug. It's supposed to be 2 of course. I have translated the code into C last weekend and thus already fixed it without even knowing that it was broken. The other relates to iof.xinf directly, but that is not wired up to any DMEDIUM_ command, namely: IOI_HDRL $28 Long File header length (per file storage overhead) - which returns 512b on DOS, while all other devices return 64b. The inconsistency here is that 512b doesnt relate to the actual file header size, as I always assumed was the intention.. Looks like the structure is somehow offset by some bytes, as that is also supposed to be 64. I was thinking more about the line of DMEDIUM_RDONLY and DMEDIUM_REMOVE. This is a bit more difficult to check but I think I got the most common cases now at least. Marcel ___ QL-Users Mailing List Thanks for your reply. Francois Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
Op 8/04/2019 om 14:58 schreef pjwitte via Ql-Users: What seems to be the problem? To me the only "problem" seems to be one or two small inconsistencies: DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..) The other relates to iof.xinf directly, but that is not wired up to any DMEDIUM_ command, namely: IOI_HDRL $28 Long File header length (per file storage overhead) - which returns 512b on DOS, while all other devices return 64b. The inconsistency here is that 512b doesnt relate to the actual file header size, as I always assumed was the intention.. Those two points also differ from SMSQmulator's NFA device, which returns the "expected" values, ie 2 and 64, respectively. Just my penny's worth.. Per On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote: Hi, There seems to be a new release of QPC2 in the pipeline. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. Have a fine day, François Van Emelen Hi, As my programming skills are limited to some easy basic, I can't argue about "DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..)" I noticed some months ago that some DMEDIUM-functions returned wrong values (see SBASIC/SuperBASIC Reference Manual Online Documentation Release 4.0.1 Rich Mellor). Not only wrong values but also differences between Smsqmulator and Qpc. And as there is a new release of QPC in the pipeline, I thought it was right time to try to convince Marcel to do some work on those DMEDIUM-functions . You could try this in QPC and SMSQMULATOR to see the difference. 90 REMark test for for some dmediium_xxx functions 100 OPEN_OVER#3,'ram2_rdonly_txt' ::datad_temp$=DATAD$ 110 REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1 120 REMark Why does 'dmedium_type(\dev$) return -1 instead of 3 130 REMark Why does 'line 240 return -23 WITH qpc2 (which seems correc)t BUT -7 with SMSQMULATOR 140 dev$='dos3_' :d$=DATE$ 150 REMark DOS3_ is an external USB CD DRIVE 160 DATA_USE 'dos3_' 170 fichier$=dev$$ 180 WHEN ERRor 190 IF ERNUM:PRINT#3,ERLIN,ERNUM:END IF 200 END WHEN 210 d= FTEST(dev$) 220 IF d<0:CLOSE#3:DELETE 'ram2_rdonly_txt' :DATA_USE datad_temp$:STOP:END IF 230 f=FOP_NEW(fichier$): 240 PRINT#3,240,' f=fop_new(fichier$) = ',f 250 PRINT#3,250,'dmedium_rdonly(\dev$) = '; DMEDIUM_RDONLY(\dev$),'rdonly' ,' 0= Read/Write 1=Read Only' 260 PRINT#3,260,'dmedium_type(\dev$) = ', DMEDIUM_TYPE(\dev$),'type' ,'0= Ram disk : 1= floppy drive :2= hard disk :3=CDrom drive' 270 PRINT#3,270,'dmedium_name$(\dev$) = ', DMEDIUM_NAME$(\dev$) ,'name' 280 CLOSE#3 290 DATA_USE datad_temp$ :PAUSE Thanks for your reply.. Have a fine day. François Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
pjwitte via Ql-Users wrote: > DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call > suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 > is arguable..) Oh, that actually is a bug. It's supposed to be 2 of course. I have translated the code into C last weekend and thus already fixed it without even knowing that it was broken. > The other relates to iof.xinf directly, but that is not wired up to > any DMEDIUM_ command, namely: > IOI_HDRL $28 Long File header length (per file storage overhead) - > which returns 512b on DOS, while all other devices return 64b. The > inconsistency here is that 512b doesnt relate to the actual file > header size, as I always assumed was the intention.. Looks like the structure is somehow offset by some bytes, as that is also supposed to be 64. I was thinking more about the line of DMEDIUM_RDONLY and DMEDIUM_REMOVE. This is a bit more difficult to check but I think I got the most common cases now at least. Marcel ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
What seems to be the problem? To me the only "problem" seems to be one or two small inconsistencies: DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 is arguable..) The other relates to iof.xinf directly, but that is not wired up to any DMEDIUM_ command, namely: IOI_HDRL $28 Long File header length (per file storage overhead) - which returns 512b on DOS, while all other devices return 64b. The inconsistency here is that 512b doesnt relate to the actual file header size, as I always assumed was the intention.. Those two points also differ from SMSQmulator's NFA device, which returns the "expected" values, ie 2 and 64, respectively. Just my penny's worth.. Per On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote: Hi, There seems to be a new release of QPC2 in the pipeline. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. Have a fine day, François Van Emelen ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
Op 7/04/2019 om 23:22 schreef Marcel Kilgus via Ql-Users: François Van Emelen via Ql-Users wrote: There seems to be a new release of QPC2 in the pipeline. It has been in the pipeline for the last 2 years... but yeah, it's much further along now. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. If you refer to the DOS device then someone must be me then. But this is not a bug. It's maybe a missing feature, but one that is amazingly difficult to pull off correctly for very little gain. I might try halve-assing it though. Marcel ___ QL-Users Mailing List Thanks for your reply. François Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] New QPC release ?
François Van Emelen via Ql-Users wrote: > There seems to be a new release of QPC2 in the pipeline. It has been in the pipeline for the last 2 years... but yeah, it's much further along now. > It would be very useful if someone would/could debug the 'DMEDIUM_XXX' > functions. If you refer to the DOS device then someone must be me then. But this is not a bug. It's maybe a missing feature, but one that is amazingly difficult to pull off correctly for very little gain. I might try halve-assing it though. Marcel ___ QL-Users Mailing List
[Ql-Users] New QPC release ?
Hi, There seems to be a new release of QPC2 in the pipeline. It would be very useful if someone would/could debug the 'DMEDIUM_XXX' functions. Have a fine day, François Van Emelen ___ QL-Users Mailing List
