Tag Archives: BBC Micro

Learn to write games for the BBC Micro with Eben

Post Syndicated from Eben Upton original https://www.raspberrypi.org/blog/learn-to-write-games-for-the-bbc-micro-with-eben/

Long-time fans of the Raspberry Pi will know that we were inspired to make a programmable computer for kids by our own experiences with a machine called the BBC Micro, which many of us learned with in the 1980s.

This post is the first of what’s going to be an irregular series where I’ll walk you through building the sort of game we used to play when we were kids. You’ll need a copy of BeebEm (scroll down for a Linux port if you’re using a Pi – but this tutorial can be carried out on a PC or Mac as well as on an original BBC Micro if you have access to one).

I’m going to be presenting the next game in this series, tentatively titled Eben Goes Skiing, at the Centre for Computing History in Cambridge at 2pm this afternoon – head on down if you’d like to learn how to make scrolling ascii moguls.

Helicopter tutorial

We’re going to build a simple helicopter game in BBC BASIC. This will demonstrate a number of neat features, including user-defined characters, non-blocking keyboard input using INKEY, and positioning text and graphics using PRINT TAB.

Let’s start with user-defined characters. These provide us with an easy way to create a monochrome 8×8-pixel image by typing in 8 small numbers. As an example, let’s look at our helicopter sprite:

Each column pixel position in a row is “worth” a different power of 2, from 1 for the rightmost pixel up to 128 for the leftmost. To generate our 8 numbers, we process one row at a time, adding up the value for each occupied pixel position. We can now create custom character number 226 using the VDU 23 command. To display the character, we change to a graphics mode using the MODE command and display it using the PRINT command.

Type the following:

10MODE 2

70VDU 23,226,0,248,32,116,126,116,112,0

RUN

PRINT CHR$(226)

You should see the little helicopter on the screen just above your prompt. Let’s define some more characters for our game, with character numbers 224 through 229. These represent leftward and rightward flying birds, a rightward flying helicopter, the surface of the sea, and a landing pad.

Type the following:

50VDU 23,224,0,14,12,104,16,28,8,0

60VDU 23,225,0,112,48,22,8,56,16,0

80VDU 23,227,0,31,4,46,126,46,14,0

90VDU 23,228,0,102,255,255,255,255,255,255

100VDU 23,229,255,255,0,0,0,0,0,0

Trying running your program and using print to view the new characters!

Now we’re ready to use our sea and platform characters to build the game world. Mode 2 on the BBC Micro has 20 character positions across, and 32 down. We’ll draw 20 copies of the sea character in row 30 (remember, rows and columns are numbered from zero) using a FOR loop and the PRINT TAB command, and pick a random position for the platform using the RND() function.

Type the following:

110FOR I%=0 TO 19

120PRINT TAB(I%,30) CHR$(228);

130NEXT

140P%=RND(20)-1

150PRINT TAB(P%,30) CHR$(229);

RUN

You should see something like this:

Don’t worry about that cursor and prompt: they won’t show up in the finished game.

It’s time to add the helicopter. We’ll create variables X% and Y% to hold the position of the helicopter, and Z% to tell us if it last moved left or right. We’ll initialise X% to a random position, Y% to the top of the screen, and Z% to zero, meaning “left”. We can use PRINT TAB again to draw the helicopter (either character 226 or 227 depending on Z%) at its current position. The whole thing is wrapped up in a REPEAT loop, which keeps executing until the helicopter reaches the ground (in row 29).

Type the following:

160X%=RND(20)-1:Y%=0:Z%=0

180REPEAT

260PRINT TAB(X%,Y%) CHR$(226+Z%);

290UNTIL Y%=29

RUN

You’ll see the helicopter sitting at the top of the screen.

We’re almost there: let’s give our helicopter the ability to move left, right and down. On each trip round the loop, we move down one row, and use the INKEY() function to read the Z and X keys on the keyboard. If Z is pressed, and we’re not already at the left of the
screen, we move one column left. If X is pressed, and we’re not already at the right of the screen, we move one column right.

Type the following:

210IF INKEY(-98) AND X%>0 THEN X%=X%-1:Z%=0

220IF INKEY(-67) AND X%<19 THEN X%=X%+1:Z%=1

230Y%=Y%+1

RUN

You should see something like this:

The game is much, much too fast to control, and the helicopter leaves trails: not surprising, as we didn’t do anything to erase the previous frame. Let’s use PRINT TAB to place a “space” character over the previous position of the helicopter, and add an empty FOR loop to slow things down a bit.

Type the following:

190PRINT TAB (%,Y%)"";

280FOR I%=1 TO 200:NEXT

RUN

Much better! This is starting to feel like a real game. Let’s finish it off by:

  • Adding a bird that flies back and forth
  • Detecting whether you hit the pad or not
  • Getting rid of the annoying cursor using a “magic” VDU 23 command
  • Putting an outer loop in to let you play again

Type the following:

20REPEAT

30CLS

40VDU 23,1,0;0;0;0;

170A%=RND(18):B%=10:C%=RND(2)-1

200PRINT TAB(A%,B%) "";

240A%=A%+2*C%-1

250IF A%=0 OR A%=19 THEN C%=1-C%

270PRINT TAB(A%,B%) CHR$(224+C%);

300IF X%=P% PRINT TAB(6,15) "YOU WIN" ELSE PRINT TAB(6,15) "YOU
LOSE"

310PRINT TAB(4,16) "PRESS SPACE"

320REPEAT UNTIL INKEY(-99)

330UNTIL FALSE

RUN

And here it is in all its glory.

You might want to try adding some features to the game: collision with the bird, things to collect, vertical scrolling. The sky’s the limit!

I created a full version of the game, using graphics from our very own Sam Alder, for the Hackaday 1K challenge; you can find it here.

Appendix

Here’s the full source for the game in one block. If you get errors when you run your code, type:

MODE 0
LIST

And compare the output very carefully with what you see here.

10MODE 2
20REPEAT
30CLS
40VDU 23,1,0;0;0;0;
50VDU 23,224,0,14,12,104,16,28,8,0   
60VDU 23,225,0,112,48,22,8,56,16,0
70VDU 23,226,0,248,32,116,126,116,112,0
80VDU 23,227,0,31,4,46,126,46,14,0
90VDU 23,228,0,102,255,255,255,255,255,255
100VDU 23,229,255,255,0,0,0,0,0,0
110FOR I%=0 TO 19
120PRINT TAB(I%,30) CHR$(228);
130NEXT
140P%=RND(20)-1
150PRINT TAB(P%,30) CHR$(229);
160X%=RND(20)-1:Y%=0:Z%=0
170A%=RND(18):B%=10:C%=RND(2)-1
180REPEAT
190PRINT TAB(X%,Y%) " ";
200PRINT TAB(A%,B%) " ";  
210IF INKEY(-98) AND X%>0 THEN X%=X%-1:Z%=0  
220IF INKEY(-67) AND X%<19 THEN X%=X%+1:Z%=1
230Y%=Y%+1
240A%=A%+2*C%-1
250IF A%=0 OR A%=19 THEN C%=1-C%
260PRINT TAB(X%,Y%) CHR$(226+Z%);
270PRINT TAB(A%,B%) CHR$(224+C%);
280FOR I%=1 TO 200:NEXT
290UNTIL Y%=29
300IF X%=P% PRINT TAB(6,15) "YOU WIN" ELSE PRINT TAB(6,15) "YOU LOSE"
310PRINT TAB(4,16) "PRESS SPACE"
320REPEAT UNTIL INKEY(-99)
330UNTIL FALSE


The post Learn to write games for the BBC Micro with Eben appeared first on Raspberry Pi.

Why Raspberry Pi isn’t vulnerable to Spectre or Meltdown

Post Syndicated from Eben Upton original https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

Over the last couple of days, there has been a lot of discussion about a pair of security vulnerabilities nicknamed Spectre and Meltdown. These affect all modern Intel processors, and (in the case of Spectre) many AMD processors and ARM cores. Spectre allows an attacker to bypass software checks to read data from arbitrary locations in the current address space; Meltdown allows an attacker to read arbitrary data from the operating system kernel’s address space (which should normally be inaccessible to user programs).

Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use.

To help us understand why, here’s a little primer on some concepts in modern processor design. We’ll illustrate these concepts using simple programs in Python syntax like this one:

t = a+b
u = c+d
v = e+f
w = v+g
x = h+i
y = j+k

While the processor in your computer doesn’t execute Python directly, the statements here are simple enough that they roughly correspond to a single machine instruction. We’re going to gloss over some details (notably pipelining and register renaming) which are very important to processor designers, but which aren’t necessary to understand how Spectre and Meltdown work.

For a comprehensive description of processor design, and other aspects of modern computer architecture, you can’t do better than Hennessy and Patterson’s classic Computer Architecture: A Quantitative Approach.

What is a scalar processor?

The simplest sort of modern processor executes one instruction per cycle; we call this a scalar processor. Our example above will execute in six cycles on a scalar processor.

Examples of scalar processors include the Intel 486 and the ARM1176 core used in Raspberry Pi 1 and Raspberry Pi Zero.

What is a superscalar processor?

The obvious way to make a scalar processor (or indeed any processor) run faster is to increase its clock speed. However, we soon reach limits of how fast the logic gates inside the processor can be made to run; processor designers therefore quickly began to look for ways to do several things at once.

An in-order superscalar processor examines the incoming stream of instructions and tries execute more than one at once, in one of several “pipes”, subject to dependencies between the instructions. Dependencies are important: you might think that a two-way superscalar processor could just pair up (or dual-issue) the six instructions in our example like this:

t, u = a+b, c+d
v, w = e+f, v+g
x, y = h+i, j+k

But this doesn’t make sense: we have to compute v before we can compute w, so the third and fourth instructions can’t be executed at the same time. Our two-way superscalar processor won’t be able to find anything to pair with the third instruction, so our example will execute in four cycles:

t, u = a+b, c+d
v    = e+f                   # second pipe does nothing here
w, x = v+g, h+i
y    = j+k

Examples of superscalar processors include the Intel Pentium, and the ARM Cortex-A7 and Cortex-A53 cores used in Raspberry Pi 2 and Raspberry Pi 3 respectively. Raspberry Pi 3 has only a 33% higher clock speed than Raspberry Pi 2, but has roughly double the performance: the extra performance is partly a result of Cortex-A53’s ability to dual-issue a broader range of instructions than Cortex-A7.

What is an out-of-order processor?

Going back to our example, we can see that, although we have a dependency between v and w, we have other independent instructions later in the program that we could potentially have used to fill the empty pipe during the second cycle. An out-of-order superscalar processor has the ability to shuffle the order of incoming instructions (again subject to dependencies) in order to keep its pipelines busy.

An out-of-order processor might effectively swap the definitions of w and x in our example like this:

t = a+b
u = c+d
v = e+f
x = h+i
w = v+g
y = j+k

allowing it to execute in three cycles:

t, u = a+b, c+d
v, x = e+f, h+i
w, y = v+g, j+k

Examples of out-of-order processors include the Intel Pentium 2 (and most subsequent Intel and AMD x86 processors), and many recent ARM cores, including Cortex-A9, -A15, -A17, and -A57.

What is speculation?

Reordering sequential instructions is a powerful way to recover more instruction-level parallelism, but as processors become wider (able to triple- or quadruple-issue instructions) it becomes harder to keep all those pipes busy. Modern processors have therefore grown the ability to speculate. Speculative execution lets us issue instructions which might turn out not to be required (because they are branched over): this keeps a pipe busy, and if it turns out that the instruction isn’t executed, we can just throw the result away.

To demonstrate the benefits of speculation, let’s look at another example:

t = a+b
u = t+c
v = u+d
if v:
   w = e+f
   x = w+g
   y = x+h

Now we have dependencies from t to u to v, and from w to x to y, so a two-way out-of-order processor without speculation won’t ever be able to fill its second pipe. It spends three cycles computing t, u, and v, after which it knows whether the body of the if statement will execute, in which case it then spends three cycles computing w, x, and y. Assuming the if (a branch instruction) takes one cycle, our example takes either four cycles (if v turns out to be zero) or seven cycles (if v is non-zero).

Speculation effectively shuffles the program like this:

t = a+b
u = t+c
v = u+d
w_ = e+f
x_ = w_+g
y_ = x_+h
if v:
   w, x, y = w_, x_, y_

so we now have additional instruction level parallelism to keep our pipes busy:

t, w_ = a+b, e+f
u, x_ = t+c, w_+g
v, y_ = u+d, x_+h
if v:
   w, x, y = w_, x_, y_

Cycle counting becomes less well defined in speculative out-of-order processors, but the branch and conditional update of w, x, and y are (approximately) free, so our example executes in (approximately) three cycles.

What is a cache?

In the good old days*, the speed of processors was well matched with the speed of memory access. My BBC Micro, with its 2MHz 6502, could execute an instruction roughly every 2µs (microseconds), and had a memory cycle time of 0.25µs. Over the ensuing 35 years, processors have become very much faster, but memory only modestly so: a single Cortex-A53 in a Raspberry Pi 3 can execute an instruction roughly every 0.5ns (nanoseconds), but can take up to 100ns to access main memory.

At first glance, this sounds like a disaster: every time we access memory, we’ll end up waiting for 100ns to get the result back. In this case, this example:

a = mem[0]
b = mem[1]

would take 200ns.

In practice, programs tend to access memory in relatively predictable ways, exhibiting both temporal locality (if I access a location, I’m likely to access it again soon) and spatial locality (if I access a location, I’m likely to access a nearby location soon). Caching takes advantage of these properties to reduce the average cost of access to memory.

A cache is a small on-chip memory, close to the processor, which stores copies of the contents of recently used locations (and their neighbours), so that they are quickly available on subsequent accesses. With caching, the example above will execute in a little over 100ns:

a = mem[0]    # 100ns delay, copies mem[0:15] into cache
b = mem[1]    # mem[1] is in the cache

From the point of view of Spectre and Meltdown, the important point is that if you can time how long a memory access takes, you can determine whether the address you accessed was in the cache (short time) or not (long time).

What is a side channel?

From Wikipedia:

“… a side-channel attack is any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis). For example, timing information, power consumption, electromagnetic leaks or even sound can provide an extra source of information, which can be exploited to break the system.”

Spectre and Meltdown are side-channel attacks which deduce the contents of a memory location which should not normally be accessible by using timing to observe whether another location is present in the cache.

Putting it all together

Now let’s look at how speculation and caching combine to permit the Meltdown attack. Consider the following example, which is a user program that sometimes reads from an illegal (kernel) address:

t = a+b
u = t+c
v = u+d
if v:
   w = kern_mem[address]   # if we get here crash
   x = w&0x100
   y = user_mem[x]

Now our out-of-order two-way superscalar processor shuffles the program like this:

t, w_ = a+b, kern_mem[address]
u, x_ = t+c, w_&0x100
v, y_ = u+d, user_mem[x_]

if v:
   # crash
   w, x, y = w_, x_, y_      # we never get here

Even though the processor always speculatively reads from the kernel address, it must defer the resulting fault until it knows that v was non-zero. On the face of it, this feels safe because either:

  • v is zero, so the result of the illegal read isn’t committed to w
  • v is non-zero, so the program crashes before the read is committed to w

However, suppose we flush our cache before executing the code, and arrange a, b, c, and d so that v is zero. Now, the speculative load in the third cycle:

v, y_ = u+d, user_mem[x_]

will read from either address 0x000 or address 0x100 depending on the eighth bit of the result of the illegal read. Because v is zero, the results of the speculative instructions will be discarded, and execution will continue. If we time a subsequent access to one of those addresses, we can determine which address is in the cache. Congratulations: you’ve just read a single bit from the kernel’s address space!

The real Meltdown exploit is more complex than this, but the principle is the same. Spectre uses a similar approach to subvert software array bounds checks.

Conclusion

Modern processors go to great lengths to preserve the abstraction that they are in-order scalar machines that access memory directly, while in fact using a host of techniques including caching, instruction reordering, and speculation to deliver much higher performance than a simple processor could hope to achieve. Meltdown and Spectre are examples of what happens when we reason about security in the context of that abstraction, and then encounter minor discrepancies between the abstraction and reality.

The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort.

* days may not be that old, or that good

The post Why Raspberry Pi isn’t vulnerable to Spectre or Meltdown appeared first on Raspberry Pi.

Slack on the Commodore 64 thanks to Raspberry Pi

Post Syndicated from Lucy Hattersley original https://www.raspberrypi.org/blog/slack-commodore-64/

We use Slack all the time at Pi Towers. Granted, we often use it for sharing animated cat GIFs and the latest hacks for the office coffee machine, but we are definitely big fans.

Imagine our delight, then, when we heard about a Slack client for the Commodore 64 (another long-standing flame of ours). Our love for the C64 knows few bounds: along with the Sinclair Spectrum and the BBC Micro, it gave many of us here at the Raspberry Pi Foundation a coding kick-start.

The only thing that could make this better is the Raspberry Pi. And guess what’s sitting slap-bang in the middle between Slack and the C64? Only our favourite single-board computer.

This amazing trinity of tech brings our favourite things together for a text messaging party. We just had to figure out how it worked.

Raspberry Pi Slack

The Raspberry Pi accesses the Slack API

It turns out that bringing Slack to the C64 was no easy matter. Jeff Harris is a software engineer and hobbyist game developer in San Francisco. He’s responsible for developing Slack for the C64.

Much as we love it, the C64 is a little long in the tooth, so it needs a little help connecting to Slack’s API. Jeff’s ingenious result is to hook a Raspberry Pi up to it. “The C64 has an extension port called the user port which, via an adapter, can communicate over RS-232 serial,” Jeff says. The solution was to connect the user port on a Commodore 64 to a USB port on the Raspberry Pi, and Jeff created a homemade cable to do just that.

“The fastest I have been able to run this reliably is a solid 1200 baud or 150 bytes per second,” explains Jeff. At 0.00015 MB, it’s not likely to be much use at a LAN party, but it’s good enough for transferring text messages.

Slack client for Commodore64

What is one thing that Slack is missing? A native client for Commodore64! I built this client in 6502 assembly on the C64 side, and a NodeJS app running on a Raspberry Pi, connected to the C64 via a serial connection. More details here: http://1amstudios.com/2016/11/27/c64-slack-client/

Coding Slack in 6502 Assembly

With the hardware hooked up, Jeff set about writing a Slack client for the Commodore 64. “On the Raspberry Pi, I wrote a NodeJS app which talks to the Slack RTM API,” he says.

The Raspberry Pi connects to the Slack API. It then uses the serial port to talk to the USB serial driver.

“On the Commodore, I wrote an application in 6502 Assembly,” says Jeff. “It uses built-in KERNAL ROM functions to read and write the serial port and update the screen.”

In this blog post, Jeff shows how the C64 client code works using C as a demonstration language. If you want to try recreating the project, all the code is available on Jeff’s GitHub page.

It’s great to see the Commodore 64 still being hacked and kept in use after all these years.

 

The post Slack on the Commodore 64 thanks to Raspberry Pi appeared first on Raspberry Pi.

Ten millionth Raspberry Pi, and a new kit

Post Syndicated from Eben Upton original https://www.raspberrypi.org/blog/ten-millionth-raspberry-pi-new-kit/

When we started Raspberry Pi, we had a simple goal: to increase the number of people applying to study Computer Science at Cambridge. By putting cheap, programmable computers in the hands of the right young people, we hoped that we might revive some of the sense of excitement about computing that we had back in the 1980s with our Sinclair Spectrums, BBC Micros and Commodore 64s.

At the time, we thought our lifetime volumes might amount to ten thousand units – if we were lucky. There was was no expectation that adults would use Raspberry Pi, no expectation of commercial success, and certainly no expectation that four years later we would be manufacturing tens of thousands of units a day in the UK, and exporting Raspberry Pi all over the world.

Less than ten million Raspberry Pis

The first two thousand Raspberry Pis. Each Pi in this pallet now has 5000 siblings.

With this in mind, you can imagine how strange it feels to be able to announce that over the last four and a half years we’ve sold a grand total of ten million Raspberry Pis. Thanks to you, we’ve beaten our wildest dreams by three orders of magnitude, and we’re only just getting started. Every time you buy a Raspberry Pi, you help fund both our ongoing engineering work, and our educational outreach programs, including Code Club and Picademy.

Very early on, we decided that we would offer the bare-bones Raspberry Pi board without accessories: that way, cost-conscious customers get the lowest possible price, provided they can beg or borrow USB peripherals, a power supply and an SD card. Over the years, Raspberry Pi distributors have built on this, producing some fantastic bundles for people who would rather get everything they need from a single source.

To celebrate the ten millionth Raspberry Pi, for the first time we’ve put together our own idea of what the perfect bundle would look like, creating the official Raspberry Pi Starter Kit.

The starter kit, unboxed and ready to go

The starter kit, unboxed and ready to go

Inside the minimalist white box (like the official case, another beautiful Kinneir Dufort design), you’ll find:

  • A Raspberry Pi 3 Model B
  • An 8GB NOOBS SD card
  • An official case
  • An official 2.5A multi-region power supply
  • An official 1m HDMI cable
  • An optical mouse and a keyboard with high-quality scissor-switch action
  • A copy of Adventures in Raspberry Pi Foundation Edition

This is an unashamedly premium product: the latest Raspberry Pi, official accessories, the best USB peripherals we could find, and a copy of the highest-rated Raspberry Pi book. The kit is available to order online in the UK from our partners element14 and RS Components, priced at £99+VAT, and will be coming to the rest of the world, and to your favourite reseller, over the next few weeks.

The post Ten millionth Raspberry Pi, and a new kit appeared first on Raspberry Pi.

Creative computing at Eastwood Academy

Post Syndicated from Oliver Quinlan original https://www.raspberrypi.org/blog/creative-computing-at-eastwood-academy/

It’s nearly two years since Computing became a subject for all children in England to study, and we’re now seeing some amazing work to bring opportunities for digital making into schools. Recently I visited Eastwood Academy in Southend-on-Sea, where teacher Lucas Abbot has created a digital making room, and built a community of young programmers and makers there.
Photo 14-06-2016, 12 51 38

Lucas trained as a physics teacher and got hold of a Raspberry Pi for projects at home back in 2012. His head teacher heard about his hobby, and when the move towards all children learning programming started, Lucas was approached to take up the challenge of developing the new subject of Computing in the school. With the help of friends at the local Raspberry Jam, Linux user group, and other programming meetups, he taught himself the new curriculum and set about creating an environment in which young people could take a similarly empowered approach.

In Year 7, students start by developing an understanding of what a computer is; it’s a journey that takes them down memory lane with their parents, discussing the retro technology of their own childhoods. Newly informed of what they’re working with, they then move on to programming with the Flowol language, moving to Scratch, Kodu and the BBC micro:bit. In Year 8 they get to move on to the Raspberry Pi, firing up the fifteen units Lucas has set up in collaborative workstations in the middle of the room. By the time the students choose their GCSE subjects at the end of Year 8, they have experienced programming a variety of HATs, hacking Minecraft to run games they have invented, and managing a Linux system themselves.
Photo 14-06-2016, 10 02 44

Fifteen Raspberry Pi computers have been set up in the centre of the room, at stations specifically designed to promote collaboration. While the traditional PCs around the edges of the room are still used, it was the Pi stations where pupils were most active, connecting things for their projects, and making together. A clever use of ceiling-mounted sockets, and some chains for health and safety reasons, has allowed these new stations to be set up at a low cost.

The teaching is based on building a firm foundation in each area studied, before giving students the chance to invent, build, and hack their own projects. I spent a whole day at the school; I found the environment to be entirely hands-on, and filled with engaged and excited young people learning through making. In one fabulous project two girls were setting up a paper rocket system, propelled using compressed air with a computer-based countdown system. Problem-solving and learning through failure are part of the environment too. One group spent a session trying to troubleshoot a HAT-mounted display that wasn’t quite behaving as they wanted it to.

Lessons were impressive, but even more so was the lunchtime making club which happens every single day. About 30 young people rushed into the room at lunchtime and got started with projects ranging from figuring out how to program a robot Mr Abbot had brought in, to creating the IKEA coffee table arcade machines from a recent MagPi tutorial.
Photo 14-06-2016, 13 04 41

I had a great conversation with one female student who told me how she had persuaded her father to buy a Raspberry Pi, and then taught him how to use it. Together, they got inspired to create a wood-engraving machine using a laser. Lunchtime clubs are often a place for socialising, but there was a real sense of purpose here too, of students coming together to achieve something for themselves.

Since 2014 most schools in England have had lessons in computing, but Eastwood Academy has also been building a community of young digital makers. They’re linking their ambitious lessons with their own interests and aspirations, building cool projects, learning lots, and having fun along the way. We’d love to hear from other schools that are taking such an ambitious approach to computing and digital making.

The post Creative computing at Eastwood Academy appeared first on Raspberry Pi.

The story of Raspberry Pi – and a masterclass with Eben

Post Syndicated from Liz Upton original https://www.raspberrypi.org/blog/story-raspberry-pi/

The Centre for Computing History, with help from the Heritage Lottery fund, conducted a video interview about the story of Raspberry Pi with our very own Eben Upton (founder, Raspberry Pi Trading CEO, fond of Jaffa Cakes) a few months ago. It’s just been made live – if you want to dive deep into the story of Raspberry Pi, this one’s for you.

Eben Upton – The Story of Raspberry Pi

Eben Upton, founder of the Raspberry Pi Foundation, talks about the Raspberry Pi, how it came to be and the ups and downs of bringing his £25 computer to market. Part of the Centre for Computing History Viva Computer project funded by the Heritage Lottery Fund. www.ComputingHistory.org.uk

Eben’s giving a sort of history/computing lesson at the Centre for Computing History here in Cambridge on July 2: he’ll be teaching people how to code on a BBC Micro (the same machine he taught himself to program on back in the 1980s). This promises to be good; I’ve caught him writing snippets of game in BBC BASIC in the evenings after work for the event. People of any age over 11 are invited to sign up: get your booking in fast, because this one’s likely to sell out quickly!

The post The story of Raspberry Pi – and a masterclass with Eben appeared first on Raspberry Pi.