The Sinclair QL Forum

I am trying to learn to program in the Pointer Environment in assembler. I don't want to use EasyPointer or EasyPEasy, just plain assembler.

I have a couple of questions (I'm sure there will be more)
1. How do I determine how much memory I need to reserve for the Window Working Definition, and the Window Status Area?
I know the Working Definition is going to be a bit bigger than the Window Definition (word pointers become long pointers etc).
Is there a formula for working it out - Like size of the window definition + x bytes for each loose item + y bytes for each...... etc.
Likewise for the Window Status Area.

2. Just how does the pattern and colours data work in Sprite definitions? I've looked at working examples, but I cannot see the way the data corresponds to the graphic that appears on the screen.

Martin Head

I suspect you need to download Wolfgang's QPTR manual and have a gander at page 185 onwards where it describes the status area (of the working definition?). There's a fixed size of $3F bytes followed by one byte per loose item. Then, elsewhere, there's an area of one byte per application sub window menu item.

I think!

Cheers,
Norm.

Many years ago, Geraint Jones did an assembler "course" for the pointer environment in Quanta. I can't remember when, sorry. Is there an index?

Cheers,
Norm.

Martin,

Martin_Head wrote: 1. How do I determine how much memory I need to reserve for the Window Working Definition, and the Window Status Area?
I know the Working Definition is going to be a bit bigger than the Window Definition (word pointers become long pointers etc).
Is there a formula for working it out - Like size of the window definition + x bytes for each loose item + y bytes for each...... etc.

Actually, there's no such thing as a documented "formula" for that (rather the opposite). When I have to calculate that size, I normally do it using trial and error (and that is one of the reasons why I tend to use EasyPtr for creating menu definitions for assembler programs, apparently, it "knows" that formula), starting from a rough estimate plus some added elbow room and then checking with the debugger.

The manual states

This may seem unfair, but only the application will be able to determine the maximum space required in this area.

At least some pity for you, but not very helpful otherwise

Tobias

NormanDunbar wrote:There's a fixed size of $3F bytes followed by ...

Bollox! The fixed size is of course $40 bytes long, not as above. The address offset into the status area is from 0 to $3F. The status byte of the first loose item is at $40 in the status area.

Sorry.

The QPTR manual is at http://www.wlenerz.com/smsqe/add1.html.

Cheers,
Norm.

I am currently using the QPTR manual that came with my QPTR package many years ago. I will have a look at Wolfgang's QPTR manual.

At the moment I am using the guesstimate plus a bit of wriggle room approach, just wondered if there was a 'formula'.

No response to question 2. Is it that tricky then? I know there are programs for designing sprites and creating the assembler for them. But I would like to know how it works. That,s why I am trying to avoid things like EasyPointer that do some of the hard work for you.

OK new question, number 3
I want to have a text box on my window that I can type into and edit. Say a filename.
Do I have to open a new (secondary?) window with it's own channel number? How do I get the cursor to appear in it when I click on it? Where is the text stored that I type?

I have disassembled the calculator from QPAC1/2 and that has taught me a lot. But it does not have a text input. I may have to disassemble one of the other QPAC1/2 programs that does have a text input that I want, to see how it works.

Martin Head

Page 104 ...

Wm.swinf, Wm.swlit, Wm.swapp etc set the window to the info window, loose item, application sub window. Then you can use wm.rname or wm.ename from page 124 to edit text in the appropriate area, or us other code to do other stuff with that area.

I've no idea at present, how to set the window back to full size again afterwards! Maybe wm.rptr copes. Never tried it in pure assembly to be honest. As far as I remember ....

Cheers,
Norm.

NormanDunbar wrote: I've no idea at present, how to set the window back to full size again afterwards! Maybe wm.rptr copes. Never tried it in pure assembly to be honest. As far as I remember .....

WM.WDRAW (which you would normally do anyways after the input) should restore everything to the previous state.

Tobias

Thanks Tobias, very useful.

Cheers,
Norm.

Martin_Head wrote:No response to question 2. Is it that tricky then? I know there are programs for designing sprites and creating the assembler for them. But I would like to know how it works. That,s why I am trying to avoid things like EasyPointer that do some of the hard work for you.

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?