Fast graphics AND MOS compatible?

Discuss all aspects of programming here. From 8-bit through to modern architectures.
jregel
Posts: 61
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire

Fast graphics AND MOS compatible?

Postby jregel » Tue Nov 29, 2016 11:26 am

Hi

I've been playing around on the Master recently with the Sprite ROM and want to display a tilemap consisting of an 11x11 grid, where each tile is 16x16 pixels in mode 1. The plan is for it to look similar to the graphics in Ultima IV/V.

I originally prototyped the idea in BASIC using a pair of FOR loops to plot the sprite tiles and the result was predictably slow. So I thought I'd try and re-implement it in the BASIC assembler, using the GXR/Sprite ROM VDU extensions for selecting and plotting the tiles. Now, this was my first attempt (following some tutorials and with the Creative Assembly book besides me), but the result was still slow. I could see the individual sprites being drawn.

Now I know that it's possible to get much faster graphics drawn to the screen, so I'd value some guidance as to where the performance problem is.

Are the MOS routines - even with the Sprite ROM - simply too slow to be useful?
Do I need to draw direct to screen memory? If so, is it possible to write screen drawing code that is fast and also MOS compatible? (I'd like to be MOS compatible if possible)
Is my code simply horrendous and inefficient? (please remember, this is the first assembly I've ever written!)

Thanks for any pointers!

Code: Select all

10 DIM code 100
   20 oswrch=&FFEE
   30 FOR pass=0 TO 3 STEP 3
   40 P%=code
   50 [ OPT pass
   60 .selectsprite
   70    LDA #23
   80    JSR oswrch
   90    LDA #27
  100    JSR oswrch
  110    LDA #0
  120    JSR oswrch
  130    LDA #1
  140    JSR oswrch
  150    LDA #0
  160    JSR oswrch
  170    LDA #0
  180    JSR oswrch
  190    LDA #0
  200    JSR oswrch
  210    LDA #0
  220    JSR oswrch
  230    LDA #0
  240    JSR oswrch
  250    LDA #0
  260    JSR oswrch
  270    RTS
  280 .displaysprite
  285    LDX #200
  290    .loop
  300    LDA #25
  310    JSR oswrch
  320    LDA #237
  330    JSR oswrch
  340    TXA
  350    JSR oswrch
  360    LDA #0
  370    JSR oswrch
  380    LDA #0
  390    JSR oswrch
  400    TXA
  410    JSR oswrch
  411    DEX
  412    BNE loop
  420    RTS
  430 ]
  440 NEXT pass
  450 CALL selectsprite
  460 CALL displaysprite
  470 END
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA

User avatar
tricky
Posts: 1817
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Fast graphics AND MOS compatible?

Postby tricky » Tue Nov 29, 2016 1:15 pm

I haven't looked at the SPRITE ROM since the 80's, so what I am about to say may not apply.
For doing something like drawing tiles, a custom routine should vastly out perform a general purpose masked sprite routine.
All beebs (B..Compact) can have their screen layouts the same, so directly addressing them on the beeb (not co-pro) is fine (if a little "illegal").
For drawing things fast on the beeb, you need 1 copy per horizontal pixel offset within a byte (4 pixels in mode 1) and a slower routine to draw at any vertical offset.
If you can live with character movement of the tiles, that would be easiest, but 4 pixel horizontal and vertical would be the next best option.
For "full" speed on the beeb, you need to draw all the tiles of a certain kind in one go, or all tiles at once sorted by tile. This is how the mario scrolling demo is so fast on the beeb.
The idea is load accumulator with a byte of a tile and then store it in all of the places it needs to go.

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Fast graphics AND MOS compatible?

Postby jgharston » Tue Nov 29, 2016 2:40 pm

OSWRCH preserves all registers, so you can do:
150 LDA #0
160 JSR oswrch
180 JSR oswrch
200 JSR oswrch
220 JSR oswrch
240 JSR oswrch
260 JSR oswrch

Other than that all your loops are as unrolled as they can be, there's little that can be done to make that code faster. It's running as fast as the MOS call it is calling.

Code: Select all

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

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Fast graphics AND MOS compatible?

Postby jgharston » Tue Nov 29, 2016 3:30 pm

If you're writing purely in machine code, then as long as you ensure your load/exec addresses are &FFFFxxxx and select a non-shadow screen mode (ie <128) the screen bitmap is directly available across all machines.

In case the user has SHADOW configured, start off by turning SHADOW off, viz:
LDA #&72:LDX #1:JSR OSBYTE :\ Ensure MODEs <128 are non-shadow
LDA #22:JSR OSWRCH
LDA #mode:JSR OSWRCH

Code: Select all

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

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am

Re: Fast graphics AND MOS compatible?

Postby poink » Tue Nov 29, 2016 4:09 pm

jgharston wrote:OSWRCH preserves all registers, so you can do:

I'd noticed that. It does make me wonder; is there a known list of scenarios where they're preserved/corrupted (like the later PRMs provide) or is it just a case of suck it and see? (And/or reading a disassembly.) Or do all MOS calls preserve?

User avatar
lurkio
Posts: 1151
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Fast graphics AND MOS compatible?

Postby lurkio » Tue Nov 29, 2016 4:46 pm

poink wrote:
jgharston wrote:OSWRCH preserves all registers, so you can do:

I'd noticed that. It does make me wonder; is there a known list of scenarios where they're preserved/corrupted (like the later PRMs provide) or is it just a case of suck it and see? (And/or reading a disassembly.) Or do all MOS calls preserve?

From the Advanced User Guide:

    image.png
    Extract from the Advanced User Guide to the BBC Micro
:idea:

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Fast graphics AND MOS compatible?

Postby jgharston » Tue Nov 29, 2016 8:53 pm

poink wrote:
jgharston wrote:OSWRCH preserves all registers, so you can do:

I'd noticed that. It does make me wonder; is there a known list of scenarios where they're preserved/corrupted (like the later PRMs provide) or is it just a case of suck it and see? (And/or reading a disassembly.) Or do all MOS calls preserve?

In general, all MOS API calls preserve all registers that are not used to return data in. The flags may or may not be preserved, in particular, the Carry flag only has a valid value in it if the call specifies that the Carry flag returns a specific value.

Code: Select all

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

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am

Re: Fast graphics AND MOS compatible?

Postby poink » Wed Nov 30, 2016 5:10 am

Thanks :D I own the AUG, so I perhaps should have found the bit where it tells me this, but I've doubtless missed it by reading only the bits I needed to get something working, rather than the whole guide in it's entirety #-o.

I think my code tends to assume that (although, it's usually just doing direct screen writes anyway), but I've occasionally wondered if there could be a weird edge case that would means registers won't be preserved. Looks like it's safe...or at least it won't just be my software that would break.

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

Re: Fast graphics AND MOS compatible?

Postby jregel » Fri Dec 02, 2016 10:12 pm

Thanks for all the feedback and comments.

A few more newbie questions:

What are the side effects of having code write directly to the screen memory addresses? Does this preclude the use of VDU functions (e.g., text and graphics windows, displaying text via VDU etc.?).

How straightforward is it to write directly to shadow memory? I'm expecting to need to use this as main memory will be used for other purposes.

Still getting my head around assembly, but it's good fun so far :-)
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA

User avatar
jms2
Posts: 1804
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Fast graphics AND MOS compatible?

Postby jms2 » Fri Dec 02, 2016 10:32 pm

Writing directly to screen memory doesn't affect your ability to use the MOS plotting functions at all.

To write to shadow memory, you use the same addresses but prior to writing you will need to set the shadow/normal latch. There is a 'legal' OS way to do this but also a 'non-legal' method involving poking a memory location. The latter version is faster but would create incompatibilities between different machines.

Not ever having tried to write a program to access shadow memory, I must confess I don't know what either of these commands are, but looking in the Master Reference manual should reveal all.

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Fast graphics AND MOS compatible?

Postby jgharston » Fri Dec 02, 2016 11:32 pm

Paging in shadow memory compatibly across platforms is a bit fiddly, but consistant. From the Wiki:

Code: Select all

 \ Screen selection routines
 \ =========================
 \ On entry, A=0 - select main memory
 \           A=1 - select video memory
 \ On exit,  all registers corrupted
 \
 .vramSelect
 PHA:TAX                  :\ A=0 main RAM, A=1 video RAM
 LDA #108:JSR OSBYTE      :\ Attempt to select Master/Integra-B video RAM
 PLA:INX:BNE vramOk       :\ X<>255, successful
 EOR #1:TAX               :\ A=1 main RAM, A=0 video RAM
 LDA #111:JMP OSBYTE      :\ Attempt to select Aries/Watford video RAM
 .vramOk
 RTS

Code: Select all

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


Return to “programming”

Who is online

Users browsing this forum: No registered users and 1 guest