peek can be dangerous?

[notwhoyouthink]

I am pretty sure i remember a post somewhere on this board, mentioning that certain call peek()'s can hang the system.

Sorry, i do not remember where i read that.

If anyone knows what i am talking about, please fill me in.

Either that, or i am just crazy, becuase i know i read something to that effect.

[zzip]

I am pretty sure i remember a post somewhere on this board, mentioning that certain call peek()'s can hang the system.

Sorry, i do not remember where i read that.

If anyone knows what i am talking about, please fill me in.

Either that, or i am just crazy, becuase i know i read something to that effect.

pokes can

 

peeks shouldn't unless there's a bug.

[apersson850]

Maybe if you peek at GROM read data or VDP read data addresses. Since these chips are autoincrementing on each read, they'll not return the next byte as the system expects.

[RXB]

I do not think CALL PEEK or RXB CALL MOVES would lock up system as I have written RXB programs to move entire VDP or GROM or RAM to screen and they never crash or lock up.

 

I even have a RXB demo that turns on DSR cards and reads the card, the only exception was the PGRAM card that would lock up.

Edited July 21, 2017 by RXB

[apersson850]

One reason for BASIC to be pretty slow is all the administration it does. Perhaps it resets the GROM read address over and over again, or at least after all instructions which has a chance to modify it, to make sure it can return and continue properly.

If you load a different address to the VDP when you are running a Pascal program, then it will fail. When p-code is interpreted from VDP RAM, the PME assumes that nothing else messes up the VDP read address, unless it does it by itself.

[Tursi]

Perhaps it resets the GROM read address over and over again

GPL does, at least. Every byte