I think it's an issue with how it looks for the BIOS files in the current working directory (which, when using command line, is the directory you run the command into).

____________________
Kuribo64

This kind of feature would require switching to a dedicated input API with direct access to all inputs, sort of like DirectInput but something portable. Or switching to polling keyboard input like we do for joystick input, but GTK seems to lack support for that.

____________________
Kuribo64

I was mostly saying what has to be done for the specific feature you request. I probably won't be working on it anytime soon, but if someone wants to...

____________________
Kuribo64

you need to export the savefile from DeSmuME to get a raw .sav that melonDS can use.

____________________
Kuribo64

you should put the .sav in the same directory as the ROM

____________________
Kuribo64

then, well, there must be an issue with melonDS itself

____________________
Kuribo64

oh, my bad, I missed that bit in the first post

then the issue must be on DeSmuME's side, either you did the export wrong or DeSmuME just does something wrong that causes this

____________________
Kuribo64

You can use your DS save, I guess, unless it's not good enough for what you want?

____________________
Kuribo64

wifi is for emulating local multiplayer between two melonDS instances or more.

there was experimental code for access point support, but it hasn't been released.

____________________
Kuribo64

well tbh my passion has been going down these times, as well as real life shito getting in the way, but that might pick up later on


the FPS cap is fixed at 60. some versions let you toggle it by pressing Tab iirc. not that melonDS is very fast, so... yeah.


Action Replay and such aren't supported.

____________________
Kuribo64

I'm late af, buuuut...

Posted by leptiphoenix

Thank you StapleButter !
Yes, from what I understood emulation is to make the bios use some virtual elements mounted by a program.
Also if I guessed right the bios is compiled and can't be read so emulaters have to input some datas and try to understand outputs.
But I am maybe totaly wrong X)

more like running software made for one platform on another platform. in the case of the DS, the game (or firmware) and the BIOS form the software stack.

said software stack is made for the DS, and we're running it on another platform, by essentially replicating what the DS would do when running it.

and actually, the BIOS (or any software for the DS) can be disassembled. it's not as straightforward as having the source code, but you can still figure out what the program does.

Posted by TechnoNightz

Oh, and this is Jamie from Kafuka. I'm not sure why I reregistered here at all... nevertheless it might teach me things! ^^

ironically I knew all these things before even reading this post

____________________
Kuribo64

I guess it's on the 'whenever I feel like doing it' list


issue is how to implement it using your typical audio API, too

basically those will regularly give you chunks of audio data sampled from the microphone at a selected rate

however, on the DS, there is no sampling in hardware. reading the TSC microphone input returns the current value. games do their own sampling by setting up a timer at whatever rate is convenient for them.

not sure how high you can go. then again, sampling faster than the audio output rate (~32KHz) would not be very useful (you couldn't play it back without losing the extra quality).


basically that means I'd need to set up timers of some kind in melonDS to read microphone input and update the returned TSC value accordingly.

____________________
Kuribo64

late af, but


taking note

____________________
Kuribo64

that's pretty much it. melonDS is not hiDPI aware, so the window contents are being drawn at the regular resolution and shittily upscaled+filtered by Windows (you can notice the menubar is getting filtered too).

I have to wonder what the hell the 'disable hiDPI scaling' setting is doing that leads to that result, too.


see, that's why I just stopped using hiDPI on my machine despite having a compatible screen-- it's not worth the trouble given how bad Windows is at it. I don't see how the 'disable hiDPI' setting could lead to such a fucking trainwreck, and yet, they did it. Linux was better but still not worth it.


might work on it eventually, but... yeah. making melonDS hiDPI aware would help, but then I'd have to take it into account everywhere. or maybe I can just make libui handle it transparently.


oh well.

____________________
Kuribo64

when giving a polygon a vertex with W=0: it goes through the clipping stage normally

BUT

when that vertex has a negative Y, something weird happens

like

when the segment made of it and the previous vertex is clipped

the new vertex gets a positive Y, when it should be negative

only happens with W=0. as if it were trying to use -W somewhere and it shat itself due to 0 remaining positive, causing something to get the wrong sign


observation on large W values:

W=0x1000000: polygon is 'skipped'. it's still stored in RAM, but it isn't rendered. might be W getting truncated to 24 bits later on and triggering some W=0 safeguard.

W=0x1000001: rendered, but color interpolation is unusual. value is getting truncated in some way before getting to the rasterizer.



it's probably causing overflow somewhere in the viewport transform.

W=0xFFFFFF is normal. W=0x1FFFFFF is fucked. so W is not getting truncated.

larger power-of-two values result in nothing showing up, too.

0x7FFFFFFF fucks up even more. causes bogus clipping (extra vertices stored).

0x80000001 is clipped/culled out (nothing stored).

0x2000001 to 0x40000001 are same as 0x1000001. coordinates are fine.

____________________
Kuribo64

DMA TIMING


measurements are to be taken with a rock of NaCl. overhead w/ setting up timer/DMA/etc seems variable. timing is unreliable despite disabling cache and IRQ.


oh well.


memory / cycles32 / cycles16

mainRAM -> mainRAM / 18 / 16
mainRAM -> VRAM / 3 / 2
mainRAM -> VRAM unmapped(?) / 2 / 2
VRAM -> mainRAM / 4 / 2
pal -> mainRAM / 4 / 2
OAM -> mainRAM / 3 / 2
mainRAM -> OAM / 2 / 2
VRAM -> VRAM / 3 / 2
BIOS -> mainRAM / 3 / 2
mainRAM -> BIOS / 2 / 2 (does it detect that can't be written to??)
NULL -> mainRAM / 3 / 2 (this DMA does run)
0E000000 -> mainRAM / 3 / 2
0F000000 -> mainRAM / 3 / 2
mainRAM -> NULL / 2 / 2 (does run)
mainRAM -> 0E000000 / 2 / 2
mainRAM -> 0F000000 / 2 / 2
NULL -> NULL / 2 / 2 (runs)

results aren't very precise tho.

I'm hungry.

pal/VRAM/OAM didn't account for video controllers possibly also reading from it. only one supposed to be working is the sub one, which might still access pal/OAM.


organizing shit a bit


mainRAM -> X

00000000: 2/2
01000000: 2/2
02380000: 18/16
03000000: 2/2 (shared WRAM probably not mapped, has to be checked)
03800000: 2/2
04000000: DS turned off. guess DMAing large chunks of shit there is not so much a good idea.
04200000: 2/2
04800000: 2/2
05000000: 3/2
06000000: 2/2 (unmapped VRAM)
06800000: 3/2 (mapped VRAM)
07000000: 2/2
08000000 thru 0F000000: 2/2
FFFF0000: 2/2
FFFF1000: 2/2

01000000(null) -> X

01000000: 2/2
02380000: 3/2
05000000: 3/2
06800000: 3/2
07000000: 2/2
FFFF0000: 2/2

04000000 -> X

01000000: 2/2
02380000: 3/2
05000000: 3/2
06800000: 3/2
07000000: 2/2
FFFF0000: 2/2
basically same as null.

05000000 -> X

01000000: 3/2
02380000: 4/2
05000000: 5/3
06800000: 4/2
07000000: 3/2
FFFF0000: 3/2

06800000 -> X

01000000: 3/2
02380000: 4/2
05000000: 4/2
06800000: 5/3
07000000: 3/2
FFFF0000: 3/2

07000000 -> X

01000000: 2/2
02380000: 3/2
05000000: 3/2
06800000: 3/2
07000000: 3/3
FFFF0000: 2/2

FFFF0000 -> X

01000000: 2/2
02380000: 3/2
05000000: 3/2
06800000: 3/2
07000000: 2/2
FFFF0000: 2/2 (knows it can't write????)


NOTE ON SAME-REGION DMA PENALTY

06800000->06800000: 5/3
06800000->06810000: 5/3 (within same bank)
06800000->06820000: 4/2 (different banks)
06800000->06840000: 3/2 (unmapped)

penalty applies when the same memory bank is accessed for reading and writing, in general.

side note on VRAM: overlapping banks don't add more waitstates.



sooo. timing rules, barring mainRAM which is a bit special.

16bit

always 2. except when doing sameregion transfer, then it's 3.

32bit

hairy, w/ different bus sizes.

16: VRAM, palette. mainRAM seems to be on a different bus.
32: OAM, BIOS, WRAM...

16->16: 4, 5 when sameregion
16->32: 3
32->16: 3
32->32: 2, 3 when sameregion

mainRAM->X:

16->16: 3
16->32: 2

it has different read timing??


cycle breakdown

16bit: 1 read + 1 write + 1 sameregion-penalty

32bit: 1 read + 1 read-from-16bit-bus-penalty + 1 write + 1 write-to-16bit-bus-penalty + 1 sameregion-penalty

mainRAM:

"In some cases DMA main memory read cycles are reportedly performed simultaneously with DMA write cycles to other memory."

I guess.

16bit: 1 read + 1 write (no optimization then, I guess)

32bit: merge(1 read + 1 write) + 1 read-from-16bit-bus-penalty + 1 write-to-16bit-bus-penalty. I guess.

the stinky case of mainRAM->mainRAM.

18/16. what a motherfucking trainwreck.

16bit: 1 read + 1 write + 1 sameregion penalty + 13 shito.

32bit: 1 read + 1 read-from-16bit-bus-penalty + 1 write + 1 write-to-16bit-bus-penalty + 1 sameregion-penalty + 13 shito.

13 shito = 7 for reading, 6 for writing???? NS penalty. 8 for reading, 5 for writing??? need checking against non-DMA timings.

____________________
Kuribo64

I felt like giving them a heads-up, that's all. There are no plans to merge with DeSmuME or contribute more significantly.

____________________
Kuribo64

wifi is generally unstable, might or might not work. you can try with more recent versions than 0.4.

as for the messages you listed: they're about parts of wifi that need more research. generally not a lot of impact. "wifi: !! unusual TXSLOT_CMD bits set C000" seems to happen when MP exchanges fail and are retried. the retry functionality needs investigation, my attempts so far only made things worse.

____________________
Kuribo64

your dpad might be recognized as a 2-axis joystick, dunno

____________________
Kuribo64

what do you mean by that? in the emulator, those are the up/down/left/right key mappings

____________________
Kuribo64