Q68 New users and general usage thread

Nagging hardware related question? Post here!
User avatar
Peter
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Postby Peter » Tue Jan 23, 2018 7:57 pm

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


User avatar
janbredenbeek
Trump Card
Posts: 249
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Q68 New users and general usage thread

Postby janbredenbeek » Tue Jan 23, 2018 9:40 pm

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
Chuggy Microdrive
Posts: 53
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Postby afx » Tue Apr 10, 2018 10:47 pm

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
QL Wafer Drive
Posts: 1026
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Q68 New users and general usage thread

Postby Derek_Stewart » Wed Apr 11, 2018 8:49 am

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
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Q68 New users and general usage thread

Postby pjw » Wed Apr 11, 2018 9:39 am

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
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
tofro
QL Wafer Drive
Posts: 1368
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Postby tofro » Wed Apr 11, 2018 11:04 am

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


User avatar
Peter
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Postby Peter » Wed Apr 11, 2018 8:27 pm

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
Chuggy Microdrive
Posts: 53
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Postby afx » Thu Apr 12, 2018 12:10 am

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)
windrivefunc0.jpg
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:
windrivefunc1.jpg
dir win1_ ... then error with print win_drive$(1)


The SD content with print card_dir$ (1) is as follows:
windrivefunc2.jpg
print card_dir$(1)


afx
Chuggy Microdrive
Posts: 53
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Postby afx » Thu Apr 12, 2018 12:19 am

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
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 New users and general usage thread

Postby Peter » Thu Apr 12, 2018 9:02 am

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.



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 2 guests