What Editor is best to use ?

[janbredenbeek]

Rich, I wish your SuperBasic manual had filtering capabilities, to filter all keywords from a specific toolkit (location, as it is named in the manual)

EXTRAS should have a parameter as filter string . And print the location.
Actually quite easy to implement...

[Derek_Stewart]

Hi,

If a file is saved in Q-Emulator to a Windows mapped Folder. I asdume a QDOS header is attached to the file.

Can this file be read on a non-emulator QL?

Is there a command in Q-Emulator not to add a QDOS header?

I only use WIN containers on Q-Emulator, which allows interchange with all QL platforms

[janbredenbeek]

I noticed the following:
OPEN_DIR#4,flp2_QLtest_bas
will return:
- Bad Parameter - if QLtest_bas exists on flp2_
- no error - if QLtest_bas does not exist on flp2_

I just tested this on Qemulator 3.2 and could not reproduce it - in both cases OPEN_DIR gave no error.
I used the JS and Minerva 1.97 ROMs and TK2 v2.12.
Minerva 1.98 kept hanging at boot...

Jan.

[RWAP]

I noticed the following:
OPEN_DIR#4,flp2_QLtest_bas
will return:
- Bad Parameter - if QLtest_bas exists on flp2_
- no error - if QLtest_bas does not exist on flp2_

I just tested this on Qemulator 3.2 and could not reproduce it - in both cases OPEN_DIR gave no error.
I used the JS and Minerva 1.97 ROMs and TK2 v2.12.
Minerva 1.98 kept hanging at boot...

Jan.

I just tried it here on my laptop with an unregistered copy of q-emulator and likewise, cannot reproduce it.

I have reported it to Daniele to look at - as it looks to be something to do with the registered version of q-emulator (which I assume Andrew has)

[RWAP]

If a file is saved in Q-Emulator to a Windows mapped Folder. I asdume a QDOS header is attached to the file.

Can this file be read on a non-emulator QL?

Is there a command in Q-Emulator not to add a QDOS header?

The header is ONLY added to the file if required (ie normally an executable file). BASIC files, and code files are easily transported between emulators and QLs. Q-emulator does not offer an option as such not to add a QDOS header (although you can use SBYTES instead of SEXEC) - as the executable file would then no longer be useable.

That is the same issue with any emulators which try to store QL files on native WIndows / Mac folders - what do you do with the QDOS header when it is needed? Some emulators create a second file which contains the header, but that does not help you get the file onto a normal QL.

Q-emulator does of course recognise if you are copying an executable file to a QL formatted disk, disk image, qxl.win file, microdrive image or zip file and write it with the normal file header so anything else can load in from this.

[Andrew]

Hi,

If a file is saved in Q-Emulator to a Windows mapped Folder. I asdume a QDOS header is attached to the file.

Can this file be read on a non-emulator QL?

Is there a command in Q-Emulator not to add a QDOS header?

I only use WIN containers on Q-Emulator, which allows interchange with all QL platforms

I guess you can use Habi Image Editor - http://hardware.speccy.org/temp/qubide-i.html

[Andrew]

I just tried it here on my laptop with an unregistered copy of q-emulator and likewise, cannot reproduce it.

I have reported it to Daniele to look at - as it looks to be something to do with the registered version of q-emulator (which I assume Andrew has)

Yes, I use the registered version
Saturday I will install an unregistered version on a laptop and will do some comparative tests.

[dilwyn]

Hi,

If a file is saved in Q-Emulator to a Windows mapped Folder. I asdume a QDOS header is attached to the file.

Can this file be read on a non-emulator QL?

Is there a command in Q-Emulator not to add a QDOS header?

I only use WIN containers on Q-Emulator, which allows interchange with all QL platforms

I guess you can use Habi Image Editor - http://hardware.speccy.org/temp/qubide-i.html

Following information on QemuLator native windoze hard disk file headers added to QL executables in case someone wants to write a routine to 'strip' these added bytes once the program is transferred to another file system such as QL (info from QemuLator manual Appendix 2):

Q-emuLator for Windows stores part of the header at the beginning of files. The header is present
only when it is useful, ie. only if it contains non-default information.
The header, which can be 30 or 44 bytes pre-pended, has the following format:

OFFSET LENGTH(bytes) CONTENT
0 18 “]!QDOS File Header“
18 1 0 (reserved)
19 1 total length_of_header, in 16 bit words
20 length_of_header*2-20 QDOS INFO

The first 18 bytes are there to detect whether the header is present (ID string).
The headers Q-emuLator supports can be 30 bytes or 44 bytes long (the value of the
corresponding byte at offset 19 is either 15 or 22). In the first case, there are 10 bytes with the values
present in bytes 4 to 13 of the 64 bytes QDOS header. In the second case the same piece of
information is followed by 14 bytes containing a microdrive sector header, useful for emulating
microdrive protection schemes. Additional header information (file length, name, dates) is obtained
directly from the file through the host file system.

Easiest way to strip the header is to let QemuLator do it - copy it to a non-Windoze medium such as ramdisk or QL floppy disk before zipping it up and transferring it, for example, rather than zipping it up in Windoze. QemuLator automatically removes the header when it spots that the file is going to QL format media such as ramdisk or floppy disk.

[janbredenbeek]

I can't understand this problem. In S_Edit, I set SV_DDLST to "" to not let TK2 use its default directory. The only way to do so, to examine, if a file name really exists and to prevent TK2 to rush its default directory in front of a filename. So, things like "win1_flp2_test_asm" are not possible. That's the most bad behavier of TK2 (in my opinion).

At least, if the filename isn't found, I set SV_DDLST to its original value and try again. If that isn't found, it is a new file.

I assume you clear out the pointer to the default data directory (sys_datd at $B0), not SV_DDLST as clearing out the latter means the system won't find any directory device anymore...
Note that the IO.OPEN trap doesn't recognise the default directories so it's up to the application program to look for them, and doing an IO.OPEN with D3=4 (directory) is the easiest way to check if a particular device exists. Of course, one could scan SV_DDLST for device names to avoid prepending the default directory in your particular example (when flp2_ is not mapped to a physical device or has no floppy in it an OPEN_DIR would fail and win1_ would be prepended which is probably not desired). But this would fail with simple devices like ser (which would be found with IO.OPEN as they ignore the type key in D3) and IMHO it's a bridge too far for an application program like QED to dive into system tables.

regards, Jan.

[mk79]

I just tried it here on my laptop with an unregistered copy of q-emulator and likewise, cannot reproduce it.

I have reported it to Daniele to look at - as it looks to be something to do with the registered version of q-emulator (which I assume Andrew has)

Yes, I use the registered version
Saturday I will install an unregistered version on a laptop and will do some comparative tests.

Incidentally I noticed the same problem (also registered copy) a few days ago. If I do a

Code: Select all

dir win1_system_c

then I get all files that start with c as expected. But if I do

Code: Select all

dir win1_system_calc

i.e. a file that actually exists, I get "bad parameter"

Cheers, Marcel