VRAM access via tube

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
6502
Posts: 20
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

VRAM access via tube

Post by 6502 » Sat Nov 10, 2018 4:01 pm

Hi ya,

I'm just a bit confused how it's possible to write to the video ram of the BBC Micro while a second processor is attached.
Say I was in mode 2 for example and wanted to write to address &3000 to put 2 pixels on the screen.

LDA #&FF
STA &3000

If I try this I'm writing to the second processor memory which of course is not the vram.

Any help with this?
Last edited by 6502 on Sat Nov 10, 2018 4:02 pm, edited 1 time in total.

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

Re: VRAM access via tube

Post by BigEd » Sat Nov 10, 2018 4:51 pm

I'll try... I think there are several answers

- You can write host memory, one byte at a time, using an OSWORD call. See
http://beebwiki.mdfs.net/OSWORD_&06

- You can of course use VDU calls with OSWRCH to cause changes on the screen - plotting points, printing user-defined characters

- You can install your own helper routine in the host so you can send bigger changes more efficiently. See the notes about USERV in the above BeebWiki page.

It's quite challenging to get the sort of realtime interactivity that you'd want with a game. So for example Elite's approach is (probably)

- You install some code in the host to update the screen locally and send high-level updates (object locations, or velocities) over a USERV kind of mechanism

- Or instead of USERV, extend or replace the usual VDU handler and send bytes with OSWRCH, or send bytes by directly writing to the Tube registers, bypassing the local OS, or both OSes.

Hope this helps...

6502
Posts: 20
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: VRAM access via tube

Post by 6502 » Sun Nov 11, 2018 8:29 am

OK thank you for your reply.
Just got a second processor working on a Raspberry Pi and was messing about with it. Thought the vram memory could be accessed with something like &FFFF3000, but obviously it's a little more complicated than that.

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

Re: VRAM access via tube

Post by jms2 » Sun Nov 11, 2018 8:42 am

That works for loading a file, where you specify the load address to OS (or use the load address already stored on disc, assuming it is pointing to the host ram, which I think it does by default).

It doesn't work in your own machine code routines because you can only specify 16-bit addresses (one high byte and one low byte).

So in summary, everything has to go via the OS, or you have to write your own replacement for the OS routines that will work with the hardware tube registers directly.

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

Re: VRAM access via tube

Post by BigEd » Sun Nov 11, 2018 9:30 am

jms2 wrote:
Sun Nov 11, 2018 8:42 am
So in summary, everything has to go via the OS, or you have to write your own replacement for the OS routines that will work with the hardware tube registers directly.
Just to tweak that statement, there's also an intermediate between those two, where you still use the OS but you extend its facilities, by hooking a vector on the host side.

Unfortunately, this is nowhere near as simple as

Code: Select all

LDA #&FF
STA &3000
but once you've set up a control block somewhere, the OS method comes down to something like this (untested!):

Code: Select all

LDA #&00  / low byte of screen address
STA &1F00
LDA #&30  / high byte
STA &1F01
LDA #&00  / zero - or FE
STA &1F02
LDA #&00  / zero - or FF
STA &1F03
LDA #&FF  / byte to write
STA &F104
LDX #0    / low byte of control block address
LDY #&1F  / high byte
LDA #6    / OSWORD 6 is a memory write
JSR &FFF1 / call OSWORD
Some of that setup only has to be done once.
Last edited by BigEd on Sun Nov 11, 2018 9:31 am, edited 2 times in total.

RobC
Posts: 2317
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: VRAM access via tube

Post by RobC » Sun Nov 11, 2018 9:48 am

I use a ROM that hooks into WRCH for my Spectrum and (WiP) Amstrad CPC emulators. Once loaded on the host, it allows me to send blocks of pixel data from the parasite (Pi co-pro in 1GHz native mode) to the screen (or anywhere else in the host's memory) using control codes to initiate the transfers (e.g. 0xFF, 0xFE etc). This means that printable characters can still be displayed by the OS routine.

I get the Pi to identify differences between the current frame and the previous one and just send the differences (unless the majority of a character row has changed, when it's quicker just to blat the whole row using an unrolled routine).

This is all based on the approach that BigEd and hoglet used in their Life co-pro demo.

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

Re: VRAM access via tube

Post by BigEd » Sun Nov 11, 2018 10:06 am

The VDU queue is a good way to move lots of data, in part because it has a deep FIFO.

What kind of bandwidth do you get Rob, in terms of useful bytes transferred per second?

RobC
Posts: 2317
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: VRAM access via tube

Post by RobC » Sun Nov 11, 2018 5:14 pm

BigEd wrote:
Sun Nov 11, 2018 10:06 am
The VDU queue is a good way to move lots of data, in part because it has a deep FIFO.
Exactly - I make sure that the Pi has a block of data ready to send and then I don't even bother checking that data is available on the host side.
BigEd wrote:
Sun Nov 11, 2018 10:06 am
What kind of bandwidth do you get Rob, in terms of useful bytes transferred per second?
I haven't measured it but it'll vary depending on the nature of the changes from frame to frame. When I've got some time, I'll put in some functionality to analyse what's going on.

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

Re: VRAM access via tube

Post by BigEd » Mon Nov 12, 2018 11:36 am

Cheers Rob - I think it could be quite interesting. No urgency, though!

Post Reply