I somewhat recently acquired an HP Officejet Pro 8620. I’m relatively happy with the printer but there is one problem with it. The internet/cloud enabled printing functionality is garbage. HP puts its ePrint service in-between your printer and Google Cloud Print. In the process it removes many features like: the ability to change quality and to set the paper size. This means that devices like Chromebooks can not ever print envelopes to my printer via the supported cloud printing functionality.
I have found a solution but its sub-optimal since it depends on another computer in my house. I installed the HP printer drivers on my Linux workstation and then shared that installed printer with Google Cloud Print.
The result is full featured access to my printer but only when both my printer and my Linux workstation are on. I would expect this to also work with a Mac or Windows.
I recently added Vs. Tetris to my Nintendo Red Tent. I was dissapointed to find there were no dipswitch settings to make it free to play like all of my other games.
I created 2 replacement ROM images which turn the game in to freeplay all the time and posted them to a github repository.
To use this you’ll need access to an EPROM programmer (and an eraser if you want overwrite the existing chips in your system). I used an inexpensive MiniPro TL866CS programmer and UV eraser off Amazon for my ROMs.
I found that the easiest way to copy files onto a Windows 3.11 VM (in my case, running inside VMware Fusion) is to use a Windows 7 file share, but before Windows 3.11 can talk to its younger sibling, a few changes need to be made.
The LM hash was the primary hashing function used by Windows LAN Manager in versions prior to Windows NT. Windows 2000 and later retained support for it but disabled it by default as of Windows Vista. Since NTLM (and NTLMv2) hashes are not backwards compatible, LM hashes must be enabled on the host for Windows 3.11 to be able to make a connection.
Configuring Windows 7
- Enable LM hashes.
This puts your account password at risk since LM hashes are easily brute forced. Avoid doing this outside safe network environments and do not choose a password that you use anywhere else.
- Run mmc and add the Group Policy Object Editor snap-in. Select Local Computer when prompted.
- Browse to Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options.
- Change Network security: LAN Manager authentication level to Send LM & NTLM – use NTLMv2 session security if negotiated.
- Change Network security: Do not store LAN Manager hash value on next passwordchange to Disabled.
- Change your password to generate the LM hash. Your password must be 14 characters or fewer. You can change it twice to get your original choice back.
- Enable advanced file sharing.
Not required but makes the following steps simpler.
- Open Windows Explorer.
- Select Tools / Folder Options / View tab.
- Uncheck Use Sharing Wizard (Recommended) near the bottom.
- Share the folder you want to use for transferring files.
- Avoid sharing any folder with confidential data.
- Use a username without spaces, ideally matching the network username you set in Windows 3.11. Create a dummy account if that is simpler. If you elect to rename your existing account, remember to log off and on after the rename.
- Share the folder read-only unless otherwise required.
- Ensure your Windows 7 computer name is NetBIOS compliant.
This means 15 characters or fewer.
- Ensure your Windows 7 VM is on the same subnet as the Windows 3.11 VM.
I found a Bridged network connection to be simplest on both.
Connecting from Windows 3.11
- Ensure the proper network adapter driver is installed.
VMware’s website has a useful article on the subject.
- Install TCP/IP-32 for Windows 3.11.
While entirely option, it is also entirely cool.
- Ensure your Windows 3.11 network username matches a valid username on the Windows 7 share.
To my knowledge, the net command in Windows 3.11 does not support the /user flag and always attempts to connect as the currently authenticated user.
net use z: \\computer\share
- Launch File Manager.
Copy your files in style.
- I used a Windows 7 VM because I already had one configured. For OS X users, it seems entirely possible for Samba to be configured with LM hashes (labelled, simply, NTLM in Samba), negating the need for a second VM. I haven’t explore this far yet but may in the future.
- Since TCP/IP-32 is readily available, you may elect to use FTP instead. I found it far more satisfying to fire up File Manager and to drag files over using a GUI from 1990. On the other hand, if you don’t have proper install media for it, using LanMan may actually be simpler.
- You can initialise the network stack from DOS using net init and net start full but I had mixed results. Connections seemed far more reliable when I let Windows 3.11 perform the initialisation.
This is a two for the price of one post. This will go over adding an RW partition to the SD card and how to use it to store your highscore files.
Adding an RW partion
- A computer running Linux
- SD card adapter
- An SD card with your arcade OS loaded on it(Use a backup copy for this!)
- Connect your SD card (Did I mention that you should use a backup yet?)
dmesg to figure out what the device name of your sd card is
- Create the partition
fdisk /dev/<sd card device>
n for add new partion
enter for the default starting cylinder
enter for the default ending cylinder (or specify a size if you don't want to fill up the rest of the sdcard with this partition)
- Format the partition:
mkfs.ext2 /dev/<sd card device partition 4>
- Its helpful to have a mount point for each of the partitions on the card so its easy to move files around:
mkdir one two three four
- Mount the third partition of the sd card. This contains most of the base OS and startup scripts
mount /dev/<sd card device partition 3> /mnt/three
- Add a mount point directory for the new rw partion we made:
- Now an edit to the startup script to mount the rw partition:
vim /mnt/three/etc/init.d/rcS (or whatever editor you like)
Add a line after the line that says “System Starting”:
mount /dev/mmcblk0p4 /sdcard-rw
- Save your edits
Now when your board boots you’ll have a directory which is mounted read-write at /sdcard-rw. The next section will go over how to move the highscores over to there.
This covers the general concept for the 412 in 1. This works for the games that run with xemu (which is xmame) and aemu which is another MAME variant with different build options.
- A read-write partition setup as described above
- A copy of hiscore.dat from here. This is needed since its not included in the image.
- Unzip the archive and get the hiscore(pre_mame0133u1).dat file this gets used the rest is not.
- Mount the new rw partition:
mount /dev/<sd card partition 4> /mnt/four
- Mount the emulators partition:
mount /dev/<sd card partition 2> /mnt/two
- Mount the base OS partition
mount /dev/<sd card partition 3> /mnt/three
- Now make some directories to store the data for each emulator on the image:
- Make a directory for the hiscore.dat file (This directory is already setup in the xmame config)
mkdir -p /mnt/three/usr/local/share/xmame
- Move the hiscore(pre_mame0133u1).dat to the directory as hiscore.dat
mv hiscore(pre_mame0133u1).dat /mnt/three/usr/local/share/xmame/hiscore.dat
- Move the highscore directories to the rw partition:
mv /mnt/two/.xmame/hi /mnt/four/xmame
mv /mnt/two/aemu/hi /mnt/four/aemu
- Create symlinks for those hiscore directories:
ln -s /sdcard-rw/xmame/hi /mnt/two/.xmame/hi
ln -s /sdcard-rw/aemu/hi /mnt/two/aemu/hi
- Move the nvram directories:
mv /mnt/two/.xmame/nvram /mnt/four/xmame
mv /mnt/two/aemu/nvram /mnt/four/aemu
- Create symlinks for the nvram directories:
ln -s /sdcard-rw/xmame/nvram /mnt/two/.xmame/nvram
ln -s /sdcard-rw/aemu/nvram /mnt/two/aemu/nvram
- Add a symlink for the hiscore directory for aemu:
ln -s /usr/local/share/xmame/hiscore.dat /mnt/two/aemu/hiscore.dat
- Unmount all those partitions:
umount /mnt/two /mnt/three /mnt/four
That’s covers everything but 19XX which uses a different emulator which I haven’t gotten to figuring out yet.
To change the music on the XXX-in-1 JAMMA boards. You need a replacement mp3 file. For mine I used some chiptunes to keep with the theme.
- Get your SD card(or copy of your SD card) off the board.
- Mount the third partition on your machine. The file system format is ext2, this can easily be done on any Linux machine. It is possible with Mac OS and Windows but it requires a bit more effort.
- On the mounted partition replace the
/usr/xrun/bg.mp3 file with the replacement mp3 file you’ve prepared.
This process has been tested with the vertical 276 in 1 and 355 in 1 boards.
While you’re in the /usr/xrun directory you’ll notice some other interesting files:
- Images for the menu system
- Sound effects (in .wav format) for coin, and menu movement
- Config files for the menu system
This assumes you’ve already hacked the board so you can run arbitrary roms.
You can pass the -scale option to /sdcard/aemu/aemu which will stretch and squish a horizontal game to run on the vertical monitor.
This is not the best solution. However, it works and you can at least see the whole game screen.
These instructions show how to build binaries for the 276 in 1 JAMMA board. These instructions probably do work for the other XXX in 1 JAMMA boards that have an SD card on the board.
This is a bit of a crash course in cross-compiling. Before we dive in here is the objective: Get the build process for whatever you are building to use the compiler and libraries in the toolchain we will install. This might happen via changes to the Makefile, CFLAGS, LDFLAGS, or options to the configure script.
I ran all of these instructions on an install of Ubuntu 12.04(Precise Pangolin) on 32bit install. If you are using a 64bit install you will probably need to install the ia32-libs package via apt-get to make the cross compile toolchain work.
- Install the build-essential package: sudo apt-get install build-essential
build-essential is a meta package which installs a few very common and always needed tools and libraries for compilation.
- Get the cross compile toolchain from the mini6410-debian project
- Extract the tar.gz file downloaded to root /: sudo tar xzvf arm-linux-gcc-4.5.1-v6-vfp-20101103.tar.gz -C /
- Add /opt/FriendlyARM/toolschain/4.5.1/bin/ to your PATH: export PATH=$path:/opt/FriendlyARM/toolschain/4.5.1/bin
It would be a good idea to add this to your .bashrc or .profile
Build prerequisite SDL library
- Get the source for SDL 1.2 from the SDL project.
- Extract the source code: tar -zxvf SDL-1.2.15.tar.gz
- cd SDL-1.12.15/
- Run the configure utility with some extra options: CFLAGS=”-mno-thumb-interwork” ./configure –host=arm-none-linux-gnueabi –enable-static –prefix=/opt/FriendlyARM/toolschain/4.5.1 –disable-pulseaudio
The option in CFLAGS was required to get the gcc compiler to not use certain assembly instructions the board doesn’t support. The –host option tells the configure script this is a cross compile for arm-none-linux-gnueabi. –enable-static means that all the dependencies for and resulting executables will be built-in. –prefix makes it install the resulting libraries and code in the location provided. –disable-pulseaudio does exactly what it says. I found that pulseaudio was not easy for me to get built so I dropped it since none of the original emulators used it.
- Run: make
This does the compile. It will take bit to finish.
- Run: sudo make install
This installs all the stuff built by make.
- Make a symlink for sdl-config: ln /opt/FriendlyARM/toolschain/4.5.1/sdl-config /opt/FriendlyARM/toolschain/4.5.1/bin/arm-none-linux-gnueabi-sdl-config
This link is required so that when we are doing cross compiles that the sdl-config executable looks like it is part of the toolchain
Note that if you building anything other than AdvanceMame you might need other dependencies. These instructions intend to be a rough outline and not a script. Its very likely that they won’t work if anything is different.
- Get the source for AdvanceMame.
- Extract it: tar -zxvf <filename>
- cd advancemame-1.2/
- Run the configure script with a bunch of options: CFLAGS=”-mno-thumb-interwork” LDFLAGS=”-L /opt/FriendlyARM/toolschain/4.5.1/lib/” ./configure –host=arm-none-linux-gnueabi –enable-static –enable-sdl –disable-kraw –prefix=<SOMETHING IN YOUR HOME DIRECTORY>
The LDFLAGS are needed to make sure the linker can find the libraries we installed for SDL. –enable-sdl makes sure we build AdvanceMAME with SDL support. –disable-kraw disables the raw keyboard input type since it doesn’t work right on the board. –prefix is the install target. Make a directory in your home directory to install to so its easy to get the entire install of AdvanceMame over to the SD card. Use this path for the prefix.
- Run: make
- Run: make install
- You have a complete install of AdvanceMame now in the prefix directory you specified. You can copy the contents of that over to your sdcard and use it.
I did not cover how to modify a Makefile for cross compilation because it is considerable more involved than just an option to configure. The short version is that you’ll need to go in the file and make sure it uses the libraries and utilities in the /opt/FriendlyARM/toolschain/4.5.1 directory instead of the ones on your system.
Many of the emulators on the 276 in 1 board have checks to make sure the configuration hasn’t changed. These checks attempt to reboot the board and exit the binary. This is unhelpful if you are trying to swap out the roms/games on this board.
I’ve started to disassemble and patch the emulator binaries to remove these checks from them. I’ll post them here as I finish them. These all live on the second partition of the sd card in the location I specify.
276 in 1 binaries
clsemuv – This is the default emulator on the 276 in 1 and it did have a check.
xemu – This is emu1 in the games.conf file and is used for many games. It does not have a check so I have not patched or uploaded it.
cemu/cemu – This is emu2 in the games.conf file and is only used for a handful of games.
412 in 1 binaries
xemu – still unprotected(but different than the 276 version)
xrunmv – Game launcher menu – It *seems* that this is all that is actually required to be able to play any game you want. Start with this and swap out the other binaries as you decide you need to.
355 in 1 binaries
Please note that the provision of these binaries is sole for you to run roms which you are legally entitled to. This is not intended for piracy.
TL;DR: Someone else has done this already go here.
My super wife bought me a modified Ms Pacman cabinet which has the 276 in 1 JAMMA board in it now. I noticed immediately it had an SD card on it and needed to know if it could be modified in anyway. This post will grow over time as I find new details.
The JAMMA board appears to have an ARM CPU based on the few binaries I looked at.
Three partitions. 1 is /boot, 2 contains some configuration and start up scripts, and 3 is / with a typical Linux file structure.
Lots of interesting things here
- clsemuv – looks to be a build of the GP32 version of MAME
- xemu – some sort of binary based on strings it seems to be a combination of sdlmame and pinmame
- xhidev – another binary – looks like its used to control the other binaries
- xrunmv – yet another binary – this seems to be a build of the LemonLauncher.
- run.sh – tiny bash script which runs xrunmv
- roms/ – symlink to /usr/roms – this directory is present on parition 3
- nvram/ – directory containing .nv files for each ROM file
- wavs/ – symlink to /usr/wavs
- xrun/ – symlink to /usr/xrun
This seems to be the bulk of the Linux installation. It has all the usual unix directories here.
From some files in etc/ I think that partition 2 gets mounted at /sdcard during boot
Backing Up Your SD Card
The SD card has a special bootloader which needs to be “fused” with the SD card after it is imaged otherwise the system won’t boot.
To do this you need a few things:
- SD-Flasher: Get it from here: https://code.google.com/p/mini6410-debian/
- The correct SDBoot image for your JAMMA board. Some folks at the Arcade Museum forums have extracted these from their SD cards and posted them. There are 2 versions which I have uploaded here for your convenience. SDBoot 1.1 or SDBoot 1.21
- An image of your existing SD Card: Do this with DD or the imaging tool of your choice
- A new SD card – You might be able to use a larger or different SD card but I bought the identical card that came with my board on Amazon.
To do it:
- Image your arcade image on to the new SD card (I did this with dd)
- Start of SD-Flasher
- Pick the SDBoot bin file
- Click Scan!
- Pick the right card out of the list
- Click Fuse
- You’re done!
Some folks on the Arcade Museum forums have actually done all this work already. One of the members there summarized most of the work on this thread:
There has quite a bit of buzz about the RTL-SDR project that is going on over at reddit on the rtl-sdr subreddit. Most of it has been about using the RTL2832/e4000 devices under Windows and Linux. Since I primarily use Mac OS I decided to cobble together the various hints of other people who have successfully used the devices on Mac OS and document them in a gist on github:
Update: After some feedback on reddit for the previous gist I decided to revisit my build to that I would have a more up to date version of GNURadio. After much hacking I came up with these directions for getting GNURadio 3.6.0 working on 10.7:
After following those directions you’ll want to then install the rtl-sdr driver and then gr-osmocomm so that you’ll be able to use the RTL tuner with gnuradio.