|
| Home | Downloads | Screenshots | Forums | Source code | RSS | Donate |
| Register | Log in |
| < melonDS 0.4 -- It's here, finally!Slowdown > |
|
Why there is no 32-bit build of melonDS Jul 25th 2017, by Arisotura |
|
The main reason is that I don't have an incentive to provide 32-bit builds. Most people already have 64-bit OSes. That being said, melonDS can currently run on 32-bit platforms. It may be less performant, as the 3D renderer does a lot of 64-bit math, but it is still possible. But if I ever decide to implement a JIT, for example, there will be no 32-bit version of it. If you're stuck on a 32-bit OS for hardware reasons, your computer will not be fast enough to run melonDS at playable speeds. melonDS will be optimized, it will run faster, but it will also tend towards more accuracy. So I can't tell how fast it will be in the end. But I highly doubt it will run well on a PC from 2004. Maybe it will, if a JIT is made, but that's not a high priority task. If you are stuck on such hardware, NO$GBA is a better choice for you. Or NeonDS if you don't mind lacking sound. Or hell, the commonly mentioned method of running DraStic in an Android emulator -- those who bash DeSmuME at every turn claim it's fast. Truth is, emulating the DS is not a walk in the park. People tend to assume it should be easy to emulate fast because the main CPU is clocked at a measly 66MHz. Let's see: There are two CPUs. ARM9 and ARM7, 66MHz and 33MHz respectively. Which means you need to keep them more or less in sync. Each time you stop emulating one CPU to go emulate the other (or to emulate any other hardware) impacts performance negatively, but synchronizing too loosely (not enough) can cause games to break. So you need to find the right compromise. The ARM7 generally handles tasks like audio playback, low-level wifi access, and accessing some other peripherals (power management, firmware FLASH...). All commercial games use the same ARM7 program, because Nintendo never provided another one or allowed game devs to write their own. This means that in theory the ARM7 could be emulated in HLE. In practice, this has never been attempted, unless DraStic happens to do it. It's also worth noting that it would be incompatible with homebrew, since they don't use Nintendo's ARM7 program. If it is possible to get ARM7 timings reasonably accurate without too much effort, the ARM9 is another deal. It is clocked at 66MHz, but the bus speed is 33MHz, so the CPU needs to adjust to that when accessing external memory. Accesses to main RAM are slow, moreso than on the ARM7, due to what appears to be bad hardware design. But the ARM9 has caches which can attenuate the problem (provided the program is built right). When the caches are used, timings can vary dramatically between cache hits and cache misses. So emulating ARM9 timings is a choice between two unappealing options: 1) emulating the whole memory protection unit and caches, or 2) staying grossly inaccurate. I went with the second option with melonDS, but I'm considering attempting MPU/cache emulation to see how much it would affect performance. Noting that RaymanDS is an example of timing-sensitive game: when timings are bad enough, it will start doing weird things. Effects get worse as timings are worse, and can range from text letters occasionally jumping out of place to travellings going haywire. I have observed polygons jumping out in melonDS, so the timings aren't good enough for this game. And then you have all sorts of hardware attached to the CPUs. Timers, DMA channels, or the video hardware-- oldschool 2D tile engines and a primitive, quirky custom 3D GPU. The 2D GPUs need to be emulated atleast once per scanline as games can do scanline effects by changing registers midframe (it is less common than on the SNES for example, but it's still a thing). The 3D GPU is another deal: geometry is submitted to it by feeding commands to a FIFO. You need to take care of running commands often enough to avoid the FIFO getting full, especially as games often use DMA to fill it. Oh by the way, the 2D GPUs are actually pretty complex, supporting a variety of BG modes and sizes, multiple ways to access graphics for sprites, and so on. The 3D GPU isn't any better, I think we have already established that it's a pile of quirks. So yeah, with the sheer amount of hardware that must be emulated, the DS isn't a piece of cake. |
| 28 comments have been posted. |
| < melonDS 0.4 -- It's here, finally!Slowdown > |
| Pages:12 |
|
aaron says: Jun 3rd 2021 |
| iiiiiiiiiiiiiii nnnnneeeeeeeeeeeeeeeeeeeeeeeedddddddddddddddd help i want create a mario kart ds rom hack and the best emulator to test the custom tracks is melon ds pleaseeeeeeeeeeeeeee make 32 bits version please |
|
W1nd0w5L1v3M3553ng3r says: Jun 18th 2021 |
|
Translated to Spanish La razón principal es que no tengo ningún incentivo para proporcionar compilaciones de 32 bits. La mayoría de las personas ya tienen sistemas operativos de 64 bits. Dicho esto, melonDS actualmente se puede ejecutar en plataformas de 32 bits. Puede que tenga menos rendimiento, ya que el renderizador 3D hace muchas matemáticas de 64 bits, pero aún es posible. Pero si alguna vez decido implementar un JIT, por ejemplo, no habrá una versión de 32 bits. Si está atascado en un sistema operativo de 32 bits por razones de hardware, su computadora no será lo suficientemente rápida para ejecutar melonDS a velocidades reproducibles . melonDS se optimizará, se ejecutará más rápido, pero también tenderá a una mayor precisión. Así que no puedo decir qué tan rápido será al final. Pero dudo mucho que funcione bien en una PC a partir de 2004. Tal vez lo haga, si se hace un JIT, pero esa no es una tarea de alta prioridad. Si está atascado en dicho hardware, NO $ GBA es una mejor opción para usted. O NeonDS si no le importa que le falte sonido. O demonios, el método comúnmente mencionado para ejecutar DraStic en un emulador de Android: aquellos que golpean a DeSmuME en todo momento afirman que es rápido. La verdad es que emular el DS no es un paseo por el parque. La gente tiende a asumir que debería ser fácil de emular rápido porque la CPU principal tiene una frecuencia de 66 MHz. Veamos: hay dos CPU. ARM9 y ARM7, 66MHz y 33MHz respectivamente. Lo que significa que debe mantenerlos más o menos sincronizados. Cada vez que dejas de emular una CPU para emular la otra (o para emular cualquier otro hardware) impacta negativamente en el rendimiento, pero sincronizar demasiado débilmente (no lo suficiente) puede hacer que los juegos se rompan. Por lo tanto, debe encontrar el compromiso adecuado. El ARM7 generalmente maneja tareas como reproducción de audio, acceso wifi de bajo nivel y acceso a algunos otros periféricos (administración de energía, firmware FLASH ...). Todos los juegos comerciales usan el mismo programa ARM7, porque Nintendo nunca proporcionó otro ni permitió que los desarrolladores de juegos escribieran el suyo. Esto significa que, en teoría, el ARM7 podría emularse en HLE. En la práctica, esto nunca se ha intentado, a menos que DraStic lo haga. También vale la pena señalar que sería incompatible con homebrew, ya que no usan el programa ARM7 de Nintendo. Si es posible obtener tiempos de ARM7 razonablemente precisos sin demasiado esfuerzo, el ARM9 es otro trato. Tiene una frecuencia de 66MHz, pero la velocidad del bus es de 33MHz, por lo que la CPU necesita ajustarse a eso cuando accede a la memoria externa. Los accesos a la RAM principal son lentos, más que en el ARM7, debido a lo que parece ser un mal diseño de hardware. Pero el ARM9 tiene cachés que pueden atenuar el problema (siempre que el programa esté bien construido). Cuando se utilizan los cachés, los tiempos pueden variar drásticamente entre los aciertos y los errores de caché. Por lo tanto, emular los tiempos de ARM9 es una elección entre dos opciones poco atractivas: 1) emular toda la unidad de protección de memoria y las cachés, o 2) permanecer extremadamente inexacto. Elegí la segunda opción con melonDS, pero estoy considerando intentar la emulación de MPU / caché para ver cuánto afectaría el rendimiento. Teniendo en cuenta que RaymanDS es un ejemplo de juego sensible al tiempo: cuando los tiempos son lo suficientemente malos, comenzará a hacer cosas raras. Los efectos empeoran a medida que los tiempos son peores, y pueden variar desde letras de texto que ocasionalmente saltan fuera de lugar hasta viajes que se vuelven locos. He observado polígonos saltando en melonDS, por lo que los tiempos no son lo suficientemente buenos para este juego. Y luego tiene todo tipo de hardware conectado a las CPU. Temporizadores, canales DMA o el hardware de video: motores de mosaico 2D de la vieja escuela y una GPU 3D personalizada primitiva y peculiar. Las GPU 2D deben emularse al menos una vez por línea de escaneo, ya que los juegos pueden hacer efectos de línea de escaneo cambiando los registros en el marco medio (es menos común que en SNES, por ejemplo, pero sigue siendo una cosa). La GPU 3D es otro trato: la geometría se le envía mediante la alimentación de comandos a un FIFO. Debe encargarse de ejecutar los comandos con la frecuencia suficiente para evitar que el FIFO se llene, especialmente porque los juegos a menudo usan DMA para completarlo. Ah, por cierto, las GPU 2D son en realidad bastante complejas, admiten una variedad de modos y tamaños de BG, múltiples formas de acceder a gráficos para sprites, etc. La GPU 3D no es mejor, creo que ya hemos establecido que es un montón de peculiaridades. Así que sí, con la gran cantidad de hardware que se debe emular, la DS no es pan comido. |
|
W1nd0w5L1v3M3553ng3r says: Jun 18th 2021 |
|
Translated to Spanish La razón principal es que no tengo ningún incentivo para proporcionar compilaciones de 32 bits. La mayoría de las personas ya tienen sistemas operativos de 64 bits. Dicho esto, melonDS actualmente se puede ejecutar en plataformas de 32 bits. Puede que tenga menos rendimiento, ya que el renderizador 3D hace muchas matemáticas de 64 bits, pero aún es posible. Pero si alguna vez decido implementar un JIT, por ejemplo, no habrá una versión de 32 bits. Si está atascado en un sistema operativo de 32 bits por razones de hardware, su computadora no será lo suficientemente rápida para ejecutar melonDS a velocidades reproducibles . melonDS se optimizará, se ejecutará más rápido, pero también tenderá a una mayor precisión. Así que no puedo decir qué tan rápido será al final. Pero dudo mucho que funcione bien en una PC a partir de 2004. Tal vez lo haga, si se hace un JIT, pero esa no es una tarea de alta prioridad. Si está atascado en dicho hardware, NO $ GBA es una mejor opción para usted. O NeonDS si no le importa que le falte sonido. O demonios, el método comúnmente mencionado para ejecutar DraStic en un emulador de Android: aquellos que golpean a DeSmuME en todo momento afirman que es rápido. La verdad es que emular el DS no es un paseo por el parque. La gente tiende a asumir que debería ser fácil de emular rápido porque la CPU principal tiene una frecuencia de 66 MHz. Veamos: hay dos CPU. ARM9 y ARM7, 66MHz y 33MHz respectivamente. Lo que significa que debe mantenerlos más o menos sincronizados. Cada vez que dejas de emular una CPU para emular la otra (o para emular cualquier otro hardware) impacta negativamente en el rendimiento, pero sincronizar demasiado débilmente (no lo suficiente) puede hacer que los juegos se rompan. Por lo tanto, debe encontrar el compromiso adecuado. El ARM7 generalmente maneja tareas como reproducción de audio, acceso wifi de bajo nivel y acceso a algunos otros periféricos (administración de energía, firmware FLASH ...). Todos los juegos comerciales usan el mismo programa ARM7, porque Nintendo nunca proporcionó otro ni permitió que los desarrolladores de juegos escribieran el suyo. Esto significa que, en teoría, el ARM7 podría emularse en HLE. En la práctica, esto nunca se ha intentado, a menos que DraStic lo haga. También vale la pena señalar que sería incompatible con homebrew, ya que no usan el programa ARM7 de Nintendo. Si es posible obtener tiempos de ARM7 razonablemente precisos sin demasiado esfuerzo, el ARM9 es otro trato. Tiene una frecuencia de 66MHz, pero la velocidad del bus es de 33MHz, por lo que la CPU necesita ajustarse a eso cuando accede a la memoria externa. Los accesos a la RAM principal son lentos, más que en el ARM7, debido a lo que parece ser un mal diseño de hardware. Pero el ARM9 tiene cachés que pueden atenuar el problema (siempre que el programa esté bien construido). Cuando se utilizan los cachés, los tiempos pueden variar drásticamente entre los aciertos y los errores de caché. Por lo tanto, emular los tiempos de ARM9 es una elección entre dos opciones poco atractivas: 1) emular toda la unidad de protección de memoria y las cachés, o 2) permanecer extremadamente inexacto. Elegí la segunda opción con melonDS, pero estoy considerando intentar la emulación de MPU / caché para ver cuánto afectaría el rendimiento. Teniendo en cuenta que RaymanDS es un ejemplo de juego sensible al tiempo: cuando los tiempos son lo suficientemente malos, comenzará a hacer cosas raras. Los efectos empeoran a medida que los tiempos son peores, y pueden variar desde letras de texto que ocasionalmente saltan fuera de lugar hasta viajes que se vuelven locos. He observado polígonos saltando en melonDS, por lo que los tiempos no son lo suficientemente buenos para este juego. Y luego tiene todo tipo de hardware conectado a las CPU. Temporizadores, canales DMA o el hardware de video: motores de mosaico 2D de la vieja escuela y una GPU 3D personalizada primitiva y peculiar. Las GPU 2D deben emularse al menos una vez por línea de escaneo, ya que los juegos pueden hacer efectos de línea de escaneo cambiando los registros en el marco medio (es menos común que en SNES, por ejemplo, pero sigue siendo una cosa). La GPU 3D es otro trato: la geometría se le envía mediante la alimentación de comandos a un FIFO. Debe encargarse de ejecutar los comandos con la frecuencia suficiente para evitar que el FIFO se llene, especialmente porque los juegos a menudo usan DMA para completarlo. Ah, por cierto, las GPU 2D son en realidad bastante complejas, admiten una variedad de modos y tamaños de BG, múltiples formas de acceder a gráficos para sprites, etc. La GPU 3D no es mejor, creo que ya hemos establecido que es un montón de peculiaridades. Así que sí, con la gran cantidad de hardware que se debe emular, la DS no es pan comido. |
|
animoizzz says: Jun 29th 2021 |
| can you make a 32 bit version |
|
n64 says: Jul 31st 2021 |
| just move to 64 bit already, only things that still use 32-bit are older phones. |
|
Fernando Rotela says: Aug 25th 2021 |
| Bro como que los 32 bits estan descontinuados, claro este sistema le falta poco para dejar de funcionar pero aun sigue siendo uno de los mas importantes y muchos lo usan :/ |
|
brianyt02 says: Sep 13th 2021 |
| porfa saquen una version de 32 bist |
|
cac4 says: Sep 21st 2021 |
|
saquen version para 32 bits serian los mejores si lo hacen |
|
Dego Ds says: Dec 18th 2021 |
| de donde salio eso de que 64 bits tiene mas mayoria de uso que el 32 .bueno la verdad ya no importa :C por lo menos agradezco tu honestidad al decir que no te da la gana de hacerlo y ya. gracias |
|
Dego DS says: Dec 18th 2021 |
| el unico emulador con multiplayer lan y requiere de tantos recursos que patetico final :,c |
|
jose lkl says: Mar 12th 2022 |
|
nececito el link de 32 bits |
|
Latam Bot says: Jul 16th 2023 |
| Entonces, si yo tengo una pc Win 10, pero es 32 bits, significa que no puedo emular el MelonDs, ¿Verdad? |
|
Buddy Holly says: Sep 16th 2023 |
| What's with all these comments in spanish? |
| Pages:12 |