|
|
Raspberry-Pi News is the number one site for Raspberry-Pi Homebrew, News and releases, Part of the DCEmu Homebrew & Gaming Network.
THE LATEST NEWS BELOW
|
May 19th, 2013, 22:41 Posted By: wraggster
 For how awesome Google Voice is, we're surprised we haven't seen this before. [Steve] is using Google Voice to run commands on just about any Linux box. Google Voice doesn't have an official API, and existing unofficial APIs weren't up to snuff for [Steve]'s project. He ended up writing his own that checks his unread message inbox every minute and looks for new text messages
http://hackaday.com/2013/05/19/contr...-google-voice/
To read more of the post and Download, click here!
 Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
 |
|
|
|
May 19th, 2013, 22:40 Posted By: wraggster
 One aspect of the Raspberry Pi that has always challenged us is the power supply. It was a great idea to power the board from a standard micro-USB port because economy of scale makes phone chargers (even in the 1A range necessary for stable operation of the RPi) cheap and easy to acquire. The thing we miss is the ability to power the device on and off using the built-in hardware.
http://hackaday.com/2013/05/19/atx-r...-raspberry-pi/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 18th, 2013, 15:54 Posted By: wraggster
We’ve been following the work of [Andrew Holme] and his homebrew GPS receiver for a while now. A few years ago, [Andrew] built a four-channel GPS receiver from scratch, but apparently that wasn’t enough for him. He expanded his build last year to track up to eight satellites, and this month added a Raspberry Pi for a 12-channel, battery-powered homebrew GPS receiver that has an accuracy of about 3 feet.
The Raspi is attached to an FPGA board that handles the local oscillator, real-time events, and tracks satellites automatically. The Pi handles the difficult but not time-critical math through an SPI interface. Because the Pi is attached to the FPGA through an SPI interface, it can also load up the FPGA with even more custom code, potentially turning this 12-channel receiver into a 16- or 18-channel one.
An LCD display attached to the FPGA board shows the current latitude, longitude, and other miscellaneous data like the number of satellites received. With a large Li-ion battery, the entire system can be powered for about 5 hours; an impressively portable GPS system that rivals the best commercial options out there.
http://hackaday.com/2013/05/17/homeb...-raspberry-pi/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 18th, 2013, 15:42 Posted By: wraggster
The RPiCluster is a 33-node Beowulf cluster built using Raspberry Pis (RPis). The RPiCluster is a little side project I worked on over the last couple months as part of my dissertation work at Boise State University. I had need of a cluster to run a distributed simulator I've been developing. The RPiCluster is the result. I've written an informal document on why I built the RPiCluster, how it was built, and how it performs as compared to other platforms. I also put together a YouTube video of it running an MPI parallel program I created to demo the RGB LEDs installed on each node as part of the build. While there have certainly been larger RPi clusters put together recently, I figured the Slashdot community might be interested in this build as I believe it is a novel approach to the rack mounting and power management of RPis."
http://hardware.slashdot.org/story/1...th-neat-tricks
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 15th, 2013, 01:07 Posted By: wraggster
 Remember that Raspberry Pi camera module we wrote about a few months ago? It looks like UK-based electronics retailer CPC / Farnell will start taking orders for the shooter on May 14th. Users on the Raspberry Pi forums who signed up for info about the camera module have received an email from the retailer inviting them to order. As a reminder, the five megapixel fixed-focus shooter -- which only measures 25 x 20 x 9mm -- can snap 2,592 x 1,944-pixel images and capture video at 1,080p (30fps), 720p (60fps) and VGA (60 or 90fps). While the accessory is expected to cost about $25, there's no actual pricing details on CPC / Farnell's website. Wanna see the camera module in action? One lucky Raspberry Pi user's received the device early and shared a video -- check it out after the break.
Update: As promised, the boards are now officially available to order per a blog post on the Raspberry Pi website. And the price is indeed $25. Hit the source link for a list of commands needed to activate the add-on, or check after the break for another video demonstrating the setup process and some PR explaining Element 14's competition to promote the Pi and its camera.
http://www.engadget.com/2013/05/13/r...h-lands-early/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 15th, 2013, 01:06 Posted By: wraggster
 Screen Grabs chronicles the uses (and misuses) of real-world gadgets in today's movies and TV. Send in your sightings (with screen grab!) to screengrabs at engadget dot com.
The original premise of NBC's show Revolution is that in the near future some unknown worldwide catastrophe devastated all electronic devices, plunging everyone into a blackout. As the plot has progressed however, in limited cases the power is coming back on. That includes a nanotech machine a couple of characters are planning to use to perform emergency surgery -- by shoving what appears to be a USB stick into an open wound -- and its configuration is enabled thanks to a very familiar-looking $35 device. Keen eyed viewers spotted a Raspberry Pi (top center) as it popped on screen a few times, however like our own prime time cameo it flashes by very quickly, the screencap above may be your best look at it.
http://www.engadget.com/2013/05/14/s...pi-revolution/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 12th, 2013, 00:32 Posted By: wraggster
Behold, something we’ve always wanted. [Matthieu] mounted his Raspberry Pi board inside of a computer monitor. His work makes for the cheapest smart-TV modification we can possibly think of.
The image above shows the monitor’s driver board on the left, with the Raspberry Pi mounted on the back plastic cover. [Matthieu] used a short HDMI cable to connect the two. The HDMI connector plugs into the RPi directly. The other end has been cut off and the wires soldered to the DVI pins on the monitor’s PCB. This is not a problem since HDMI and DVI use electrically identical protocols. The one thing missing is audio. But if you were pulling off the same hack with a device that had HDMI (like a television) it would just be a matter of also soldering in the audio connections. While he had his iron hot he also connected a 5V source from the monitor board to the RPi. He completes his hack by cutting a slot in the monitor case to allow access to the SD card.
We’ve long wanted an XBMC computer we could velcro to the back of the TV and the RPi turned out to be just the thing. Now we’ve got to consider cracking open the TV to replicate this internalization hack!
http://hackaday.com/2013/05/09/raspb...puter-monitor/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
May 3rd, 2013, 16:58 Posted By: wraggster
Here's an Interesting idea of how to use a Raspberry Pi and a few other inexpensive items to make a low cost detection system. From the article: 'The Drone Shield would combine a Raspberry Pi, a signal processor, a microphone, and analysis software to scan for specific audio signatures and compare them against what known drones sound like. (Because obviously a Predator drone is going to sound very different than a small quadcopter.) Once a match is found, the Drone Shield then sends an e-mail or SMS to its owner..
http://tech.slashdot.org/story/13/05...tection-system
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 28th, 2013, 22:35 Posted By: wraggster
via http://rpix86.patrickaalto.com/rblog.html
Improvements in the new version
This version does not have any new features, it has just various small fixes and improvements, mainly affecting certain games. Here is a list of the changes:
Fixed a potential crash when a game moves the cursor far outside the screen area.
Implemented a dummy OUT 82,AL operation (Alone In The Dark).
Improved SB IRQ behaviour for short DMA buffers (Alone in the Dark).
Implemented a missing REP MOVSW Mode-X to RAM operation (Ween - The Prophecy).
Fixed a bug in REP MOVSW RAM to Mode-X operation (Ween - The Prophecy).
Implemented reading from DMA page register (Super Frog).
Implemented USE16 version of Mode-X REP STOSD opcode (Super Frog).
Implemented USE32 version of REP INSB opcode (Super Frog).
Implemented USE32 version of REP OUTSB opcode (Super Frog).
Added JPE special handling for "Super Frog".
Further detail about the changes
In the beginning of last week I got some error logs from rpix86 forum user Vanfanel, containing problems in games Alone in the Dark, Ween - The Prophecy and Super Frog. I began by troubleshooting Alone in the Dark, as I already had that game and it works fine in DSx86. However, as soon as I started it in rpix86, the whole rpix86 crashed with a segmentation fault. I could not even get an error debug log, which I thought was a bit strange.
Being able to run my emulator on top of a real operating system has the advantage that I can attach the GDB debugger to it from a different shell session, and I can then have GDB tell me exactly where the program crashes. With DSx86 and DS2x86 these problems have been much harder to track down, as they will simply hang the whole system in similar situations. In this case the debugger showed that rpix86 tried to draw the text mode blinking cursor outside of the memory block I had allocated for the text mode screen. I calculate the cursor position based on the row and column values, but had not limited those in any way. So if a game decides to hide the cursor by moving it to row 255 for example, my code simply tried to draw it there, even though the text mode only has at most 50 rows, and normally only 25. I added an out of bounds check and skipped the cursor drawing if the address is out of bounds, and this got rid of the crash.
After this small fix I got the exact same rpix86dbg.log error report from Alone in the Dark as what Vanfanel had reported to me. This was caused by the game trying to setup Sound Blaster with DMA channel 3 instead of the DMA channel 1 (which it actually uses in rpix86). I added a dummy handler for that DMA channel, but this only caused rpix86 to crash again with a segmentation fault. I again debugged this problem, and found out that the game executed code at the end of the RAM area (which was full of zeroes) and continued beyond the end of the RAM area! Obviously something much more serious was going on.
I do have various conditional debug defines in my cpu emulation sources, just for these kinds of problems. I enabled the "do not run zero code" and the "trace all opcodes" flags, and ran the game again. I found out that the game attempted to execute code at address FFEF:0008 forwards, and there it ran into zero code. After some more debugging I noticed that it jumps to that address when it tries to call the DOS INT 21h interrupt, and sure enough, some code had overwritten the int 21h vector to point to that invalid address!
I also have a memory watch feature built into rpix86, so I added a watch for the int21h vector address, and found out the code where it gets overwritten. It took me quite a while longer to understand what was going on, as I noticed that the root cause for the memory overwrite problems was that the game first allocates all available DOS memory, loads and executes another program, and after it exits the game again tries to allocate all available memory (of which there is none at this point), does not check whether the allocation succeeds and then proceeds to loading another program into memory that has not been allocated! This loading then obviously corrupts memory from all sorts of locations, including that int 21h address.
Since the game does work in DSx86, I began debugging it there and comparing the behaviour with what happens in rpix86. After considerable time I noticed that the first program that gets loaded is actually a Sound Blaster driver, and it exits with an error code if it can not determine the IRQ number for the Sound Blaster. It occurred to me that I had not run the Alone in the Dark hardware configuration option in rpix86. When I ran that, it detected only "Sound Blaster (no DMA)", even though it should have also detected "Sound Blaster (DMA)". Using the no DMA configuration allowed the game to start, though, but the audio was very bad.
So, obviously the problem was related to the game not detecting the SB IRQ number. After some more debugging I realized that the game does not set the playing frequency at all, and in rpix86 it gets left at zero, which will then never cause an IRQ to happen. In DSx86 I had (by chance) handled this situation better, and I copied the same handling to rpix86. This finally allowed the game to detect the proper Sound Blaster (DMA) audio device. The game does still not run very well, though. It has some weird slowdowns, so that it actually runs faster in DSx86! I have not yet managed to determine what causes these slowdowns, it looks like some sort of a timing issue.
The next game I debugged was the Ween - The Prophecy. It used a couple of somewhat more rare VGA Mode-X block moves, which I had not yet implemented in the code I had ported over from DSx86 and converted to be compatible with protected mode. I implemented these operations, and this allowed Ween to start up and proceed to the actual game fine.
Next I downloaded and tested Super Frog. The first problem was simple, it attempted to read from the Sound Blaster DMA page register, which I just had not implemented yet. After I implemented this, it proceeded to the next problem, where it attempted to clear the Mode-X graphics screen using a 16-bit REP MOVSD block operation. I had only implemented the 32-bit version which is usually used by protected mode games, but for some reason Super Frog wanted to use the 16-bit version even when it ran in 32-bit protected mode. This was pretty easy to implement, though.
After that problem Super Frog stopped into protected mode REP INSB port operation, which it used to read the VGA palette register values, and immediately after that into the corresponding REP OUTSB operation used to set the VGA palette register values. These were also easy to implement.
Finally the game stopped into a JPE opcode, in a code that was exactly like the routine mentioned in the Simply FPU tutorial for reducing an angle within the allowable range of ±263 radians. That is, the game obviously uses a lot of floating point operations, which are currently simply handled as a no operation in rpix86. At this point I assumed that this game can not be made to run in current rpix86, but I decided to code support for this specific algorithm anyways.
After this fix, to my surprise, the game did start up and did seem to work. I don't know how to play that game so I don't know whether it uses floating point operations during the game so that it will be unplayable, but I will leave that to you to test. :-)
I also spent a little time testing X-Wing, which seemed to work without problems, and also the horizontal pan jitter problem in Commander Keen 1. This jitter problem is difficult to solve, and I could not figure out a way to improve it in this version yet.
New web site features
Last week I also got a request to add a donate button to my rpix86 pages. Thus, I added one at the bottom of the main page. This is not a request for you to donate anything, but there is now a button for that purpose if for some reason you absolutely want to donate. :-)
Also, big thanks to Ben Garrett, who created a very informative tutorial for rpix86 installation and usage. The tutorial also gives a short history lesson about what DOS is, so check it out! I added a link to the tutorial also to my FAQ page.
In other news...
Last week I also got contacted by the people behind the new gaming console Game Consoles Worldwide Zero, or GCW-Zero for short. They would like me to port my x86 emulator also to their new device, and this is something that I find quite interesting. The device is powered by an Ingenic JZ4770 CPU running at 1GHz, so it is quite a bit more powerful than the 360MHz JZ4740 that is in the DSTwo flash cart for which I developed the DS2x86 version of my emulator. However, both of those processors use the MIPS32 architecture, so it should be relatively easy for me to port my DS2x86 code (which is 95% MIPS32 ASM) over to work on GCW-Zero.
I have already done some preliminary porting tests, and there are some issues that I need to solve to be able to run my emulator under an operating system, but these issues are reasonably similar to what I had to do when porting DSx86 over to rpix86. What this means, though, is that it looks like my finishing my Android port will get pushed back, as I am currently more interested in working on GCW-Zero than on my continuing the ax86 version. But who knows, possibly I can use some new features (that are coded in C language) in both of them!
Anyways, thanks again for your interest in my emulators! Have a nice 1st of May!
Download Attached
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 21st, 2013, 23:03 Posted By: wraggster
The Dos emulator for the RaspBerry Pihas been updated:
This new version has the following fixes and enhancements:
- New serial port emulation support, with rpix86 now forwarding data between emulated serial port COM1 and a USB-to-serial device connected to your Raspberry Pi. This new support might work also with the GPIO UART connection, but this is completely untested. Note that you will need to give the new -s[NUM] parameter to rpix86 when you launch it to enable serial port support. For example, if your device is connected to /dev/ttyUSB0, you would give parameter -s0. There is a special parameter -sA, which attempts to use the /dev/ttyAMA0 GPIO UART device.
Note that I have only tested this serial port emulation with the Telix communications program talking to my old modem, so it may or may not work with other serial port programs and serial devices. Let me know if you have problems with it, I can then try to improve the support.
- Changed the -w and -h parameters to not force 4:3 aspect ratio. In prior versions you could change the screen size using those parameters, but rpix86 always attempted to keep 4:3 aspect ratio (as used in practically all monitors during the DOS era). If you do not give those parameters rpix86 will still attempt to keep 4:3 aspect ratio. Note that you can also combine the overscan parameters with the screen size parameters, to get the rpix86 window to be pretty much whatever aspect ratio and located anywhere within your physical screen area.
- I also added a simple dialog window to show up when launching rpix86 inside the X Window environment, when rpix86 can not find 4DOS.COM. Previously rpix86 would just quit without showing anything in this situation. This feature is mainly to avoid frustration with new users (who don't RTFM :-) failing to launch rpix86 for the first time.
Now rpix86 will show the above dialog, and wait for the user to press either Y or N. The dialog will show the directory that will be used as the C: root, so if that is wrong you can just press N and adjust your launch directory or rpix86 parameters.
If you press Y, rpix86 will download 4DOS.COM to the directory shown, and then attempt to launch the actual main window. For some reason this seems to often fail with a "BadMatch" error message, so you may need to restart rpix86 manually.
- Added an icon to rpix86 application when running in X Window. The icon is shown also in the title bar of the above 4DOS question dialog.
- Added also the current version number to the X Window title bar.
- Enhanced the keyboard and mouse reading system, so that it will not slow down the actual emulation quite as much as before. I also added the joystick and serial port reading to the same system, so all of those are now handled somewhat more efficiently. I hope I didn't break anything when making this change.
Here below is again a screen copy that shows a couple of the new enhancements: New rpix86 icon in the title bar, showing the version number in the X Window title, and running Telix in rpix86. The Telix window shows the result of giving a command AT\S to my old modem, connected to my Raspberry Pi with a Prolific PL2303 USB to RS-232 adapter.
Thanks again for your interest in rpix86, I hope you find the improvements in this new version useful!
via http://rpix86.patrickaalto.com/
Download via comments
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 16th, 2013, 23:53 Posted By: wraggster
Six months after the release of Wayland 1.0, versions 1.1 of Wayland and Weston have been released. Wayland/Weston 1.1 brings new back-end support for the Raspberry Pi, Pixman renderer, Microsoft Remote Desktop Protocol (RDP), and FBDEV frame-buffer device. Wayland/Weston 1.1 also introduces a modules SDK, supports the EGL buffer-age extension, touch-screen calibration support, and numerous optimizations and bug-fixes."
http://tech.slashdot.org/story/13/04...rry-pi-support
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 14th, 2013, 22:59 Posted By: wraggster
via http://rpix86.patrickaalto.com/rblog.html
First off, rpix86 now has a logo image! Big thanks to UnfocusedBrain (http://unfocusedbrain.com/) for creating a cool image for rpix86! I immediately liked the idea when I saw the image he had created, as I think it nicely combines the Raspberry Pi theme with the x86 text. I now use small versions of that image as the favicon of these pages, and in the rpix86 executable when running under X Window graphical environment. I also used the image in the new Raspberry Pi Store BoxArt image.
I have not managed to get nearly as much work done on rpix86 this past week as I did during my vacation week. During workdays I don't have much time to work on my hobby projects. I did however acquire some new hardware which I can use when coding new features and testing them. I got a Roland MT-32 sound module from eBay, and an USB to RS-232 converter cable. I used to have a Roland LAPC-1 sound card back in 1991, but I swapped it for a Roland SCC-1 in 1992. Even though the new card was in some ways better, I have pretty much been regretting this switch ever since. I still have the SCC-1 card, but I don't have any PCs with ISA card slots so I can not use it any more. I thought it might now be time to re-acquire a MT-32, I can use it when testing the MIDI support in rpix86, and I also have some old MIDI compositions that were made for MT-32 and don't sound correct on any other MIDI device.
I got the USB to RS-232 device in order to code serial port emulation into rpix86. This is the most often requested missing feature, so I thought I would try to add that next. This is what I am currently working on. I found an old modem in my closet, and I am first trying to get communications between rpix86 and that modem working. I am using an old DOS communications program Telix to test the communications. I used that program back in the early 90's to call various BBS systems. Launching up Telix in rpix86 brought back a lot of memories from those old times. :-)
I am hoping to get the serial port support done by the next weekend, but it might take longer. In any case, thank you again for your interest in rpix86!
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 13th, 2013, 23:29 Posted By: wraggster
We like the look which [Emmanuel] achieved with his Raspberry Pi based Squeezebox client. It’s got that minimalist slant that makes it seem like a commercial product at first glance. But one more look at the speakers without grates, the character LCD, and the utilitarian buttons, knobs, and switches tips us off that it’s filled with the hardware we know and love.
Since Logitech announced that it was terminating the Squeezebox line we’ve seen several projects which take up the torch. We’ve seen the RPi used as a Squeezebox server and several embedded Linux systems used as clients. This follows in the footsteps of the latter. The RPi is running Raspbian with the squeezelite package handling the bits necessary to talk to his server. The controls on the front include a power switch, rotary encoder and button for navigating the menus, and a potentiometer to adjust the HD44780 LCD screen’s contrast. The speakers are a set of amplified PC speakers that were liberated from their cases and mounted inside of the wooden box that makes up the enclosure. The in-progress shots of that case look pretty rough, but some sanding and painting really pulled everything together. As you would expect, we’ve embedded the demo video after the jump.
http://hackaday.com/2013/04/13/squee...box-appliance/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 7th, 2013, 18:28 Posted By: wraggster
via http://rpix86.patrickaalto.com/rblog.html
Okay, after working on rpix86 for the whole of my vacation week, I feel that I have managed to get quite a lot of work done on it. It was nice to be able to focus on it for a full week, especially as I had a good list of interesting new features that I wanted to implement. I am going to explain the new features and other fixes with a bit more detail this time, so let's get on with it.
[h=4]1. EGA palette handling fix[/h]In the previous 0.04 version I made some minor performance enhancements to the 16-color graphics modes palette handling. The change was so minor that I did not even think to run my small test.com x86 program that simply loops through all the supported graphics modes and prints some characters and lines with different colors. If I had run it, I would have noticed immediately that my small fix actually broke the 16-color palette handling! Sorry about this, I think in the future I need to always run this test program before the release, and it might be a good idea to always have the previous version available for download in addition to the just released version. So if the latest version breaks something, you can try running the previous one. In any case, now the palette problems are fixed in this version.
[h=4]2. Hardware mouse cursor emulation[/h]The next major feature is the addition of a hardware mouse cursor. Perhaps "hardware" is somewhat of a wrong term as back in the VGA days the cursor was usually drawn by the mouse driver instead of actual hardware, but I use the term to make a distinction between a (software) mouse cursor that the game itself draws, and a (hardware) mouse cursor that gets drawn simply by calling the int 33h mouse function "Show mouse cursor". My test.com tester program uses the hardware mouse cursor in all the different graphics modes, so it was a good test bench also for this work.
I wanted to see if I can use actual hardware (the OpenGL ES engine) in Raspberry Pi to draw the mouse cursor, my problem was just that I am still really unfamiliar with the OpenGL ES techniques and only barely understand how the vertex and fragment shaders work. However, I thought that attempting to make a mouse cursor for rpix86 would be a good learning experience, and thus I began working on it. I started with a simple OpenGL ES triangle tutorial, trying to get a white triangle visible on top of the actual background texture showing the PC screen. After I got that working, I began enhancing it by adding a texture to contain the actual mouse cursor shape. It took me some googling to get the alpha channel working properly, and then a lot of trial and error to get everything showing in the correct orientation. After some more studying I realized that I could perhaps have the vertex shader do all the position and scaling adjustments so that I don't need to do that in code. I was pretty happy with the end result, the vertex shader now shows the mouse cursor in the correct location and takes into account the current mouse cursor shape hot spot locations etc.
The current vertex shader code looks like the following, in case you are interested. The mouse cursor size is based on a 640x400 screen size, and it will then get proportionally larger when zooming the PC screen to larger displays.
static const char* mouse_vertex_shader = "attribute vec2 a_position; \n" "attribute vec2 a_texcoord; \n" "varying mediump vec2 v_texcoord; \n" "uniform ivec2 u_mouse_xy; // Mouse (x,y) position \n" "uniform ivec2 u_max_xy; // Max mouse coords (screen size) \n" "uniform ivec2 u_hot_xy; // Mouse hot spot position \n" "void main() \n" "{ \n" " // Adjust the mouse coordinates by the screen size. \n" " float x = float(u_mouse_xy.x)/float(u_max_xy.x)*2.0 - 1.0; \n" " float y = float(u_mouse_xy.y)/float(u_max_xy.y)*2.0 - 1.0; \n" " // Adjust the mouse hot spot position by the cursor size. \n" " x = x - float(u_hot_xy.x - 16)/640.0; \n" " y = y - float(u_hot_xy.y - 16)/400.0; \n" " // Adjust the vertex position by the mouse position. \n" " vec2 p = vec2(a_position.x + x, a_position.y - y); \n" " v_texcoord = a_texcoord; \n" " gl_Position = vec4( p, 0.1, 1.0 ); \n" "} \n";I also need to have code that converts the mouse cursor shape (given to the mouse driver using int 33h commands) to a texture. That conversion (which happens very rarely) is done with the following code. The name of the routine is from the DSx86 version where I used a hardware sprite to draw the mouse.
static u32 mouseTexture[16][16]; // RGBA valuesvoid CursorToSprite(u16 *mask){ // Convert from input 16 bits per 16 rows screen and cursor masks // to 16x16 matrix of RGBA values. int x, y; for (y = 0; y < 16; y++) { for (x=0; x < 16; x++) { if (mask[y+16]&(1<<(15-x))) // cursor pixel set = white mouseTexture[x][y] = 0xFFFFFFFF; else if (mask[y]&(1<<(15-x))) // screen pixel set = transparent mouseTexture[x][y] = 0; else // Both pixels clear = black mouseTexture[x][y] = 0xFF000000; } }}[h=4]3. Overscan adjustment support[/h]I had also received reports that rpix86 does not handle screen overscan properly. Especially when using a PAL TV output, part of the rpix86 DOS screen is in the overscan area and thus not visible. This of course makes using rpix86 pretty difficult. I had assumed that setting the overscan values in the /boot/config.txt would affect all software, but it seems to affect only the console and X Window screens.
I decided to add support for reading the /boot/config.txt overscan values, and in addition I thought it might be a good idea to have command line parameters to allow still further overscan adjustment. Thus I added the following new command line parameters to this version of rpix86:
-olLEFT where LEFT is the amount of overscan on the left border. If not given, defaults to /boot/config.txt overscan_left value. -orRIGHT where RIGHT is the amount of overscan on the right border. If not given, defaults to /boot/config.txt overscan_right value. -otTOP where TOP is the amount of overscan on the top border. If not given, defaults to /boot/config.txt overscan_top value. -obBOTTOM where BOTTOM is the amount of overscan on the bottom border. If not given, defaults to /boot/config.txt overscan_bottom value.The current values are written to stdout (if they differ from zero) when rpix86 starts, so you can check that the correct values get used, and change them when starting rpix86 if necessary.[h=4]4. Support for running rpix86 in X Window environment[/h]I also have been wanting to try adding support for running rpix86 inside the X Window graphical environment for some time now. Since many people run their Raspberry Pi "headless" without any screen or input devices connected, it would be nice if also those users could run rpix86. Of course rpix86 will run much slower when in the X Window environment, but there is a lot of old DOS software that is not performance critical and thus would run fine.
I started by googling for general information about coding for the X Window system (which was yet another completely new area for me). I found an interesting forum thread started by teh_orp, and example code in github by a forum member shirro. As the thread and code are both a bit dated already, I am not sure if this is the best way to do this, but I decided to give this approach a try. It looked like it did not require many changes to my existing OpenGL ES code, so I began adding the required changes. After a few hours of work I already had rpix86 showing up in a window (the picture was upside down, but that just needed some adjustments to the code).
I used a WinVNC connection from my Windows XP development PC to my Raspberry Pi to test this. At this point the keyboard and mouse reading still used the /dev/event files, and I knew I had to change them to use the X Window event system when running in X Window, otherwise it would not work via WinVNC and similar remote desktop connections.
I had coded touchpad mouse support into DSx86, which works by detecting the touch position on the screen and then converting these coordinates to the mouse position. I tested how the X Window mouse coordinates behave, and it looked like I can use this system pretty much as-is. The X Window mouse movement events give coordinates in pixels relative to the left top corner of the window, just like the mouse coordinates should work. This will work fine as long as the game does not use its own scaling system, which sadly many games do. Such games will most likely not be usable from within the X Window environment (thus I consider the X Window support in rpix86 to still be in the "experimental" state).
Adding keyboard support also introduced new problems. I could not find proper keycodes from the key press and key release events. Running rpix86 via VNC, and from the X window started from the console, had different keycodes for the same keys, so I knew that I can not use the keycode directly. After mapping the keycode to a KeySym value the result was (mostly) similar, but the problem was that I have a Finnish keyboard layout and rpix86 expects to get raw US keycodes, which it can then give the KEYB DOS program to convert. I haven't yet found a proper way to get the raw keycode (unaffected by the keyboard language) from the KeySym that the X Window returns. Thus some keys might not work or give incorrect keys when running rpix86 in X Window environment. It might help if you set the X Window keyboard mapping to US with a command setxkbmap us in the LXTerminal window before starting rpix86.
[h=4]5. Option to run rpix86 without audio[/h]When testing rpix86 in X Window via VNC, I realized that it might be somewhat useless to run the audio emulation if your Raspberry Pi is completely headless, with no I/O capability besides the ethernet connection. So I added a new command line option, -a2, which skips the audio emulation thread startup and thus plays no audio. This option will make rpix86 run around 10% faster, perhaps even more if a game uses both AdLib and SoundBlaster audio.
[h=4]6. Added support for running "Chess Genius 3" DOS version[/h]After releasing version 0.04 I got a rpix86dbg.log crash log from running Chess Genius 3 by Richard Lang DOS version in rpix86. From the log I could see that the game uses jpo (Jump if Parity Odd) opcode. This is a problem in rpix86, as my CPU emulation core does not support the Parity flag natively. Whenever a game uses either JPO or JPE (Jump if Parity Even) opcodes, rpix86 will quit with an error log unless I have coded specific support for this situation.
The game-specific support for Parity flag in rpix86 works by examining the previous opcodes whenever the JPO/JPE opcode is encountered. The specific code snippet in Chess Genius 3 had the following opcodes:
1AF0:3980 A818 test al,181AF0:3982 7505 jne 3989 ($+5)1AF0:3984 31BFB001 xor [bx+01B0],di1AF0:3988 C3 ret1AF0:3989 7B0D jpo 3998 ($+d)That is, the game tests the AL register for value 0x18, and if either of those two bits are set, it jumps to address 0x3989 where it tests whether the parity is odd (meaning that only one of those bits are set), in which case it jumps to address 0x3998. To support this in rpix86, I need to know what was the operation that was supposed to set the parity flag, calculate the result of this operation, determine the resulting parity flag value, and then either jump or not jump depending on the result. The problem is that I don't keep track of which opcodes have been executed and in what order before encountering the JPO/JPE opcodes.In the above situation it is not very difficult to determine the correct parity flag value. I can test that the opcode bytes before the JPO opcode are those 0xA8, 0x18, 0x75, 0x05, 0x31, 0xBF, 0xB0, 0x01, 0xC3, in which case I know the correct parity flag can be calculated by anding the AL register with 0x18, and counting the number of resulting bits. There is by the way a neat ARM ASM trick for calculating the parity of a register, created by FluBBa.
The problem in the case of Chess Genius 3 was that this was not the only location where it used JPO/JPE opcodes. Every time I fixed one location and tried to run the game in rpix86, it soon stopped in the next location and so on. After adding about a dozen or so special cases, I noticed that the code segment seems to stay the same, so I decided to disassemble this whole code segment and look for JPO and JPE opcodes from the disassembled result.
I found out that the game had 36 different locations in the code where it used the JPE opcode, and 35 places with JPO opcode, used in a variety of ways. There were even a couple of pretty difficult problems, for example in this code:
1AF0:58C6 A809 test al,091AF0:58C8 B004 mov al,041AF0:58CA 7A02 jpe 58CE ($+2)The code tests the AL value, then stores something else into AL, and then jumps based on the parity result of the test. When rpix86 encounters the JPE opcode, it has no way of knowing what AL value was used in the test, because the value had already been overwritten! I needed to add code to store the TEST AL,imm8 opcode (0xA8) result into memory, in order to use this later in the JPE opcode. This will marginally slow down the handling of that opcode, but luckily that is not the most commonly used opcode, and simply writing a byte to memory (into stack area, actually) should not slow anything down noticeably.I have been letting the game run a match (computer versus computer) for a long time and it does not seem to encounter any problems, so hopefully the game will now work properly in this 0.05 version.
[h=4]7. Other JPE/JPO opcode support fixes[/h]
When adding the JPO/JPE opcode support for Chess Genius 3, I noticed that I had not ported the existing special support properly from DSx86 version to the rpix86 version. I fixed the problems in the existing support, which affected all the following games. If you have encountered weird problems in these games, they might work better in this version. Some of the names only show the executable name, as those are based on DSx86 crash logs so I have not known the actual game name: - Amazing Spiderman
- Batman Returns
- Bubble Ghost
- BUBBOB
- CALGAMES
- F29 Retaliator
- GWBASIC
- Micro Machines 3
- STARGATE
- Super Solvers: Challenge of the Ancient Empires
- The Incredible Machine
- TOUTRUN
- Turbo Science
[h=4]8. Help request[/h]If you are graphically inclined, I could use your help with rpix86. I would like to have a rpix86-specific favicon for these web pages, and I think that rpix86 could also have its own icon, which could be used when running it in X Window environment. Also, the "box art" image that I have in the Raspberry Pi store for rpix86 is pretty horrible. If you have an idea for an icon, and/or interest in creating one, please let me know! If/when I decide to use your icon/image, I will certainly credit you on these pages.
Download Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 3rd, 2013, 23:59 Posted By: wraggster
via http://rpix86.patrickaalto.com/rblog.html
[h=4]Version 0.04 information[/h]
In case you are not interested in reading my whole blog post, here first is the most important information about the changes in this new version: - Added support for 80x50 text mode. This is used by some of my old MIDI software, and also by Little Big Adventure setup program.
- Added support for USB analog joysticks (and foot pedals). Like in the old DOS days, up to 4 buttons and 4 analog channels are supported.
- Added emulation of Roland MPU-401 MIDI ports in "dumb UART" mode. All the MIDI commands are sent to /dev/midi1 device, so if you have a General MIDI synth connected to your RPi using an USB MIDI dongle, you should now get proper MIDI music out of your DOS games.
- Stripped out the debug symbol information from the executable, as that decreased the size of rpix86 to less than half of what it was.
[h=4]Sudden jump in interest for rpix86[/h]After I released version 0.03, I began working on the Android version of my emulator, as it looked like my new rpix86 release did not generate much interest (I received no emails nor any forum messages about it for the first two days after the release). I managed to create a download system for 4DOS.COM into my Android version as well. I am still relatively new to Android programming, so I was pretty proud of myself for getting this working after spending just a few hours of work on it.
Then suddenly on Tuesday evening I got several emails concerning rpix86, and also the Raspberry Pi forum thread seemed to suddenly have more views and replies than before. The same thing continued on Wednesday. On Thursday I then checked the web statistics of my rpix86 subdomain, and at first glance I thought there was some sort of a statistics error or hacking attempt going on. The normal traffic of about 50 visits per day had suddenly jumped to over 3000 visits per day!
After checking the "connected from" list of web sites, I realized that the statistics were probably correct, rpix86 had been mentioned on the Hack A Day site, and there had been over a thousand hits per day from that article alone to my web pages! No wonder the general interest had suddenly increased!
[h=4]rpix86 and DOSBox relationship[/h]In the comments of that Hack-a-day post there are some outright accusations of rpix86 being a *significant* ripoff of DOSBox. Even though everyone who reads these blog posts of mine will be able to immediately dismiss such accusations as untrue, I feel like it might be a good idea for me to address them here anyways. You can perhaps imagine that after working almost 4 years bulding my emulation core from the ground up opcode by opcode, it is pretty annoying having someone dismiss it offhand as a simple copy of some other software.
As a proof that rpix86 is a ripoff of DOSBox, one commenter has found three (3) functions that have the same names in rpix86 as in DOSBox: DasmI386, DasmLastOperandSize and op386map1. The author conveniently fails to mention that the remaining 56600 or so (based on the output of listing the symbol table of rpix86 and counting the resulting number of lines) functions in rpix86 have no counterpart in DOSbox. I would not consider 0.005 per cent similarity to be in any sense *significant*, but perhaps that is a matter of opinion.
The other issue that the author brings up is a possible GPL violation. Since I use the same names in my disassembler routine (which by the way is never executed during the normal run of rpix86, it is only used if/when rpix86 crashes) and the code seems to be very similar, the author thinks this is obviously a GPL violation. However, the debug_disasm.cpp source module in DOSBox is based on earlier work done by Robin Hilliard, which was released under Apache License (which does not force derivative works to be released as open source). His original source code is available for example here. Both DOSBox and my disassembler routines are based on this original implementation, I named my routines similarly to DOSBox simply to keep track of the bug fixes done by the DOSBox people, which I also might need to do to my version of the code. This was pretty much the first code I made into DSx86 back in the summer of 2009, and it has only had a few minor bug fixes and changes done to it after that time.
You would be hard pressed to find any other similarities between rpix86 and DOSBox, as I have made sure not to violate any licenses, and have sourced information from many other sources besides DOSBox. For example my DOS int21h emulation routines are much more closely related to FreeDOS than to DOSBox, as I used FreeDOS as an example when coding all those routines, not DOSBox.
If you are interested in the main architectural differences between my rpix86 and DOSBox, you might be interested in checking out the history of my emulation core. The roots of my emulator are explained in my earliest DSx86 blog posts, so if you are interested feel free to read them (from the bottom up if you wish to read them in chronological order): - See here for DSx86 blog entries from July-December 2012.
- See here for DSx86 blog entries from January-June 2012.
- See here for DSx86 blog entries from July-December 2011.
- See here for DSx86 blog entries from January-June 2011.
- See here for DSx86 blog entries from July-December 2010.
- See here for DSx86 blog entries from January-June 2010.
- See here for DSx86 blog entries from 2009.
[h=4]MIDI support[/h]Last week I got an email asking whether rpix86 would support MIDI, specifically running an old DOS MIDI sequencer program. I had not thought about this possibility at all, until this email message. I began to think about this, and realized that it should not be all that difficult to have rpix86 emulate a Roland MPU-401, and then send and receive all MIDI messages to/from the /dev/midi1 device. Since I already had an EDIROL UM-1EX USB MIDI interface and still have my old Akai X-7000 Sampling Keyboard (from around 1989), it looked like I actually have everything I need to code and test support for MIDI! Well, everything except a powered USB hub, which I then purchased on my way home from work.
I then hunted for some software to use for testing, and remembered my own old MidiTracker from 1991, which I used to play MOD files via MIDI using my Akai sampler. When testing it I realized I did not yet have 80x50 text mode support in rpix86, so before I could start working on the MIDI support I needed to code support for that text mode. My MidiTracker (same as my old LineWars II game) only used the "dumb UART" mode of the Roland MPU-401, so I started by coding support for that. After some coding I managed to get both MTRACKER and LW2 to detect a Roland MPU-401 MIDI interface in rpix86, and send the MIDI notes all the way to my Akai sampler. My MTRACKER should be able to also send the MOD samples to my sampler, but for some reason this does not seem to work. The sampler never acknowledges the received MIDI SYSEX header, and I have not yet found out the problem. This should not affect any of you rpix86 users, though, so fixing this is a low priority. If you are interested in MidiTracker, it is available here as MTRACKER.ZIP. The zip contains also documentation and full source code.
Download Attached
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 3rd, 2013, 22:51 Posted By: wraggster
The Raspberry Pi is all about low-cost computing, which makes this particular hackquite fitting, as it allows you to make a terminal for your lil' Linux machine out of something you may already have at home: a Kindle Paperwhite. Displeased with the glare from his laptop's screen on a sunny day, Max Ogden was inspired to find something better and ended up with this Paperwhite hack. It builds on the original "Kindleberry Pi" method for the Kindle Keyboard, although Ogden had to massage it for the newer model and added some extra hardware to make the setup as wireless as possible. You wouldn't call the end result a monitor, as such -- the Paperwhite logs into an SSH session running on the Pi, so it "pretty much only works for terminals." That's probably for the best, as Ogden guesses the lag between wireless keyboard and e-ink screen is around 200ms, but at least it has portability, battery life and sunlight readability in the 'pros' column. Details of the project can be found at the source below, meaning only time (and probably, a few peripherals) stands between you and the ultimate hipster coffee shop machine.
http://www.engadget.com/2013/04/02/k...berry-pi-hack/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
|
April 3rd, 2013, 20:30 Posted By: wraggster
We’re never really sure what to call these things. When we say “back up camera” it sounds distinctly like a redundancy system for when the primary camera fails to work. But it is used for when you move in reverse in an automobile. [Jeremy Blythe] built the distance sensing video system using a Raspberry Pi board as the brain.
The flexibility of Linux and the power of the RPi board ended up making it pretty easy to get everything working together. He’s using a Microsoft Lifecam Cinema HD camera, which connects to one of the USB ports on the board. Just above that you can see the infrared distance sensor which is connected to the RPi’s GPIO header using one of Adafruit’s Pi Cobbler breakout boards. This also facilitates the connection to the 176×220 color LCD screen.
In the video after the break you can see [Jeremy] testing out the system by moving his hand in front of the sensor. Python is used to grab the image from the camera, draw a circle on it, and overlay the distance in centimeters at the bottom. Once his hand is within 30cm the overlay turns red and the work STOP is displayed. Pretty neat!
http://hackaday.com/2013/04/02/build...arking-camera/
To read more of the post and Download, click here!
Join In and Discuss Here
Grab the latest Deals on Consoles, VideoGames and Mobile Phones and Tablets for IOS/Android from Ebay.co.uk/ Ebay.com/Amazon UK/Amazon.com |
|
|
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
next » |
|
|
