[Tutorial] Installing MVEM (Milton-Bradley Microvision emulation) on RPi 3

NowArrivingHere

Part 4: Controlling the Emulator

The controls are hardcoded:
Escape is used to exit.
The analog control can use either the mouse movement left and right or O and P.
The microvision control pad (3 across x 4 down) uses 123,qwe,asd,zxc for each of the respective rows. Overlays are not shown, so it may be tricky to work out how to play. You may need to look up images of the microvision keypads for these games.

Debugging mode is accessed with M. I don't really understand it, so I'm going to put Paul Robson's explanation here. Probably best to stay out of debugging mode though.

0-9A-F change displayed address
G run program until broken (with M)
K set breakpoint at current address
S single step
V step over
M return to monitor (if running)
Esc exits the debugger

Part 5: Notes on ROMS and MVEM configuration

I recommend sticking with the 640x480 game area at the maximum. It is large enough to be clearly visible to me, and with 16x16 square pixels on the screen, you don't have to worry about missing detail. The main problem with increasing the game area is that there is a separate row below the game area that shows the current position of the analog control. If the game area is made larger than 640x480, this row will overlap the game area. As the source code has been released, this may be fixable, but I don't know how to do it.

EDIT BLOCK RELEVANT TO BUILD 15
Build 15 users are able to select larger screen sizes. I currently use 1280x720x1 for my screen size value.
Raph Koster has confirmed that 1920x1080x1 should work for users of 1080p screens
END OF EDIT BLOCK

Here are the CRC32 checksums for my current collection (Build 14).

Alien Raiders(Milton Bradley)(1981):
alienraiders.bin (B1632712)

Baseball(Milton Bradley)(1980):
baseball.bin (40E3327A)

Block Buster(Milton Bradley)(1979):
block.bin (FD18EA6D)

Bomber(Milton Bradley)(2014):
bomber.bin (BADBD0F8)

Bowling(Milton Bradley)(1979):
bowling.bin (460AC30E)

Connect Four(Milton Bradley)(1979):
connect4.bin (6A4CF60B)

Cosmic Hunter(Milton Bradley)(1981):
cosmichunter.bin (D8BA1377)

Demo(Paul Robson)(2014):
demo.bin (54F1B288)

Invaders(Paul Robson)(2014):
invaders.bin (D520FF6E)

Mindbuster(Milton Bradley)(1979):
mind.bin (D5DC1F7D)

Star Trek Phaser Strike(Milton Bradley)(1979):
phaser.bin (C7768D04)

Pinball (Milton Bradley)(1980):
pinball.bin (906544EA)

Super Block Buster(Milton Bradley)(19xx):
sbb.bin (796660E3)

Sea Duel (Milton Bradley)(1980):
seaduel.bin (83093475)

Vegas Slots (Milton Bradley)(1979):
slots.bin (4500C1D9)

Speed(Paul Robson)(2014):
speed.bin (67A53F5E)

Test(Paul Robson)(2014):
test.bin (A64065F9)

Once you have these files, you can rename them as you wish. However, you may wish to leave pinball.bin as is. The pinball.bin uses a separate pinball.bmp for a background, which is included with the source code. If pinball.bin is renamed, this background will not show up when running the game. This background is not required to run the game, but the game logic makes much more sense with the background.

EDIT BLOCK RELEVANT TO BUILD 15:
The file naming scheme has changed in Build 15. I have not fully tested file renaming. I would recommend sticking with the names from Raph Koster's distribution, as the emulator appears to use these names to determine which .bmp images to load for the controller and screen overlays.

Also, there is an ongoing bug where certain .bmp images (controller, key hints, and knob) will not appear if you are loading MVEM after booting the Raspberry Pi straight to Emulation Station. This is fixable by exiting Emulation Station, running and exiting MVEM on any game and then reopening Emulation Station. This appears to be a problem with SDL-based external emulators and RetroPie/Emulation Station.
END OF EDIT BLOCK

I will try to post pictures soon, but I am having issues with adding images right now.

rkoster

May I suggest starting from the source code available on my site? I released a newer version (build 15) a couple of months ago with Paul Robson's blessing... with all overlays present and better rendering. Also more front-end friendly. Haven't tried it on Pi yet though... I'll have to give it a shot.

Link not present to avoid links to roms. I haven't gotten it in github yet. :/

NowArrivingHere

@rkoster
I am now really glad that I posted this, and that you chose to respond. I had no idea that anyone was still working on MVEM. I have tried out your Build 15 on my main Windows PC and it looks great. It is definitely more user-friendly with the overlays, control listings and better view of the game screen now that the pixels are spaced out.

I found your source. If this can be compiled and run on the Pi, I will be sure to add a section to the tutorial.

NowArrivingHere

@rkoster
Okay, I have attempted to compile the current source on my Raspberry Pi3. I am running into some issues. The first one was an easy fix. I was getting errors like this one.

core11.c: In function ‘C11_LoadAndReorganise’:
core11.c:190:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
  for (int i = 0;i < 2048;i++) {
  ^
core11.c:190:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

I was able to fix this by adding another item to CFLAGS on line 4 of the Makefile, just as the compilation note recommended.

Original:

CFLAGS  = -g -O2 -DDEBUGGABLE -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11R6/include  -I/usr/X11/include -DHAVE_OPENGL -g

New:

CFLAGS  = -std=c99 -g -O2 -DDEBUGGABLE -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11R6/include  -I/usr/X11/include -DHAVE_OPENGL -g

However, "hardware.c" is still throwing linking errors such as this one

/tmp/ccSInogM.o: In function `IF_LoadOverlay':
/home/pi/new_mvem/hardware.c:169: undefined reference to `SDL_SetHint'

Part of the issue was an include that was dependant on Windows and MINGW

#include <c:/MINGW/MINGW_DEV_LIB/INCLUDE/SDL2/SDL.h>

However, just changing it to #include <SDL.h> or #include<SDL2/SDL.h> did not seem to fix the problem. The include is referencing the correct directory, but the library is not being referenced properly. Still looking into this.

Here is a pastebin of the whole output from my most recent attempt https://pastebin.com/fiZN111j

rkoster

The older builds also used SDL2 iirc. If it worked before, what did the include look like in the older codebase? I don't think I added any new includes...

NowArrivingHere

@rkoster

Here is the original include set from "hardware.c" from build 14:

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include "hardware.h"
#include "hwinterface.h"
#include "debugsc11.h"
#include <SDL2/SDL.h>

#include "font.h"

Here is the new include set from "hardware.c" from your build 15:


#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include "hardware.h"
#include "hwinterface.h"
#include "debugsc11.h"
#include <c:/MINGW/MINGW_DEV_LIB/INCLUDE/SDL2/SDL.h>

#include "font.h"

rkoster

Right... I updated that solely to fix a path real quick and forgot to make it nice. But putting it back to how it was in build 14 isn't working? That doesn't make any sense to me, if you can compile build 14. Did you make clean?

NowArrivingHere

Yeah, I added a make clean, used it, and then tried to compile again. Same errors. Looking over the compiler output, I did find this warning that did not show up during the Build 14 compilation. Not sure if it is relevant. I already included this in the Pastebin from earlier.

hardware.c: In function ‘IF_Initialise’:
hardware.c:85:17: warning: implicit declaration of function ‘IF_ToggleFullscreen’ [-Wimplicit-function-declaration]
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~
hardware.c: At top level:
hardware.c:155:6: warning: conflicting types for ‘IF_ToggleFullscreen’
 void IF_ToggleFullscreen(SDL_Window* Window) {
      ^~~~~~~~~~~~~~~~~~~
hardware.c:85:17: note: previous implicit declaration of ‘IF_ToggleFullscreen’ was here
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~

NowArrivingHere

@rkoster

Yeah, I added a make clean, used it, and then tried to compile again. Same errors. Looking over the compiler output, I did find this warning that did not show up during the Build 14 compilation. Not sure if it is relevant. I already included this in the Pastebin from earlier.

hardware.c: In function ‘IF_Initialise’:
hardware.c:85:17: warning: implicit declaration of function ‘IF_ToggleFullscreen’ [-Wimplicit-function-declaration]
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~
hardware.c: At top level:
hardware.c:155:6: warning: conflicting types for ‘IF_ToggleFullscreen’
 void IF_ToggleFullscreen(SDL_Window* Window) {
      ^~~~~~~~~~~~~~~~~~~
hardware.c:85:17: note: previous implicit declaration of ‘IF_ToggleFullscreen’ was here
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~

I did find this.

It discusses MinGW and errors with SDL libraries. Not sure if relevant
https://stackoverflow.com/questions/34848279/g-windows-linker-undefined-reference-to-with-sdl2#34861276

rkoster

Yeah, I wasn't good about the warnings, I admit. Once it was working, I stopped there. :) Those shouldn't affect it compiling (it compiles with those same warnings here, I just checked) unless you've got the compiler set to be strict about it. Adding a declaration to the header file would fix IF_ToggleFullscreen, but iirc adding it made it barf for other reasons... so I lived with the warning. You can definitely fix the warning in IF_Initialise by changing that line to if (f == 1) IF_ToggleFullscreen(window); -- it's just missing the arg.

None of this addresses the actual issue though, which is that your environment isn't finding SDL.h. That's what the linking errors look like to me. Did you try giving it an absolute path?

mitu

@nowarrivinghere The Makefile is missing the linking libraries, just uncomment the line with the LIBS in the Makefile and edit it so it's like:

LIBS    = -lSDL2

then try running make again.

NowArrivingHere

@mitu @rkoster

Wow. I don't know how I missed that, but there it is. I can confirm that it compiles now. However, there appears to be an issue with the *_snap.bmp files used for the controller layout. The keyhints.bmp, knob.bmp and the various game screen overlay .bmp files are showing up correctly on screen, but the various *_snap.bmp files are not showing up. Note that I am testing with 1280x720x1, as this is my TV setup. I'm thinking this may be an error on my end. Going to continue investigating when my Pi is through with updates.

rkoster

IIRC, they're huge -- 1175x3074. You might want to just try resizing them, they may be too large for the Pi.

NowArrivingHere

@rkoster

Okay, here's the current status. I have run the _snap.bmp collection through GIMP to downsize them.
Original dimension: 1175x3074
New Dimension: 587x1537
Original size: 14,110 KB
New size: 2,648 KB

Now, all of the games can be made to work in Build 15 in Retropie. However, there are two things I want to note.

First, GIMP interpreted the clear area around the _snap.bmp images as white space, so these images now have a white border around them. I haven't found a way online to fix this.

Second, while the image resizing solved a real problem with the images not displaying properly, there is a separate issue that I believe is either a RetroPie, Emulation Station, or SDL issue. I have seen something similar before when running an external version of SDLmame. If I boot my Raspberry Pi into Emulation Station and pick any Microvision game, it will load. However, the only .bmp that will load is the overlay for the screen. The knob, key hints and controller layout will be missing. This is true for all games. However, if I exit Emulation Station, load any single game in MVEM directly, exit MVEM, reopen Emulation Station and try to pick a Microvision game again, all of the bitmap files will load properly for all games.

Now, I should confirm that the issue with downsizing the *_snap.bmp files was a separate problem, as those 14MB files would not load in RetroPie even if I had previously loaded MVEM on its own. In fact, those wouldn't even load in MVEM when MVEM was run on its own.

Again, I don't think this is a problem with your code. I think this is just a compatibility issue with RetroPie and external SDL-based emulation in general. It is weird that the overlay for the game screen is the only one that loads correctly after directly booting into Emulation Station. This makes me wonder if its a separate image size issue. Both keyhints.bmp and the downsized _snap.bmp images are larger than the game screens. However, the knob is only 255KB and fails to load while the screens themselves are 1,356KB and load properly.

This reminds me of a problem I had loading an external version of SDLmame in which if I booted directly to Emulation Station and tried to load a game it would crash. However, if I exited Emulation Station, loaded SDLmame and exited, I would be able to reload emulation station and select the game without crashing.

I'm going to try to get a section of the tutorial for Build 15 available soon, as well as some pictures of what this looks like on my TV.

NowArrivingHere

Build 14 (Bomber)

Build 15 (Bomber)

Image Loading Error Build 15 (Block Buster)
0_1504346441331_image_loading_issue_block_buster_build_15.jpg

rkoster

It could very easily be total memory. If the knob is last to load and the video memory is all used up by prior loading, it could fail too. And I am pretty sure the knob is last, and the overlay is first. Try downsizing all images? Even with a 1080 screen, you can probably go down to 540 pixels on the vertical.

NowArrivingHere

@rkoster
Unfortunately, I can't really test that right now. I still have that problem where downsized images replace the transparent parts with white. However, the screen overlays appear to depend on transparent sections to show the actual game area. GIMP fails because it can't retrieve an Alpha channel from your .bmp images, and Paint fails because it is Paint. I don't have proper Photoshop, and my attempts to google ways to downsize these images while maintaining transparency are drawing a blank.

rkoster

I just uploaded snapreduced.zip to http://www.raphkoster.com/gaming/microvision/snapreduced.zip

This has all the snaps and the keyhints resized to 720px tall, with alpha preserved. Give those a try... if it's not enough, I can do it again, with a smaller size still, and also the overlays (though they are only like 540px tall).

rkoster

Oh, and FYI, GIMP can in fact do BMP with alpha. It needs to be set up as a channel called Alpha, and saved in one of the BMP formats that allows it. These ones are using R8.

All these images should have it, but by default, the alpha channel is usually not visible. In Photoshop at least you have to open the image, go to Channels, make it visible, then save.

NowArrivingHere

@rkoster

Okay, I just tried your reduced snaps. It still isn't loading properly. If this is caused by the combined size of all the images being loaded together, it might be a good idea to downsize the actual screen overlays. These are 1.4MB each and are now the largest images loaded when a game is booted, as the snaps are 774KB apiece, the keyhints.bmp is 774KB, and the knob.bmp is 255KB

Also, I'm going to add a screenshot of one of your images loaded into GIMP. I'm not an expert in GIMP, but I am looking at the Channels panel, and I only see a Red, Green, and Blue. I know the images must have an alpha channel due to the transparency, but my GIMP is not recognizing it as such and certaintly not exporting it as such. It must be some sort of import error on my end.