wraggster
December 16th, 2013, 22:50
I introduced a rather annoying bug in the previous version, so I decided to release this new version today. However, I have also made some architectural changes to this version, so it is possible that I again introduced some new bugs. This is why I decided to still have the old 0.11 version available for download as the "previous" version. It should not have any major bugs, so you may revert to it if you have problems with this version.
Here are the changes in this version:
Fixed arrow (cursor) key handling, which got broken in 0.12 version when I added the Curses library header. I had not noticed that both the Curses library and the Linux input headers define the same key macros (like KEY_LEFT). I fixed this by moving the Curses header file include after the normal console keyboard input routine, so that the header file affects only the console key emulation routines. This small change seemed to fix that problem, so that I did not need to move the routine to a separate source file (which would have been the other possible fix).
Changed the interrupt handling system to use Linux asynchronous signals instead of separate threads. I had emulated the timer IRQ by launching a new thread which only wakes up at the current emulated timer IRQ speed interval, and sets a variable that tells the main thread to start handling an IRQ. Since the Linux thread context switch runs at 1000 times a second, the highest IRQ speed that this system can handle (in theory) is around 1000Hz. However, some games play Sound Blaster Direct DAC audio, meaning that they only generate one audio sample during each IRQ timer tick. This type of audio sets the timer IRQ to run at over 10kHz, and it obviously was not possible to emulate such a system using a separate thread.
The new system sets up a Linux interval timer (alarm) to run at the requested timer IRQ frequency. The main thread gets interrupted at the speed of the interval timer, and this signal handlers sets the same variable that the separate thread used to set. To avoid race conditions I also changed all my other IRQ routines (like the Sound Blaster, keyboard, mouse and serial IRQs) to use async signals. I originally created this system for my zerox86 (http://zerox86.patrickaalto.com/zblog.html) emulator, as the Linux kernel on that platform only ran the context switch at 250Hz, which was not sufficient for many games.
Improved SB Direct DAC handling and SB detection routine emulation for Ishar: Legend of the Fortress. Major part of this improvement was due to the new interrupt handling system, but I also noticed that the game occasionally fails to detect Sound Blaster and attempts to play digitized music using the PC Speaker. This is not supported in rpix86 at all yet, so the result was just some horrible screeching sounds. The game uses a hardcoded loop to wait for SB IRQ to happen, and at times this loop ran completely before the thread context switch had a chance to run the SB audio emulation. I made rpix86 detect this type of SB detection system, and have it spend 8 milliseconds simply waiting for the SB thread to run before continuing. This made the SB detection work more reliably in Ishar.
The Direct DAC audio quality is still pretty horrible, but there is not all that much that can be done about that. There will always be a bad audio glitch during the screen blitting, as the main thread that should generate the audio will not run during that time. So, expect heavy glitching at least 60 times per second in this type of audio.
Fixed screen resolution of the BC Racers game. This game first goes to normal MCGA 320x200 256-color mode, and then programs the CRTC registers to resize the screen to 288x224 pixels. I improved my MCGA mode screen blitting to recognize this nonstandard screen size and adjust the OpenGL ES texture handling accordingly.
Implemented some more special keys for the experimental terminal emulation. Some Alt and Ctrl key combinations should now work, same as most function keys. This code still needs work and many keys are still not correctly supported.
I will continue working on the other problematic games that you have reported to me either directly or via the Raspberry Pi forum rpix86 thread (http://www.raspberrypi.org/phpBB3/viewtopic.php?p=413377#p413377). Hopefully I will get a few more problems fixed again in the next version. Let me know of any problems you encounter in this version, and thanks again for your interest in rpix86!
http://rpix86.patrickaalto.com/rblog.html
Here are the changes in this version:
Fixed arrow (cursor) key handling, which got broken in 0.12 version when I added the Curses library header. I had not noticed that both the Curses library and the Linux input headers define the same key macros (like KEY_LEFT). I fixed this by moving the Curses header file include after the normal console keyboard input routine, so that the header file affects only the console key emulation routines. This small change seemed to fix that problem, so that I did not need to move the routine to a separate source file (which would have been the other possible fix).
Changed the interrupt handling system to use Linux asynchronous signals instead of separate threads. I had emulated the timer IRQ by launching a new thread which only wakes up at the current emulated timer IRQ speed interval, and sets a variable that tells the main thread to start handling an IRQ. Since the Linux thread context switch runs at 1000 times a second, the highest IRQ speed that this system can handle (in theory) is around 1000Hz. However, some games play Sound Blaster Direct DAC audio, meaning that they only generate one audio sample during each IRQ timer tick. This type of audio sets the timer IRQ to run at over 10kHz, and it obviously was not possible to emulate such a system using a separate thread.
The new system sets up a Linux interval timer (alarm) to run at the requested timer IRQ frequency. The main thread gets interrupted at the speed of the interval timer, and this signal handlers sets the same variable that the separate thread used to set. To avoid race conditions I also changed all my other IRQ routines (like the Sound Blaster, keyboard, mouse and serial IRQs) to use async signals. I originally created this system for my zerox86 (http://zerox86.patrickaalto.com/zblog.html) emulator, as the Linux kernel on that platform only ran the context switch at 250Hz, which was not sufficient for many games.
Improved SB Direct DAC handling and SB detection routine emulation for Ishar: Legend of the Fortress. Major part of this improvement was due to the new interrupt handling system, but I also noticed that the game occasionally fails to detect Sound Blaster and attempts to play digitized music using the PC Speaker. This is not supported in rpix86 at all yet, so the result was just some horrible screeching sounds. The game uses a hardcoded loop to wait for SB IRQ to happen, and at times this loop ran completely before the thread context switch had a chance to run the SB audio emulation. I made rpix86 detect this type of SB detection system, and have it spend 8 milliseconds simply waiting for the SB thread to run before continuing. This made the SB detection work more reliably in Ishar.
The Direct DAC audio quality is still pretty horrible, but there is not all that much that can be done about that. There will always be a bad audio glitch during the screen blitting, as the main thread that should generate the audio will not run during that time. So, expect heavy glitching at least 60 times per second in this type of audio.
Fixed screen resolution of the BC Racers game. This game first goes to normal MCGA 320x200 256-color mode, and then programs the CRTC registers to resize the screen to 288x224 pixels. I improved my MCGA mode screen blitting to recognize this nonstandard screen size and adjust the OpenGL ES texture handling accordingly.
Implemented some more special keys for the experimental terminal emulation. Some Alt and Ctrl key combinations should now work, same as most function keys. This code still needs work and many keys are still not correctly supported.
I will continue working on the other problematic games that you have reported to me either directly or via the Raspberry Pi forum rpix86 thread (http://www.raspberrypi.org/phpBB3/viewtopic.php?p=413377#p413377). Hopefully I will get a few more problems fixed again in the next version. Let me know of any problems you encounter in this version, and thanks again for your interest in rpix86!
http://rpix86.patrickaalto.com/rblog.html