Q68 New users and general usage thread

Nagging hardware related question? Post here!
User avatar
tofro
QL Wafer Drive
Posts: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Postby tofro » Thu Apr 12, 2018 11:16 am

Peter wrote: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.


Note that "all the windows" might include windows that are not currently displayed, for example windows of programs shrunk to a button. So, your mileage might vary. I have also experienced that resolution changes tend to work pretty often, but there's always the odd chance of crashing your computer.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2011
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 New users and general usage thread

Postby Dave » Thu Apr 12, 2018 3:41 pm

Has anyone created a relative speed index for all the different screen modes on the Q68 yet?


User avatar
tofro
QL Wafer Drive
Posts: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Postby tofro » Thu Apr 12, 2018 3:45 pm

Yep. The higher the resolution and color depth, the slower the machine. That's good enough for me ;)

Tobias


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

Re: Q68 New users and general usage thread

Postby Peter » Thu Apr 12, 2018 4:16 pm

Dave wrote:Has anyone created a relative speed index for all the different screen modes on the Q68 yet?

Manual provides figures for modes 3, 5 and 7. Since there is no cache yet, you can calculate it, I described that already.

Relative speed loss = Vertical refresh rate (60 Hz) * Screensize (... MB) / Memory bandwidth (160 MB/s)

Although I don't recommend the large video modes when speed is relevant, this is a relative loss. Q68 speed remains much faster than GoldCard.

Things change dramatically, when code/data is located in fast RAM. Not only 4x faster CPU access, but also no more dependency on the video mode. That's why cache would make much sense.


User avatar
Dave
SandySuperQDave
Posts: 2011
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 New users and general usage thread

Postby Dave » Thu Apr 12, 2018 5:35 pm

Indeed.

Can a user force an SBASIC program to run from the fast RAM?


User avatar
tofro
QL Wafer Drive
Posts: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Postby tofro » Thu Apr 12, 2018 7:07 pm

Dave,

I don't think he can, and even if he could:

An SBASIC Program is "running" in so many places, that even if the BASIC code itself would reside in a specific (fast) RAM area, the interpreter code runs wherever SMSQ/E has been loaded initially (and that is definitely not in fast RAM), the data area are put wherever there's room, and precompiled SBASIC code is put again somewhere else.

An SBASIC program is just too wide-spread across all of the memory space that there is no single location where you could concentrate it.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
Gold Card
Posts: 397
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Q68 New users and general usage thread

Postby pjw » Thu Apr 12, 2018 8:46 pm

But a compiled S*BASIC program could possibly?


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: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 New users and general usage thread

Postby tofro » Thu Apr 12, 2018 9:02 pm

If it's not too large, most probably yes.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
afx
Chuggy Microdrive
Posts: 66
Joined: Tue Dec 28, 2010 10:23 pm

Re: Q68 New users and general usage thread

Postby afx » Fri Apr 13, 2018 12:58 am

Peter wrote:
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.


Problem (1) solved.

- Derek sent me an updated q68_smsq.win version. I had an outdated version. It was only necessary replace the q68_smsq.win old version with new one in my SD card. Now win_drive$ function work fine.


Problem (2) clarified.

- Now I understand the disp_mode behavior better. Change display resolutions on the fly is a cool Q68 feature, I find it very useful.


Peter, Derek, thank you very much for your support.

QL and Q68 forever! :D

.


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

Re: Q68 New users and general usage thread

Postby afx » Tue Apr 24, 2018 8:50 pm

Hi.

Last week I've been testing serial interface with my Q68.

The results have been very good, especially with Ser-USB, but I have some doubts in my data transfer tests between Q68 and PC.

I report my expereinces separately, a) Ser-USB test and b) PC to Q68 transfer tests.

a) Ser-USB test. The results have been great. Q68 connects perfectly with Ser-USB at 115200 baud. The connection is 100% reliable, both, with SerUSB2 driver (QDOS unit) and UsbWiz driver (Fat32).

(What is the Ser-USB? ... The Ser-USB is a device that attaches to one of the QL serial ports and provides access to storage devices such as SD cards, memory sticks and USB hard drives. Ser-USB was sold by Memory Lane Computing from 2011 to 2012).

Some screens:

Q68_SerUsb2Driver.jpg
SerUsb2 driver


Q68_UsbWizDriver.jpg
UsbWiz driver


Q68_SerUSB.png
Q68 Ser-USB


For example, psion chess is loaded in approximately 5 seconds, psion xchamge in 18 seconds (approximately).

b) PC to Q68 transfer tests. The results have not been so good. I managed reliably transfer data between Q68 and PC (a small SuperBASIC program on Q68 side, a small C# programa on PC-Win10 side), but I have a problem.

The problem is that I had to put a "Thread.Sleep" (between 5 and 20 ms) inside loop that transfers the individual bytes in PC side so the connection is reliable. This causes communications to take a long time.

The parameters that I have used are:
Baud 115200 (also 19200)
Parity none
Data bits 8
Handshake none

I don't have knowledge in serial communications, so what can I be doing wrong?

Another question, SER_FLOW, SER_ROOM, SER_BUFF work on Q68?



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests