I’m a big fan of Octoprint, and in the past I used it on a couple of Raspberry Pi computers, one instance per Pi. Those things are harder to come by these days, so as I try to get my 3d printers up and running again after a long hiatus in storage, I wanted to try to take one cheap Windows Mini-PC and see if I could install Linux on it and utilize Docker to have multiple Octoprint instances, one for each printer, all running on one PC. Each 3D Printer will also have a webcam attached. I also wanted to use an external Wifi Adapter as the built in adapter on the Mini-PC didn’t have as much power. So those are the goals:

• One PC to handle three printers
  • One Octoprint instance per Printer
  • USB Powered Hub to expand available ports
• Each printer has a webcam
• External WiFi Adapter (better than the internal)
• Docker containerization for ease of setup / config

This article serves as the general build and install log of that setup. It covers the basic install of Ubuntu, Docker, Octoprint, and some USB UDEV rules so we can make sure the printers and webcams always run under the expected device names.

Wiring Connections

The Mini-PC I have has two USB 3.0 and two USB 2.0 ports. I’ve got to hook up three webcams, three printers, and an external WiFi adapter, so that’s already 7. So I had one six port powered USB 3.0 hub, which I wanted to attach the 3D Printer related stuff to, use the other USB 3.0 port for the WiFi adapter, and then have the other two ports open as needed. That was the goal at least, it didn’t work out that way, but close. I had to remove one camera from the hub and use one of the USB 2.0 ports for it (perhaps I was maxing out the hub with video?). Nevertheless, that at least left one port open for something else someday. It’s going to be a headless system for the most part.

Mini-PC Linux Software and Config

This was fairly straightforward for the install side. Downloaded the latest Ubuntu server image (could have done desktop, but it’s a headless system), used Balena Etcher to pop it on an SD Card, then shoved that card right into the Windows Mini PC and started the install (wiping out everything). Once that was done, I installed open ssh (if it wasn’t installed as part of the initial OS install) so I can just use Putty to connect via my main PC for ease of copy/paste.

WiFi Adapter Compile and Install

More optional than anything, since this is an adapter that doesn’t have direct Linux support at this time. It’s better than the internal one my PC had though, so I’ll be using it. It’s the Alfa AC1900 WiFi Adapter and it requires special but easy handling.

Copy of the documentation from their website: https://docs.alfa.com.tw/Support/Linux/RTL8814AU/

sudo apt update
sudo apt install git build-essential
git clone https://github.com/aircrack-ng/rtl8812au.git
cd rtl8812au
make
sudo make install

After that I did a recycle, still wired in. I had to update my netplan config to take the new settings for the new adapter.

My internal adapter on the PC (that sucks), was named wlp2s0. But I need the name of the new adapter, so to get that…

sudo lshw -C network

This gives me the output of network adapters, and I can see a new one beyond my default internal, which should be the adapter we just compiled drivers for:

*-network DISABLED
       description: Wireless interface
       physical id: 8
       bus info: usb@1:3
       logical name: wlx00c0caaedc2d
       serial: .....
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=rtl88XXau driverversion=5.15.0-72-generic multicast=yes wireless=unassociated

The logical name wlx00c0caaedc2d is what I’m interested in. Now I’ll edit the netplan config to set both ethernet and wifi as optional interfaces and get the adapter ready to connect to my SSID.

sudo vi /etc/netplan/00-installer-config.yaml

That may bring up some default networking stuff. I pretty much replace it with these contents:

network:
  ethernets:
    enp1s0:
      dhcp4: true
      optional: true
  wifis:
    #    wlp2s0:
    #  optional: true
    #  access-points:
    #    <SSID>:
    #      password: <PASSWORD>
    #  dhcp4: true
    wlx00c0caaedc2d:
      optional: true
      access-points:
        <SSID>:
          password: <PASSWORD>
      dhcp4: true
  version: 2

After that we apply the settings with sudo netplan apply and we’re off. I can see the adapter light blinking. I reboot with the network cable disconnected to make sure I can still connect via WiFi.

USB and UDEV rules

I want to set some UDEV rules so that we know exactly the USB ports our devices are being plugged into (included devices attached to the powered hub I bought), so that I can create aliases accordingly (i.e. I want to use /dev/ttyPrinter1 and /dev/videoPrinter1 and so on instead of assuming /dev/video0 is always the first camera.)

To do this, I open up an SSH session and type:

udevadm monitor

This will now spit large walls of text every time I plug something in or take something out of USB ports. I plugin the hub, and figure out which ports I’m going to use for which printer. The goal here is to grab the right ‘port identifier’ and use UDEV rules to map that consistently to the right device name. I will always plug the printers/cameras into the same USB ports. So I used a simple video camera and went from port to port, copying down the key line that shows which identifier the system uses for the specific port I just plugged into. You’ll see a bunch of lines, but look for the one that defines a video device like /dev/video0 and then look to the left of that line. You’ll see text like this, which I copied down into a notepad session:

...
/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.2/1-4.1.2:1.0/  (printer-2)
...
/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.1/1-4.1.1:1.0/  (video-printer2)
...
/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4:1.0/  (printer1)
...
/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.3/1-4.3:1.0/  (video-printer1)

As I move the camera from port to port I see which key identifiers change (see the 1-4.1.2:1.0 becomes 1-4.1.1:1.0, or 1-4.4:1.0 as I move down the line)

I use those identifiers to build the udev rules file. I store mine in /etc/udev/rules.d/01-krystof-usb.rules so here are my contents (as root):

SUBSYSTEM=="tty", KERNELS=="1-4.4:1.0", SYMLINK+="ttyPrinter1"
SUBSYSTEM=="tty", KERNELS=="1-4.4:1.0", RUN+="/var/lib/docker/composers/octoprint/restart-octoprint.sh octoprint1"
SUBSYSTEM=="tty", KERNELS=="1-4.1.2:1.0", SYMLINK+="ttyPrinter2"
SUBSYSTEM=="tty", KERNELS=="1-4.1.2:1.0", RUN+="/var/lib/docker/composers/octoprint/restart-octoprint.sh octoprint2"
SUBSYSTEM=="tty", KERNELS=="1-4.1.4:1.0", SYMLINK+="ttyPrinter3"
SUBSYSTEM=="tty", KERNELS=="1-4.1.4:1.0", RUN+="/var/lib/docker/composers/octoprint/restart-octoprint.sh octoprint3"
SUBSYSTEM=="video4linux", KERNELS=="1-4.3:1.0", ATTR{index}=="0", SYMLINK+="videoPrinter1"
SUBSYSTEM=="video4linux", KERNELS=="1-4.1.1:1.0", ATTR{index}=="0", SYMLINK+="videoPrinter2"
SUBSYSTEM=="video4linux", KERNELS=="1-8:1.0", ATTR{index}=="0", SYMLINK+="videoPrinter3"

The printers use subsystem TTY, and the videos use subsystem video4Linux. The “KERNELS” argument is where I put those uniquely changing identifiers from watching udevadm monitor running, and the actions afterwards are what we want to do with that device when it’s plugged in. For my case, I want to create a symbolic link under /dev/ for the printer. (I could have named them towards the printer model, but some of my models are the same so I just went with printer1, printer2, etc. – You could easily put A B C, BobsPrinter, DavesPrinter (even if Dave’s not here), etc.

You’ll notice the lines are duplicated for the printers and then there’s a RUN option. That executes a script for docker later when the printers are plugged in. It attempts to restart the docker instances of OctoPrint when the printer is disconnected and reconnected (sometimes it OctoPrint in a container can’t detect that very well, so we basically perform a restart). That script looks like this if you want to use it (if you don’t, remove those lines) – Obviously those scripts don’t exist yet but will after I set up docker.

#!/bin/sh
sleep 10
docker stop $1
sleep 10
docker start $1
exit 0

To apply the UDEV rules, and make sure there aren’t any errors in the config:

sudo udevadm control --reload-rules && sudo udevadm trigger

You can see if it works by connecting one printer or video camera to the hub you wrote down your identifiers for and put into the rules. If you plug in the right device to the right port, you should get a /dev/ttyPrinter1, or /dev/videoPrinter1 device available:

#Plugged the printer into USB port designated for printer 1:
erkrystof@pc-octoprint:/etc/udev/rules.d$ ls /dev/tty*Pr*
/dev/ttyPrinter1
#Unplugged the printer from USB port that I designated for printer 1 and put it in printer 2:
erkrystof@pc-octoprint:/etc/udev/rules.d$ ls /dev/tty*Pr*
/dev/ttyPrinter2

Docker and the OctoPrint Containers

Followed the standard docker install for Ubuntu:

https://docs.docker.com/engine/install/ubuntu/

I also like to use Portainer, but that’s entirely optional for you (it’s a web admin interface for Docker containers)

https://www.portainer.io/install

Once docker is installed, we need to create the docker-compose.yml file. I like to put mine under /var/lib/docker/composers/octoprint. (I created the directory as root). I use the ‘official’ OctoPrint image, which I’ve had no issues with thus far in its current state. Read that page over to better understand what is happening below.

sudo vi /var/lib/docker/composers/octoprint/docker-compose.yml

version: "2.4"

services:
  octoprint1:
    container_name: octoprint1
    image: octoprint/octoprint
    restart: unless-stopped
    ports:
      - "8001:80"
    devices:
      - /dev/ttyPrinter1:/dev/ttyUSB0
      - /dev/videoPrinter1:/dev/video0
    volumes:
      - ./octoprint1:/octoprint
    environment:
      - ENABLE_MJPG_STREAMER=true
      - MJPG_STREAMER_INPUT=-n -r 1280x720
  octoprint2:
    container_name: octoprint2
    image: octoprint/octoprint
    restart: unless-stopped
    ports:
      - "8002:80"
    devices:
      - /dev/ttyPrinter2:/dev/ttyUSB0
      - /dev/videoPrinter2:/dev/video0
    volumes:
      - ./octoprint2:/octoprint
    environment:
      - ENABLE_MJPG_STREAMER=true
      - MJPG_STREAMER_INPUT=-n -r 1280x720
  octoprint3:
    container_name: octoprint3
    image: octoprint/octoprint
    restart: unless-stopped
    ports:
      - "8003:80"
    devices:
      - /dev/ttyPrinter3:/dev/ttyUSB0
      - /dev/videoPrinter3:/dev/video0
    volumes:
      - ./octoprint3:/octoprint
    environment:
      - ENABLE_MJPG_STREAMER=true
      - MJPG_STREAMER_INPUT=-n -r 1280x720

Since I’ve got three printers, and three webcams, I have three entries. Easy enough.

So then we could run the compose command from that directory (as root):

docker compose up -d

Now, if I do this without having the USB cameras and printers connected via USB, none of the instances will actually start. Each OctoPrint instance expects a video camera and tty device now before it will start. See how we map our well known aliases to /dev/ttyUSB0 and /dev/video0 for every single instance? That allows us to create multiple OctoPrint installs, but utilize different USB devices. The UDEV rules helped us map ports to well known aliases.

At this point, I hooked up the printers and video cameras to the Linux PC, recycled everything to make sure all was good there, then I ran docker compose up -d. After that, I was able to hit the web interface on each instance at http://pc-octoprint.lan:8001 through 8003. (Your hostname may vary, that’s up to you).

Now underneath our composers directory we’ll have the three OctoPrint install directories designated under the volumes section.

Key notes on some settings in OctoPrint come from the OctoPrint Docker image page:

Webcam Setup in OctoPrint

Use the following values in the webcam & timelapse settings screen of the initial setup:

Container Environment based configs

There are configuration values that you pass using container --environment options. Listed below are the options and their defaults. These are implicit in example docker-compose.yml, and if you wish to change them, refer to the docker-compose docs on setting environment variables.

I tested the recycle script as well, so if I physically disconnect and reconnect, the docker instance tied to that port is recycled.

References

• https://www.reddit.com/r/octoprint/comments/mouzdf/ive_been_testing_running_multiple_instances_of/
• https://www.reddit.com/r/octoprint/comments/p3dk12/guidetutorial_multiinstance_octoprint_on_a/
• https://hub.docker.com/r/octoprint/octoprint

The post Octoprint with Multiple Printers on One Ubuntu Linux Mini-PC appeared first on Krystof.IO.

What is MiSTer FPGA?

I like to think of MiSTer FPGA as hardware emulation vs the software emulation I’m used to. The MiSTer suite of cores and utilities are designed to be installed on the Terasic DE10-Nano FPGA board, and various add on boards to support more USB components or video/audio output. MiSTer FPGA is a project that coordinates different ‘cores’ (e.g. old computer systems or game consoles) and applies them to the FPGA board, effectively instructing the FPGA board to act as the chipsets of these old retro computer and console systems.

FPGA itself stands for ‘Field Programmable Gate Array’. It is a type of integrated circuit that can be programmed by the user to perform specific functions. So think of it like a blank slate chip that you can program to act as another chip. That’s how we do the hardware emulation. Since this reprogramming of the chip can happen without having to manufacture a new chip, we can use the term ‘Field Programmable’ – you can reprogram it in the field, outside of a chip manufacturing plant.

Why MiSTer FPGA?

I wanted to try MiSTer FPGA because I’ve never messed with hardware emulation. It’s always been on the real deal or with software emulation (like DOSBOX or VICE). My understanding is that lag is nearly non-existent when compared to emulators, and the ‘cores’ (the systems we’re emulating) run more true to the original hardware than their software emulating counterparts. Want to know some of the cores directly supported? Check out the core list here.

My motivation for doing this is because while I like to have genuine retro systems of the old systems I had as a child, I don’t care to try to own an Apple IIe, or an Atari ST. I was a Commodore guy, so while I want to tinker with those systems, I definitely don’t want to hit up e-bay and start trying to build my own piece-by-piece setup for a system I never owned or had no vested interest in. (See how I through that line in there? I never owned a Commodore PET, but I wouldn’t turn a free one down)

The MiSTer Wiki page has excellent information, tutorials, and references.

The Parts List

So from the hardware standpoint, we need at a minimum the Terasic DE10-Nano board. This is the specific model of FPGA board that the open source MiSTer FPGA project software (Mr. Fusion) expects to be installed on, so it’s a must. After that you have all sorts of add ons and adapters (adapters to even hook up old console specific adapters like light guns) to enhance your retro gaming experience. I went with the following (links to where you could find them included – not necessarily the only place, but at least one place)

• Terasic DE10-Nano board – The bare minimum as stated above. I ordered mine from Terasic directly.
• USB Hub V2.1 for MiSTer – This gives us more USB ports to connect keyboards, mice, joysticks, etc. to the Terasic board. It’s a powered HUB that is designed to mount underneath the Terasic. It comes with a splitter power cable to split your power supply between the USB board and the Terasic (but if you use the digital IO board you don’t use the splitter, see that part for more detail)
• 128MB SDRam Module – Not required for all the cores, but it is required for enough of them that I wanted to mess with. This slides into the top part of the Terasic board. You can see the cores that require SDRam here.
• I/O Boards: There are typically two I/O boards that people use for this. I’m going to try both, but you only install one at a time. Generally, for those that want to stream HDMI but play on a CRT, you’ll get the Analog board. The Digital board offers some extra expansion capabilities, though. Regardless of which one you get, this board sits on TOP of the Terasic, so when combined with the USB hub below, the Terasic is in the middle. Of note are the three switch buttons on top to easily access Reset, OSD (On screen display), and user defined functions. Cases for these are also available, and assume you have the standard 3 board setup (USB board + Terasic board + IO Board)
  • MiSTer Digital IO Board v1.2 – The MiSTer FPGA Digital IO Board v1.2 provides the following features: a dedicated power switch to turn the unit on and off with over-voltage protection, a 3.5mm audio jack for ADC In (Tape Input) a separate ADC-In addon board is not required, 3.5mm Mini-TOSLINK & Digital TOSLINK Connectors, a secondary microSD card slot the functionality depends upon the core being used, a fan speed control jumper providing 3.3 volts or 5 volts, three status LEDs (red, yellow, green), three large push buttons providing system reset, on screen display menu and game reset, an expansion connector in the form of a USB 3.0 connector however this is not for standard USB devices. If you use this board, it comes with a cable so you power your entire setup through this board, power goes through the GPIO pins into the Terasic, and then you use the included barrel cable to go from the Terasic to the USB board. So one power cable powers all three boards connected together. Acrylic Case Link
  • MiSTer Analog IO Board v6.1 – The MiSTer FPGA Analog IO board v6.1 includes the following useful features: a VGA (DB15) connector allowing for the output of a VGA/RGB/YPbPr signal depending on the cable being used, a 3.5mm audio jack with Mini-TOSLINK providing analog audio output and digital audio output, a secondary microSD card slot the functionality depends upon the core being used, a fan speed control providing a 3.3 volt / 5 volt selector jumper, a status LED control jumper allowing switching on or off the built in LEDs, a Sync-on-Green switch, three status LEDs (red, yellow, green), three large push buttons providing system reset, on screen display menu and game reset, an expansion connector in the form of a USB 3.0 connector however this is not for standard USB devices. Acrylic Case Link
    • Configuration of the video output signal on the IO board is controlled via the MiSTer.ini file, more information on how to configure and download of the MiSTer.ini file see the https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Configuration-Files configuration
• Wifi/Bluetooth USB Dongles – Generally, I think you can use whatever ones you may already have. Terasic sells some from their site, I used some I already had. They fit nicely into the USB board to give you connectivity as you desire. Not every dongle dangles properly, so here are some recommended adapters for Wifi and Bluetooth.

I also picked up some more ‘odd’ add ons for this as well, more specific to my gaming taste:

• MiSTer SNAC-IEC CBM 1541 Connector – I believe with this I can hook up a real 1541 drive to the kit and use it with the C64 core.
• Ultimate Dameon x2 Player MiSTer FPGA adapter – The Ultimate Deamon PRO USB Dual Encoder for ATARI / SEGA MEGADRIVE / GENESIS. This small form-factor USB adapter makes it possible to use SEGA MEGADRIVE / GENESIS controllers on your PC (Windows, Mac OS X, Linux), Raspberry Pi or MiSTer. The adapter has a native 1ms/1000Hz polling rate so input lag is minimal (the average is 0.75ms with a wired controller). Fully assembled in a Aluminium enclosure and includes USB-C cable to connect this adapter to your favorite setup. (from ultimatemister.com)
• MiSTer RTC Real Time Clock Board 1.4 – For cores that use a clock, mainly if your FPGA kit isn’t going to be internet connected for automatic time syncing, this one’s for you. I don’t believe you need this if you’ll have internet connectivity, though.

Putting the parts together

While you don’t *need* a digital IO board or USB hub connected to your DE10-Nano, it sure makes things easier. Our final configuration when this is setup will be the DE10-Nano sandwiched in between the USB hub board on the bottom, and the digital IO board on the top. Wrap the acrylic case around it and we’re done.

A note on orientation.

When I say ‘top’ or ‘right’, I’m orienting my Nano like the pictures on Terasic’s website. The ethernet adapter is on the right side when the board is facing up:

Heatsink

Nothing wrong with that. Picked mine up from https://misterfpga.co.uk/product/mister-fpga-ultimate-heatsink/, made to fit the Cyclone V SoC on the DE10-Nano board.

USB HUB Board

The USB Hub board sits below the DE10-Nano, and you’ll need to remove the standoffs from the Nano (I gently twisted with pliers, keep the screws for later but you’ll need to remove them) so that you can mount the USB board below it. On the ethernet side of the Nano, on the very top right, there’s the USB-Micro style OTG (On The Go) port, which is how we connect the HUB to the Nano. My board comes with a slick adapter that plugs into four pins of the USB board:

and then zig zags up and out to the plug into the Nano’s OTG port:

So with the standoffs screwed into each other (leaving the top screws since we’ll be putting the digital board on top), we’re ready to continue.

128MB SDRam Addon Board

I next installed the ram board. I could have done this prior to the USB board, but if nothing else I wanted to do it before a placed the I/O board on top of the Nano. The two large SDRam chips face the inside of the nano for my version, and there’s a label on the opposite side that says ‘this side faces outwards’, so that helps orient you. The SDRam goes into the pin header on the TOP of the Nano.

Digital IO Board (Or Analog if you have that)

Next up is the IO Board, but before we install it, (for Digital IO Boards only), we need to flip a switch on the Nano. Namely, SW3, and it’s right here (in our orientation, SW3 is on the left side of the bank, SW0 is on the right side)

After flipping it on (UP) (and ONLY for the digital IO board – for the analog IO board, all switches should be down/off), we’re ready to put the Digital board on top. Our orientation has the ‘green’ LED above the Red LED, this is how the IO board will look when putting it on top of the Nano if you’re using the orientation we are for our Nano (ethernet port on the right side). We also put another set of standoffs on top of the Nano for this to rest on.

One troublesome thing I noticed was there are more headers (holes) on the Nano then there are pins on the IO board, so you’ll want to be careful. With our orientation we’ve been using, the digital IO board carefully slides into the pins on the Nano. Gently make sure all of the pins line up. On the both top and bottom sides of the Nano, you’ll have more headers (holes) on the Nano then you actually will pins from the digital IO board. Here are some shots from the misterfpga.co.uk site that show the differences of top and bottom headers/vs pins:

At pretty much anytime during this install, we could have turned the whole thing on and tried things out (hooking up a keyboard, HDMI, and power), but we’re going to cover that later. For now, on to the Acrylic Case. (If you’re not using a case, you can screw the IO board into the brass standoffs it should be touching – but if you ARE using a case, no screws yet)

Acrylic Case

More parts! Don’t worry – it’s not uncommon that you will leave here with more brass standoffs than you started with, as individual parts often come with extras. My case is designed for the digital IO board AND USB board in the mix. There are other case variants that use the Analog IO board and USB board, naturally.

Put the top standoffs into your digital IO board now, before you start building your case walls. (You can do it afterwards, it’s just annoying). Rest the MiSTer on top of the bottom part of the case, and build your walls up by aligning holes to case sides. The tabs on the case sides slid together easily enough for me.

The part that was roughest for me was the three little separate plastic buttons that rest on top of the Digital IO board’s buttons. I found it easiest to put the buttons in the top side of the case, turn the MiSTer upside down, and align the case top and buttons that way.

With the case top on, and making sure the buttons were in place, I put the four screws in to the top of the case, securing the boards and case all together. We’re done assembling our FPGA sandwich!

Power setup

When using this style of kit, where we have the IO board on top of the Nano on top of the USB hub, we really only need to give power to one component, and then we daisy chain power down to the other two boards. We power the Digital IO board directly, which then gives power to the Nano, then we use the included Male to Male barrel connector to go from Nano to USB board. So my power side/HDMI side looks like this:

Don’t forget, the Digital IO board also comes with a power switch on the bottom left (a simple slider switch). I’m also using an inline switch power adapter, just make sure you’re turning all the right parts on. I just leave the digital board switch on and use the inline adapter switch, but you do you. 🙂 After this point, I hook up the HDMI, and USB keyboard/mouse and I’m ready to go… after we flash the SD card with the Mr. Fusion software.

Flashing the MicroSD card with Mr. Fusion

If you have your case on, you’ll notice that the SD card is a royal pain in the ass to get out easily. If I just trimmed my fingernails, I end up having to use a tiny pliers to grab the card after I release it with a push (it’s a spring-loaded-grabber SD Card type, but when releasing the card it *barely* clears the case if at all). This is another reason I want to avoid having to take the SD Card in and out of the kit, it’s too damn annoying. This is why I’m thinking most people would want to SCP into their MiSTer, use USB memory cards, or use network shares instead of ever having to remove the microSD card every time they wanted to add something. I’m going with the network mount for the purposes of this document.

So, if you haven’t yet, remove the SD Card and put it into your favorite PC. I like to use balenaEtcher, so I grab that and the latest Mr. Fusion release (at time of writing, 2.7), and let the etcher do its thing.

Putting this back into the MiSTer (the MicroSD card slot is on the bottom side of the Nano board, so you should make the gold contacts of the MicroSD face UP when you slide it in), we’re now finally ready to boot this thing up and configure some of the software.

First boot

If everything has gone okay (and why wouldn’t it, things never break or go wrong, right?), you’ll see this on your monitor:

This will reboot, and then come to a screen that at first, made me think the flashing didn’t work right. I didn’t know what to expect, so don’t be alarmed, and in fact, you should expect see this:

All this means is that you’ve loaded up Mr. Fusion and are looking at a blank core menu because, well, the initial flashing doesn’t install any cores. We’ll have to do that ourselves in a bit. First things first. Connectivity. Well, one more thing first. If the flashing static background starts annoying you, hit F1 on your keyboard to change it. This also easily screws up encoding, as I was streaming his at the time and all of the static made the rest of the stream overlays pixelate.

Initial Network Connectivity

If you’re hard wired in, you should already have an IP address. If not, you should hit Escape, which will bring up the system settings, and select the ‘Scripts’ directory.

At the warning, type yes (since you do want to run the script), and select ‘wifi’ and hit return. Assuming you have a wifi dongle plugged in (and if not, you should just go hard wired with ethernet), you’ll see the list of SSIDs – select yours and enter your password. After that point, you should get taken back to the main menu, but you’ll have a little ‘Wifi’ signal icon in the upper bar of your menu now.

Now we’re cooking. Next steps are to download the well known ‘update_all’ script (not the stock update script that comes with the install – which definitely works if you only want to use that) that downloads all the stuff that the update script does, as well as a lot of neat and/or experimental features should you desire it and performs general updates and downloading of additional scripts. But first let’s go over where I’m storing all of the files the downloader is going to download.

MiSTer file paths and network mount considerations

MiSTer FPGA has a fairly standard directory structure it uses to look up files, be it cores or roms. Whether it’s network storage or the SD Card itself, MiSTer mounts a well known directory structure referenced here: https://mister-devel.github.io/MkDocs_MiSTer/cores/paths

to do any of the following, we need to login via SSH to our running MiSTer. To see these directories in action, you can use PuTTY to open up a terminal into your MiSTer. The default account is root and the default password is 1. (So… maybe we’ll change that later)

After you login, know that all of the directories MiSTer is going to care about are under /media. The basic key directories are:

You won’t have some of these directories yet because we haven’t downloaded anything with the update_all script yet (you’ll at least have a Scripts directory because we’ve already run files from there). Previously I mentioned that I did NOT want to constantly remove the MicroSD card to add content to my MiSTer. I would think most people don’t want to do this, especially with a case because getting those SD cards in and out easily is annoying. So, I figure I had these options:

• Use the SD card for primary storage, let the update_all script download cores to the SD card, and use SCP/SSH to transfer files to the MicroSD card to my computer. Doable, but slightly cumbersome
• Use a USB Stick (which the MiSTer should automount according to the core paths page referenced in the github link above. Here we can at least windows to do a little easier transfer, but we still have to move the stick between files.
• Use a Samba share – You can enable the Samba (Windows file share) service on the MiSTer and expose your SDCard over the network as described here: https://mister-devel.github.io/MkDocs_MiSTer/setup/games/ Also doable, but I prefer to not really use the SDCard except for booting up the MiSTer and storing some configuration data.
• Use the CIFS mount scripts and download all cores and games onto my Synology NAS, and then have MiSTer mount those directories instead (even thinking it’s /media/fat, when it’s really talking to my NAS). I liked this because virtually all files are on my NAS, so I can use that from windows more easily than SFTP, and I’m not constantly writing to the MiSTer SD Card. This is the option this document will describe further down below.

So, my goal is to create a NAS share, and have MiSTer mount the FPGA directories for cores, systems, etc. on the NAS, but making it think it’s still under /media/fat (reason being if anything we ever install assumes /media/fat is used, it will just work). The primary directories we’ll leave on the SD card itself are /media/linux and /media/config, which are much more towards MiSTer even running things properly. The cores and games, however, will live on my NAS.

So I created a share and made a dedicate user for it, this way it wasn’t going to see any other directories on the NAS and things are neatly organized. For the CIFS mount to work, the directories must already exist, so I created the directories I needed by using a template.zip file from a forum thread I found on doing this exact thing, referenced here. However, I found I needed to add a couple of directories to that template, so I’ve created my own, which you can grab here. It’s just a zip file with empty directories to get you started. All I did was just unzip it to the root of my NAS MiSTer share.

(The reason we do this is that those directories must exist to mount them on the MiSTer, otherwise when the download runs it will download files to the /media/fat/games directory on the SD CARD, not the network mount that we want. We’re using CIFS to trick MiSTer into thinking /media/fat/games is on the SD card when it’s really on the network, remember.)

These are the empty directories included in the zip file. (Ignore #recycle, that’s from my Synology NAS)

Download and configure the CIFS_MOUNT scripts

Now that we have those directories created, we need to tell the MiSTer how to mount them. To do that, we’ll download to our /media/fat/Scripts directory (which will NOT be part of our NAS) the two scripts cifs_mount.sh and cifs_umount.sh from https://github.com/MiSTer-devel/Scripts_MiSTer.

cd /media/fat/Scripts
wget https://raw.githubusercontent.com/MiSTer-devel/Scripts_MiSTer/master/cifs_mount.sh
wget https://raw.githubusercontent.com/MiSTer-devel/Scripts_MiSTer/master/cifs_umount.sh

Now, in that same directory, we need to create a cifs_mount.ini file. Here’s mine, you’d obviously use a real IP address for your NAS, a real username, and real password.

# NAS IP (If server name doesn't work, use IP)
SERVER="192.168.50.10"

#The share name on the NAS
SHARE="mister"
USERNAME="mister"
PASSWORD="mister"

#Local directory/directories where the share will be mounted.
LOCAL_DIR="*"

#mfsymlinks most likely is necessary so the update_all ArcadeOrganizer download works.
ADDITIONAL_MOUNT_OPTIONS="vers=3.11,mfsymlinks"

#"true" in order to wait for the CIFS server to be reachable;
#useful when using this script at boot time.
WAIT_FOR_SERVER="true"

#"true" for automounting CIFS shares at boot time;
#it will create start/kill scripts in /etc/network/if-up.d and /etc/network/if-down.d.
MOUNT_AT_BOOT="true"

#========= ADVANCED OPTIONS =========
BASE_PATH="/media/fat"
#MISTER_CIFS_URL="https://github.com/MiSTer-devel/CIFS_MiSTer"
KERNEL_MODULES="md4.ko|md5.ko|des_generic.ko|fscache.ko|cifs.ko"
IFS="|"
SINGLE_CIFS_CONNECTION="true"
#Pipe "|" separated list of directories which will never be mounted when LOCAL_DIR="*"
SPECIAL_DIRECTORIES="config|linux|System Volume Information|#recycle"

You can see in the SPECIAL_DIRECTORIES section we ignore config and linux, which we’ll always want to leave on our SDCard for stability. The rest of the directories are mounted from the NAS IF they exist on the NAS already.

So, saving that file, my scripts directory now looks like this:

/media/fat/Scripts# ls -l
total 160
-rwxr-xr-x 1 root root   911 Apr  6 00:18 cifs_mount.ini
-rwxr-xr-x 1 root root 12993 Apr  6 00:17 cifs_mount.sh
-rwxr-xr-x 1 root root  1051 Apr  6 00:17 cifs_umount.sh
-rwxr-xr-x 1 root root  4662 Jan  1  1980 update.sh
-rwxr-xr-x 1 root root 10638 Jan  1  1980 wifi.sh

I then invoked the ./cifs_mount.sh command to make sure it worked, and voila, here was my output:

./cifs_mount.sh

And now, all of these new directories appear on /media/fat (but most of them are on our NAS!)

Now, if you’re ever unsure as to whether or not the directory you see under /media/fat is local to the SD card or not, check out the mounts by doing a cat /proc/mounts. You’ll see output like this:

You can see all of the directories that are actually mounted to the NAS. These are the same directories our update_all script is going to download to (as well as config/linux/Scripts, but those stay local on the SD card because we’ve either ignored them or did not create a matching directory on the NAS).

You should be able to reboot your MiSTer and SSH into it again and see these mounts are still there.

Download and run theypsilon’s update_all.sh script

Finally, the moment we’ve all been waiting for… let’s get things updated and downloaded.

SSH back into your MiSTer if you rebooted, and in the Scripts directory download the update_all.sh script from theypsilon’s git hub.

cd /media/fat/Scripts
wget https://raw.githubusercontent.com/theypsilon/Update_All_MiSTer/master/update_all.sh

Then, execute it. The update_all.sh script takes a while to run – you may want to run it from the OSD on the MiSTer, or you can still run it via SSH if you prefer. On the MiSTer OSD you’d see this (Hit ESC to get to the System Settings menu, then select Scripts):

Select update_all and you’ll be greeted with a preamble. If you want to use default download options, just let it go, otherwise, hit UP ARROW and you can configure to download optional items. (If you’re on Wifi, this may take a while, might be best to do an initial update via ethernet cable)

I hit UP and was greeted to the main settings page. Where I enabled this and that, but regardless it’s going to download the primary cores, scripts, and folder setup structure for /media/fat/games.

You can always just take the defaults, ‘Exit and Run update all’, and run it later if you want to download Disabled items.

That runs for a looooooong time.

At the very end of the script, barring any issues, you’ll see this:

Your MiSTer will now reboot, and we’re done with the initial downloading. If you look at your NAS share now, you’ll see it holds plenty of files and takes up a bit more space:

Rebooting and final touches

A note on starting up your MiSTer now that you’re mounting a bunch of folders on your NAS: Now that you’re ‘tricking’ MiSTer into thinking /media/fat/<some of your directories> are local and not on the NAS, you may be occasionally surprised if you menu under ‘Arcade’, ‘Console’, or ‘Computer’ is empty when you first start up. Don’t be. Just go back to the root of the menu (hit that OSD button on your case, or just escape out), wait a tick for the cifs_mount.sh script to finish in the background, and then you’ll see your cores and games visible. It’s just on the initial boot up, and usually only takes a few seconds after the menu shows up.

Once that was all said and done, I went to the Scripts directory again and executed the timezone script to set my timezone properly.

Now, that pretty much concludes this round documenting my initial setup. Some good reference links:

HotKeys: https://mister-devel.github.io/MkDocs_MiSTer/basics/hotkey/

Defining GamePads: https://mister-devel.github.io/MkDocs_MiSTer/setup/controller/

MiSTer FPGA Documentation: https://mister-devel.github.io/MkDocs_MiSTer/

MiSTer Wiki on GitHub: https://github.com/MiSTer-devel/Wiki_MiSTer/wiki

SMB/CIFS Mount Threads: https://misterfpga.org/viewtopic.php?t=3246&start=30https://misterfpga.org/viewtopic.php?t=4972

theypsilon’s Update_All_MiSTer repo: https://github.com/theypsilon/Update_All_MiSTer

The post MiSTer FPGA Initial Setup and Network Mounting appeared first on Krystof.IO.

I felt the need to separate GOG game installs from DOS games I’ve got that I’ll be setting up manually or through Steam. The great thing about GOG (Good Old Games) games is that they do a lot of the legwork for getting old games to run on modern systems. However, they’re not always great – they sometimes have issues, or occasionally lack content I’ve got on my original CDs or floppy images I’ve saved off. Plus, I may want to run these with a different version of DOSBox, since a lot of the GOG games come packaged with DOSBOX 0.74-XXX. I’d like to try some of these with DOSBOX-X and take advantage of save states and shaders which seem to be better supported there.

Nevertheless, they’ve tweaked a lot of the DOSBOX settings for CPU cycles and such on their end already, so that should save me some heavy lifting and fine-tuning… hopefully.

Here are some of the software / utilities I used when bringing in some GOG games:

GOG install and personal tweaks to GOG’s DOSBOX

So, I installed GOG Galaxy, linked my account, and found the myriad of games I’ve purchased over the years. First stop, a personal favorite – Heroes Of Might and Magic. I’m going to focus on the first of the series, which uses DOSBOX.

Now, my personal flavors on DOSBOX gaming are that I’d like full screen (I’d prefer borderless window but that’s not something I’m sure I can do with DOSBOX) at the host machine’s resolution, so I don’t encounter a crap ton of resolution switching on my monitor if I want to look at manuals or reference cards.

In the past, I would manually tweak a GOG games unique DOSBOX config to my liking, with generally these settings:

[sdl]
fullscreen=true
fullresolution=desktop
output=opengl

[render]
aspect=true

GOG stores the main dosbox config for each game in the game’s dosbox<abbreviation>.conf file. So for Heroes of Might and Magic 1, that ends up being dosboxHOMM1.conf. I may automate some of these changes, but for now I’m manually doing these to see how things play out first. In fact, each GOG game gets its own DOSBOX copy stored underneath the game’s main directory:

The game loads up fine, though I do find it annoying that if I alt-tab out to look up a page in the manual and go back, DOSBOX reverts to the window, I have to hit alt-enter to go back to full screen. At least I don’t have the monitor itself changing resolutions on top of it. DOSBOX-X, thankfully, doesn’t do that, but we’ve not converted our GOG HOMM to DOSBOX-X yet.

DOSBOX-X install and initital configuration

Now, I’ve installed my generic DOSBOX-X copy in a single directory under my D:\Emulators path:

Now, as far as DOSBOX-X goes, I’ve edited the dosbox-x.conf that comes with the download and tweaked to my liking.

[sdl]
output=opengl
fullscreen=true
autolock=true
autolock_feedback = none

[render]
aspect         = true
aspect_ratio   = 4:3
glshader       = crt-lottes-krystof.glsl

You may notice the glshader entry in there. That’s a custom one I was tweaking – you can make your own or point to one of the built in defaults under the glshaders directory. Definitely something to play around with.

Swapping HOMM’s DOSBOX for my DOSBOX-X

If I run dosbox-x.exe, it works, and everything is happy. Now, the question I have… Can I somehow swap out the DOSBox that my GOG Heroes of Might and Magic usses to use my global DOSBox-X directly? It leads me to other questions:

• How do we point a GOG game to use my dosbox-X under D:\emulators\dosbox-x? What about configs?
• If we can swap a GOG’s dosbox to dosbox-x, can one dosbox-x config handle all the GOG games? Probably not
• How do we have a common config and allow overrides as needed with dosbox-x?
• How can we take a GOG’s customized DOSBOX-.74 config and overlay them on top of my global DOSBOX-X config?

First off, the manual approaches. Even if this works for one game, that doesn’t mean it will work for all, so I anticipate having to come back and make changes. Perhaps I can automate some of them.

HOMM GOG’s DOSBox has multiple configuration files:

The launcher link also calls this, and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

So we can see they’re already using overrides – the ‘single’ conf file overrides their HOMM global config file. We also have some relative paths in there, going to the parent directory (which is the HOMM install). The ‘single’ file seems to be more of the autoexec related work, and doesn’t try to override much in the way of rendering, though it does shut ipx off.

Brute Force – Duplicate DOSBOX-X and use it against the GOG HOMM’s DOSBOX 0.74 configs

How can I swap out the EXE? I could just copy all of dosbox-x and duplicate a game-unique DOSBOX install inside HOMM’s dosbox directory, which is effectively what they do. Let’s try that, and rename dosbox-x.exe to just dosbox. This means we won’t have to change the shortcut. I did that and to be sure, deleted any dosbox-x.config files in my HOMM dosbox copy. So now we have the DOSBOX-X binary being executed, but using the dosboxHOMM config files, which we know target the original DOSBOX-0.74 version. Just because we’re using DOSBOX-X binaries doesn’t mean we can assume DOSBOX 0.74 configs will just work 100% without flaw. At least I wouldn’t think so. Perhaps I have trust issues.

Result? Successful proof of concept. It worked – with a side note. I had to click into the program and heard an audible ‘click’ when I activated the window. I don’t recall that being a thing. But we aren’t taking advantage of any spiffy DOSBOX-X configs, and if there are any defaults in our global dosbox-x we set, we’re not picking them up, since we made a complete duplicate dosbox-x. It’s not what I want long term.

Next step – Overwrite dosboxHOMM1.conf with our dosbox-x global config contents.

I tried this just to see if it would still load. Now what this also means is that we would lose ANY HOMM specific dosbox configurations since we’re going to replace it with dosbox-x. So things like CPU cycle settings, sound card configs, xms,ems settings, etc. that GOG curators put in there would be lost. This probably won’t fly long term, just wanted to see how well it would work. So, I wiped did a copy and paste of the file contents of my global dosbox-x.conf into the file dosboxHOMM1.conf.

Result? Mixed but doable. We did get the shader working, but a couple of oddities. The mouse only worked in full screen mode. In window mode (for dosbox x you toggle full screen with F11-F) I couldn’t get a mouse cursor anymore. Switching back to fullscreen fixed that. To solve this, I needed to change my dosbox-x.config:

[sdl]
autolock=true
autolock_feedback = none

autolock_feedback set to none removes the ‘click’ when dosbox locks the mouse (that same audible click I heard the first attempt). Your call. You can hit CTRL-F10 to unlock the mouse again.

Dont’t forget, we copied our dosbox-x.conf contents into dosboxHOMM1.conf. That’s not a good long term solution, we’re just doing proof of concept.

So, that worked, but it worked this time... I totally expect some games to not tolerate this, because something in the game specific DOSBOX config would be lost if we did this for each game. You can see with the autolock we already had a deviation from the dosbox-x default, but in this case, I’m fine with changing it. However, it won’t always be the case – what if a DOS game wants EMS memory setup but another DOS game crashes because of it? I suspect I’ll have to handle those cases.

What would be useful is a program that parses dos box config files, looks for values that don’t match default or ignorable patterns, and reports just meaningful differences. Then we can take those differences, put them in the override dosbox config (e.g. dosboxHOMM1_single.conf), and still use our generic dosbox-x.conf as the primary for all of our games. That’d be great, because if we want a different shader, they automatically apply to all the games. We can still use the override file if we want to change it for a specific game, too.

What about those .lnk (Windows Shortcut) files? GOG is using those to launch from it’s launcher. If I import GOG games into LaunchBox, it’s going to use those .lnk files as well. I’d like to leave the link intact, but I may need to modify them if I want to try to make some global dosbox.config usable. But say I could do that, what does that look like?

Attempting to use a single DOSBOX-X install and base config for multiple GOG games

Let’s see if this even works before I worry about modifying Windows Shortcut links.

Resetting our GOG HOMM from scratch again…(Backups backups backups)

Recall our initial .lnk shortcut pointed this way and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

That means dosboxHOMM1_single.conf is referencing paths from the standpoint of our GOG HOMM’s DOSBox directory. So we must start our command there just like the link does. But if we want to use a global DOSBOX config in our D:\Emulators\dosbox-x, we’re at a bit of an impasse.

So, in a command line prompt, I switched to the GOG HOMM DOSBOX directory and ran this command line instead from the GOG HOMM DOSBOX dir:

D:\GOG Galaxy\Games\HoMM\DOSBOX> d:\Emulators\dosbox-x\dosbox-x.exe -conf "d:\Emulators\dosbox-x\dosbox-x.conf" -conf "../dosboxHOMM1_single.conf"

This actually worked. I was surprised, since I half expected it to not find my custom shader, but it looks like dosbox-x is looking in it’s folders appropriately. But what about any DOSBOX junk in the GOG HOMM folder left over? We’re not actually using that DOSBOX anymore, we’re just starting in that directory so the relative paths in our dosboxHOMM1_single.conf work.

My current plan is as follows for each GOG game, and summarizes the plan based on our results above:

• Modify the .lnk to point to our DOSBox-X base config, but still utilize the game-specific override config
  • I”ll look at this GitHub repo and maven artifact: https://github.com/DmitriiShamrikov/mslinks which seems to allow me to edit windows shortcuts programmatically.
  • Using that, I now have some throwaway-ish Java code that does the following:
    • Spin through GOG games via network share to my retro machine
    • Look for a shortcut in each game root folder
    • If shortcut has dosbox in its target, make backups of the GOG DOSBOX config files.
    • Point the first config in the shortcut to our dosbox-x global config under D:\Emulators\dosbox-x instead of the GOG game specific primary dosbox.config
    • Change the shortcut target to point to our dosbox-x.exe in D:\Emulators\dosbox-x
• If a game doesn’t ‘just work’ with DOSBox-X: Look at the now abandoned ‘GOG-specific’ dosbox config and determine if anything unique to that GOG game needs to be put in the override config. See if we can automate this looking for the most common reasons a DOSBox game would have issues (e.g. cpu cycles)
  • I’ll have to find a DOSBox properties parser or roll my own. We need to support [bracket] sections and retain linefeeds and comments. I searched around a bit and though I found some INI file parsers, they didn’t handle the DOSBOX autoexec section very well (since they’re not key-value pairs). Ended up rolling my own simple parsing mechanism that gets the job done.

Progressing through my GOG installs

After figuring out how to do this for Heroes of Might and Magic 1 and 2 (the rest in the series are native windows apps from GOG), I continued on with my other GOG installs. Anything of interest noted below:

DOSBOX Settings I take from the GOG install and put into the override file before pointing a GOG game at DOSBOX-X

My thought is that I only want to take certain settings out of GOG’s DOSBOX-0.74 config and put them into the override file. If I take everything, it would overwrite full screen and shader settings that I want to utilize with the DOSBOX-X binaries and my global config.

I thought it’d be an interesting exercise to look at ALL GOG DOSBOX configs at once and count occurrences of unique key value pairs. Here’s the raw dump:

Occurences of keys/values across all dosbox GOG configs:
83	 cpu.core.auto
4	 cpu.core.dynamic
3	 cpu.core.normal
9	 cpu.core.simple
1	 cpu.coretype.auto
5	 cpu.cputype.386_slow
5	 cpu.cputype.486_slow
86	 cpu.cputype.auto
1	 cpu.cputype.pentium_slow
3	 cpu.cycledown.100
88	 cpu.cycledown.1000
1	 cpu.cycledown.10000
2	 cpu.cycledown.20
1	 cpu.cycledown.50
2	 cpu.cycledown.500
2	 cpu.cycledown.5000
1	 cpu.cycles.10000
1	 cpu.cycles.100000
1	 cpu.cycles.11000
1	 cpu.cycles.15000
2	 cpu.cycles.19000
2	 cpu.cycles.20000
1	 cpu.cycles.300
1	 cpu.cycles.3000
1	 cpu.cycles.35000
1	 cpu.cycles.4000
3	 cpu.cycles.500
2	 cpu.cycles.5000
1	 cpu.cycles.50000
1	 cpu.cycles.7500
2	 cpu.cycles.8000
1	 cpu.cycles.80000
1	 cpu.cycles.9000
29	 cpu.cycles.auto
2	 cpu.cycles.auto limit 16000
1	 cpu.cycles.fixed 10000
1	 cpu.cycles.fixed 12500
2	 cpu.cycles.fixed 14000
1	 cpu.cycles.fixed 15000
2	 cpu.cycles.fixed 30000
1	 cpu.cycles.fixed 35000
1	 cpu.cycles.fixed 6000
1	 cpu.cycles.fixed 60000
1	 cpu.cycles.fixed 7000
1	 cpu.cycles.fixed 8000
33	 cpu.cycles.max
2	 cpu.cycleup.10
3	 cpu.cycleup.100
88	 cpu.cycleup.1000
1	 cpu.cycleup.10000
1	 cpu.cycleup.50
2	 cpu.cycleup.500
2	 cpu.cycleup.5000
1	 dos.automount.true
2	 dos.ems.false
97	 dos.ems.true
1	 dos.files.127
93	 dos.keyboardlayout.auto
6	 dos.keyboardlayout.none
99	 dos.umb.true
99	 dos.xms.true
98	 dosbox.captures.capture
98	 dosbox.language.
98	 dosbox.machine.svga_s3
1	 dosbox.machine.vesa_nolfb
83	 dosbox.memsize.16
9	 dosbox.memsize.30
3	 dosbox.memsize.32
3	 dosbox.memsize.63
1	 dosbox.memsize.8
1	 dosbox.vmemsize.4
1	 glide.glide.true
1	 glide.grport.600
1	 glide.lfb.full
3	 gus.dma1.3
3	 gus.dma2.3
96	 gus.gus.false
2	 gus.gus.true
96	 gus.gusbase.240
93	 gus.gusdma.3
93	 gus.gusirq.5
7	 gus.gusrate.22050
89	 gus.gusrate.44100
3	 gus.irq1.5
3	 gus.irq2.5
96	 gus.ultradir.C:\ULTRASND
1	 innova.innova.false
1	 innova.quality.0
1	 innova.samplerate.22050
1	 innova.sidbase.280
2	 ipx.Connection.0
2	 ipx.Enable.0
7	 ipx.ipx.false
98	 joystick.autofire.false
64	 joystick.buttonwrap.false
34	 joystick.buttonwrap.true
1	 joystick.joysticktype.2axis
97	 joystick.joysticktype.auto
95	 joystick.swap34.false
3	 joystick.swap34.true
6	 joystick.timed.false
92	 joystick.timed.true
1	 log.bios.true
1	 log.cpu.true
1	 log.dma_control.true
1	 log.dosmisc.true
1	 log.exec.true
1	 log.fcb.true
1	 log.files.true
1	 log.fpu.true
1	 log.gui.true
1	 log.int10.true
1	 log.io.true
1	 log.ioctl.true
1	 log.keyboard.true
1	 log.logfile.
1	 log.misc.true
1	 log.mouse.true
1	 log.paging.true
1	 log.pci.true
1	 log.pic.true
1	 log.pit.true
1	 log.sblaster.true
1	 log.vga.true
1	 log.vgagfx.true
1	 log.vgamisc.true
4	 midi.config.
4	 midi.device.default
94	 midi.midiconfig.
94	 midi.mididevice.default
98	 midi.mpu401.intelligent
1	 midi.mt32rate.auto
87	 mixer.blocksize.1024
10	 mixer.blocksize.2048
2	 mixer.blocksize.4096
98	 mixer.nosound.false
6	 mixer.prebuffer.20
3	 mixer.prebuffer.240
68	 mixer.prebuffer.25
1	 mixer.prebuffer.30
4	 mixer.prebuffer.40
1	 mixer.prebuffer.512
16	 mixer.prebuffer.80
5	 mixer.rate.22050
93	 mixer.rate.44100
1	 mixer.swapstereo.false
1	 ne2000.macaddr.AC:DE:48:88:99:AA
1	 ne2000.ne2000.true
1	 ne2000.nicbase.300
1	 ne2000.nicirq.3
1	 ne2000.realnic.list
1	 parallel.parallel1.disabled
1	 parallel.parallel2.disabled
1	 parallel.parallel3.disabled
1	 printer.docpath..
1	 printer.dpi.360
1	 printer.height.110
1	 printer.multipage.false
1	 printer.printer.true
1	 printer.printoutput.png
1	 printer.timeout.0
1	 printer.width.85
73	 render.aspect.false
26	 render.aspect.true
1	 render.char9.false
99	 render.frameskip.0
1	 render.linewise.false
1	 render.multiscan.false
1	 render.scaler.hardware2x
2	 render.scaler.none
96	 render.scaler.normal2x
1	 sblaster.dma.0
98	 sblaster.dma.1
1	 sblaster.hardwarebase.220
99	 sblaster.hdma.5
1	 sblaster.irq.10
33	 sblaster.irq.5
65	 sblaster.irq.7
4	 sblaster.mixer.true
4	 sblaster.oplemu.compat
89	 sblaster.oplemu.default
1	 sblaster.oplemu.old
96	 sblaster.oplmode.auto
2	 sblaster.oplmode.opl3
7	 sblaster.oplrate.22050
91	 sblaster.oplrate.44100
99	 sblaster.sbbase.220
94	 sblaster.sbmixer.true
93	 sblaster.sbtype.sb16
6	 sblaster.sbtype.sbpro1
98	 sdl.autolock.true
99	 sdl.fulldouble.false
5	 sdl.fullresolution.
74	 sdl.fullresolution.desktop
20	 sdl.fullresolution.original
99	 sdl.fullscreen.true
70	 sdl.mapperfile.mapper-0.74-2.map
16	 sdl.mapperfile.mapper-0.74.map
1	 sdl.mapperfile.mapper-SVN.map
2	 sdl.mapperfile.mapper.map
10	 sdl.mapperfile.mapper.txt
1	 sdl.output.OpenGL
5	 sdl.output.ddraw
1	 sdl.output.direct3d
5	 sdl.output.opengl
84	 sdl.output.overlay
3	 sdl.output.surface
1	 sdl.overscan.0
1	 sdl.pixelshader.none
98	 sdl.priority.higher,normal
95	 sdl.sensitivity.100
3	 sdl.sensitivity.500
98	 sdl.usescancodes.true
98	 sdl.waitonerror.true
99	 sdl.windowresolution.original
1	 serial.serial1.disabled
97	 serial.serial1.dummy
97	 serial.serial2.dummy
1	 serial.serial2.nullmodem port:23
98	 serial.serial3.disabled
98	 serial.serial4.disabled
1	 speaker.disney.false
97	 speaker.disney.true
9	 speaker.pcrate.22050
89	 speaker.pcrate.44100
98	 speaker.pcspeaker.true
98	 speaker.tandy.auto
9	 speaker.tandyrate.22050
89	 speaker.tandyrate.44100
1	 vsync.vsyncmode.off
1	 vsync.vsyncrate.75

I did this just to get a quick look at how many configs really change between all the GOG Games. As I suspected, we find a wide variety of cpu section settings. We had 2 that turned off EMS memory, and a few that changed the memsize. Quite a few twists in the joystick section, and a few other oddities here and there. So just by looking at this, I changed my program to take some additional overrides.

So, the little local snippet of code I wrote looks at my DOSBOX-X main config and each GOG’s DOSBOX config and compares the following, taking the GOG config and overriding just for that game.

While HOMM worked just fine without taking [cpu] settings, the next game I tried was Alone in the Dark, and with default DOSBox-X settings, it slowed to a crawl. Turns out GOG had tweaked their primary Alone in the Dark DOSBOX-0.74 config:

core -> simple
cputype -> pentium_slow
cycles -> 11000
cycleup -> 1000
cycledown -> 1000

This is why [cpu] is one of the sections I take from GOG’s curated game-specific configuration.

Game specific tweaks I had to make

Here’s the log of games I installed and any interesting tweaks I had to make to convert them to use my DOSBox-X install.

The post Retro Gaming PC Build Log Part 3 : PC Games with GOG appeared first on Krystof.IO.

Figured I’d start off with my favorite system – The Commodore 64. Here are the key software components I used:

Nibconv and .NIB disks

I have some disk images that are already the D64 or G64 type, and some that are .NIB. I need to convert those using the nibconv from the Nib Tools package first. A simple batch file that worked for me (drop it in the folder where you have nibconv.exe and .NIB files and it will handle the rest. It deletes the G64 file first since mine would lock if the file already existed.

for %%f in (*.nib) do (
	del "%%~nf.g64"
	nibconv "%%~nf.nib" "%%~nf.g64"
)
pause

VICE install

VICE doesn’t install – it just unpacks into a directory. I put mine in a common emulators folder D:\Emulators\SDL2VICE-3.6.1-win64. Underneath there are all sorts of binaries and such but the primary one is x64sc, and that’s what I’ll be configuring as I test out some games.

First LaunchBox import and adding VICE as an emulator

I put my Bruce Lee G64 file in a temporary directory just to try this out. I’m going to let LaunchBox manage the Commodore 64 ROM files necessary, so it will ‘move it’ into the LaunchBox Games directory on import:

Now here is where I may deviate from most. I like the idea of RetroArch, and perhaps I’ll revisit it in the future, but I found while I can create global configurations to be shared across multiple emulators, I really liked having features in the later versions of emulators that don’t have an updated RetroArch core, or the core has crippled some features I desire. So in general, I rarely use RetroArch at this time.

For starters, all I’m populating is the name (VICE 64) and the location to x64sc.exe (The VICE C64 binary)

I let it populate all the checkboxes for both LaunchBox and EMU Movies.

I leave these options as default:

After searching the online databases for media, I now show Bruce Lee in my LaunchBox main view:

Testing the first game – Failure and Fix

Double clicking on Bruce Lee does… nothing. I see nothing. I got nothing. What gives?

I decide to launch the emulator directly (x64sc.exe in the VICE directory) and it worked fine:

I then decided to load the G64 image directly through VICE, bypassing LaunchBox. Result:

Okay. So now I now there’s something up with LaunchBox dealing with VICE. I’m actually used to loading VICE first on my RetroPie and loading the image directly. So this means I’ve got a command line argument issue. Turns out LaunchBox tried to force my hand with RetroArch even though I wanted to configure the emulator manually!

Perhaps I should have set the emulator up first, but if you run into this, you’ll see in your emulator config under ‘associated platforms’ a WIDE list of items, and they also populate well known RetroArch cores.

I missed the little ‘pop up’ that stated it populated RetroArch for me. I wish it hadn’t done that, it caused me a small headache. So I went back into my VICE config and wiped out ALL of the associated platforms, left that tab, went back to an empty one (so it doesn’t show the RetroArch core column), and added one entry for Commodore 64 like so:

After that, VICE finally launched from LaunchBox properly:

Configuring VICE on Windows

Great, now we know we can launch at least one game from LaunchBox using VICE. Now I need to configure it to my tastes. First off, it’s a tiny window in the center of the screen, and not full screen. There are plenty of other things I like to configure for VICE, and here is where I’ll record those ‘default’ settings I immediately set into the VICE configuration when I first install VICE. I may tweak this over time but the settings below are my current reference settings of choice.

First off, VICE by default is storing it’s settings in C:\Users\<userid>\AppData\Roaming\vice. Underneath there is a sdl-vice.ini after saving the first time and vice.log for any interesting execution log statements. Good to know.

Side note: Try out wireless gamepads for the PC (Like XBOX controllers). Luna loves chewing cables.

Here are the highlights for my VICE 3.61 Windows SDL version’s settings that deviate from the known defaults.

• SDL audio instead of WMM – Things sounded horrendous otherwise.
• NTSC Mode vs Pal- I had NTSC, but sometimes images I have require PAL. So I set up both
• I set the VICE snapshots directory to the Snapshots directory I created underneath my C64 LaunchBox game folder for easier visibility.
• I set the drive sound emulation to 1. It’s just music to my ears.
• Joystick – I set by default, Joystick 2 to my game controller (a generic gamepad), and Joystick 1 to the numeric keypad. VICE by default sets my A button to Joystick firing, B button to bring up the VICE menu. I manually set the Y button to toggle WARP speed on and off, and the X button to ‘swap’ the Joystick ports. I also set the left trigger to the ‘Load snapshot’ menu, and the right trigger to ‘Save snapshot’ menu.

What I ended up doing was creating two emulator profiles – one for NTSC and one for PAL. The two config files allow me to tweak the two ‘versions’ of C64 emulation differently, and sometimes I just need to do that for some games.

VICE 64 – NTSC setup example (points to NTSC config)

VICE 64 PAL – PAL setup example (points to PAL config)

Current reference settings:

sdl-vice-ntsc.ini:

[C64SC]
SDLStatusbar=1
SoundDeviceName="sdl"
VirtualDevice1=1
MachineVideoStandard=2
IECReset=1
CIA1Model=0
CIA2Model=0
KernalRev=-1
VICIIFullscreen=1
VICIIModel=3
SidModel=0
JoyPort10Device=0
JoyPort9Device=0
JoyPort8Device=0
JoyPort7Device=0
JoyPort6Device=0
JoyPort5Device=0
JoyPort4Device=0
JoyPort3Device=0
JoyDevice1=4
EventSnapshotDir="D:\LaunchBox\Games\Commodore 64\Snapshots\"
GlueLogic=0
DriveSoundEmulation=1

sdl-vice-pal.ini:

[C64SC]
SDLStatusbar=1
SoundDeviceName="sdl"
VirtualDevice1=1
IECReset=1
CIA1Model=0
CIA2Model=0
KernalRev=-1
VICIIFullscreen=1
VICIIModel=0
SidModel=0
JoyPort10Device=0
JoyPort9Device=0
JoyPort8Device=0
JoyPort7Device=0
JoyPort6Device=0
JoyPort5Device=0
JoyPort4Device=0
JoyPort3Device=0
JoyDevice1=4
EventSnapshotDir="D:\LaunchBox\Games\Commodore 64\Snapshots\"
GlueLogic=0
DriveSoundEmulation=1

LaunchBox specific settings:

Command line parameters:

• -chdir “D:\LaunchBox\Games\Commodore 64” (Sets the autostart image directory to our games folder)

Game Specific Settings

Game specific tweaks and oddities

The post Retro Gaming PC Build Log Part 2 : Commodore 64 appeared first on Krystof.IO.

The Goal

It seems when I’m able to come anywhere near close to dusting off some retro gaming work, I boot up whatever RetroPie or Windows based system I’ve set up for some retro gaming years back and can’t for the life of me remember how I set things up from either a taxonomy standpoint, controller setup, emulator configurations, and more. I’m using these build logs to document my thought processes at the time and ‘Figure it out’.

The Hardware

Now, I’m not a retro gaming purist. I’m at best retro gaming purist adjacent. This means I love playing games on the older hardware, but with limited space, I can’t set up all the things. I can set up some retro systems here and there, but I can’t set up everything in one big retro corner. I’ve taken up enough corners in this house with my hobbies. In fact, I’m fresh out of corners. So, I’m going to emulate quite a bit, whether it’s Stella for the Atari 2600 or DOSBOX for Ultima Underworld. I very much enjoy playing games on the original hardware when I can – but when it comes to easily streaming live content or looking up videos and articles about the game, it is very much easier to do it on a PC running emulation software. Plus, I get to compare how the emulators compare to the real deal at my leisure.

Most of the time you don’t need a fancy machine to emulate old retro games – look at RetroPie for example. You can emulate a metric crap ton of games on a Raspberry Pi. The machine I chose is a bit beefier than I would need, but that’s because it’s available to me. Why not a Pi? I have a lot of DOS and Windows games as part of my ‘Bucket List‘ which rules out the Pi right quick – the Pi is great for certain computer and console emulation, but starts to have some issues in retro libraries of later eras (like Windows 9X games). Plus, some of those may require some video acceleration – and for that I’ve an NVIDIA card to take care of the heavy lifting. It’s not for the latest and greatest, but it will do for the oldest and greatest just fine.

It’s a 2018 ASUS GR8 II-6GT024Z VR Ready Mini PC Gaming Desktop with Intel Core i7-7700 and GeForce GTX 1060 6G Video Card. All things considered it’s a powerhouse when it comes to what I need for retro gaming, even if it’s not available for purchase anymore and won’t be supported by Windows 11.

Here are the basic specs:

Processor	‎4.2 GHz core_i7
RAM	‎16 GB DDR4
Hard Drive	‎1 TB SSD
Graphics Coprocessor	‎NVIDIA GeForce GTX 1060
Chipset Brand	‎NVIDIA
Card Description	‎Dedicated
Graphics Card Ram Size	‎6 GB
Wireless Type	‎802.11ab
Number of USB 3.0 Ports	‎4

So, while I type this, I’m performing that fresh Windows 10 install to start from scratch and begin the documentation process. While we wait for that, let’s talk about the primary front end I’ll be using.

Don’t forget to pack your LaunchBox

I’ve tried a few front ends over the years, and most of the time they’re targeting specific emulating systems (MAME for example, has plenty of front ends, but that’s assuming you’re primarily dealing with MAME things). I really adored HyperSpin in the mid 2010s, but I haven’t checked it out lately. I think I’ll still use HyperSpin for a dedicated MAME cabinet (Project Pedestal), but I’m not considering it for this round.

I played around with LaunchBox quite a few years ago when it was in the early years, and I’ve been enjoying seeing the updates and enhancements (like BigBox) since then. With the inherent support for multiple platforms and the capability for me to examine the datafiles (they’re stored in XML files inside the LaunchBox directory) easily, I can use LaunchBox to store configurations for the various games and I can also export that data to my ‘Bucket List‘ database, and from there I can auto populate my Twitch stream with box art, game metadata, and my personal high scores and playtime.

I also wanted to be able to have some custom data points, which LaunchBox supports. For example:

• Series Index – I use a field I call Series Index to indicate what order I should play a game when it’s part of a series. Sometimes the titles aren’t an indicator (looking at you, GoldBox RPGs), and while I could use release date, I liked having a dedicated data-point.
• Port Indicator – I don’t do this for all the games, but for some where I want to try out different versions, like say ‘BurgerTime’ on Atari 2600, Intellivision, Commodore 64, etc. – I use this to link together individual game/platform combinations together.

LaunchBox also has created a database to pull a lot of metadata down for recognized games, along with EmuMovies integration for video and additional art. We can also pull down manuals, which is a big help so I don’t have to find the ASCII text files or open my game boxes up needlessly.

So, I head over to the LaunchBox site, purchased a lifetime license, and went to work on the install. You can of course install the free version, but I purchased it a looooong time ago, so I’m going to use my permanent license.

I’m leaving some hard drive space for the OS, but most of my stuff will be installed on a D: drive so I can keep some parts separated from the main OS. We’ll see how well that works – ideally nothing should FORCE me to stay on the C: drive but you never know. Personal preference, really – I could do all this on C: if I really wanted to.

After launching LaunchBox, I attached my GOG profile and my EmuMovies account subscription for future game and metadata downloads.

That’s it for this round. Next chapters will probably be platform specific as I set up emulators and related utilities.

The post Retro Gaming PC Build Log Part 1 : Host PC and Front End appeared first on Krystof.IO.

The basic version of DOSBox does not contain support for ‘shaders’. Those little bits of code and configuration that can make a modern retro gaming screen look cell shaded, dotted like an old school CRT monitor, or even curved and blurred like an old TV tube. So how do I get shaders? We have to utilize a fork or variant of DOSBox. Let’s run a comparison of these shaders in a MSDOS Retro Gaming screenshot session of DOOM.

I have plans for three dioramas. One is complete – the C64 years. I still have an Atari 2600 and IBM PC diorama to do, and the latter is a bit more technically challenging when it comes to actually playing the games. Not only do I have to worry about DOS games, but Windows 3.1, Windows 95, and even some Windows 98 gaming, and attempting to make all of those games work on one small PC that will host the actual gameplay.

Why DosBox at all?

Between the old copies of games I have on CD and floppy images (I saved a lot of crap digitally if not physically), the actual CDs themselves, and sites like GOG.com, I’ll be able to relive a lot of my old gaming days. This is, of course, thanks in no small part to a little program called DOSBox.

From their site to explain it best: DOSBox is an emulator that recreates a MS-DOS compatible environment (complete with Sound, Input, Graphics and even basic networking). This environment is complete enough to run many classic MS-DOS games completely unmodified.

It’s the de facto standard for running DOS games on modern hardware.

I am 32 flavors and then some

To that end, there’s almost always a variant of DOSBox that gains popularity for a while because DOSBox ‘proper’ doesn’t support every single feature a DOS gamer might want to utilize when playing a game (e.g. Voodoo 3Dfx support). There are a decent number of variants that fall under the label of ‘SVN Builds’, you can check em all out here: https://www.dosbox.com/wiki/SVN_Builds.

One of the most popular variants today is called DOSBox ECE, standing for Enhanced Community Edition. It emulates 3Dfx hardware and supports up to 384 MB of ram, two things that the standard DOSBox build doesn’t cover.

Remember that you don’t have to use one version of DOSBox for every single game you play, although if you could, that would be ideal from a configuration management standpoint, as each variant may have different config file options available.

Now we have variants like DOSBox X, SVN Daum, ECE, and even CRT, which first caught my eye because, while I don’t always play with shaders (I dislike them on VICE), I wanted to see what the DOSBox world had to offer me. However, I wanted a relatively recent version of DOSBox with shaders. The hunt begins.

DOSBox CRT is close but no cigar

DOSBox CRT fit the bill at first – it’s essentially DOSBox 0.74 with a custom shader to give that real CRT look and feel. As much as I liked the inner screen rendering of it, this version essentially paints a CRT border around the screen that becomes part of your DOSBox window… I did not find this palatable:

Good job and a nod to Mattias Gustavsson for compiling his custom shader work into DOSBox. It just wasn’t for me. So our hunt continues. I didn’t want to use Retroarch for this, and I wanted something a little more recently maintained…

An Optionals requirement is found

I stumbled across another DOSBox variant called DOSBox Optionals, created by Marty Shepard with near latest enhancements of DOSBox ECE, standard DOSBox, and other patches people have released that aren’t incorporated into the ‘standard DOSBox’ build. Marty has done a fantastic job of grouping all of these enhancements into a single DOSBox build that also supported the shader patch by duganchen. VOGONS thread about that support here.

I downloaded and extracted DOSBox Optionals and opened up the dosbox.conf. Yikes! The sheer number of options and documentation to each option compared to the normal DOSBox install was amazing. I recommend trying it out – I’ve tried a handful of titles with it thus far and they’ve worked, though I did discover a speech pitch issue. I’ll cover that later in this post.

Throwing Shade…rs.

So without any ‘shaders’… What does DOSBox Optionals look like? Let’s compare shader to non shader. Given that I’m scaling my screen up, my no-shader view will have a slight blurring to it – but that’s not the shader.

Using DOSBox Optionals I took a ‘before and after’ screen shot of ‘no shader‘ and the ‘crt-lottes_mod‘ shader. You can drag the vertical slider below with your mouse and immediately see a difference.

Please note that the new defaults (scaler=none, aspect=on) are needed for the shaders to work as designed.

The results? Immediate shift to a more ‘dot-based’ look, a little darker and very much closer to a curved CRT. Compare yourself – the left side is without any shader and the right side is with ‘crt-lottes_mod’ selected. Drag the line to move your comparison from left to right.

Let’s zoom in and see what it looks like:

I’m impressed. You really get a sense of the dots and CRT nature of the view, and the phrase ‘dot pitch’, which I haven’t thought about in probably a decade, comes right back like it was yesterday. This isn’t just any simple scan-line filter.

Quick rundown of 13 shaders in DOSBox and DOOM

What about some of the other shaders? Let’s take a look – you can use the compare slider to look at the same screen shot of DOS and the same screen shot area of DOOM and compare shaders. I imagine one shader might be good for one game and one for another – or if you’re playing CGA, EGA, VGA, or ANSI text games, you very well might want a specific kind of shader for those resolutions and colors.

For me, I’ve really got my eye on crt-lottes_mod and crt-easymode. GTU looks like a contender as well. Some of these other shaders are just nuts – FixingPixelArt gives one hell of a blur for example, and the xbr (#4,#5) shaders give it a ‘behind stained-glass’ feel to me.

Modifying shaders for testing

As much as I like crt-lottes_mod, I have some tweaks I’d like to make:

• I don’t like curvature shaders. I know it’s trying to be more realistic, it’s just so damn off-putting to me, I’d like to disable it.
• It’s a little too dark – I’d like to increase the brightness a little bit.

I started to wonder – if I do this, does it end up looking like crt-easymode? Let’s tweak it a bit and find out.

I’m going to head over to the SHADERS/crt-lottes_mod.frag file and tweak a few values:

#define warpX 0.000 //0.021, 0.007
#define warpY 0.000 //0.045, 0.021 
#define brightboost 1.0

Let’s compare crt-easymode to my custom-mod-v1:

Granted, you could spend all day playing around with parameters, and while I feel the lottes_mod definitely has a lot more in the way of customization options, I’m leaning towards crt-easymode even with the modifications I made to flatten lottes and brighten the screen. This is just to get something going to see if I like it enough. It’s also a little lighter on the GPU than lottes will be from what I gather, which is good since I won’t be playing my DOSBox titles on a super high end modern machine.

DOSBox Optionals comes with free Chipmunks

Once I found a shader setting I wanted to try out for a bit, I needed to test a few titles on DOSBox Optionals to make sure it worked for my gaming tastes. Optionals comes packaged with a demo for DUNE2, one of the first Real Time Strategy games, and a Westwood classic.

I fired up the demo and as soon as the voice synthesis came on, I could tell something was just a bit… chipmunky. This was with default settings that come with the DOSBox Optionals install. Listen to this:

This did *not* happen running the same DUNE 2 demo on regular DOSBox, so I knew it was something specific to Optionals. But what? What patch is inserting Alvin into my games? I found this VOGONS thread referencing elevated pitch in DOSBox, calling out this code in particular:

I found a reference to Goldplay while searching the DOSBox Optionals repository:

Snippet pulled from https://github.com/MartyShepard/DOSBox-Optionals/blob/master/dosbox/tOptionals/src/hardware/sblaster.cpp at the time of this writing.

So, Goldplay. We’re now just a bit above my pay grade – it’s DMA transfers, sample rates, and IRQ programming. Nevertheless, I set goldplay = true in the dosbox.conf and voila:

I’ll have to keep that configuration option in mind in the future if something seems off in Speech. But between DUNE2, the demo and the game, along with Ultima Underworld, I needed to have this setting set to true for speech to sound proper.

Conclusion

Got some shader settings you like? I’d love to know if there’s a favorite preset or game/app you use a particular shader for. I’ll probably stick with crt-easymode for now, though I might look at the shader configuration and tweak a few things and see what happens. That’s what shader configs are all about – experimentation – because if a shader just isn’t doing anything for you, and it’s not reminding you of the monitor model you played that game on – tweak it!

References

• https://github.com/MartyShepard/DOSBox-Optionals – DOSBox Optionals Repo
• https://github.com/duganchen/dosbox_shaders – Duganchen’s shaders included in DOSBox Optionals
• https://mattiasgustavsson.itch.io/dosbox-crt – DOSBox CRT Build
• https://www.vogons.org/viewtopic.php?t=33896 – VOGONs thread regarding sample rate and DMA for SoundBlaster devices
• http://filthypants.blogspot.com/2015/04/more-crt-shaders.html – A good article referencing example shots of these shaders utlized in other emulators like RetroArch.
• https://emulation.gametechwiki.com/index.php/CRT_Shaders – General Shaders article – references a lot of shaders converted over to DOSBox (Duganchen’s build) and included in DOSBox Optionals.
• https://scalibq.wordpress.com/2017/03/12/dma-activation/ lots of technical information but references SoundBlaster GoldPlay

The post DOSBox Shaders Comparison For Modern DOS Retro Gaming appeared first on Krystof.IO.

After my recent move, the streaming and ‘workshop/den/laboratory’ setup has been a lot of work from the ground up on the computer system side. I used to have a Raspberry PI 4 used as a remote webcam that covered my old place’s 3D printing area. While that worked, I never liked the idea of dedicating a whole Raspberry Pi 4 to that – I wanted to try a Raspberry Pi Zero W and see if it could handle the load. Utilizing the popular MJPG-Streamer package, I was able to get that installed and running, though I had a few hiccups which I’ll reference at the bottom.

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.

In a previous article of the Diorama 64 series, we installed VICE 3.4, unmodified, on our Raspberry Pi 4. I didn’t cover any customization of VICE in that article because I wanted to ‘walk before I run’. However, our goal is to take a miniature floppy drive model, shove a LED into it, and have our VICE emulator control when the LED blinks on or off, mirroring the Commodore 1541 disk drive activity LED. This article won’t cover the circuit itself (that’s a later article), but it is focused on modifying the VICE source code, and using some Python to transfer data from VICE and drive the Raspberry PI’s GPIO pins, which would later drive an LED light.

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.

In my Commodore 64 Diorama series, I used Python to read shared memory segments that we wrote to from VICE. However, the version of Python at the time of that Raspbian install was less than the version I needed – 3.8 or higher. Here’s how I installed an alternative version of Python, along with making it the default version and using PIP in a version-specific manner.

Downloading and Updating

The obligatory apt update/apt upgrade, along with installing dependencies:

cd ~

sudo apt update
sudo apt upgrade
sudo apt-get install -y build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev libffi-dev tar wget vim

wget https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tgz

Compile and Install

tar zxf Python-3.8.0.tgz
cd Python-3.8.0
./configure --enable-optimizations
make -j 4
sudo make altinstall

Validation

Executing this on the command line should work just fine and return the version installed:

pi@vice-pi:~ $ python3.8 -V
Python 3.8.0

Making our install the default version

I prefer to do this by adding the alias to a (potentially new) file .bash_aliases in your home directory by adding this line to the file:

alias python='/usr/local/bin/python3.8'

Example PIP updating

Based on some current reading it looks like it’s a good practice to use the python version specific pip for the version you’re running instead of assuming any default. Here’s the example I used to update the python package manager and installing the RPi.GPIO library.

sudo python3.8 -m pip install --upgrade pip
sudo python3.8 -m pip install RPi.GPIO

References

• https://www.scivision.dev/compile-install-python-beta-raspberry-pi/
• https://installvirtual.com/how-to-install-python-3-8-on-raspberry-pi-raspbian/
• https://www.ramoonus.nl/2019/10/23/how-to-install-python-3-8-on-raspberry-pi/
• https://stackoverflow.com/questions/2812520/dealing-with-multiple-python-versions-and-pip

The post Installing Alternative Python Versions on Raspberry Pi appeared first on Krystof.IO.

My Commodore 64 Diorama project was well underway. After installing VICE on the console of a Raspberry Pi 4, the next step was to make sure I could get a tiny display that would fit some sort of ‘tiny monitor’ I’d have to create further into the project. I shopped around a few different places, but I ended up really liking two, both available from Adafruit. Either way, we’re mirroring the Raspberry Pi to a ST7789 driven LCD display.

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.