osasci

[wemb]

So - just renovated my first BBC master - first BBC microcomputer I've touched in about 30 years.

Having great fun playing with BBC basic and just started exploring what's possible with the built-in assembler. Mostly limited to doing pointless things with loops over strings and sending the output to osasci.

Also taken a look at a look at beebasm so I can fiddle with this sort of stuff in vscode too and one of the examples is a 'Hello World' which starts by sending &16 to osasci/ &FFE3. This, apparently, clears the screen. It's ascii character 22: 'SYN Synchronous Idle' - I did a cursory search but couldn't find anything documenting why this causes the Beeb to clear the screen. Is it just a well known hack - or am I not reading the best reference guides. Can anyone point me to a good reference book where this sort of thing might be documented?

Thanks.
Dave

[sweh]

Character 22 is "MODE"; it would be followed by another character to indicate the mode number.

e.g.. sending 22,7 would change to MODE 7; 22,3 would change to MODE 3. (it's not quite the same as the MODE command 'cos BASIC would set up variables like HIMEM on a mode change, sending the ascii sequence doesn't do that.)

In BASIC you can see this with the VDU command; e.g. VDU 22,7 or VDU 22,3.

There is an excellent PDF of the User Guide at https://www.stardot.org.uk/forums/viewtopic.php?t=14024

Page number 378 lists what VDU codes do

[wemb]

...sending &16 to osasci/ &FFE3. This, apparently, clears the screen.

Ah... I see - now - it's not - its changing the screen mode. How do you choose which mode it's going to go to when you call this??

Thanks

[wemb]

Ah - should have read more before posting - I see who it works. You keep loading A with the arguments to the VDU command and carry on called osasci or oswrch. Which is kinda weird if all you're expecting is it to output ASCII characters but very neat nontheless.

Thanks - will try and digest the Advanced User Guide now.
Dave

[sweh]

Yeah, in assembler you might do

Code: Select all

LDA #22
JSR OSWRCH
LDA #7
JSR OSWRCH

Note I used OSWRCH (&FFEE) here; OSASCI is almost the same, but if you send a 0D then it will send an 0A first.

Code: Select all

.OSASCI
  CMP #&0D
  BNE OSWRCH
.OSNEWL
  LDA #&0A
  JSR OSWRCH
  LDA #&0D
.OSWRCH
  JMP (&020E)

When sending VDU control sequences you normally want OSWRCH; only if you want CR to become LF CR would you use OSASCI.

[Coeus]

See a related discussion going on at: viewtopic.php?p=415537#p415537

Ah - should have read more before posting - I see who it works. You keep loading A with the arguments to the VDU command and carry on called osasci or oswrch. Which is kinda weird if all you're expecting is it to output ASCII characters but very neat nontheless.

BASIC generally hides this stuff from you in that there are command words for doing things like moving the cursor, changing the colour or changing the screen mode and, in many modern programming environments, there are functions/procedures to call to move the cursor, draw lines etc. so that tends to be how we think and it is a way of implementing these things that works well when the program and the display are in the same computer.

That wasn't always the case, though. Early computers separated the actual computing from display, first with very limited devices like the teletype, then with CRT-based terminals with cursor addressing and maybe colour etc. With that separation, the program running on the computer controls the terminal by sending codes as well as the actual characters. The official ASCII meaning for the control codes below &20 (space) is only sufficient for the functions of a teletype or similar so just about every kind of more advanced terminal had a way of extending those for the more advanced functions.

In the case of the BBC micro, there is still that separation between the running program and the VDU drivers in that the VDU driver is controlled by sending codes to it with the same call, OSWRCH or OSASCI, as is used to send the actual characters. Apart from being one way to define the API to the VDU drivers this has the advanage that program output could be spooled to disc (*SPOOL command) or transmitted over a serial line and then replayed or displayed remotely.

The BBC VDU drivers have their own particular extensions to ASCII and this generally works by re purposing the lesser used ASCII control codes rather than, for example stacking all the functions behind one code (like ESC). There has been an evolution here - you may be familiar with the ANSI standard for controlling a terminal but this was a later and rather more complex encoding. Simpler ones, as used by the VDU drivers, were more common at the start.

[joachim]

Another consequence of the way this is implemented in BASIC is that if you send an incomplete VDU sequence, you can get unexpected behaviour from a subsequent BASIC command that tries to use the VDU drivers. For example

Code: Select all

MODE1:VDU22:MOVE18760,2573

will change to MODE1 and print "HI" on the screen.

(The initial MODE change is to lower HIMEM. If you omit it and start in MODE7 it doesn't work, and I don't really understand what is happening but presumably it's to do with the BASIC stack getting corrupted in the VDU22 mode change.)