|
|
|
July 5th, 2014, 00:38 Posted By: wraggster
Okay, after a very long hiatus I am back working on zerox86! I have been working on my other projects in the mean time, and also for the past couple of months my nephew has been using my GCW-Zero to test my library of over 300 DOS games on zerox86. He has not yet had time to test all of the games, so I will give my GCW0 back to him for a few weeks again.
Anyways, I released a new version of zerox86 today, mainly because I heard reports that zerox86 does not work on the latest GCW0 firmware from May 5th. It turned out that zerox86 did actually work on it, but since my directory defaults and error messages were not correct, it was not easy for new zerox86 users to figure out the potential installation problems. There are not all that many fixes in this version yet (as I only have worked on it for a couple of partial days), but here is the list of the changes and improvements I managed to implement.
[h=4]Implemented mouse scaling[/h]This has been one of the most requested missing features. In this version you can have new configuration keys MouseXScale and MouseYScale in the zerox86.ini. These should have a floating point value (like 0.5 or 2.0) to make the mouse pointer move slower or faster than the default speed. You can have these settings in either the default section or in the game-specific sections in the ini file.
[h=4]Fixed a crash in Grand Prix 2[/h]Grand Prix 2 is one of my newer test games, mainly because it is very pretty and runs in either 640x480 SVGA mode or in 320x200 MCGA mode. The menus are in the SVGA mode, so I can get nice screen copies from it :-)
http://zerox86.patrickaalto.com/zblog.html
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 5th, 2014, 00:44 Posted By: wraggster
Hey fellow Backers! It's Update time once again. Thanks for waiting one extra day. I wished for more shipping to be completed before posting this week and today more units have reached the post office for shipment.
> Numbers shipped:
As of today, 15 of the final 29 confirmed consoles have been dropped off at the post office for shipping the other 14 will go out Monday. What is left to be completed between now and our ultimate shipping completion goal in two weeks is the vetting and sorting of unexpected address confirmation emails and the shipment of consoles to all legitimate Backers therein. Some are indeed legitimate pledges from Backers our now-terminated fulfillment company claimed to have delivered to, when in reality they had not (hence our disposal of the "services" provided by that company). Other emails are a different story altogether. Without naming names, we have already received emails from Backers who have since proven to have already received their consoles as well as, outrageous as it is, address confirmation emails from individuals confirmed to never have been part of the KS campaign in the first place! Sorting out the con-artists is time consuming work, but we remain committed to meeting our goal of completely fulfilling any outstanding pledges in the next two weeks. We are sorry that some disingenuous people are slowing the process down, but we remain on track to meet our goal.
We promise that all who are owed a GCW Zero console will get one, absolutely no question about it.
> Power adapters:
As Justin Barwick stated, we began removing the DC adapter from GCW Zero packages back in late November/early December following multiple cases of EU/UK countries either cutting the power cords or rejecting or confiscating the package due to the power supply not being current-compliant for EU/UK territories. We are looking into finding a replacement adapter that will be CE/EU/UK compliant. Thus far, it seems it will likely wind up being a USB charger which we will mail out to anyone who requests one after all consoles are shipped out.
Alternatively, the console can be charged and powered via USB from your PC, or through a standard USB wall-plug charger. Using this method to recharge the Zero's battery is only marginally slower than using the DC adapter for this purpose. The Zero was designed to charge either way for the sake of personal preference, convenience and as a way of providing a backup option when one method is unavailable. For what it's worth, I've only used my power adapter once during my many months of Zero ownership. I much prefer the convenience, portability and versatility of charging via USB, but that's just my personal preference.
https://www.kickstarter.com/projects...d/posts/894288
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 5th, 2014, 01:09 Posted By: wraggster
via http://pdroms.de/
Sqrxz requires fast reflexes and is a simply mindblasting Jump’n’Run puzzle game with high frustration factor. Now ported to GCW Zero by Zear!
Storyline: While Sqrxz wandered around on a sunny day, he was unaware that he had lost all his items while enjoying the scenery. It was already dark until he recognized the loss. There was no possibility, but to go back where he started the trip and save his things. If the loss was not already enough, strange creatures appeared. Will they be helpful?
http://www.sqrxz.de/2014/06/27/sqrxz...-for-gcw-zero/
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, 01:19 Posted By: wraggster
Hi All,
I finally got around to releasing a set of ScummVM testing/preview builds for all the GPH backend devices (GP2X, Wiz and Caanoo) and the OpenPandora.
You can grab them from my site and I would appreciate any feedback from testing as these builds will they form the basis of the upcoming official 1.7.0 releases in the near future.
Comments to this thread, my site or the ScummVM forums please. Bug fixes and patches to the ScummVM tracker or GIThub  . Oh, and please don't mirror these test builds.
Cheers,
John
http://www.gp32x.com/board/index.php...dpost&p=970788
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 |
|
|
|
|
|
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 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 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 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 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 |
|
|
|
|
|
|
|
