SCR_BASE

[dilwyn]

I spent a fair bit of time trying to explore what was going wrong in using SCR_BASE in SBASIC to find the base address of the screen on Q68 and QIMSI-Gold in the extended display modes (anything higher than the QL modes set by DISP_MODE 0 or 1).

I kept getting a negative value from SCR_BASE and it took me a while to realise that as SCR_BASE returns a signed 32 bit value, and the extended mode screens are at very high addresses on both machines ($FE80 0000) it's bound to return a negative value rather than the unsigned address value of 4,269,801,472 which corresponds to $FE80 0000. The same issue is true with other toolkit extensions which return screen base address.

Obviously having a 'negative' address may cause problems for programs which, for whatever reason, directly address the screen for doing graphics. (I was investigating why all sorts of things went wrong with an older program of mine which writes directly to the screen. Tut tut, naughty me )

So in an effort to document the undocumented... (I'm sure some will say we shouldn't be writing direct to screens, but on very rare occasions it's necessary to directly manipulate the screen)

Unsigned 32 bit values go from 0 to 4,294,967,295 ($0 to $FFFF FFFF)
Signed 32 bit values go from -2,147,483,648 to +2,147,483,647

If we get a negative value from SCR_BASE we can do one of two things:

1) if the number is negative, add 4,294,967,296 (note: at these number sizes SBASIC will be using 'E' notation), something like: adr = SCR_BASE: IF adr < 0 THEN adr = adr + 4294967296

2) If the address returned by SCR_BASE is negative, check for MACHINE type and then do a hard address depending on the screen mode of the machine. MACHINE will be decimal 18 (hex 12) for Q68 or QIMSI-Gold, and if the screen address given by SCR_BASE is negative it will be at the fixed address $FE80 0000 (decimal 4269801472).

Code: Select all

adr = SCR_BASE
IF adr < 0 THEN
  IF MACHINE = 18 THEN adr = 4269801472
END IF

Method 2 only works on machines where the screen memory is at a fixed, known address. For standard QL mode 4 and 4 screens the base of screen is at QL addresses anyway, so a positive value which needs no change.

Any more ideas on this?

[Andrew]

Obviously having a 'negative' address may cause problems for programs which, for whatever reason, directly address the screen for doing graphics. (I was investigating why all sorts of things went wrong with an older program of mine which writes directly to the screen. Tut tut, naughty me )

I am not sure about this.
In Pitman I use SCR_BASE to find the base address of the screen and I write the sprites directly to video memory with Move_Memory. The game works perfectly on Q68 in mode 6, so there are no problems.
It also works on QPC2 in all colour modes and all resolutions.

[dilwyn]

You may have got lucky.
Although SCR_BASE returns a negative (signed) value, other commands like Sbytes, POKE_L etc also can use the negative address values in parameters. It only becomes a problem if you need something using absolute (i.e. positive) 32 bit addresses.

In the QL screen modes (512x256 mode 4 or 8) the screen is at same address as QL anyway - decimal 131072.

Even if scr_base returns a negative value (which it will with the screen at $fe800000), something like Sbytes

SBYTES filename,scr_base,scr_llen*scr_ylim

to save a screen shot in high resolution or high colour modes will still work as it too uses signed values when handling parameters, so is able to accept SCR_BASE negative values. Peek_l and Poke_l do so too. Not checked if they do when compiled. I'm guessing now, that if Basic commands, functions &extensions use Basic 's parameter fetching, they too may work the same way. That once the signed value is through parameter passing, it's a 32 bit address in a register anyway.

The program I was trying to debug was using an extension which calculated absolute, unsigned, values. It was at that point that things went wrong by trying to "rectify" the negative value and adding 2^32 at which point things started going out of range.

Just be aware that the signed address values can actually work ok in basic as long as you keep track of where the address value is signed or unsigned.

[dilwyn]

Forgot to mention that what made me notice the negative address values in the first place was a program with over-enthusiastic error trapping on functions, testing for negative values as errors:
Adr=SCR_BASE
IF adr < 0 : print "Oops, something went wrong":STOP

[BSJR]

Forgot to mention that what made me notice the negative address values in the first place was a program with over-enthusiastic error trapping on functions, testing for negative values as errors:
Adr=SCR_BASE
IF adr < 0 : print "Oops, something went wrong":STOP

Hi Dilwyn, you make an interesting point here.
I use this test often without problems but my QL-RAM doesn't go into Giga bytes either so it should be save.
Do any of the emulators even support this?
: IF adr <0 AND >-40 : should be an error code, anything else could be a valid address.

BSJR

[dilwyn]

Hi Dilwyn, you make an interesting point here.
I use this test often without problems but my QL-RAM doesn't go into Giga bytes either so it should be save.
Do any of the emulators even support this?
: IF adr <0 AND >-40 : should be an error code, anything else could be a valid address.
BSJR

Well, QIMSI-Gold has "only" 32MB, of which about 28M seems free for programs, so I'm not sure if the high video memory area probably is or isn't part of that. I haven't looked at that in any detail (probably explains in the manual if we look), e.g. maybe the FPGA has some separate RAM for the extended screen modes at those high addresses, or 4MB of the 32MB RAM appears at those high addresses. Peter would explain I'm sure.

When you ask if other emulators support this, did you mean the signed high address values? Probably irrelevant because AFAIK no emulator puts the screen memory (or any memory probably) at such high addresses to generate negative values. They simply wouldn't appear. I'd imagine that all versions of SMSQ/E for all systems handle signed parameters in this way, just that the possibility of negative SCR_BASE never became apparent to us before Q68 and QIMSI-Gold.

When I consulted with Peter, Stephan and Wolfgang when I first came across it, they were clearly aware and able to clarify it quickly for me.

As Andrew implied, I don't think we need to worry too much about it, just be aware of the signed values as something to consider if we observe misbehaviour in a minority of software which writes direct to the screen on these machines.

Point taken about checking for a small range negative value error return, rather than just any negative being treated as an error.

[BSJR]

Hi Dilwyn, you make an interesting point here.
I use this test often without problems but my QL-RAM doesn't go into Giga bytes either so it should be save.
Do any of the emulators even support this?
: IF adr <0 AND >-40 : should be an error code, anything else could be a valid address.
BSJR

Well, QIMSI-Gold has "only" 32MB, of which about 28M seems free for programs, so I'm not sure if the high video memory area probably is or isn't part of that. I haven't looked at that in any detail (probably explains in the manual if we look), e.g. maybe the FPGA has some separate RAM for the extended screen modes at those high addresses, or 4MB of the 32MB RAM appears at those high addresses. Peter would explain I'm sure.

When you ask if other emulators support this, did you mean the signed high address values? Probably irrelevant because AFAIK no emulator puts the screen memory (or any memory probably) at such high addresses to generate negative values. They simply wouldn't appear. I'd imagine that all versions of SMSQ/E for all systems handle signed parameters in this way, just that the possibility of negative SCR_BASE never became apparent to us before Q68 and QIMSI-Gold.

When I consulted with Peter, Stephan and Wolfgang when I first came across it, they were clearly aware and able to clarify it quickly for me.

As Andrew implied, I don't think we need to worry too much about it, just be aware of the signed values as something to consider if we observe misbehaviour in a minority of software which writes direct to the screen on these machines.

Point taken about checking for a small range negative value error return, rather than just any negative being treated as an error.

The QPC2 manual gives 255MB as maximum memory allowed, SMSQmulator keeps it at 240MiB.
The SMSQ/E manual doesn't give any limit thus relying on the underlying system.

I would suspect that QDOS/SMSQ/E does the conversion from Float to Integer address correctly as long as one doesn't use any String representation in between.
Even Marcel's FREEMEMBT gives me a negative value.

BSJR