Window Manager programming in Assembler

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 3095
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Window Manager programming in Assembler

Post by tofro »

Silvester wrote:
Martin_Head wrote:

But of course, to use the macros you first need a good understanding of QPtr and its data arrays :geek:
To use the macros, you first need to have a QPTR license. I don't think it's still on sale, and I don't think it's available for download anywhere.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Martin_Head
Aurora
Posts: 970
Joined: Tue Dec 17, 2013 1:17 pm

Re: Window Manager programming in Assembler

Post by Martin_Head »

mk & tofro

I did wonder if it was to do with the bit patterns in the screen memory. Then I thought, No, That's so hardware dependant. Tony Tebby made QDOS so hardware independant. I thought, Surely the Window Manager would use some standard bit pattern, and then convert it to the correct form for the hardware it's running on.

Wrong....

On another topic.. This may be an 'obvious' question..

If I am writing a PE/Window manager program that I want to run in mode 4, and mode 8, and maybe GD2 modes. Do I need to write 2, or 3 different Window Definitions, one for each screen mode. Then when the program starts, look at the screen mode/window manager version to decide which Window definition to use.


As far as working out how much memory to reserve for the Window Working Definition, and Status areas. I was thinking about writing a routine that would allocate an area of memory, fill it with something like $55. Then use the Window manger routines to read your Window Definition and build the Working Definition in this area. Then scan the area backwards looking for the $55 to stop. This would be the end of the Working Definition. Subtract the start of the area from it, and add bit working room to get the required size for the Working Definition

Martin Head


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

Window Manager programming in Assembler

Post by mk79 »

Martin_Head wrote:I thought, Surely the Window Manager would use some standard bit pattern, and then convert it to the correct form for the hardware it's running on.
With the limits imposed by the QL hardware you have to make shortcuts. SMSQ/E on the other hand can convert sprites between the different colour modes. The converted sprite is cached because the systems were/are still too slow to make the conversion live.
If I am writing a PE/Window manager program that I want to run in mode 4, and mode 8, and maybe GD2 modes. Do I need to write 2, or 3 different Window Definitions, one for each screen mode.
If you use the system palette then no, you only need to do one definition. Except for mode 8 maybe, but that's because of the different pixel size, not the colours.
As far as working out how much memory to reserve for the Window Working Definition, and Status areas. I was thinking about writing a routine that would allocate an area of memory, fill it with something like $55.
I'm at a conference and don't have access to my files. But that sounds awfully complicated. EasySource I think outputs the needed value, so I'd really advice for designing the menu in EasyMenu and convert that to assembler using EasySource.


User avatar
BSJR
Trump Card
Posts: 220
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: Window Manager programming in Assembler

Post by BSJR »

mk79 wrote:The sprite format is pretty well documented. QL format in the Qptr manual, extended colour sprites for example here:
http://www.kilgus.net/smsqe/display.txt

Not sure if the latter is incorporated into the new Qptr manual. Any specific questions?
This may be a bit off a side step but looking at the display.txt, I cannot find how the various GD2 palette modes (3,7,15,31) should work. Where is this palette located inside the sprite, how many bytes are used for each colour sample?
Or is this one of the "Options" that was never worked out?

BSJR


User avatar
tofro
Font of All Knowledge
Posts: 3095
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Window Manager programming in Assembler

Post by tofro »

mk79 wrote:EasySource I think outputs the needed value, so I'd really advice for designing the menu in EasyMenu and convert that to assembler using EasySource.
It indeed does. It emits symbols for both the working definition and the status area length.

Code: Select all

worklen	equ	$00000210
statlen	equ	$00000060
Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Window Manager programming in Assembler

Post by Silvester »

tofro wrote: To use the macros, you first need to have a QPTR license. I don't think it's still on sale, and I don't think it's available for download anywhere.
Tobias
The macros included with QPtr are exactly the same as included with the current SMSQ/E sources. They are WMAN macros. QPtr is the Basic toolkit (bin file).

Like most people at the time, I bought the QPtr package just for the official documentation on the Pointer interface/Window manager.

Although I had a tinker with QPtr BASIC keywords I've never used them. Though I have used EasyPtr 3 extensively.

Even though I already had TT original QPtr I stumped up again and bought new update from Jochen Merz (along with many other QL things).

I don't know if you know but you don't 'include' macros in your finished code - they are like a catalyst - only used to create machine code, and otherwise don't get 'used'.

I have never read anything about 'license' required to use them in your own code.


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

Re: Window Manager programming in Assembler

Post by mk79 »

BSJR wrote: This may be a bit off a side step but looking at the display.txt, I cannot find how the various GD2 palette modes (3,7,15,31) should work. Where is this palette located inside the sprite, how many bytes are used for each colour sample?
Or is this one of the "Options" that was never worked out?
The palette is not per sprite, but global for the whole OS. It's the same you get when using COLOUR_PAL in basic. You can redefine it using the PALETTE_8 command http://superbasic-manual.readthedocs.io ... #palette-8. Of course this makes it pretty much impossible to known what colour you actually end with as a developer, so I think nobody has ever used it in practice.


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

Re: Window Manager programming in Assembler

Post by mk79 »

tofro wrote:
mk79 wrote:EasySource I think outputs the needed value, so I'd really advice for designing the menu in EasyMenu and convert that to assembler using EasySource.
It indeed does. It emits symbols for both the working definition and the status area length.

Code: Select all

worklen	equ	$00000210
statlen	equ	$00000060
Thanks for checking. I'm now united again with my laptop and just checked QPtr, there the size of the area is determined automatically using the SETWRK macro.

And by the way
Location: SW Germany
Um, may I ask where in SW Germany?


User avatar
tofro
Font of All Knowledge
Posts: 3095
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Window Manager programming in Assembler

Post by tofro »

mk79 wrote:
tofro wrote:
Location: SW Germany
Um, may I ask where in SW Germany?

Stuttgart

Grüßle,
Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Window Manager programming in Assembler

Post by mk79 »

tofro wrote:
mk79 wrote:Um, may I ask where in SW Germany?
Stuttgart

Grüßle,
Tobias
And I thought I was the last active QL user in the region :o

Cheers from Esslingen, Marcel :-)


Post Reply