QL / PASCAL

Anything QL Software or Programming Related.
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QL / PASCAL

Post by NormanDunbar »

As far as I remember, this occurs on C68 as well. I wrote something years ago and suffered. I had to turn off buffering to make it work.

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.
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL / PASCAL

Post by mk79 »

This, too, is a known side effect of the C runtime. QDOS does not buffer/delay writes to the screen.


User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

OK, I think I committed a hacky fix/workaround for this in SVN r49381. So flush() between write() and read() on the console is no longer necessary. For a proper fix, I'd need to know if a file handle/channel ID I have is a "device", i.e. "con_". But I don't suppose I can query this info from QDOS and we need to track this internally in the RTL somehow? At least it seems like C68 libc seems to track some kind of flags for this...?


User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

And a question: I don't suppose there's any way to figure out in a Job, where it was loaded from? I'm thinking about something like, you do EXEC_W "win3_some.exe", but "some.exe" has several files on "win3_" which it would like to access. Is there a way for some.exe to know it was loaded from "win3_" or whatever other path? (Maybe I asked this already but missed/forgot the answer? Sorry then.)


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL / PASCAL

Post by tofro »

Chain-Q wrote:OK, I think I committed a hacky fix/workaround for this in SVN r49381. So flush() between write() and read() on the console is no longer necessary. For a proper fix, I'd need to know if a file handle/channel ID I have is a "device", i.e. "con_". But I don't suppose I can query this info from QDOS and we need to track this internally in the RTL somehow? At least it seems like C68 libc seems to track some kind of flags for this...?
Two possible ways: Either you track the "isInteractive device" fact in the open function (like C68 seems to do), or you use the channel ID to walk (the channel id contains the index into this) the channel table (acessible from the system variables) and find out later what type of channel you got. It's actually one of the traits of QDOS that this knowledge actually shouldn't be needed at all - files and devices are handled transparently and ar thus fully redirectable.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL / PASCAL

Post by tofro »

Chain-Q wrote:And a question: I don't suppose there's any way to figure out in a Job, where it was loaded from? I'm thinking about something like, you do EXEC_W "win3_some.exe", but "some.exe" has several files on "win3_" which it would like to access. Is there a way for some.exe to know it was loaded from "win3_" or whatever other path? (Maybe I asked this already but missed/forgot the answer? Sorry then.)
That function is in a system extension (a "Thing") named the "HOME thing". This system extension is guaranteed to be present in SMSQ/E and a loadable extension in QDOS. Documentation is here. There should be some assembly examples in there on how to access it (Note this seems to be a Quill doc file that would need some conversion to read otherwise)


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

tofro wrote:It's actually one of the traits of QDOS that this knowledge actually shouldn't be needed at all - files and devices are handled transparently and ar thus fully redirectable.
Yes, and that's actually a quite cool concept, I agree. But in practical terms, it's sometimes good to know the kind of device the channel accesses anyway. Anyway, the main issue regarding this has been fixed, so it's good for now.
tofro wrote:That function is in a system extension (a "Thing") named the "HOME thing". This system extension is guaranteed to be present in SMSQ/E and a loadable extension in QDOS.
Thanks. Looks like on the QL we have to make these optional somehow. I'd really prefer if FPC binaries would still work on a stock QL.

In other news, the first "real world" usable application written in FPC for the QL just got released. Marcus Sackrow ported his "Hex2" calculator-with-variables over to the QL. It's quite big, as for float calculations it includes FPC's SoftFPU, and a bunch of string handling functions, but it's a first, and it just fits into the stock QL's memory, when nothing else is running... ;)


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL / PASCAL

Post by tofro »

Chain-Q wrote:
tofro wrote:That function is in a system extension (a "Thing") named the "HOME thing". This system extension is guaranteed to be present in SMSQ/E and a loadable extension in QDOS.
Thanks. Looks like on the QL we have to make these optional somehow. I'd really prefer if FPC binaries would still work on a stock QL.

In other news, the first "real world" usable application written in FPC for the QL just got released. Marcus Sackrow ported his "Hex2" calculator-with-variables over to the QL. It's quite big, as for float calculations it includes FPC's SoftFPU, and a bunch of string handling functions, but it's a first, and it just fits into the stock QL's memory, when nothing else is running... ;)
Now I see where this is coming from. As a side note (the "HOME thing" is definitely "better", because it's doing stuff automatically), there is a mechanism in QDOS that uses specifically marked standard "patch blocks" for stuff you're hesitant to hard-code into your binary and that can be identified and patched by a menu-driven system program. "The Config Block/Menuconfig" approach. But that's probably "something for later".


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL / PASCAL

Post by mk79 »

Chain-Q wrote:
tofro wrote:That function is in a system extension (a "Thing") named the "HOME thing". This system extension is guaranteed to be present in SMSQ/E and a loadable extension in QDOS.
Thanks. Looks like on the QL we have to make these optional somehow. I'd really prefer if FPC binaries would still work on a stock QL.
QDOS didn't have the concept of a directory, which explains the lack of a notion of any "current directory" or similar... this is why usually a "config block" was added to EXE files that could be manipulated using a standard config application (which directly patches the EXE) to tell the EXE its base directory.

There are also two global directories (not per-process) introduced by TK2 directories called DATAD and PROGD, the default data and program directories. There is no standard interface for it but they can be accessed through the system variables (sys_prgd, sys_datd).

As this is all not ideal Wolfgang and I designed and implemented the mentioned Home thing to finally remedy the situation, it automatically tracks the directory an EXE was started from and also maintains a "current directory" per process. "Things" are by definition dynamically called, so handling it as optional is fairly easy. Fallback could be a hard-coded directory out of a config block, as it was the custom before. I might have a stab at it as I don't think it makes sense for you to waste your time on learning these intricacies. Which function would access the directory?
In other news, the first "real world" usable application written in FPC for the QL just got released. Marcus Sackrow ported his "Hex2" calculator-with-variables over to the QL. It's quite big, as for float calculations it includes FPC's SoftFPU, and a bunch of string handling functions, but it's a first, and it just fits into the stock QL's memory, when nothing else is running... ;)
Very cool. Though here we already have the problem that the application does not find its help file ;)


User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

mk79 wrote:As this is all not ideal Wolfgang and I designed and implemented the mentioned Home thing to finally remedy the situation, it automatically tracks the directory an EXE was started from and also maintains a "current directory" per process. "Things" are by definition dynamically called, so handling it as optional is fairly easy. Fallback could be a hard-coded directory out of a config block, as it was the custom before. I might have a stab at it as I don't think it makes sense for you to waste your time on learning these intricacies. Which function would access the directory?
Well, there's no other really platform independent solution, than investigating and parsing ParamStr(0), which is the equivalent of C's argv[0]. Which ideally contains the executable name and the full path to it. A lot of code uses this to determine its home dir.

And as you can see, setting it is simply missing on the QL: https://github.com/graemeg/freepascal/b ... em.pp#L186

I guess ideally one needs to add a helper function which returns this, depending on what extensions, etc. are available on the system. Then just wire this helper into the line I linked. I'm not sure what's needed for a config block. Sounds like some extra linker magic?
mk79 wrote:Though here we already have the problem that the application does not find its help file ;)
Indeed. It will only find the help file, if it runs from mkv1_...


Post Reply