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.

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.

Raspberry Pi 4 Version Log

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

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

wget -O - <raw script url> | bash

Test Programs

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

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

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

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

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

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

Looking for more demos and such?

https://csdb.dk

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

VICE/PI General Settings I change regardless of version

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

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

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

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

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

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

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

• Sound Settings ->
  • Frequency 44100 Hz

This generally sets a config file line:

SoundSampleRate=44100

VICE/PI Version specific settings I’ve changed

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

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

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

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

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

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

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

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

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

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

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

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

BEFORE:

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

AFTER:

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

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

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

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

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

Hardware before the Software

This part is pretty simple – you’ll need:

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

Write The Raspberry Pi 4 Image

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

Boot the Raspberry Pi and get connected.

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

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

sudo apt update
sudo apt upgrade

Download and execute the install script

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

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

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

What the script does at a high level:

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

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

Why compile SDL on the Pi?

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

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

Apply generic settings for sound/video options in VICE.

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

Download a demo and see it perform horribly or wonderfully?

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

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

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

Apply settings and watch a demo perform smoothly

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

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

Raspberry Pi 3B+ Instructions

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

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

sudo apt update
sudo apt upgrade

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

mkdir ~/sdlwork
cd ~/sdlwork

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

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

cd ~/sdlwork

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

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

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

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

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

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

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

#Now, on to VICE for the Raspi 3B

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

mkdir ~/vicework
cd ~/vicework

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

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

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

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

References:

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

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

It’s popped up on a few sites far and away from my little neck of the woods:

A German Home Theater Enthusiasts Forum – HeimKinoTreff.com in a side thread about other ‘geeky and nerdy’ things. Fair and accurate, that one.

The German Commodore Enthusiasts Forum – Forum64.de from poster emulaThor.

The Netherlands hosted Commodore News run by Richard Lagendijk :

I don’t know if it will pop up anywhere else new over time, but if it does I’ll update this post for posterity.

The post The Diorama is getting around… appeared first on Krystof.IO.

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

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

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

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

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

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

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

Birth of a diorama / emulator combo

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

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

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

My brain goes down a creative spiral.

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

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

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

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

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

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

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

The Diorama is still a ‘room’

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

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

Making The Mini Commodore Parts

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

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

A ‘living, breathing’ Commodore.

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

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

Twitching The Progression

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

Diorama/Emulator Parts Breakdown

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

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

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

Series Breakdown

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

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

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