Barbie Seahorse Adventures v1.1.5 (GCW Zero Game)

January 6th, 2015, 00:45 Posted By: wraggster

vIa http://pdroms.de/

Barbie Seahorse Adventures is a fun little platformer made by The Olde Battleaxe for the PyWeek 4 contest. Rewritten for GCW Zero by Nebuleon.


You’re a seahorse, and you have to go to the Moon! There are enemies in your way, which you must defeat, and landscapes that will end up confusing you…
You shoot bubbles from your… face… and those bubbles destroy enemies and turn them into bubbles, which you can ride to raise yourself to new heights. Three bubbles from your face are enough to defeat most enemies, or one if you have hair, but there is one thing that your bubbles cannot defeat alone…
http://pdroms.de/gcw-zero/barbie-sea...-gcw-zero-game

Join In and Discuss Here

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

XMAME v1.2 for GCW-Zero

January 4th, 2015, 22:15 Posted By: wraggster

After a good year in development:

HAPPY NEW YEAR: XMAME v1.0 for GCW-Zero!

It wasn't quite ready for before Christmas but at least it made a 2014 release (only just).
There's certainly more work in all the little details than what you may think!

XMAME v1.0 splash screen


Konami's Xexex running on XMAME v1.0 (Mame 0.69)


Taito's Chase HQ running on XMAME v1.0 (Mame 0.69)


Original Releases
Download XMAME v1.0 for GCW-Zero executable
Download XMAME snapshot preview images
Download XMAME v1.0 for GCW-Zero source (for compiling)

Discuss the XMAME v1.2 release

Updated Releases
Download XMAME v1.2 for GCW-Zero executable
(fixes to taito_f3 and system32 games)

What is XMAME v1.2?

XMAME is a UNIX version of MAME optimized for the GCW-Zero handheld.
The main goal of XMAME is to provide an updated version (actually versions) of MAME which was something other than the ubiquitous MAME4ALL.

Why?

• New games. 1000s of new games.
• Updates for existing games. ie. adding sound where previously missing and new graphical effects.
• Save state support for some games. Disclaimer: Some games, certainly not all!
• Better frontend launcher.

As many MAME users have already noted, later versions do tend to get slower. This is true to a degree, and confirmed by MAME developer Aaron Giles, see his post.

XMAME v1.2 for GCW-Zero supports three versions:

MAME 0.37b16, 0.69 and 0.84.

Take careful note of those versions and understand that optimally you will need three sets of ROMs to play all the games that this release supports.

The good news is that you won't really need three sets.


Three versions of MAME?

Correct, the frontend not only lets you choose the game but also which version of MAME to run. There are also other frontend improvements including being able to filter the ROM lists, create favourites and snapshot image support.

So will I really need all those ROM sets?

Well of course not - unless you plan to try every single game. If you are, please contact me so perhaps you could do some testing for me

The versions of MAME chosen were not random, many hours went into researching which versions would be best.

The final list of versions are a nice mix of earlier releases, with MAME 0.84 providing a large number of playable games. MAME 0.84 happens to be the same version that MAMEOX - MAME for the Xbox - was based on.


Basic Installation

Copy the xmame_1.2.opk installer to your apps folder, either internal storage or external SD card.

XMAME v1.2 can be installed to the GCW-Zero's internal 16GB storage or on an external SD card.

Once the installer has started you can choose the destination - either internal or external storage.

If you want to install to the external SD card but there is no option to do so from the installer, exit the installer, and try running the "reboot" icon under "settings" in Gmenu2X. Then try running the installer again. For some reason the GCW-Zero doesn't always mount the SD card successfully first time around.

Once the destination has been selected, wait a minute or two. When finished you will have a new icon under the emulators section called XMAME v1.2.

The installer can be deleted now as it is no longer required.

Important: Before you run XMAME, you will need to copy some ROMS into each of the "roms" directories for each version of XMAME installed.


Advanced Installation

Once the basic installation is complete, you can optionally make you own adjustments.
This may include:

• Using symlinks to share ROM folders just like the "snap" directory in the basic install.
  By default the install sets up three separate "roms" directories one for each version but as an alternative, you could use a single "roms" directory and use symlinks to share this directory between all versions of XMAME.

If you run into trouble, delete what you've done and follow the Basic Installation again.




How does the XMAME frontend and main executables work?

The XMAME frontend checks to see which versions of XMAME are installed. The directory structure should be as per the basic install for the frontend to function correctly
ie. /xmame/xmame69/xmame.SDL.69
The new frontend allows the user to switch versions of XMAME and select a game. The new frontend then sets the XMAMEROOT environment variable (see below) and starts the selected XMAME with the parameters chosen by the user.
The XMAME executables don't explicitly need the frontend, and can be run from a shell. Indeed during development this is the best and quickest way to test games.
Each of the main XMAME executables searches for directories ie. "roms" or "snap" in a directory defined by the XMAMEROOT environment variable. If this variable is not defined it is defined when starting XMAME as the current directory where the XMAME executable resides.


Credits (in no particular order)

• The MAME developers.
• The GCC developers.
• Franxis for the original MAME for the GP32 and later MAME4ALL.
• d_smagin for the cywin version of the GCW-Zero toolchain.
• sparkymark79 for pestering me
• hi-ban for testing and updated icons.
• Justin for a GCW-Zero.
• notaz for Cyclone and Pandora's SDL (yes, there is a Pandora version coming)
• http://www.slaanesh.net/2014/12/xmam...-gcw-zero.html

Join In and Discuss Here

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

WetSpot 2 (24-10-2014) (GCW Game Port)

November 17th, 2014, 00:25 Posted By: wraggster

via http://pdroms.de/

In Wetspot 2 you control a small crab and your target is to kill every monster on the current level. Since you have no weapons, to accomplish your job you must use the same bricks that forms the walls of the level you are into.


http://www.gcw-zero.com/news.php?id=8

Join In and Discuss Here

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

Mini Status Update October 4th, 2014

October 5th, 2014, 21:52 Posted By: wraggster

Hey Backers, our Full Update is in the works but will be submitted on Wednesday, rather than tonight, in order to be sure all arrangements with the post office for upcoming shipment have been squared away. I need to confirm their receipt of our parcels before I can make an announcement that will bring all of us a collective sigh of relief. As I promised, I won't declare any milestones have been met until they have literally, physically come to pass. I hate to have you wait even a few days longer for good news but I'm making sure that news is signed, sealed and delivered first.
As mentioned on the KS Comments board, a batch of 28 consoles were shipped several days ago and more Backers should already be seeing shipping notifications, tracking info and parcel movement. Additionally, the issues with customs holding up shipments have now been resolved and should no longer be a problem.
There have been mentions in Comments recently of GCW Zero-related promotions and media coverage as well as that of new retailers who have signed on with GCW and will soon carry the Zero too. I've declined to make official announcements regarding these developments out of respect for the Backers still waiting for their consoles as I understand doing so might cause them further frustration. We'll be talking about all of this in official Updates and posts as soon as all units have shipped in order to be as fair and respectful as possible to all of you who have seen this through to having your GCW Zeros en route or in hand.
Attached are photos taken today of remaining Zeros at GCW currently awaiting shipment. They're all here and will be on their way to their respective Backers very, very soon.
Best wishes, everyone. The full Official Update is coming this Wednesday

https://www.kickstarter.com/projects.../posts/1007794

Join In and Discuss Here

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

Dingoo A320 Native and Gamepark GP32 - vAtari v2.0

September 23rd, 2014, 00:44 Posted By: wraggster

I originally made vAtari because the GP32 was sorely missing a good Atari 2600 emulator and as it happens so does the Dingoo A320 in Native mode.
The original version of vAtari for the GP32 was entered into the PACC 2010 contest. It didn't win but it did provide excellent motivation to get most of the work on it done.
Since then, this version has many fixes and enhancements including more accurate graphics and sound and higher compatibility.

My two favourite Atari 2600 games: H.E.R.O


..and River Raid

Download Dingoo A320 Native vAtari v2.0 Binary
Download GP32 vAtari v2.0 Binary

Join In and Discuss Here

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

MAME4ALL v1.3 for Dingoo A320 Native

September 8th, 2014, 20:12 Posted By: wraggster

It's been a long time between releases. I've been busy with a host of stuff, so I'd better start releasing them!

Join In and Discuss Here

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

GpAlice (04-07-2014) (GP32 Game)

September 8th, 2014, 20:00 Posted By: wraggster

via http://pdroms.de/

The GP32 is not yet dead, which is also courtesy of Orion_. GpAlice is a cute looking platform game where you need to collect fruits and gems, but avoid peaks. Mushrooms let you either shrink or grew in size, which will give all the gameplay a tiny twist.




http://onorisoft.free.fr/gp32/gp32.htm#Games

Join In and Discuss Here

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

[GPH] Hase For Caanoo

August 26th, 2014, 01:33 Posted By: wraggster

Hi,

I made a little game named "Hase" (German for hare). It is a worms clone in space with gravitation. And hares. You can read more about it in the Pandora board or at Dingoonity.
Furthermore here a video for you:



I compiled it for the Caanoo, but as I don't own such a device, I would need a tester for it. Here is the download:
http://ziz.gp2x.de/downloads/hase/ha...oo-1.4.2.0.zip

I hope it works! It is not finished, but gives a good impression of the game idea.

Greetings,
Ziz

Join In and Discuss Here

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

[GPH] Hase For Wiz

August 26th, 2014, 01:32 Posted By: wraggster

Hi,

I made a little game named "Hase" (German for hare). It is a worms clone in space with gravitation. And hares. You can read more about it in the Pandora board or at Dingoonity.
Furthermore here a video for you:



I compiled it for the Wiz, but as I don't own such a device, I would need a tester for it. Here is the download:
http://ziz.gp2x.de/downloads/hase/hase-wiz-1.4.2.0.zip

I hope it works! It is not finished, but gives a good impression of the game idea.

Greetings,
Ziz

Join In and Discuss Here

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

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