Hardware pointers and cursors.

Anything QL Software or Programming Related.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Hardware pointers and cursors.

Post by pjw »

Dave wrote:.. Let me explain this in a way that might spark some empathy. ..
He, he. Poor sod. Now you know how Rip van Winkle must have felt when he woke up after a hundred years!

Look, its not that I wouldnt want a new graphics accellerator standard or anything, but I wouldnt want one designed by someone who didnt have the first idea about how the current system works. Afterall, theres about 30 years worth of software using it, which youve obviously decided to negate. Why start "fixing" things now?

Im sure you want to make yourself useful, then why not concentrate on one product at a time, and lets see what you can do? Then we can revisit the issue when youre up to speed.


Per
dont be happy. worry
- ?
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Hardware pointers and cursors.

Post by Dave »

pjw wrote:Look, its not that I wouldnt want a new graphics accellerator standard or anything, but I wouldnt want one designed by someone who didnt have the first idea about how the current system works. Afterall, theres about 30 years worth of software using it, which youve obviously decided to negate. Why start "fixing" things now?
I know. I'm just sounding out the potential for it. If there isn't any, I won't go beyond the 10 chipsets I have bought already.

My idea is to make a generic display adapter for retro electronics where all the config lines are jumpered, so it can be quickly applied to any system. Maybe. I have a serial card to finish this weekend (just clean up some level conversion) and lots to do on Issue 8.

This is just a case of having people thinking about certain possibilities - possibilities which anyone else could bring to fruition.


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

Re: Hardware pointers and cursors.

Post by pjw »

Dave, I didnt mean to sound as harsh as it came across; I just wanted to try to save you from another distraction ;) Being a sufferer myself, Im familiar with how the imagination races ahead, generating ideas at thousands of times the speed of any chance of implementing them! Im sure many people here are wetting their pants in anticipation of the forthcoming Issue 8.. ;)


Per
dont be happy. worry
- ?
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Hardware pointers and cursors.

Post by Dave »

pjw wrote:Dave, I didnt mean to sound as harsh as it came across; I just wanted to try to save you from another distraction ;) Being a sufferer myself, Im familiar with how the imagination races ahead, generating ideas at thousands of times the speed of any chance of implementing them! Im sure many people here are wetting their pants in anticipation of the forthcoming Issue 8.. ;)
It is a problem I have ;)

That said, this particular video hardware is surprisingly simple. Far simpler than the 4M memory card Nasta did the schematic for and I did the PCB design for.

Anyway, I have bigger problems. Some mystery person sent me an anonymous gift - an Altera FPGA development kit and book! I know what I'm doing this winter!


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Hardware pointers and cursors.

Post by mk79 »

Dave wrote:The root of my question is: if there were hardware support for funtionality that is currently implemented laboriously in software - that makes the implementation unconscionably difficult to work with - is there any will or desire to shift that load from software to hardware?
Sorry, what difficulty are you even talking about?

Code: Select all

spr=ALCHP(1024):LBYTES win1_some_sprite_spr,a
SPRW #1,50,50,spr: REMark EasyPtr in this case
This draws the sprite at pixel position 50,50. I really don't get what's "unconscionably difficult" about that, it's BTW about the same effort in assembler. Of course this call also automatically selects which sprite to draw if you supply a combined QL/high colour sprite and even converts the sprite into the current screen mode if necessary, too, so the programmer does not have to worry about what platform the program is running on. And does alpha-blending if necessary. I call this "fucking cool" and not "unconscionably difficult".

All this potential video hardware would do is split an already small user base even further, because most platforms would not have this hardware feature. On the other hand I was trying to unify the platforms through the PE, because the programmer does not have to care too much about the colour mode, the PE already does most things for you. And if the underlying platforms supports accelerated graphics like blitting then the PE supports this too, without the programmer even noticing. This is currently only true for QPC and SMSQmulator, but any potential hardware blitter could be integrated likewise, so how fucking cool is that?
Mac OS X is free. It will install on most newer PCs with little difficulty.
This is explicitly forbidden by Apple. It's like saying bread is free, you just have to steal it.
In my enthusiasm, I come here and ask, and the topic of conversation quickly shifts to "oooh, Dave doesn't understand the pointer environment, let's tell him how he's wrong!"
Sorry, but you're setting the tone with all the "oooh, the PE is so stupid and outdated and slow and 'unconscionably difficult to work with', while at at the same time saying that you have never used it. This is not a good start, especially when somebody who wrote most of the later PE code reads your text (hint: me).

Rant over and out. Marcel


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

Re: Hardware pointers and cursors.

Post by Dave »

mk79 wrote:Sorry, what difficulty are you even talking about?
The difficulty of having the code modified to use more capable graphics hardware.
mk79 wrote:All this potential video hardware would do is split an already small user base even further, because most platforms would not have this hardware feature.
Then we shouldn't ever create anything new, in case we accidentally improve things for some but not others. This proposed video system would work in everything from the base QL thru the Q40/60. It wouldn't work on the Q68, but the Q68 already has very decent video. It could be added to a future Q68 if it used a slightly larger FPGA. All it needs is access to address, data, control lines, and for reads to be from shadow RAM.
mk79 wrote:On the other hand I was trying to unify the platforms through the PE, because the programmer does not have to care too much about the colour mode, the PE already does most things for you. And if the underlying platforms supports accelerated graphics like blitting then the PE supports this too, without the programmer even noticing. This is currently only true for QPC and SMSQmulator, but any potential hardware blitter could be integrated likewise, so how fucking cool is that?
That IS pretty cool :D I'm trying to unify the platforms by giving the base QL Q68-like graphics capabilities. Are you saying that PE doesn't care too much about bit order for colour information, or are you saying something different? Bit order flexibility would increase the accessible capabilities of this chipset quite significantly.
mk79 wrote:Sorry, but you're setting the tone with all the "oooh, the PE is so stupid and outdated and slow and 'unconscionably difficult to work with', while at at the same time saying that you have never used it. This is not a good start, especially when somebody who wrote most of the later PE code reads your text (hint: me).
There's a bit of picking and choosing going on there. I only found out TWO DAYS AGO that the mouse buttons are reversed in PE. In 30+ hours of plugging away at it, I did not know that. I'd think that would be an important thing to mention. Maybe in the documentation. Alas, it's one of those situations where the people who wrote the documentation wrote it from a place of already knowing how to do it. It seems to be assumed that nobody might be a PE beginner and need proper introductory guides.

Which, in this day and age, someone in the know might use a screen cap routine on an emulator and simply visually introduce the concepts of the PE, one at a time. Though that seems to be a bad use of time since there will probably be only a few dozens of new users, it would certainly be welcomed by those new users. It would definitely be more intuitive to learn from that than a PDF. Especially given we're not in our teens or 20s anymore! ;) I also recognize the hundreds.... thousands of hours it takes to write something as complex as the PE, and maintaining it must be a bit of a rabbit hunt at times.

That said, nothing requires anyone to think positively of it. It might be a good learning experience to put a Q68 system in front of a teenager who has never seen the PE, and has a lifetime of using more standard window systems, turn it on and ask them to explore. To see what they struggle with, and what needs explaining.

It just seems weird to me that in such a small community, someone says, "well I had a really bad experience with this so I don't like it" and is roundly condemned. That not a single person, NOT ONE, asks, "so what happened? What bit did you get stuck on?" It was someone somewhere else who pointed out the mouse buttons are reversed. That one fact by itself will get me further down the road. I've set some time aside to have another go at the PE next weekend.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Hardware pointers and cursors.

Post by mk79 »

Dave wrote:That IS pretty cool :D I'm trying to unify the platforms by giving the base QL Q68-like graphics capabilities. Are you saying that PE doesn't care too much about bit order for colour information, or are you saying something different? Bit order flexibility would increase the accessible capabilities of this chipset quite significantly.
The standalone PE is QL mode only. The PE that is inbuilt into SMSQ/E on the other hand has the colour drivers and as such of course can handle all known QL colour modes except Aurora 16-colours mode.
There's a bit of picking and choosing going on there. I only found out TWO DAYS AGO that the mouse buttons are reversed in PE. In 30+ hours of plugging away at it, I did not know that. I'd think that would be an important thing to mention.
They are not reversed per se, there is just a different paradigm to it. Left mouse button selects an item in both Windows and the PE, so in this case they are the same. But to act on an item is a double click in Windows and a right click in the PE. The PE does not have double clicks (I guess the PE was developed before the double click was even invented).
Maybe in the documentation. Alas, it's one of those situations where the people who wrote the documentation wrote it from a place of already knowing how to do it. It seems to be assumed that nobody might be a PE beginner and need proper introductory guides.
Well, which documentation did you read in the first place? There are countless "PE beginner's guide". One of the more popular is http://www.dilwyn.me.uk/docs/ptr/peig/pe.html. The point is that no matter how many manuals you write, people in general do not read (or find) them.
That said, nothing requires anyone to think positively of it.
There is constructive criticism and there is "I've never used the PE for longer than it takes to disable it".

Marcel


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Hardware pointers and cursors.

Post by NormanDunbar »

mk79 wrote:There are countless "PE beginner's guide". One of the more popular is http://www.dilwyn.me.uk/docs/ptr/peig/pe.html.
Probably my most popular effort, written way way way back when I still lived in Aberdeen. That was at least 1990, possibly even a little before that. I wrote it because I was quite hopeless at understanding Tony and/or Jonathan's documentation on the subject - even after I bought QPAC 2 and obtained a very large manual (large as in pages of content) and still not getting it!

I had a similar problem with the EasyMenu manuals too. Maybe it's just me? ;)


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Hardware pointers and cursors.

Post by tofro »

Dave,

when talking about "Mouse buttons reversed" you should be pointing out "reversed compared to what?"

Windows (that sort of nailed the left/right-button usage down) wasn't by far as predominant when the PE was designed as it is today. MacOS only had one mouse button, and X-Windows never made any assumptions about mouse button usage.

And I was a bit surprised that someone who praises RiscOS for its plain design of a WIMP is complaining about confusing (?) semantics of mouse buttons ;)

Tobias


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

Re: Hardware pointers and cursors.

Post by Dave »

tofro wrote:when talking about "Mouse buttons reversed" you should be pointing out "reversed compared to what?"

Windows (that sort of nailed the left/right-button usage down) wasn't by far as predominant when the PE was designed as it is today. MacOS only had one mouse button, and X-Windows never made any assumptions about mouse button usage.

And I was a bit surprised that someone who praises RiscOS for its plain design of a WIMP is complaining about confusing (?) semantics of mouse buttons ;)
I learned to use a mouse on an Archimedes, so Select, Menu, Adjust are the most natural thing in the world to me. Select is obvious. Menu brings up any context sensitive menu. Adjust is just select but the menu remains up instead of being dismissed. Simple. I do think they would have been better off going for a two-button mouse, and using shift or alt as the "adjust"...

I did a fair amount of ARM and BBC BASIC V programming back in the day. The five programmers reference manuals that described the Risc OS system calls were exquisitely written, and should be emulated. At that time, scalable, aliased fonts and hardware pointers were quite new to that level of the market. I earned some half way decent money rewriting a few different versions of basically the same article, describing anti-aliased font principles, which were published in Archive magazine initially, then versions in a couple of newstand mags and Personal Computer World. Those were good times, when my mind was a sponge.

Now, I am a grumpy old fart.
mk79 wrote:
Dave wrote:That said, nothing requires anyone to think positively of it.
There is constructive criticism and there is "I've never used the PE for longer than it takes to disable it".
When I said that, it quickly summarized that 'I do not have extensive experience with the PE.' I did not know it would become a flash point. I have spent somewhere between 30 and 40 hours using the PE. That includes five hours this last weekend. As I have learned from Norman's post above, I found the worst possible source of info - Tony's manual. Terse? It's the definition of opaque. I did not look further than that, because I did not expect anyone would have written a soft and fluffy guide for ordinary people. You, Marcel, are blessed to not be an ordinary person.

Maybe it would help if you understood that I use my QL/Q68 almost exclusively for programming. I don't program for anyone else's consumption, I never do more than one thing at a time, and I never have a need to use "windows" more complex than the ones I create myself. A lot of what I write is heavily graphics oriented and writes directly to video RAM. So, really, even if I got along with PE, it would bring me very little if any utility and in many ways would be obstructive to my goals. To me, for my use case, it is at best a passive nuisance, occupying memory and absorbing CPU cycles like some mild and harmless Doctor Who alien.

Interestingly, I only bought a Q68 as a way to run my BASIC programs faster and have better video capabilities. I did this because the problem I have with the PE, I also have with the compilers. Which, I am sure the code is great but the documentation is again too terse. I don't recall which of Supercharge or Q-Liberator it was, but each section of the manual required you to have read the other sections first, as each section referred to principles of other sections without explanation. So you had to read the manual iteratively. Which, considering that the USE of the programs seems to be quite simple, is the most self-defeating bit of writing ever. It just makes you feel like you don't understand. And then you have this fantastic tool, but it just has all these little mystery black boxes. Nothing major, but it means occasionally something unexpected happens, and you're just.... a bit stuck. And you can bet the manual will be no help.

So: I bought a Q68 to compensate for my own incapacity. My lack of intellectual heft is, it turns out, good for the QL maker community :P


Post Reply