The screen is mounted vertically instead of horizontally and rotated clockwise by 90 degrees
Does that answer your question?
Yes, that's exactly what i thought...
@glenbull : is there a way to rotate the image of the screen so the top of the snap program face top of the arcade? (in the OS)
In windows, we can rotate the screen by software in the OS (like this in win7):
Others questions: Computer type, OS, browser
We are now running the browser in the Kiosk mode. (Thanks, @bromagosa)
@loucheman The Raspberry Pi 3 setting to place the monitor in the portrait mode (rather than the landscape mode) required a patch, but that has now been implemented.
We're using the default OS for the Raspberry Pi 3, currently running the Chromium browser.
That's perfect !
Could we have a picture of the internals ? 
We'll take a photo of the inside tomorrow. However, it is currently just lashed together as a temporary proof-of-concept to make sure that all the components work together.
We're envisioning this as a group project for a class that has already been using Snap! Therefore, we want it to be reasonably affordable, to enable as many students as possible to tackle this if they want. Here are the current components and estimated cost:
- Raspberry Pi 3 (list: $35)
- Ten-inch screen ($30 from Alibaba)
- BBC micro:bit ($30)
- Arcade buttons & joystick ($15)
This assumes that the supply constraint for Raspberry Pi will ease by the time school starts in the fall, and that it will once again be possible to acquire one for close to list price.
Snap!Bridge is the thing that makes it all work, however. Snap!Bridge connects Snap! to MicroBlocks, which in turn is used to access the arcade controls. We wanted to verify that the speed and latency in responding to the arcade controls would make the game playable. The arcade controls seem to be responsive in the current implementation.
The current version of Snap!Bridge requires more overhead than we would like for an implementation by novices who may not have much experience with microcontrollers. It requires the user to first launch MicroBlocks, connect to the micro:bit, and then disconnect and launch Snap! This is OK for a pilot implementation, and has enabled us to move the project forward, but we would like to control MicroBlocks through Snap!, so that the novice only has to launch a single browser window with Snap!
John Maloney says that this would take some work on his part, but is feasible. He says that he is willing to attempt it if @bromagosa, Jens, etc. are supportive of this goal. We envision that the mature, tested version of this would be called "MicroBridge" on the Snap! side (because it would serve as a bridge to enable Snap! to control microcontrollers via MicroBlocks). Once developed and tested, it could then be added as a Snap! library to make it accessible.
The thing that we find empowering about MicroBlocks is that it can be used with a range of different microcontrollers, and John updates the drivers as new, more powerful and less expensive microcontrollers emerge. That would make it possible to use any of a range of microcontrollers with Snap!, depending on which ones are available and affordable at a given point in time.
John says he is going to be at a meeting in Europe in May when he will get to see folks from the Snap! community in person. If there is support for this, that would provide an opportunity to work out a direction and details for moving forward.
Clarification based on the following from John:
We are currently doing the two-browser shuffle
(1. Launch Microblocks and connect to the micro:bit,
then disconnect. 2. Launch Snap! and then run
Snap!Bridge) manually.
That shouldn't be necessary. Once you've loaded the Snap!Bridge program onto the board, it will stay there until you replace it with something else. The program is stored in Flash memory, so it is persistent even when the board is not powered. So, assuming users are not changing the Snap!Bridge program, you could pre-install Snap!Bridge on the boards they will be using and they can then use it like they would use a MakeyMakey -- just plug it in and it works.
If you pre-install MicroBlocks, you can also pre-install the Snap!Bridge and students will just need to plug in the board, start Snap!, and go. No need for them to do anything with MicroBlocks. - John
Hi, Glen.
If you wanted to get rid of the Snap! control bar (full screen button, green flag, etc), you could do so by using a special URL. Let me know if you want to learn more. We used this method in our two arcade machines.
Another lower-tech option, though, is to just make a screen bezel that covers it up 
Yes, we would love to learn the method for hiding the Snap! control bar through use of a special URL. (Although use of a bezel is an equally great low-tech way to accomplish this.)
@cymplecy Here's a photo of the back of the screen.
This screen has a slot on the back that can be used to house the Raspberry Pi.
Here's a photo showing the arcade control mounts from underneath:
As you can see, this is relatively low overhead - the Raspberry Pi connects to the micro:bit, and the micro:bit is connected to the joystick and arcade buttons.
A lovely superLowTech Snap!Arcade. Congrats
So, the URL that doesn't include any buttons or decorations is:
https://snap.berkeley.edu/snap/snap.html#present:Username=[project-username]&ProjectName=[project-name]&embedMode&noExitWarning
Basically, embedMode will remove the control bar and make the stage as big as possible. noExitWarning will make sure there is no warning when you close the browser, which may or may not be what you want.
We would like to load the Snap! program directly from the Raspberry Pi as a local .xml file. However, when we do that, the "&embedMode" flag does not seem to work. Is there a way to run the program in this mode when loaded from a local .xml file?
You have a couple of options in that case:
https://snap.berkeley.edu/snap/snap.html#run:[your-project.xml]&embedMode
The only issue with this is that the green flag will still show up on top of the project. If that's a problem, you can do:
https://snap.berkeley.edu/snap/snap.html#run:[your-project.xml]&hideControls
But hideControls will not completely fill the full screen bounds like embedMode does. There will be a slight padding around the stage area.
Here's the most recent version of the Snap! arcade. We previously were using the MetroM0 Express microcontroller, which is currently about $25 on the Adafruit site, in combination with the MicroBlocks "Keyboard & Mouse" library.
John Maloney pointed out that we could substitute a Raspberry Pi Pico. The Pico only costs $5 without headers installed, so there is a considerable savings.
Here's a photo ... the Pico is the microcontroller to the righthand side of the blue arcade buttons.
Glen, this looks beautiful! 
Are you all set? Is there anything else left to do?
To launch the browser we're using the following terminal command:
"chromium-browser --kiosk snap.html"
We then tried to run a local file in the same directory using
"chromium-browser --kiosk snap.html#run:pacman.xml"
However, we're getting a "cannot retrieve file" error message.
We're assuming that this may have something to do with either:
(1) Linux file paths, or
(2) file permissions
Any thoughts would be welcome. (Thanks!)
I would start by putting the entire file path in the command, e.g., /usr/users/glenbull/Desktop/pacman.xml or whatever it is. See if that helps.