BBC Micro: Hiding Program Listings?

[ThomasAdam]

Hi,

Back in the days when I had a Model B (but I'm presuming this could have applied to any BBC Micro version -- I'd be interested if there's any differences to the approach needed), there were a couple of programs (LOGO could have been one of them, but I don't think it matters) which once loaded, if you were to then type:

Code: Select all

L.

No listing would appear -- in fact, something "blocked" that instruction from working, and the screen would instantly clear.

I'm curious how that could have been achieved. I presume it will have had something to do with the loaded program, but what would that have to do in order to affect the L. command from working?

TIA!

Thomas

[duikkie]

mostly with vdu21 or calls like that

somewhere on this form i uploaded a ssd file ( called nice programs or so) which can deblock them and lots more

it was a poor way to protect something

[davidb]

Perhaps not exactly what you saw, but many programs included the Ctrl-S (VDU 21) control code in REM statements. This had the effect of disabling VDU output when the user listed the program, so you would only get to see the listing up until the first one of those codes encountered. As duikkie said.

[ThomasAdam]

Interesting.

Perhaps someone should take me through what happens when a program is loaded into memory, so I can best understand why, in REM statements, this would even have any effect.

By all means point me towards the literature if there is any!

Kindly,
Thomas

[duikkie]

i am terrible in search in this form . but the program is called B.shower on the ssd NICEPROG.ZIP or maybe NICEPROG.RAR

you have allso B.HIDER

[duikkie]

it is very simple :

10 REM and in machinecode &15 and maybe &7f,&7f and more

[duikkie]

found it on my laptop

[duikkie]

simple things

load program

then delete 1,11 ( lines 1 to 11)

maybe the code is only in line 1 to 10 , i think not

[richardtoohey]

Perhaps someone should take me through what happens when a program is loaded into memory, so I can best understand why, in REM statements, this would even have any effect.

Don't worry too much about obscuring the listing for now, let's just make a listing beep with VDU 7.

So your listing in memory is stored as the line number, a token for REM, then the text of your REM.

When you do LIST, the command will read & display the line number (from binary to decimal characters), read & translate the token for REM (so the one byte token expands to the text REM on-screen), and then stream out (using the VDU driver) the text following the REM command.

So if you have

10 REM Hello

It is stored as two bytes (IIRC) for the line number, one byte for the REM token, then Hello.

So when you list, it effectively does VDU H VDU e VDU l VDU l VDU o.

If you replace (with a ? poke) the H of Hello with a binary 7 - that's a beep.

So when you list, it effectively does VDU 7 (beep) VDU e VDU l VDU l VDU o.

You can replace 7 with other VDU codes, like 21, or 12 (clear screen.)

I'll dig out the actual token for REM and more information on how a program is stored - or do some peeking & poking yourself.

[richardtoohey]

Tokens are in the User Guide, pp 483, REM is &F4.

VDU codes ibid p. 507

Will see if I can find something in there about BASIC program layout. (Not in the User Guide ... maybe Beebug somewhere ...)

Here's some simple fiddling:

Code: Select all

10 REM HELLO
>P.~PAGE
      1900
>P.?&1900
        13
>P.?&1901
         0
>P.?&1902
        10
>P.?&1903
        12
>P.?&1904
        32
>P.?&1905
       244
>P.~244
        F4
>P.?&1906
        32
>P.?&1907
        72
>P.ASC*"H"
        72
>?&1907=7
>L.
   10 REM ELLO

Looks like I've missed a few things - but hopefully you can see what I'm doing.

[richardtoohey]

Ah, bit more information in Birbaum's Assembly Language Programming for the BBC Microcomputer.

2nd Edition, pp. 189, discusses RETRIEVE a program to try and restore a mangled BASIC program.

It says a line is stored as

0D start of line (so that's the 13 at PAGE, &1900, above)
00 0A (two bytes for line number &0A is 10 decimal)
XX line length (the 12 in my example above)
32 above is my space between line number 10 and the REM
... and so on.

&FF is the terminator for a program.

[duikkie]

rem is &f4 after that they do &21 , printer off , a lots of &7f( delete) to hide the hole line, maybe clear screen &12.

you can really play with the vdu charaters

they use it for blokking a listing, displaying something else used by *dir for disc. or play a trick , like a few of my machine code programs.
item TODAY I PROTECTED ..

[jgharston]

Will see if I can find something in there about BASIC program layout. (Not in the User Guide ... maybe Beebug somewhere ...)

http://beebwiki.mdfs.net/Program_format

[richardtoohey]

rem is &f4 after that they do &21 , printer off , a lots of &7f( delete) to hide the hole line, maybe clear screen &12.

VDU 21 would be VDU &15, and to clear screen is VDU 12 or VDU &0C. (Not trying to be clever but trying to avoid confusion.)

[duikkie]

always confused about # and & in machinecode lda#&01 always save

rem is &f4 after that they do &21 , printer off , a lots of &7f( delete) to hide the hole line, maybe clear screen &12.

VDU 21 would be VDU &15, and to clear screen is VDU 12 or VDU &0C. (Not trying to be clever but trying to avoid confusion.)

[Coeus]

...so I can best understand why, in REM statements, this would even have any effect.

I think the key bit of understanding here is that the OS ROMs VDU driver works a bit like a text terminal as you might use on a mainframe, Unix, Linux etc. in that it can be sent a sequence of bytes, some of which are printed literally and some of which instead cause some action to happen such as moving the cursor on the screen, drawing shapes, making a beep etc.

When a program is listed literal text is sent to that VDU driver. Normally that would only be ASCII text characters but if someone has embedded control codes these would be acted on by the VDU driver at the appropriate point. Some of the control codes do such things as enabling and disabling output to various devices so by including the "disable output to screen" code at the beginning and the corresponding enable code at the end the middle part of the program listing is never displayed.

The normal editor for program line entry in BASIC also echos the characters you type to the VDU driver, even ones it doesn't store as part of the line you are typing, and you can explot this to control VDU features from the keyboard, for example typing LIST, then Ctril-B (IIRC) to enable copy to printer before finally pressing return and getting your listing on the printer.

[ThomasAdam]

Hi all,

Just to follow up on this, I was reading some old Acorn User magazines, and noticed the following excerpt attached to this message.

I've not typed this into my BBC Micro or an emulator yet -- but is this another approach which achieves the same aim?

Kindly,
Thomas

[BeebMaster]

This is a different approach, which corrupts the end of program information stored by BASIC, rather than disabling video output within the program, which use of VDU code 21 does. Here it confuses the BASIC interpreter sufficiently to prevent the program being LISTed or SAVEd, but doesn't confuse it sufficiently to prevent it from being RUN.

[ThomasAdam]

This is a different approach, which corrupts the end of program information stored by BASIC, rather than disabling video output within the program, which use of VDU code 21 does. Here it confuses the BASIC interpreter sufficiently to prevent the program being LISTed or SAVEd, but doesn't confuse it sufficiently to prevent it from being RUN.

Heh -- thanks for this. Indeed, until I can try this for myself (and apologies if this were to be obvious by trying it for myself), given the two approaches, which one is more robust? Given my recent example, is there more of a likely occurrence of something going wrong, and a program listing more often than not displaying?

Cheers,
Thomas

[Bitstik]

I remember using *fx200,2 and *fx200,3 BITD to “protect” my BASIC programs- not that anyone would have been interested in them!

[duikkie]

I remember using *fx200,2 and *fx200,3 BITD to “protect” my BASIC programs- not that anyone would have been interested in them!

this will not help you can still list the program before start:)

[Bitstik]

Ah yes of course - my mistake!
Could be implemented with a loader but I see there are better methods.