IOP.SWDF - what does A1 point at please?

[NormanDunbar]

While MrsD is away, Norm will get time to play. Once he's done his chores that is!

I'm looking at IOP.SWDF in the current QPTR manual, the assembly code, obviously! I might want to use it is some potential code for the eComic. However, the documentation is a bit weird:

A1 points to a long word pointer to a table of pointers to sub-window definitions. This pointer may be zero. It is followed by a sub-window record for the main part of the window. The pointers to sub-window definitions are long words, the list is terminated by a zero long word. Each pointer points to a sub-window record.

Am I correct in decoding this to be as follows:

Code: Select all

start
    lea tblPtr,a1          ; Pointer to pointer to table
    ...
    
tblPtr
    dc.l swdfList         ; Pointer to sub window definitions
    dc.w MAIN_X
    dc.w MAIN_Y
    dc.w MAIN_X_ORG
    dc.w MAIN_Y_ORG
    dc.w 0, 1, GREEN, WHITE  ; spare, border width, border colour, paper colour
    dc.l MAIN_POINTER_SPRITE
    
swdList
    dc.w SUB_1_X
    dc.w SUB_1_Y
    dc.w SUB_1_X_ORG
    dc.w SUB_1_Y_ORG
    dc.w 0, 1, GREEN, WHITE 
    dc.l SUB_1_POINTER_SPRITE
    
    ; Repeat as required.
    
    dc.l 0         ; List terminator.

With apologies for any invalid assembly code there!

Thanks.


Cheers,
Norm.

[tofro]

Norm,

this looks OK to me.

Tony does, however, have a bit of a different concept of "pointer". Quite a number of his "pointers" are in fact relative, so, instead of

Code: Select all

tblPtr
    dc.l swdfList         ; Pointer to sub window definitions

it should probably be

Code: Select all

tblPtr
    dc.l swdfList-*      ; Pointer to sub window definitions

(Same for the other "pointers"). Otherwise you will create a position-dependant program

[NormanDunbar]

Thank ToFro, very helpful. I might have to update my qdosmsq webdite with this info. George Gwilt didn't expand much when he kindly erote some stuff for me,

If I get time tomorrow, I'll hopefully try it out.

Thanks again.

Cheers,
Norm.

[tofro]

Quite a number of pointers - and data they point (sic) at - in QPTR (dear!) are relative - typically the ones that are not calculated at run-time, but prepared up-front at compile-time. In such cases, they must be relative, as no one knows where the program is going to be loaded and would otherwise have to undergo runtime relocation. Pointers that are provided by the run-times, however, are typically absolute. Tony has not always been very clear (I think when he meant absolute, he wrote "address", and used "pointer" for relative) which is which, but in your example, it's relatively obvious. I can only remember this single general statement about window manager structure pointers, right at the beginning of the WM chapter:

Within these definitions all pointers are word length relative pointers. Where reference is to be made to an address which is more than a word offset away, the least significant bit is set. This (after clearing the bit) is then a pointer to a long word containing a relative address. All addresses are even. A zero pointer implies that the structure pointed to is absent.

Whether the latter part of this sentence ("long" relative pointers marked by being odd) is also true for IOP.SWDF input, I don't know - but doubt, as these are not "word" pointers. I've had a short browse through Tony's example programs, but couldn't find an IO.SWDF example anywhere.

[NormanDunbar]

Thanks again.

If I get time to play, I'll let you know what happens.

Cheers,
Norm.

[tofro]

Norman,

I have been looking at the IOP.SWDF call for a while now, and found it is actually asking for a pointer into (rather: a subset of) the window working definition in a1 - The working definition normally holds absolute pointers that have been expanded by the WM.SETUP call from the initial window definition (which holds relative pointers) - so you can expect this list to have been generated using absolute addresses at runtime (and no, you probably shouldn't try and define it yourself as you did in your example, you can, but it's going to be a chore). When looking at the SMSQ/E source code, the code takes a1 and simply puts it into the channel definition block (the window working definition) - so, I guess, it wants an address.

Maybe I should row back a bit and ask what you actually want to achieve?

[pjw]

Ive been following this thread with interest as I too was fiddling in this area - and got stuck. I was trying to make a stand-alone version of SPRS (set the pointer sprite for a given window) and using IOP.SWDF seemed to be the only "legal" way to do it. Your last post, tofro, seems to nail it: We're talking existing Working Definition here, not setting up a new structure! Seems obvious - once you know (like most thing PE ). So I guess all I need to do is poke the address of my sprite into the relevant sub window definition. I must try and see when I next get to that point..

[pjw]

Ah, I remember now: My program doesnt have a working definition! So Id have to devise a skeletal one for the purpose. Hmm, maybe there'll be something in Norman's next eComic that I could use for this..

[NormanDunbar]

Afternoon Gents,

IOP.SWDEF is part of the pointer environment, and nothing to do with WMAN, so I was assuming that I could, for example, open a console, then use a list of sub-window definitions to divide said console into sections which can be used for various things I might want to do. The existing docs for IOP.SWDF implies, to me anyway, that this is what it does.

To my mind, it's along the lines of WMDEF in WMAN, you give it a windows definition and it does the needful when called. The docs do not give me the impression that I need a fully setup window definition in order to call it and I'm assuming that the PE can be used happily without WMAn, as I have done it before. I wrote some "pointer perversions" for Dilwyn's amusement a long time ago.

<insert delay while I try to find source code - a thought occurs>

See attached. Boo.asm is one of the afore mentioned perversions. I waits for as many minutes as configured, then pops up and changes the pointer to a user defined sprite. It doesn't do any harm to the system or files etc, it's not a virus. I had a look at the source and, who would have known, I use the (QDOS) version of IOP.SWDF in there!

If you run it, to quit: HOLD down the ESC key (and possibly click both buttons together to simulate a HOT_DO '.' ) the comments don't match the code exactly. Oops!

This will probably help, granted I use a zero pointer to the sub windows, but it's probably a start.

Cheers,
Norm.

boo.zip

(2.62 KiB) Downloaded 40 times

[mk79]

IOP.SWDEF is part of the pointer environment, and nothing to do with WMAN

Yeah, except that it was written to ingest 100% the WMAN data structures Or the other way round, but sure, you should be able to use it without. The window must be a managed window, so make sure the outline is set.

As mentioned in the manual "This call is used to set the pointer to the sub window definition list. This is a sub-set of the window working definition.". WMAN gives the call the ww_splst offset ("pointer to sub-window sprite list") from the working definition. Now, there isn't a description of the sub-window sprite list, but what WMAN sub-windows can change the sprite? Application sub-windows! So it just happens that the structure of the "sub-window sprite list" exactly matches the structure of the "application sub-window list", a downright amazing coincidence

Marcel