The article is a combination of various articles I found on the web, referencing older versions of one part or another, and this is a reference for my setup should I need to rebuild it.

Hardware

• Raspberry Pi Zero W – Purchased one of those kits on Amazon and it came with various cases and cables I needed, so I was happy with it.
• Logitech USB Webcam
• Power/HDMI/USB
• Keyboard/Mouse

Fresh Raspbian Install

I’m utilizing the latest version of Raspbian as of this writing, which was released around February, 2020. Flashing that to a simple 16 GB Micro SD Card for a blank slate:

Assuming you’re relatively familiar with the Pi, here’s the minimum I’m generally doing as post boot up task work:

• Changing default password
• Setting Up Wifi
• Enabling SSH
• Setting Hostname
• Setting Locale/Internationalization Options
• Rebooting

After that, the obligatory ‘update’ install:

sudo apt update
sudo apt upgrade

I can now SSH into the Pi Zero W, disconnect the keyboard, and move along with the install.

Build Dependencies

We need to download some things first before we can build mjpg-streamer. I found some references to articles that pulled from the SVN repo to retrieve and compile, but I ended up getting a large amount of compile errors that look like some library was swapped but the source wasn’t updated. It’s the 'redefinition of ‘struct statx_timestamp’' error.

Instead of pulling the SVN version, I’m going to be pulling the Git repo of mjpg-streamer that was created by jacksonliam. This (https://github.com/jacksonliam/mjpg-streamer) is the ‘official’ successor to the now abandoned SVN version at https://sourceforge.net/projects/mjpg-streamer/.

We’ll now install our dependencies before we download and compile mjpg-streamer code:

sudo apt-get install build-essential libjpeg9-dev imagemagick libv4l-dev cmake git -y

Git, Make, Install

mkdir ~/mjpg-streamer
cd ~/mjpg-streamer

git clone https://github.com/jacksonliam/mjpg-streamer.git
cd mjpg-streamer/mjpg-streamer-experimental

make
sudo make install

The make install will copy binaries, libraries and the www pages to the /usr/local/ directory structure:

• /usr/local/bin/mjpg_streamer – The primary binary
• /usr/local/lib/mjpg-streamer/ – The directory of input/output modules
• /usr/local/share/mjpg-streamer/www – The www server interface

Test The Build

I’m going to test the build by plugging in a webcam into the Pi Zero W’s lone USB port. Executing dmesg shows that it was loaded properly:

[ 1275.662775] usb 1-1: New USB device found, idVendor=046d, idProduct=082d, bcdDevice= 0.11
[ 1275.662796] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=1
[ 1275.662806] usb 1-1: Product: HD Pro Webcam C920

Let’s test by trying to run mjpg-streamer against the input_uvc.so plugin, since I”m not using a Raspi-Camera, but a USB one instead. (See notes at the bottom about Raspberry Pi Bullseye and Raspi-Cameras). I’ll also output using the http plugin. So my testing command line looks like this:

/usr/local/bin/mjpg_streamer -i "input_uvc.so -f 15 -r 640x480" \
 -o "output_http.so -w /usr/local/share/mjpg-streamer/www"

Executing that line gives us a dump of data – here’s the relevant info:

MJPG Streamer Version: git rev: 5a6e0a2db163e6ae9461552b59079870d0959340
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: 15
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
 o: www-folder-path......: /usr/local/share/mjpg-streamer/www/
 o: HTTP TCP port........: 8080
 o: HTTP Listen Address..: (null)
 o: username:password....: disabled
 o: commands.............: enabled

Our key variables to tweak are -f for frame rate, and -r for resolution. I’ll change those later, but for a quick test I head on out to my browser and point it at the www server at http://cam-pi-zero.local:8080/

Not only do we see the web interface, but a snapshot of the web cam, which was, clearly, laying down on a workbench behind me while I tried this out.

Validating the stream worked (by clicking ‘Stream’) and turning around, I could see myself moving:

You can now hit CTRL-C in your SSH window (or terminal) and quit the stream. After this point, I could delete the build files I downloaded.

Tweaking configuration

I wanted to run my camera at its intended resolution and at least a frame rate of 30fps. To do that I modified my command line:

#30fps, 1080 HD
/usr/local/bin/mjpg_streamer -i "input_uvc.so -f 30 -r 1920x1080" \
 -o "output_http.so -w /usr/local/share/mjpg-streamer/www"

I then loaded my own stream up in VLC by opening the direct network path to the stream:

http://cam-pi-zero.local:8080?action=stream

That worked, and I get about a 1-2 second delay from Pi to VLC. So I wouldn’t use this with audio feeds unless I was planning on creating a sync delay. I’m using this to monitor 3D prints, or watch birds outside, so my use case does not demand low latency. Is it exactly 30 frames per second? No…. NO it’s not.

At 1280×720, it seemed closer, but at 1920×1080, when set at 30fps, it definitely wasn’t even close. I’d guess more like 15.

The PI wasn’t maxed out on CPU, but it could just be the nature of USB 2.0 at this point. I’m not sure how I can tell if it’s overloaded there or not, but, once again, this is a light monitoring video stream, I don’t care too much about latency. It could be WiFi as well. Someday I may dig in a bit more and find out where the bottleneck is.

I think you could probably choose either 1920×1080 15fps or 1280×720 30fps routes and be okay.

v4l2-ctl --list-formats-ext

Running On Startup

I liked Jacob Salmela‘s script – all I did was change it for my command line on the stop and restart section for my resolution and frame-rate. Save the following script by doing a sudo vi:

sudo vi /etc/init.d/livestream.sh

#!/bin/sh
# /etc/init.d/livestream.sh
### BEGIN INIT INFO
# Provides:          livestream.sh
# Required-Start:    $network
# Required-Stop:     $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mjpg_streamer for webcam
# Description:       Streams /dev/video0 to http://IP/?action=stream
### END INIT INFO
f_message(){
        echo "[+] $1"
}

# Carry out specific functions when asked to by the system
case "$1" in
        start)
                f_message "Starting mjpg_streamer"
                /usr/local/bin/mjpg_streamer -b -i "input_uvc.so -f 15 -r 1920x1080" -o "output_http.so -w /usr/local/share/mjpg-streamer/www"
                sleep 2
                f_message "mjpg_streamer started"
                ;;
        stop)
                f_message "Stopping mjpg_streamer…"
                killall mjpg_streamer
                f_message "mjpg_streamer stopped"
                ;;
        restart)
                f_message "Restarting daemon: mjpg_streamer"
                killall mjpg_streamer
                /usr/local/bin/mjpg_streamer -b -i "input_uvc.so -f 15 -r 1920x1080" -o "output_http.so -w /usr/local/share/mjpg-streamer/www"
                sleep 2
                f_message "Restarted daemon: mjpg_streamer"
                ;;
        status)
                pid=`ps -A | grep mjpg_streamer | grep -v "grep" | grep -v mjpg_streamer. | awk ‘{print $1}’ | head -n 1`
                if [ -n "$pid" ];
                then
                        f_message "mjpg_streamer is running with pid ${pid}"
                        f_message "mjpg_streamer was started with the following command line"
                        cat /proc/${pid}/cmdline ; echo ""
                else
                        f_message "Could not find mjpg_streamer running"
                fi
                ;;
        *)
                f_message "Usage: $0 {start|stop|status|restart}"
                exit 1
                ;;
esac
exit 0

Then we enable this on startup by performing:

sudo chmod 755 /etc/init.d/livestream.sh
sudo update-rc.d livestream.sh defaults

Now you can reboot your pi, or use commands like ‘sudo service livestream start’ I rebooted my pi, and my fed was running, and running a status command on my service yields:

pi@cam-pi-zero:~ $ sudo service livestream status
● livestream.service - LSB: mjpg_streamer for webcam
   Loaded: loaded (/etc/init.d/livestream.sh; generated)
   Active: active (running) since Thu 2020-05-14 11:46:09 CDT; 2min 51s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 411 ExecStart=/etc/init.d/livestream.sh start (code=exited, status=0/SUCCESS)
   Memory: 2.2M
   CGroup: /system.slice/livestream.service
           └─416 /usr/local/bin/mjpg_streamer -b -i input_uvc.so -f 15 -r 1920x1080 -o output_http.so

May 14 11:46:07 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: TV-Norm...........: DEFAUL
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: www-folder-path......: /us
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: HTTP TCP port........: 808
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: HTTP Listen Address..: (nu
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: username:password....: dis
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: commands.............: ena
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: starting input plugin inpu
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: starting output plugin: ou
May 14 11:46:09 cam-pi-zero.local livestream.sh[411]: [+] mjpg_streamer started
May 14 11:46:09 cam-pi-zero.local systemd[1]: Started LSB: mjpg_streamer for webcam.

Conclusion

Using the Raspberry Pi for video streams is good enough if we’re looking for low frame rate monitoring without audio. I’ve yet to find anything that really gives me the frame rate and audio (regardless of latency) that a standard USB webcam directly into my OBS machine would give. Maybe if NDI ever makes it on to the raspberry Pi, or if there is ever SLDP support.

Have you tried streaming across the network on a Raspberry Pi with a USB webcam? Did you fare better than I? Let me know!

Nevertheless, with that, I’m done! I can now embed this into OBS via the VLC media source or anything that can handle an HTTP Motion JPEG video stream. I won’t have audio, but that’s okay for what I’m using this for.

Raspi-Cameras (libcamera is in, raspivid is out in Bullseye)

Mjpg-Streamer won’t have the raspicam input module anymore if you compile on Bullseye, because I believe the headers don’t exist as the Bullseye version is going the way of libcamera. While I was able to hack around that and build it, I got HORRIBLE artifacts using a raspberry pi camera with the h264 codec and libcamera. I tried switching codecs to MJPEG instead of H264 and had less artifacts, but worse frame rate. So for now I decided to go with gstreamer instead of mjpg-streamer at 1280×720 for a nice 30fps solution.

For me, what worked was to enable the legacy raspi-camera support (so we’re not using libcamera, we’re using v4l2).

Here are the rough steps:

• Started out with Bullseye, latest install with sudo apt update/sudo apt upgrade executed.
• Edit /boot/config.txt and change the following:
  • start_x=1 //add this line
  • gpu_mem=128 //probably no higher
  • #camera_auto_detect=1 //Comment this line out
• Restart
• Installs:

sudo apt-get install gstreamer1.0-tools gstreamer1.0-plugins-base \
     gstreamer1.0-plugins-good gstreamer1.0-plugins-bad

Then execute this on the command line:

/usr/bin/gst-launch-1.0 v4l2src ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse config-interval=1 ! matroskamux streamable=true ! tcpserversink host=::0 port=9000 sync=false sync-method=2

Once that’s up and running, I ran VLC against it using :network-caching=250 and a URL of tcp://<yourhostname>:9000 and was able to get a decent stream. That’s about the extent I’ve been pushing the raspi-cameras as I typically use the USB side. I did notice it was nice and fluid, along with less power consumption by a 100 milliamps or so, so I think I’ll use this as a portable battery powered wireless camera to use around the house on streams. Hmmm, I may need to look at getting a microphone on here somehow and streaming audio with gstreamer as well.

References

• https://einar.slaskete.net/2018/08/16/using-a-raspberry-pi-as-a-surveillance-camera-in-home-assistant/
• https://picamera.readthedocs.io/en/release-1.12/fov.html
• https://qengineering.eu/install-gstreamer-1.18-on-raspberry-pi-4.html
• https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md – Raspberry Pi Document on WIFI Setup
• https://www.amazon.com/Vilros-Raspberry-Starter-Power-Premium/dp/B0748MPQT4 – The Raspberry Pi Zero W kit I purchased
• https://sourceforge.net/projects/mjpg-streamer – The original source forge project.
• https://github.com/jacksonliam/mjpg-streamer – The successor to the abandoned Sourceforge project.
• https://jacobsalmela.com/2014/05/31/raspberry-pi-webcam-using-mjpg-streamer-over-internet/ – Reference for build information
• https://www.acmesystems.it/video_streaming – Another build reference
• https://qiita.com/xeno14/items/e32e52c688d969d182e2 – Another build reference

The post MJPG-Streamer on a Raspberry Pi Zero W with a USB Webcam Streaming Setup appeared first on Krystof.IO.

While the circuit details will come in a later article, here’s a little visual of the circuit setup – a Raspberry Pi 4 with GPIO pins attached to a breakout board, attached to a breadboard. The top breadboard is used to drive a separate power source for the LEDs, but you can see the green ‘power’ LEDs and one of the red ‘activity’ LEDs light up there, that’s all driven by the Raspberry PI and VICE.

High Level Design

Since VICE is an open source project (thank goodness!), I figured I’d need to get in that code and see if I can detect when the virtual floppy drives are being used. If I could do that, I’d want to send that data to a different program that would be responsible for driving the Raspberry Pi GPIO pins, which then drive the LEDs. I purposefully did not want to drive the LEDs directly from VICE itself – I wanted to affect the actual emulator process as little as possible. Just enough to get the data out of VICE. After that, some other process takes the data and controls the circuit. The secondary program would be written in Python, primarily because it’s very easy to interface with the Raspberry PI with the Python GPIO libraries. VICE, of course, is written in C.

So I’d have a C program that gathers data, and a Python program that does something with it. We typically call that a Publisher/Subscriber scenario. VICE is the Publisher as it is sourcing data, and making it available (publishing) for other processes to use, and VICE isn’t getting any data back – this is a one-sided conversation. Our Python program will be one of the Subscribers as it will poll for new ‘messages’ or changes in state. The Python program will then, in turn, send signals via the GPIO library and Raspberry PI GPIO pins to the Darlington Array, which controls individual LEDs, namely our Commodore 1541 Floppy Disk Drive Activity Lights. Here’s a high level flow:

The first real question I pondered was how I’d get a C program and a Python program on a Raspberry PI to share data, even if the conversation is one-sided. I figured I had four options off the top of my head:

1. Datafile access – Vice writes to a file that the Python program constantly reads from to determine drive status. While this is definitely feasible, I wanted to avoid constant file-system access, OS caching or not. The LED is meant to blink on and off rapidly, that’s a lot of file updates to apply on a SD card.
2. Networking Channel – UDP or TCP, some sort of client/server or packet broadcast. This would be necessary if the diorama was remote (an interesting idea), but ultimately the emulator and the consumer are on the same machine, so I wanted to keep the communications channel a little tighter.
3. UNIX Sockets – Since the Raspberry Pi 4 is running Raspbian, it supports UNIX style sockets for a simple IPC (Inter-process Communication) channel between the VICE and Python processes. However, it’s still a lot of code to inject into VICE.
4. The Winner – Shared Memory – I finally decided on a shared memory solution to avoid a lot of unnecessary and potentially harmful patching to VICE with any networking related code (the less I’m in VICE the less I affect its processing), along with Python recently getting support for shared memory between disparate processes with Python 3.8 and above.

While we are calling this a ‘Publisher/Subscriber’ model, it’s a very loose fit – there’s no middle-ware here handling message flow – it’s a bit bucket we poll for state changes every few milliseconds. Therefore, I hesitate to apply the terminology of ‘Publisher/Subscriber’ without a few grains of salt. Thy key point: VICE is decoupled from the consuming process(es).

Patching VICE

Remember where we compiled VICE on the command line? Even if a binary was available, the reason why I wanted to compile VICE was because I knew I’d be tinkering with the source code. To that end, I downloaded their SVN source and started searching through the code for key strings like ‘1541’, ‘drive’, ‘floppy’, etc. until I found drive.c and drive.h. I won’t include the whole pieces here, but this part is what I found particularly interesting – I wanted to find some place to initialize the shared memory, and some place to write to it so we can ‘publish’ our floppy drive status updates.

/* Initialize the hardware-level drive emulation (should be called at least
   once before anything else).  Return 0 on success, -1 on error.  */
int drive_init(void)
{
    unsigned int dnr;
    drive_t *drive;

    if (rom_loaded) {
        return 0;
    }

//..... More
}

Great! drive_init sounds like a good hook method – we don’t want to constantly be creating shared memory segments, create it once, but write to it many times. Here’s where I figured I’d place the ‘publishing’ code:

static void drive_led_update(drive_t *drive, drive_t *drive0)
{
    int my_led_status = 0;
    CLOCK led_period;
    unsigned int led_pwm;

    /* Actually update the LED status only if the `trap idle'
       idling method is being used, as the LED status could be
       incorrect otherwise.  */

    if (drive0->idling_method != DRIVE_IDLE_SKIP_CYCLES) {
        my_led_status = drive->led_status;
    }

//More.....
}

So now, we know the two spots that sound like they’d be great for initialization and continuous updates of our shared memory with drive status. Let’s look at the modifications necessary, then. Our goal is to allocate some shared memory (just enough to hold drive status for drive devices 8 through 11), and when VICE is updating it’s UI LED, we want to update shared memory with that status, a simple 1 or 0 toggle will suffice. That’s a pretty straightforward hook!

Modifications for drive.c

#include <fcntl.h>
#include <sys/shm.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <unistd.h>

const char *led_shm_name = "vice-drive-led-shm";

void *viceDriveLedShmPointer;

void init_drive_led_shm(void) {

	int shm_fd;

	const int SIZE = 16;

	/* create the shared memory object */
	shm_fd = shm_open(led_shm_name, O_CREAT | O_RDWR, 0666);

	/* configure the size of the shared memory object */
	ftruncate(shm_fd, SIZE);

	/* memory map the shared memory object */
	viceDriveLedShmPointer = mmap(0, SIZE, PROT_WRITE, MAP_SHARED, shm_fd, 0);

	sprintf(viceDriveLedShmPointer, "%s", "80900010");
}

void update_shm_drive_status(unsigned int driveNumber,
		int driveLedStatus) {
//      Uncomment for some simple and extreme debugging
//	log_warning(drive_log, "Hey! Drive %d Status : %d", driveNumber,
//			driveLedStatus);

	if (drive_init_was_called) {
		((char*) viceDriveLedShmPointer)[(driveNumber * 2) + 1] = (
				driveLedStatus == 0 ? '0' : '1');
	}
}

//  Call our initialization method from drive_init
init_drive_led_shm();

//  Add this to update our status in the existing function drive_led_update
update_shm_drive_status(drive->mynumber, my_led_status);

Modifications to drive.h

extern void init_drive_led_shm(void);
extern void update_shm_drive_status(unsigned int driveNumber, int driveLedStatus);

Modifications for compilation

There’s not much else to this – all I needed to add (and this was a quite a bit of stumbling around on my part as I’m not comfortable or familiar with automake/autoconf) was adding the system libraries to work with shared memory to the configuration file configure.proto, around line 3316, before references to GFXOUTPUT_DRIVERS

dnl Patch to add -lrt for shared memory IPC work
echo "Patch to add -lrt for shared memory IPC work"
old_LIBS="$LIBS"
LIBS="$LIBS -lrt"

Github repo

Of course, you don’t have to copy these and paste them yourselves. I put a GitHub repo for my modifications here:

https://github.com/erkrystof/vice

You’ll want to check the tags for ‘pure VICE’ and tags for my modifications to see deltas or pull the version you desire.

When I wrote this – there was one tag that represented my modifications and VICE 3.4 combined:

git clone --single-branch --branch 3.4-Modded-1.0 https://github.com/erkrystof/vice

Running VICE with our patch

After running the same build commands as I did when installing basic VICE, executing the binary should have no discernible difference (unless you un-comment that log statement) in the logs for the way VICE handles.

However, you should now notice there’s a piece of shared memory you can see, and that you can read, given that everything in *nix is a file.

pi@vice-pi:/dev/shm $ ls -l
total 4
-rw-r--r-- 1 pi pi 16 Feb  9 09:16 vice-drive-led-shm
pi@vice-pi:/dev/shm $ cat vice-drive-led-shm
80900010
pi@vice-pi:/dev/shm $

Excellent, we now know it’s working! If I loop over that in an SSH console, just to see, and run VICE and load a floppy, you should see the second byte (0/1 – the drive 8 status LED) flip between 1 and 0.

for i in {1..10000}; do cat vice-drive-led-shm; echo ... Counter: $i; done
#Sample output:
80900010... Counter: 43
80900010... Counter: 44
80900010... Counter: 45
81900010... Counter: 46  <----- We have activity on drive 8
81900010... Counter: 47
81900010... Counter: 48
81900010... Counter: 49

Looking good so far. So VICE is essentially done – it’s ‘publishing’ drive status to an area in shared memory that we’ll now want to read from and drive the LEDs connected to the Raspberry Pi GPIO pins.

Reading the 1541 drive status with Python

We’re halfway there – the next step is to work on a separate process – our subscriber that reads the VICE drive status and sends commands to the Raspberry Pi’s GPIO pins to drive our LEDs. I could have done this in C, matching how we read shared memory that we’re writing to in VICE, but I wasn’t familiar with driving a Raspberry Pi’s GPIO pins from C. I am a bit more comfortable with the GPIO libraries available in Python, however, though the question of reading shared memory needed an answer.

Granted, I could probably just read from /dev/shm/vice-drive-led-shm, but I really wanted to keep this semi-portable in the sense that I wanted to use the available shared-memory libraries instead of a known *nix-specific file behavior. After doing some research on Python and shared memory, it turns out we need a more recent version of Python than may come with your default Raspbian install – Python 3.8 or greater.

Python 3.8 or greater and RPi.GPIO libraries

For that installation, I’m going to divert away from this article to a separate one that’s not necessarily part of the series as reference if you need it – How to install Python 3.8 on the Raspberry Pi.

If you already have Python 3.8 or greater, you’ll just need to make sure you have the RPi GPIO library installed:

sudo python3.8 -m pip install RPi.GPIO

A simple Python client

The latest source code for the Python piece is available on GitHub, although I’ll go over this roughly below.

Initialization

Let’s look at the first chunk, primarily initialization and some structure:

powerLedsPin = 23
drive8ActivityPin = 27
drive9ActivityPin = 22

DRIVE_8_ACTIVITY_INDEX = 1
DRIVE_9_ACTIVITY_INDEX = 3

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BCM)
GPIO.setup([powerLedsPin,drive8ActivityPin,drive9ActivityPin],
        GPIO.OUT, initial=GPIO.HIGH)

My diorama has four ‘devices’ – two 1541 floppy drives, a Commodore keyboard, and a Commodore monitor. We use one pin for all green ‘power’ LEDs, since I didn’t feel like controlling power LEDs separately, it’s all the same output. For the floppy drive activity LEDs, however, I needed them controlled separately, so I created a drive 8 and drive 9 pin and reserved them to pins 27 and 22, respectively.

After that I’m setting up the state to be HIGH – initialize all LEDs as on.

Load the shared memory reference

Our primary code must first initialize the reference to shared memory:

try:
    print ("Consumix Python version starting up.")

    while (True):
        try:
            shm_vice = shared_memory.SharedMemory(name="vice-drive-led-shm", create=False, size=16)
            break;
        except Exception as e:
            print (e)
            print ("Error Trying to Open Shared Memory... Trying again in a bit.")
            time.sleep(.5)
            continue

    print ("Shared memory found, let's read it.")

We’re using the same shared memory name we used in VICE, and we say ‘create=False’ since VICE is responsible for creating the shared memory object – we are just reading 16 bytes worth. In the case that the Python program starts before VICE, we catch the exception and try again in a little bit. I had to add that slightly fault tolerant try/catch loop as this Python client ends up staring before VICE when I startup my Raspberry Pi.

Read Shared, Write LED

Now that we’ve loaded our shared memory reference, we read from the shared memory, place it into a character array, and update the LEDs with a loop and a function:

while (True):
        driveData = array.array('b',shm_vice.buf[:8])
        driveDataString = driveData.tostring().decode("utf-8")
        updateLEDLighting(driveDataString)
        time.sleep(0.025)

#... more stuff after....
#update function for reference:

def updateLEDLighting(driveDataString):
    if (driveDataString[DRIVE_8_ACTIVITY_INDEX] == '1'):
        GPIO.output(drive8ActivityPin,GPIO.HIGH)
    else:
        GPIO.output(drive8ActivityPin,GPIO.LOW)

    if (driveDataString[DRIVE_9_ACTIVITY_INDEX] == '1'):
        GPIO.output(drive9ActivityPin,GPIO.HIGH)
    else:
        GPIO.output(drive9ActivityPin,GPIO.LOW)

It’s a pretty simple program overall – but it does the job. Since I only ended up wiring up two drives, I only read the drive 8 and 9 data, and ignore 10 and 11.

A note on Python shared memory

This isn’t as fault tolerant as I’d like though – if you quit your Python client, the shared memory reference seems to be destroyed – which completely baffles me. The creator of a resource is in charge of closing it, not some other process. So if VICE is creating the shared memory, I could understand if my Python client needs to open and close a reference, but not the shared memory itself.

Regardless, when I close my Python client, it destroys the shared memory object completely, even if I try to ‘close’ the reference ahead of time. Perhaps I’ve wired something up wrong here – but i think, based on some of these links referencing the shared-memory usage in Python 3.8, that I’m not entirely crazy.

https://bugs.python.org/issue38119

Now, I’m not really worried about this myself – but it could be an interesting read for others – as far as my Python client goes, I don’t need to restart it, so it shouldn’t start closing the shared memory VICE created on me. What I may need to do now and then is restart VICE, however, and this setup handles that just fine (my patched-VICE simply uses the existing shared-memory object and the Python client keeps reading happily).

The outcome

Load up VICE and the Python client, and watch your GPIO pins toggle high and low with drive activity. You can debug by tailing the shared memory object as we did above, you could use an oscilloscope or multimeter to watch some voltage changes on the GPIO pins, or you could do what I did – have some LEDs on the pins and watch them blink on and off – which is exactly what I’m looking for.

The post Patching the VICE emulator to light up floppy drive LEDs appeared first on Krystof.IO.

Previously in the series, we installed VICE on our Raspberry Pi and made sure it worked. Now we want to mirror the HDMI output to our tiny LCD for the diorama.

Here’s our video that covers this article at a high level:

Two LCDs enter, One LCD leaves

The OLED Breakout Board – 16-bit Color 0.96″ w/microSD holder was a contender. At about 1/12 scale this would have worked out nicely, though it felt a little ‘wide screen’ compared to the monitors I knew of my youth. I was also concerned with resolution, as it supports 96×64, a far cry from the Commodore 64’s 320×200.

The other, and my ultimate winner – the Adafruit 1.3″ 240×240 Wide Angle TFT LCD Display with MicroSD – ST7789 at least got me closer with 240×240, though it was a touch larger. To that end, I’d try both with the Raspberry Pi and compare. Once I plugged in the 240×240 display and saw the Commodore 64 Ready screen, I was sold. Even though you’d be able to make out what I was playing on the OLED display mirroring my HDMI output, with the 240×240 you can actually read a good amount of text, as well. We have a winner.

A Couple of Quests for the Chosen One

Adafruit has a great page in terms of how to wire this up to an Arduino and Raspberry Pi located here. It’s where I learned that the ST7789 chip is used to drive two different LCD displays – 240×240 and 320×240. This becomes important later as I struggle with getting that working on the Raspberry Pi. Regardless of what display I chose – I knew I needed to have the following requirements satisfied:

• The LCD should mirror HDMI output – I didn’t want this to be the primary display, but a mirrored display.
• The LCD screen needed to be in a specific orientation – pins on the bottom – so they could more easily hide inside the 3D printed monitor ‘bottom’

Wire Before You Fire

The display doesn’t come with header pins pre-soldered, so after remembering which end of the soldering iron is the hot end, I was able to move forward by placing the display into my breadboard:

I followed the basic Adafruit directions for wiring the ST7789 driven 240×240 display into my Raspberry Pi. Key points:

• This is an SPI mode device. We’re using the Raspi’s SPI0 mode, so that some of the LCD pins need to wire up to specific Raspberry Pi Pins. More on SPI here.
• We have a choice on the LCD’s reset pin, we went with a loose default of 24 on the Pi.
• We have a choice on the D/C pin, we went with a loose default of GPIO 25 on the Pi.

Here’s from Adafruit’s page specific to our ST7789 driven LCD display: (Editors Note – If you compare this to Adafruit’s wiring page, you may notice I swapped my RST and D/C pins – Adafruit uses 24/25 and I’m using 25/24 – It’s fine as long as you’re consistent with your physical pins and the command line options you’ll use later. Thanks, Thomas!)

• Vin connects to the Raspberry Pi’s 3V pin
• GND connects to the Raspberry Pi’s ground
• CLK connects to SPI clock. On the Raspberry Pi, thats SCLK
• MOSI connects to SPI MOSI. On the Raspberry Pi, thats also MOSI
• CS connects to our SPI Chip Select pin. We’ll be using CE0
• RST connects to our Reset pin. We’ll be using GPIO 25 but this can be changed later.
• D/C connects to our the data/command pin. We’ll be using GPIO 24, but this can be changed later as well.

Remember that the Raspberry PI has numerous GPIO pins, but GPIO pin 24 doesn’t mean pin 24 on the pin-out diagram – always refer to some cheat sheet like this one from RaspberryPi.org shown below. Also, another great Raspberry Pi pin-out page that’s interactive is made available by Gadgetoid.

Okay, so we’ve got it wired now, and there’s a promising backlight barely illuminating the LCD when we turn the PI on. We’re one step closer to mirroring our Raspberry Pi to the ST7789 driven LCD Display. Now what?

LCD Driver Powers activate! Form of a mirrored display

While I could have used Python to draw some Commodore images, screenshots, and other static media on the display, I want to actually mirror the display. What shows on the HDMI output should show on the LCD, but I need the mirror scaled. My monitor I’ll play games on doesn’t support 320×240 as a resolution, the bare minimum is 800×600 to make it work well enough. So I searched around the internet and found a couple of solutions that did NOT turn the LCD into the only display or require me to overwrite with a new image.

This is where things might get a little confusing. Both solutions I’m presenting here involve taking the HDMI display output and doing a little frame-buffer copy and manipulation magic.

1. Notro’s fbtft LCD device drivers, which create an LCD frame buffer at /dev/fb1, then utilizing tasanakorn’s fbcp program which copies /dev/fb0 (HDMI output) to /dev/fb1 (LCD output), effectively mirroring the display.
2. juj’s fbcp-ili9341 display driver that effectively does the same thing as #1, though it doesn’t technically create it’s own framebuffer, and it’s not just for ili9341 displays (it supports my ST7789!)

Which one to use? Well, if only one works for you, choose that one. Otherwise, I found that the second, fbcp-ili9341 worked the best, but it does utilize a little more CPU, so you may very well want to test both (the Raspberry Pi 4 handled it fine)

The primary issues I had with both of these solutions involved rotation. My requirements for either solution were to have the header pins aligned with the bottom of the display so I could more easily hide them in the mini-LCD monitor’s bottom piece.

Option 1 – fbtft and fbcp

The Journey to a working LCD mirror

Notro’s fbtft driver repo seems to be still a good reference point but may not be forever. There’s a lot of discussion around the future of this project, as part of it has been brought into the Linux staging structure, and that it may stay there forever stagnating based on some discussions on the development page. Nevertheless, it did end up working.

There’s a lot of good information to sift through on that wiki, but I’ll keep this page more towards my journey in getting it working.

I saw some references in the staging code base to the ST7789 driver, so it felt promising:

https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c

Now, the key here is that if these drivers are effectively already part of my Raspbian install, I should be able to use the Linux modprobe commands to load these modules in. By looking at other sample modprobe commands I tried this against my Raspberry Pi with the LCD on the breadboard:

#Screen mirrors but inverted colors and rotation
sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 gpios=reset:25,dc:24

The command above loads the fbtft_device module with a custom configuration based on the provided driver fb_st7789v. Notice that we didn’t have to declare the standard SPI pins but we need to reference our two custom GPIO pins from the wiring section – reset and dc.

Remember that this command just creates a framebuffer for the LCD at /dev/fb1, it doesn’t actively mirror the display. We need the fbcp program for that. I just run fbcp as a background process and voila. The LCD came to life … but it’s a little off. (Also, don’t worry, the full setup steps are at the end)

Here’s the result when I ran ‘htop’:

If you don’t know what that should look like, I can tell you that display screen is rotated 180 degrees off my desired layout (pins on the bottom), and the screen color is ‘negative’. It should be a black screen with white text.

Now I’m off to figure out how to rotate and how to invert the colors. I dug around the issues page on the wiki and found this reference:

https://github.com/notro/fbtft/issues/425

Github user tr1p1ea references an init string argument you can also pass along in the modprobe argument, which probably was setting some ST7789 specific codes I needed to set.

init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

What is all this crap? These are initialization parameters you can send directly to your LCD driver chipset. Notro’s page has some information there, but understanding the specifics for your LCD require the datasheet. Nevertheless, I tried it out and we got farther…

The fbtft_device page on the wiki references other parameters – one of them being rotate:

rotate
Angle to rotate display counter clockwise: 0, 90, 180, 270 

Okay, so we rotate with our updated command – I figured 180 degrees to start.

sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

Which now leaves us with something completely different – I thought I saw rotation but couldn’t tell easily – so I ran VICE and saw it fill up only part of the screen!

During my research on fbtft and fbcp, I ran across that the ST7789 driver chip supported 320×240 and 240×240 displays. So it looked like to me that my 240×240 lcd was acting as a viewport into the ‘opposite end’ of the video ram that stores the 240×240 image as configured by our modprobe command.

I had a rough idea now of what I was looking for – I need to ‘scroll’ up about 320-240 = 80 pixels. How the **** am I supposed to do this? At this point I started looking for the ST7789 data sheet so I could see if there was some ‘mode’ or related setting. After perusing this for a while, I found something quite interesting in the PDF:

At this point it looked like I wanted to add to our init string. Something with instruction 37h, with 2 parameters. I defaulted the first to zero and the second to the number of pixels I wanted to ‘scroll’. I wasn’t sure if my rotation settings ‘inverted’ the pixel count so I just started with the difference of 320-240 = 80. Of course, we’re dealing with hex, so thats 0x50. The full piece of the initialization string I inserted after the 0x36 instruction follows:

-1,0x37,0x00,0x50
-1 (break for new instruction)
0x37 Instruction for Vertical Scroll Start Address Of RAM
0x00 First Parameter  (defaulted this to 0)
0x50 Second Parameter (set this to 80 pixels, converted to hex)

So now my init string, with the extra 37h instruction added, yielded this result:

Install Instructions for Option 1 – fbtft and fbcp

So, we at least have something working. That was the entire goal of this first stage – just get the LCD mirroring the HDMI output of my Raspberry Pi with VICE. Good to go! So let’s finish off option 1 by building the list of instructions.

Since fbtft drivers are already part of Raspbian Buster, all we really need to do is download and copy fbcp, and basing the instructions off that GitHub page: https://github.com/tasanakorn/rpi-fbcp

mkdir ~/fbcp-src
cd ~/fbcp-src

git clone https://github.com/tasanakorn/rpi-fbcp.git
cd rpi-fbcp/

mkdir build
cd build
cmake ..
make

After that point, a new fbcp binary now exists in the build directory we just made.

To just test the general execution of these two, I’ll enter the commands into the shell. Afterwards I’d see the LCD activate and mirror the screen properly.

#start LCD Driver - create fb1 frame buffer
sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x37,0x00,0x50,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

Then, we need to run fbcp so it can copy the framebuffer from HDMI (/dev/fb0) to the LCD (/dev/fb1) – run this from your fbcp’s build directory you created earlier:

./fbcp &

What if we want this to run on start up? There are numerous ways to do that, here’s a simple one – pop it into rc.local. We’ll cover alternate methods later in the series, this article is just about getting the LCD going.

#Copy fbcp and start it up and the fbtft drivers  (run from your fbcp build dir)
sudo cp fbcp /usr/bin 
sudo chmod +x /usr/bin/fbcp

sudo nano /etc/rc.local

Add the following lines to rc.local before ‘exit 0’. Remember the sudo modprobe is all one single line.

sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x37,0x00,0x50,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

#
#Add a little sleep before starting fbcp to allow fbtft to initialize
#(your display might stay blank otherwise)
#
sleep 2

/usr/bin/fbcp &

Reboot and you should see the screen mirror after the boot process initializes some. If you don’t have your HDMI output active, VICE may not load (it doesn’t get a good hook into /dev/fb0) – so you may need to edit your /boot/config.txt and add:

hdmi_force_hotplug=1

Option 2 – fbcp-ili9341

A faster alternative to fbtft/fbcp that uses a little more CPU

I was initially happy with option 1 – I wasn’t planning on playing games using the tiny LCD, just mirror it so the diorama looked alive. However, I still perused a few other search threads and found out about this other option called fbcp-ili9341, and while the name may be confusing (it doesn’t create a framebuffer, and it’s not just for the ili9341 driver), I was able to get it working with our ST7789 1.3″ LCD display.

Why did I try it out? Turns out, SPI doesn’t have the inherent bandwidth as it stands with libtft and fbcp – and since I’m playing games, which inherently implies video as opposed to text, I noticed the refresh rate on the LCD was always a little stuttered while playing C64 games and demos. Through some optimizations and shortcuts, the author juj has created an alternative that is faster than our option 1, all the way to 60fps. Ohhhhh yeah.

So here’s the journey to making that work. A little easier, and a bit nicer payoff. This option, while using a little more CPU (Our Raspi has 4 cores, so it’s not a big deal), is fast. In fact, it says so on it’s GitHub page, so you know it’s true!

Since the name is also confusing, here’s why it’s named the way it is:

The fbcp part in the name means framebuffer copy; specifically for the ILI9341 controller. fbcp-ili9341 is not actually a framebuffer copying driver, it does not create a secondary framebuffer that it would copy bytes across to from the primary framebuffer. It is also no longer a driver only for the ILI9341 controller. A more appropriate name might be userland-raspi-spi-display-driver or something like that, but the original name stuck.

So I downloaded the source and compiled it, and there’s effectively just one execution line since this takes the place of fbtft and fbcp – in fact, you can’t run both at the same time – test with Option 1 or Option 2 separately.

The cmake command to the build takes a few options in, and I chose these as my initial settings so I could see what it would do:

-DST7789=ON 
There's built in support for our chip set, so this was a natural choice.
-DGPIO_TFT_DATA_CONTROL=24
Same as option 1 - our custom pin we chose for data control.
-DGPIO_TFT_RESET_PIN=25
Same as option 1 - our custom pin for LCD display reset.
-DSPI_BUS_CLOCK_DIVISOR=30
My sensible default based on the GitHub page - lower is more responsive but may cause screen artifacts on LCDs.

Compiling with those options successfully, I now had a fbcp-ili9341 binary to execute. Survey says…

Okay, we can fix this. Reading up on a reported issue in the project’s GitHub issues list, I found reference to a couple of items to change in the code:

define DISPLAY_OUTPUT_LANDSCAPE - If we comment this out, we'll rotate the display 90 degrees - which way though?  Let's try and find out what happens.

So we’re rotated properly, but we’re reversed. The text should be on the left. So we need to reverse the image, not just a simple rotation. Here’s the next changes I tried:

madctl ^= MADCTL_COLUMN_ADDRESS_ORDER_SWAP;  - Adding this line into another file will mirror image the display - Sold!

-DSTATISTICS=0 Remove that debug information

So, we try this change and rebuild, and we now have…

Now we’re getting there! We’re oriented in the right way, and the image reads left to right. Only thing now is to change the scaling, which is how my research led to this option:

-DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON - I expected something like this because our display is 240 wide, so it's scaling 180 on the vertical to maintain aspect ratio.  Let's just make it fill the whole thing so we don't have the black bars of doom.

And now….

So now I’ve got both options working in the same fashion. There are differences though, and we’ll cover that in the next section below, after the ‘install instructions’

Install Instructions for Option 2 – fbcp-ili9341

Our goal is to download fbcp-ili9341, perform some quick modifications to the code, set our options, compile, and execute it.

If necessary, download the dependencies required:

sudo apt-get install cmake

Then let’s download our source code:

mkdir ~/fbcp-ili9341
cd ~/fbcp-ili9341
git clone https://github.com/juj/fbcp-ili9341.git

This creates and downloads the source to /home/pi/fbcp-ili9341/fbcp-ili9341 (Yeah, it’s a double directory, I always make my own root directories for compilation work)

Before we compile, we need to make the edits referenced in our previous section on figuring out how Option 2 was going to work.

Edit your config.h file:

nano ~/fbcp-ili9341/fbcp-ili9341/config.h

Comment out the line below (the example is already commented out)

//#define DISPLAY_OUTPUT_LANDSCAPE

Next, we’ll edit our ST7789 (actually it’s a file that handles a couple of ST-made chips) specific file to do the ‘mirroring’ swap. Edit the following:

nano ~/fbcp-ili9341/fbcp-ili9341/st7735r.cpp

and add the following line:

madctl ^= MADCTL_COLUMN_ADDRESS_ORDER_SWAP;

somewhere before this line:

SPI_TRANSFER(0x36/MADCTL: Memory Access Control/, madctl);

Optional Gamma Change: I’ve also, over time, discovered that I like the screen a little darker, primarily because I have a camera pointed at it at the Twitch stream and it causes some overexposure of the screen compared to the diorama itself. So you can make the gamma 1.0 by changing this line in the same file:

SPI_TRANSFER(0x26/Gamma Curve Select/, 0x04/Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)/);

Change the 0x04 to 0x08:

SPI_TRANSFER(0x26/Gamma Curve Select/, 0x08/Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)/);

That’s it for file editing, let’s get back to the compile.

cd ~/fbcp-ili9341/fbcp-ili9341
mkdir build
cd build
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DSPI_BUS_CLOCK_DIVISOR=30 -DSTATISTICS=0 -DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON ..
make -j

This will create the fbcp-ili9341 binary in the build directory. Try it out by running it and hitting CTRL-C when you’re done.

sudo ./fbcp-ili9341

If that works nicely for you, you could also make a quick hack to your /etc/rc.local file and make it boot on startup. (This is a quick hack)

#Copy fbcp-ili9341 and start it up on boot
sudo cp ./fbcp-ili9341 /usr/bin 
sudo chmod +x /usr/bin/fbcp-ili9341

sudo nano /etc/rc.local

Add the following line to rc.local before ‘exit 0’.

sudo /usr/bin/fbcp-ili9341 &

Comparing Mirroring Options

You may notice right off the bat that the default initialization of our option 1 vs option 2 have a stark difference in brightness. I didn’t investigate further in making the first option brighter, because I was just so happy with option 2 as a whole I never looked back.

Option 2, as you can see in the video segment at the beginning of this article, has a much higher frame rate as promised. While I did try two different arguments to the SPI_BUS_CLOCK_DIVISOR option (30 and 8), I really didn’t see much of a difference in my eyes. The big difference is between fbtft/fbcp being much slower than fbcp-ili9341.

What’s the trade-off? As you see in the video, there’s about a 20-40% spike in one of my Pi’s cores on FBCP-ILI9341 vs regular old FBCP. Given I’m using a beefy Raspberry Pi, I detected no issues in game play. Your mileage may vary.

So we’ve now got part of our diorama circuitry working – we successfully mirrored the Raspberry Pi HDMI output to the ST7789 driven LCD display, showing whatever we play on our VICE Commodore emulator’s HDMI output. There’s more to come, though! Remember those 1541 disk drives that Commodore computers utilized? Well, we need to make sure that the LEDs we plan on putting in those floppy drives light up according to activity in VICE. To do that, we’ll need to create a custom VICE build (we’ll be doing a small bit of C programming) so we can drive LED activity and power LEDs based on whatever VICE is doing. That will be the next article in the series, coming soon.

References and Further Reading

SPI – Serial Peripheral Interface

https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi/all
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/spi-sensors-devices

Option 1 – FBTFT/FBCP

https://github.com/notro/fbtft

https://github.com/notro/fbtft/wiki/Development

https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c

https://github.com/notro/fbtft/issues/425

https://www.rhydolabz.com/documents/33/ST7789.pdf

https://github.com/tasanakorn/rpi-fbcp

Option 2 – FBCP-ILI9341

https://github.com/juj/fbcp-ili9341

Raspberry Pi GPIO Information

https://www.raspberrypi.org/documentation/usage/gpio/

Adafruit

.96″ OLED Product Page (Not the display I ended up going with for resolution reasons, otherwise it’s very nice.)

1.3″ 240×240 TFT LCD Product Page (My ultimate choice for this diorama)

Tutorial/Learning Page for the 1.3″ display (wiring, python, etc.)

VICE

The Elder Scrollers Demo by Booze Design

The post Mirroring Raspberry Pi HDMI Video to a ST7789 1.3 inch LCD Display appeared first on Krystof.IO.

Raspberry Pi 4 Version Log

All of these in records in the table below imply the general settings changes to the VICE config presented later in the document (VICE/PI General Settings I change regardless of version). Also, make sure to check out settings specific to the OS you’re using later in this document!

Simplest way to execute the scripts is to copy the Raw link and on your raspberry pi console /ssh, do this:

wget -O - <raw script url> | bash

Test Programs

I’ve also added some test programs I can easily download from my VICE script github. I use these to test very basic SID/graphics functionality. Here are the credits to the great demo makers that made them:

delaytest.d64 – Written by the 8-bit guy – useful for testing lag, and also gives an audio ping each time you press a key. I start here for just the most basic ‘is this thing on?’ approach.

Booze Design – Remains (PAL) – Lovely haunting track. https://csdb.dk/release/?id=187524

SHAPE – Disco Apocalypso (PAL) – Up beat and great visuals. https://csdb.dk/release/?id=133935

Fairlight – 2600 (PAL) – https://csdb.dk/release/?id=197187

Style – Shine On (NTSC) – https://style64.org/release/shine-style – At least some graphics and smooth SID music for NTSC testing

Looking for more demos and such?

https://csdb.dk

http://www.atlantis-prophecy.org/recollection/?load=home

VICE/PI General Settings I change regardless of version

Unless noted here, I don’t change any system settings on my raspberry pi workbench setup, except for enabling Wifi and SSH, everything is is left as the default when Raspberry Pi OS installs.

These seem to be the best general settings for things to play smoothly on the PI. They mostly involve removing the raster line filter and adjusting audio settings.

• Apply these settings in your VICE Config:
  1. Machine Settings -> Model Settings -> SID Settings:
     1. SID Model -> 8580 + digi boost (ReSID)
     2. reSID sampling method -> Fast
  2. Video Settings -> Size Settings
     1. Disable double size
     2. Disable double scan
     3. Select Fullscreen
  3. Video Settings -> Render filter
     1. Select ‘None’
  4. Sound Settings
     1. Buffer size 50msec
     2. Frequency 22050 Hz

In C64 VICE Config form (/home/pi/.config/vice/sdl-vicerc, this looks like this:

[C64]
MenuKey=293
MenuKeyUp=273
MenuKeyDown=274
MenuKeyLeft=276
MenuKeyRight=275
MenuKeyPageUp=280
MenuKeyPageDown=281
MenuKeyHome=278
MenuKeyEnd=279
SoundDeviceName="alsa"
SoundSampleRate=22050
SoundBufferSize=50
AspectRatio="1.000000"
VICIIVideoCache=0
VICIIDoubleScan=0
VICIIDoubleSize=0
VICIIFullscreen=1
VICIIFilter=0
SDLStatusbar=1
SidResidSampling=0
SidEngine=1
SidModel=2
ETHERNETCARTBase=56832
Acia1Base=56832

Sometimes, I mess with the sound sample rate when I’m capturing HDMI output and streaming It seems I need to set audio sample rate to 44100 to get my HDMI capture device to grab audio into OBS, but as far as the VICE/PI goes, I heard audio fine through my speakers. (SoundSampleRate=44100)

If you need to change your sample rate if you’re capturing output, you can try the various options in here: (Menu or config file)

• Sound Settings ->
  • Frequency 44100 Hz

This generally sets a config file line:

SoundSampleRate=44100

VICE/PI Version specific settings I’ve changed

2023-02-21-raspios-buster-armhf-lite.img.xz / VICE specifics

Synopsis: Apply general settings and you’re good to go.

Raw Notes: After applying recommended generic settings, test programs ran fine (Before that, no so much). I was locked in at 100%/50fps using x64 and PAL/NTSC using the x64 binary. The x64sc binary still chews more CPU and runs slightly slower (naturally). I still recommend applying the generic settings I use though, since I had issues with NTSC (read on…)

However, on NTSC, I do notice the CPU/FPS drop from 100% to 80%, jump back up again. This was before applying my general settings. Once I applied those, everything worked well, no stutters or CPU drops.

2023-02-21-raspios-bullseye-armhf-lite.img.xz / VICE specifics

Synopsis: Apply general settings and change to fkms video driver, and then choose HDMI output in raspi-config.

Raw Notes: After executing the script and applying the generic settings, I noticed the strange 100% to 80% CPU drops go away. This has to be something with the audio layer, imho. Now, I just wasn’t getting audio (maybe on headphones on the 4B, but the 400 doesn’t have a headphone jack)

When I switched default audio to HDMI 0 in raspi-config, that broke ALSA in vice (error message), but I also noticed even when playing demos, the CPU was locked at 100%. Something with the sound layers… I’ve tried changing to SDL and I get no audio at all (I’m only in console mode, remember)

So, next, I tried the no longer supported but still available fkms overlay setting in /boot/config.txt. After setting that and rebooting, I was able to select HDMI in raspi-config and I got audio. So far, so good. I’m not happy about having to use fkms still for bullseye, but it at least got it working.

So, for me to get this working on Bullseye, I make the following changes:

1. Make the general settings changes to sound/display in my general settings section (this is a must)
2. Bring in fkms driver for HDMI audio:

Edit your /boot/config.txt and change the following:

BEFORE:

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d

AFTER:

# Enable DRM VC4 V3D driver
dtoverlay=vc4-fkms-v3d

You must reboot after /boot/config.txt changes. You must also go into raspi-config and choose your audio device (this is how I was able to get VICE HDMI Audio on the 400)

Side note: I had flashing video artifacts on bullseye, but only when I was going through a USB HDMI capture device. Direct HDMI worked fine. Not sure why video is flashing so much when not going through the USB HDMI capture device on bullseye when it didn’t happen on buster at all. I’ve got another HDMI capture device I might use to see if it’s something specific with the flasher. Is there some refresh rate configuration difference between buster and bullseye? Same hardware, same firmware, just different OS versions and vice dependencies.

The rest of the document is a bit of a ramble since these versions change all the time but it covers the high level.

To that end, given all the changes that constantly happen in VICE, PI, and such, the video below is no longer 100% accurate. It still covers the general setup tasks, but the script is the source of truth as versions and methods change over time.

Hardware before the Software

This part is pretty simple – you’ll need:

• Raspberry Pi 4 Model B, or Raspberry Pi 3B+
• Micro SD Card (we’re generally at the days of 16GB or higher)
• Micro HDMI cable (or full HDMI if you’re using a Raspberry Pi 3B+)
• Keyboard / Mouse for initial setup, Wifi connectivity for later SSH connectivity.

Write The Raspberry Pi 4 Image

We’ll start with a fresh SD Card and a Raspberry Pi 4. We’re going to burn Raspberry Pi OS Lite (I’m not using a window environment) on to the SD Card using Balena Etcher.

Boot the Raspberry Pi and get connected.

We know our default password is raspberry and our default user name is pi. You should change these if you’re going to keep this install around. Regardless, we need to set just a couple of things before we start with VICE – such as my desire for SSH access so I could copy/paste commands more easily. Here are those steps after you give yourself a good old fashioned sudo raspi-config:

1. Set hostname to vice-pi-install (This makes it unique and through bonjour lets me access it from my Windows PC as vice-pi-install.local.)
2. Set WIFI up to my access point (Country Code and SSID)
3. Allow SPI interface access (my diorama is going to be controlling an LCD through SPI) – This is purely optional – I used it because I’m hooking up some custom circuits to my Pi.
4. Allow SSH interface access (so we can copy/paste from a Windows SSH client) – Optional if you just want to type all the commands directly to your Pi console.
5. Setup locale, keyboard, etc.
6. Verify Internet Connectivity (ping google.com)
7. Perform your normal apt update / apt upgrade commands to update your system.

sudo apt update
sudo apt upgrade

Download and execute the install script

I’ve created a few scripts for various versions to do all this work on a Pi Install. Check the table at the very start of this document for matching scripts to install based on your PI or VICE or PI OS version (Yeah, it can be that twitchy). Download the script you want, chmod +x the script, and run it. Look it over yourself if you’re concerned about just running some guy’s script.

You can execute your script directly by doing this if you don’t feel like downloading it, chmod-ing it, and executing it manually:

wget -O - https://raw.githubusercontent.com/erkrystof/vice/master/<insertscriptnamehere>.sh | bash

What the script does at a high level:

1. Performs the general sudo apt update/upgrade
2. Downloads SDL from libsdl.org
3. Compiles and installs SDL and other SDL libraries
4. Downloads VICE compilation dependencies
5. Downloads VICE source code from sourceforge.net
6. Configures VICE to enable fast-sid options and the x64 ‘old’ binary build (as well as the new binary x64sc)
7. Installs VICE into your home directory (/home/pi/vice-<version-number>) – Because I dislike /usr/local for vice.
8. Binaries will be in the bin directory of where we installed VICE. You’d generally run x64 for the ‘older’ but smoother for PAL Demos binary, or the x64sc (technically more accurate, but uses more CPU and causes PIs to stutter in demos)

The latest version of the script will always be at the link above. It’s configured so if it runs into any error, it aborts.

Why compile SDL on the Pi?

We used to have to do this from a fork from Retropie, and in previous cases before that I could just install the sdl libraries and use those. However, I’ve found that every time I try to do that with the latest versions of Raspi-OS and VICE, I end up getting an SDL related error trying to draw the screen when launching from the console – so for now, I compile the SDL libraries on the Pi and things seem to work. In previous versions of Buster, I couldn’t get this to work from SDL directly, I had to use RetroPie’s fork and manipulations on some videocore headers. I no longer need to do that for what I’m assuming are changes in the OS version over the past couple of years.

We will build SDL2-2.0.14 from RetroPie’s fork that has Raspberry Pi specific modifications. Part of the compilation below is from RetroPie’s SDL 2.0 install script. To learn more about the excellent RetroPie project, head on over to their site here. I’ve made a fork off that repo and that’s where I’m pulling from in my script – it’s just in case I need to make any tweaks.

Apply generic settings for sound/video options in VICE.

See the VICE/PI General Settings I change regardless of version section for that. Also, if you’re in Bullseye, there are some specific tweaks in the Bullseye section to apply.

Download a demo and see it perform horribly or wonderfully?

I downloaded a simple demo from csdb.dk by Booze Design known as ‘The Elder Scrollers‘. Downloaded the .D64 file and uploaded that to the VICE Pi. Moving into the /home/pi/viceinstall/bin directory, I typed ./x64 and was greeted with an old blue friend:

Now, depending on how this all comes together, you might have a really tiny C64 screen in the corner of your big monitor. Simply hit F12, scroll down to Video Settings -> Screen Settings -> Fullscreen.

Noticing stuttering and other issues? Look at the settings in the top part of the document that I apply generically as well as for certain OS/VICE combinations and try those.

Apply settings and watch a demo perform smoothly

Finally, after modifying my settings, restarting VICE, and after autostarting the demo image I downloaded, I was able to sit back and enjoy classic SID sound from the Elder Scrollers demo:

With that, we finish the install of VICE on a Raspberry Pi 4 in console mode as the foundation of my Diorama 64 project. Any thoughts or concerns, things that didn’t work well for you with your install? Leave a comment down below or join the discord at https://discord.gg/wbngTy8 and we can chat. Next up: the Raspberry Pi 4 and the LCD display turned monitor.

Raspberry Pi 3B+ Instructions

** May not work, I have NOT updated this yet for VICE 3.6.1 **

Generally, the build is very similar. I’m going to skip all the discussion points and run down what I think seems to work on a Raspberry Pi 3B. The key differences are how we build SDL. I didn’t seem to need to change any graphic related driver setting to get this to work.

sudo apt update
sudo apt upgrade

#SDL for Raspi-3B dependencies
sudo apt-get install libfontconfig-dev qt5-default automake mercurial \
 libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile-dev \
 libudev-dev libtiff5-dev libwebp-dev libasound2-dev libaudio-dev \
 libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxss-dev \
 libesd0-dev freeglut3-dev libmodplug-dev libsmpeg-dev libjpeg-dev

mkdir ~/sdlwork
cd ~/sdlwork

hg clone http://hg.libsdl.org/SDL
cd SDL

./autogen.sh
./configure --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland \
 --disable-video-opengl --host=arm-raspberry-linux-gnueabihf
make
sudo make install

cd ~/sdlwork

wget http://www.libsdl.org/projects/SDL_image/release/SDL2_image-2.0.5.tar.gz
wget http://www.libsdl.org/projects/SDL_mixer/release/SDL2_mixer-2.0.4.tar.gz
wget http://www.libsdl.org/projects/SDL_net/release/SDL2_net-2.0.1.tar.gz
wget http://www.libsdl.org/projects/SDL_ttf/release/SDL2_ttf-2.0.15.tar.gz

tar zxvf SDL2_image-2.0.5.tar.gz
tar zxvf SDL2_mixer-2.0.4.tar.gz
tar zxvf SDL2_net-2.0.1.tar.gz
tar zxvf SDL2_ttf-2.0.15.tar.gz

cd SDL2_image-2.0.5 
./autogen.sh 
./configure 
make 
sudo make install
cd ..

cd SDL2_mixer-2.0.4
./autogen.sh 
./configure 
make 
sudo make install
cd ..

cd SDL2_net-2.0.1 
./autogen.sh 
./configure 
make 
sudo make install
cd ..

#Interestingly enough TTF builds just fine on the 3B.

cd SDL2_ttf-2.0.15
./autogen.sh
./configure
make
sudo make install
cd ..

#Now, on to VICE for the Raspi 3B

sudo apt install libmpg123-dev libpng-dev zlib1g-dev libasound2-dev libvorbis-dev libflac-dev \
 libpcap-dev automake bison flex subversion libjpeg-dev portaudio19-dev texinfo xa65

mkdir ~/vicework
cd ~/vicework

#3.4 is the latest VICE release
svn checkout svn://svn.code.sf.net/p/vice-emu/code/tags/v3.4/

cd ./v3.4/vice
./autogen.sh 
./configure --prefix=/home/pi/viceinstall --enable-sdlui2 --without-oss --enable-ethernet \
 --disable-catweasel --without-pulse
make -j $(nproc)

# I got an error here for the running of make install - you may or may not need to do the sudo.
sudo make install

#after this point, I went directly to the vice install directory and ran it
cd ~/viceinstall/bin
./x64sc

References:

• Balena Etcher
• Enabling Bonjour for your Raspberry Pi
• VICE Homepage
• Lemon 64 Thread on Custom SDL Build
• SDL on Raspi (for 3B compile)
• Compiling SDL2 from source
• x64 vs x64sc VICE binaries
• The Elder Scrollers Demo

The post Installing the VICE Commodore Emulator for Console Mode on a fresh Raspberry Pi 4 appeared first on Krystof.IO.

10 Year Old Me: Dad, I want a Nintendo!

Older, Wiser Father: Well, Son, I bought you this Commodore 128 Computer instead.

10 Year Old Me: God damn it, Dad (internal dialogue).

There went my hopes and dreams of having a Nintendo – replaced with this many keyed Commodore paperweight. Dad’s goal, unbeknownst to me, was simple – get something that could play games but could also be used to learn about computers. One day I was bored enough to pick up the manual…

I don’t remember which exact program I first built – but I do recall it was making use of the Commodore’s sprite mechanisms – some extremely crude animations and graphics manipulation. Of course, most of the time with the Commodore 128 was spent in it’s ’64 mode’, where almost all of the software library resided.

Nevertheless, thanks to my Nintendo-dodging father, I knew exactly what field I was going to get into in some way, shape, or form, by the time I was eleven. I never had a console beyond the Atari 2600 until I was in my late thirties.

Fast forward through the years and Dad’s ‘spare room’ (or ‘pit of crap’ according to my mother) became the ‘computer room’ as far as I was concerned. Now, in the present, I want to pay homage to that era with a diorama capturing the spirit of that back room. I also wanted to play some of those old games again, along with games I never knew existed at the time.

Birth of a diorama / emulator combo

I’ve put together Raspberry Pi emulator setups before, and I wanted to create one for myself, and I wanted to use this to specifically target my Commodore days. While you’ll see a model of a Commodore 128, anybody who really used one will tell you it spends most of it’s time in ’64 mode’ since it was backwards compatible. So the first thought was a 3D printed case that looks like a Commodore computer to wrap around my Raspberry Pi.

I found a few models online on sites like Thingiverse, an example being this one.

I liked the idea, but I thought maybe I could add something to it – like LEDs? A monitor? A 1541 disk drive to hold an SD Card? This will run the popular VICE Commodore emulator, so I figured a retro case like this to display the Raspberry Pi 4 I was planning to use would be a cool little project to take on. Unfortunately, my brain wasn’t going to let me get off that easily.

My brain goes down a creative spiral.

If I’m going to print a case and a little disk drive, why not a monitor? Instead of that, what about a little computer desk and smaller versions of those components? My mother does 1/12th scale miniatures (1 inch = 1 foot) as a hobby, so I just naturally went with that scale. The more I thought about it, the more I realized trying to rebuild the Commodore setup I had as a child was really the way to go. We (sadly) sold those pieces long ago; I felt building a diorama that captured the spirit of that room was now my goal.

Now I know I’m building a ‘room’, what about those LEDs? Could I incorporate some simple little power LEDs into each component – monitor, disk drives, and keyboard?

If I’m going to build and/or manipulate 3D models to house LEDs for power – what about disk drive activity? Could I have the classic red activity light on a 1541 disk drive turn on when the VICE emulator loads ‘virtual’ floppy disk data?

If I’m going to manipulate power and activity LEDs for the components… what about a tiny LCD screen inside the Commodore 1802 monitor? Could I play animations? Show the ‘READY’ screen? Could I even mirror the Raspberry Pi output?

If I’m going to do all that, I should get some sort of Commodore styled keyboard of some sort to type with so I can use those special PETSCII keys.

The VICE emulator also had some special keys for those common emulator functions, like mounting a virtual floppy image, pausing the emulator, loading/saving emulator machine state, etc. Maybe I could build a little ‘mini-macro’ keyboard to shorten those keystrokes.

I had a few other design ideas that went farther, but this is where I stopped. If I went too far, I knew I’d never get it done. Nevertheless, that was my thought process behind the diorama / emulator combo. I wanted to pay homage to that era as well as have a working emulator.

The Diorama is still a ‘room’

My mother has been creating miniatures for years now – primarily 1/12 ‘dollhouse’ scale. Once I mentioned the idea of the diorama to her, her ‘miniature brain’ (ahem, don’t read that literally) went to work and she built the structure for the room box, carpet, desk, shelves, and even the old rolling chair we had plus some family pets. It really started to feel like this diorama would capture the spirit of the computer room of my youth. What I wasn’t expecting was mixing some ‘old me’ and ‘young me’, as she found a figure, and with some paint in the right spots, created… mini-me.

She created her own prototype of the diorama with a domed room, with myself and my Siamese Luna enjoying what little air is left under this glass by playing some Pac-Man (which I’d be replacing with Commodore specifics).

Making The Mini Commodore Parts

Taking a few models from Thingiverse (the series article on the modeling will have the details), and modifying them for some future LED wiring, I went to work recreating the system we had – A Commodore 128, two 1541 drives, and a monitor. I also went about creating some floppy disks which you can see below, though I ended up making them thinner later.

After slimming down those floppies I created envelopes resembling some of the makers I remembered from my youth – Commodore branded floppies, BONUS, Elephant, Maxell, and Verbatim. You may also recognize an EA branded floppy envelope from the days where EA was ground breaking and universally adored.

A ‘living, breathing’ Commodore.

The LED related goals of the diorama: Power LEDs and drive activity LEDs that match our VICE emulator install. When you load a virtual floppy in VICE, I want the drive 8 LED to light up. That requires a customization we’ve made to VICE itself (details in the series article), but it all has to come together connecting to the Raspberry Pi, a custom circuit board, and power. Needless to say, the breadboard came in mighty useful during this endeavor.

Also, I wanted the 3d printed monitor to work as an enclosure for a small LCD that mirrors the HDMI output of the Raspberry Pi – here’s the initial capture I took when it somehow didn’t melt upon plugging all of it together:

Twitching The Progression

I decided to clean up the work space a little bit and get the Twitch stream going. Figured I’d work on this and if anyone decided to stop by and chat about it, they could. In fact, they did. So far I’ve met a few interested in the old Commodore retro scene, some more on the electronics side of the circuit, and some just curious as to what the hell I’m doing.

Diorama/Emulator Parts Breakdown

This diorama / emulator combo breaks down into these major components, and thus the series articles for more detail follow this list. As I wrap up each one I’ll post the links here for posterity.

• Raspberry Pi 4 – The heart of the electronics – this runs the emulator as well as drives the circuit controlling power and drive activity LED’s. You can now see more on the VICE and OS install here: https://krystof.io/installing-the-vice-commodore-emulator-for-console-mode-on-a-fresh-raspberry-pi-4/
• LCD display – this mirrors the Raspberry PI’s HDMI output, so as the big-me plays games, the mini-me in the diorama is playing the same game – or is it the other way around?
• LED circuit board – This reads GPIO pin inputs from the Raspberry Pi and switches on the power and drive activity LED’s. I also decided to try out a simple ‘Power’ button to ease the shutdown of the Raspberry Pi.
• 3D Printed Commodore Models – Modified and scaled accordingly, printed in resin or filament, and painted by hand (crap-fully)
• Custom VICE build and LED driver software – I created a custom VICE build to get my hook into the floppy drive activity and get that state sent to the LED circuit – so when VICE considers a floppy drive active, my LED circuit turns the LED on or off accordingly.
• Diorama Room containing models of our old computer desk, floppy disk holders, game boxes, and wall art I would hang in the computer room or my bedroom over the years.
• Input Peripherals – I need a keyboard to type on and joysticks to … joy with.
• Custom Keyboard Deck – This keyboard of 10 keys controls common emulator functions (mount floppy image, pause, restart emulator machine, etc.)
• Diorama case ‘base’ – where we’re going to store the electronics of this diorama/emulator combo – underneath in a 3 inch tall base for the diorama to rest on.

There are some parallel threads in the series here – I worked on many pieces at the same time – and you could to if you were recreating it. Nevertheless, here’s how the series is presented – and I’ll do my best to keep this cohesive.

Series Breakdown

As I upload articles and videos, this list will be updated and links created. Stay tuned!

1. This entry – the overview and motivation – Released Jan 4 2020
2. VICE on the Raspberry Pi 4 Install – Raspberry Pi 4, VICE Compiling – Released Jan 12 2020
3. Raspberry Pi 4 and ST7789 LCD Install – How to get frame buffer copying and display rotation working. – Released Jan 19 2020
4. Custom VICE build and Python Shared Memory – Using Linux shared memory to communicate between VICE and Python to drive the proper drive activity LEDs – Released Feb 15 2020
5. Controlling LEDs from a Raspberry Pi and a Darlington Array – Isolating the power driving LEDs and building the LED circuit
6. 3D Modeling the Commodore Computer – Modifications to support LED housing and wiring, painting, and decals
7. Input Peripherals – Keyboard and Joysticks and some alternate considerations
8. VICE Custom Keyboard Deck – Using an Arduino compatible Teensy to act as a USB HID Keyboard
9. Diorama Room – It’s not a diorama without some background items and finishing touches.
10. Diorama Case Base – Final touches and assembly of the diorama.
11. Retrospective – Looking back as we moved forward through this series.

The post The ‘Working’ Commodore 64/128 Diorama and Raspberry Pi VICE Emulator appeared first on Krystof.IO.

Step 1 – Install pmount

pmount is a wrapper around the standard mount program which permits normal users to mount removable devices without a matching /etc/fstab entry. This is how we’ll manage to auto mount our USB drives.

sudo apt install pmount

Step 2 – UDEV Rule

Udev allows for rules that specify what name is given to a device, regardless of which port it is plugged into.

sudo vi /etc/udev/rules.d/usbstick.rules

ACTION=="add", KERNEL=="sd[a-z][0-9]", TAG+="systemd", ENV{SYSTEMD_WANTS}="usbstick-handler@%k"

Step 3 – Create Systemd service

sudo vi /lib/systemd/system/usbstick-handler@.service

[Unit]
Description=Mount USB sticks
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/automount %I
ExecStop=/usr/bin/pumount /dev/%I

Step 4 – Create Mount Script

sudo vi /usr/local/bin/automount

#!/bin/bash

PART=$1
FS_LABEL=`lsblk -o name,label | grep ${PART} | awk '{print $2}'`

if [ -z ${FS_LABEL} ]
then
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}
else
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${FS_LABEL}_${PART}
fi

sudo chmod +x /usr/local/bin/automount

Step 5 – Should be working, but if not…

You’ll see your USB drives mounted under /media

Per the comment from James:

And rather than reboot, UDEV should automatically detect new rules[2], but if it fails to:

udevadm control –reload

If that doesn’t work… you can always try turning it off and on again 🙂

References

• pmount
• Stack Exchange Post

The post Auto mounting a USB drive in a Raspberry Pi appeared first on Krystof.IO.

With the control panel layout finalized, I test fit everything together. I wish I took more pictures along this stage, but unfortunately I did not. Next project I will have to snap more photos. I was originally intending a flashing Tardis light up on top, then just went and cut a ventilation hole up there instead, totally forgetting about the light fixture. Ah well. I still wired up my Raspberry Pi with a script to drive two LED lights embedded in the speaker holes to pulsate with the Tardis ‘Whoosh!’ sound when the machine boots up, so it all worked out well enough.

I designed and printed off the Marquee at home, overlaying the Doctor’s name in Gallifrey on top of the ‘Pop’s Arcade’ in a Doctor Who style font. Behind the marquee is just a flat panel of wood with 2 soft white 12 volt LED strips from my old RC airplane days. I printed two copies of the marquee and laid them over each other, which not only fought off light washing out the print but also gave a slight effect of depth to the words which I really liked.

Unfortunately I only have a inkjet and not a huge plotter, therefore at certain angles you can see where joined the two marquee halves together. There are printing companies online that will do full pieces, and I’ll heavily consider it next time around.

The Control Panel piece is hinged so it lefts up and towards you to get access to any wiring necessary, and the original plans I found (see first post) were adjusted to add more height for a keyboard tray. The very back of the arcade opens up to reveal the monitor mounted on a horizontal length of wood, with the power supply, wiring, and raspberry pi secured inside.

Now that it’s put together, tear it all down

I assembled most of it at this point except for the raspberry Pi and controls. This way I knew the wood came together as it should before I took it into the garage for painting. I haven’t done a lot of routing in my life either, so I was opting for white edge banding compared to arcade T-Molding. While the T-Molding really looks great and smooths edges out nicely, I figured I’d save that wood working struggle for a later time.

So, taking each piece downstairs, it was time to sand and prime.
Not having access to anything near a professional painting setup, just a garage with some Krylon Fusion and some sand paper, I got down to business. I was surprised and happy overall with how it turned out, and while I read that I could have just started painting, I’m really glad on how the primer helped the paint attach and how smooth 95% of the surfaces felt when I was done.

It was around this time between painting breaks that I worked on the acrylic control panel overlay. Measuring out the acrylic to match the control panel was easy. The cutting of the holes for the acrylic proved to be more of a challenge. I didn’t want to just use a spade or forstner bit. I tried to practice with scrap acrylic knowing it would be a struggle and it surely was. So when it came down to the actual cutting of the holes for the buttons and joystick to fit into, I opted for a step bit on the acrylic whereas I used the forstner bit on the control panel wood.

A Milwaukee #9 7/8 in. and 1-1/8 in. Step Drill Bit, to be exact. Taking it slow into the circles and spots I drew on the acrylic outer plastic wrap (leave that on while you drill!), I couldn’t have asked for an easier cutting experience with acrylic. Once the piloting hole was drilled through, this thing literally fell through the acrylic like butter, step by step. Take it slow, take it easy, and with the 1 1/8″ maximum width of the bit matching my desired hole size, I didn’t have to worry about it sliding further and making a larger hole than intended. After I finished drilling all of the holes in the acrylic, I noticed only one small crack that was hidden by the button chrome anyhow. After drilling that many holes I was more than accepting of that outcome. Expensive as it may be, it’s my go-to for acrylic hole drilling from this point forward.

I found some Tardis schematics online and printed them out on a high gloss inkjet paper. Trimming those the control panel board, I was able to complete the acrylic/overlay/control panel sandwich. I manually traced the circles through with the paper and cut them out by hand, however. Drills and paper are extremely strange bedfellows, in my opinion.

After the paint dries…

It’s time to take it all back upstairs and put it all together.

While C slept one morning, I was edge banding my life away after finally getting the painted pieces re-assembled. While I’m glad I used a hot iron to affix the edge banding, it sure is a delicate process. Compared to T-Molding, however, I think it came out fairly well with only a few spots to touch up or re-cut afterward.

So at this point, it was really ready to go except for one last piece. The side art. An arcade machine should have something on the side, and I’ve got a ncie control panel, cool lit up Marquee, but nothing yet for the side art. I struggled with the idea of printing a large background on paper and having to line up each piece… Or something on adhesive ink jet vinyl… or a poster of some sort.

C had a great idea that left a lot of the nice ‘Tardis Blue’ paint I found revealed but also gave her a creative outlet with that Silhouette cutter. She searched around for various members of the Dr. Who rogue’s gallery and started cutting outlines on adhesive backed vinyl. Here’s the spectacular result:

Even the piece above the keyboard tray got some K-9 action:

When it’s all said and done…

I love how it turned out. I love that it was challenging for me on numerous levels, from hardware, woodworking, painting, graphics, software, joystick controls, lighting, and even some electrical work, as a LED switch plug and cutting apart a surge protector was not something I’d ever thought I’d be doing. I love that I was going to be able to present this as a gift to my Dad, and we could relive gaming on three separate platforms all over again, from Atari 2600 to Commodore 64 to your standard IBM PC.

It may not be the perfect build, but it’s the all the effort that goes into a handmade gift that really makes it special. As much as this was for Dad, I give credit to Mom for holding a secret for so many months.

When we took it over to my parent’s house, it was underneath a sheet and sitting on the coffee room table. He had only one guess that he could come up with what was sitting underneath the cloth: a gun rack. His expression when I lifted up the sheet, however, was priceless. The first thing he asked after looking at it from various angles was ‘What is it?’ ‘Well, Pop, it’s your very own arcade machine.’ ‘Well yeah, but… it works?’

I powered it up into it’s start up sequence – a Tardis flying through space and the words ‘Welcome To Pop’s Arcade’ flying right along with it, Dr. Who theme music and all. He was completely enamored and taken aback by the whole thing. When you hear the words ‘I don’t think you’ll ever be able to top this gift and what it means to me that you made this’, I felt overjoyed that we could relive a little of our gaming history together again and that he loved how it turned out.

In fact, that’s what we did for the next two or three hours. Playing Heretic on my laptop connected to his Tardis Arcade via LAN meant that once again, after 20 years, I could turn him into a chicken with the ‘Morph Ovum’ spell, and he could, somehow, manage to figure out a way to peck me to death.

Visit the Tardis Gallery for all images.

The post The Tardis Themed Arcade Comes Together appeared first on Krystof.IO.

So I started browsing around for DIY arcade designs, as I wanted to make this myself, and hopefully not lose a limb in the process. The two people I would have asked for help, Salazar and Pops, I could not ask… As I was also building a retro PC for Salazar as well. So any woodworking would be my first and mine alone. Still have all my fingers, so I must have done something right.

Ordering a game at the bar…top

There are numerous designs for your own DIY arcade. Cocktail, Bartop, Standup, Showcase… Bartop ended up winning for my gift for Pops – I could put it on his bar downstairs (if I could convince him to stop using it as a storage area, but if Mom can’t do that, I doubt I’d be able to) or even a desk. I searched numerous designs, but found this instructable by rolfebox that fit my bill for the most part:

The plans are great, and I followed them not to the letter, but more to the word. I knew I was using at least these components:

• Raspberry Pi Internals
• Acer VS228 LCD Monitor
• Joysticks and Buttons
• Keyboard and Mouse accessible (we played a LOT of Heretic, Hexen, and Doom)
• LED Lights for Marquee
• LED lights for startup sequence (I wanted to add the Tardis Whoosh!)

I wanted to make sure all of these would physically fit with the plans above. They wouldn’t right off the bat, you could see above there is no keyboard tray, and the monitor used is smaller than the one I wanted. There are two main conclusions to draw from this:

• Be ready to modify any plans you find for your own purposes. Print them off, tape them together, or take them to your local printer and print them at scale. Your hardware needs to fit, and if you don’t have exactly every single piece used in an example you find, you may need to adapt measurements.
• Make a cardboard mock-up of your final plans before you cut any wood. I can’t stress that enough, so I’ll probably say it again in either this sentence or the Make a cardboard mock-up of your final plans before you cut any wood. — well, there it is. You can measure the width and height of your display and make sure the cardboard mock-up fits, as you can see in the featured photo at the top and below:

No Guts, No Glory

So now that I have the plans I wanted to base the arcade build upon, had a separate thread in my head of what was going to be inside. While I’m used to keyboard and mouse gaming on a PC, a DIY Arcade’s spirit demands joystick and button glory.

This was a difficult decision. You can make this as cheap or expensive as possible. You could buy your own joystick, your own buttons, your own controller, and wire each one yourself. I’ve been down that road, and was getting tired of the soldering iron. While it would have helped my soldering skills, there was a balance between exactly how much Y I wanted to put in the DIY. I was already building the cabinet, I figured I’d at least purchase some wiring harnesses instead of cutting, crimping, and soldering each connection individually.

So, a pack of hardware suited me best. I opted for this package from Game Room Solutions

You get essentially everything you need to use arcade hardware in your RetroPie arcade setup. It’s also, due to the USB controller shown, not limited to the your Raspberry Pi.

A shell of an arcade

Off I go to Home Depot. Tools, Lumber, Glue, Brackets. I’ve measured out the cardboard prototype and just had to figure out the material I’d use to create this monstrosity. I searched for a few options available to me, and they came down to two in the end:

• Plywood – This is what I ended up going with. 3/4″ thick Maple or Birch Plywood. It may be heavier, and I could have probably gone lighter, but I wanted stability and some room for error. I could still sand and paint this later as well. You’re looking for furniture grade in my opinion. Cheaper is not necessarily better, but your mileage may vary.
• MDF – I felt it would be heavier than the plywood I chose (even though my plywood was heavier than thinner plywood by comparison), but there were two aspects of MDF that gave me pause. Toxicity and Screwing. (Oh man, I used ‘anal’ in another post, now I’ve got screwing? It’s all downhill from here) MDF is quite toxic when you’re cutting it, as it’s formed by taking wood pulp and pressing it down with a generally formaldehyde based resin. That’s in the air when you’re sanding and cutting. Plywood itself can be bad enough, so toxicity was a big no for me as an amateur. Screwing is the next point – once you screw into MDF, it tears fibers apart to make room for the screw. You can screw into MDF once, where a wood screw in plywood can handle more room for error. You can use pilot holes and MDF screws to counteract this, but I wanted to get this project moving along.

Once again, as a total novice in woodworking, I chose the option with more give and take and less chance for killing myself with. Both are very viable choices, it comes down with what you’re more comfortable with.

I started turning my garage into a wood working nightmare. At least if I ever do anything with wood again, I’ve got tools and sawhorses for it. I was so ready, can’t you tell?

“One person’s craziness is another person’s reality.” Tim Burton

Control? Come in, Control.

While there was woodworking going on, there was also some wiring of the guts together before anything was actually placed inside. These DIY projects tend to have multiple threads going at once, and I wanted to make sure the parts would work together. I highly recommend prototyping your control panel just like we made a cardboard mockup of the shell for no other reason than seeing something come to fruition early to keep momentum going, and give you a break from one part of the project to work another. Wiring up a control panel let’s you gauge sizing issues, determine layout, and hook all your guts up while you spend time configuring the software side (i.e. your joystick controls and your system / emulator / game play)

You could use very thin project board, scrap plywood, whatever. The Control Panel is by far the most important component of the external interface to your arcade. Consider button layout very carefully. Once you drill holes in wood, you should already have a good idea of button placement. An excellent resource for layout styles and history is is Slagcoin, and search DIY arcade forums as well like the Arcade Controls Forum

I opted to make mine out of spare foam poster-board. It was just sturdy enough to hold all the components together:

You may notice the markings on the buttons. They weren’t there when I got them. Another piece of hardware I purchased for this endeavor, and has been used quite a lot by C and myself for other projects is a Silhouette Portrait cutter. Works like a printer, cuts paper and adhesive vinyl, and that’s what I used to create the button labels – the nice thing is that they’re underneath the top button casing, no fingers working against the vinyl over time:

Things were starting to come together – mock-ups created, wood and plans finalized, and control panel wiring designed and tested with the Raspberry Pi. Now to actually make the cuts and start putting this thing together.

The post The Tardis Arcade Hardware Invasion appeared first on Krystof.IO.

A slice of retro

Last year I was using a Raspberry Pi to measure pH shifts in my aquariums that naturally occur from CO2 injection. I just received one of the newer Pi-2 Model B‘s and asked my self what next? What can I do with this thing? Searching on google for raspberry pi projects, I came across a wonderful little project called RetroPie. Retro gaming on this little credit card sized computer? Consider me signed up. As an aside, there’s numerous projects like this for the Pi, such as PiPlay

What is RetroPie? It’s essentially a project that integrates required components to launch, emulate, and gather meta-data about any ‘retro’ games you might install. It’s a large endeavor as it attempts to make the setup as simple as possible, and given that while it may only use one front end, there are many emulators necessary to make this happen, depending on what you want to support.

The Front side

Underneath the project wrapper itself, you’re looking at a simple yet elegant front end known as Emulation Station. Not just for your Linux Pi installs, Emulation Station works on Debian Linux and Windows. You don’t technically need a front end to play a game, but it surely helps. An emulation front end separates you from having to remember which emulator to play which game, how to launch it, how to configure it, etc. While there are as many front ends as there are emulators, Emulation Station is a good fit for the RetroPie project as it looks sleek but covers your basic needs of wiring menu to emulator to software. Even more important is the RetroPie script that just installs this all for you.

EmulationStation acts as your interface to select the game you want to play. As such, it supports various control mechanisms, from keyboards to joysticks, even your classic arcade controllers if you can wire them in yourself or they’re USB compatible.

Also included is a scraper. You’ve wired up a game you’ve saved onto your Pi, perhaps by taking that old floppy drive from your Commodore 64 and interfacing it with your Linux machine by writing your own drivers and wiring your own connection interface, right? No? Me neither. The task of collecting ROMs or Disk Images isn’t here, so move along. I’m assuming you’ve got some already. Ah yes, the scraper. Sure, you can add ‘Panzer’s East!’ as a menu item in Emulation Station to use the Vice emulator. But what about at least a little flair? Some box art? Some text describing the game? That’s where the scraper comes in. Scanning open and internet based databases containing game information and pointers to images, scraping turns your emulation station front end into more eye candy than you had before. I like that idea, though when I played around with Emulation Station I ran some scrapers as scripts in the background, as the embedded scraper seemed to be slow and a bit clunky to use, but perhaps that has improved.

The Back side(s)

RetroPie takes best of breed emulators for various gaming platforms and installs them all with default configurations. These emulators cover a wide range from Apple to NES, from MAME to Commodore, from Sega to Atari. These emulators, through the power of the RetroPie script, are wired into Emulation Station for you, no explicit configuration required unless you feel like tinkering.

While there are experimental builds of some emulators, the defaults generally work well out of the box, and some emulators are patched with the Pi in mind, taking advantage of certain pieces of Pi hardware or patched to work with the limited power the Pi has compared to a full desktop system. It’s a little give and take. While most of the early console systems worked well for me, DOSBOX emulation started to struggle. Since I’m a child of the 80s, a lot of my stuff was covered, but I also gamed into the 90s, so a lot of my DOS and early Windows games would need emulation on something with more oomph than a Raspberry Pi 2 Model B. (The first generation Pi does work with RetroPie, but it suffers on the console side a lot more than the Pi 2).

If you’re used to tinkering with Raspberry Pi’s, you already know about images. The RetroPie project has you covered there and if you follow along and are already comfortable with the basics of Raspberry Pi usage, you’ll be fine. I wouldn’t recommend it as your very first Pi Project if you’ve never used one and never touched a Linux/Unix OS before. That’s more akin to hitting the ground hurtling instead of running, in my opinion.

Pi installed, let’s play!

One of my favorite games from the days when I had a Commodore 64 was a strategy game by Avalon Hill called ‘Panzers East!’. You’re the Axis powers and you must take out Russia before winter sets in, and you must utilize your Luftwaffe and supply lines to keep the pressure on while maintaining your ground.

My father and I played the crap out of that game. I could open that old game box if I still had it and there would be zero crap in there. He was Panzers and infantry, I was Luftwaffe. My mother had access to a copy machine (Yeah, I’m old) so we blew up the 8 1/2″ x 11″ map to fill the wall behind the old Commodore 64. This map, to be precise:

To this day, I still remember cringing every time I saw the phrase ‘Insufficient German troops, Russians retake Bessarabia’. God damn it, not again!
There it is, on a Raspberry Pi, running the Vice emulator launched by Emulation Station.

It was right about this point I knew I’d end up not only having a RetroPie emulator, but I’d actually try and build an arcade box out of this, because I knew I wanted Pops to have one. I couldn’t just hand him over a bunch of wires and an HDMI cable and say ‘Hey, let’s play a game!’.

So I knew I was going to make something to house a raspberry Pi in. I just didn’t know how far I’d go and what it would actually be. I just knew it was for Pops and it would be special. It wasn’t until I was past prototyping that I thought… “Tardis“.

The post How A Tardis Themed Arcade Build Began To Take Shape appeared first on Krystof.IO.