"Legally" writing to the screen

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
jregel
Posts: 210
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

"Legally" writing to the screen

Post by jregel » Thu May 28, 2020 4:36 pm

I’m possibly being really daft and missing the obvious here, but what are the ways to legally write to the screen on the BBC?

In BASIC, I can obviously use the various PLOT commands to draw lines, triangles etc., PRINT CHR$ to get user definable characters on screen, which in turn use the VDU driver, but what’s the “legal” way to draw a multi-coloured graphic to the screen?

I know that GXR provides the sprite capability to do this, but in the absence of GXR, is there a way to copy multi-coloured graphical bitmaps to the screen without directly poking the screen memory addresses?

Thanks
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

User avatar
davidb
Posts: 2817
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: "Legally" writing to the screen

Post by davidb » Thu May 28, 2020 5:09 pm

You can use VDU 5 to overlay different coloured characters at the same graphics position. However, that's very slow. On RISC OS, SWI calls like OS_SpriteOp can be used, but that's not very useful if you want to do that on the 8-bit systems. :(

Naomasa298
Posts: 384
Joined: Sat Feb 16, 2013 12:49 pm
Contact:

Re: "Legally" writing to the screen

Post by Naomasa298 » Thu May 28, 2020 7:20 pm

OSWORD &6?

User avatar
jgharston
Posts: 4039
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: "Legally" writing to the screen

Post by jgharston » Thu May 28, 2020 10:00 pm

The legal way to write to the screen is via OSWRCH.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
flibble
Posts: 776
Joined: Tue Sep 22, 2009 11:29 am
Contact:

Re: "Legally" writing to the screen

Post by flibble » Thu May 28, 2020 10:20 pm

OSWRSC, or is that a master/mos 3+ thing?

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: "Legally" writing to the screen

Post by kieranhj » Thu May 28, 2020 11:41 pm

If you want to do anything interesting, then the short answer is: no!

The long answer is that Acorn didn’t think / care about sprites, so you’re limited to standard PLOT calls I’m afraid.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

jregel
Posts: 210
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: "Legally" writing to the screen

Post by jregel » Sat May 30, 2020 12:03 pm

Thanks for all the suggestions.

Agree that VDU5 will be a bit slow for what I was looking for.

Although I mentioned sprites (and this is a use case I’m interested in), I was also thinking in terms of displaying pictures, whereby the source data is in the correct screen format and just needs a way to be copied to the screen memory. Given how complete MOS is (for its time), the lack of this functionality is really surprising.

So, reading up on the the other suggestions:

OSWRSC writes a byte to screen memory, so seems to be a suitable candidate (I’m on a Master, so can use this call), but it’s not compatible with second processors (not that this is essential at the moment, but something I’d possibly like to support in the future).

OSWRCH does work with second processors, but I’m not sure how you would use it to write a coloured bitmap? Any simple example or pseudo-code would be much appreciated!

OSWORD &6 sounds like it’ll do the job as a generic way to write to a memory address, and also supports second processors.

Is that a fair understanding of the different options?

How do those that program do it? Do you just bypass the MOS and write bytes directly to the screen address?

Thanks
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

Naomasa298
Posts: 384
Joined: Sat Feb 16, 2013 12:49 pm
Contact:

Re: "Legally" writing to the screen

Post by Naomasa298 » Sat May 30, 2020 12:21 pm

jregel wrote:
Sat May 30, 2020 12:03 pm
How do those that program do it? Do you just bypass the MOS and write bytes directly to the screen address?
I think that's pretty much what you have to do for speed. I shudder to think how slow calling OSWORD &6 for every byte would be when writing a MODE2 screen. Although if you're only writing data that's changed on a game screen, it might be acceptable.

Then again - Tube Elite?

User avatar
Richard Russell
Posts: 1578
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: "Legally" writing to the screen

Post by Richard Russell » Sat May 30, 2020 1:52 pm

jgharston wrote:
Thu May 28, 2020 10:00 pm
The legal way to write to the screen is via OSWRCH.
Indeed, but importantly you can put a sequence of graphics commands (which may include GCOL, PLOT etc.) in a single string variable and PRINT it; this can go some way to providing a sprite-like functionality. For example suppose you want to plot a cross consisting of a green horizontal and a red vertical:

Code: Select all

   10 MODE 2
   20 cross$ = CHR$18 + CHR$0 + CHR$2 : REM GCOL 2
   30 cross$ = cross$ + CHR$25 + CHR$0 + CHR$-50 + CHR$-1 + CHR$0 + CHR$0 : REM PLOT 0,-50,0
   40 cross$ = cross$ + CHR$25 + CHR$1 + CHR$100 + CHR$0 + CHR$0 + CHR$0 : REM PLOT 1,100,0
   50 cross$ = cross$ + CHR$18 + CHR$0 + CHR$1 : REM GGOL 1
   60 cross$ = cross$ + CHR$25 + CHR$0 + CHR$-50 + CHR$-1 + CHR$-50 + CHR$-1 : PLOT 0,-50,-50
   70 cross$ = cross$ + CHR$25 + CHR$1 + CHR$0 + CHR$0 + CHR$100 + CHR$0 : PLOT 1,0,100
   80 REPEAT
   90   MOVE RND(1200),RND(1000)
  100   PRINT cross$;
  110   d = INKEY(50)
  120 UNTIL FALSE
This technique can be extended to quite complex sprites, for example I use it to display this folder icon using a single PRINT:

foldericon.png
foldericon.png (1.18 KiB) Viewed 665 times

User avatar
Mince
Posts: 36
Joined: Thu Sep 05, 2019 11:25 pm
Location: Cambridge, UK
Contact:

Re: "Legally" writing to the screen

Post by Mince » Mon Jun 01, 2020 2:02 am

If you want to zap stuff up to the screen from a second processor, you can render it into a buffer on the parasite processor and then use the Tube transfer protocols (the calls through &406 on the host processor) to copy it into screen memory via something like a custom OSWORD routine. I don't think this would work where a lot of changing on the screen (best speed would be 1/5s for the whole screen) but might be OK for moving sprites in odd locations around: it significantly faster than using OSWORD &6 when you're moving blocks of data.

The calls would be a bit awkward as you need to work out how best to use the available transfer modes, especially given the layout of screen memory.

RobC
Posts: 2923
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: "Legally" writing to the screen

Post by RobC » Mon Jun 01, 2020 7:48 pm

Mince wrote:
Mon Jun 01, 2020 2:02 am
If you want to zap stuff up to the screen from a second processor, you can render it into a buffer on the parasite processor and then use the Tube transfer protocols (the calls through &406 on the host processor) to copy it into screen memory via something like a custom OSWORD routine. I don't think this would work where a lot of changing on the screen (best speed would be 1/5s for the whole screen) but might be OK for moving sprites in odd locations around: it significantly faster than using OSWORD &6 when you're moving blocks of data.
I've mentioned this on here before but, for my Pi co-pro emulators, I use a custom OSWRCH handler to plot rectangular blocks to the screen. The speed of the Pi and the depth of the VDU FIFO mean that the Pi can always keep ahead of the Beeb if you get the data lined up first. So there's no need to keep checking that there's data waiting on the Beeb side and this gives a decent speed improvement. The Pi keeps track of which bytes have changed since the previous frame and only pushes across areas that have need to be updated.

If you're only really interested in sprites/tiles of a limited variety of sizes, you could have a different VDU code and routine for each one. E.g. VDU &F1 could indicate that you're about to plot an 8x8 sprite, VDU &F2 for a 16 x 8 etc. Your custom handler would then read the screen offset and sprite data from the TUBE and copy it to the appropriate addresses in screen memory.

If you' are thinking of using a very fast co-pro (particularly the native Pi), it could manage any sprite masking and background/tile re-painting. I suspect you could write a pretty impressive game using these sort of techniques.

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: "Legally" writing to the screen

Post by kieranhj » Mon Jun 01, 2020 8:06 pm

RobC wrote:
Mon Jun 01, 2020 7:48 pm
If you're only really interested in sprites/tiles of a limited variety of sizes, you could have a different VDU code and routine for each one. E.g. VDU &F1 could indicate that you're about to plot an 8x8 sprite, VDU &F2 for a 16 x 8 etc. Your custom handler would then read the screen offset and sprite data from the TUBE and copy it to the appropriate addresses in screen memory.
Whilst this is a perfectly valid approach to having code on a parasite processor draw sprites over the TUBE, it's still not 'legally' writing to the screen as per the original query.

It would be helpful to understand why using a 'legal' method to write to the screen is important. The reasons I can think of are:
  • Portability between Acorn platforms, so same the program runs on Elk, Beeb, Master, Archimedes possibly even BBC BASIC for Windows?
  • Program is being written in BASIC and wishes to avoid machine code, for either the portability reason above or readability (use of PLOT / VDU codes).
  • Program is intended to take advantage of a faster co-processor on the other side of the TUBE.
Ultimately if you want anything approaching fast sprites on a Master then the only recourse is to write directly to screen memory. This needn't be a large amount of code, in either BASIC or assembler, and is certainly a much easier path than rolling TUBE routines. As an example, the excellent Planet Nubium games by Andrew Waite have the main logic written in BASIC but call out to machine code routines to plot sprites on screen.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

RobC
Posts: 2923
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: "Legally" writing to the screen

Post by RobC » Mon Jun 01, 2020 9:50 pm

kieranhj wrote:
Mon Jun 01, 2020 8:06 pm
RobC wrote:
Mon Jun 01, 2020 7:48 pm
If you're only really interested in sprites/tiles of a limited variety of sizes, you could have a different VDU code and routine for each one. E.g. VDU &F1 could indicate that you're about to plot an 8x8 sprite, VDU &F2 for a 16 x 8 etc. Your custom handler would then read the screen offset and sprite data from the TUBE and copy it to the appropriate addresses in screen memory.
Whilst this is a perfectly valid approach to having code on a parasite processor draw sprites over the TUBE, it's still not 'legally' writing to the screen as per the original query.
I didn't mean to imply that it was legal - I was only referring to the post that discussed plotting to the screen over the TUBE.

(Also, it may not be legal in the strictest sense but is only using OSWRCH sequences so could be thought of as "legal" from the 2P's point of view.)

jregel
Posts: 210
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: "Legally" writing to the screen

Post by jregel » Mon Jun 01, 2020 10:12 pm

kieranhj wrote:
Mon Jun 01, 2020 8:06 pm
It would be helpful to understand why using a 'legal' method to write to the screen is important. The reasons I can think of are:
  • Portability between Acorn platforms, so same the program runs on Elk, Beeb, Master, Archimedes possibly even BBC BASIC for Windows?
  • Program is being written in BASIC and wishes to avoid machine code, for either the portability reason above or readability (use of PLOT / VDU codes).
  • Program is intended to take advantage of a faster co-processor on the other side of the TUBE.
Ultimately if you want anything approaching fast sprites on a Master then the only recourse is to write directly to screen memory. This needn't be a large amount of code, in either BASIC or assembler, and is certainly a much easier path than rolling TUBE routines. As an example, the excellent Planet Nubium games by Andrew Waite have the main logic written in BASIC but call out to machine code routines to plot sprites on screen.
I asked the question because I'm writing a program that displays multi-coloured graphics/tiles/sprites to the screen and Acorn put such an emphasis on following the guidelines and doing things legally. One of the main arguments being that such well-written programs would work on a second processor.

On digging into it, it appears that although the MOS supports a number of high level primitives (lines, triangles, circles, ellipses etc.), it doesn't have a built-in capability to copy a coloured object in memory to the screen (OSWRSC appears to provide that functionality, but not in a way that is compatible with the second processor). That is, until you use the Sprite/GXR ROM which adds this feature through VDU23,27 (select a sprite) and VDU25,232 (plot a sprite).

On a Master, this actually seems like quite an attractive option. As previously discovered in a different thread, the Sprite ROM on the Master is 9K code leaving 7K for storing sprite graphics in Sideways RAM. This would allow for over 200 8x8 Mode 2 sprites to be stored and is compatible with the second processor and can be called from both assembly and BASIC. Sprites aren't limited to 8x8 though, and it appears they can be any size up to the 7K limit of free RAM in the sideways RAM bank. While I'm sure it's nowhere near as fast as directly writing bytes to the screen memory, it should be possible to get some good functionality out with relative ease.

It's an idea that Acorn seem to have followed through on into the Archimedes range, where the sprite format appears to be the "official" way to display multi-coloured bitmaps through the VDU driver.
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: "Legally" writing to the screen

Post by kieranhj » Tue Jun 02, 2020 11:25 am

jregel wrote:
Mon Jun 01, 2020 10:12 pm
I asked the question because I'm writing a program that displays multi-coloured graphics/tiles/sprites to the screen and Acorn put such an emphasis on following the guidelines and doing things legally. One of the main arguments being that such well-written programs would work on a second processor.

On digging into it, it appears that although the MOS supports a number of high level primitives (lines, triangles, circles, ellipses etc.), it doesn't have a built-in capability to copy a coloured object in memory to the screen (OSWRSC appears to provide that functionality, but not in a way that is compatible with the second processor). That is, until you use the Sprite/GXR ROM which adds this feature through VDU23,27 (select a sprite) and VDU25,232 (plot a sprite).
That all makes perfect sense and I'm glad you've found a solution that works for your needs. I've never really played around with the GXR ROM but it does seem to fill a big hole in the original MOS support for graphics. Acorn clearly didn't have games in mind when designing the machine (it was an educational computer for the BBC after all) despite setting up Acornsoft to create the first batch of software titles, particularly games!

EDIT: I suppose we'd observe in hindsight that the MOS + BASIC at 32K was already large in size compared with other machines of the era, which tended to have a more limited OS squeezed into 8-16K. Adding yet more support for graphics and sprites would have been nigh-on impossible without an additional ROM or SWRAM. 20K screen modes in a 32K machine are difficult enough!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
BigEd
Posts: 3197
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: "Legally" writing to the screen

Post by BigEd » Tue Jun 02, 2020 11:59 am

I very much like Richard's idea of vector art in a string. It might even be Mode agnostic to some extent. And it should work also with new VDU technologies like the pi on 1MHz bus.

User avatar
Richard Russell
Posts: 1578
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: "Legally" writing to the screen

Post by Richard Russell » Tue Jun 02, 2020 12:55 pm

BigEd wrote:
Tue Jun 02, 2020 11:59 am
I very much like Richard's idea of vector art in a string. It might even be Mode agnostic to some extent. And it should work also with new VDU technologies like the pi on 1MHz bus.
I started a new thread about it. As you say it's completely 'legal' and should even work on Matrix Brandy, BBC BASIC for Windows and BBC BASIC for SDL 2.0 to the extent that the minor graphical differences allow. The folder icon example I gave, along with a similar file icon, is what SDLIDE.bbc uses in its file selector, all in bog-standard BASIC code:

fileselector.png

dp11
Posts: 1158
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: "Legally" writing to the screen

Post by dp11 » Tue Jun 02, 2020 2:05 pm

BigEd wrote:
Tue Jun 02, 2020 11:59 am
I very much like Richard's idea of vector art in a string. It might even be Mode agnostic to some extent. And it should work also with new VDU technologies like the pi on 1MHz bus.
My lastest version supports vdu23 and vdu 5 as well as nula vdu 19

Post Reply

Return to “programming”