[HILO OFICIAL] Nintendo 64

SuperPadLand escribió:Evidentemente la consola Japonesa no le entran los cartuchos PAL y viceversa así que es algo a tener en cuenta si vas a comprar juegos o modificar la carcasa de la consola para que entren todos (es romper unos plasticos). El tema de los hz los dicta el juego, es decir si usas un juego PAL irá a 50hz y si es NTSC irá a 60hz sin importar de donde sea tu consola. Si usas flashcard no tienes que romper nada e irá a los hz de la ROM que lances.

SuperPadLand escribió:@RiGaL se me fue la pinza con Megadrive creo La N64 comprueba la región en el cartucho sí, había unos cartuchos para hacer bypass, pero no iban al 100%. @kamelillo ten esto en cuenta que me equivoqué.

kamelillo escribió:Si no es molestia claro que me gustaria un top de juegos! Aunque más o menos me he estado informando jejej

kamelillo escribió:Pffff vaya catálogo veo ahí! Creo que pillaré primero algo de variedad en géneros y ya luego poco a poco jajaja

Por cierto gente, que tan importante es el expansión pack? Mejora todos los juegos?
Decidme también que tengo que tener en cuenta a la hora de comprar una Nintendo 64, que voy a empezar la caza.

X_Glacius escribió:el Mission Impossible que aunque sea morralla a mí me encanta

coyote-san escribió:@X_Glacius los Pokémon Stadium como se disfrutan de verdad es conectandoles los cartuchos de Game Boy y usar los Pokémon que tienes en ellos, se crearon para eso mismo principalmente.

EMaDeLoC escribió:Acabariamos antes diciendo los juegos malos que no se recomiendan.

Bimmy Lee escribió:@SuperPadLand El problema de Mission Impossible es que acabó siendo víctima de un hype inmenso. Recuerdo verlo en Nintendo Acción en su fase beta y caérseme los huevos al suelo. Luego por desgracia sufrió un downgrade muy bestia (era evidente que "eso" no lo podía mover una N64, pero como soñar no cuesta nada y uno era joven e ingenuo por aquel entonces...) y claro, el desencanto fue mayúsculo.

Se podría decir que fue el Watch Dogs de su generación.

Bimmy Lee escribió:

EMaDeLoC escribió:Acabariamos antes diciendo los juegos malos que no se recomiendan.

Venga, ¿quién es el primero en nombrar al aborto hecho videojuego?

Bimmy Lee escribió:Quest 64/Holy Magic Century se queda un poco en tierra de nadie: no es un desastre pero tampoco una maravilla. Para echar unas partidas rápidas no está mal.

Me recuerda un poco al Mystic Quest Legend de SNES: un RPG para novatos, sin más.

X_Glacius escribió:

Es la segunda parte de:

X_Glacius escribió:¿Qué opináis de los Extreme-G? Yo iba con muchas ganas pero me decepcionaron por el mal framerate, no parece que vayas rápido para nada, o esa fue mi impresión.

SuperPadLand escribió:

X_Glacius escribió:¿Qué opináis de los Extreme-G? Yo iba con muchas ganas pero me decepcionaron por el mal framerate, no parece que vayas rápido para nada, o esa fue mi impresión.

El primero no recuerdo que tuviera mal framerate, el segundo sí me pareció que rascaba ya demasiado para un juego de velocidad, pero aun con todo me parecieron bastante buenos.

Edit hoy he actualizado mi tarjeta SD

@Conker64 intenté probar el alt64 pero debí hacer algo mal porque no me lo detecta y me dice que descargué el firmware normal desde una web. revisaré el próximo finde a ver que hice mal

@mcfly doom 64 hack probado y todo perfecto

SuperPadLand escribió:@X_Glacius hace muchos años cuando lo probé por primera vez se me lanzaba directamente al encender, tuve que haber colocado mal los archivos o la tarjeta SD que puse no la detecta (microSD en adaptador).

@mcfly pues son los que indican en el propio hack, puedes pillar los niveles nuevos del 2020, nuevas opciones, el brillo viene configurado al máximo y aunque hace que luzca menos tétrico, permite apreciar mucho mejor la calidad gráfica, etcétera.

X_Glacius escribió:

SuperPadLand escribió:@X_Glacius hace muchos años cuando lo probé por primera vez se me lanzaba directamente al encender, tuve que haber colocado mal los archivos o la tarjeta SD que puse no la detecta (microSD en adaptador).

@mcfly pues son los que indican en el propio hack, puedes pillar los niveles nuevos del 2020, nuevas opciones, el brillo viene configurado al máximo y aunque hace que luzca menos tétrico, permite apreciar mucho mejor la calidad gráfica, etcétera.

No he podido probarlos pero he encontrado este:

https://github.com/Suprapote/Altra64/releases

y este que en un video lo muestra que funciona desde el arranque:

SuperPadLand escribió:@X_Glacius has probado lo de eliminar las imágenes.png para ver si así la navegación por los menús es más fluida?

Lo del DK64 es sumamente raro, miraste en opciones del flashcard que el modo de vídeo esté en Auto o en PAL?

SuperPadLand escribió:@X_Glacius sí, DK64 fue de los últimos anticopias que se superaron para flashcards, pero hace mucho de ello. Cuando yo compré el mío por el 2017 ya eran todos compatibles, si puedo miro a ver si la NTSC me hace lo mismo que a ti, de todas formas mira a ver si en romhacking tiene algo para quitar la protección (que por otro lado una protección debería no dejar jugar, no jugar achatado).

@ruyner expansión pak no hay nada, el que lo invente va a hacer unos buenos euros.

Mandos originales nuevos no hay, puedes encontrar alguno a la venta, pero no como ir al Carrefour y pillarte un dualshock 4 o 5. De terceros tienes bastantes a calidades decentes, el problema de todos ellos es que el stick es más sensible que el original (en unos más que otros) y como última opción puedes pillarte el oficial de Nintendo para Switch y hacerle un adaptador bluetooth para usarlo en N64 esta última opción es la que más está gustando últimamente.

Los mandos de terceros, yo tengo el de retrobit.

.: Nintendo 64 Test Cart version 1.? :.

Finally, a public release of both complete ROMs from a Nintendo 64 test cart!
Wait, both!?

Test carts were designed to be reprogrammed–in full or in part–through the jtag port or via gangwriter. When there’s any kind of electrical delay whatsoever it seems to map the “testcart_reflash” ROM, allowing you to pipe a new “testcart_runtime” to it. (Check the “reflash interface.txt” doc for more info on how that works.)
That’s rather been the problem up to this point, but it turns out if you stick a bit of polyimide tape over the cart’s CIC pins you can boot to a 64DD while it still maps the main runtime (assuming yours has a CIC+IPL or you programmed your own). Having the code you want exposed means you can just DMA everything instead of trying to read from the exposed flash addresses; there’s a bit of a trick to doing that with 16bit hardware.
This dump was taken via a 64DD dev unit while the runtime was accessible. It was checked against a second dump taken via IO access (doubled-reads, similar to the writing method), and both were compared against an earlier partial dump to verify known good contents. You could also read the individual flash units themselves if your IC programmer supports the chipset / has the right adapter.

Please note that the runtime is not supposed to be some perfect multiple of a chip size. If you have ever had the “privilege” of using jtag you’d understand why. The reflasher is aligned to the start of the last unit (each unit being 0x200000 large) and retains its padding (in other words, the unwritten bytes erased to 0xFF at the end). That file has a maximum size in other words, so that feels like an important thing to preserve.

.: Why version 1.? :.
The specific build is up for debate. It is clearly *not* version 1.0. It’s suspected to be at least a version 1.1–likely final–based on the audio test.
There are two existing blobs of source code for the Go/No Go tool (GnG, used for factory quality control): one from the OMAN archive and another distributed with libultra OS2.0E. Both predate this release (built against OS2.0H). The most noticeable–arguably only–difference from 2.0E is that the left/right audio test stopped using beeps and midi sequences, replacing them with a voice saying “This is your * channel.” It also doesn’t use the “subway” sequence. It’s not clear what version was first used for these standalone cartridges.
(So yes, there’s at least one other version that needs to be tracked down and dumped.)

For those in the know, a partial dump of the main runtime was taken by marshallh back on Jun 29, 2016. That was done by sniffing the address lines and was largely complete, lacking only data that wasn’t accessed (as opposed to used). It’s been available to emulator devs since then, awaiting a complete dump before public release. It’s the same build as this one or very, very close.
It was missing:
*) The tail end of all audio samples. They’re clipped by the player before running to completion so the ends weren’t loaded. (Samples are only loaded on-demand in blocks.) One did have a short non-matching segment, could be a smidgen of corruption or maybe it was leveling or something applied to a single spot.
*) Sequences for noteLeft, noteRight, and subway (plays G, then E). LR were replaced by more explicit “This is your * channel.” messages from version 1.1 onward, but the original beeps & sequences are still compiled in.
*) The number sequence used for the PI test. This is only run (or relevant) when a zaru test rig is attached, not when booted standalone (unless you run it manually via command line).

.: About Zaru :.
Also provided is a short, hopefully accurate, document on how the zaru rig should operate. You could theoretically build one and stick it in a controller slot (like a mempak) to pointlessly check all your grounds. Many of the tests only run with a zaru or run alternate code when one is found.

.: Does It Emulate? :.
If it doesn’t, complain to your emulator’s devs.
There isn’t much point to emulating it other than to confirm accuracy or complaining about the lack of it. The central focus is usually on passing the RCP tests, but you’d be surprised how few emulators support the Recenter button (the Start in L+R+Start toggles 0080, not 1000) or how many neglect the VI entirely, directly outputting the framebuffer (the wiggly triangle video test uses VI settings to clip a window out of the framebuffer and scale it, otherwise you’ll see a triangle bouncing inside a box). Or how many aren’t unicode-aware. (Did they just copy some old PJ64 source or something? Is it that hard to use strncpy(20) and decode instead of hoping a raw bytes “filename” doesn’t throw an error?)

It works fine on flashcarts, but then the test cartridge *is* a flashcart so that’s no surprise. Might be useful if you did a console mod and need to know how bad your solder job really was.

Note it’s *supposed* to display garbage for ~15 seconds, then differently colored garbage about as long before ultimately loading the interface. There’s an initial bootloader in the 80200000 range that first runs some very basic tests–like confirming RDRAM is available & works by running through its setup and some r/w tests–before loading the actual interface code to the 80000000 range, faking a reset (except with zaru where the reset is quite real), then going through the entire initialization routine again and finally setting up some video. Don’t be surprised that it has two sets of basic lib functions. You can sidestep that–and need to if you’re using an iQue–but you’re also avoiding some of the lowest level tests.
It runs some tests a bit differently if 4MB, 6MB, or 8MB of RDRAM are detected. If you don’t think 6MB was ever a thing, try asking around about 64DD support in Ocarina of Time ;*)

The reflasher is relatively pointless to run without a real unit. It was incredibly helpful to learn how to talk to the flash properly and understand the IO limitations; the dumper(s) wouldn’t have been possible without it.

.: Checksums :.
“testcart_reflash.n64”
internal 318B3640 72EC843F
md5 2E61A0218EB2407336104EAC28431E44
sha512 1A5BE7A343C91E8D36EFE0EEB49A2059887DCB229F7EE8260AA746678E2B8FE9E5D349CC6913DBA7098F20E4A7FF0FAC3C50FED72DDAB8CAD28E2B211EA9EEDF

“testcart_runtime_v2.n64”
internal BDFEF553 94A42EF9
md5 B991B1BF574A73E1D8AC5081B96D5D2D
sha512 2BC1B969FCE9548FCC41B9160680E9F14F6B3A7C3C2257DCC36A076DFC1FDDFE81E9264657CB6A8FAF4E70BB3F6D20AC6377060604902837534B2C7AF40B555D

.: Thanks :.
Many thanks to the anonymous donor that lent one of these! Praise be to Anon!

-Zoinkity

SuperPadLand escribió:@X_Glacius sí, DK64 fue de los últimos anticopias que se superaron para flashcards, pero hace mucho de ello. Cuando yo compré el mío por el 2017 ya eran todos compatibles, si puedo miro a ver si la NTSC me hace lo mismo que a ti, de todas formas mira a ver si en romhacking tiene algo para quitar la protección (que por otro lado una protección debería no dejar jugar, no jugar achatado).

@ruyner expansión pak no hay nada, el que lo invente va a hacer unos buenos euros.

Mandos originales nuevos no hay, puedes encontrar alguno a la venta, pero no como ir al Carrefour y pillarte un dualshock 4 o 5. De terceros tienes bastantes a calidades decentes, el problema de todos ellos es que el stick es más sensible que el original (en unos más que otros) y como última opción puedes pillarte el oficial de Nintendo para Switch y hacerle un adaptador bluetooth para usarlo en N64 esta última opción es la que más está gustando últimamente.

Los mandos de terceros, yo tengo el de retrobit.

X_Glacius escribió:A ver si alguien me puede aclarar qué está pasando, probando Donkey Kong 64 USA tengo barras negras arriba, abajo y a los lados, pero con la versión PAL lo veo en perfecta pantalla completa. ¿Sabéis por qué puede ser? Gracias!