Date : Sun, 13 Jun 2004 12:35:58 +0000
From : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Econet speed
On Sun, 2004-06-13 at 10:54, Philip Blundell wrote:
> On Sun, 2004-06-13 at 11:23, Jules Richardson wrote:
> > Any idea what sort of data rate I can expect over a short Econet
> > network? That's another thing that'll have a bearing on how I go about
> > this picture wall thingy.
>
> About 10-20KB/s, I think, if you're using model Bs. Later machines
> could go faster.
Hmm, that does have big display implications then. Is that speed using
the low-level Econet routines, or higher level code?
I expect I won't need any high level processing other than a bit of byte
copying at each BBC on the network (i.e. there's no setting up of FDC,
calling other OS routines etc.). All the BBC really needs to do is
receive data into a memory buffer flat-out and acknowledge it.
I am aiming for a large image display wall of course, not realtime video
:-)
Say I have a 4x4 array of BBC's & Cub screens all in Mode 2. That's 20KB
of video data per station - or rather 10KB if I'm assuming a double line
height. But say I scratch the whole "buffer everything before display"
idea, and incrementally merge the 'new' display on each station with any
current image... ten updates means transferring 10% of the final image
to each BBC in the array on each cycle, which equates to 1KB per cycle.
If I can maintain a 16KB/s transfer rate, that's 1 second per update
cycle to all screens in the wall, and ten seconds for an entire image
display.
All theoretical of course, but that could work as the effect of an old
picture merging into a new one over ten seconds could actually look
OK... I think...
A 4x4 array of screens gives me a 640x512 image (assuming 2 scanlines on
each BBC to one real line of pixel data) which is actually pretty good.
There *may* even be scope to fudge the colours a little - people are
going to be looking at this from at least a few metres away, and I'm
planning ditching 50% of the vertical resolution of the BBC by
duplicating alternate scanlines. But, I have 4 bits per pixel to play
with, yielding 16 possible colours - and I'm only going to be using the
8 solid ones. So there's 8 unused colours there... I wonder if say a red
pixel in a 'live' scanline above say a blue one at the corresponding
point in the 'dead' one will look like a purple pixel at x metres away
from the screen... that's an experiment for a later date though :)
cheers
Jules