Date   : Sat, 12 Jun 2004 20:17:59 +0100
From   : David Devenport <dave@...>
Subject: Re: network-aware scrolling message thingy

If I rememeber correctly it should be stupidly easy to do.

Asumming you have 5 linked for example, simply run the the program :
10 MODE 7
20 GOTO 20
on 4 of the machines (left most message machine -> penultimate machine 
on the right)


Then write a simple routine to scroll text on a mode 7 screen.
All you do is send econet POKE commands to 4 of the machines to fill 
their screen memory (1K of data), with the appropriate bits of the 
message, and then physically write to the local machines memory for 
final fifth part of the message (the right most screen)...

As an aside, during my time I school we wrote routines that PEEKED mode 
7 screens real time, and also (accidently *cough*) PEEKED the 
administrators machines' keyboard buffer too, allowing us to achieve 
supervisor status, then change the *PROT command (held on a hard disk on 
the server, for non master machines), so that PEEK was never blocked ... 
  Incidentally found by a bit of sneaky hacking, you could change your 
PROT flags by a simple poke command, also I am not sure, but I remember 
you could also elevate your superuser status with a poke too

Cheers

Dave


Jules Richardson wrote:
> On Fri, 2004-06-11 at 19:24, Sprow wrote:
> 
>>In article <1086979761.15873.456.camel@...>,
>>   Jules Richardson <julesrichardsonuk@...> wrote:
>>
>>>(Of course a 4x4 Cub 'video wall' hooked up to a camera to give large,
>>>grainy digitisations of museum visitors would be pretty neat too...)
>>
>>When I converted 18 Cubs to accept composite video and welded up a 6x3
>>monitor rack for them, using them as a video wall was definitely on the
>>cards.
>>
>>Then I graduated, ah, happy days,
> 
> 
> Ha ha!
> 
> Well the video wall's looking more realistic project all the time. Other
> people seem keen, plus I got a lead on another school full of unwanted
> BBCs and Cubs earlier, so a source of hardware may have been found.
> 
> I need to really sit down and think about architecture. One BBC per
> screen, linked by Econet, with *something* controlling them seems like
> the way to go (rather than having to build hardware for one BBC to
> control more than one display) - plus of course a rack full of BBC
> boards would look pretty nifty :-)
> 
> One approach would be for the controlling system to take an image, split
> it into chunks according to how many screens/BBC's are hooked up, send
> each chunk to an off-screen image on each BBC over Econet, and then tell
> each BBC on the network to display it's off-screen image at once. 
> 
> That method relies a) on Econet being fast enough to transfer the data
> in a reasonable amount of time, and b) for the BBC to have enough memory
> to buffer an entire local image off-screen in memory. Likely not a prob;
> my memory's a bit hazy on both transfer speeds of Econet and how much
> memory the various BBC video modes need.
> 
> I also need to ponder the controlling system configuration - one the one
> hand a later Acorn will have the CPU power to split up and image, and I
> probably have a spare digitiser board already. On the other hand, BBC
> hardware is highly hackable and I know nothing about programming later
> Acorn machines...
> 
> Lots to think about...
> 
> cheers
> 
> Jules
> 
> 
>