Beyond Super Gold Card

A place to discuss general QL issues.
User avatar
Pr0f
Gold Card
Posts: 393
Joined: Thu Oct 12, 2017 9:54 am

Re: Beyond Super Gold Card

Postby Pr0f » Fri Nov 15, 2019 7:58 am

...

stephen_usher wrote:If you want to go digital use DVI as that's a sub-set of HDMI and probably doesn't have the licensing issues

Yes, I wrote that already. I don't really like the DVI solution, because the connector consumes even more board width than VGA and breaks the compact Q68 case size. (And for a SGC successor DVI would even be worse, because the card has just one usable side for external connectors, not two.) Whereas a HDMI connector, espcially the upright version, frees some space, e.g. for 3.5 mm jack sockets. So DVI would only be a last resort.


If you have an extension card that sticks out from the bbql case, then you potentially have 3 sides to play with, and that might also aid cooling, if speeds are going to be 'cranked up' a bit.

I am not a big fan of the DVI connector either, and in fact this interface supports both digital and analog connections and fully wired, supports 2 monitors, not just one, which is why it's so large - not a problem on a big PC server case, but not good if you want to keep sizes down. DVI also doesn't have any sound channel, whereas HDMI does.


User avatar
Peter
Aurora
Posts: 918
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Postby Peter » Fri Nov 15, 2019 2:02 pm

Pr0f wrote:If you have an extension card that sticks out from the bbql case, then you potentially have 3 sides to play with, and that might also aid cooling, if speeds are going to be 'cranked up' a bit.

Hehe, very much QL style, reminding of the good old days, where boards were also sticking out. And the cooling should of course be with a golden heatsink. :lol:

But seriously, even a minimal size board, just reaching the QL edge, has already way too much area for the functional components. I'd hate wasting even more.
And design from me would certainly need no cooling at all.


User avatar
vanpeebles
Commissario Pebbli
Posts: 2154
Joined: Sat Nov 20, 2010 7:13 pm
Location: North East UK

Re: Beyond Super Gold Card

Postby vanpeebles » Fri Nov 15, 2019 3:17 pm

Make it in one of those whopping big cases where the QL sits on top :D


User avatar
SinclairSociety
Bent Pin Expansion Port
Posts: 98
Joined: Fri Feb 22, 2019 6:17 pm

Re: Beyond Super Gold Card

Postby SinclairSociety » Fri Nov 15, 2019 3:55 pm

vanpeebles wrote:Make it in one of those whopping big cases where the QL sits on top :D


How about make it like a Atari Mega 2 or Mega STe/TT as the QL keyboard is not large, about the same size as Atari keyboards for these systems were. Make a nice case to sit behind the QL that has all sorts of new input output. Just run a cable from the expansion port to this new external case/ device.

This way the QL is still used so the nostalgia stays and super dooper expansion is at hand and looks the part.

The Mega STe and TT were quite neat looking.

TJ


Sinclair Computers are AWESOME!!
bixio60
Chuggy Microdrive
Posts: 54
Joined: Sun May 04, 2014 7:05 am

Re: Beyond Super Gold Card

Postby bixio60 » Sat Nov 16, 2019 10:48 pm

I checked again because this is a video resolution for Q68 I've never used and the refresh speed, according my feeling, is more than adequate: DISP_Mode 4 1024x768 (4 colour)
Fabrizio

Peter wrote:
tofro wrote:well, it's not only the screen refresh for high color display that slows the Q68 - Also, the poor CPU has lots more to do to initially fill the screen with information.

Yes I'm aware, but the initial fill (or things like moving windows) is not what I think bugs users like Fabrizio most. I have also heard from another user who is only concerned about the 56% loss of overall speed in the highest resolution, and otherwise okay with display speed. Let's see how Fabrizio perceives 1024x768 in 4 colours - if that is already too sluggish for folks like him, it makes little sense to only add separate video memory.

All this reminds me of my initial plan to hide the memory intensive display modes altogether. I have always warned about them, and the manual warns about them, but in the end people just use and feel annoyed.


User avatar
Peter
Aurora
Posts: 918
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Postby Peter » Sun Nov 17, 2019 10:21 am

bixio60 wrote:I checked again because this is a video resolution for Q68 I've never used and the refresh speed, according my feeling, is more than adequate: DISP_Mode 4 1024x768 (4 colour)

Many thanks for your feedback. Could you also try DISP_MODE 5, the "Nasta" mode in 1024x768 pixel @ 256 colours? I presume that is already a little too slow for your requirements?

Would be interesting to know if there are mainly specific tasks (like moving a windows) that are annoying for you? Some SMSQ/E operations in this area, are massively (!) slower than the technical capabilities of the Q68, and there might be a chance to solve that on the software side. (Not trivial since affected routines are generic, and can not be optimized just for the Q68. But there might be common ground. For example, moderate loop unrolling.)

That said, to reduce the non-specific impact of screen refresh in memory-intensive modes, cache is still required, and ideally also a separate video RAM.
Unfortunately, I can not work on both cache (as logic update for the Q68) and a new hardware at the same time.

In general, squeezing more speed out of native hardware, is a quite unsatisfying task today. There is no really motivating goal anymore, emulation on PCs will remain faster.


Derek_Stewart
QL Wafer Drive
Posts: 1504
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Beyond Super Gold Card

Postby Derek_Stewart » Sun Nov 17, 2019 8:57 pm

Hi Peter,

If there is a vote, I would say development on new hardware.

I use the Q68 mainly in DISP_MODE 4, which is very compatiable with all my existing QL QPTR software.

I usually use Digital Precision software like ACT, EditorSE, 3D Precision in DISP_MODE 1. But most of the DP Software runs in DISP_MODE 6, but their software pre-dates the Hi-Colour system, so does not take advantage of the colours.

I do not use DISP_MODE 3,5,7 mainly fue to speed, but I do not have much software that will use the colours and resolution.


Regards,

Derek
User avatar
mk79
Gold Card
Posts: 399
Joined: Sun Feb 02, 2014 10:54 am

Re: Beyond Super Gold Card

Postby mk79 » Sun Nov 17, 2019 11:16 pm

Peter wrote:Would be interesting to know if there are mainly specific tasks (like moving a windows) that are annoying for you? Some SMSQ/E operations in this area, are massively (!) slower than the technical capabilities of the Q68, and there might be a chance to solve that on the software side. (Not trivial since affected routines are generic, and can not be optimized just for the Q68. But there might be common ground. For example, moderate loop unrolling.)
Au contraire, platforms that provide accelerated graphics (like QPC or SMSQmulator) already have their own code paths. This is no problem at all, the code structure is prepared for it.

Cheers, Marcel


User avatar
Peter
Aurora
Posts: 918
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Postby Peter » Mon Nov 18, 2019 9:29 am

My informations that e.g. the bit blitting operations for native hardware were generic, were by hearsay. But from a usually well informed source. If it is not so, even better.

However, Marcel does not seem to say the code is separated, just that it could be separated. That means work, and I would not expect that work to be trivial. Glad if I'm wrong, I'm not an SMSQ/E developer and have no ambitions to become one.


User avatar
mk79
Gold Card
Posts: 399
Joined: Sun Feb 02, 2014 10:54 am

Re: Beyond Super Gold Card

Postby mk79 » Mon Nov 18, 2019 2:43 pm

Platforms can use the generic code path or provide their own. You have that choice per mode even, QPC uses the generic code path for QL modes and its own for 8 bits and up. It's as much work as changing

dev8_iod_con2_16_mblock_rel

to

dev8_iod_con2_qpc16_mblock_rel

in a _cct file to get the accelerated "move block" routine, which among other things is the one used to move windows around (also show/hide windows, so accelerating this one call can already help quite a bit).



Who is online

Users browsing this forum: No registered users and 2 guests