|
|
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
|
October 12th, 2013, 01:16 Posted By: wraggster
via http://pdroms.de
If you own a GCW Zero device you might be happy to know that there was an improvement/update for the OpenDingux OS.
Changes:
* included improvements in OpenGL ES from the Etnaviv project; read details here
* set GPU clock to 500 MHz (was 432 MHz)
* set VPU clock to 166 MHz (was 333 MHz, but it didn’t actually work at this speed)
* print a reminder that the login name is “root” in the network configuration utility
http://www.gcw-zero.com/updates
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 25th, 2013, 01:27 Posted By: wraggster
Even in the age of the NVIDIA Shield, dedicated Android gaming handsets are still a bit of a rarity, which is all more of a reason to take a gander at the leaked GamePad 2 from Archos. The device first reared its head at the FCC, and thanks to an online retailer -- which has since scrubbed all references to the product -- we're now treated to a press shot and a smattering of technical specs for the successor to the original GamePad. This time around, it's purported to sport a slightly more dense 1,280 x 800, 7-inch IPS display, along with a 1.6GHz quad-core CPU and 2GB of RAM. In addition to the previously available 8GB model, a new 16GB version is said to be in the works, and in both cases, the GamePad 2 will retain a microSD expansion slot. There's no word yet on pricing or availability, but you can bet that we'll hear more from Archos soon enough.
http://www.engadget.com/2013/09/24/a...epad-2-leaked/
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 24th, 2013, 23:46 Posted By: wraggster
Distributor MSE Group will launch the Wikipad gaming tablet in the UK and Ireland this month, which aims to fill a “huge hole” in the mobile gaming space.
Having hit the US earlier this year, the tablet will now go on sale in the UK on September 24th.
Fraser Townley, president of sales at Wikipad, told PCR: “Half of tablet usage is gaming and we believe the Wikipad does this better than any other tablet. The exclusive and patented removable controller, upgradeable storage and our focus on gaming makes the Wikipad different from other tablets.”
“We believe we have carved an exciting niche that fills a huge hole in the mobile gaming space.”
The Wikipad is specifically designed for mobile gaming, featuring an Nvidia Tegra 3 mobile processor with a quad core CPU. Its lightweight removable controller features standard game pad controls, including dual-analog sticks, buttons, D-pad, bumpers and triggers.
Users can download games via the Google Play Store, Amazon App Store, the Nvidia Tegrazone and Sony PlayStation Mobile.
http://www.pcr-online.biz/news/read/...s-month/031968
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 19th, 2013, 12:43 Posted By: wraggster
A simple resistive DAC is all you need to drive a VGA display. Combining that with an on-chip DAC for audio, the STM32F405RGT6 looks like a good choice for a DIY game console. [Makapuf's] Bitbox console is a single chip gaming machine based on the STM32 ARM processor.
We’ve seen some DIY consoles in the past. The Uzebox is a popular 8 bit open source game system, and [makapuf] was inspired by its design. His console’s use of a more powerful 32 bit processor will allow for more complex games. It will also provide more colors and higher quality audio.
One of the keys of the Uzebox’s success is the development tools around it. There’s a fullemulator which allows for debugging with GDB. [Makapuf] has already built an SDL based emulator, and can debug the target remotely using GDB. This will certainly speed up game development.
After the break, check out a demo of the first game for the Bitbox: JUMP. Also be sure to read through [makapuf]‘s blog for detailed information on the build.
http://hackaday.com/2013/09/18/the-b...ce-gaming-rig/
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 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.
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, 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
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 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.
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 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!
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, 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
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, 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.
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 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:Version 1.2 is only different by one line of code [...] It changes how the save game folder is created and now does this using the name of the .wad or .txt file used to launch the game. This means you get a full amount of save slots for each game and don’t have to share with the underlying wad.
http://boards.dingoonity.org/dingoo-...goo-native-os/
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 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!
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 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/
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 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.
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 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
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 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/
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
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
next » |
|
|
