make sure MAC randomization is enabled

____________________
Kuribo64

it's used by the 'undo state load' feature

____________________
Kuribo64

we could virtually scale to any amount, the only issue with higher resolutions (besides performance) is whether the framebuffers and shit would fit in your GPU's memory

____________________
Kuribo64

it's weird, because the DS itself runs at 60FPS

so, either you want to artificially slow down your game? or it happens to run 'too fast' in melonDS due to a timing issue?

____________________
Kuribo64

command 94

replies with some sort of ID data?

example data from a Jam with the Band cart:

past that it's all zeroes.

the 16 bytes at 0x18 are also found at the beginning of the last 0x800 block in the save memory (which seems to be 8MB). the game checks for them.


command D6

retrieves the NAND status, repeated over and over again.

status values:
20 on init
bit5: NAND ready
bit4: write enable -- set by command 85, NOT cleared by command 84, cleared after a write/erase/etc command

command B2

seek somewhere? takes an address. doesn't seem to have any response.

after a B2 command, B7 reads from the savemem.

sets the 0x20000-byte window in which SRAM read/write is permitted. NAND stays stuck perma-busy if the address is before the start of the SRAM region (ROM header 94/96).

issuing this command while already in SRAM mode fucks shit up.

command 8B

reverts to regular ROM mode (B7 reads from ROM).

command 84

discard writebuffer. a subsequent cmd82 will have no effect.

command 85

write enable. sets bit4 in status register.

only works if SRAM mode (cmd B2) is engaged.

command 82

write disable. clears bit4 in status register.

required to finalize a write after using command 81 to send the data. (data presumably written from some temp buffer to the actual NAND)

write buffer is 0x800 bytes. not filling it enough fucks things up.

last 0x20000 block of the SRAM region is not writable. it's all FF except for the ID data at the beginning of the last 0x800 bytes.

____________________
Kuribo64

FF 01 00 00 04 01 03 0C 00


FF: starter byte presumably

01 00 00 04: header
01 00: command??
00 04: length of payload

01 03 0C 00: payload

____________________
Kuribo64

UPDATE on this matter


the game does something weird during SPI comm:

1. set SPICNT to A040
2. send FF byte
-> cart sends IRQ, which is ignored
3. set SPICNT to 0043
4. small delay
5. set SPICNT to A040
6. send header and payload (SPICNT set to A000 before last byte, as normal)
-> cart sends IRQ at the end of the payload


it's weird because just sending the first byte with SPICNT=A000 does not replicate this

as if normal 'clear hold after last byte' just told the cart to reset SPI comm, and next byte is considered a 'first byte' again

but the weird reset done by setting SPICNT to 0043 somehow behaved different, deselecting the SPI thing but with a different timing? that somehow tells the cart 'but wait, there's more'

prolly that setting stops the BT controller from getting a SPI clock, which it can detect SPI clock is supposed to only work during a transfer

____________________
Kuribo64

CONTENTS OF THE POKETYPE CART

* typical Macronix ROM
* STMicroelectronics M25PE10 SPI FLASH memory, presumably 128K
* Broadcom BCM2070 Bluetooth controller
* 26MHz crystal oscillator

____________________
Kuribo64

what do you mean by that

____________________
Kuribo64

I was explained what that was, at the same time, in IRC


we don't have rollback netcode, and prolly won't for the near future

____________________
Kuribo64

thanks, same to you

____________________
Kuribo64

what do you mean by analog control?

____________________
Kuribo64

it's possible with something like AM64DS. with some extra code in melonDS we might support that too.

____________________
Kuribo64

this screen means that either your NAND is lacking the nocash footer, or your BIOS files aren't augmented. are you using the same that you used with NO$GBA? these should work.

____________________
Kuribo64

BIOS files that work with NO$GBA are already augmented

also, for the NAND, what is the exact size of your file?

____________________
Kuribo64

Posted by NickyFan7

The NAND is 245,761 Kilobytes or 240 MB should it be smaller, larger?

that seems to be the correct size (ie includes nocash footer). what's the exact size in bytes? as it says in the property dialog.

____________________
Kuribo64

Kuruma de DS (UZCJ) also has a BT controller

____________________
Kuribo64