gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > DS emulator problems

#66675 - radicalrandy - Thu Jan 12, 2006 8:43 pm

I have used all three ds emulators and I tried to get some of the code that comes with DEVKITPRO to work. I've been trying to get a rotation program to work with IDEAS, however the program doesn't seem to sense any actions from the keyboard. Can anybody tell me why this program isn't sensing anything from the keyboard or tell me how to fix this?

#66678 - radicalrandy - Thu Jan 12, 2006 9:06 pm

here's my code for the keyboard stuff

scanKeys();
u32 keys = keysHeld();

if( keys & KEY_R ) angle--;
if( keys & KEY_L ) angle++;
if( keys & KEY_LEFT ) scrollX++;
if( keys & KEY_RIGHT ) scrollX--;
if( keys & KEY_UP ) scrollY++;
if( keys & KEY_DOWN ) scrollY--;
if( keys & KEY_A ) scaleX++;
if( keys & KEY_B ) scaleX--;
if( keys & KEY_START ) rcX ++;
if( keys & KEY_SELECT ) rcY++;
if( keys & KEY_X ) scaleY++;
if( keys & KEY_Y ) scaleY--;

anybody know why this isn't working?

#66680 - radicalrandy - Thu Jan 12, 2006 9:13 pm

Well I answered my own question.

Apparently the code I'm looking at is wrong, I should be using
if(keysHeld() & KEY_A)
{
whatever the hell I want it to do
}

#66789 - MrD - Fri Jan 13, 2006 3:37 pm

Are you inverting the key input properly with KeysHeld?
_________________
Not active on this forum. For Lemmings DS help see its website.

#66829 - radicalrandy - Fri Jan 13, 2006 7:35 pm

Yes apparently the code that comes with DEVKITPRO doesn't all work, which makes ds development difficult to start at. Two different programs seem to handle keyboard input differently and only one of them works.

#66920 - wintermute - Sat Jan 14, 2006 1:09 pm

radicalrandy wrote:
Well I answered my own question.

Apparently the code I'm looking at is wrong, I should be using
if(keysHeld() & KEY_A)
{
whatever the hell I want it to do
}


That really shouldn't be any different to what you posted earlier

#66921 - wintermute - Sat Jan 14, 2006 1:13 pm

radicalrandy wrote:
Yes apparently the code that comes with DEVKITPRO doesn't all work, which makes ds development difficult to start at. Two different programs seem to handle keyboard input differently and only one of them works.


All the code that comes with devkitPro has been tested on hardware, if it doesn't work then the emulators are at fault.

#66944 - tepples - Sat Jan 14, 2006 4:55 pm

Problem at this stage is that all publicly available emulators are "still at fault".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66948 - wintermute - Sat Jan 14, 2006 5:16 pm

tepples wrote:
Problem at this stage is that all publicly available emulators are "still at fault".


What's that supposed to mean?

If code works on hardware and doesn't on emulators then the emulators are missing something.

Being honest I get really fed up with claims that the toolchain is at fault when the supposedly faulty code runs fine on hardware

#66954 - tepples - Sat Jan 14, 2006 6:18 pm

Problem: The publicly available Nintendo DS emulators are missing something.

Solution: Fix the emulators. Problem with this solution: Developers don't have time to fix the emulators, and they're not willing to let The Community do it either. Case in point: The maintainer of iDeaS quit and didn't release source code.

Workaround: Use only hardware. Problem with this workaround: The amount of manual labor inherent in juggling a memory card between a GBA Movie Player and a USB memory card writer after each build might be holding back interest in DS homebrew.

Workaround: Fix libnds. But does there exist a well-defined subset of libnds that works on hardware and at least kinda-sorta works on the emulators that are publicly available today?

Workaround: Develop only for PC. Congratulations; you've limited the growth of the DS homebrew scene.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66956 - wintermute - Sat Jan 14, 2006 6:29 pm

tepples wrote:


Workaround: Fix libnds. But does there exist a well-defined subset of libnds that works on hardware and at least kinda-sorta works on the emulators that are publicly available today?


This assumes that there's something wrong with libnds that can be changed to work with emulators. The problem is actually that the emulators do not fully emulate the DS not that libnds takes advantage of hardware quirks.

There's nothing to fix ( at least in terms of emulators)

Solution:

Use hardware or write an emulator that works properly.

#66958 - tepples - Sat Jan 14, 2006 6:31 pm

I understand that it is not your fault, but but people are being scared away from DS development and being directed toward "Workaround: Develop only for PC." The problem with writing an acceptable emulator, even for the version of Hello World distributed with libnds, is that starting from scratch now might take so long that the Nintendo DS might be end-of-lifed by the time it's finished.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66974 - melw - Sat Jan 14, 2006 9:09 pm

It's a shame that iDeaS project got cancelled, but there's fortunately other emulators and hopefully some day we'll see an emulator that is good enough for all kinds of development. But I think you're overstating the difficulty of developing with hardware. Using WiFiMe after code / compile cycle adds something like 10 seconds to get things running on the real thing. At least I'm not that impatient this would be a real problem.

(Even with flash cards, copying first to CF / SD and booting the DS takes max. 30 seconds - well, and that's why I rather use WiFiMe :)

#66977 - tepples - Sat Jan 14, 2006 9:24 pm

melw wrote:
Using WiFiMe after code / compile cycle adds something like 10 seconds to get things running on the real thing.

And buy a new computer that can take an additional PCI card, as both PCI slots in my computer are filled.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66990 - GPFerror - Sat Jan 14, 2006 10:33 pm

there are a 4 opensource ds emulators now dsemu, dualis and DeSmuME and also the next generation dsemu is also opensource and the sourcecode is available for download.

I have done all of my coding on emulators there are some limitations to what can be done, some of my code has special workarounds depending on whether its a release build or a test build for emulators.

With the emulators and the kind folks in irc chat as beta tester on hardware its been going good so far. And one of these days Ill be able to purchase hardware to actually test and run my creations/ports.

Troy(GPF)
http://gpf.dcemu.co.uk

#67015 - HyperHacker - Sat Jan 14, 2006 11:58 pm

There's still another problem with testing only on real hardware, though. Debugging is a lot harder. You can't single-step instructions, and if the CPU crashes you can't open up a debugger and see what went wrong.

#67090 - doublec - Sun Jan 15, 2006 12:58 pm

Quote:
Solution: Fix the emulators. Problem with this solution: Developers don't have time to fix the emulators, and they're not willing to let The Community do it either. Case in point: The maintainer of iDeaS quit and didn't release source code.


DSEmu is open source and I'm more than willing to let the community work on it. A number of patches have been received and applied to the codebase from the community. Feel free to contribute!

I've not had any problems with button handling with DSEmu and libnds by the way. Can you point me to a homebrew or some source code that demonstrates something that doesn't work?

#67152 - tepples - Sun Jan 15, 2006 10:05 pm

start dsemu
Open DS...
Select devkitPro/examples/nds/Graphics/2D/BG_Rotation/BG_Rotation.nds and click OK
Debug > Run
See corrupted top screen, as if it were displaying 8-bit data in 16-bit mode
Press S key
"dsemu.exe has generated errors and will be closed by Windows."
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#67241 - doublec - Mon Jan 16, 2006 1:04 pm

Thanks for the bug reports Tepples!

Code:
See corrupted top screen, as if it were displaying 8-bit data in 16-bit mode


I've pushed some patches through to the source code repository to fix this. The bitmap displays fine now. You'll need to build DSemu from source or wait for the next release in about a week.

Quote:
Press S key
"dsemu.exe has generated errors and will be closed by Windows."


This is also fixed in the repository.It wasn't a key handling problem it was due to handling video memory incorrectly and causing a crash.

Details on source code repository is here:
http://www.double.co.nz/nintendo_ds/dsemu.html#source

#67302 - GPFerror - Mon Jan 16, 2006 9:48 pm

cool fixed the graphical output for XrickDS.

How difficult would it be to add gdb debugger to the emulator?

sourcecode debugging would be the coolest feature to me, beats adding print statements everywhere to view in the logwindow :)


Troy(GPF)
http://gpf.dcemu.co.uk

#67315 - doublec - Mon Jan 16, 2006 11:29 pm

Quote:
cool fixed the graphical output for XrickDS.


Great! It fixed the display of the console text in DSLinux as well. I've got some other grapphical fixes in progress which should make the next release run a few more things.

Quote:
How difficult would it be to add gdb debugger to the emulator?


I'm not sure I'd have to do some research on gdb. One of the GBA emulators does this doesn't it? It's a good idea, I'd find it useful as well, so I'll look into it.

#67318 - GPFerror - Mon Jan 16, 2006 11:35 pm

doublec wrote:

I'm not sure I'd have to do some research on gdb. One of the GBA emulators does this doesn't it? It's a good idea, I'd find it useful as well, so I'll look into it.


cool, yeah Visual Boy Advance emulator has that feature.

Also I did find this article on Implementing a Debugging Agent for the GNU Debugger, don't know how helpful it is though.
http://billgatliff.com/drupal/node/26

And if I remember right I think arm-elf-gdb/Insight is available on devkitpro site but im not sure if its targetted for the DS or not.

Troy(GPF)
http://gpf.dcemu.co.uk

#67329 - tepples - Tue Jan 17, 2006 1:46 am

Another thing I'd like to see is a VRAM viewer so that I can look at tiles, textures, palettes, etc. VBA has that too.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#67358 - doublec - Tue Jan 17, 2006 12:03 pm

I looked at the GDB remote debugging information and it looks implementable without too much difficulty. I'll definitely get on to trying that out.

The VRAM viewer is another good idea. I do want to improve the information provided about the various VRAM banks.

I've released DSEmu 0.4.10:

http://www.double.co.nz/nintendo_ds/dsemu.html

It contains the fixes from yesterday as well as some more. This release includes working Sprite support. A few more demo's work now as a result.

#67368 - melw - Tue Jan 17, 2006 3:18 pm

Thanks for the update! One thing I've been wondering lately - everything printed on DSEmu console debug screen is corrupted. But the same thing works perfectly on real hardware. Here's an example of what I get (on the screen it should be lot of rows with "fps: 60.0" or similar information):

[Images not permitted - Click here to view it]

#67372 - GPFerror - Tue Jan 17, 2006 4:52 pm

try going to the options menu and then select configuration and check the Unscramble console text and click OK

See if that fixes the problem, if not im not sure whats wrong.

Troy(GPF)
http://gpf.dcemu.co.uk

#67376 - wintermute - Tue Jan 17, 2006 5:35 pm

what does unscramble console text do?

#67379 - GPFerror - Tue Jan 17, 2006 5:53 pm

it was added to dsemu 0.4.7
Quote:
Workaround for 'console scramble'. There has been an issue since DevkitPro R14 which causes text output using the console output routines to be scrambled. I implemented a workaround in 0.4.6 but it didn't work for homebrew programs built with previous versions. I've been unable to fix the problem so far, so I added a 'Unscramble console text' option in the Options/Configuration menu option. If you run a game and the text appears scrambled, check or uncheck this, and it should correct the problem when you press 'Ok'. I hope to fix this in 0.4.8.

#67382 - wintermute - Tue Jan 17, 2006 6:11 pm

GPFerror wrote:
it was added to dsemu 0.4.7
Quote:
Workaround for 'console scramble'. There has been an issue since DevkitPro R14 which causes text output using the console output routines to be scrambled. I implemented a workaround in 0.4.6 but it didn't work for homebrew programs built with previous versions. I've been unable to fix the problem so far, so I added a 'Unscramble console text' option in the Options/Configuration menu option. If you run a game and the text appears scrambled, check or uncheck this, and it should correct the problem when you press 'Ok'. I hope to fix this in 0.4.8.


yeah, but what does it *do* ? As in what do you change to get the output code to work in dsemu?

#67389 - GPFerror - Tue Jan 17, 2006 6:32 pm

here is the relevent code, not sure what its doing though

Code:
if(unscramble) {
               int addr = lcd * 0x80 * 0x4000 + charBase+(((tileChar&0x03FF)>>1)*32)+(x/2)+y;
               b = MMUMainrdB(0, addr + 0x06000000);
            }
                else  {
               int addr = lcd * 0x80 * 0x4000 + charBase+(((tileChar&0x03FF))*32)+(x/2)+y;
               b = MMUMainrdB(0, addr + 0x06000000);
            }

#67395 - GPFerror - Tue Jan 17, 2006 7:48 pm

also for BMP8_512X512 and mode6 BMP8_1024X512 etc they just cause dsemu to close with no error.

If I change void GPUscanLCD0 function to increase the array size of scanlines to scanline[1025] from scanline[256] it doesnt close anymore, of course it doesnt display anything but its not crashing lol

Troy

#67410 - doublec - Tue Jan 17, 2006 8:56 pm

Quote:
also for BMP8_512X512 and mode6 BMP8_1024X512 etc they just cause dsemu to close with no error.


Thanks I'll fix this. It's just options not yet implemented and as you noted the close is caused by it trying to write the non-displayed parts of the bitmap to the scanlines, exceeding it's array size.

wintermute, the unscramble text option is a hack which changes the tiles index used to find out what character to display. I've not yet had a chance to really dig into how this side of things work yet - or what dsemu is getting wrong. It appears to get the wrong character depending on what screen it's displaying on, what mode is being used, etc.

Even when unscramble works, it doesn't work for all characters. The extended rotation bitmap example in devkitpro displays the text fine, but the numbers showing the coordinates are scrambled. I'm sure it'll turn out to be something simple in the end :)

#67411 - pepsiman - Tue Jan 17, 2006 9:08 pm

GPFerror wrote:
here is the relevent code, not sure what its doing though

It's changing the address looked at to get the tile data to cope with 16colour tiles. When bit7 of the background is not set, each tile uses half the memory.