Busy times

.

Although there hasn't been too much activity regarding coding the emulator on my side, I was able to "solve" a disturbing issue on the emulator capabilities: Block transparency. I said "solve" because it wasn't really the most elegant solution out there, and it's merely a prototype of a workaround, but it's looking good so far.

Up to now, what I did was hacking some registry address (I know, bad solution), which led to a partial execution of transparency enabling. Yet, the border address appear as if they were uniformly modified, which needs to be fixed as soon as possible, even though it's a very small detail.

Basically, the registry was modified in lines 24 (DSH:4A0000H24FSH->DSH:4A0000H24FAH*) and 25
( F1FF A4H6 FFFF 0000-> &F1FF A4H6 FFFF 0001). The pointers are to reference/deference addresses only when needed (IE: The code now will disable the registry hacking when it isn't proper or when the game can run fine without it), since as of now, there aren't many games which require it.

Pic to show how it's looking:

Prime wifi works

.

First, i'd like to apologize for not posting as often as i used to. However, in this case, having no news actually means good news. I've been focusing in what would probably be the biggest feature in DS emulation so far: Wifi network programming.

So far, it's been quite a mess working with the specifications, as there's not enough documentation to base the work on, but i've been managing mostly on the engineering of an actual DS and it's served very well for the work needed so far. As of now, most of the 16 bit structutes have been coded, and circular buffer is in the works. I had to start from the begining because previous versions had very little (if any) of this work done.

Most of the coding was done on the flowcharts field. My intention was for the emulator to be able to access the primary network, but that hasn't been possible because TIME_BEACON and TIME_PREBEACON functions not being fully coded yet. However, those functions are dependant on the registry files, and those files are dependant on the BB and RF chip procedures. So what i did was update the Memory control options to have at least some connection support. Range and Address settings are almost done, so that's excellent news. Here's the piece of C code which i'll be importing into assembly for Rffilter operations:

WIFI_triggerIRQ(wifi, WIFI_IRQ_SENDSTART);
WIFI_Host_SendData(wifi->udpSocket, wifi->channel,(u8*)&wifi->circularBuffer[address], txLen);
WIFI_triggerIRQ(wifi, WIFI_IRQ_SENDCOMPLETE);

address &= 0x1FFFF;
wifi->circularBuffer[address >> 1] = val;

No screenshots today, as there's nothing to show aside from boring pieces of code. I'll upload maybe some header files to hopefully get some input sometime in the future, but we'll see about that.

Newest features

.

I haven't posted much recently, but that doesn't mean i've been inactive. In fact, as many of you have noticed, v2.4a is out and is the closest release to a full speed NDS hardware so far. Up to now, there are still some network options (Specially wi-fi) to code, but sound and speed acceleration are practically done (Even though some settings were hacked, but that isn't much of a problem).

There isn't much to talk about the current release, but i'll let you know that the next one won't be focused around wi-fi, but to achieve stability between speed and graphics issues, without losing much on one of them. I'm working on the DMC (Dynamic memory control), specially on the cache and TCM, trying to get to coordinate some lacking features, such as Read allocation methods and pseudo-random replacement algorithms.

As of now, some games are running smoothly and a couple of freezing bugs have dissapeared. I was specially concerned about games that froze at a certain Frame rate, or through other unexpected bugs. It was one of the main problems with no$ since most games were playable up to the point when the cache failed to allocate memory, even if the graphics were being displayed correctly.

And that's it for now. No more chit chat, as this topic is long and boring (Though very important). I'll leave you a few screenshots as well:

Some flickering fixes

.

Today's post will be brief since the fix wasn't that much of an advance, but rather an adjustement of a bug that made the screen unstandable at some points. The focus of the problem revolved around the fact that the BLDALPHA function was incomplete, and half of its instructions weren't being applicated correctly.

In short, what had to be done was coding the rest of it. Modules 13-15 and 5-7 were correctly coded, but 0-4 and 8-12 had some partial errors that caused flicker at the top screen. I had used SDL previously to fix this problem to an extent, but since it persisted i figured i'd just finish the function. Since both of them are 32-bit instructions, the only thing to be done was completing the coefficients. Module 0-4 had to be redirected to "First target", while the 8-12 one was to the "Second target".

As always, a pic without flicker at the top screen:

Speed and graphics improvements III

.

I've been working a bit on graphics lately; taking a break from the speed acceleration. During these past days, i centered my attention to games with more recent games, or in other words, the +600 ones.

The video capture functions had a few bugs i felt like fixing since it made some backgrounds and other textures display incorrectly. The Display engine has 32 possible values, divided in 14 modules, all of which have different ranges. The ones that were being displayed incorrectly were module 3 (values 8-12); module 6 (values 18-19) and module 10 (value 25).

Modules 3 and 6 were pretty easy to fix, i just had to add addresses 0=08000h and 0=18000h to the current function and they started to work after while. Module 10, on the other side, was a pain on the back to fix; i had to do a lot of trial/error to finally find that FIFO had to be set to 1 for it to execute properly.

After fixing the Video capture mode, here's what it looks like

Speed and graphics improvements II

.

Well, a new release is up with a few more features not specifically useful in terms of emulation capabilities, but they do add to the Emulator structure (ie: The Microphone inclusion). However, and as said before, work will be centered from now on into fixing speed and graphic issues.

One of my main worries was the poor capability of Texture blending the emulator had. I spent a few hours fixing the polygon pixels display, which consists of Vertex and Texture colors. The main problem was that the previous versions only used one of either by resorting to the function TEXIMAGE_PARAM, but i figured a way to have the CPU used both simultaneously if needed.

Basically, to use only Vertex colors, TEXIMAGE_PARAM must be equal to 0, whereas to use only Texture colors, ALPHA_POLYGON must be equal to 31, so, in order to coordinate between the 2 of them:

Blending = !(*ALPHA&31) + (1 - PARAM&length;3) & 3

Which also increases speed by saving the CPU a lot of proccesing power:





















That'll be all for now. See ya in the next update

Speed and graphics improvements I

.

Well, since the last release, it's been quite clear that the emulator's compatibility was good enough. Now we have to center around Speed and graphics issues. One of the main problems that was causing low framerates is known as SwapBuffer misfunction.

The SwapBuffer exchanges the two sets of Polygon/Vertex RAM buffers, that is, the newly defined polygons/vertices that are passed to the rendering engine. The another buffer, therefore, gets emptied and passes to the geometry engine to get filled with the geometry commands. However, if the polygons and RAM addresses are passed incorrectly, then the game is likely to have: a) Low framerates (Due to the 2nd buffer having to wait for the correct instructions) and b) Gfx errors (Caused by the aforementioned SwapBuffer misfunction)

To fix the SwapBuffer, i had to set the values of that function = 1, meaning that it'll be sorted manually from now on. It's hard to do so, i know, but it's probably for the best as of now, until i come up with an algorithm that can execute it automatically (Also note that depth buffering isn't supported manually, so there will still be Gfx errors). For now, speed has increased even more, and there are a few of Graphics fixes:

























New updates to come up soon