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$&d$
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
fe
