The Sinclair QL Forum

Thanks, I didn't want to register for a minimal change, maybe you can correct data bus width to 16.

Peter wrote:Thanks, I didn't want to register for a minimal change, maybe you can correct data bus width to 16.

Oops, I thought I'd read 32 bits data bus where the manual says 32 bits address bus. I'll correct it asap.

Jan.

I am testing some specific functions and Q68/SMSQE commands. I have several drives configured (WIN1_, WIN2_, ... FAT1_, QUB1_). Everything works fine, but I have two questions about behavior that I don't understand.

1) The win_drive$ and qub_drive$ functions give me errors. For example:

PRINT WIN_DRIVE$(1) always reports the "buffer full" message.
PRINT QUB_DRIVE$(1) causes a system crash.

However, PRINT FAT_DRIVE$(1) work fine.

2) I change the resolution with DISP_MODE command and configure the SuperBasic windows (windows#0, windows#1 and Windows#2) with custom sizes. The first time everything works correctly. But when I change to 1024x768 resolutions and later return to 512x384 resolution, when I rescale windows to sizes greater than 512x256 (for example 512x300), I get an "out of range" error message. (I have to apply "reset" to Q68 so everything work correctly again).

What I can be doing wrong?

Hi,

What is your definition of the WIN_DRIVE and QUB_DRIVE and QUB_DRIVE.

They must have exisiting WIN and QUB container located on the SD Card in either a FAT16 or FAT32 partition.

I will look into the changing of the video resolution, but it sounds like the DISP_SIZE command is changing the resolution of the display but not resetting the screen channels. I would say this has to be done after the change in resolution.

A possible solution would be to do:

DISP_SIZE disp_num : WMON

Where disp_num = 1 to 7

Not a clean solution, but should work.

afx wrote:I am testing some specific functions and Q68/SMSQE commands. I have several drives configured (WIN1_, WIN2_, ... FAT1_, QUB1_). Everything works fine, but I have two questions about behavior that I don't understand.

1) The win_drive$ and qub_drive$ functions give me errors. For example:

PRINT WIN_DRIVE$(1) always reports the "buffer full" message.
PRINT QUB_DRIVE$(1) causes a system crash.

However, PRINT FAT_DRIVE$(1) work fine.

Ensure that those drives are pointing to valid devices or container files before trying to read them. Unless there is a configuration option, a good place to do that initially would be in your boot file.

2) I change the resolution with DISP_MODE command and configure the SuperBasic windows (windows#0, windows#1 and Windows#2) with custom sizes. The first time everything works correctly. But when I change to 1024x768 resolutions and later return to 512x384 resolution, when I rescale windows to sizes greater than 512x256 (for example 512x300), I get an "out of range" error message. (I have to apply "reset" to Q68 so everything work correctly again).

What I can be doing wrong?

I dont think DISP_MODE was designed for changing resolutions mid-session. On the QL you could safely change between mode 0 and mode 8, but DISP_MODE should ideally only be set at boot time. I dont have a Q68, but I remember from my Atari + QVME days, that if you needed to change disp mode without rebooting, you had to close all windows that would fall outside the new resolution before the change or the machine would crash.

Per,

that's right. None of the QL operating systems (or windowing systems, for that matter) is designed to be able to change display resolutions on the fly.

It might work if you close all windows first, but there's no guarantee.

Tobias

afx wrote:PRINT WIN_DRIVE$(1) always reports the "buffer full" message.
PRINT QUB_DRIVE$(1) causes a system crash.

Do the corresponding container files exist?

afx wrote:2) I change the resolution with DISP_MODE command and configure the SuperBasic windows (windows#0, windows#1 and Windows#2) with custom sizes. The first time everything works correctly. But when I change to 1024x768 resolutions and later return to 512x384 resolution, when I rescale windows to sizes greater than 512x256 (for example 512x300), I get an "out of range" error message.

What happens if you re-scale in 1024x768 first, and then change DISP_MODE?

Derek_Stewart wrote:They must have exisiting WIN and QUB container located on the SD Card in either a FAT16 or FAT32 partition.

AFAIK containers must be in a FAT32 partition, not FAT16.

Peter wrote:Do the corresponding container files exist?

Yes, the files names are correct, and the SD is FAT32 (16GB).

Here some screens:

I have defined my WIN and QUB containers in Q68_SMSQ configblock. I have two SDs (slot 1 and slot 2) When starting, everything works fine (dir win1_ ... dir win2_ ... dir qub1_.... etc.). There is only one error in the win_drive$(x) function and qub_drive$(x). For example: The SD content with print card_dir$ (1) is as follows:

Peter wrote:What happens if you re-scale in 1024x768 first, and then change DISP_MODE?

That way, the result is correct! (Without errors).

Now work fine, when I change the windows size before disp_mode the error don't occur (when resizing from large resolutions to minors).

afx wrote:The SD content with print card_dir$ (1) is as follows

I'm just guessing, but that FAT32 directory looks suspicious to me. You should only have files with 8.3 filenames in the toplevel directory. Maybe save the OS binary and the filesystem containers, reformat the SDHC card, and copy them back.

afx wrote:

Peter wrote:What happens if you re-scale in 1024x768 first, and then change DISP_MODE?

That way, the result is correct! (Without errors).
Now work fine, when I change the windows size before disp_mode the error don't occur (when resizing from large resolutions to minors).

Yes, otherwise windows are larger than the display for some time, and that should be avoided.

By the way, as long as the colour depth remains, and all windows are within the future display range before switching mode, I could always change DISP_MODE on the fly without any odd behaviour. This may not be an official feauture, but it seems to work.