Flashcard para Nintendo 64

Ya Neoflash fabricó un cartucho flash de N64, casero imagino que será más complicado.

solbadguy0308 escribió:Ya Neoflash fabricó un cartucho flash de N64.

Y es una chufa...
¿Tanto costaria una targeta Flash del rollo NDS para N64?

chachin2007 escribió:

solbadguy0308 escribió:Ya Neoflash fabricó un cartucho flash de N64.

Y es una chufa...
¿Tanto costaria una targeta Flash del rollo NDS para N64?

Para eso tienes la iQue.

A una N64 no se le puede poner una SD y ya, porque una SD es demasiado lenta para estos quehaceres. Además, se necesitaría pasar de serie (SPI) a paralelo, a una velocidad que un Microchip no puede alcanzar, por lo que habría que meterse con CPLD o FPGA...

Optar por un CF con unos cuantos circuitos lógicos, yo realmente creo que es la mejor opción, ya que ambos son paralelos, la CF es lo más rápido que hay hoy en día, por lo que no se necesita ningún tipo de interface ni conversión.

SD/CF + FLASH/RAM + FPGA/CPLD + CIC creo que es la solucion.

Si usamos una CF, no hace falta una RAM ni un FPGA ya que es capaz de funcionar a la velocidad requerida.

Además, el protocolo de la CF, es igual que el de la GBA, y el de la GBA es muy similar al de la N64... ¿sabéis por donde voy, no?

Tal vez lo podamos hacer con pocos componentes...

Pues no se por donde vas... Reusar un flashcard de GBA?

No he acabado de entender eso de no usar FAT que has dicho al principio, por lo que a lo mejor lo que voy a decir es lo que querías comentar. El problema de usar FAT/FAT32/(o lo que sea) es que el tiempo de acceso no es lineal, sino que tienes que recorrer un número variable de estructuras, además por la misma razón el tiempo de acceso se deteriora rápidamente. Para evitar eso se suele usar una memoria intermedia en formato crudo.

Seguramente lo que querías decir es no usar ningún formato, sino ponerlo en crudo directamente en la CF. Podría funcionar, se tendría que mirar si es lo suficiente veloz y si se pueden obtener los x bytes necesarios de una sola 'llamada' (por ejemplo en las SD se leen y se escriben bloques). Por otra parte se tendría que crear un programa en PC que le diese formato y, por supuesto, generar un 'formato' propio. Existen todo tipo de velocidades en las CF, así que unas podrían funcionar, otras no...

Coincido contigo que la RAM/Flash es algo a evitar si es posible, para evitar cargas.

Respecto a FPGA: si quieres hacer un flashcard genérico (para muchos formatos de cartuchos) dudo que puedas escaparte de ello, y mas en el caso de la N64 que, por lo poco que se, es una especie de canal serie con timings variables de por medio. A ver, poder se podría, pero creo que seria mucho más trabajoso y se usaría bastante material.

No había caído... El EZ-Flash IV de GBA o el EZ-Flash 3in1 para DS creo que son una buena opción.

Por una parte, el EZ4, lleva soporte para SD incluso en modo GBA, en el cual se copia a una PSRAM (Pseudo Static Random Access Memory) antes de ser lanzado.

Sobre el EZ 3in1, más de los mismo, salvo que los que saben de este dispositivo podrían hacer un Homebrew para DS para poder cargarlos directamente desde la DS, y luego conectarlo a la N64 mediante un adaptador, similar al N64 Myth

Otros como los que llevan memoria interna (EZ1, EZ2, EZ3) también pueden ser una buena opción, ya que van desde los 128 megabits del que tengo yo a los 1024 megabits, incluyendo una pila interna con la cual se pueden simular EEPROM serial y paralela, SRAM y FLASH serial

En cuanto a la CF, usa memoria FLASH NOR, en la cual NO se leen por bloques, aun que sí se escribe por bloques.

Pues no será por que no hay posibilidades

ojala tu proyecto llegue a buen puerto estAre pendiente de todos tus avances y si lo llegas a conseguir aqui tienes uno que le interesaria uno

Creo que tendrian que ser muy, muy parcidos los disenos de GBA y N64 para que valiese la pena intentarlo por esta via. Suerte!!

He encontrado esto:

En los foros de BenHeck
Tiene 16 líneas de datos/direcciones. Primero se carga la dirección superior (si la dirección es p.e.: $6899, se envía el $68), luego se carga la inferior (si es $6899, se envía $99), y luego se puede leer los datos mandando bajo la línea de READ, pudíendose leer hasta 512 bytes hasta tener que volver a mandar la dirección.

El de la GBA, tiene 24 líneas de datos/direcciones. De estas, las 8 líneas superiores (16 a 23) son sólo para dirección, y los 16 inferiores (0 a 15) están multiplexados. Se envía por los 24 pines la dirección, se lleva el READ bajo y entonces salen los datos. Al igual que el de N64, se pueden leer datos sin necesidad de volver a mandar la dirección, pero éste no tiene el límite de los 512 bytes.

Estoy ahora mismo trabajando en un adaptador con un CAD electrónico...

Sigue adelante, no te desanimes! DA gusto realmente ver personas q toman la iniciativa en este tipod e proyectos, si tuviera conocimientos de electronica (Estudio medicina ) ya habria hecho varias de estas cosas (Espero estudies esquema de cartuchos de SNES y quiza AES) sin pagar los desorbitados precios a los q suelen vender estos flash, q emocion investigar y testear unos mismo, echale pa lante!

Saludos

Finalmente, en lugar de CADs para PC, me he decidido por la técnica de toda la vida:

Esto es lo que me dedico a hacer en las aburridas clases de 3º de la ESO

Sólo se necesitan dos ICs: un 74HC573, que es un buffer (o latch, como prefiráis llamarlo), y un chip de la familia de los 74... que sean dos o más puertas NAND.

El funcionamiento es el siguiente:

1. La N64 pone en el bus los 16 bits superiores de la dirección
2. La N64 pone en alto ALE_H y ALE_L
3. Como el cartucho de la GBA usa direccionamiento de 24 bits y no de 32 como este, solo vamos a guardar los 8 bits inferiores de los 16 bits que se encuentran en el bus en el chip 74HC573, que es un búffer o latch
4. El ALE_H se pone bajo, y la N64 pone los 16 bits inferiores de la dirección
5. Las puertas NAND comprueban si ALE_L está alto (+3,3v), y si ALE_H está bajo (0v). Si es así, sale un 1 lógico al pin /OE (0v. El / que aparece al principio, indica que está invertido el pin, por lo que 0v es 1 y 3,3v es 0)
6. Ahora los datos de la dirección ya han sido guardados en el latch de 24 bits interno que llevan los cartuchos, obteniendo los 16 bits inferiores de lo que se encuentra en el bus de datos, y los 8 bits superiores del latch 74HC573
7. Los datos de la dirección desaparecen del bus de datos, y se configura como entrada (lectura)
8. La consola manda una señal al pin /READ, que está conectado al pin /RD del cartucho. Éste manda los 16 bits solicitados en la dirección que previamente ha sido mandada
9. Los datos son leídos por la consola
10. Si hay más datos contíguos que leer, se manda otra señal al pin /READ, y la dirección es incrementada automáticamente, hasta en 256 ocasiones (512 bytes, límite de la N64, no del cartucho de la GBA). Si no hay más datos contíguos o no se puede leer más, se vuelve al principio para mandar otra dirección

Lo primero:
NO LO HE PROBADO, pero debería funcionar

Un saludo

La verdad es que es interesante el proyecto, la cosa es que si dejas el cic de "fábrica" tendrás que parchear las roms o precargar un bootloader que se lo trague todo.

Aquí hablan de eso:

http://n64.icequake.net/#backup Ojo a la parte de "Problems we encounter with backup units"

Más info sobre el puerto de cartuchos:

http://www.crazynation.org/N64/n64_cart_info.htm

socram8888 escribió:[...]

Creo que la mayoría de cartuchos flash de GBA (y la mayoría de cartuchos comerciales) empiezan a funcionar con un menú donde puedes elegir juego u operar con el USB/CF/SD/(o lo que sea).

Si lo anterior es cierto:

En el caso de que toda la parte hardware funcione, lo primero que te llegara a la N64 es el código de ese menú (lo podemos llamar SO, firmware,...) en perfecto ARM de GBA. Deberías escribir tu menú en MIPS e introducirte en la flash/rom interna de cartucho flash original.

Lo cartuchos flash bien hechos tienen dos modos de operación: modo menú, donde todo el hardware que agrega esta mapeado y se puede controlar, y el modo juego donde la CPU solo ve la 'ROM' emulada mediante la correspondiente traducción de direcciones (y saves y todo lo que haga falta).

wah_wah_69 escribió:La verdad es que es interesante el proyecto, la cosa es que si dejas el cic de "fábrica" tendrás que parchear las roms o precargar un bootloader que se lo trague todo.[...]

Creo que el CIC es independiente del software. Si pones un CIC PAL en una consola PAL o un CIC NTSC en una consola NTSC es suficiente. Lo suyo seria crear un chip multiregión...

Eteream escribió:

socram8888 escribió:[...]

Creo que la mayoría de cartuchos flash de GBA (y la mayoría de cartuchos comerciales) empiezan a funcionar con un menú donde puedes elegir juego u operar con el USB/CF/SD/(o lo que sea).

Si lo anterior es cierto:

En el caso de que toda la parte hardware funcione, lo primero que te llegara a la N64 es el código de ese menú (lo podemos llamar SO, firmware,...) en perfecto ARM de GBA. Deberías escribir tu menú en MIPS e introducirte en la flash/rom interna de cartucho flash original.

Lo cartuchos flash bien hechos tienen dos modos de operación: modo menú, donde todo el hardware que agrega esta mapeado y se puede controlar, y el modo juego donde la CPU solo ve la 'ROM' emulada mediante la correspondiente traducción de direcciones (y saves y todo lo que haga falta).

wah_wah_69 escribió:La verdad es que es interesante el proyecto, la cosa es que si dejas el cic de "fábrica" tendrás que parchear las roms o precargar un bootloader que se lo trague todo.[...]

Creo que el CIC es independiente del software. Si pones un CIC PAL en una consola PAL o un CIC NTSC en una consola NTSC es suficiente. Lo suyo seria crear un chip multiregión...

Échale un ojo al link que puse antes, el de icequake.net:

Problems we encounter with backup units

Unfortunately for the user, Nintendo learned their lesson with the ease of use and wide proliferation of the Super NES backup units. This time, they knew what was coming, and intentionally made it difficult to operate a backup unit to play pirated games. Here is a summary of the problems a user might face, and the workarounds.

Boot chips. The N64's lockout scheme employs quite a few different boot chips (called CICs) that reside in the game cartridge, and unless the CIC provides the correct response to the N64, it will refuse to boot the game that is inserted. So, without a proper CIC at all, the N64 will refuse to boot. This is also a problem, say, if you are attempting to boot your backup device with a cartridge that has a NUS-CIC-6102 bootchip, and the program that you are attempting to boot uses a different chip, such as a NUS-CIC-6105. Since the boot code in the 6105 program image does not work with the 6102, the N64 will not allow the program to run.

Los EZ 1 y 2 (y el 3, creo) tienen un modo en el cual actua como un cartucho normal y corriente, sin menú, asi que no hay problema por eso

Sobre el CIC, yo lo voy a pillar de un cartucho, asi como la carcasa y la base para el cartucho (la placa)

wah_wah_69 escribió:Échale un ojo al link que puse antes, el de icequake.net:

Pues si, parece que el software comprueba el estado CIC al arrancar.

socram8888, ya pero entonces la pregunta es ?como se llega a ese modo?

Ahora mismo no lo tengo aqui, estoy en el aula de informática de mi instituto, pero se puede desmarcando una opción en los menús que están en la barra de arriba

Me referia a que se me ocurren 2 maneras de llegar al no-men'u:

hardware: con un coste extra por unidad

software: con coste pr'acticamente 0.



La 'ultima opci'on implica c'odigo arm des de el principio.

En ASSEMbler Games hay gente que te puede ayudar con el funcionamiento de los cartuchos de N64, el multiplexado de las señales y toda la paranafernalia.

andoba escribió:En ASSEMbler Games hay gente que te puede ayudar con el funcionamiento de los cartuchos de N64, el multiplexado de las señales y toda la paranafernalia.

Si no recuerdo mal, creo que fue de allí de donde pillé la imagen de las señales

Ya me pasaré por allí