ax86
Main Page
Blog
Downloads
Credits
 

ax86 - Blog

June 28th, 2014 - New subdomain for pax86

Just a short blog post, letting you know that I have created a new subdomain pax86.patrickaalto.com for my pax86 x86 emulation core, which I have commercially licensed to a few parties. I also moved the blog posts that relate more to pax86 than to ax86 from this blog to my new blog for pax86. Check out the new pax86 blog if you are interested in it!

Here is a video capture of my Asus Nexus 7 Android tablet running Doom in pax86:

May 5th, 2013 - GCW Zero port started

During the past week I have not worked much on ax86, as I got my new GCW Zero "engineering sample" game console. I began porting my DSTwo version to that device, and that has taken pretty much all of my free time for the past week. I plan to continue working on this during the following week as well, so my work on ax86 is still on a break until I get something running in the GCW0 as well.

Working on GCW Zero is interesting because it uses a processor that has a MIPS32r2 architecture. This Release 2 version of the architecture brings a couple of very powerful and useful new opcodes to the MIPS ASM language, namely EXT and INS. I can use these new opcodes in quite a few places in my code to speed up the emulation, so I am very interested to see how fast zerox86 (current working name of the project) will run on the device.

I began my porting project by first porting my unit test program. I then began changing the code to use the new EXT and INS opcodes where possible. After a few changes I run the unit test program to make sure I don't break anything, and then continue making the changes. Since I use the unit test program from the special 386-enabled DSx386 version, I have also needed to fix some incompatibilities between the unit test program and my old DS2x86 sources. The current status is that opcodes 0x00..0x0E work fine, and I am working on the 386-specific 0x0F group opcodes, mainly fixing those incompatibilities.

Apr 21st, 2013 - (Lack of) ax86 progress

Sorry for the lack of updates for the past few weeks, but I have still been working on the Raspberry Pi version of my emulator. I have not done anything else to ax86 besides checking that my changes to rpix86 have not broken anything in ax86 (as they share most of the source code).

I again hope to focus more on ax86 in the future, but as I just released version 0.06 of rpix86, it is possible that I need to continue fixing bugs in it, in case I broke something or the new features do not work as expected. I will try to write short blog posts like this on here as well, though, even if I don't currently work much on ax86.

Mar 31st, 2013 - ax86 progress

After I released version 0.03 of rpix86 last weekend, things were pretty quiet for a few days on the rpix86 side, so I decided to work on ax86 for a while. I had added a feature into rpix86 where it downloads (after asking a confirmation from the user) the 4DOS.COM command interpreter if it is not found on the disk, and I wanted to have similar feature in ax86. So, I started reading Android documentation about how to add dialogs and how to download files. It turned out that both of those things are reasonably simple to accomplish, and after spending a couple of evenings working on them, I had a working system in place!

When ax86 starts, it attempts to find 4DOS.COM from either the internal data storage, or from the SD card storage area. If neither locations have it, ax86 displays the above dialog. Clicking on Cancel will quit ax86, clicking on Download will start downloading 4DOS.COM. This phase shows a progress bar dialog while the file gets downloaded. After 4DOS.COM has been succesfully downloaded, ax86 starts running the main emulation code and presents the DOS prompt. I am thinking that this dialog could perhaps also have a third button, "Choose directory", in case the user already has a directory reserved for DOS software and wants to use that for ax86.

In the middle of last week I suddenly began to get lot more emails and forum messages about rpix86. This increased acticity was caused by several major technology news sites suddenly releasing an article about rpix86, so I got thousands of hits per day into my web site! I decided to switch back to working on rpix86 because of this increased interest in it. I will try to keep working on ax86 as well, though, so that I can eventually release it publicly as well.

Mar 24th, 2013 - ax86 progress

During the past couple of weeks I have been mainly fixing issues in the Raspberry Pi version rpix86 of my emulator. I just today released version 0.03 of it, and I hope that this version will now be able to support most of the possible keyboard/mouse input devices. My plan is to now move my main focus back to ax86, as I have been neglecting it for a while now. Of course all the changes and fixes I have made to rpix86 in the core emulation features will also affect ax86, but I have also spent quite some time working on the rpix86-specific features.

I did spend some time last week working on ax86, though. I started by first implementing the same audio features as what I did for rpix86. Currently they both can play SB digital audio and PC speaker sounds in addition to the AdLib support that has been working for a while already. I also noticed that Doom kept crashing randomly after I added the digital audio features to ax86. Since the addition of digital audio should not have caused any changes to the core emulation besides sending interrupts more frequently, I took a closer look at the interrupt synchronization, and noticed that I did not have proper mutex locks in one part of the interrupt handling system. I added the mutex locking and Doom stopped crashing. It is now quite nice to play Doom on my Android tablet, as it runs pretty fast and now also plays all the audio properly.

I had (somewhat stupidly) named my Android project "ax86Test" instead of "ax86" when I created it, so next I decided to rename it to the proper name. I don't need to keep it as a "test" project any more, as I am pretty sure it will actually work. :-) However, I made a mistake when renaming it, so that the whole project got lost from Eclipse. It took me a while to get it loaded and fixed again, but now after the renaming I noticed that it crashes if it does not find the 4DOS.COM command interpreter. Since my plan is to have ax86 automatically download 4DOS.COM if it is missing, I think this is now a good time to work on that feature. In rpix86 this was easy to do, I can simply call system("wget ftp://ftp.jpsoft.com/4dos/files/4dos.com"), but I think I will need to do this somewhat differently in Android. I will also need to let the user determine what directory to use as the C:\ root directory, what sort of a keyboard emulation to use, and so on. Quite a bit of work that is specific to the Android environment.

Mar 10th, 2013 - ax86 progress

Nothing much has happened on the ax86 front during the past couple of weeks, as I have been focusing on getting rpix86 released. I have now submitted rpix86 to the Raspberry Pi Store Community Approval Process, so I should be able to get back to working on ax86, or at least on features that are needed in both. Currently the Sound Blaster digital audio features are implemented only in rpix86, so I need to add those to ax86 next. After that I will need to add a configuration page to ax86, as it can not use a similar command line parameter system as I made for rpix86.

Feb 24th, 2013 - ax86 progress

The week after my previous ax86 blog post was spent mostly getting rpix86 up to the ax86 level. During the last week I have then been working on both rpix86 and ax86, mostly fixing bugs in either one of them. During the previous weekend I noticed that my AdLib audio emulation did not work correctly on ax86, for example in Leisure Suit Larry 3 the intro music did play fine, but then there was only intermittent audio during the actual game. When I was debugging this I suddenly noticed that I had forgotten to adjust the modulation levels to take into account the sample volume levels that are lower than in DSx86 (this lower volume level is needed for the software channel mixing)!

After I adjusted the modulation volumes, the audio began to sound much better on rpix86, but still there was the problem of missing notes on ax86. I made all sorts of tests but still did not manage to find the cause, until I then finally decided to test the exact same AdLib emulation code (slightly optimized for ARMv6) in ax86 that I used in rpix86. It did play the audio correctly! So, the problem was obviously in some of my non-ARMv6 code, and now that I had only a very limited amount of code to check, I finally found the problem. One of the sample loops mixed the audio properly in the ARMv6 code, but simply overwrote the samples in the ax86 code! This was relatively easy to fix, so now the AdLib audio works correctly in both versions.

The next problem was that rpix86 (which uses the OpenGL ES 2.0 vertex and fragment shaders for palette handling) did not seem to show all palette values correctly. I compared the same DOS games between ax86 and rpix86, and was able to determine that the problem is indeed in the shader code, since ax86 did show the palette correctly. After some adjustments (hacking, to be honest, as I am still very unfamiliar with the shader language) I managed to get the palette values to get converted correctly, so that both ax86 and rpix86 both display the same colors, even though one uses hardware and the other software to handle the palette lookup.

Next, I worked on switching the text mode to use 8x16 pixel character font also in ax86. I had used the original 6x8 characters from DSx86 in ax86, and the better looking 8x16 fonts only in rpix86. My eventual goal is to have ax86 adjust the character size based on the physical Android device screen properties, but for now I am using the 8x16 fonts (meaning the text mode screen is 640x400 pixels) always in both versions of my emulator.

This Saturday I then began working on one of the remaining major issues, Sound Blaster digital audio emulation. I am porting the routines from an old version of DS2x86 (which still used the original DSTwo data transfer system) as I need to have somewhat similar buffering scheme. I am also using parts of the DSx86 code, as it is written in ARM assembly instead of MIPS assembly in DS2x86. So, in effect I am combining the algorithms from DS2x86 with the actual code from DSx86. :-)

I already managed to get the easiest digital audio mode, simple one-shot DMA output, working on Saturday. I used Supaplex and my own LineWars II to test this, and both of those games now play audio fine. It was nice to again hear the original music by u4ia in my LW2. :-)

Today I have been working on getting the auto-init DMA system working. This is considerably harder, as it is very timing-critical to not get buffer underflows or overflows, and still make the emulated game think that the audio runs at some quite different speed to what the actual hardware is playing the audio buffers at. I am using Doom for these tests, as I am familiar with how it works (it plays a 4096-sample buffer at 11.1kHz, with an IRQ request after every 128 samples have been played). Converting this to my double-buffered 2048-sample buffers running at 32kHz is somewhat difficult, and I have not yet managed to get it working perfectly. It does already play recognizable audio, but it still has some stuttering and occasional skipping.

During the next week I will continue with the audio features, for example all the ADPCM digital audio formats are still missing. Then the most essential features have been implemented, so I will just need to spend some more time testing and creating some configuration options and settings, before I could release the first beta version. I don't think floating point support is essential for the first beta, as not very many DOS games use floating point operations.

Feb 10th, 2013 - New subdomain for rpix86

Today I created a new rpix86.patrickaalto.com subdomain for rpix86, just to keep it and ax86 properly separated when writing these blog posts. Even though they share most of the same source code, they are still completely different software targeting different operating systems, so I think it will be less confusing if I keep them separate on my web pages as well. :-)

Feb 3rd, 2013 - ax86 progress, rpix86 started!

I have managed to work quite a bit on ax86 during the past two weeks. Here is a list of the more inportant changes I have managed to implement:

  1. Better file system support. Since the EXT3 file system used in linux is case-sensitive, my file routines from DSx86 (which only supported FAT file system) had problems handling files that were not in all capital letters. I improved my file routines so that if a requested file (which in the internal DOS routines is always in all upper case) is not found from the file system, ax86 scans the directory, converts each found file to upper case, and then checks if this is the correct file. This will of course take much more time than directly accessing the file, so it is still a good idea to actually have all file names in all upper case.

    I still have a problem with the directory scanning routines. Currently I re-open the directory and skip a number of files for every DOS FindNext call, when I think that a better and faster approach would be to open the directory once on the FindFirst call, read all the files into a memory buffer (perhaps a linked list), and then use this linked list when DOS calls the FindNext routine. The current system is very slow with directories that contain hundreds of files, and also causes problems when deleting files. Every time you do a DEL *.*, the current system deletes only HALF of the files (because a file that the routine skips over has already been deleted, it skips over the NEXT file instead of the CURRENT file). So this still needs to be changed, but still the new file system support now allows me to test much more games.

  2. AdLib audio support. This is what I spent the previous weekend on. I was able to mostly use the AdLib emulation routines from DSx86 (where the emulation runs on the ARM7 processor), but instead of using 9 separate hardware audio channels (with 9 separate sample buffers) I needed to change my code so that it mixes the output of the 9 AdLib channels to a single buffer which is then sent to the Android OpenSL system for output. This was relatively easy to do, and I managed to get audio out pretty soon, but the quality was very poor.

    It turned out that in order to get rid of the clicks and stuttering of the audio, I needed to increase the buffer size to 2048 samples! In DSx86 I had a buffer size of 64 samples, so this was a major change to the code. In DSx86 the small buffer allowed me to handle the AdLib note commands between buffer fills and still not cause any audible problems with the note timing. The audio latency caused by the AdLib buffer filling was only around 2ms, while now with the 2048-sample buffer the latency is 64ms. Such a high latency causes very audible problems when handling note events only at 64ms intervals. Thus I needed to add a time stamp for every AdLib note event, and then interleave the buffer filling and note event handling so that the notes get handled at their correct relative times. This fixed most of the audio problems, but of course does not get rid of the actual latency, which is quite noticeable when a game plays sound effects with AdLib audio. I don't think there is much that can be done about this, though.

  3. Last weekend I also ordered an IVSOŽ Wireless Bluetooth Keyboard Case For Google Nexus 7 Tablet from Amazon, which then arrived already on Tuesday via DHL (quite a fast delivery considering I ordered it via Free SuperSaver Delivery option)! Some reviews on Amazon mention that it does not have a Tab key, but at least my version does, so it is quite a good match to ax86. I spent Tuesday and Wednesday evenings coding support for a Bluetooth keyboard into ax86, so now controlling games is much easier and simpler than using the on-screen virtual touch keyboard. This also meant that my improving the inbuilt touchpad keyboard went down in my TODO list priority order. :-)

  4. On last Thursday I then decided to order a Raspberry Pi computer, as I have been toying with the idea of porting DSx86 to it as well as to Android. It arrived on Friday, and I could not resist the temptation to start working on it immediately. Thus I began to experiment with porting my current ax86 version to it. The Friday evening was spent in an attempt to create my own Makefile system to compile ax86 (or rpix86 as I decided to call it), but after miserable failures and considerable frustration (it turns out I am really NOT a Makefile guru!) I decided to copy the Makefile system from Nintendo DS DevKitARM pretty much as-is, as it seems to work nicely and I am familiar with it. Using that I got practically all the code to compile on Friday, but the hardware-specific stuff was still missing, so it did not actually run yet.

    I continued this work on Saturday, and finally by Saturday evening I was able to get 4DOS to start up inside rpix86 on Raspberry Pi! I still don't have any input (like keyboard) support on the Raspberry Pi side, so I just adedd a frame counter that exits the program after a few seconds, but still it was nice to see that I can use pretty much the same code for both Android and Raspberry Pi. From now on I think I will work on those two versions side by side, as I added some compile defines to places where I need to do things differently between those two, and most of those places are in a single source code module which contains the native interface.

    It also looks like I will be able to do some development things (like using a cycle counter to help me optimize some routines) more easily on the Raspberry Pi than on Android. Eventually I will probably want to add some processor-specific optimizations to my code, so that will cause differences between the versions (since RPi has ARMv6 and modern Android devices have ARMv7 processors), but for now I can work on both at the same time.

Next I will probably spend some more time on the Raspberry Pi side to get it at the same level with the Android version (namely to get keyboard and AdLib support working), after that I need to add mouse support and floating point support to both, as those are the things that currently limit the number of games I can test on ax86/rpix86. Then I will need to add SoundBlaster digital audio support, implement the missing graphics features, and so on, so there is still quite a bit of work ahead before the eventual public release.

Jan 20th, 2013 - Doom in ax86

During the past two weeks I have been working on the Mode-X and EGA graphics mode support. I got Mode-X support working already last weekend. As soon as I got the most common Mode-X graphics mode opcodes implemented, I wanted to see whether Doom would run in ax86. The first problem I ran into with Doom was that it tried to detect the type of the floating point coprocessor. This is part of the DOS4GW initialization routines, so even though Doom itself does not use floating point operations, the DOS extender wanted to detect the FPU type. I have not yet added any floating point support into ax86, so I had to add some hacks to simply bypass those FPU operations that DOS4GW uses. This allowed Doom to progress slightly further.

The next problem was that Doom complained "Not enough available XMS memory", which was a bit weird since I had allocated (or so I thought) 16MB of RAM for XMS emulation. After some debugging it turned out that I had made a silly mistake, I meant to allocate 16MB of memory but I only allocated 16KB of memory for the XMS emulation! No wonder that was not enough for Doom to run. Next I ran into an unsupported protected mode far call opcode. I had not implemented all protected mode opcodes when I ported the 386 features from DS2x86 to the Raiden Legacy core, and this was one of those unimplemented versions. Implementing it was pretty easy, but then I ran into a more difficult problem.

I fought the whole of last Saturday with a weird problem where protected mode SS (stack segment) register got an invalid value. I used both my DS2x86 and DOSBox to help me in checking what the correct value should be, but the problem was that those two did not even call the routine where this invalid SS value problem happened! So, this was obviously some more serious and difficult to find problem in my code. After a considerable amount of backtracking I finally found a routine that does get called, and was then able to follow the program flow and see where the code paths differ. Finally I found the problem. There are five similar opcodes that load both a segment register and a general purpose register simultaneously. These are called LES, LDS, LSS, LFS and LGS. I had separate 16-bit and 32-bit handlers for each of those, but for some peculiar reason the 16-bit LDS handler did not have the protected mode code at all! I don't quite understand how and why I could have skipped implementing that, but at least doing that fixed the problem in Doom.

After fixing that I ran into an architectural problem that was caused by my using statically allocated first megabyte of RAM, but a dynamically allocated XMS memory block. This caused those two memory blocks not to be adjacent, which in turn caused problems in some of my memory handlers. I decided to have all my emulated RAM be dynamically allocated (as there is no proper reason why any of it should be statically allocated), and fixing that let Doom to start up and run the demo games fine!

The first thing I wanted to do after getting Doom to run was to run the -timedemo demo3 speed test to see where my ax86 stands in relation to the DOSBox Turbo performance estimates. I got a result of 2715 realticks (27.5 fps) on my first run, and during the subsequent several runs the speed varied between 2707 and 2738 real ticks. Comparing the results with the DOSBox Turbo results (I copied the table below from the afore mentioned link and added ax86 results to it) shows that ax86 reaches speeds reasonably close to those of DOSBox Turbo, however since I don't yet have any audio support, it is very possible that the ax86 results will get somewhat poorer. On the other hand I still don't have any ARMv7 optimizations, so if I figure out some such I might reach higher speeds. In any case it looks like DOSBox Turbo is indeed really well optimized, I wouldn't have thought that the DOSBox architecture can reach similar speeds to my optimized ASM core. For comparison, I also added the results when running the Doom timedemo in DS2x86 on my Nintendo DS, and when running it in aDosBox on my Nexus 7 using all default settings. I'm not sure what settings I have wrong when my aDosBox result is so poor, but I am not all that interested in finding out either. In any case it is horribly slow. :-)

real tics avg fps SoC/CPU Type Device DosBox Emulator Remarks
665 112.3 Intel Core i7-3770k @ 3.9Ghz Ivy Bridge Desktop PC + DosBox Desktop DosBox 0.74 Doom Timedemo on PC w/32GB RAM with DosBox 0.74
1784 41.9 Samsung Exynos Quad-core @ 1.6 Ghz Samsung Galaxy Note II DB Turbo 1.5.1 Stock Rom
2128 35.1 Tegra 3 @ 1.5 Ghz Nexus 7 Tablet DB Turbo 1.5.0 AOKP (JB Build 3) overclocked to 1.5 Ghz.
2193 34.1 Tegra 3 @ 1.5 Ghz Nexus 7 Tablet DB Turbo 1.4.3 AOKP (JB Build 3) overclocked to 1.5 Ghz.
2715 27.5 Tegra 3 @ stock 1.3 Ghz Nexus 7 Tablet ax86 No audio support yet!
2716 27.5 Samsung Exynos 4210 Dual @ 1.4 Ghz Samsung Galaxy Note DB Turbo 1.4.3 sound device = soundblaster 16 (need to retest w/SB2)
2916 25.6 Tegra 3 @ 1.5 Ghz Nexus 7 Tablet AnDosBox 1.2.8 AOKP (JB Build 3) overclocked to 1.5 Ghz. Emulation Mode = Speed in AnDosBox settings.
12320 6.1 Tegra 3 @ 1.5 Ghz Nexus 7 Tablet aDosBox 0.2.5 AOKP (JB Build 3) overclocked to 1.5 Ghz.
14352 5.1 MIPS @ 396MHz DSTwo cart DS2x86 0.37 DS2x86 on Nintendo DS, for comparison
30961 2.4 Tegra 3 @ stock 1.3GHz Nexus 7 Tablet aDosBox 0.2.5 Default aDOSBox settings on my Nexus 7

This weekend I have been working on EGA support, and have just managed to get Commander Keen 4 starting up and running the demo games. It is one of the more complex EGA games, as it uses various EGA hardware tricks for smooth scrolling and panning. I still have many less common EGA opcodes to implement, same as some Mode-X opcodes, so those will keep me busy during the next week. After those I think the most important thing to add will be proper file system support, so that I don't need to rename all the files in my test games to be in all capital letters. After that I will be able to test much more games, and then it would be time to add some audio support.

So, lots of work still remaining, but I think ax86 is progressing nicely. :-)

Jan 6th, 2013 - Work started on ax86 (Android x86 emulator)!

Since my previous DSx86 blog post at dsx86.patrickaalto.com, I have begun working on ax86. I have been on a two-week Xmas vacation which is just ending, and I have been able to work on ax86 several hours per day during my vacation. It has progressed quite nicely, although there is still a huge amount of work remaining, so do not expect a public release version for a while yet. :-)

I spent the first couple of days of my vacation simply getting a "Hello, World" -style Android application running. Even this first "Hello world" application did however already contain my 386 emulation sources from Raiden Legacy, but the problem was that I did not know how best to interface to them from Java. I am reasonably familiar with Java, but not with the Android specialities, so I began searching for tutorials on the net. I found a blog post by Richard Quirk, which seemed to be exactly what I was after. He also moved on to Android programming after coding for Nintendo DS, so it was easy to follow and understand his code and techniques. On the 26th of December I got my "Hello world" application (which was mostly based on his example code) working on my Asus Nexus 7 Android tablet, so I was in business!

The next couple of days were spent studying the example code and figuring out ways to add my own code to it, porting the BIOS and DOS emulation stuff (which had not been needed in Raiden Legacy) from Nintendo DS to Android, and such. I also needed to code the text screen blitting code, so that it converts the PC text mode screen character buffer to RGB565 format used by the Android OpenGL system. Then finally on the 29th of December I got 4DOS.COM starting up in Android!

I am still using the original 6x8 pixel font from DSx86 in the text mode (so that the 80x25 text screen is actually 480x200 pixels, which is then scaled to 800x600 resolution for my tablet's 800x1280 screen). I am thinking of using different character sizes in the text mode depending on the actual size of the device screen, so that I could support screen widths of 320 (4x6 font), 480 (6x8 font) and 640 (8x16 font) pixels natively, with the scaling becoming active only for resolutions beyond those values.

The next step after I got 4DOS running was to add a virtual keyboard. I didn't want to use the default Android virtual keyboard as it does not have enough buttons to emulate a proper PC keyboard. I created my own preliminary keyboard, which is currently sort of working but very awkward to use even on the large 800x1280 7" screen, so I still need to work on the usability of it. I am also considering purchasing a bluetooth keyboard, so that I could add support for that as well.

Anyways, after I got 4DOS running the next goal I had was to have Norton SYSINFO running, so that I could get some kind of an idea as to the emulation speed I could achieve. This required me to first create proper timer IRQ handling (as SYSINFO obviously uses the timer to calculate the actual processor speed). This was the thing that I had been most worried about, because in DSx86 I could simply use the NDS hardware directly for all my timer and interrupt needs, but that was not possible on Android. After some studying some of the options available on the Android environment I thought that I could perhaps have a separate thread running, which would be sleeping between the timer intervals, and then set a timer IRQ flag in my core whenever the timer interval has passed. I ended up using the clock_nanosleep() method with the CLOCK_MONOTONIC clock parameter and the timer interval calculated based on the requested PC clock. The PC clock runs at 1.193.182 Hz, meaning that the interval between each tick is around 839 nanoseconds. The default timer IRQ happens after every 65536 ticks, which equals 18.2Hz, which equals 55ms (65536*839 = 54.984.704 nanoseconds).

On the 2nd of January I had finally enhanced ax86 sufficiently so that I could start up Norton SYSINFO and go to the CPU benchmark page. The emulation speed seemed to be about equal to a 486/66 machine, perhaps a little bit faster (on my tablet which has a 1.3GHz quad core Nvidia Tegra3 processor). I had hoped that my emulator would beat DosBox Turbo, which is supposed to run at around Pentium 60-75MHz speed on similar 1.3GHz quad core Nvidia Tegra3 processor as what my Nexus 7 table has, according to the performance estimates given for it. The speed of my emulator was a bit lower than I expected, but on the other hand if you interpolate from the 66MHz CPU speed of Nintendo DS, which runs my 386-enabled core at 7.5 times PC speed, 1.3GHz should reach 147 times PC speed. So it actually is pretty fast, I had just thought that newer ARMv7 processors would be somewhat more efficient in running also plain ARMv5 code (which my core still is). Perhaps when I get around to enhancing my core with ARMv7 features I can reach faster speeds. I do still need to test with the actual Doom timedemo (when I have enhanced my core sufficiently so that I can run it) before I can know the exact speed difference between DosBox Turbo and my ax86. But in any case ax86 will be heaps faster than the free aDosBox! :-)

During the following days I then added some graphics modes, the MCGA 32x200 mode and also the VESA SVGA modes 640x400 and 640x480 from DS2x86. I again used my Linewars II game to test these, and managed to get it running in the SVGA 640x480 mode!

Linewars II runs pretty fast in that mode, as it is not synced to the screen refresh rate (when I originally coded LineWars II, PCs were not fast enough to run much over 60fps in SVGA mode), it can reach up to 500fps when there is nothing on the screen, and generally stays at or over 100fps all the time. The screen copy above is from the landscape orientation (which is still very preliminary). My plan is to have user-configurable game-specific buttons on the sides, with the actual screen in the middle. I don't plan to have a proper QWERTY virtual keyboard available in that orientation (as that just would not fit in any sensible way).

The biggest issues still remaining are the following:

I will try to keep this blog up to date about my progress with ax86. It will still take a while before I can release even the first beta version. I also need to learn how to release and update Android software on Google Play, but I will still have ample time to do that. :-)