Playing StarCraft On An ARM

August 3rd, 2014, 22:02 Posted By: wraggster


Except for the really terrible Nintendo 64 port, StarCraft has always been bound to desktop and laptop PCs. Blizzard could take the code for StarCraft, port it to an ARM platform, put a version on the Google Play an iTunes store, and sit there while the cash rolls in. This would mean a ton of developer time, though, and potentially years tracking down hard to find bugs.
Or one random dude on the Internet could port StarCraft to an ARM platform. Yes, this means all the zerg rushes and dark templar ambushes you could possibly want are available for tablets and Raspberry Pis.
This godlike demonstration of compiler wizardry is a months-long project of [notaz] over on the OpenPandora team. Without the source for StarCraft, [notaz] was forced to disassemble the Win32 version of the game, convert the disassembly to C with some custom tools, and recompile it for ARM while linking in all the necessary Win32 API calls from the ARM port of Wine. Saying this was not easy is an understatement.
If you have an OpenPandora and want to relive your heady days of youth, you can grab everything you need here. For anyone without an OpenPandora that wants to play StarCraft on a Raspi, you might want to get working on your own recompiled port. Video below.

http://hackaday.com/2014/07/31/playi...aft-on-an-arm/

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 development on a break

August 3rd, 2014, 21:40 Posted By: wraggster

This is just a short blog post, letting you know that I don't have time to work on zerox86 for a while now. Today my summer vacation ends, and I also have some work to do for my commercial pax86 emulator project. Thus, I gave my GCW-Zero again to my nephew for some further testing of zerox86.
I will continue working on zerox86 after I get my device back from my nephew, probably in a couple of months. So, I hope you can manage with the current version of zerox86 until then! I know there is at least one game that I somehow broke in the latest version, Dangerous Dave Goes Nutz. Sorry about that, I will take a look at that game when I get back to working on zerox86. Thanks again for your interest in zerox86 and for your keeping the compatibility wiki up to date!

http://zerox86.patrickaalto.com/zblog.html

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 version 0.06 beta released!

July 28th, 2014, 20:28 Posted By: wraggster

This version has a couple of major architectural changes, a few configuration improvements, and several game-specific changes. I wrote about some of the changes in my previous blog post, so I will only mention those briefly in this post. I did some more work to zerox86 since my blog post from last weekend, and will write longer chapters about these new changes. I like to order my change logs so that the new features are first, then the fixes that affect several games, and lastly the game-specific fixes. This is why the changes are not usually listed in chronological order.

Enabled Virtual Memory (paging) support in zerox86
This is the major architectural change in this version. I wrote a rather detailed blog post about this change last weekend, so see below for more information about this. Please note that this does not mean that every game that uses virtual memory will now work, it just means that support for those games can now be added.

Implemented a slowdown feature using key MHZ in zerox86.ini
This is a new configuration feature that you can use to slow down zerox86 for those very old games. The value of the new MHZ key should be an integer corresponding to the clock speed of a 80386 processor you wish to emulate. If you give any value outside the range of 1 .. 79, there will be no slowdown applied, so zerox86 runs at the approximate speed of a 80MHz 80386 (or 40MHz 80486, as the 80486 CPU is about twice as fast per clock cycle as the 80386).

When running those old games, you should use rather low values, anything between 1 and 4 should be worth a try. In this version the MHz value needs to be an integer, but if you feel this is too coarse, let me know and I'll look into implementing finer control in the next version. Since the value is only an approximation, the actual slowdown will vary depending on how the game is programmed.

Implemented further optimizations to IRQ emulation
This is again something that I already mentioned in my previous blog post. This change should allow me to add support for the PC Speaker digitized music that some games use, but I did not have time to implement it into this version yet.

Increased max number of game configs in zerox86.ini to 512
I had only allowed for 128 game-specific configurations in the zerox86.ini. This turned out to be pretty low (some of you seem to really like your DOS games!), so I increased this limit to 512 in this version. The limit can be increased still further, but this is probably enough for now, I believe.

Fixed Jazz Jackrabbit audio crackling
The compatibility wiki mentioned Jazz Jackrabbit having an audio crackling problem in addition to the pause menu selector problem that I wrote about in the previous blog post. Since I got the menu fixed, I thought it would be a good idea to make this game fully supported and fix the audio quality as well. I had not listened to the game all that closely, and when I did, it was pretty obvious that the audio quality was not as good as it could be.

First I needed to find out what actually goes wrong in the audio rendering. I added a memory buffer where I wrote the last 16 audio blocks that my SBEmulation() routine creates. I did not add any file writing feature to my code, as it occurred to me that I could simply use GDB for that. This is what the new SDL audio_callback routine looked like, after I added my memory logging mechanism (with the JAZZDBG define) for the created audio samples:

#define JAZZDBG 1
#if JAZZDBG
#define JAZZBUFSIZE (256*16)
short jazzbuf[JAZZBUFSIZE];
int jazzbufpos = 0;
#endif

void audio_callback(void *userdata, Uint8 *stream, int len)
{
// Write the Sound Blaster samples to the stream (or clear the stream if nothing to play).
int Need_SB_IRQ = SBEmulation(stream);
#if JAZZDBG
memcpy(jazzbuf + jazzbufpos, stream, 256*2);
jazzbufpos = (jazzbufpos+256)&(JAZZBUFSIZE-1);
#endif
// Write the AdLib emulation samples to the stream. 2 times 128 samples.
AdlibEmulation(stream);
AdlibEmulation(stream+256);
if (Need_SB_IRQ)
SendSBIRQ();
}

I then ran Jazz Jackrabbit, and attached GDB to the running zerox86.exe, looked up the address of my jazzbuf, and dumped that to a file using the GDB command dump binary memory jazzdump.raw 0x1ac8620 0x1ac8620+256*16*2. Next I started up Audacity and imported the raw sample data.

http://zerox86.patrickaalto.com/zblog.html

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 work continues

July 20th, 2014, 21:21 Posted By: wraggster

Sorry, no new version today, as there are not all that many useful enhancements yet in this version, and I have not had time to make sure my new changes have not broken any major features. I have been working on zerox86 quite a lot during the past week, though. Here is some information about the changes I have been working on.

Further optimizations to IRQ emulation
I started my work for the next version by rewriting the IRQ handling code yet again. The changes I made to the previous version already made it possible to run the emulated IRQs faster than the 250Hz task switch speed of GCW0, but I still had some thread synchronization code in my IRQ handling routine. However, now that I moved my timer IRQ not to use the asynchronic signals, I wanted to also move all the IRQ handling into the main emulation thread.

I was able to get rid of all the thread synchronization code, and also the whole signal broadcasting system I used to send IRQ requests from the UI and audio threads to the main emulation thread. Now the other threads simply set flags that the main thread reads. I still need to be careful when resetting the flag from the main thread, but other than that consideration there is no need for any extensive thread locking.

While I did that optimization, I also rewrote the timer I/O port handling in ASM. It used to be done in a C code (which is always slow to call from my main ASM code). When playing digitized sounds using the PC Speaker, the timer I/O ports are written to from the timer IRQ (at several thousand times per second), so to eventually handle that I need to have my timer I/O port handling pretty fast. Sadly this change caused Wizardry 6 to cause a division-by-zero error when using audio. This is probably caused by some timing problem, as the game seems to determine the speed of the PC using a very fast timing loop. I spent some time trying to adjust my timer handling, but was not able to fix this yet.

Fixed Jazz Jackrabbit menu selector on pause menu
Jazz Jackrabbit was reported on the combatibility list as having a problem in the game pause menu, where the selector bar is not visible. This was a rather curious issue, as the selection seems to work fine in all the other menus. It would be strange that the game would use two different techniques to handle menus. I had not played Jazz myself so far that I would have used the pause menu, so I had not noticed this problem, but going to the pause menu the problem was immediately visible. Finding the actual problem was considerably more difficult, though.

First I had to figure out the best way to debug this. I wanted to find out the opcode where the problem occurs, so I wanted to see which opcode Jazz uses to write the menu items to the screen. Since I did not know which opcode it was, it was difficult to figure out how and where to put a breakpoint. In the end it occurred to me that whatever opcode the game uses, it will always need to write something to the VGA registers before writing to screen (since the game runs in Mode-X). So I decided to let zerox86 run up to the pause menu, and then attached the GDB debugger to it, and set a breakpoint to the VGA port 0x3CE handler. Luckily the game does not draw anything else to the screen while on the pause menu, so my breakpoint got triggered only after I pressed cursor down.

When I got the code to stop to the break point, I copied the current CS:IP register value and used that to then cause zerox86 to break at the corresponding game code. The result looked like this (curiously the game uses 16-bit protected mode instead of the much more common 32-bit flat address space protected mode):

0207:0ED3 BACE03 mov dx,03CE VGA Graphics Registers I/O port
0207:0ED6 B80318 mov ax,1803
0207:0ED9 EF out dx,ax 03 = VGA Function Register = 0x18 (XOR)
0207:0EDA B8003F mov ax,3F00
0207:0EDD EF out dx,ax 00 = VGA Set/Reset Register = 0x3F
0207:0EDE B8080F mov ax,0F08
0207:0EE1 EF out dx,ax 08 = VGA Bit Mask Register = 0x0F
0207:0EE2 8E068615 mov es,[1586] ES = 014F (segment base address = 0xA0000)
0207:0EE6 8B7E08 mov di,[bp+08]
0207:0EE9 268A4551 mov al,es:[di+51] Load the VGA latch from VGA VRAM contents
0207:0EED A10483 mov ax,[8304]


There are a couple of interesting things in that code. First, the game sets the VGA Function Register to XOR instead of the normal MOV which simply writes the data as-is. The XOR function uses the VGA latch value (a sort of internal VGA register that keeps a copy of the most recent data that was read from the VGA VRAM) and performs a bitwise XOR operation with the data that is about to be written to the VGA VRAM, before actually writing the data. This is used for various tricks in the 16-color EGA graphics modes, but I had not seen this technique used in the 256-color modes until now. Perhaps because in the 256-color modes it is usually simpler to just use the XOR opcode to perform such operations, instead of programming the VGA registers and then making sure the VGA latch register contains the correct data.

The second interesting thing is that the code loads a byte from the VGA VRAM (at the code address 0207:0EE9), but then immediately overwrites the AL register (low 8 bits of AX) on the next code line. So, obviously the code has no need for the data at the VGA VRAM at that location, and the only possible use for that code is that it simply preloads the VGA latch register for later.

I had not coded any support yet for using the XOR function in the Mode-X graphics mode, so that was most likely the cause for the missing selector bar. Now I just needed to find out in which opcode the actual writing happens. Checking for the XOR function in all my Mode-X opcodes would cause a performance hit in all games, which I wanted to avoid since no other game has so far used this trick. Annoyingly, Jazz used a function pointer to call the actual screen writing code, so it took me a while longer to find it. It turned out that Jazz uses opcodes C6 (MOV r/m8, imm8) and C7 (mov r/m16, imm16) to perform the write. That was very nice, as those are rather rare opcodes to use for screen writing (usually games write some dynamic values, not hardcoded single pixels as in these C6 and C7 opcodes). So, I added support for the XOR operation to only these two opcodes, which resulted in the menu selection appearing properly! Here below are some screen copies about the problem, before and after my fix.


Enabled Virtual memory support
I also began working on the Virtual memory support in zerox86. Since the code is based on my DS2x86 which does have (rather fragile) virtual memory support, much of the code was already in place, just disabled or commented out. I removed the comments and then began running some of my test games. I started with Warcraft II demo. The first problem was that zerox86 crashed with a SIGBUS error. After running zerox86 in GDB I realized that my TLB (Translation Lookaside Buffer) table clearing needed work. I use the highest bit of the memory address to determine whether the address is in physical RAM or in some special area (like EGA or ModeX graphics memory or in Virtual Memory). In DS2x86 all the physical addresses are in the range 0x80000000 .. 0x80FFFFFF while on GCW0 the RAM addresses are in the range 0x00000000 ... 0x7FFFFFFF. Thus I have the exact opposite handling of the highest bit in GCW0 than in my DS2x86 code. The SIGBUS was caused by my forgetting to initialize my TLB to a proper "uninitialized" value, which on DS2x86 was simply zero but on GCW0 is actually 0x80000000. So I needed to fill my full 4MB TLB with 0x80000000 when zerox86 starts.

The next couple of problems were caused by my not noticing a few places in the code that needed more extensive checks, which were still commented out. The main problem with the paging (virtual memory) support is that a single opcode may span multiple pages, either with the opcode bytes, or with the memory address the opcode uses. DOSBox handles this by loading every byte separately, performing the memory access mapping for each byte. To speed up the emulation, I use a CS:EIP pointer in the host address space and load the opcode bytes without any memory checking. Similarly I also load the memory address that the opcode uses with just a single access to the TLB. This works fine and fast with linear memory access, not so when paging is on.

To handle the code segment paging, I change my main opcode loop to test whether the current CS:EIP pointer is within the last 16 bytes of the 4K page, and if so, I relocate these 16 bytes together with the 16 first bytes of the next 4K page to a continuous 32-byte temporary area. Accessing the next 4K page while relocating it may cause a Page Fault, which may thus not happen at exactly the same opcode as it should. This usually does not cause problems, though. Then when the CS:EIP pointer advances to within the first 16 bytes of the next page, I adjust the CS:EIP pointer to go back to the correct physical memory address. Since these checks add extra code to the innermost opcode interpreter loop, I use self-modifying code to add/remove these checks when paging gets enabled/disabled. This feature handles the code segment paging, but it still does not help in a situation where the opcode performs a memory access that spans multiple pages.

For the memory access spanning multiple pages, again the perfect solution would be to load/store all data one byte at a time using a separate TLB lookup for each byte. This would slow down most of the opcodes quite noticeably, so I am not willing to do that. Instead, I have added checks to the opcodes that have had this problem in the games I have tested. What this means in practice is that games (using virtual memory) I haven't tested myself and added specific support for will most likely not run in zerox86. This is what I mean with a "fragile support" for virtual memory.

One interesting thing happened when I was adding support for a 16-bit memory read page check. This code needs to check whether the address ends in 0xFFF, so that the low byte is in this page but the high byte needs to be read from a different virtual page (which may be physically far away from the first byte). I originally had written the check simply like this:

.set noat
andi AT, memory_address, 0xfff AT contains the last 12 bits of memory_address
sltiu AT, at, 0xfff AT = 1 if AT < 0xFFF, else AT = 0
beqz AT, spans_two_pages Jump if AT = 0 (last 12 bits of address are 0xFFF)
.set at

When I was looking at the MIPS architecture reference, I realized that this might actually be a situation where I could finally use the somewhat weird nor (not or) opcode of the MIPS assembly language! So, I changed the above code to the following.
.set noat
li AT, 0xFFFFF000 AT = 0xFFFFF000
nor AT, memory_address, AT AT = 0 if last 12 bits of memory_address are 0xFFF, else AT != 0
beqz AT, spans_two_pages Jump if AT = 0 (last 12 bits of address are 0xFFF)
.set at

In this code I NOR the memory address with 0xFFFFF000, where the result is zero only if the memory_address ends with 0xFFF. It is not any faster, but not any slower either, and finally uses the nor opcode for something! :-)

I got Warcraft II to start up pretty easily after a few such opcode fixes, and then I began to look into making Grand Theft Auto running. This game needed a few more opcodes to be supported, but otherwise it was surpiringly easy to get running. You obviously need to run the 8bit graphics version, as that is all that zerox86 supports. It is also not very fast, as is to be expected with all the additional code needed for virtual memory support.


After I got GTA working, I could not resist testing how far will I get with Windows 3.11. Back when I worked on DS2x86, it was partly my frustration trying to make Windows 3.11 work in it that eventually resulted in my stopping work on it. However, now with GCW0 I have a lot better debugging tools on a much faster platform, so it is again interesting to work on Windows 3.11 support. If I get it working, the next step would be to try to make Windows 95 running, as that is practically my end goal with my emulator projects.

I had pretty good notes from my work on Windows 3.11 on DS2x86. I ran into many of the same issues on zerox86, and could use my notes to see what needs fixing. Much of these fixes were just uncommenting some code, but some code also needed actual changes, mostly because of the 0x80000000 bit significance change. I still have not managed to get quite as far as I got with DS2x86, but I am already past the middle point of my notes from DS2x86. :-)


When working on changing my opcodes to be paging-enabled, I keep running Doom timedemo occasionally to keep track of how my changes affect the overall performance of zerox86. If the performance drops, I then spend some time figuring out new performance enhancements to the new paging-enabled opcode versions. Here is a table of Doom timedemo results at various steps on the way. The doom timedemo measures the number of timer ticks running the demo takes, so the smaller the number the faster the PC. The corresponding FPS can be counted as 74690/realticks, for example 74690/6451 = 11.57 fps.

realticks Description of the change made
6451 zerox86 version 0.03 on a high-resolution timer -enabled kernel.
7020 zerox86 version 0.05 (workaround for the lack of high-res timers).
6762 After further optimizations to IRQ emulation.
7408 With paging-enabled opcodes for GTA and WAR2.
6909 Performance enhancements to paging-enabled MOV opcodes.
6629 Performance enhancement to paging-enabled PUSH opcode.


Future work
I probably am not able to resist working on Windows 3.11 a little while longer, even though there are still many games on the compatibility wiki that would need looking into. I do plan to make some game-specific fixes before releasing the next version, though. I also have an idea about how to make zerox86 slow down for the really old games that currently run too fast, so that is also something I want to experiment with.

http://zerox86.patrickaalto.com/zblog.html

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Status Update July 6th, 2014

July 14th, 2014, 20:54 Posted By: wraggster

Hey guys, after shipping out most of the "final 14" confirmed units this week before the post office closed for the holiday, we're now headed into our final projected week in which we expect all shipping to be completed.
All appears on track to meet this date, give or take a couple of days if absolutely necessary as we're still finishing the vetting of confirmation emails.
On that note, I can't stress enough that no one, absolutely no one need worry about being forgotten, ignored or "slipping between the cracks". A number of you have asked for personal confirmation of being (rightfully) listed among the remaining Backers with console shipment pending.

We'd love to do that but for the greater good have chosen to maintain our focus on the ongoing shipping process as the matter of greatest importance. Please bear with us on this decision, at the end of the day your console's delivery ASAP trumps all other expenditures of effort and productivity. We've poured enough resources into making this happen and resolving unforeseen crisis at the expense of reduced profits. That's a sacrifice we're willing to make to fulfill all your pledges with the utmost commitment.
I can assure all who have sent us their address confirmation submissions to the email account we created for that sole purpose that you are present and accounted for on our fulfillment list. Unless your email submission is returned to you as "undelivered" immediately after being sent, then we have received it and that means we've got you covered. Guaranteed. We haven't provided individual response emails due to the extra time that would require, resulting in delayed shipping.

I think we can all agree that getting your Zero into your hands as quickly as possible is the highest priority. It certainly is on our end. You've waited long enough to enjoy the console you pledged to receive and we'd hate to make you wait even longer for the sake of individual confirmations! If you haven't received your shipping notification yet, it's not because you slipped off any list or spreadsheet. It just means your console's shipment is still pending.

As mentioned in prior updates and comments, through the address confirmation emails we received, we unexpectedly discovered more units remained to be shipped in addition to the previously stated "confirmed" numbers. These additional consoles are being checked, processed and shipped while we go through the emails so we can't precisely state their numbers until all emails are reviewed.

That's why we're refraining from adding them to the "final confirmed" count. It can change by a unit or two on any given day depending on the emails reviewed so posting the additional numbers would be more confusing than helpful. That said, fulfilling all pledges right around our target-timeframe is on track because these additional numbers are low enough, so no worries!

Whether you're among the "final" confirmed pledges tallied in Updates or among the pledges we're now confirming were falsely declared "shipped" by the fulfillment company we fired for misconduct, your GCW Zero will be mailed out to you well before July draws to a close. Crossing that finish line will be a great moment for everyone who supported and believed in this project, enduring the stumbles, delays, frustrations and many, many months of waiting to finally reach this goal. Backers, you guys have displayed the patience of a saint and we humbly thank you with all our hearts. You guys are awesome.
There will be no Backer left behind, that's a promise.
Really looking forward to sharing the next Update! It will announce full completion of console shipment within the next 7-10 days (again, I've added a few extra days for wiggle-room just to keep the bases covered while we finish reviewing emails). I've been confidently assured of this and am comfortable in officially confirming it. I really want to see you all enjoying the Zeros you pledged for so long ago- you deserve it.

Thanks to all for enduring the imperfections and we're truly happy knowing all KS Zeros will be on their way to our remaining Backers in a matter of days.
Best wishes as always,
Craig Strother

https://www.kickstarter.com/projects...d/posts/902219

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 version 0.05 beta released!

July 14th, 2014, 20:50 Posted By: wraggster

via http://zerox86.patrickaalto.com/zblog.html

This version has actually quite a large number of fixes, but the fixes themselves are not all that big or complex. A couple of new features (which I probably need to improve in the future versions), and quite a few game-specific fixes, mostly for games mentioned on the compatibility wiki as not working. I also noticed that my FAQ did not yet have a comprehensive list of options you can use in the zerox86.ini configuration file, so I added a section for those.
[h=4]Implemented simple CD-ROM emulation[/h]This version of zerox86 now includes a very simple CD-ROM emulation. There is no support for ISO images yet, but now you can configure a certain directory on your SD card to be used as the CD-ROM contents (which shows up as the D: drive in DOS). This can be configured per-game using the zerox86.ini, so you can have several games that need data from different CDs on your SD card. If you configure this in the default section, then you can access the D: drive also from the DOS prompt.

As an example, I copied two CD-ROM games, Fragile Allegiance and Realms of the Haunting on to my sd card. I copied the games to directories GAMES/FragAlle and GAMES/ROTH respectively. ROTH has a separate subdirectory "CD" that should be used for the CD-ROM contents, while Fragile Allegiance wants to have the same contents on the CD-ROM as are in the game directory. Thus I added the following configuration sections to my zerox86.ini:
[roth]CDROM=/media/sdcard/GAMES/ROTH/CD[fragile]CDROM=/media/sdcard/GAMES/FragAlleBoth of those games run in 640x480 SVGA resolution, and even play videos at that resolution, so they are not all that fast (or readable) on GCW-Zero. They do work and are playable in this version of zerox86, though.

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Xump v1.00 (GCWZ Game Port)

July 6th, 2014, 20:53 Posted By: wraggster

Via http://pdroms.de/

Xump by Retroguru is a simple one screen puzzle game initially released in 2005 by Psilocybin Development. This overhaul is a rewrite featuring new graphics, new levels, new music… simply new everything. Ported to GCW Zero by Zear.
Help Xump and his human master Holger to disarm mines on fields located somewhere above our atmosphere. Collect coins by destroying fields or mines but do not fall of the playing field. There are 48 levels plus hidden 32 original levels if you can unlock them.



http://retroguru.com/xump/

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 version 0.04 beta released!

July 6th, 2014, 20:42 Posted By: wraggster

This version has one major change and a few smaller fixes. Here is some additional info about the changes in this version.
[h=4]No more high-resolution timer support needed in the kernel![/h]The major change in this version affects the timer interrupt handling. My original timer IRQ code in zerox86 was based on the code I use on Android and Raspberry Pi, where the Linux kernel has support for high-resolution timers. In those platforms I let the kernel interrupt my code at the correct timer interval, thus making my emulator timer interrupts happen in real time. This is a simple and easy system, but since the GCW-Zero kernel only runs timers at 250Hz (4ms interval), this is not sufficient to emulate games that need higher frequency timer interrupts.
I had already coded a different timer interrupt emulation system for my Windows Phone 8 version of pax86. The Windows Phone 8 task switch frequency was even less than that of GCW-Zero, so on that platform I had to use an internal counter and then periodically check the elapsed time using performance counters. This has the drawback of needing extra memory accesses for the counter in the main opcode interpreter loop, so it slows down all the emulation. However, luckily on zerox86 I had one MIPS register still unallocated, so instead of using a counter in memory, I was able to use this register for the counter. This meant that instead of loading a value from memory, decrementing it, saving it, and testing it for zero (4 opcodes), I was able to simply decrement the register and test it for zero (2 opcodes) on zerox86. This still causes a slowdown, but running Doom timedemo it looks like it only slows zerox86 down about 3% (meaning the new version runs at 97% of the speed of the previous version). I find this an acceptable trade-off for running games at their proper speed.
When the counter register reaches zero, I then call the C routine clock_gettime(CLOCK_MONOTONIC, &timestruct) to get the current time (with around a microsecond actual precission), and check whether it is time to start an emulated timer IRQ. I then reset the counter register to a suitable value (depending on the actual wanted IRQ frequency) for the next timer interval. Since I don't do cycle counting, this counter is rather approximate, which is why I try to have the counter reach zero several times during one timer IRQ period, and use the clock_gettime() call to determine the more accurate IRQ time.
I tested how much time the clock_gettime() call takes on GCW-Zero, and noticed that two adjacent calls return a time difference of about 1666 nanoseconds, and that I can call the routine over a million times in a loop that lasts for a single second. So the call is pretty fast, and it should not be a problem calling it at up to 100.000 times per second for a game that sets the timer IRQ to some very high value (like 33kHz, as in Wizardry 6). At those speeds this will of course still slow down the emulation quite a bit, but the normal timer IRQ speeds of less than 1000Hz should run quite fine, and even the games that play digitized audio using Direct DAC system (one sample of audio generated at every timer IRQ) should run reasonably OK. The actual routine that starts the timer IRQ handling in zerox86 is still not very fast, and I plan to still improve that in the future versions.

Here is a list of some of the games that will now run much better than before. Any game that used a higher timer speed than 250Hz used to run slower than normal.

• Commander Keen 4 (sets timer to 560Hz)
• Ishar: Legend of the Fortress (sets timer to 13240Hz for Direct DAC intro music)
• Jill of the Jungle (sets timer to 6080Hz for Direct DAC sound effects)
• LineWars II (sets timer to 768Hz)
• Sid Meier's Colonization (sets timer to 607Hz)

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

[GPH] Scummvm 1.7.0 Preview Builds

July 6th, 2014, 01:19 Posted By: wraggster

Hi All,

I finally got around to releasing a set of ScummVM testing/preview builds for all the GPH backend devices (GP2X, Wiz and Caanoo) and the OpenPandora.

You can grab them from my site and I would appreciate any feedback from testing as these builds will they form the basis of the upcoming official 1.7.0 releases in the near future.

Comments to this thread, my site or the ScummVM forums please. Bug fixes and patches to the ScummVM tracker or GIThub . Oh, and please don't mirror these test builds.

Cheers,

John

http://www.gp32x.com/board/index.php...dpost&p=970788

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Sqrxz v1.0b (GCWZ Game)

July 5th, 2014, 01:09 Posted By: wraggster

via http://pdroms.de/

Sqrxz requires fast reflexes and is a simply mindblasting Jump’n’Run puzzle game with high frustration factor. Now ported to GCW Zero by Zear!

Storyline:

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

GCW News- Status Update June 29th, 2014

July 5th, 2014, 00:44 Posted By: wraggster

Hey fellow Backers! It's Update time once again. Thanks for waiting one extra day. I wished for more shipping to be completed before posting this week and today more units have reached the post office for shipment.
> Numbers shipped:
As of today, 15 of the final 29 confirmed consoles have been dropped off at the post office for shipping the other 14 will go out Monday. What is left to be completed between now and our ultimate shipping completion goal in two weeks is the vetting and sorting of unexpected address confirmation emails and the shipment of consoles to all legitimate Backers therein. Some are indeed legitimate pledges from Backers our now-terminated fulfillment company claimed to have delivered to, when in reality they had not (hence our disposal of the "services" provided by that company). Other emails are a different story altogether. Without naming names, we have already received emails from Backers who have since proven to have already received their consoles as well as, outrageous as it is, address confirmation emails from individuals confirmed to never have been part of the KS campaign in the first place! Sorting out the con-artists is time consuming work, but we remain committed to meeting our goal of completely fulfilling any outstanding pledges in the next two weeks. We are sorry that some disingenuous people are slowing the process down, but we remain on track to meet our goal.
We promise that all who are owed a GCW Zero console will get one, absolutely no question about it.
> Power adapters:
As Justin Barwick stated, we began removing the DC adapter from GCW Zero packages back in late November/early December following multiple cases of EU/UK countries either cutting the power cords or rejecting or confiscating the package due to the power supply not being current-compliant for EU/UK territories. We are looking into finding a replacement adapter that will be CE/EU/UK compliant. Thus far, it seems it will likely wind up being a USB charger which we will mail out to anyone who requests one after all consoles are shipped out.
Alternatively, the console can be charged and powered via USB from your PC, or through a standard USB wall-plug charger. Using this method to recharge the Zero's battery is only marginally slower than using the DC adapter for this purpose. The Zero was designed to charge either way for the sake of personal preference, convenience and as a way of providing a backup option when one method is unavailable. For what it's worth, I've only used my power adapter once during my many months of Zero ownership. I much prefer the convenience, portability and versatility of charging via USB, but that's just my personal preference.

https://www.kickstarter.com/projects...d/posts/894288

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

zerox86 version 0.03 beta released!

July 5th, 2014, 00:38 Posted By: wraggster

Okay, after a very long hiatus I am back working on zerox86! I have been working on my other projects in the mean time, and also for the past couple of months my nephew has been using my GCW-Zero to test my library of over 300 DOS games on zerox86. He has not yet had time to test all of the games, so I will give my GCW0 back to him for a few weeks again.
Anyways, I released a new version of zerox86 today, mainly because I heard reports that zerox86 does not work on the latest GCW0 firmware from May 5th. It turned out that zerox86 did actually work on it, but since my directory defaults and error messages were not correct, it was not easy for new zerox86 users to figure out the potential installation problems. There are not all that many fixes in this version yet (as I only have worked on it for a couple of partial days), but here is the list of the changes and improvements I managed to implement.
[h=4]Implemented mouse scaling[/h]This has been one of the most requested missing features. In this version you can have new configuration keys MouseXScale and MouseYScale in the zerox86.ini. These should have a floating point value (like 0.5 or 2.0) to make the mouse pointer move slower or faster than the default speed. You can have these settings in either the default section or in the game-specific sections in the ini file.
[h=4]Fixed a crash in Grand Prix 2[/h]Grand Prix 2 is one of my newer test games, mainly because it is very pretty and runs in either 640x480 SVGA mode or in 320x200 MCGA mode. The menus are in the SVGA mode, so I can get nice screen copies from it :-)

http://zerox86.patrickaalto.com/zblog.html

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

GCW News- Status Update May 28th, 2014

June 2nd, 2014, 23:26 Posted By: wraggster

After two weeks of unfortunate, time-consuming complications mentioned in previous Updates and its projected shipping date pushed back twice, the latest batch of Zeros has finally been dropped off at the post office today for shipping. Thanks to all for enduring these patience-draining developments, we appreciate it.
> 50 consoles were handed to the post office today, with more to come very soon. The batch was intended to be 60 units (as we've mentioned previously) but after today's continued prepping, shipping, testing and flashing of more Zeros following the batch of 60, time ran short a pack of 10 was accidentally left behind in the rush to get to the post office before it closed. They'll be sent out ASAP in the coming days and I'll post an Update as soon as they're dropped off at the post office. Out apologies for the 10 left behind in the shuffle.
> Drumroll, please... After today's batch of consoles was dropped of at the post office, a total of 147 GCW Zeros, including the previously mentioned 10, are left to be shipped. I hope some of you are pleasantly surprised by how low this number actually is.
> Going forward, I will hold off on announcing any projected shipping dates and only provide numbers after a shipment has reached the post office. Hope this will help to avoid any future confusion or missed dates.
The next Update will be posted in one week, or sooner if more shipments reach the post office.
Best wishes,
Craig Strother

https://www.kickstarter.com/projects...d/posts/858472

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

OpenPandora Design Files Released

June 1st, 2014, 22:00 Posted By: wraggster

[As of Saturday, May 31], the OpenPandora case and hardware design files have been released for non-commercial use. The OpenPandora is a hand held Linux computer with gaming controls, but essentially it is an all-purpose computer. The OpenPandorra offers the greatest possible degree of software freedom to a vibrant community of users and developers.

http://hardware-beta.slashdot.org/st...files-released

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

GCW News- Status Update May 20th, 2014 Part II

May 27th, 2014, 00:37 Posted By: wraggster

Regarding the battery discussion, it's true that the prototype consoles had a 2800mAH battery with RAM that was 3.3 volts with a battery life of 8 to 10 hours.
It has just been brought to our attention here that the KS units have a 2200mAH battery and this was confirmed with the factory that indeed, it was a 2200mAH battery- but one with Low Power RAM that operates at 1.2 volts. It's true, regrettably, that the factory changed batteries without our knowledge.
Nonetheless, it's virtually an even trade off and there is no loss of battery life as the KS model ram is drawing considerably less power than the prototype models did. The average is still 8 to 10 hours as attested to by many people here and other forums.
GCW based the Zero's technical specs off of the prototype models when we started the Kick Starter campaign. This was before production had commenced, and therefore the specs could have changed. At that point in time though, GCW had no knowledge they had been. Had we known, the specs had changed we would have put it in an update long ago but it was just brought to our attention. Bottom line, despite the change in battery model, the battery life is still the same as it had been promised from day one- 8 to 10 hours of use per full charge due to its Low-Power memory RAM (vs the 2800mAH which ran at a higher voltage).
As for HDMI, at PAX Prime 2013 in Seattle we performed a demo using an experimental HDMI driver that was not completely full screen running just off the battery. During these demos, the average battery life was 6 to 8 hours.
We have a great and dedicated development team. To knock them or put them down is not warranted as the GCW Zero would be nothing without them helping it become the great piece of hardware that it is. They work tirelessly to add new features and optimize those already implemented. They have continued to work for this cause no matter what has happened and they deserve respect and admiration for everything they have done and continue to do on a daily basis for GCW and The GCW Zero.
As for the shipping order of the consoles, they are shipped from a list that is exported from Kick Starter we are unsure as to why the order is off. We do know and feel that everyone deserves to get their console and no favoritism should be given to those who backed first on a particular day or backed later. Everyone deserves to get and will get their consoles and we will fulfill that promise.
As for why there were no shipments during the last week, it was explained in my update that the developers had to remove certain games from the firmware image as they are no longer viable as pre-installed software since the author of the music from those games has joined GEMA an authors guild.
Also, many have reported getting an unflashed unit or one that's the wrong color from ones that were pre-packaged in USPS mailers. So with that in mind all units are being re-flashed with the new firmware image (minus certain games for the aforementioned reasons), tested and boxed for packaging.
Those units that are already flashed, 60 in total, will be packed and begin shipping tonight so keep eye on Kick Starter inbox for confirmation of address and/or actual shipping confirmation. More units will continue to be flashed, tested, and packaged this week and will go out Saturday or Monday.
There have been delays due to unforeseen personal and health-related events Justin’s life. Some people close to him, like me and others in the forums have seen proof that all are legitimate and very unfortunate.
They know that none of the things he has stated that have caused the delays are lies or stall tactics to buy time. He has had a rough last nine months with personal, health, and just plain flukes of bad luck.
Come what may, he has stayed the course and continued to ship consoles to make this Kick Starter project a reality and a success in delivering consoles to all supporters. He will fulfill his promises that anyone who pledged for a console will get theirs, as promised.
Unlike certain posters continue to claim, contact with backers has not stopped either from Justin or myself commenting as PR.
We have also produced all the consoles as were promised to all backers and have frankly experienced events, many beyond our control, that have slowed or temporarily halted shipping on some occasions.
We will continue to work as hard as we can, continuing to fulfill the rewards earned by each and every one of you who has made a pledge for a console.
In closing, here are examples of other Kick Starter projects that have run into roadblocks or unforeseen events out of their control. It is not uncommon and most do, ultimately, have a happy ending like the one we strive for every day with our project.
"Kick starter, the world's largest crowdfunding site, gives entrepreneurs a platform to raise money for pet projects like a new business, a film, or even a music video.
To date, the site has collectively raised more than $679 million for more than 100,000 campaigns, launching the likes of the new gaming console Ouya and funding a feature film for "Veronica Mars" fans.
But not all Kickstarters have a happy ending and success can be difficult to bear. Some fundraisers simply aren't prepared to handle the demand that comes with thousands of new backers and hundreds of thousands of dollars.
1. Ed Carter hoped to raise $21,000 to fund his board game. Instead, he lost his house and job.
Carter's plan was to raise money to produce a deluxe version of his board game "Glory to Rome." It was a smashing success. At the end of his 21-day funding period in the summer of 2011, Carter had raised $73,102 from 1,600 board game enthusiasts — more than three times his goal. In return for the donation, Carter promised his backers free shipping of his game.
Fast forward a year and Carter was in deep trouble. His backers-turned-customers still hadn't seen their board games. Turns out, the games were ready to ship but were crushed in transit after Carter forgot to indicate that the packages were fragile. And free shipping was easy enough to finance for domestic orders and even to Brazil, but a large order to Australia cost Carter more to ship than the game itself.
The blows kept coming. Carter was laid off from his full-time job with Staples. As he ran out of money, he had to dip into his personal savings account to pay for the game production and subsequently stopped making payments on his mortgage.
The writing was on the wall at that point. Eventually, Carter lost his Boston home. Despite bankrupting himself, Carter has managed to deliver all of the games he promised and says he'd do it again.
"I’m doing this because the corporate world is one of the best games ever invented," he told Quartz.com.
2. Childhood friends raised thousands to produce eco-friendly sandals. Then they completely fell off the radar.
John Eades and Michael Ferreri created the Vere flip-flop, a sandal they marketed as having "its eye on the environment." The childhood friends hoped to raise $12,000 to build a sandal-making factory in Geneva, N.Y., telling would-be supporters they had the experience and equipment, but needed help with production costs.
The two raised $52,618 — almost four and a half times their goal — in the spring of 2011.
Ten months later, Eades and Ferreri found themselves in the hot seat with their 1,091 backers. The sandals that were promised to customers were still nowhere to be seen as of December 2011, way past flip-flop season.
"It’s been a long, frustrating process to say the least, and we’ve hit more roadblocks than even we expected," they wrote in a letter to BetaBeat.com. "Kickstarter orders were overwhelming, and if we were to do it again we would definitely have put a limit on the number of backer awards available."
The two sporadically updated backers, citing mechanical issues, short-staffing, and the late arrival of materials.
They were still fielding complaints from customers in January, but it seems like they've finally managed to get on track. The sandals are finally being sold at retailers across the country.
Technology and design-related projects, three-quarters of which don’t finish on time, make up 4.2 percent of successfully funded projects on the site, according to Kickstarter’s statistics. They drew in 21 percent of money raised. The website has helped spawn several consumer-electronics makers and artistic endeavors that probably wouldn’t have existed otherwise. Success stories include the LunaTik iPod Nano watch, which is available at the Apple Store, and is expected to reach $10 million in sales by the end of the year, according to Kevin Brennan, a general manager for the company. After being rejected by venture capitalists, Eric Migicovsky turned to Kickstarter in April to pitch his Pebble watch, which became the site’s highest-grossing campaign, with $10.3 million in funding. Even then, there was some skepticism about whether popular Kickstarter projects would come to fruition.“When a cool project shoots up, it shoots high,” Migicovsky said in an interview earlier this year. “Unfortunately, most of the products on Kickstarter come a bit late. So we’re hoping to change that.”Last month, Pebble joined the club. Migicovsky posted a note to backers saying Pebble Technology would miss its September target of delivering to them a watch that can display messages from a smartphone. In an e-mail, he declined to forecast a new date. Enough Kickstarter campaigns have hit snags that some rivals are seizing on the opportunity. New crowd-funding contenders have emerged, including Indiegogo Inc. and RocketHub Inc. Reicherz, formerly of private stock exchange SecondMarket, is working on a service called CrowdHut to help entrepreneurs figure out what to do after they raise money from crowd-funding sites. And several incubators have emerged, including Jeremy Conrad’s Lemnos Labs, to lead hardware startups down the right path.“They go on Kickstarter, and wake up one day with $150,000 in the bank, and say, ‘I don’t know what I’m doing,’” Conrad said. In January, Jason Giddings’s Kickstarter project for a touchscreen keyboard and mouse raised $143,584. He missed his July target for completing the product, and expects it to take at least another six weeks, he said.“It didn’t really seem on the surface like it was going to be that challenging, but it has been extremely challenging,” he said. “A lot, lot slower than I expected. A lot, lot more money than I expected to spend.”Kickstarter backers aren’t silent partners. Giddings’s page on the site is full of people demanding progress reports. Video-game studio Harebrained Schemes, which raised $1.84 million in April, ended up hiring someone to handle its requests from backers.“You really do have to plan on a huge amount of energy and time in being responsive to your backers,” said Jordan Weisman, Hairbrained Schemes’ chief executive officer. “That was something we underestimated when we launched the campaign.” "
Best wishes,
Craig Strother and the GCW Team

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

GCW Zero 5/5/14 Firmware Update Released

May 19th, 2014, 01:39 Posted By: wraggster

GCW Zero owners have been patiently awaiting the release of the next firmware update. Packaged among some great fixes is the addition of triple buffer support. This new implementation provides a means to greatly increase the performance of emulation, which is perhaps the largest draw for both current and potential Zero owners. Flashing this firmware update is the same as previous updates, instructions can be found via the GCW WIKI article linked below.

Root file-system changes:

• Triple buffering in SDL
• Input through joydev instead of evdev for joysticks
• Access point mode (ad-hoc WiFi between two Zeros)
• Integrated WiFi manager (GCW Connect)
• Integrated image viewer (o2xiv)
• WiFi notifier (blinks the green LED slowly)
• Low-power warning (blinks the green LED fast)
• Root file-system based on Buildroot 2014.02
• Root file-system now located on system partition
• On-demand loading of the network daemons
• Added command-line tool to launch OPKs, "opkrun"
• Added WiFi modules for recent units
• Added GNU Screen

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Sqrxz 4 – Cold Cash v1.00 (DC, Wiz, GP2x, Caanoo, PSP, GCW Zero, Pandora, Symbian OS

May 19th, 2014, 01:04 Posted By: wraggster

via http://pdroms.de/

The fourth installment of Sqrxz has been released. Sqrxz 4 – Cold Cash has been released to the public on 20th April for plenty of systems, such as Windows (32-Bit), Linux (32-Bit, 64-Bit), Wiz, PSP, MotoMagx, Dreamcast, GCW Zero, MacOS X (32-Bit, 64-Bit) / Intel, Amiga OS4, MorphOS, Symbian OS Series 60, Symbian OS UIQ3, Raspberry Pi, Caanoo, GP2x and OpenPandora.

<iframe height="281" src="https://www.youtube.com/embed/n_ZB7bd3xTI?feature=oembed" frameBorder="0" width="500" allowfullscreen=""></iframe>

http://www.sqrxz.de/2014/04/20/sqrxz-4-released/

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Sqrxz 4 – Cold Cash v1.00 (DC, Wiz, GP2x, Caanoo, PSP, GCW Zero, Pandora, Symbian OS

May 19th, 2014, 01:04 Posted By: wraggster

via http://pdroms.de/

The fourth installment of Sqrxz has been released. Sqrxz 4 – Cold Cash has been released to the public on 20th April for plenty of systems, such as Windows (32-Bit), Linux (32-Bit, 64-Bit), Wiz, PSP, MotoMagx, Dreamcast, GCW Zero, MacOS X (32-Bit, 64-Bit) / Intel, Amiga OS4, MorphOS, Symbian OS Series 60, Symbian OS UIQ3, Raspberry Pi, Caanoo, GP2x and OpenPandora.


http://www.sqrxz.de/2014/04/20/sqrxz-4-released/

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

Sqrxz 4 – Cold Cash v1.00 (DC, Wiz, GP2x, Caanoo, PSP, GCW Zero, Pandora, Symbian OS

May 19th, 2014, 01:04 Posted By: wraggster

via http://pdroms.de/

The fourth installment of Sqrxz has been released. Sqrxz 4 – Cold Cash has been released to the public on 20th April for plenty of systems, such as Windows (32-Bit), Linux (32-Bit, 64-Bit), Wiz, PSP, MotoMagx, Dreamcast, GCW Zero, MacOS X (32-Bit, 64-Bit) / Intel, Amiga OS4, MorphOS, Symbian OS Series 60, Symbian OS UIQ3, Raspberry Pi, Caanoo, GP2x and OpenPandora.


http://www.sqrxz.de/2014/04/20/sqrxz-4-released/

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here

[GP32] Gpalice

April 12th, 2014, 01:34 Posted By: wraggster



GpAlice is a platform game, playable on the GP32 console.
This game was created for the "speed coding" contest held at the retro computing convention AC 2014,
on the 5th and 6th April 2014 at "Congis sur Thérouanne", France.

Principle of the Game:
Alice is in wonderland and she must find the white rabbit hole.
She can collect fruits and gems, but she must avoid the peaks and be careful with the mushrooms !
If she jumps on a tiny mushroom she will become tiny, and won't be able to jump too high.
Jumping on a big mushroom will get its normal size back !

The Contest Rules required a 2 players mode, but because of the lack of 2 GPLink, I couldn't do a real 2 players mode.
That's why, Player 1 plays first, then Player 2, and in the end, the game tell who finished the level faster !

See my GP32 page to download the game: http://onorisoft.free.fr/gp32/gp32.htm#Games

http://www.gp32x.com/board/index.php...dpost&p=970411

Join In and Discuss Here

Submit News and Releases Here and Contact Us for Reviews and Advertising Here