Pate has posted more WIP News of his Dos emulator for the DS

Since last weekend I have been working on the I/O port handling and other things that already exist in DSx86 but which I had not ported over to DS2x86 yet. When I got DS2x86 running, I wanted to immediately start working on the protected mode stuff, so I left a lot of code commented out. Now I thought is a good time to port this code as well, so that DS2x86 could run most of the same games that DSx86 runs. I got most of the EGA/VGA port addresses done, and then also coded the MCGA graphics support, so that Wing Commander II will progress up to the part where it attempts to play digitized sounds.

After I had coded the straightforward MCGA mode blitting (where only a 256x192 window of the original 320x200 screen is converted to 16-bit color and copied to the DSTwo SDK internal buffers), I thought that this might be a good time to look into improved screen scaling methods. Many users of DSx86 have requested a smoother screen scaling method, but I have not yet added that as it needs going from the 256-color palette mode to 16-bit color mode. Now with DS2x86 I need to use the 16-bit color mode in any case, so this is a suitable test bench for the better scaling method.

The biggest problem with the more advanced screen scaling methods is that they are quite expensive computationally. The direct palette conversion code is reasonably straightforward, it just needs an extra table lookup to convert the palette index to a 16-bit color that can then be written to the output buffer, like this (shown for a single row):

la v0, BG_PALETTE // v0 = address of the palette table
1: lbu t3, 0(t1) // Get a byte (palette index) from VGA VRAM
addu t1, 1 // Increment input index
sll t3, 1 // Palette table has 16-bit values
addu t3, v0 // t3 = pointer to the palette table
lhu t3, 0(t3) // Get the 16-bit color from the palette table
addu t0, 2 // Increment output index
sh t3, -2(t0) // Store the 16-bit color to output table
bne t0, t2, 1b // Loop until one row done


However, even the simplest smooth scaling method, linear interpolation, needs a division and two multiplications per pixel. I am actually not sure how many CPU cycles multiplications and divisions take on the MIPS processor of DSTwo, but I assume they are more expensive than normal additions and subtractions. In any case, I used a calculator and some experimenting, and noticed that what I actually need is a way to smoothly draw 4 output pixels for every 5 input pixels (as 320/256 = 5/4). So, I have only four separate cases, and in fact the two rightmost output pixels are mirror images of the two leftmost pixels, so actually I only have two different cases. I was sure that I can come up with some shortcuts for these two situations, so I began to look into these more closely.

Linearly interpolating over 5 input pixels showed that the first output pixel should have a color of 80% of the first input pixel and 20% of the second input pixel. The second output pixel should have 60% of the second input pixel and 40% of the third input pixel. Mirroring these, the third output pixel should have 40% and 60%, and finally the last output pixel needs 20% and 80% weighting of the colors. To get rid of the divisions, I looked into multipliers that would let me divide the result by a power of two (so that I can use a shift instead of division). The first 80%/20% case is pretty close to 25/32 (78.125%) and 7/32 (21.875%), and the 60%/40% case is close to 5/8 (62.5%) and 3/8 (37.5%). I coded the first version of a linearly interpolating scaling code using simple shifts and additions to handle this pixel weighting, and I thought the result looked satisfactory, especially as the pixel weighting percentages are not quite correct. The code did not seem to cause any noticeable slowdown, even though it is still far from fully optimized. Here below are screen copies of the zoomed and scaled versions of the same Wing Commander II title screen.


Next I plan to start looking into the audio support. The whole audio playing technique in the DSTwo SDK is still completely unclear to me, as I haven't looked into it at all yet. That is the biggest feature still completely unsupported, so it is time to start working on it.

http://dsx86.patrickaalto.com/DSblog.html ...

News via http://dingoonity.org/

FCEU320 with autoframeskip has been updated again! This emulator just keeps getting better and better!

Quote
v0.3 is here!
changelog:
* added button X to exit the emulator in file browser(exit in menu is not implemented yet)
* GUI is now on the POWER button, not on L
* L is now "load state 9"
* R is now "save state 9"
* updated mappers and boards
enjoy! ...

Yep you read right, theres a new release of the only active Nintendo 64 Emulator for the PSP.

Heres whats new:

What's changed in this revision:
Revision 601
Revision 600
[+] Small speed up in DList processing (Corn)
[~] Fixed daedalus profiler to profile Ucodes properly (Corn)
[~] Fixed missing preview msg in classic GUI (Corn)
[+] ScreenShots will be saved in ms0:/PICTURE for release and default dir for debug build
[~] Fixed issue that caused gui selection not be saved in preferences.ini
[~] Small clean ups, made a couple of funcs debug only, etc
[!] Corrected regression that messed up the penguins in M64
[~} Corrected regression that caused analog stick to stop working (thx KingPepper for reporting)
[!] Optimized intraFontGetID, uses about 70% less cpu (gui feels smoother now)
[~} Corrected overlapping text when psp is charging in bat info
[+] Changed how button polling in GUI is done, now is only done in one place instead of zillion times everywhere ( note : gui buttons now will be only checked 16.5 times/sec too) (Corn/Salvy)
Revision 599
[!] Made kernelbuttons even more robust
[!] Removed a bunch of hacks I had for KernelButtons (no longer need 'em)
[+] Implemented a wrapper for kernelbuttons to clean up code and make things easier
[~] Minor tweaks on the battery info when PSP is charging (psppwner300)
Revision 598
[+] Made rom deletion more robust, now rom list is refreshed. warning shows up before deleting, and deletion is canceled if other input is detected (Classic Gui recommended) (Corn)
[+] Is now possible now to reset only settings or only hle caches (Corn)
[!] Killed a couple of warnings from last commit (Corn)
[!] Improved Reset settings instructions, just follow the onscreen indirections.
[+] Added a new function to print intrafont text (pretty easy to use and can be used everywhere)
[!] Battery status and time is printed with intrafont to match with the Gui
[~] Improved GUI switching
[~] Corrected typo that prevented gprof build from compiling
[~] Removed debug info that I forgot from DeleteRecursive (debug build compiles again)
Revision 597
[+] Added build support for psp gprof (Thanks Hardhat for the help!)
[!] Cleaned up global prefs, also made "skip splash screen" and other prefs debug only
[!] Improved "Reset Settings", now is more robust and friendly (moved to global too)
[+] Implemented recursive deletion, hle cache is now deleted when resetting settings
[+] Implemented tooltips with usage info of features of the emu (only for Classic GUI) (Corn)
[~] Moved PSP Slim cache init out of initialization list

Warning : Make sure to back up your memory stick before using this revision.

http://forums.daedalusx64.com/viewto...t=2640&start=0

Those wanting to try an alternative PSP N64 Emulator can also try out Monkey 64 --> http://psp-news.dcemu.co.uk/emulator...psp-35150.html ...

The PSP Emulator for Windows has seen yet another release, heres whats new:

Partially implemented sceVaudio module.
Exported "Impose" and "System Param" settings to a new "Region" section in SettingsGUI.
Fixed VPL freeing in SceKernelVplInfo.
Properly implemented error handling for savedata MODE_SIZES in sceUtility.
Added new findings to sceAtrac3plus and sceSasCore.
Added drafts for missing sceAtrac3plus functions and implemented sceAtracSetAA3DataAndGetID.
Improved sceAudioSRCOutputBlocking.
Improved communication between scePsmf and sceMpeg modules.
Improved sceRtcTickAddMonths and sceRtcTickAddYears.
Updated all language files.
http://buildbot.orphis.net/jpcsp/ ...

Apple's (as yet unconfirmed) plans to make an iPhone with a built-in, programmable SIM chip is getting a strong push-back from European carriers who would have the most to lose from the shift away from physical SIMs. The Financial Times of London reports that carriers are saying Apple may provoke a "war" if they pursue this technology, and that they may decide to just stop offering iPhone subsidies in protest. Meanwhile, the industry group representing carriers is working on its own embedded SIM.

As we reported a few weeks ago, Apple is said to be working with SIM-card manufacturer Gemalto to make a programmable SIM-on-a-chip that would let consumers buy a phone directly from Apple and activate it with the carrier of their choice via iTunes.

http://modmyi.com/forums/iphone-news...built-sim.html ...

Apple's (as yet unconfirmed) plans to make an iPhone with a built-in, programmable SIM chip is getting a strong push-back from European carriers who would have the most to lose from the shift away from physical SIMs. The Financial Times of London reports that carriers are saying Apple may provoke a "war" if they pursue this technology, and that they may decide to just stop offering iPhone subsidies in protest. Meanwhile, the industry group representing carriers is working on its own embedded SIM.

As we reported a few weeks ago, Apple is said to be working with SIM-card manufacturer Gemalto to make a programmable SIM-on-a-chip that would let consumers buy a phone directly from Apple and activate it with the carrier of their choice via iTunes.

http://modmyi.com/forums/iphone-news...built-sim.html ...

Apple co-founder Steve Wozniak has turned the blogosphere upside down twice this past week. First, in a recently published interview with Dutch newspaper De Telegraaf, Wozniak was quoted saying that smartphones running Google's Android mobile operating system will likely have a better and brighter future than Apple's very own iPhone. It's a comment that got everyone in the tech space talking, including PC World, which published the following on Thursday:


Quote:
Apple co-founder Steve Wozniak thinks Android will eventually beat the iPhone as a mobile-phone platform in much the same way Windows computers squeezed Apple's market share in the PC

http://modmyi.com/forums/iphone-news...-misquote.html ...

Apple co-founder Steve Wozniak has turned the blogosphere upside down twice this past week. First, in a recently published interview with Dutch newspaper De Telegraaf, Wozniak was quoted saying that smartphones running Google's Android mobile operating system will likely have a better and brighter future than Apple's very own iPhone. It's a comment that got everyone in the tech space talking, including PC World, which published the following on Thursday:


Quote:
Apple co-founder Steve Wozniak thinks Android will eventually beat the iPhone as a mobile-phone platform in much the same way Windows computers squeezed Apple's market share in the PC

http://modmyi.com/forums/iphone-news...-misquote.html ...

News via http://wololo.net/wagic/2010/11/20/v...u-1-2-for-hbl/

Developer neur0n released a new alternate menu for HBL a few days ago, called vMenu (Visual Menu). He’s already back with a nice update today.

What you will LOVE about this menu is that it shows you the thumbnail of each Homebrew, and it does it faster than the XMB

The new version adds sound, and the possibility to browse the memory stick (version 1.1 was limited to the default folder)

There are still a few bugs here and there (I found that version 1.2 doesn’t show all my homebrews, for example it doesn’t display Wagic ), but this looks super promising, I highly recommend you to try it!

Download here, and don’t hesitate to post your feedback to neur0n in his thread on /talk where you will find alternate versions to dowload

Installation: unzip in the hbl folder of your memory stick, NOT in your homebrew folder! ...