Weeknight 'Virtual' Dev session #5, Thursday 22nd October 2020, 7pm - 10pm

[markdryan]

Mark asked about the Beeb816 speed up for the Raytrace program running on PiTubeDirect's native Arm copro.

viewtopic.php?f=2&t=19280&start=30#p272781

On my BBC B with Pi3A+ I got 13.8s

Enabling Beeb816 @ 14MHz to accelerate the host, that came down to 2.8s for about a 5x speed up.

R

If you get the chance, could you possibly try the attached binary on the PiTubeDirect's native Arm copro with the Beeb816? It's compiled to run at 0000F000, so I execute it as follows

Code: Select all

*LOAD rayvfp 0000F000
*GO 0000F000

Escape handling is currently very broken in this program so don't hit the Escape key while it's running!

On my PiZero, the binary still executes in about 14 secs, but in this version, the maths only take 0.11 seconds, as opposed to 2.4 seconds for the original BASIC version.

[Revaldinho]

If you get the chance, could you possibly try the attached binary on the PiTubeDirect's native Arm copro with the Beeb816? It's compiled to run at 0000F000, so I execute it as follows

Code: Select all

*LOAD rayvfp 0000F000
*GO 0000F000

On my PiZero, the binary still executes in about 14 secs, but in this version, the maths only take 0.11 seconds, as opposed to 2.4 seconds for the original BASIC version.

Hi Mark

Just ran this now on the latest Beeb816 board and build - see the screen shots.

I also get a bit under 14s for the program running with Beeb816 locked to the motherboard clock.

Looks like 5.4x speedup when running Beeb816 at 14.3Mhz, and 6x if overclocking to 17.2MHz.

This is on a BBC B with a Pi3A+ running the new Gecko RC1 version of PiTubeDirect.

Rich

[markdryan]

Looks like 5.4x speedup when running Beeb816 at 14.3Mhz, and 6x if overclocking to 17.2MHz.

So it looks like the compiled version is slightly faster than the interpreted BASIC version (IIRC this took 2.8 seconds at 14Mhz) but not massively so. I was secretly hoping it would be fast enough to animate, but I guess not. I may take another look to see whether I can speed up the drawing code further. I could try eliminating most of the GCOLs, for instance, which should save another 20%. Anyway, thanks for checking.

[Edit]

I wonder whether setting the background colour to blue, clearing the screen and then not drawing any blue lines would help.

[BigEd]

(Maybe if a line is only one or two pixels it will be quicker to draw it as a point? Not sure if this makes sense in context. Maybe there's a case to be made for a raytracing/basic/compiler thread?)

[markdryan]

(Maybe if a line is only one or two pixels it will be quicker to draw it as a point? Not sure if this makes sense in context. Maybe there's a case to be made for a raytracing/basic/compiler thread?)

Agreed. This information is currently scattered amongst a number of different threads. I'll start a new thread that ties everything together.

[markdryan]

(Maybe if a line is only one or two pixels it will be quicker to draw it as a point? Not sure if this makes sense in context. Maybe there's a case to be made for a raytracing/basic/compiler thread?)

I've created a new thread, summarising what's been tried so far.

viewtopic.php?f=29&t=21358

[Arcadian]

RobC's talk about how to program the VideoNuLA add-on for the BBC Micro/Master is finally online!



Other links:

Stardot ordering thread for VideoNuLA:
viewtopic.php?f=8&t=13632

Rob's VideoNuLA talk from the RISC OS London 2017 Show:
https://www.youtube.com/watch?v=4DaVrNS3034

Various VideoNuLA demonstration videos on Youtube:
https://www.youtube.com/user/CRob1974/s ... =videonula

[jregel]

RobC's talk about how to program the VideoNuLA add-on for the BBC Micro/Master is finally online!

Really enjoyed watching this video this evening. One comment that RobC made was:

"At which point the CPLD ... was completely full. Or so I thought. I'll come back to that".

Unless I missed it, I don't think RobC did come back to it. I'm intrigued... more space found in the CPLD?