Views: 6,702,768 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-29-24 09:29 AM
Guest:

Main - Posts by Arisotura

Pages: 1 2 3 4 5 6 ... 40 41 42 43 44
Arisotura
Posted on 04-07-17 11:39 AM, in The Compatibility Thread Link | #62
I guess compatibility reports should just not mention emulation speeds. Unless there's an emulation issue causing bad speeds, ie. game runs super slow but emulator says 60FPS.

____________________
Kuribo64

Arisotura
Posted on 04-07-17 02:07 PM, in Building melonDS in Windows with Code:Blocks Link | #65
Telling us more about those errors would be helpful.

____________________
Kuribo64

Arisotura
Posted on 04-07-17 02:15 PM, in Building melonDS in Windows with Code:Blocks Link | #67
I see.


You should get msys2 and use its shell to install mingw64, wxWidgets and SDL2.

____________________
Kuribo64

Arisotura
Posted on 04-08-17 01:02 PM, in Building melonDS in Windows with Code:Blocks Link | #79
You'll need to place the appropriate .dll files along with it. Check the melonDS release for a list of the DLLs it requires.

____________________
Kuribo64

Arisotura
Posted on 04-10-17 04:45 PM, in The melonDS Ideas Thread Link | #85
you can resize the window to that effect

____________________
Kuribo64

Arisotura
Posted on 04-11-17 12:22 AM, in The Compatibility Thread Link | #86
Also, the information should be as objective as possible.


Anyway, it's nice that there aren't that many failing games on 0.1. I'm in the process of fixing shit, most of the broken games are already getting further. Bejeweled seems playable, Cars too (although the first level is boring, so I didn't play much). Scribblenauts is getting further, but it's showing the limits of my cart DMA hack, so see you when that feature is implemented properly, I guess.

As usual, anything 3D is slow, because the renderer is a pile of shit. However, I've got improvements to implement that will make it faster and more accurate.

____________________
Kuribo64

Arisotura
Posted on 04-11-17 08:16 PM, in GBAtek addendum/errata (rev. 30 of 04-09-22 05:41 PM) Link | #87
GBAtek is an amazing piece of documentation, but it can be improved upon :)


This is a general pile of findings. I claim no ownership on those, they come from several individuals.



VRAM

* VRAMCNT registers are readable!!
* TODO: add notes about overlapping VRAM banks and mirroring
* invalid MST values for a VRAM bank result in the bank not being mapped


ROM transfers

* transfer time is 8 cycles for a command, 4 cycles per response word (basically 1 cycle per byte) (see ROMCTRL bit27 for cycle duration)
* plus start delay and 0x200-block delay at the start of each 0x200 block
* bit28 allows skipping incoming bytes automatically during delays
* DELAYS DO NOT APPLY WHEN THE WR BIT IS SET
* DRQ bit (bit23) is set once a response word has been transferred
* reading from 0x04100010 clears the DRQ bit, and:
** if the transfer is finished: clears the busy bit and triggers IRQ if specified
** if there are more words to transfer: begins transferring the next word


2D

* The main memory display FIFO is a simple circular buffer that holds 16 pixels. The video controller reads from it regardless of whether you fill it. It doesn't get 'empty' or 'full'.
* Writing to the upper halfword of 0x04000068 increments the FIFO write pointer by two (writes to the lower halfword leave it unchanged). The write pointer simply wraps to 0 when reaching the end of the buffer. It is also reset upon VBlank.
* 8-bit writes to 0x04000068 don't work well. TODO: figure out what's happening. eventually.

* Colors are converted early from 5-bit to 6-bit, as such: 6bit = 5bit*2
* Color special effects (brightness, blending) are applied to the 6-bit color components
* In some cases, the MSb of color values is used as LSb for the green component. TODO: find out where this applies. Confirmed to apply to the standard BG palette.

* Bitmap sprite blending follows the same rules as non-bitmap semitransparent sprites, with EVA=alpha+1 and EVB=16-EVA. Except: bitmap sprites with alpha=0 are always hidden.

* 3D layer blending follows rules similar to those of semitransparent sprites (only requires second target bits set in BLDCNT, overrides BLDCNT color effect selection and window 'enable color effect' setting where it applies).
* 3D layer blending uses 5-bit alpha values (from the 3D graphics), such as: EVA=alpha+1 and EVB=32-EVA.
* When the 3D alpha is less than 16, the final color components are incremented by one. (seems to be some hardware glitch??)
* 3D layer pixels with alpha=0 are always hidden (not rendered). They're preserved when capturing the 3D output alone, though.

* BG mode 6 works on both GPUs. On the sub GPU, it only gets 128K of VRAM, so it will repeat the same bitmap 4 times.
* BG mode 7 renders (text-mode) BG0, BG1, and sprites. No BG2/BG3.

* large BG sizes 2-3 are the same as corresponding sizes for regular bitmap BGs (512x256, 512x512)


3D

* Shadow polygons can use textures. In that case, decal blending is applied.
* The stencil buffer can hold two scanlines. It's cleared only when the current scanline contains shadow mask polygons, before rendering a group of shadow mask polygons.
* Stencil buffer bits are set only where the shadow mask is drawn but fails the depth test.
* Visible shadow polygons (polyID>0) are only drawn where stencil buffer bits are set and where the destination pixel's polygonID is different from that of the shadow, regardless of whether that pixel was translucent.

* Drawing visible shadow polygons supposedly resets the stencil bits. TODO: check. I guess not.

* Toon highlight mode uses the following formula: (GBAtek is wrong)
v=vertex t=texture s=tooncolor=toontable[Rv]
R = ((Rt+1)*(Rv+1)-1)/64+Rs ;truncated to MAX=63
G = ((Gt+1)*(Rv+1)-1)/64+Gs ;truncated to MAX=63
B = ((Bt+1)*(Rv+1)-1)/64+Bs ;truncated to MAX=63
A = ((At+1)*(Av+1)-1)/64

* Translucent pixels are only drawn where the destination pixel has a different polygonID OR where the destination pixel was opaque.

* for each separate polygon, W values are 'normalized', they're collectively shifted left or right by 4 until they all fit within 16 bits (if they fit within 12 bits or less, they can be shifted left to use the 16-bit range better)

* conversion for Z values:
** Z-buffering: zbuf = (((Z * 0x4000) / W) + 0x3FFF) * 0x200 (using original W)
** W-buffering: zbuf = W (but it appears to use normalized W)

* conversion for clear depth:
** clearZ = (val * 0x200) + 0x1FF

* There are special depth-test rules for polygon borders. TODO: work it out.
** it seems to only apply to wireframe polygons
** when Z values are equal, left edges have priority over right edges, and top edges have priority over bottom edges (TODO: check wireframe vs normal)
** 'less or equal' depth test has no margin
** (dunno about other orders but they should use the regular rules. Y-sorting gets in the way)

* Cases where 'less than' depth test becomes 'less or equal':
** wireframe polygon borders as mentioned above
** apparently, polygon borders in some other cases too
** when rendering frontfacing polygon pixels over existing opaque backfacing polygon pixels

* in W-buffering mode, 'equal' depth test mode has a margin of 0xFF in either direction. That is, for example, incoming Z range of 0x100-0x2FE is considered equal to an existing Z-buffer value of 0x1FF.
* in Z-buffering mode, margins are +-0x200.

* PUSH/POP/STORE/RESTORE to the modelview matrix always apply to the vector matrix too, even in matrix mode 1.
* "NORMAL/VEC_TEST require matrix mode 2" <- wrong. They work the same regardless of the matrix mode.

* edge marking
Posted by GBAtek
Technically, when rendering a polygon, it's edges (ie. the wire-frame region) are flagged as possible-edges (but it's still rendered normally, without using the edge-color). Once when all opaque polygons (*) have been rendered, the edge color is applied to these flagged pixels, under following conditions: At least one of the four surrounding pixels (up, down, left, right) must have different polygon_id than the edge, and, the edge depth must be LESS than the depth of that surrounding pixel (ie. no edges are rendered if the depth is GREATER or EQUAL, even if the polygon_id differs). At the screen borders, edges seem to be rendered in respect to the rear-plane's polygon_id entry (see Port 4000350h).

-> polygon ID rule for screen edges confirmed
-> at screen edges, the aforementioned depth test uses CLEAR_DEPTH (when testing against a pixel that would be offscreen), even when using a clear bitmap

* antialiasing
** seems to be calculated from edge slopes
** topmost two pixels are retained, antialiasing blends them together including alpha (except color isn't blended when the pixel below has alpha=0)
** during rendering, if an incoming pixel fails the depth test with the topmost pixel, it is checked against the pixel below


DMA

* ARM9 DMA start mode 3 is similar to the GBA's 'video capture' DMA, although GBAtek doesn't make it obvious. It is triggered at the start of each scanline from 2 to 193. The enable bit is automatically cleared on scanline 194.
* TODO: find when 'main memory display' DMA starts. Probably 8 pixels (48 cycles) in advance from the actual display. -- DMA starts ~32 cycles after the start of the scanline. Actual display starts ~48 cycles after the start of the scanline.


Sound

* repeat mode 3 behaves same as mode 1 (loops)
* TODO: check to see what can be changed while a channel is playing. Format can be changed and that's a whole fucking pile of things to check.

____________________
Kuribo64

Arisotura
Posted on 04-12-17 12:16 PM, in New rankset! Link | #88
We've got a shiny new rankset courtesy naknow! It's melon-themed and pretty cool, check it out :)

____________________
Kuribo64

Arisotura
Posted on 04-12-17 11:02 PM, in melonDS 0.2, coming soon Link | #89
A sneak peek of this new version of melonDS.




You'll have to bear with French game screenshots for a while, atleast until I implement firmware saving I guess :P


Anyway, for this version, I've been fixing shit. Most of the games that didn't boot, now atleast get somewhere. Noting that there are still a few problems I'm trying to fix:

* Pokémon White only runs when booting from the firmware
* firmware boot is unstable
* Rayman RR2 sometimes gets its backgrounds cut in half -- linked to above problem, DMA start timing related

Other things worth mentioning are that it's got preliminary audio support, and enough wifi functionality so that games don't hang when trying to use it. (it doesn't connect. don't ask.)


Anything else you'd absolutely want to see in this version?

____________________
Kuribo64

Arisotura
Posted on 04-12-17 11:24 PM, in melonDS 0.2, coming soon Link | #91
Savestates would be something I'd work on once the thing is a bit more mature tbh.

____________________
Kuribo64

Arisotura
Posted on 04-20-17 03:11 PM, in Reporting issues Link | #97
Issues can be reported on the Github issue tracker or on this board.


Just be sure to follow these few guidelines:


When you think you've found an issue, compare to the real hardware (unless it is something blatantly malfunctioning). I just want to avoid wasting time chasing non-issues, like game bugs that occur on the DS or malfunctions caused by a bad ROM.

It is also possible to compare against other emulators, but do not assume they will produce correct results.


Include as much information as possible in your reports.

____________________
Kuribo64

Arisotura
Posted on 04-21-17 10:30 PM, in (because every board needs one) The introductions thread Link | #101
Well, welcome aboard! :D

____________________
Kuribo64

Arisotura
Posted on 04-23-17 03:11 AM, in Aging cart tests Link | #104
Reference listing of the aging cart tests.

The table is at 0x021F2FD0 and has 114 entries, which is more than the 75 mentioned in the interface.

02010FF4 | ATTEST (dummy)
0200CC0C | VRAM
0200CA80 | TEST MAIN EX MEMORY
02013218 | VRAM-2
020131C4 | ITCM
02013170 | DTCM
0201311C | MAIN MEMORY
02004710 | TIMER TIMER0
02004540 | TIMER CONNECT
02004300 | TIMER INTERRUPT
0200409C | TIMER PRESCALER
02014E48 | DMA INTREQ FLAG
02015018 | DMA PRIORITY
02016548 | DMA ADDRESS CTRL
02016290 | DMA VBLANK START
02015FEC | DMA HBLANK START
02015DD0 | DMA DISP START
020170A8 | CAPTURE CONTROL
02016A70 | CAPTURE BLENDING
02007ECC | ACCELERATOR DIV
02007A88 | ACCELERATOR SQRT
02021E30 | 3D ATTR FARCLIP
0201B8B0 | 3D BOX TEST
02020AD8 | 3D ALPHA TEST
02029D10 | 3D ATTR DEPTH UPDATE
0202357C | 3D ATTR DEPTH TEST
02022B14 | 3D CLEAR IMAGE
0201AEF8 | 3D EDGE MARKING
0201A218 | 3D FOG
0202A8C0 | 3D LIGHT COLOR
0202BFFC | 3D LIGHTING
02021588 | 3D SHININESS
0201E4C0 | 3D ONE POLYGON
0201FA30 | 3D ANTIALIAS
0202527C | 3D SHADOW POLYGON
02018EE4 | 3D TEX COORDINATES
0202698C | 3D WIRE FRAME
0201ED90 | 3D ATTR 1DOPOLYGON
02028910 | 3D TEX DECAL
020294D4 | 3D TEX ENVMAPPING
020198E0 | 3D TEX SRT
0201CEB4 | 3D VERTEX COORD 1
0201D5F8 | 3D VERTEX COORD 2
0201DD3C | 3D VERTEX COORD 3
02027FFC | 3D TEX ALPHA
02023E7C | 3D TEX VERTEX SOURCE
02027440 | 3D TRANSLUCENT
020246E0 | 3D VIEW PORT
0201C31C | 3D TEX FORMAT
020202CC | 3D TOON/HIGHLIGHT
0202D3AC | 3D DEMO NITRO MODEL
0202B654 | 3D FUNCTION OF 2D
0202F2C4 | 2D(MAIN) VRAM
0202F298 | 2D(MAIN) MAINMEM
0202F26C | 2D(MAIN) BGMODE0-0
0202F240 | 2D(MAIN) BGMODE0-1
0202F214 | 2D(MAIN) BGMODE0-2
0202F1E8 | 2D(MAIN) BGMODE1-0
0202F1BC | 2D(MAIN) BGMODE1-1
0202F190 | 2D(MAIN) BGMODE2-0
0202F164 | 2D(MAIN) BGMODE3-0
0202F138 | 2D(MAIN) BGMODE4-0
0202F10C | 2D(MAIN) BGMODE5-0
0202F0E0 | 2D(MAIN) BGMODE6-0
0202F0A4 | 2D(SUB) BGMODE0-0
0202F068 | 2D(SUB) BGMODE0-1
0202F02C | 2D(SUB) BGMODE0-2
0202EFF0 | 2D(SUB) BGMODE1-0
0202EFB4 | 2D(SUB) BGMODE1-1
0202EF78 | 2D(SUB) BGMODE2-0
0202EF3C | 2D(SUB) BGMODE3-0
0202EF00 | 2D(SUB) BGMODE4-0
0202EEC4 | 2D(SUB) BGMODE5-0
0200A560 | RTC REGISTER
0200A178 | RTC INTERRUPT
0200A394 | RTC RESET
0200A0A8 | RTC OUTPUT 32K
0200A040 | RTC STORE CORRECTION
02007704 | PLAY COIN
0200773C | PLAY BGM
02007720 | STOP BGM
020076D8 | PLAY SIN LR
020076AC | PLAY SIN L
02007680 | PLAY SIN R
02008BE8 | KEY
02012514 | DETECT FOLD
020098B0 | TOUCH PANEL
020098C0 | TP CALIBRATION
020097C8 | TP INTERFACE
02000D24 | LCD UNIT CHECK
02001034 | ADJUST FLICKER
02000B04 | LCD UNIT CHECK
02000AD8 | LCD ENABLE
02000AAC | LCD DESABLE
0200EEA0 | PMIC LIGHT BL1
0200EE78 | PMIC LIGHT OUT BL1
0200EE50 | PMIC LIGHT BL2
0200EE28 | PMIC LIGHT OUT BL2
0200EDF8 | PMIC BLINK LED
0200EDD0 | PMIC LIGHT LED
0200EDA0 | PMIC BLINK QUICK LED
0200ED7C | PMIC POWER OFF
0200ECFC | PMIC WRITE ALL REG
0200F4A4 | MIC SAMPLING 8BIT
0200F360 | MIC SAMPLING 12BIT
0200EC20 | IPL2 SET LANGUAGE CODE
0200D12C | CARTRIDGE ROM
0200CFF4 | CARTRIDGE SRAM
0200B058 | INTERRUPT
020122E8 | EEPROM ACCESS
02011184 | PHI SET CONTROL
02011130 | PHI STOP CONTROL
0200D6D8 | REFRESH
0200D6BC | GET VERSION

Gives you a rough idea of what to expect. Those are the test names and their corresponding test functions.

The graphics tests verify correctness by capturing and checksumming the output. The 3D tests do it too, so you pretty much need pixel-perfect 3D rendering to pass those.

____________________
Kuribo64

Arisotura
Posted on 04-24-17 01:37 AM, in melonDS 0.2 -- breaking the silence! (rev. 2 of 04-24-17 01:42 AM) Link | #105
There it is! melonDS 0.2 is out, with sound output and various other improvements. Here's the exact changelog:


• preliminary sound
• various compatibility improvements and fixes
• various little speedups too
• cart transfer delays emulated
• RTC uses system time
• wifi stub -- games requiring wifi functionality shouldn't hang anymore
• 2D: windows
• 2D: various fixes to display capture
• 3D: toon/highlight shading, shadows, polygonID
• 3D: box test, pos test, vec test


pile of copypasta

[image] [image] [image]

How to use

melonDS requires BIOS/firmware dumps from a DS. You can dump them with the following dumper.

The files must be placed in the same directory as the melonDS executable, as follows:

* bios7.bin -- ARM7 BIOS, 16KB
* bios9.bin -- ARM9 BIOS, 4KB
* firmware.bin -- firmware, 256KB or 512KB

Note: the DS-mode firmware in the 3DS isn't bootable. It only contains the bare minimum required to run DS games. Be sure to enable direct game boot when using a firmware dump from a 3DS.

Settings

Emulation: settings related to emulation. For now it lets you enable direct game boot (directly runs the game instead of going through the firmware).

Input: allows you to configure keyboard and joystick input. You can change a mapping by clicking the corresponding entry, then pressing a keyboard key or joystick button. For now, joystick input uses the first joystick available if multiple joysticks are plugged.


Downloads

* Windows 64-bit
* Linux 64-bit


Have fun! :D

____________________
Kuribo64

Arisotura
Posted on 04-25-17 01:38 AM, in Sneak peeks of melonDS 0.3 (rev. 2 of 04-25-17 01:40 AM) Link | #107
Let's start with a couple screenshots of the latest fixes.

(note: I haven't changed the version number in the title bar yet -- the game doesn't work in the 0.2 release)



The game is Tongari Boushi to Oshare na Mahou Tsukai, and at the time of writing this, melonDS is the only emulator that can run it.

It has an antipiracy system that checks how long ROM transfers take, similarly to some Pokémon games.


Sooo... melonDS is still far from being accurate, but I guess it's not too bad :)

____________________
Kuribo64

Arisotura
Posted on 04-25-17 07:19 PM, in The melonDS Ideas Thread Link | #117
as a side note, Emulation->Run with no game loaded will run the BIOS

____________________
Kuribo64

Arisotura
Posted on 04-27-17 02:50 PM, in (because every board needs one) The introductions thread Link | #122
you can go to his profile and block his layout, that does the job.

____________________
Kuribo64

Arisotura
Posted on 04-28-17 03:46 PM, in melonDS errata (rev. 4 of 07-15-17 05:51 PM) Link | #126
Keeping track of little things that eventually need fixed in melonDS.


* ARM: several opcodes should be ARM9-only


* Cart hardware: can only be accessed from one CPU at a time, set in EXMEMCNT. Enforced loosely in melonDS, some places don't check EXMEMCNT.

* also the bus can only be used for ROM OR for save memory, not both (set in AUXSPICNT). Enforced loosely or not at all.


* Things that still happen magically instantly:
** SPI transfers (both firmware/TSC/powerman and save memory)
** hardware division/sqrt

** maybe other meaningless things

____________________
Kuribo64

Arisotura
Posted on 04-28-17 07:09 PM, in melonDS 0.2 -- breaking the silence! (rev. 2 of 04-28-17 07:09 PM) Link | #128
you need the BIOS and firmware files: bios7.bin, bios9.bin, firmware.bin


also medusa is another project but it's not a race, no :P

____________________
Kuribo64

Arisotura
Posted on 05-01-17 04:49 PM, in Questions about "unknown ARM9/ARM7/CP15 read/write" Link | #136
they're known and generally nothing to worry about. they may help me figure out why something isn't working, but most times they're unimportant.

____________________
Kuribo64
Pages: 1 2 3 4 5 6 ... 40 41 42 43 44

Main - Posts by Arisotura

Page rendered in 0.189 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 109/109, time: 0.019 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.