BBC Micro co-processor graphics compression

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
User avatar
dudleysoft71
Posts: 143
Joined: Tue May 26, 2020 6:56 pm
Contact:

BBC Micro co-processor graphics compression

Post by dudleysoft71 »

I've been working on getting a real-time raytracing demo up and running using the PiTubeDirect in Native Pi mode, I have been using it along with my beebScreen code which is designed to transfer graphics from the pi co-processor (which it handles very easily) via the tube to the host which struggles because of the size of data being sent over the tube.

I've hosted my code here for anyone who's interested in taking a look.

There has been a bit of a discussion in the latest Virtual ABug developers meeting chat, but this is probably a better place for it.

Since that started I've already made a few optimisations to the code, and reduced the size of the host assembler code.

There are really two considerations for the data, 1 is the amount of data sent across the tube, the second is how quickly the host can deal with it, the second is far more important, for example I've changed long runs of unchanged data to send a new start address, which uses 3 bytes for any value >127 skipped, this is an extra byte over the tube when skipping 128-254 bytes, however the code is still quicker since it doesn't have to loop twice around the instruction decoder and 16bit addition loop.
dp11
Posts: 1234
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: BBC Micro co-processor graphics compression

Post by dp11 »

Given that on host side basic can't be running then I think you have have access to ZP page 0x00 to 0x8F to play with.
User avatar
dudleysoft71
Posts: 143
Joined: Tue May 26, 2020 6:56 pm
Contact:

Re: BBC Micro co-processor graphics compression

Post by dudleysoft71 »

I'm not sure if it's just under BeebEm, but I noticed that the tube host was executing code in zero page when I was trying to debug my audio code.

I remember because I thought it was strange that code was jumping to zero page, I thought at first there was a bug in my interrupt handler.

I guess we'd need someone more familiar with the tube host code to confirm what zero page is safe to use.

Also I'm not sure exactly how much it would save from a code execution standpoint, it's only really the store on address change, and the address increment, neither of which are in tight loops so aren't called that often. A better saving would be to change the parasite code to ensure change blocks don't overflow page boundaries, except where the block overflow would cause less lost cycles than starting a new block would save.
User avatar
jgharston
Posts: 4262
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: BBC Micro co-processor graphics compression

Post by jgharston »

dudleysoft71 wrote:
Thu Jan 14, 2021 1:17 pm
I'm not sure if it's just under BeebEm, but I noticed that the tube host was executing code in zero page when I was trying to debug my audio code.

I remember because I thought it was strange that code was jumping to zero page, I thought at first there was a bug in my interrupt handler.
Yes, when the Tube Host is running, /it/ is the current language, so /it/ owns &00-&8F.

No known Tube Host code uses &70-&8F, so just as Basic assigns that part of its language workspace to code running in its environment, I think we could declare that the Tube Host shall have assigned &70-&8F to code running in the Tube Host environment.

There's precedence for this as the Z80 Client's OSWORD &FF code uses &70-&76.

Code: Select all

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

Return to “programming”