Mile Stones and Shipping Updates

September 16th, 2013, 00:05 Posted By: wraggster

via http://www.kickstarter.com/projects/...handheld/posts

# Shipping and Availability of Units
A milestone has been reached. 778 KS units have been shipped and another 200 are scheduled to ship on Saturday - but the project still has a long way to go. Both Special Edition and Kickstarter units will continue to ship while we strive to make communication more transparent. Retail units will become available on gcw-zero.com only after all the Kickstarter orders have been shipped.
# Graphics and Games
At this point we would like to share with you yet another achievement of this project. In its infancy, the GCW Zero firmware launched without GPU (Graphics Processing Unit) drivers, which meant that software lineup was limited to 2D games or software rasterizing. As of today’s firmware upgrade [1], we are proud to announce the support of GCW Zero’s Vivante GC860 GPU core.
All thanks to the open source project of etna_viv maintained by Wladimir J. van der Laan. While still work-in-progress, it has finally reached a development stage that allows for a public release. We welcome gamers, enthusiasts and developers alike to test out the hardware acceleration. Issues and rendering problems can be reported at the GitHub issues page [2] from van der Laan.

Join In and Discuss Here

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

GCW News - Update September 6th, 2013

September 8th, 2013, 22:52 Posted By: wraggster

via http://www.kickstarter.com/projects/...handheld/posts

Why did I goto PAX?
For this project to stay alive after the KickStarter it needs exposure to attract more developers Indie and Commercial alike so the console library will be always evolving and growing.

It was also a place to make connections with other vendors to make the console and it's experience better for everyone.
I stated the amount of consoles shipped at PAX and met a lot of kewl KickStarter backers in the process.
They also got to have a hands on experience with the hardware and it gave a good grueling test of the hardware in the four days and all units were still working and in good condition. So it was a good test of wear and tear on the system.
Did consoles ship while I was gone to PAX?
Yes as stated in update I made a deal with a local shipping house and fedex to do shipping also so consoles continue to ship. I will still continue to ship also to boost the numbers and ensure shipping gets out there.
I understand everyone wants their pledge reward and I will do my best to ensure you get them as soon as possible. But to not answer e-mails from other Vendors, KickStarter Backers, and new fans would make this project for nothing as we would have nothing after fulfilling the KickStarter pledges.
I have to take the time to reply to e-mails trivial or just information or concerns to just ignore them would be rude and counter productive to the project and the purpose of KickStarting it in the first place.
Alot of projects not naming any are way over their expected dates it's not an excuse just a fact all of the projects for most part are just like me one to three people operations on logistics side with a great idea and the ability to produce the product.
The stalemate to the equation is getting it out to everyone and staying in budget you have from KickStarter funds you raised.
We've had our delays in this project let there be no doubt and have tried our best to navigate through them with as little effect to you the backers as we can.
This project means alot to me hence I have put mostly my own funds to fund development and produce the prototypes that were shown and even now after the KickStarter pledge portion has ended.
I funded PAX out of my own money just as I'm funding and covering the excess cost of shipping that has arisen due to delays and the swap of D-Pads and buttons shipping costs back to China then back to the States.
Once again thank your for your faith in the project and your pledge to make this project/start-up a reality with out you and the early adopters this dream would have died along time ago.
Please read these to get a better understanding of what KickStarter purpose and what it is for:
http://www.kickstarter.com/hello
http://www.kickstarter.com/blog/is-lateness-failure
http://www.kickstarter.com/blog/kick...is-not-a-store

Join In and Discuss Here

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

GCW Zero Update - Apology for shipping delays

September 1st, 2013, 23:25 Posted By: wraggster

via http://www.kickstarter.com/projects/...handheld/posts

I'm only one person with the help of my wife and kid sometime to ship all of these packages. With the delays and added expenses from delays and damages unexpected hikes in shipping costs etc.
If I could dedicate full time to this endeavor I could have them out in a matter of weeks with no issues. But as this is a project with limited man power and resources as everyone has day jobs who volunteers to assist.
It's always easier when you look in from the outside to say well I would do it this way or why does it take so long, But until you actually do the thing your looking at you have no true concept of how long it will take or what it actual takes to do it.
I believe we are doing alot better then most projects on here on trying to get items out and answer private messages etc.
My nights usually consist of having about 30 to 40 minutes family time then answering emails which are usually around 300 to 400 a day. Shipping consoles and discussing things with my developers.
I do apologize for it taking time to do the shipping but we are not Sony or Amazon with a huge shipping divsion at our disposal things do move alot slower.
To speed up the process I've been in talks with numerous fulfillment companies but the answer always ends up it's not viable with the added expense as they want a picking fee for each item and their shipping is more then it would cost me to do it.
I've worked out a deal with Fedex for Smart post and cheaper rates then USPS for overseas that should be finalized Tuesday then you will see a drastic increase in shipping as they will bulk print all of the shipping labels for me and send them over night.
All it will require from that point will be is to slap the labels on and arrange pickup by fedex. I've also arranged a deal with local Goin Postal to assist with this so you should see an e-mail with tracking fairly quickly come Wednesday and going forward.
I will be shipping all pledge gifts minus the etched glasses till the replacement ones arrive I've taken a step to make this upto those who pledged the higher amounts by getting stadium cups and stress balls as addon for this.
Once again I apologize for delays and if you feel I'm not doing a good job on shipping but as I stated before looking from the outside and guessing or thinking you would do it a certain way is not like actually doing it.

• [*]

Join In and Discuss Here

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

zerox86 version 0.02 alpha released! - Dos Emulator for GCW Zero

September 1st, 2013, 23:14 Posted By: wraggster

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

This version has the following fixes and improvements:

Added SoundBlaster ADPCM support (Duke Nukem 2).
Fixed SB IRQ handling for very short buffers (Alone in the Dark).
Fixed reading data directly from disk to EGA VRAM (Heimdall).
Implemented EGA 640x400 special graphics mode (Mahjong Fantasia).
Fixed EGA Register Interface Library handling (A-Train).
Fixed various bugs in FPU emulation (Alien Legacy).
Added support for launching games given on the zerox86 command line.
Implemented mouse support using the analog control.
Many of those fixes I described in my previous blog post, so here are some info about the additional fixes I managed to implement during the last week.

Alone in the Dark
Alone in the Dark crashed at start if Sound Blaster audio was enabled. This was again a situation I thought I had encountered before, and sure enough, in my rpix86 blog Apr 28th, 2013 entry I had written about the exact same kind of crash in rpix86. Since the cause was the same (short SB IRQ buffer with no playing speed given), the same fix also helped in zerox86. After that fix the game seemed to run properly.


Command line parameter
In this version I also added the option to give the DOS program to run on the command line. That is, you can start zerox86 with a command line like "./zerox86 /boot/local/home/DOS/LW2/LW2.COM" and have it immediately launch LineWars II instead of the 4DOS prompt. In fact, when launching games this way you don't even need to have 4DOS.COM at all! I think this should make it possible to launch DOS executables directly using the gmenu2x file browser, but I think this will still need some MIME type changes or something, so it might not work properly in this version yet. Also note that launching .BAT files this way is not possible, as those would need 4DOS to process them.

You should use a full (not relative) path when launching executables this way. That is because of the way the C:\ root directory emulation is handled in this situation. Launching the executable in this way is a three-step process:

The path except the last two parts is considered the C:\ root directory. If the parameter was "/boot/local/home/DOS/LW2/LW2.COM", this would make the emulated C:\ root be located at "/boot/local/home/DOS".
Next zerox86 performs a CD to the second last part of the full path, in the example case this will be "cd LW2".
Last, the executable is loaded without path from the current directory, in the example case the executable is "LW2.EXE".
This is important to keep in mind if you install the program in DOSBox on your PC and then copy it to zerox86 for running. Some games need to be run from the exact same DOS directory they were installed in.

Mouse support
Finally I quickly hacked together some preliminary mouse support. You can now move the mouse using the analog controller (there is no setting for the mouse sensitivity yet, so the movement may be either too slow or too fast depending on the game). For mouse clicks, you need to map a GCW0 button to emulate either the left or right mouse button using special scan codes LMB and RMB in the zerox86.ini file.

Future work
It looks like my time to work on zerox86 in the near future will be quite limited. I got a new project that I need to spend my free time on, so I will not be able to implement any major changes to zerox86 for a while. I will get back to working on it after the other project is finished.

Thanks again for your interest in my emulation projects!

Join In and Discuss Here

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

Status Update August 20th, 2013

August 26th, 2013, 22:26 Posted By: wraggster

via http://www.kickstarter.com/projects/...d/posts/574923

Ok alot of you have had questions and I'm going to try and address them as quick as possible with this e-mail.
1. Giving estimated numbers and such is alittle bit of a pain as I get out as much as I can a day working a day job then shipping at nights and weekends.
I get out as much as I can each day this is also same time trying to answer e-mails continue to flash units and also deal with any warranty or tech support issues. I'm working with a local fulfillment house so units should start going out alot faster. I will try to get a number each week of how many have shipped etc starting next week.
I understand your frustration trust me I do as I get frustrated also I wish I had unlimited funds and could just magically make all these units get shipped out ASAP.
2. For those that already have your consoles here are some links to get more applications/games/emulators etc. We will have have the actual GCW Zero repo up very soon.
Below you will see a link of the Repo preview to get a feel of what it will eventually look like.
http://www.gcw-zero.com/downloads

Join In and Discuss Here

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

zerox86 progress

August 26th, 2013, 22:12 Posted By: wraggster

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

For the past week I have been working on implementing various missing features and fixing various bugs in zerox86. I also got a new 4GB SDHC card where I could fit all my DOS test programs (of which I have about 3GB's worth). I put that card into my GCW-Zero and thus now have easy access to all my DOS test programs. I then began to go thru my test programs (mostly alphabetically) and checking the problems in them.

Duke Nukem 2
I had left the Sound Blaster ADPCM sound emulation so far unimplemented, so I started my improvements by implementing that. It took a couple of days, mostly because I had all sorts of other activities after work during the first half of the last week. I ported the ADPCM code from the rpix86 version, converting the ASM code from ARM to MIPS. It now plays something at least resembling the correct audio, and since very few programs actually use ADPCM audio, I think it is now sufficient. Duke Nukem 2 actually uses all three ADPCM formats, 4-bit, 2-bit and also the slightly weird 2.6-bit (8 divided by 3) version. Thus it is simple to test the ADPCM code using a single game.

Heimdall
Heimdall is one of the few games that read data directly from disk to graphics VRAM. Jazz Jackrabbit does that into Mode-X VRAM, while Heimdall uses EGA 16-color graphics mode. I had thought that this was already working, but I decided to test it just to be sure. To my surprise it did not work, and after a little bit of debugging I realized that my EGA version did not restore the GP register properly when calling from C routine to my ASM routine.

Back when coding DS2x86 I noticed that the DSTwo firmware did not use the GP (global pointer) register for anything. MIPS convention is to use the GP register as a pointer into the middle of a 64KB "near data" block. This is because MIPS has very simple memory addressing system, you can only use a register with a 16-bit signed offset to address memory. By having the GP register always pointing to the most commonly used data area, you can avoid calculating memory addresses into temporary registers most of the time. Thus, in my DS2x86 ASM code I used the GP register to point into my data area, and also made the actual emulation address calculations take advantage of the GP register pointing to a certain address which was also aligned in a certain way.

In the GCW-Zero environment, however, all the libraries are linked in a way that has the linker decide the suitable value for the GP register, which differs from my needs. It would have slowed my emulation down quite a bit if I would have had to change my code to not rely on the GP register value, so I decided to let the C code use the linker's GP value, and have my ASM code use different value that suits my purposes better. In my ASM code I load the GP register with the value I want after every call to or return from C code (which does not happen all that often, luckily). For the linker to allow that, I needed to have my ASM code use the -mno-abicalls compiler flag. This will make the linker give a lot of linking abicalls files with non-abicalls files warnings, but as long as I remember to handle the differing GP register values this does not seem to cause any problems. Not using ABI calls also has the advantage that I can call my own ASM subroutines using the simple JAL address (jump and link) opcode, instead of the complex way that the C code uses by first calculating the target address into t9 register and finally calling the address using JALR t9 (jump and link register) opcode.

Mahjong Fantasia
After those fixes, I then began going thru my games alphabetically. The first game I tested was Mahjong Fantasia, which for some reason I have in a directory called 98mj2. It is the only game I have encountered that goes to the EGA 640x200 mode, and then changes the EGA registers so that the actual graphics screen goes to 640x400 resolution. I noticed that I had not taken this register change into account in my EGA graphics blitting routines, and fixed that problem. This made the game start up and look correct.


A-Train
The next game I tested was A-Train. It seemed to work fine, except that the main game screen was mostly monochrome. I thought that the problem seemed somehow familiar, so I went through my old DSx86 blog posts, and found a DSx86 blog June 27th, 2010 entry where I fixed the exact same problem in DSx86. The problem was the EGA Register Interface Library handling. I checked my code in zerox86, and realized that when I had copied the C code from rpix86, I had not changed the call parameters to match the way my MIPS ASM code differs from the ARM ASM code. I fixed the parameters, and the game began to look correct.


Alien Legacy
Next I checked Alien Legacy. It seemed to hang with a black screen, which has usually been a difficult situation to track down. I can attach the gdb debugger to the running zerox86 process (which is a huge step forward from the DS2x86 times), but since it is much more likely that the x86 code is the one running in a loop instead of my emulation code, stopping the emulation code does not get me very close to the root problem. Since I am already using signals to handle various interrupts in my code, I thought that it might be a good idea to have a signal that would print a disassembly of the currently executing x86 code to the standard output. This way I could send that signal repeatedly to my zerox86, and see if the x86 code is running in a tight loop.

The problem with this in zerox86 is that my emulation code keeps the x86 registers in MIPS registers and not in any memory address, so when the code gets the signal, the x86 registers (including the program counter) are not in any variable that I could simply examine. But since the signal handler needs to return to the code that was running at the time of the signal, all the register values need to have been pushed on the stack.

Luckily I already had a memory variable that tells the stack pointer value of my emulation core, so I began experimenting with this by coding a SIGUSR1 handler that simply printed the current stack pointer value and my emulation stack pointer value. The difference in Alien Legacy hang situation seemed to be a bit over 700 bytes, which means around 175 words had been pushed on the stack. The problem was just to find where in that area the signal handler has pushed which register.

I added code into my signal handler to print out all the stack values, and then used gdb to break when the signal handler is started, and then again when the code returns back to my emulation loop. Many of the register values only appeared one time in the stack, so using those addresses together with the known GP register value (which the signal handler also needs to push into stack) I was able to make an educated guess as to how the registers are pushed. I added code to my signal handler that looks for the GP value, and gets the register values from the certain offsets in the stack relative to the GP value. These register values are then saved into the memory variables that my disassembly routine uses. After having my signal handler print the disassembly, I managed to find out where Alien Legacy hangs:

0180:001B03DA D9F8 fprem
0180:001B03DC 9B fwait
0180:001B03DD DFE0 fstsw ax
0180:001B03DF 66A90004 test ax,0400
0180:001B03E3 75F5 jne 001B03DA ($-b)

Alien legacy uses the floating point fprem (remainder) opcode, and then checks the floating point flags to see if the C2 flag (value 0x400) is clear (meaning the remainder operation was finished), and runs the remainder again if not. I had not coded proper FPU support into zerox86 yet, so this test always failed causing a never-ending loop.

So, I decided to finally start implementing the FPU operations, as it has been on my TODO list for a while. Since the MIPS processor in the GCW-Zero has proper hardware floating point support, I needed to look into how the floating point parameters are handled in function calls and so on. After some studying I realized that the floating point parameter passing convention is pretty easy to understand and suits my existing FPU emulation framework quite easily, so it only took a couple of hours to implement the missing floating point operations. After that Alien Legacy progressed to the main game screen quite fine. It seems to need mouse, though, so I think I need to implement mouse emulation next.


Thanks for your interest again, I will continue working on zerox86, adding the missing features and testing various games. There are still a lot of misbehaving games that I need to debug, but I hope at least some more games (including the ones mentioned above) will run better in the next version.

Join In and Discuss Here

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

Dooom v1.2 (Dingoo misc Port)

August 18th, 2013, 11:12 Posted By: wraggster

via http://pdroms.de/


Dooom is a Doom port for the Dingoo Native OS by the_wub, which itself is based mainly on the Chocolate Doom source port by Simon Howard.
Release notes:

Join In and Discuss Here

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

zerox86 version 0.01 alpha released!

August 18th, 2013, 11:06 Posted By: wraggster

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

Okay, here it is, the first public alpha version of zerox86! Note that a lot of features are still missing, and this can still only run a few games, but feel free to test it and report the miss-behaving games to me. I can then improve the compatibility in the upcoming versions.

Since the last blog post I changed the default key mappings somewhat. It was requested that I follow the default SDL key mapping of GCW Zero as closely as possible, so now the default key mappings use those defaults. However, I think it is important to have easy file and directory selection when on 4DOS prompt, so I added a different default configuration for 4DOS. Here the A key is used for bringing up the file selection window, and B key is mapped to ESC key (to back out from the selection window, for example). If you feel these mappings are not good, you can add a 4DOS section to the zerox86.ini file and change the mappings to be whatever you like. The only hardcoded keys are LOCK for exiting the emulator and SELECT for toggling the virtual keyboard on/off.


The image above shows the current configuration display when running 4DOS (the image is zoomed 2x to make it bigger on computer displays). The bottom left area shows the currently running executable (which is used as the section name in the zerox86.ini file when loading game-specific settings), the config that is currently used, and the current graphics mode. On the right side is a key legend, so you don't need to remember all the key assignments. This shows the A and B buttons (red and blue colored) having 4DOS-specific assignments. The image below shows the default key mapping, in this example I was running Doom, so the graphics mode is 320x200 Mode-X.


If the game requires some unsupported low-level feature (like virtual memory support) or encounters some internal error that causes it to misbehave, you may get a message like below on the screen. Please send me the crash logs that get written in this situation, as those will help me in tracking and eventually fixing the problem in zerox86. This display stays on the screen for 5 seconds, after which you get dropped back to the GCW Zero main menu.


Have fun with this alpha version of zerox86! I will continue working on it and improving the game compatibility in the future versions. Thank you for your interest in my x86 emulators!

Join In and Discuss Here

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

Dooom v1.1 (Dingoo misc Port)

August 4th, 2013, 20:50 Posted By: wraggster

via http://pdroms.de/

Dooom is a Doom port for the Dingoo Native OS by the_wub, which itself is based mainly on the Chocolate Doom source port by Simon Howard.

Release notes:


I’ve uploaded version 1.1 to the google code page. This version lets you put all your wads in the dooom folder with a separate command line file for each wad. The wad selector lets you select either a wad file or a command line file and I’ve changed the file format of the command line files to .txt to make editing easier with notepad!

The really important bit: You must also specify the wad needed for a total conversion or modded wad with the -iwad command line option.

So, for Aliens Total conversion I now have this:

chocolate-doom -deh atcud19.deh -merge alitcsf.wad -file alitcsnd.wad alitcwad.wad -iwad doom.wad

You can save the command line file as anything you like .txt This is a lot easier to use now but I will have a look at getting it working with wads in separate folders with a proper savegame folder for each.

http://boards.dingoonity.org/dingoo-...goo-native-os/

Join In and Discuss Here

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

Manic Miner v1.0 (GCW Zero Game Port)

August 4th, 2013, 20:47 Posted By: wraggster

via http://pdroms.de/

alekmaul released Manic Miner in a very first version for the GCW Zero. Source code is available as well!


http://boards.dingoonity.org/gcw-rel...ner-v1-0-6469/

Join In and Discuss Here

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

zerox86 progress

August 4th, 2013, 20:27 Posted By: wraggster

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

For the past weeks I have been on my summer vacation, and I decided to spend my vacation mostly not programming at all. Thus I have not made much progress with zerox86 either. However, I could not resist spending a few hours every few days working on either rpix86 or zerox86, whenever I got momentarily fed up with just being lazy. :-) For zerox86 I have worked on four specific issues: Fixing the annoying race condition, implementing Sound Blaster Direct DAC support, implementing a virtual keyboard, and finally I also began implementing the configuration display.
[h=4]Fixing the race condition problem[/h]I began working on the race condition problem by coding a logging system that logged all IRQ-related events into a ring buffer. I could not log them directly to the file, as that changed the timing of the events so that the race condition did not occur, at least not as often. When the program then stopped because of the race condition, I wrote the ring buffer contents to a log file.
After a couple of attempts at studying the log, I finally understood the race condition. Sometimes the timer signal interrupted the audio thread (which in turn has interrupted the main thread), and because of a complex interaction between the main thread turning interrupts on or off and marking an interrupt handled, and the other threads queuing interrupts, it was possible for the system to get out of sync. Rather than attempting to fix the already too complex thread locking system, I decided to try rewriting it all using Linux real-time asynchronous signals.

The timer IRQ emulation already used the asynchronous SIGALRM signal, and I coded additional signal handlers for the other emulated IRQ lines, and also added new routines that any thread could use to send a signal to the main thread:
static void TimerIRQ() { IRQRequest(0); }static void KeyboardIRQ() { IRQRequest(1); }static void MouseIRQ() { IRQRequest(3); }static void SBIRQ() { IRQRequest(7); }static void PS2IRQ() { IRQRequest(12); }void SendKeyboardIRQ() { pthread_kill(maintid, SIGRTMIN+1); }void SendSBIRQ() { pthread_kill(maintid, SIGRTMIN+7); }void SendMouseIRQ() { pthread_kill(maintid, SIGRTMIN+3); }void SendPS2IRQ() { pthread_kill(maintid, SIGRTMIN+2); }void SendSIGTERM() { pthread_kill(maintid, SIGTERM); }The pthread_kill functions send a signal to the thread ID given as the first parameter, so calling the Send... routines from whatever thread always sends the signal to the main thread (which is where the actual emulation happens). IRQRequest is the common routine that handles the various IRQs in the main thread, and the static methods above are the actual signal handlers. I also added the program exit to the same system, so I can send the SIGTERM signal from any thread and handle it cleanly in the main thread. Now I was able to code the actual IRQRequest routine so that I did not need to use any thread synchronization mechanisms, as it will always get called within the main thread context. The only thing I needed to protect against was a new signal attempting to interrupt the handling of the previous signal. I decided to block all the used real-time signals in the beginning of the IRQRequest routine, and then later unblock them at the end, so that took care of that problem. In other routines in the main thread I simply used the ll and sc MIPS ASM opcodes to protect against interrupted execution. Since only the IRQRequest can interrupt the main thread, and not the other way around, this was sufficient locking for the variables shared between the IRQRequest code and the main thread. These changes seem to have fixed the race condition, as I have not encountered the problem any more.
[h=4]Sound Blaster Direct DAC support[/h]Next, it occurred to me that using interval timers for the TimerIRQ emulation allowed me to support very high timer speeds (like 8400Hz as used in Star Control 2) as long as the GCW0 kernel supports high-resolution timers. This makes it possible to have the timer interrupt routine play a single audio sample, which is what the Sound Blaster "Direct DAC" method does. So, I decided to enhance my Sound Blaster emulation so that it can play samples buffered by the timer interrupt routine. Because the actual audio playing rate I use in zerox86 is 22kHz, I still need to convert the samples from 8.4kHz (or whatever the game uses) up to 22kHz, and thus I need to buffer them before playing them. This buffering may cause some skips to the audio, but the audio still seems to sound mostly correct.
[h=4]Implemented preliminary virtual keyboard.[/h]I also implemented some code to handle the keyboard image you can see in the screen copies of the previous blog post. I decided to use the SELECT key to toggle between activating the virtual keyboard (which then uses the D-Pad and A keys) and disabling it (which leaves D-Pad to emulate cursor keys and A to emulate Enter). I also tested using the amalog controller for the key selection, but noticed that it was too awkward to quickly select the correct key with that. Separate D-Pad key presses to move to adjacent virtual keyboard keys seems to work better.
[h=4]Implemented preliminary config display.[/h]Finally, I also worked on displaying the current configuration (including a key mapping legend). This is something that I have wanted to do for a long time now, and I wanted to get it done before starting the actual configuration system, so that I can see that the configuration system works properly. Here below is a screen copy of the preliminary config and key legend display. It uses the lower 40 scanlines of the screen to display the configuration in use, and the currently mapped keys. Using the SELECT key you can toggle the screen bottom area to show either this display or the virtual keyboard. I will perhaps also add a third option that will show nothing, in case this display is distracting in some situations. I think I will need to still make this config screen somewhat cleaner, but in principle the visual layout is now in place. The values it shows are currently just placeholders for the actual values. I used those to determine the space I need to reserve for the key code names. The next step is to have it show the proper values currently in use.
My summer vacation ends today, so I will get back to the normal daily routine, and hopefully get some proper progress done to zerox86 as well.

Join In and Discuss Here

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

GCW Zero - KickStarter Units Address Change form...

August 1st, 2013, 13:39 Posted By: wraggster

news via http://www.kickstarter.com/projects/...handheld/posts

Thank you so much for believing in the project and helping us get fully funded. As most of you know, the units are in house and the flashing phase has begun. We are excited and eager to get these in your hands and will begin shipping soon. Many of you have already confirmed your information, but we are in need a final confirmation from a few of those who may have changes in address.
This form is for GCW KickStarter backers whose address may have changed or for those who missed the first confirmation form. If this applies to you, please input your information in this form.
If you need the package shipped at a later date or special instructions or requests please put those in the other section of the webform.
https://docs.google.com/forms/d/1qF_...vHkVM/viewform

Join In and Discuss Here

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

Handy320 v1.0 (Atari Lynx emu for GCWZ)

July 29th, 2013, 16:50 Posted By: wraggster

via http://pdroms.de/gcw-zero/handy320-v...x-emu-for-gcwz

Handy320 by darth_llamah is an Atari Lynx emulator for GCW Zero devices based upon Handy/SDL v0.5.
Changes:

Join In and Discuss Here

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

Dooom v0.8 (Dingoo misc Port)

July 29th, 2013, 16:45 Posted By: wraggster

via http://pdroms.de/dingoo/dooom-v0-8-dingoo-misc-port

Dooom is a Doom port for the Dingoo Native OS by the_wub, which itself is based mainly on the Chocolate Doom source port by Simon Howard.

Changes:


- Removed my stupid music volume hack that prevented music from being completely muted.
- Fixed enemy AI problems and BFG ammo bug by adding back dehacked support.
- Added support for modified wads. If all you want to do is play the official wads then the app will work exactly as it did before (with all your wads in the Dooom folder). To run a modified wad or total conversion you will need to create a text file called “comline.wub” that contains the command line options needed. It is also best to make sure that the Dooom folder only contains the files needed for the wad you want to play. It *should* be possible to specify these details with the command line options but I haven’t been able to do so reliably yet. For example, Aliens TC needs these files: ALITCSF.WAD, ALITCSND.WAD, ALITCWAD.WAD, ATCUD19.DEH and DOOM.WAD
- The command line options to run the wad are: chocolate-doom -deh atcud19.deh -merge alitcsf.wad -file alitcsnd.wad alitcwad.wad – Copy/paste that line of text into a new notepad document and save it as “comline.wub” in the /GAME/DOOOM/ folder.
- When you launch the app you can select an over-clock value as before and then press START to launch the wad. More information on running some of the popular wads can be found here: http://www.chocolate-doom.org/wiki/i...p/Category:TCs
- The command line can also be used to launch an official wad with extra options like -nomonsters etc…

http://boards.dingoonity.org/dingoo-...goo-native-os/

Join In and Discuss Here

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

Status Update July 25th, 2013 "The Eagle Has Landed"

July 29th, 2013, 16:41 Posted By: wraggster

Thats right "The Eagle Has Landed" the KickStarter GCW Zero consoles have arrive with the fixed D-Pad and buttons. You all have asked a couple questions so I will take time to answers those also.
1. Will the consoles when shipped have tracking yes all packages will be trackable bu USPS.com and Stamps.com links.
2. What about resellers like Dragonbox.de shipping the consoles at this point we are still trying to work out a way but as always when it comes down to the VAT either I pay it or you pay it.
Either way it's not going to be a small amount for me or you who ever pays it, I won't be reimbursed in anyway and it was not calculated into your shipping cost as no one can calculate what each countries VAT or customs fee will be as they differ.
One person same country got charged two pounds another almost thirty pounds same country same customs for the GCW Zero SE. The paperwork was filled out the same so no ryhm or reason to differences.
3. We will start flashing consoles tonight and follow through till Sunday and start shipping on Monday. All SE models that are left from d-pad replacement will ship by Staurday and Monday.
4. As for address changes we are going to reset the webform so everyone can put there new address in if it has changed from address you originally put in when you made your pledge. I will post the link as soon as we reset it as an update.

Join In and Discuss Here

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

Temper 0.80 for Dingoo Native v1.0

July 23rd, 2013, 10:54 Posted By: wraggster

via http://www.slaanesh.net/

What is Temper?
Temper is an NEC PC Engine emulator originally coded by Exophase and ported by Slaanesh.
Temper plays HuCard, CD, SCD, AracdeCD and SuperGfx games.

Another one that's been a long time in the coming. Much of this was done more than a year ago, however it wasn't polished or fast enough as I couldn't use any of the ARM assembly code that a good portion of this is written in.

A few recent breakthroughs in my development toolchain and other optimizations on the native side code has meant that this is now working fullspeed on the Dingoo Native!
Most games (even CD) will run at fullspeed with no frameskip. Well all the ones I've tried - about 30 or so.
Everything seems to work fine including HuCard, CD, SCD and Arcade support. There is full OGG support for CD tracks and BZIP2 compression is also supported for compressed ROMs and savestates.

Download Binary - Temper 0.80 for Dingoo Native

Join In and Discuss Here

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

OpenDingux (06-07-2013) (GCWZ OS)

July 22nd, 2013, 01:04 Posted By: wraggster

via http://pdroms.de/gcw-zero/opendingux-06-07-2013-gcwz-os

If you own a GCW Zero device you might be happy to know that there was an improvement/update for the OpenDingux OS.



Changes:


* improved video performance (enabled framebuffer caching)
* made vsync more robust (eliminated glitches on page flipping)
* made the FTP server list hidden files (names starting with a dot)
* improved Unicode support in both gmenu2x and command line tools
* fixed bug that powered off the system if the power slider was raised, released, then raised again soon after
* list IP addresses in System Info application
* added unrar command line tool
* added shared memory support (allows more applications to be ported)

http://www.gcw-zero.com/updates

Join In and Discuss Here

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

colecOD v1.0 (ColecoVision emu for GCWZ)

July 22nd, 2013, 01:03 Posted By: wraggster

via http://pdroms.de/gcw-zero/colecod-v1...n-emu-for-gcwz

colecOD is a ColecoVision emulator by alekmaul for the GCW Zero.

http://boards.dingoonity.org/gcw-releases/colecod-v1-0/

Join In and Discuss Here

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

ProSystem v1.1 (A7800 emu for GCWZ)

July 22nd, 2013, 01:02 Posted By: wraggster

via http://pdroms.de/gcw-zero/prosystem-...0-emu-for-gcwz

ProSystem is an Atari 7800 emulator ported to GCW Zero by alekmaul.

http://boards.dingoonity.org/gcw-rel...rosystem-v1-1/

Join In and Discuss Here

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

Noiz2sa v1.0 (GCWZ Game Port)

July 22nd, 2013, 01:00 Posted By: wraggster

via http://pdroms.de/gcw-zero/noiz2sa-v1-0-gcwz-game-port

Noiz2sa by Kenta Cho is an abstract shoot’em up game. Control your ship and avoid the barrage. A ship becomes slow while holding the slowdown key. A green star is the bonus item. A score of the item(displayed at the left-up corner) increases if you get items continuously. Ported to GCW Zero by alekmaul.

http://boards.dingoonity.org/gcw-releases/noiz2sa-v1-0/

Join In and Discuss Here

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