MAME to go open source!

Screen Shot 2015-05-16 at 11.04.26 PM

As I write this I don’t see anything outside of this twitter tweet (post?), along with this Gamasutra post.

The only ‘good’ part I see in there:

Milanovic tells Gamasutra. “Our aim is to help legal license owners in distributing their games based on MAME platform, and to make MAME become a learning tool for developers working on development boards.”

So I guess they want to do android and embedded Linux stuff?

Does anyone know anything more concrete?

It does sound exciting, especially for MAME’s chipset emulation which, let’s face it is superior, and being able to plug them into other emulators that are ‘good enough’ or even different purpose than full system emulation is a good thing.

Also from other sources, I hear that MAME/MESS are to be fully merged, and will be shipped simply as a single executable called MAME.

**EDIT

Well I should have checked the source.  Many things are going to a ,BSD-3-Clause license for example the MUSASHI 68000 processor emulation:

// license:BSD-3-Clause
// copyright-holders:Karl Stenerud
/* ======================================================================== */
/* ========================= LICENSING & COPYRIGHT ======================== */
/* ======================================================================== */

While others are going LGPL, or GPL.

Building SDL2 for Android

Phew is this rather involved.  First you need to download over a gigabytes worth of files. For something that is going to be embedded you need a MASSIVE amount of space.

You need:

I went ahead and installed the JDK in a normal directory,  The same went for the Android SDK.  The NDK is a 7zip file, that I went ahead and put at the root of my C drive because I’m that kind of guy.  Next I unpacked ant into the NDK directory, and SDL.  For SDL be sure to use some command line or other unzip tool that makes sure that the text files are translated appropriately, otherwise they are impossible to read in good editing tools, like notepad.

cd C:\android-ndk-r10d\
unzip -aa \Downloads\SDL2-2.0.3.zip
unzip \Downloads\apache-ant-1.9.4-bin.zip

Now to stage the project directory.  The ‘Android project’ that we are going to build out of is *INSIDE* the SDL archive.  And SDL needs to be inside the project directory, so we xcopy out the bits we need.

md proj
cd proj
xcopy ..\SDL2-2.0.3\android-project\*.* . /e/s
md jni\sdl
xcopy ..\SDL2-2.0.3\*.* jni\sdl /e/s

Now we need to set some environment variables.  Again this is where my stuff is, yours may be different.

set NDK_ROOT=C:\android-ndk-r10d
set ANDROID_HOME=”C:\Program Files (x86)\Android\android-sdk\”
set PATH=%NDK_ROOT%\apache-ant-1.9.4\bin;”C:\Program Files\Java\jdk1.7.0_79\bin”;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools;%PATH%

Now we need to edit the jni\src\Android.mk and point it to your sources.  In this case I’m using dinomage.com‘s simple main.c &  image.bmp as I haven’t written anything exciting yet. Change YourSourceHere.c, to main.c

Now copy in the image.bmp file into the assets directory:

md assets
copy image.bmp assets

Now we can fire up the native compiler tools, and by default it’ll compile for ARM thumb, ARM v7a, and x86

..\ndk-build

Now for the java.  Android is a java platform, so now we have to compile the wrapper that calls our C/C++ code.  First we have to set what version of Android we are compiling for:

android update project –path . –subprojects -t 12

And now we compile with ‘ant’ by typing in:

ant debug

And if all goes well you’ll get:

BUILD SUCCESSFUL
Total time: 2 seconds

Now to run the program, we can fire up one of the emulators (you will have to configure one no doubt) using AVD.  I just clicked around, and picked something that’d launch.  The shell seems to crash a lot, but otherwise yeah.

Now to upload our application to the emulator once it is running:

ant debug install

And if all goes well, you’ll see:

install:
[echo] Installing C:\android-ndk-r10d\proj\bin\SDLActivity-debug.apk onto d
efault emulator or device…
[exec] pkg: /data/local/tmp/SDLActivity-debug.apk
[exec] Success
[exec] rm failed for -f, Read-only file system
[exec] 1985 KB/s (1028625 bytes in 0.506s)

BUILD SUCCESSFUL
Total time: 5 seconds

And on my first shot at running, it crashed.

Unfortunately SDL App has stopped

Unfortunately SDL App has stopped

Using ‘adb logcat’ on the emulator I was able to find this line:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol “signal” referenced by “libSDL2.so”…

Well it turns out signal was an inline function until platform android-21, now it’s not inline anymore. When you use the ndk r10, android-21 is used by default but it’s not fully retro-compatible with devices running former Android versions. In this case, signal can’t be found on the emulator. (It did run properly on my Lollipop phone).

Fixing this is simple just edit jni\Application.mk and add in the APP_PLATFORM line:

# Uncomment this if you’re using STL in your project
# See CPLUSPLUS-SUPPORT.html in the NDK documentation for more information
# APP_STL := stlport_static
APP_PLATFORM := android-12
APP_ABI := armeabi armeabi-v7a x86

Re-compile with ndk-build, and re-upload with ant then you are good to go.

working

working

I grabbed, and borrowed some phones around the office, including an x86 phone and yeah it works!

SDL2 test!

SDL2 test!

I haven’t even tried to cross build libraries on Windows… I suspect I should be doing this on OS X or Linux.

All aboard the VENOM hype train!

So here we go, another time for another major security threat, and this time it’s the “VIRTUALIZED ENVIRONMENT NEGLECTED OPERATIONS MANIPULATION” aka VENOM attack.  Yes it has a website, and even a logo! (Creative Commons Attribution-ShareAlike 4.0 International License)

Look at me!

Look at me!

So what is all the fuss about?  Well if you can compromise a Xen, or KVM (and QEMU) VM to run code that bangs against the floppy controller it can have a buffer overflow exploit.

fantastic.

But, I know what you are thinking, most people who KVM use guest OSs that either don’t have floppy drivers, or even explicitly disable the floppy controller.  And from the site:

an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

Oops.

But let’s calm down, first the attacker has to get root level on the VM before they can think about doing anything.  Of course this is a BIG problem for VM resellers.  Hopefully the patches will be available quickly, and they will be moderately disruptive, especially for those of us who still use virtual floppies.

The source patch has been released on the Qemu mailing list right here.

Overheating boxes…

So apparently sometimes doing ‘stupid things(tm)’ can overheat your disks, and your box… So you should always keep an eye on the temperature.

So for my benefit more so in the future, and maybe others, here is a quick script to check the temperature of the processors, disk, and any changes in /var/log/messages to see what is going on.  I guess I should make it more modular, and not hardcode stuff, but here we are.

#!/bin/bash
#
#
# Read the disk temperature

disk="smartctl -d ata -A /dev/sda  | grep Temperature_Celsius | awk '{print \$10}'"
diskt=$(eval $disk)

if [ "$diskt"  -gt 40 ];
	then
	error=$"Disk temperature is hotter than 40c it's now $diskt\n"
	else
#	error=$"Disk temperature is fine, it's $diskt\n"
	:
	fi

sensors| grep Core|awk '{print $3}'>/tmp/dat.txt

j=0

while read line
do
number="echo $line |sed 's/\.
#!/bin/bash
#
#
# Read the disk temperature
disk="smartctl -d ata -A /dev/sda  | grep Temperature_Celsius | awk '{print \$10}'"
diskt=$(eval $disk)
if [ "$diskt"  -gt 40 ];
then
error=$"Disk temperature is hotter than 40c it's now $diskt\n"
else
#	error=$"Disk temperature is fine, it's $diskt\n"
:
fi
sensors| grep Core|awk '{print $3}'>/tmp/dat.txt
j=0
while read line
do
number="echo $line |sed 's/\.\0\°C//g'|sed 's/\+//g'"
cpu=$(eval $number)
if [ "$cpu" -gt 82 ];
then
error=$"$error\nCPU core $j temperature is $cpu"
else
#error=$"$error\nCPU core $j temperature is $cpu"
:
fi
j=$(($j+1))
done < /tmp/dat.txt rm -f /tmp/dat.txt if [[ -f /tmp/messages.1 ]]; 	then 	tail /var/log/messages > /tmp/messages.2
dstring="diff /tmp/messages.1 /tmp/messages.2" 
logadd=$(eval $dstring)
if [ ! -z "$logadd" ];
then
error=$"$error\n\n$logadd"
else
:
fi
mv /tmp/messages.2 /tmp/messages.1
else
tail /var/log/messages > /tmp/messages.1
fi
if [ ! -z "$error" ];
then
echo "there are issues.."
echo -e $error > /tmp/message.tmp
mail your_name@your_domain.com -s "errors on machine_name" 
\°C//g'|sed 's/\+//g'" cpu=$(eval $number) if [ "$cpu" -gt 82 ]; then error=$"$error\nCPU core $j temperature is $cpu" else #error=$"$error\nCPU core $j temperature is $cpu" : fi j=$(($j+1)) done < /tmp/dat.txt rm -f /tmp/dat.txt if [[ -f /tmp/messages.1 ]]; then tail /var/log/messages > /tmp/messages.2 dstring="diff /tmp/messages.1 /tmp/messages.2" logadd=$(eval $dstring) if [ ! -z "$logadd" ]; then error=$"$error\n\n$logadd" else : fi mv /tmp/messages.2 /tmp/messages.1 else tail /var/log/messages > /tmp/messages.1 fi if [ ! -z "$error" ]; then echo "there are issues.." echo -e $error > /tmp/message.tmp mail your_name@your_domain.com -s "errors on machine_name"

Of course, it can and should be expanded to check up on things like SMART disk errors, and other things going on.  And of course in the crontab, something like:

*/5  *    *   *   *   /root/report.sh

To run it every five minutes.  As always it’s lacking comments, full pathing to executables, and much of anything to keep it safe.  I’m sure if I was smart I could read more from pipes and variables, but I’m old so I read from files.  If you were looking for the bash shell script expert, it’s not me. lol

Going away for a bit

So Cloudflare is hitting my site like crazy, basically DOS’ing me.  So Im going back to the old way.  And then as luck has it my DNS guy has a fit once, I move the root enteries off Cloudflare.

websitespot...

websitespot…

 

Yeah, so looks like I’m going off line, but once I get the DNS sorted out I’ll be back.

OK I’m back.  Turns out it’s someone in Hungary that has their client misconfigured.

80.64.65.25 – – [11/May/2015:11:21:17 -0400] “GET /?feed=rss HTTP/1.1” 301 496 “-” “Mozilla/6.0 (compatible; Firefox 9.0; Windows NT 5.1; SV1)”
80.64.65.25 – – [11/May/2015:11:21:18 -0400] “GET /feed/ HTTP/1.1” 200 37325 “-” “Mozilla/6.0 (compatible; Firefox 9.0; Windows NT 5.1; SV1)”
80.64.65.25 – – [11/May/2015:11:21:20 -0400] “GET /?feed=rss HTTP/1.1” 301 496 “-” “Mozilla/6.0 (compatible; Firefox 9.0; Windows NT 5.1; SV1)”
80.64.65.25 – – [11/May/2015:11:21:21 -0400] “GET /feed/ HTTP/1.1” 200 37325 “-” “Mozilla/6.0 (compatible; Firefox 9.0; Windows NT 5.1; SV1)”

I’ve had to block you, 80.64.65.25, whomever you are.

Scripted Amiga updated to version 0.82

Captain Blood on the SAE

Captain Blood on the SAE

It’s really amazing to see this in action, and knowing it’s all in javascript of all things.  The Scripted Amiga Emulator now in version 0.83 fixes sound on Chrome, bringing back that Amiga experience with next to no pain.  By default it’ll boot up AROS and various demos or game demos, but you can substitute it with any 68000 compatible kickstart ROMs, and whatever diskettes you have lying about.

Even better the source code is up on github, and now under the GNU General Public License v2.0.

Click here, and give it a shot!  Any modern browser with good javascript support is all you need to get going!

Quake One blocked

Is this happening to everyone else?

Screen Shot 2015-05-04 at 11.40.58 AM

Google blockinig

Screen Shot 2015-05-04 at 12.02.16 PM

Sophos warning

Apparently, according to Sophos, it’s Mal/HTMLGen-A, which is just some generic placeholder thing.

Safari blocking Quake One now

Safari blocking Quake One now

The generic blocked by Safari message.

Which is a shame, they just had an interesting interview with John Romero.  Oh well when this gets sorted out, for those who are brave (lol) the link is right here.

Screen Shot 2015-05-04 at 10.44.56 PM

It’s short, but an interesting read none the less.

Qemu 2.3.0 released!

While trying to build on OS X there is some errors with building pixman
Undefined symbols for architecture x86_64:

“_prng_state”, referenced from:
_main in region-test.o
“_prng_state_data”, referenced from:
_main in region-test.o

But these are some ‘test’ programs that we really don’t need or care about.  A quick way to get it to bypass these is to run

touch /pixman/test/region-test
touch /pixman/test/scaling-helpers-test

And now it’ll compile, link and everything!

DOOM!

DOOM!

And yes, it’ll run DOOM.  Although on my 2012 MacBook Air, it’s VERY slow.  But at least the audio works.

From the source code…

DEFINE_PROP_UINT32 (“iobase”, SB16State, port, 0x220),
DEFINE_PROP_UINT32 (“irq”, SB16State, irq, 5),
DEFINE_PROP_UINT32 (“dma”, SB16State, dma, 1),
DEFINE_PROP_UINT32 (“dma16”, SB16State, hdma, 5),

So for MS-DOS be sure to set the BLASTER environment variable to:

SET BLASTER=A220 I5 D1 H5 P330 T6

From the source, in case anyone cares anymore about how to run MS-DOS soundblaster stuff in Qemu.  For any OS X users, you can find my binaries here.

And to run DOOM it’s something like this (once you’ve installed MS-DOS and DOOM itself!)

./qemu-system-i386 -L pc-bios -m 16 -soundhw sb16,adlib,pcspk -hda i/doom.vmdk