BBC Changing Coordinate system from 0-1024,0-1280

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Wed Mar 21, 2018 3:23 pm

Just a quickie, i'm porting a basic program and as you know the beeb has a system o 1280x1024.
My question is can it be changed and still interpretted correctly?, Yes I could add scale factors, but there are LOTS to change,
just changing the coords would be much easier. I thought VDU 29 might help, but just seems to offset the origin?

Is it possible?
So many projects, so little time...

joachim
Posts: 138
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by joachim » Wed Mar 21, 2018 3:32 pm

You could intercept OSWRCH, and rescale the coordinates any time you see VDU 25 (or 24 or 29, if you care about those). I don't think there's a simpler way.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by crj » Wed Mar 21, 2018 7:02 pm

Um.

What are you porting from?

If it's not using the Acorn 1280x1024 co-ordinate system, presumably it's also not using the Acorn MOVE/DRAW/PLOT commands, so you're going to have to do a certain amount of translation anyway.

Is performance absolutely critical? If not, you could just define procedures which implement the graphics primitives your program expects, and the co-ordinate system it expects, and map the other system's graphics commands into procedure calls.

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Wed Mar 21, 2018 8:46 pm

crj wrote:Um.

What are you porting from?

If it's not using the Acorn 1280x1024 co-ordinate system, presumably it's also not using the Acorn MOVE/DRAW/PLOT commands, so you're going to have to do a certain amount of translation anyway.

Is performance absolutely critical? If not, you could just define procedures which implement the graphics primitives your program expects, and the co-ordinate system it expects, and map the other system's graphics commands into procedure calls.
Thanks that's actually what I'd gone with, but wondered if there had been a quicker way of changing the system. Performace not critial as it's turn based and I guess I can optmise the freqently called stuff.
So many projects, so little time...

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Tue Jul 03, 2018 2:25 pm

Hi,

I'm back looking at this a bit and with the following code the translation works perfectly.

Code: Select all

 8300DEF PROCLINE(MX%,MY%,DX%,DY%)
 8310MOVE MX%*4.5,1023-(MY%*5.1)
 8320DRAW DX%*4.5,1023-(DY%*5.1)
 8330ENDPROC
 
 8400DEF PROCDRAW(DX%,DY%)
 8420DRAW DX%*4.5,1023-(DY%*5.1)
 8430ENDPROC
Thought inevitable it has slowed things down some what.

Wondering if anyone had any optimisation ideas?

Thanks
Stew
So many projects, so little time...

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

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by jgharston » Tue Jul 03, 2018 4:59 pm

sbadger wrote:
Tue Jul 03, 2018 2:25 pm

Code: Select all

8310MOVE MX%*4.5,1023-(MY%*5.1)
That seems to be a wierd coordinate size you're converting. The source appears to be 285x-200. Using integer arithmetic would speed it up:
MX%*4+MX%DIV2, (MY%*5+MY%DIV8)EOR1023

A more normal "foreign" screen size is 256x200, which is quickly scaled with:
MX%*5, MY%*5+MY%DIV8

Code: Select all

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

User avatar
Rich Talbot-Watkins
Posts: 1337
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by Rich Talbot-Watkins » Tue Jul 03, 2018 7:15 pm

Apple ][ is 280x200 I believe (each character block is 7 pixels across, bizarrely). So it may well have come from Applesoft BASIC originally.

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Tue Jul 03, 2018 7:19 pm

Thanks Jonathan i'll try that out.
It's from an Apple II system that I understand is 280×192 with a BASIC coordinate system to match, but 0,0 being top left.
Your assertion of 285x200 pleases me!, because I did it by eye rather than the actual Apple resolution (the pixels dont feel the same shape!). Pleased because it's pretty darn close! :D
So many projects, so little time...

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Tue Jul 03, 2018 7:20 pm

Rich Talbot-Watkins wrote:
Tue Jul 03, 2018 7:15 pm
Apple ][ is 280x200 I believe (each character block is 7 pixels across, bizarrely). So it may well have come from Applesoft BASIC originally.
yeah!, cross post - yes it's apple 2 basic
So many projects, so little time...

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Tue Jul 03, 2018 7:28 pm

A quote from wiki
The Apple II's Hi-Res mode was peculiar even by the standards of the day
:D
So many projects, so little time...

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

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by jgharston » Wed Jul 04, 2018 1:44 am

sbadger wrote:
Tue Jul 03, 2018 7:19 pm
It's from an Apple II system that I understand is 280×192 with a BASIC coordinate system to match, but 0,0 being top left.
Quickly scaling Y from 192 to -1024 can be done with (MY%*5+MY%DIV3)EOR1023.

Scaling X with MX%*4+MX%DIV2 goes from 280 to 1260, leaving 20 logical pixels/4 physical pixels unused at the right. If you want to scale to use those pixels with a trade off for speed, the fastest is probably MX%*4+MX%DIV2+MX%DIV14. If you were doing it in machine code you'd be best using MX%*4+MX%DIV2+MX%DIV16 to keep everything to logical shifts, leaving half an unused pixel at the righthand edge.

Code: Select all

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

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

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by jgharston » Wed Jul 04, 2018 2:02 am

A quick bit of testing gives these speeds on 6502 BASIC looping 1000 times:

Code: Select all

                             BASIC IV  BASIC II
NX%=MX%*4+MX%DIV2          -> 255cs     282cs
NX%=MX%*4+MX%DIV2+MX%DIV14 -> 298cs     440cs
NX%=MX%*4.57               -> 283cs     423cs
SX=4.57, NX%=MX%*SX        -> 180cs     309cs  (SX set outside the loop)
So, the fastest in BASIC IV is to store the scaling factor in a variable and multiply by it directly, the fastest in BASIC II is lose the four pixels at the right, second fastest use a variable as in BASIC IV. This is one of the things that demonstrates the more efficient arithmetic coding in BASIC IV due to being coded for the 65C02.
Last edited by jgharston on Wed Jul 04, 2018 2:03 am, edited 1 time in total.

Code: Select all

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

User avatar
sbadger
Posts: 335
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: BBC Changing Coordinate system from 0-1024,0-1280

Post by sbadger » Wed Jul 04, 2018 7:03 am

jgharston wrote:
Wed Jul 04, 2018 2:02 am
A quick bit of testing gives these speeds on 6502 BASIC looping 1000 times:

Code: Select all

                             BASIC IV  BASIC II
NX%=MX%*4+MX%DIV2          -> 255cs     282cs
NX%=MX%*4+MX%DIV2+MX%DIV14 -> 298cs     440cs
NX%=MX%*4.57               -> 283cs     423cs
SX=4.57, NX%=MX%*SX        -> 180cs     309cs  (SX set outside the loop)
So, the fastest in BASIC IV is to store the scaling factor in a variable and multiply by it directly, the fastest in BASIC II is lose the four pixels at the right, second fastest use a variable as in BASIC IV. This is one of the things that demonstrates the more efficient arithmetic coding in BASIC IV due to being coded for the 65C02.
Many thanks. Due to the size of the BASIC code presently I can only get it to fit on a Master anyway, so will go with the direct scale factor for X.
So many projects, so little time...

Post Reply