|
|
OpenSource Handheld News - Gp2X, Dingoo, Wiz, Pandora, GCW Zero and Caanoo is a News and downloads site for Open Source Handhelds, We have all the latest emulators, hack, homebrew, commercial games and all the downloads on this site, the latest homebrew and releases, Part of the
DCEmu Homebrew & Gaming Network.
THE LATEST NEWS BELOW
|
January 6th, 2015, 00:49 Posted By: wraggster
vIa http://pdroms.de/
Giana’s Return aims to be a worthy UNOFFICIAL sequel of “The Great Giana Sisters” by Retroguru and has been recently released for GCW Zero devices (ported by Zear!).
Evil Swampy and his followers have stolen the magic ruby, which made it once possible for Giana and Maria to return from their dream. Many creatures are after this ruby, but does it really has power, or was it just a coincidence?As this is not bad enough, Swampy fell in love at first sight with Giana’s sister Maria and shamelessly kidnapped her. She simply has been at the wrong place at the wrong time.You will now have to take on the role of Giana and get back the magic ruby. And most important of all, save your beloved sister Maria and get home save!
http://www.retroguru.com/gianas-return/
To read more of the post and Download, click here!
 Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
 |
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
The Dingoo A320 is my first .SIM release so there is no frontend end: it uses the Dingoo Native's OS to select a ROM.
The GP32 version has a frontend: select a game and press either 'A', 'B' or 'Select' to start the game. The button you press to start determines the GP32's CPU clock rate.
In both cases, the Atari 2600 ROMs should be uncompressed and have the .A26 suffix.
Controls
* Joystick provides movement for either joystick or paddle.
* 'A' Button is the fire button.
* 'B' Button is the fire buttons on the "other" controller.
* 'START' Atari Reset.
* 'SELECT' Atari Select.
* Games the require two joysticks, hold 'B' button to use second joystick
* Games the require two joysticks, 'L Shoulder' is the other fire button
A320 Specific
* 'Power Slider' to switch off.
* Hold 'L + R Shoulder' back to O/S.
* 'L Shoulder' decrease volume.
* 'R Shoulder' increase volume.
* 'Y' toggles Player 1 difficulty.
* 'X' toggles Player 2 difficulty.
GP32 Specific
* 'SELECT + START' back to frontend.
* 'L + R' Information screen
* 'L Shoulder' toggles Player 1 difficulty.
* 'R Shoulder' toggles Player 2 difficulty.
http://www.slaanesh.net/2014/09/ding...park-gp32.html
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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!
First is MAME4ALL v1.3, which has a host of new features. You really do need to read the "whatsnew.txt" file included in the Binary download for all details. The "readme.txt" is also updated so please look at that for updated information on controls.
Download MAME4ALL v1.3 for Dingoo A320 Native Binary
Download MAME4ALL v1.3 for Dingoo A320 Native Source Code
Discuss this release on the forums
Quick summary of the major news:
* Vastly improved front-end, now featuring full snapshot preview support. Almost 2000 snapshots are included, all taken from within this version of MAME4ALL!
* Huge number of bug fixes, including a long standing sound bug which improves sound for many, many games! Including the newly supported Zwackery.
* Huge number of new games added and existing games updated.
Zwackery now works, nice game and despite needing 6 buttons, plays fine once controls are customised.
Macross, new game added, complete with sound.
Konek-Gorbunok, another new game added.
New frontend. Grey name is a clone, Red name is a non-working game.Preview snapshots "slide" out from the right. If there is no snapshot, nothing is displayed. Multiple snapshots for the same game cycle around.
GCW-Zero version of MAME 0.37b16, MAME 0.66 and MAME 0.84 coming soon, complete with integrated frontend and preview snapshot support.
http://www.slaanesh.net/2014/09/mame...20-native.html
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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/
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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.
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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/
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
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, ×truct) 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)
[h=4]Fixed screen corruption in Ishar: Legend of the Fortress logo screen[/h]After I got the new timer system working, I wanted to take a look at the screen corruption problems in various games. I first started with Grand Prix 2, but since the corruption in that game happens only in the actual game and it takes a LONG time to get to that point in my debug-enabled DOSBox (which I use for comparisons), I decided to start with a different game. Ishar: Legend of the Fortress was a suitable test game, as in it the screen corruptions happens in the title screen as soon as the game starts. I spent a full day debugging the game in both zerox86 and DOSBox, but was not able to find the problem. On the second day of debugging I was able to get closer to the problem location, and noticed that something strange happens after the game has read the logo image from disk to EMS memory, and before it is copied from EMS memory to the VGA screen VRAM.
I added full logging to this code, but I could find no differences between the code running on zerox86 and it running on DOSBox. However, when I instead added a memory watch to a pixel on the screen, and compared the operations that are performed on that pixel, I found that on zerox86 some operations were not performed at all! After some head scratching it finally occured to me that my full logging code recalculates the CPU flags after every opcode, which does not happen when running the code without logging. I then decided to test what happens if I forcibly recalculate the CPU flags after every opcode, and that fixed the screen corruption! So, finally I found out how the screen gets corrupt, now I just had to find out which opcode uses my lazy flags incorrectly. I changed the full logging code to optionally not recalculate the flags, ran both versions, and then compared the logs. There I finally saw the problem: I had forgotten to adjust the zero flag testing algorithm for LOOPNE and LOOPE opcodes when I made a small performance fix to the zerox86 version of my code! After fixing that problem Ishar logo began to draw correctly. Here are some screen captures, first the problem screen and then the fixed screen in the new version of zerox86.
http://zerox86.patrickaalto.com/zblog.html
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
« prev
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
next » |
|
|
