ATTR & SCREEN$

[PeterJ]

Was ZX Spectrum BASIC the only one which included such commands (or equivalent)? Looking at other machines of the time, this is my understanding.

If this is the case how did other BASICs allow the handling of collision detection in BASIC (as is used in so many type ins).

Thanks

[p13z]

No idea of the answer to this question - but,
the SCREEN$ function bug in Speccy BASIC makes it a lot less efficient and useable than it should be

[p13z]

And as a more related answer to the original question:
I assume the screen memory layout makes "PEEK"ing screen data easier for other machines in BASIC.

[catmeows]

ATTR is quite specific thing related to ZX hardware. On many computers POINT function would return color of single point.
SCREEN$ is not so exotic, for example CoCo Extended Basic has GET and PUT commands that can copy characters from rectangle on screen to string and draw them back. SCREEN$ can be simulated by GET x,y,1,1.

[PeterJ]

No idea of the answer to this question - but,
the SCREEN$ function bug in Speccy BASIC makes it a lot less efficient and useable than it should be

Are you referring to this?

The SCREEN$ error
(from Understanding Your Spectrum, by Stephen Kelly and others.)

The BASIC routine for calculating SCREEN$ accidentally leaves a duplicate entry of the string result at the top of the calculator stack. This means that the BASIC statement IF "X"=SCREEN$ (0,0) THEN PRINT "BUG" will invariably print "BUG" no matter what happens to be on the screen at the time. The bug is fortunately not present in machine code, and calling the subroutine S_SCRN$_S will evaluate SCREEN$ correctly, leaving the stack correct. As with the STR$ error the best way to avoid it in BASIC is to use temporary variables, e.g.

LET A$=SCREEN$ (0,0) : IF "X"=A$ THE PRINT "BUG" will work correctly.

[Joefish]

ATTR just does a PEEK (22528 + (y*32) + x)
SCREEN$ needs to fetch 8 bytes and compare with each character in the character set, one-by-one, which is terribly slow.

On a machine with a character-mapped screen, you could just do a PEEK to get the equivalent of the CHR$ code for the character at any particular position, as easily as you can get its attribute on the Speccy.

Doesn't quite work though so easily on the ZX81 as the length of its screen memory varies; it doesn't simply store 32 bytes per line if it doesn't need to. Collision detection in ZX81 BASIC is done by doing a PRINT AT ; command to move the PRINT position, then reading the DF_CC system variable at 16398 to get the address of that print position on the screen, then doing a PEEK to read the character already there. So you see something like this a lot in listings:

Code: Select all

PRINT AT Y , X ;
LET C = PEEK ( PEEK 16398 + 256 * PEEK 16399 )

e.g. It's Snowing Again by John West:
https://archive.org/details/sinclair-pr ... 2/mode/1up

[AndyC]

Locomotive BASIC on the CPC had a COPYCHR$ function which basically did the equivalent of SCREEN$, at least as of BASIC 1.1

But reading the screen memory like that is generally a terrible way if trying to do collision detection as you waste a lot of time trying to convert a bitmap back into a recognizable character. Most BASIC programmers tended to use an array of what objects were at what location and just cross reference that to find out what was a the position a player might "collide" with.

[PeterJ]

Hi [mention]AndyC[/mention],

Looking at listings in Sinclair User and Sinclair Programs most seem to use ATTR or Screen$. I get your point about arrays though. I've seem some good examples using that technique.

[PeterJ]

SCREEN$ needs to fetch 8 bytes and compare with each character in the character set, one-by-one, which is terribly slow.

Genius! So that's why it doesn't work with UDGs then?

I did see a routine today which checks for a result of zero, then moves the system variable to point 256 below the start of the UDGs then tries again.



The Spectrum Handbook by Tim Langdell

[p13z]

Are you referring to this?

The SCREEN$ error
(from Understanding Your Spectrum, by Stephen Kelly and others.)

Yes. Basically, as I understand it, the screen$ function messes up the stack - so also - if you use screen$ as part of a calculation, you will get a garbage answer. You can LET a$=screen$ then use a$. But as trying to make anything remotely fast enough to be playable in BASIC usually requires pairing down everything to the least number of lines, statements and expressions, this becomes pretty frustrating.

[PeterJ]

Just noticed that Memotech BASIC has a similar command:

[p13z]

The screen$ bug is also a particular pet hate of mine, as first time around, as a young kid, with no internets or access to any relavent literature, I spends months frustrated by this, until the penny finally dropped that my code was OK, and it was actually Speccy BASIC that was faulty.

[PeterJ]

This is something that [mention]+3code[/mention] links to yesterday. They do a very interesting speed comparison between screen$ and attr:

http://blog.jafma.net/2020/08/29/effici ... um-v/#sp_3

[AndyC]

Hi @AndyC,

Looking at listings in Sinclair User and Sinclair Programs most seem to use ATTR or Screen$. I get your point about arrays though. I've seem some good examples using that technique.

Well ATTR us kind of a special case of using the screen memory as an array and probably slightly more efficient if you can live with the limitations, because each attribute is only one byte (and has to be there for the screen in any case). SCREEN$ is best avoided though, both because of the bugs and because it's really slow.

[uglifruit]

This is something that @+3code links to yesterday. They do a very interesting speed comparison between screen$ and attr:

http://blog.jafma.net/2020/08/29/effici ... um-v/#sp_3

That's a fascinating article (thank you Google translate)