QL / PASCAL
- NormanDunbar
- Forum Moderator
- Posts: 2274
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL / PASCAL
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.
https://superbasic-manual.readthedocs.i ... l#dev-name
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Re: QL / PASCAL
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.martyn_hill wrote:<>
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...
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: QL / PASCAL
martyn_hill wrote:[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
Cheers, Marcel
- NormanDunbar
- Forum Moderator
- Posts: 2274
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL / PASCAL
Nice, thanks.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
- Chain-Q
- Chuggy Microdrive
- Posts: 62
- Joined: Mon Nov 16, 2020 1:10 pm
- Location: Berlin, DE, EU
- Contact:
Re: QL / PASCAL
@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.
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
- Forum Moderator
- Posts: 2274
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL / PASCAL
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:
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.
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 ...'
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.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
- Chain-Q
- Chuggy Microdrive
- Posts: 62
- Joined: Mon Nov 16, 2020 1:10 pm
- Location: Berlin, DE, EU
- Contact:
Re: QL / PASCAL
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.Chain-Q wrote: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).
At least that's my current assumption. Need to verify this.
- NormanDunbar
- Forum Moderator
- Posts: 2274
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL / PASCAL
You are correct. D1 is the (new) position and ERR_EF shows you hit end of file.
Cheers,
Norm.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
- Chain-Q
- Chuggy Microdrive
- Posts: 62
- Joined: Mon Nov 16, 2020 1:10 pm
- Location: Berlin, DE, EU
- Contact:
Re: QL / PASCAL
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.
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.