Well since robbbert hasnt posted one I will

Gba:

ahawk - Has gotten worse now its just the same as Rob's was in the last one i can no longer see anything

Copper Bars - Works

Around the World - Blank Screen

Arm Wrestler - All the Arm VSTE Tests are bad

Fill - Completly Works now!

FontDisp - Errors out now.


Ds:
2dexample_arm9a - Now the Touch screen thing works.

2d_Exapmple - Works but no touch screen thing

Arm Wrestler - Same as before itll just blank on some screens but you can continue

BattleShipDS - Title Screen then Freeze

Birds - White screen

Cube, Ship, Tri, Nibbles - Balnk Screen

Dsmode4dc - Text then nothing
Dsmode4ep - Text on top blue on bottom

Davr_arm9a - Random Text on top with a pink background nothing on bottom

Drops-arm9a - Blue top Black Bottom

Draw-Arm9a - White flash on top then blank

Dspaint - Text on top with info then 2 strips of odd color on bottom Freeze

First1 - Nothing on top cool lava thing on bottom

Mines_arm9 - Top screen greens out and the bottom blues out.

Mode6.nds.arm9 - Disco like dance floor on top blank on bottom

PandaForth - Blank top screen white bottom screen but i get texto both saying PandaForth by Torlus

PongDs - Title screen is a little messed up PLAYABLE but 2 bugs would be that it slightly blanks out going from top to bottom screen but i think its supposed to like the real DS. But when it hits this side > it blanks out part of the ball

Tetris 1p - Works Perfectly

Tetris 2p - Works great and i can change bottom screens colors

Tile02 - Text and stuff then Freeze

Sman - FLashes red and blue between the screens

Sman Touch - Blue messed up on the bottom


And those are all the demos i have. do the logs even matter?

Also any roms not mentioned here that ive mentioned before have not changed.

I've been asleep. I'll have a look after work, in about 12 hours from now.

Thanks for the tests. The ARM v5 tests are bad because the GBA CPU is no longer an ARM v5. It's what it should be, an ARMv4. This extends to Fill1, since it employed an ARMv5 opcode to stop the CPU, which no longer gets executed. As for fontdisp, it's more a stop-working than an error-out (here, anyway); and it's my skills at SWI handling that're letting me down, I think.

Well whats odd is that it works perfectly on ds. Or is it two completly different CPU's that ye be talking about. Also are logs usefull in anyway?

Well in case there are i forgot to mention that Mario demo doesnt error anymore or have that huge repeating undefined thing.

Another one has though. Arm Wrestler has a bunch of them. Ds has this repeated

[20050403.21:21:56] COPRO: Read from cpF c0/c0 op 0/1 to r2

And GBA just has alot of undefiened opcodes. That might be caused by the whole ARMv4 thing. But you fixed the COPRO errors that the gba Arm Wrestler gave in 0.0.2g although the ones from the ds are still there.

Indeed so. The GBA has an ARM7 core now, whereas the DS has an ARM9.
Note that these aren't FAILs, just messages. Most of the time, you can safely ignore log messages until they are preceded by FAIL. I happen to like using the logfile to write out pertinent messages for debugging purposes; it's not all bad.

Yea but i showed that cause the GBA no longer shows that after youve made changes. It used to show that with 2g in the gba it showed it in the ds too. That also appears alot in the ones that mess up and not in the working.

Haven't tested new version of DSEmu (yet).

Anywho, I saw this on Dualis's Download page.

It's a document on the Graphics handling on the DS.

http://dualis.1emulation.com/files/gfxnotes.txt

Might be useful for DSemu to look at.

~Paladinate~

New major version means I report on ALL roms

Firstly, I think something good was attempted and it didn't quite work out... drag a rom onto the EXE and it opens in DS mode, even for GBA roms... oops.

DS ROMS

2d_emu and 2dexample_arm9a : checkerboard at top, lava at bottom, cherries are missing

armwrestler.ds.arm9 and armwrestler.nds.arm9 : load in bottom screen, top is black. All tests pass OK.

battleshipDS : freezes at start

birds_arm9 : white screen

cube_emu, ship_emu, tri_emu, DSnibbles : black

DSmode4dc : text, no colours

DSmode4ep : text and blue screen

davr_arm9a : purple and black

drops_arm9 : blue and black

draw-arm9 : black

dspaint : bottom screen corrupt and no response

first1 : lava at bottom

lights : black

mines_arm9 : text appears, click on bottom and game appears, no further response

mines_arm9a : bottom is blue, click on top screen and it turns green, then no further response

mode6.nds.arm9 : black. when emu closed it crashes

pandaforth : keyboard missing and no response

pongDS : no change - same bugs (1) ball is square should be round (2) slows down to a crawl after first point (3) all text is missing including the scores (4) ball goes invisible near right side

tetris-1p : works, cannot change bg

tetris-2p : works, cannot change bg of top screen. use A and S keys for bottom screen

tile02 : starts then no response

under_pressure : text is missing

tetris.nds : runs, no text, 1fps. All other NDS roms crash.

Overall, no change from version 2g, except it all runs incredibly slowly.

---------------------------

GBA ROMS

ahawk : "list.cpp 43 memory error"

copperbars : works
fill1 : works (advance)
fontdisp : freezes during load (regression)
aroundtheworld and gbadevad : black
ht : works
maddness : freezes emu

At this point I was getting tired of the slowness. Task manager shows that DSemu takes 99% of the CPU at all times. The slowdowns make testing impossible.

This CPU hog problem, and speeds like 0.3fps needs to be fixed now as further tests are pointless.

You seem to be getting stressed.

There is a reason for the CPU hogging; it's doing work all the damn time. As for the 0.01fps, I dunno what the issue is there; I get about 10fps on a P3-600.

If you take particular issue with the slowdown and the buggy output, I'd suggest that you fix it. The emulator is opensource, after all.

only 10fps? im geting about 50 with limits and 70 without x_X. Also since you said testing on all roms ill update my first post. Even though i dont have all those demos itd be nice if you could say where your gettingt them from. The whole fps thing might not be a problem with the emulator as it is with the computer what type of comp do you have?

EDIT: Updated my first post with alot more demos. Also about cpu usage. If its the thing i have open at the time it takes up like 90% of my cpu but when i useo therr things it goes down to about 40-50% which is still pretty large considering most things take up like 2-3% of my cpu usage.

DSemu only takes up about 10k when running, I dunno why robbbert was having so much trouble.

Stressed? Perhaps you're right. I'll give it a rest for while. cya

Rest is a good thing.

Well since it is open source like Two9A said im gonna try my luck at making a confid option for it fully intergrated not an independant program >>.

Hi,

I've tried compiling the latest CVS version of DSEmu with MS Visual Studio.NET and it complains about a missing config.h file referenced in defs.h. Any tips?


Thanks

Ignore that last post, just saw it mentioned in the Makefile. I'm having great fun converting it into a visual studio project.

Yea ive had problems using cygwin to compile it cause of config.h but right now im just trying to find out where it handels all the code for the child windows i know where the debugger code is its in its own source file. Im trying to figure out what links that to the main program.

The *.c files look like they're a mix of formats too, playing havoc with the visual studio editor. ds.c is in UNIX format while mmu.c is in DOS format. Meaning that the line numbers the debugger gives don't match.

What child windows do you mean?

Child Windows like Debugger and Pallete. Ive gotten pretty far to the point where it creats the windwos and then what toggles then showed or unshowed. I also found each windows proc. I still dont know whats connecting them all though.

dbgOut in dbgout.c draws the fixed-width characters on the buf argument it is passed. This drawing buffer is linked to the child windows with membuf being attached to the memory debug window, palbuf to the pallette, etc. This is done with the SetDIBitsToDevice call in glds.c I believe.

Well from what i can gather all the windows procs and stuff are in glds.c and in glgba.c ill look into that call and see what i find. If that doesnt work ill trace it back from main.c wince thats the main winmain function.

Someone understands my code? This isn't right.

Well, work backwards from the child window. Take the debugger window. It has its buffer blitted in emuRefresh (one of a few places). Where does the buffer get filled? ARM7status, which has a reference to dbuf. Where does dbuf get passed into the ARM core? emuInit, with ARM7init after it's been allocated. It all ties together.

If that made sense, you're a better man than me.

Well yea i see emuInit. I think im just not gonna do it the way you did it. I think im just gonna derive everything from win.c in the proc since im so lazy. It shouldnt slow down the emulator at all considering the code would only run when you open the window.