Q68 New users and general usage thread

[tofro]

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

[Dave]

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

[tofro]

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

Tobias

[Peter]

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.

[Dave]

Indeed.

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

[tofro]

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

[pjw]

But a compiled S*BASIC program could possibly?

[tofro]

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

[afx]

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.

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!

.

[afx]

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:

SerUsb2 driver

UsbWiz driver

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?