Q68 New users and general usage thread

Nagging hardware related question? Post here!
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Post by Peter »

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


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Q68 New users and general usage thread

Post by janbredenbeek »

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.


afx
Trump Card
Posts: 171
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Post by afx »

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?


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Q68 New users and general usage thread

Post by Derek_Stewart »

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.


Regards,

Derek
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Q68 New users and general usage thread

Post by pjw »

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
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Post by Peter »

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.


afx
Trump Card
Posts: 171
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Post by afx »

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)
Containers in config block
Containers in config block
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:
dir win1_ ... then error with print win_drive$(1)
dir win1_ ... then error with print win_drive$(1)
The SD content with print card_dir$ (1) is as follows:
print card_dir$(1)
print card_dir$(1)


afx
Trump Card
Posts: 171
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Post by afx »

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).


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Post by Peter »

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.


Post Reply