Screen Writing

[Derek_Stewart]

Hi,

I have been looking at older game programmes for the QL, which the software authors assumed:

Screen Base Address = $20000
System Variables = $28000

While this worked for a while till QDOS was debugged with Minerva and later with SMSQ/E.

A question I have be contemplating:

If a programme is written that assumes that the Screen Base Address is loacated at $20000 and is $8000 in length and the System Variables are located below the Screen memory at $28000.

The programme, usually a game, is altered so that the correct Manager Trap QDOS: MT.INF (SMSQ/E: SMS.INFO), to find the System Variables and the use of QDOS: SD.EXTOP (SMSQ/E: SMS.XTOP) to find the screen memory base and length based on the channel ID of the screen channel passed in register A0.

The SD.EXTOP/SMSM.XTOP routine, will return the screen address at $32(A0) of the channel ID and the screen length is $64(A0)

Would the programme run any slower with this alteration and would the extra code be a burden of smaller QL systems with only 128K?

[NormanDunbar]

Hi Derek,

I would think that it depends on how many times the code needs to access the screen, and if it does so using a "constant" screen base value held in a register. Let's say that the screen base is loaded into A4 once in the code and all accesses are then down with offsets from A4. of course, this assumes that they developer has not also used a hard coded value for the width of a pixel row!

If the code has to get the screen address frequently, I'm sure it would slow things down.

In summary:

• Getting sysvars frequently would potentially slow things down;
• Getting screen address frequently would potentially slow things down;
• Getting the addresses once in the initialisation would have minimal effect overall.

It obviously depends on how frequently the code needs to get the addresses as to how much effect it would have on the performance.


Cheers,
Norm.

[dilwyn]

For anyone interested in how to use assembler to check screen base addresses etc have a look at the source code for my little basic extensions toolkit called Display_cde, on the toolkits page on my site. The extensions show how to check a lot of system information. Norman's DJtoolkit is also a good source of example assembler code.

[Derek_Stewart]

Hi,

I think once the locations of the System Variables and Screen Base address had been found, then this should only required once. I do not think SMSQ/E moves the hardware address around, only defines them on boot up.

The idea was to have two subroutines:

Get_Sys_Vars
Get_Screen_Base

to replace all the direct calls to the QL hardware.

I am not sure if this would work, it would minimise the software alterations required, keeping the original design the same.

I have consulted all the major assembler sources including DJtooklit and SMSQ/E source code, refering back to the SMSQ/E Reference manual.

[mk79]

I think once the locations of the System Variables and Screen Base address had been found, then this should only required once. I do not think SMSQ/E moves the hardware address around, only defines them on boot up.

SMSQ/E never moves the system variables anyway, only Minerva can do this. But no matter the system, they NEVER move during runtime, only during boot. This much is guaranteed.

The screen base could move at any time. But only if the user requests a new resolution and/or colour depth. That's unlikely to be an issue while playing a game. It would be for "well behaved" programs that are expected to survive a new screen resolution.

Marcel

[tofro]

This is what I tend to use:

First thing is opening a console channel, then I check for presence of the Pointer Interface - If that's there, resolution and window width can be directly queried from there. Screen dimension and PE version get stored somewhere in the data area (pointed to by a6).

When the PE cannot be detected by the iop.pinf call, I normally assume 512x256 or 256x256 screen resolution depending on the MODE set. But the next step (starting at peDone) is a short call to an SD.EXTOP routine that pulls screen start (video RAM start address) and line length (amount of bytes per horizontal scan line) into internal variables.

Once that is done, you have all the information for writing a relatively save direct screen-addressing program.

Code: Select all

graphicsInit    
                ; DEBUG   {'GraphicsInit'}
                move.w  UT.CON,a3
                lea     windowdef,a1 
                jsr     (a3)
                bne     err_exit
                move.l  a0,channelID(a6)

                move.w  #-1,d3                  ; timeout forever
                QDOSIO$ iop.pinf                ; check for pointer interface
                tst.l   d0
                bne.s   no_pe
                lea     peInstalled(pc),a0
                move.l  d1,(a0)                 ; save pointer version
                bra.s   peThere
no_pe
		bra.s   peDone
peThere
                lea.l   winLimits(a6),a1
                move.l  channelId(a6),a0
                QDOSIO$ iop.flim
                tst.l   d0
                bne     err_exit

peDone
; Now we need to get screen start address and line length
                move.l  a6,a1                   ; Parameter to extop (data area)
                move.w  #-1,d1                  ; timeout
                lea.l   extop,a2
                QDOSIO$ SD.extop                ; call routine
                rts

***************************************************************************************
* extop
* Called as part of the screen driver
* sets the screen-related parameters in the data space
* On entry, a0 points to the channel definition block, a1 to the dataspace
* a6 to system variables
***************************************************************************************
extop
                move.l  SD_SCRB(a0),screenStart(a1)
                move.w  SD_LINEL(a0),lineLength(a1)
                move.l  a6,sysVars(a1)                  ; while were here, remember them
                clr.l   d0                              ; no error!
                rts
                
                

[Derek_Stewart]

I think once the locations of the System Variables and Screen Base address had been found, then this should only required once. I do not think SMSQ/E moves the hardware address around, only defines them on boot up.

SMSQ/E never moves the system variables anyway, only Minerva can do this. But no matter the system, they NEVER move during runtime, only during boot. This much is guaranteed.

The screen base could move at any time. But only if the user requests a new resolution and/or colour depth. That's unlikely to be an issue while playing a game. It would be for "well behaved" programs that are expected to survive a new screen resolution.

Marcel

Hi Marcel,

If the user requests a new resolution and/or colour depth, what happens to existing open channel to the screen memory, does the operating system up date all the channel tables with the new screen address?

[mk79]

Hi Marcel,

If the user requests a new resolution and/or colour depth, what happens to existing open channel to the screen memory, does the operating system up date all the channel tables with the new screen address?

Sure, otherwise things would stop working pretty much immediately.

[Peter]

Hi Marcel,

If the user requests a new resolution and/or colour depth, what happens to existing open channel to the screen memory, does the operating system up date all the channel tables with the new screen address?

Sure, otherwise things would stop working pretty much immediately.

Which does not mean things usually continue to work.
One can get all sorts of funny effects when switching resolution and/or colour depth after boot time.

[mk79]

Which does not mean things usually continue to work.
One can get all sorts of funny effects when switching resolution and/or colour depth after boot time.

Yes, resolution is not so much a problem as higher resolutions have been around for a long time and most apps are used to it.
But changing colour depth is a truly dramatic experience for everybody involved. Basically only save time to do this is during boot before any jobs are loaded.