unresolved symbol __imp____iob_func aka SDL 1.25 & Visual Studio 2015

While trying to build something with Visual C++ 2015 Community edition I got this fun error while trying to link:

LNK2019 unresolved external symbol __imp____iob_func referenced in function _ShowError
LNK2019 unresolved external symbol __imp__fprintf referenced in function _ShowError

So it turns out that some of the fundamental streams have changed, and when the SDL library is compiled it attaches LIBC into it, which then creates this fun mis-match.  The fix is easy, of course, just download the source to SDL 1.25, and re-build it with Visual Studio 2015.  But then you’ll get another error that /ZI and /Gy- are incompatible with eachother.  I just changed /ZI to the older /Z7 setting, and I could quickly compile SDL, copy the libs to my project and happily link & run.

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


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:

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:

[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)

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.



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.

Time for another Cockatrice release

I’ve been busy at work, but I did get some stuff done on this over the weekend, and just wanted to push this version out while there is some momentum.

The big fixes are in SCSI to support the dynamic scatter gather buffers so you can format big (lol) disks.  Then again I only tested a 2GB disk but it’s working fine as far as I can tell.

I also hard coded SCSI id #6 as a CD-ROM.  It only reads HFS partitioned images, and only can boot from a handful of those.  From some SCSI CD emulation packages with passthru it performs just as poorly, so it’s not just me.  I tested with the ‘blessed’ Win32 build 142, with ForceASPI in a Windows XP VM with emulated SCSI CD.  There is a lot more ‘magic’ going on with the cdenable.sys driver on the Windows side, which mounts ISO’s without any hesitation.

This also includes my latest networking fixes as I moved more of the networking code to use queues, forced the 60Hz timer to hit the network card so it won’t stall anymore, and added in that timer patch, that more than doubled my LAN download speeds.

I’ve also added a simple PCAP filter as I noticed that my LAN was quite chatty, and I figured all this traffic wouldn’t be good as an emulator really shouldn’t be processing stuff it doesn’t need to.  Something like this:

(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:16:48)))

09:00:07:ff:ff:ff is the AppleTalk broadcast address, ff:ff:ff:ff:ff:ff is the typical all hosts broadcast, and I’m still generating a MAC based on PID which is good enough for me.


Feel the need for speed!

So while before downloading 124MB on my LAN took 8 minutes, now it’s about a minute.

I’ve updated the sourceforge page with source, Win32, Linux i386 and OS X (10.8) builds. I’ll add a 10.6 x86/PowerPC build later.  On the sourceforge page I also added a utilities section with a simple ISO image with various utilities to get you started, including the A/UX partitioning tool to partition & format a virtual disk, a tool to try to mount ISO’s (remember HFS has the only hope right now), QuickTime, Flash, Internet Explorer and some other stuff.

Also, thanks to Peter, it’s also available on github, so my horrific edits are open for the world to see…

Announcing Cockatrice III

Well I was shuffling files back and forth into Shoebill, and with the advent of Ethernet support, I decided I wanted to build an AppleTalk network.  This endeavor seems to have taken a life of it’s own.

So, the first thing I did was tear into minivmac, as I figured it would be the easiest to modify, as ‘mini’ is in it’s name.  But it’s more geared to LocalTalk.  From it’s readme:

It does this by converting the LocalTalk packets between SDLC frames in the virtual machine to LocalTalk Over Ethernet (LTOE) packets.  These LTOE packets will be sent out the host machines Ethernet interface and will reach any other machine on the LAN.  LTOE packets are not routable and not recognized by EtherTalk devices.

Which is pretty creative, but I want to talk to A/UX, Windows NT and Cisco routers.  So this isn’t going to work out for me.

The next other ‘big’ names in Macintosh emulation are Basilisk II and SheepShaver.  Both of which are from Christian Bauer which is a sizable download (or so I thought) and has a very confusing release versions for Windows. So I went ahead and tried BasiliskII, which only does some native networking via a TUN/TAP & bridge solution (which is really popular solution for plenty of UNIX based stuff), which personally I don’t really care for.  The Windows version does support SLiRP, but for some strange and annoying reason it always crashes when I try to download anything big.  As a matter of fact, the Windows version crashes, a lot!

While digging around for various builds of Basilisk II, I found the defunct sourceforge page, which is thankfully still up.  And there I found the 0.8 and 0.9 release source code, which weighs in at a tiny 350kb in size.  This is something I could probably dive into.  So I went ahead and tried to build it on a Debian 7 x86 VM.  And much to my surprise, after altering configure to accept GCC 4.7, and forcing it to turn X11 on (I don’t know why it kept failing to detect it), I was able to build a binary in no time.  Even better, it worked!

So the first few goals were simple, I wanted to take 0.8 and remove it’s dependency on X11,and make it use SDL 1.2.  Why not SDL 2.0?  Well 2.0 is more about 3d space, and even to render a flat framebuffer it uses streaming textures.  Which is too heavy for me, so I’m sticking with 1.2.  I took a bunch of code from SDLQuake, and after a while of bashing it around, I was able to open a window, and capture some ouput from the framebuffer.  With even more bashing around I got it to work correctly.  I did make some small tweaks though, it only supports 8bit depth.  But I’m interested in networking, so 256 colours is fine by me.  Now that i could see what I was doing, I was able to then re-compile on OS X, and I was greeted with the Mac Boot screen.  The harder part was Windows, as the system code written by Lauri Pesonen who did an excellent job of porting BasiliskII to Windows, but to say their code took 100% advantage of the Win32 API would be an understatement.. And I wanted something more pure to being SDL so I really couldn’t use much of that code.  And what code I could find it was for far later versions.  However with enough pushing I did finally get BasiliskII to boot up on Windows.  I was once more again bitten by the fact that open on Windows defaults to being in ASCII mode.

The next thing to add was SDL input for the keyboard and mouse.  And at this point googling around for an example of an input loop for SDL that is appropriate for an emulator I stumbled uppon the fact that there already was a SDL support built into the more current version of Basilisk II.  But for some strange reason I kept going ahead, and incorporated some of the code into my 0.8 branch.  And then I could finally send some keystrokes, move the mouse, and click on things!  Things were looking up!

While looking at the SDL code, I did see they also have audio support, so I went ahead and borrowed the skeleton framework from there, although the initialization didn’t work at all as BasiliskII had drifted in how it hooked into the native sound support.  So I once more again turned to SDLQuake, and I was able to initialize sound, and Even get QuickTime to play the old Quadra quicktime video, which was the first QuickTime thing I’d ever seen, back when they were still making Quadras.

So now with video and sound in place, it was finally time to tackle the networking.  At first this seemed quite easy to do, and using SIMH for inspiration I was able to quickly replace the tun/tap code with some pcap code to open the interface, send packets, and receive packets.  One more again I started on Linux, made it build on OS X, although my MacBook air doesn’t have anything I can really inject packets into so I don’t know if it actually works.  The bigger test for me was on Windows with a GNS3 network, and with a few more minor changes I was happily sending AppleTalk to both Shoebill and Windows NT.

The next thing I wanted to tackle was SLiRP support.  Ironically to bring SLiRP to Shoebill I used the SLiRP from the github of Basilisk II.  At this point I figured this would be very simple, and I could wrap up later that day.  It ended up taking me three days.  Once more again my build would crash all the time, just like the later Basilisk II builds.  Using Internet Explorer 4.0.1 would seemingly crash the whole system within seconds with faults in SLiRP’s slirp_select_fill, and slirp_select_poll functions.  Now if you don’t call these functions SLiRP doesn’t process it’s TCP state and you end up with barely functioning UDP to only SLiRP which isn’t great beyond DHCP and DNS.  First I tried semaphores which only made things worse as the nature of Basilisk II’s threaded nature just made the requests stack up deadlocking within seconds.  I tried a mutex, timed mutexes and various other locking methods insdide of SLiRP and Basilisk II to no end.  Netscape would kind of work, but IE would crash the whole thing out after a few pages. Then a better solution hit me as I was playing with the system clock on the Windows build.  There is a 60Hz timer that calls a 1Hz timer once every 60 ticks.  What if I had the clock drive SLiRP?  And to my amazement not only did that work, but it worked great until I hit another problem that I had with Shoebill (that needs to be fixed now that I found away around it here).  There is a static buffer that passes data between SLiRP’s callback when it is going to send a packet to BasiliskII and when Basilisk II then feeds the packet to MacOS.  With enough traffic it will overwrite part of itself as they are on two different threads.  Once more again I tried semaphores, which of course is the wrong tool here as if something is stacking waiting for it to unstack is just crazy, and more mutexes.  The mutexes kind of worked but performance was horrible, as in 1992 dialup speed horrible.  And I didn’t want to simulate a 1992 internet experience 100%

So the obvious solution as a queue.  I took a simple queue implementation, added the ability to peek, changed it to accept a packet structure and I was set.  Now I only needed a mutex when I queued items, and dequeued them.  But I could hold 100 packets easily.

So with all that in place I can finally download files greater than 10MB, and even with Internet Explorer!


124MB in 8 minutes!

So the next was to make Pcap dynamically loaded, which for C++ is a bit of fun with __cdecl, GetProcAddress and all that fun.  But I had it working after a bit so now if the user doesn’t have WinPcap installed they don’t get an error message, and I don’t have to maintain two builds.  Nobody likes doing that kind of stuff.  Ever.

Multitasking.. Kind of.

Multitasking.. Kind of.

There is still plenty of things broken afterall I’m using an ancient version of Basilisk to base this off of. I’ve also removed a bunch of features as I wanted to make this more of a ‘core’ product with again a focus on networking.

Will this interest the majority of people? Probably not.  But for anyone who wants to actually download a file this may be somewhat useful.

Where to go from here?

Well there is still a lot of OS specific stuff in the code that I want to convert to SDL.  I’d like to build from a 100% more generic code tree rather than having private files here and there.  The CPU optimization programs that re-read GCC’s assembly output don’t do anything.  I want to try it through an older version of GCC and see if there is any difference in speed.  I also recently received the source code to vc5opti.cpp and I’d like to try that to see if it speeds up the Windows Visual C++ based build.  Long term I’d love to patch in the UAE CPU code from the newer versions that have a far more solid 68030/68881 and 68040 emulation.  The price of standing on so many tall shoulders is that when I fall off I don’t know if the CPU exceptions I see are faults in the CPU emulation, Basilisk II or just plain crashes in MacOS which was certainly not the most stablest thing once you mixed in multimedia and networking.  It was par with Windows 3.1, which honestly both of them were ‘saved’ with help from the older generation, ala BSD Unix for MacOS, and the VMS team for Windows.

So after all this I’m ready to release some binaries, and code.  Although the last thing I wanted to do is add more confusion by calling this Basillisk II v0.8.SOMETHING … A quick google search on Basilisk gave me this:

As for some reason I actually never did look up what a Basilisk was.  So seeing that this project is basically the same thing I chose Cockatrice.

The Cockatrice III source forge page is here, Windows binaries, Mac OS X binaries, and source code here.

There are plenty of bugs, and plenty of things not working, but it works well enough to do things, and that is a credit to everyone who worked on Basilisk II before me.

8086tiny 1.25 has been out for a while

now, and I figured I should see if I can get it running on NT 4.0…

There was some minor issues with the way it handles for loops, but making them more C89 friendly was trivial.

8086tiny on NT 4.0

8086tiny on NT 4.0

You can download my project (source and binary) here.  The ‘killer’ feature is that it being built with Visual Studio 97 on NT 4, the needed Visual C++ LIBC DLL ought to be in place on anything modern these days.

You can always find the home page for 8086tiny, right here, at megalith.co.uk.  Code is maintained on github.

SDL 1.2.15 not working with Visual Studio 2003 (2002, 6, 97..)

Well yeah fun errors like this:

SDL “error LNK2001: unresolved external symbol __alloca_probe_16”

What gives? well the binary kit was built using 2005 (I guess) something higher.

Download and link against SDL-devel-1.2.13-VC6.zip and all will be happy.  I suppose you could build the source yourself, but who’s got time for that?

And remember to set your project to use the Multi Threaded DLL libc, otherwise you’ll get errors like this:

LNK2005: __isctype already defined in LIBCMT.lib(isctype.obj)
LNK2005: _exit already defined in LIBCMT.lib(crt0dat.obj)



Well today I got my new Dec Alpha running!

Ok, my friends say I’m insane to have bought this… but I couldn’t resist.

It’s a DEC Alpha 221164 machine, with 64MB of ram, and a 4GB disk!

It’s the best technology of 1996-1997!

So I’ve gone ahead and installed Windows NT 4.0 on the beast… at 600Mhz it’s pretty dammed fast… considering how old it is. Although I suspect a Pentium III I found in the garbage with a 1Ghz cpu is 2x faster…..

But at any rate, this is a DEC Alpha, the long time geek cpu of dreams etc…
What makes this slightly useful for me, is that I do have Visual C++ 4.0 & 6.0 for the Alpha. So at least I can build *SOME* stuff to run on the thing….

So I’ve been fighting the compiler, and it seems it’s default blended optimizations do *NOT* work on my machine.. I’m sure this will be fun down the road. However it seems setting the target cpu to the 21064 produces ok code.. I’ve got to bench the stuff, but at least my exe’s are not crashing.

So what have I manage to produce today so far?


unzip is a major one.. It’s hard to use a machine today without it.

The other thing I’ve manage to get running, is Quake! I’ve included my source & project trees as it was a feisty little thing to build..

I’m currently building & testing over terminal services so I don’t know what the speed is on the console… Also, this build does not include networking… I’m sure the winsock code will work just fine, I’m just not in a good position physically to test it, as Quake1 will *NOT NAT* correctly.. Also the SDL sound doesn’t actually output anything, so I’ve built it with the null sound driver..

I’d love to get that m68k->C build of frontier elite to go on the Alpha but I’m afraid my 64mb of ram will be a major constraint..

I know this isn’t much of an emulation thing, as the only emulator that possibly can run Windows NT for the Alpha costs upwards of $16,000 USD… It’s cheaper to score an alpha on ebay for $100 USD.

Well here is the screen shot…

Quake on the Dec Alpha


I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.

Quake for the MIPS (NT4)

Well I started this off hoping I could get Quake running on Windows NT 3.1 … I’m almost there I have the null version running just fine. However I’m not all that great with DIB programming so I was looking thru SDL and saw that it has a WINDIB driver!

So with a LOT of tweaking through SDL 1.2.13 I got it to compile with Visual C++ 1.0!! However it is lacking one critical call, the CreateDIBSection api call in GDI is not present in NT 3.1. So remembering all the MIPS stuff as of late, and that I have Visual C++ 4.0 which should easily support this call, I first got it running with Visual C++ 2.0 on the i386 (Under XP of all things). So it was just a matter of building the source, and making sure there is no errors, uploading it to the emulator, and rebuilding for the MIPS.

And after 30 minutes, I got my exe, and it ran!

Quake 1.06 on the MIPS/NT

Quake 1.06 on the MIPS/NT

I’ve included a link for any other MIPS people out there that want to play quake. I haven’t built the networking as I was having issues with my network earlier and couldn’t get it working…

The exe is available here.

And the source code with all the bits is right here.

In this build I’m not building SDL as a DLL or static library, but rather compiling Quake right into the source. Now that SDL is running on the MIPS, and possibly other Win32 OS’s (I have yet to test Win32s… I suspect the inherent threading in SDL will prevent it, but could the DBI calls be made directly stripping out SDL…?) but who knows, I think anything past 3.51 would work.