Chain-Q wrote:First, you used {$PACKRECORDS 1} for this SystemVariables type.
Hmm. Usually I code in C/C++ and not Pascal. However, when I'm coding on the PC to read QL structures, I always have to pack the structures to get the correct offsets. I suspect this was simply "muscle memory" in action. I've commented out the packing lines and recompiled the QDOS and SMS examples (in
packages/qlunits/examples) and they appear to work fine. However, I'm on QPC which is impersonating/emulating a 68020 and I have fallen foul of that in the past with misaligned words/longwords on byte addresses -- the original QL with its 68008 would have barfed but the 68020 just did what was needed and carried on.
So I then compiled my own example program which displays all the QDOS System Variables on 5 or so pages. That also worked, so the good news is, unless I'm being 68020'd, is that I didn't need the packing after all. Famous last words?
Chain-Q wrote: I'd prefer to keep the offset constants you removed, for various reasons.
No worries, I've edited them back in.
Chain-q wrote:... I think there's some trouble on how FPC handles and shares a single channel as stdin/stdout handle. For example a write('enter your name:'); readln(name); won't work, the "enter your name" text will not appear, and then all sorts of weird things will happen depending on the length of your input.
I noticed this. When I was doing my "list all the system variables" program, I needed to prompt the user to "press any key to continue or ESC to quit" and weird things did indeed happen. I resolved this as follows but the user doesn't have to press ENTER:
Code: Select all
Write('Press Any key (except ESC) to continue, ESC to Quit....');
Flush(output);
Enter := char(io_fbyte(stdInputHandle, -1));
if Enter = chr(27) then
Pause := false;
Writeln;
In a test program, It works fine like this:
Code: Select all
program test;
var
name: array[0..49] of char;
begin
write('enter your name:');
flush(output);
readln(name);
writeln('your name is: ', name);
end.
The prompt gets printed if I flush, If I forget to flush, there's no prompt and it acts weird.
The QL defaults to three channels being open -- C68 may do other things, other (SuperBASIC) compilers allow the programmer to select how many windows to copy from SuperBASIC or whether the code opens its own windows etc -- Depending on TV or Monitor mode. The input channel (#0) is a con channel at the bottom of the screen and is about 3 lines deep. The other two are at the top of the screen, one is used for program output without a channel id, the other for listings etc. Those are both also con channels as input is permitted, but only by explicitly specifying the channel number (#1 or #2).
At the moment, I would leave the console opening as is, and note, perhaps, that between a write and a read, a flush may be required?
This file is a replacement for FPC.patch.8.zip and contains the changes/reversions above. It has been tested with the latest updates -- Revision: 49374 -- as per svn info.
Cheers,
Norm.