Work in progress

[doublec]

I've updated the darcs repository with some new patches. These include X/Y key support contributed by Normmatt, partial FIFO support, some key handling fixes and GBA support re-enabled. Although the latter probably does not work, it's re-enabled for others to work on. When FIFO support is completed I'll release 0.4.7, including any other patches for other contributers.

[doublec]

FIFO support is completed and added to the darcs repository. There are a few bugs I want to try and stamp out and then 0.4.7 will be released. Some of the E3 demos run further now, but it looks like the hardware divide and squareroot registers may need to be implemented to get them further along. I tested a couple of GBA demo's with the recently re-added GBA support and they worked fine.

[Robert]

Sounds like good news. I have quite a few GBA demos and I'll be interested to see how they perform.

[crazyjul]

FIFO support is completed and added to the darcs repository. There are a few bugs I want to try and stamp out and then 0.4.7 will be released. Some of the E3 demos run further now, but it looks like the hardware divide and squareroot registers may need to be implemented to get them further along. I tested a couple of GBA demo's with the recently re-added GBA support and they worked fine.

<{POST_SNAPBACK}>

 

If you're interested in, I caan look at the square root and divider accelerator

I've already had a look at it, I just need to figure somthing out, and I think it'll be complete

[Normmatt]

Well what do you need to figure out?

[crazyjul]

The integer square root do not exist in C or C++ library. My first idea was to convert it to double, do the square root ad convert it back. but the conversion of a int64 to double can cause loss of data.

 

For now, i'm using this solution, knowing that it's both inaccurate and slow to execute.

 

I've made small test apps with libnds that just display the result of some division and square root. I'm just waiting my flash linker to validate the result of the emulator.

 

//EDIT : I've send a patch to doublec

Edited August 28, 2005 by crazyjul

[doublec]

Great, thanks! I'll take a look at it tonight.

[crazyjul]

I've looked at sprite code.

 

It seems that VRAMmap is never initialized, so when the program writes data int othe vmemory, as the vram pointer is null, the write is just skipped.

 

It seems that video memory remapping register is never written. Nobody knows any default value of it?? It maybe explained why some demo works (in fact, if they remap VRAM, it should work)

 

I will have a look at this tonight.

 

Crazyjul

Edited August 29, 2005 by crazyjul

[doublec]

VRAMmap is initialized in MMUMaininit in dsmmumain.c. It is initialized to nulls and then modified by writes to the VRAM registers. This is a recent change to get memory mapping working correctly (from 0.4.6). If you look at the MMUMainremapVRAM_BANK_A, etc functions you'll see where the initialization is done. Not all of it is implemented as I'm unsure how things like extended palletes, image textures, etc work.

 

I have noticed some demos don't map the VRAM by writing to the registers. I wrote a simple test of this and when writing to the memory area (VRAM_A for example), the write appears to work but when you read the value back you get 0x00, not what you wrote. So I assumed that there is no default mapping.

 

This may not be the case for sprites, or may not be the general case and only happened to be the case for the one that I tested of course.

 

Prior to me doing the VRAM mapping code sprites did not work correctly either so there may be something more fundamental wrong.

Edited August 29, 2005 by doublec

[doublec]

There is a problem with Thumb code emulation. GPFerror noticed that some of his demos don't run on dsemu if compiled with '-mthumb' but do if recompiled with '-mthumb-interwork'. For the former all that would happen is a black screen. This may be the reason why some of the demos give only a black screen.

 

I'm currently looking into this, to hopefully fix it for the 0.4.7 release.

[crazyjul]

VRAMmap is initialized in MMUMaininit in dsmmumain.c. It is initialized to nulls and then modified by writes to the VRAM registers. This is a recent change to get memory mapping working correctly (from 0.4.6). If you look at the MMUMainremapVRAM_BANK_A, etc functions you'll see where the initialization is done. Not all of it is implemented as I'm unsure how things like extended palletes, image textures, etc work.

 

I have noticed some demos don't map the VRAM by writing to the registers. I wrote a simple test of this and when writing to the memory area (VRAM_A for example), the write appears to work but when you read the value back you get 0x00, not what you wrote. So I assumed that there is no default mapping.

 

This may not be the case for sprites, or may not be the general case and only happened to be the case for the one that I tested of course.

 

Prior to me doing the VRAM mapping code sprites did not work correctly either so there may be something more fundamental wrong.

<{POST_SNAPBACK}>

 

So I'll try to make a lot of test. I'll start from scratch. From what I've understood, there are default value in vram mapping register, when I'll get my flasher, I'll try to read them. I will also do some test.

 

For the demo that does not work when not intializing the vram, they seem to write sprite at 0x06004000. On DsTekWiki, this is shown as Sprte memory, maybe when no memory is map to this address space.

 

Crazyjul

Edited August 30, 2005 by crazyjul

[crazyjul]

The darcs repository has been emptied and fill with tutorial

 

Where all the code had gone??

Where can I found the source??

 

Thanks

 

Crazyjul

[doublec]

Oops, my fault. Copied stuff into the wrong area. I've fixed it now and the repository is back online.

[crazyjul]

From what I've seen, it seems that DS graphic mode is close to GBA graphic mode when nothing is initialized.

 

Does somebody can approve this??

 

Crazyjul