QL / PASCAL

[NormanDunbar]

You could scan the directory driver list? I did this in DJToolkit for one of the extensions which returns the "next" dev_name each time it is called.

https://superbasic-manual.readthedocs.i ... l#dev-name

Cheers,
Norm.

[pjw]

<>
On this point of detecting whether a valid directory-device has already been specified, what is the most robust/elegant way to validate this, given the ever-growing list of possible devices that a user may have installed? I guess QPAC has a way to build it's list of available devices for the 'File' Thing...

It may not be enough to just scan for valid device names, as users can create their own USEage names as well! Ive demonstrated how you can list and find device names and usage names in my DevGet routine, which could be adapted to whatever you need.

[mk79]

[Short, off-topic question] On this point of detecting whether a valid directory-device has already been specified, what is the most robust/elegant way to validate this, given the ever-growing list of possible devices that a user may have installed? I guess QPAC has a way to build it's list of available devices for the 'File' Thing...

Code: Select all

; Does filename start with a known device name? Don't add default dir then!
; Note: we assume all directory devices have 3 character names
        subq.w  #5,d0                    ; must have at least 5 chars for check
        bcs.s   uod_start
        cmp.b   #'_',6(a6,a1.l)          ; underscore at right place?
        bne.s   uod_start                ; no, we can skip test
        move.b  5(a6,a1.l),d0            ; drive number must be between 1 and 8
        sub.b   #'1',d0
        bcs.s   uod_start
        subq.b  #8,d0
        bcc.s   uod_start

        moveq   #sms.info,d0
        trap    #1
        lea     sys_fsdl(a0),a0          ; list with directory device drivers
        move.l  #$dfdfdf00,d1
        and.l   2(a6,a1.l),d1            ; First 3 chars of filename
uod_fsloop
        move.l  (a0),d0                  ; next driver
        beq.s   uod_start                ; no more
        move.l  d0,a0
        move.l  #$dfdfdf00,d0
        and.l   iod_dnus-iod_iolk+2(a0),d0
        cmp.l   d0,d1
        bne.s   uod_fsloop               ; no match, try next

        andi.b  #$ff-uod.datd-uod.prgd-uod.dstd,d7 ; match, don't try def dirs!
uod_start

This is how I did it.

Cheers, Marcel

[NormanDunbar]

Nice, thanks.

[martyn_hill]

Thanks, oh gurus!

Now back to Norman's topic

[Chain-Q]

@Norman

Tonight I made a selective merge of your patches into FPC's trunk. The main changes are on top of what you did:

- Code style, here and there
- I did not merge the FS_POSAB and FS_POSRE changes, because the idea is, these are OS API functions, and should return what the OS returns, always. Therefore the ERR_EF issue must be dealt with in the Pascal code which uses these functions. So I made some changes in the Pascal code instead. This is BTW consistent with how QDOS GCC deals with these functions (and others).
- Also, the parameter trashing thing I fixed before I noticed your patches, so there the code might be slightly different.
- The directory creation, and the rename code is not merged yet. I'd like to add separate functions for the calls involved there, not just have a snippet of inline assembly. The reason is, not sure if you noticed already, but there's a "qlunits" directory in "packages/qlunits", which exposes the native QDOS/SMS/whatever API, so one can write Pascal code using the OS API directly. And that code reuses and exposes all the RTL-implemented functions, plus adds a bunch of its own (the ones which are not used by the RTL should go into Packages). So therefore having the OS calls in separate functions not just a "what is prettier" question, but has practical implications.

Additionally, there were two changes from me and Pierre Muller, another FPC developer:
- I implemented an "OS heap" allocator, which just exposes the OS API as Pascal's GetMem/FreeMem/etc, instead of doing the heap management internally and just going to the OS for bigger blocks. This reduces the code size by about 3K, and potentially behaves better in a memory-constrained multitasking environment, because it doesn't devour the entire RAM at the start, because the code "might" need it... I guessed this was important on small systems, like the QL, especially on stock, or close-to-stock machines. The "bigmem" allocator, which is default in FPC can be still enabled by flipping a define at the start of the System unit code.
- Pierre Muller implemented some initial code for command line parameter handling, which then I fixed up slightly. But not sure how to test it. Can one pass command line arguments to a QL job when started via EXEC_W or similar? Or only in the newer OSes?

Also, I'd like to apologize to everyone who I didn't answer or didn't react lately (or a long ago), also here and in e-mail. I was, and still am quite busy, and the QL things just fell through the cracks, I'm sorry. Too many hobbies, platforms, and communities...

Norman (or whoever else feels motivated too), please keep working, eventually all your work gets merged to upstream, for sure, and won't get lost.

[NormanDunbar]

Hi Chain-Q,

Thanks for that explanation. I'll pull the latest trunk and see what I need to do. I hadn't started on the units yet, just what was in system, sysfile and sysdir. I figured getting those sorted was the best place to start.

There are a couple of places where there's a need to copy from a Pascal string to a QDOS string which I need to split out, I (now) intend putting that into the Qdos unit, unless you object?

I'll sort out the other stuff you mentioned too.

You can pass parameters to a QDOS job. Most people, I should think, have Toolkit 2, or the Turbo Toolkit so this is now fairly standard. It is done as follows:

Code: Select all

EX jobFile.exe ; 'parameter parameter ...'

The job stack on entry is

0(sp) = how many channels were opened for this job. (WORD)
2(sp) = channel id(s) (LONG)
2+(4*channels)(sp) = length of parameter string (WORD)
Then the bytes of the parameter string.

More at http://qdosmsq.dunbar-it.co.uk/doku.php ... #job_stack.

The full EX details are at https://superbasic-manual.readthedocs.i ... ex.html#ex.


Cheers,
Norm.

[Chain-Q]

I did not merge the FS_POSAB and FS_POSRE changes, because the idea is, these are OS API functions, and should return what the OS returns, always. Therefore the ERR_EF issue must be dealt with in the Pascal code which uses these functions. So I made some changes in the Pascal code instead. This is BTW consistent with how QDOS GCC deals with these functions (and others).

OK, meanwhile I realized my solution is slightly wrong here, and the FS_POSAB and FS_POSRE wrappers still have to be changed. But what I'm going to do instead, is make the new_pos parameter passed by reference, to the function can return both the error code (in return value) or the new position (in the parameter). Because - if I get this right -, D1 is still valid in case of ERR_EF, and the error code just signals the fact that the desired position is out of bounds. Then it can be properly dealt with in the Pascal code.

At least that's my current assumption. Need to verify this.

[NormanDunbar]

You are correct. D1 is the (new) position and ERR_EF shows you hit end of file.

Cheers,
Norm.

[Chain-Q]

So here's the current state of FPC SVN trunk. It has somewhat working command line arguments handling (read: ParamCount and ParamStr() works now), and file I/O seems to be largely OK, although the Seek() changes need to be tested more thoroughly: https://twitter.com/chainq/status/1380914243416043522

Now I'll get to merge the directory handling changes, and then I'll go back to hiding waiting for the next set of patches by someone.