Ver la versión completa : Analogue Pocket, por fin abren las reservas!
Hola Companchis,
Después de mucho esperar, el 3 de agosto abren las reservas! Por un momento pensé que la iban a cancelar, incluso les escribí un par de mails... pero la cosa va para adelante.
Yo me subo al carro, es un concepto que me flipa. La consola es compatible(sin emulación) con GB, GBC y GBA, y mediante adaptadores(a 29€ la unidad) con NeoGeo Pocket Color, Lynx y GameGear. Yo voy a por el lote completo y dar uso a la colección de cartuchos que tengo!!!
Os dejo el link a la noticia: https://vandal.elespanol.com/noticia/1350736541/la-analogue-pocket-se-retrasa-a-mayo-de-2021-y-las-reservas-se-abren-el-3-de-agosto/
Os dejo el enlace al Pdf que me ha llegado por mail con todos los detalles... es un cacharro precioso! https://support.analogue.co/hc/en-us/article_attachments/360062886711/ANLG_PKT_JULY_27_NEWS.pdf
Pufff yo creo que me apunto al lote completo!
insisten mucho en lo de "sin emulacion". Dudo mucho que lleve el hard origianl de todas esas maquinas. Supongo que será fpga. Que sí, que tecnicamente no es emulacion, pero que a la hora de la verdad tiene sus mismos problemas con defectos, incompatibilidades, etc...
edito: veo en el pdf que sí, que efectivamente es fpga.
Sí, es FPGA... No me mates Syto!Yo soy un poco Zote en en estos asuntos... voy a tener problemas??? SHIT!!!
Sí, es FPGA... No me mates Syto!Yo soy un poco Zote en en estos asuntos... voy a tener problemas??? SHIT!!!
Les pasa lo mismo que a los emuladores, como están hechos sin la documentación oficial y sin saber exactamente como están sincronizados los procesadores o incluso algún defecto que no este implementado, te puedes encontrar algún juego que no funcione perfectamente.
masteries
29/07/2020, 13:37
insisten mucho en lo de "sin emulacion". Dudo mucho que lleve el hard origianl de todas esas maquinas. Supongo que será fpga. Que sí, que tecnicamente no es emulacion, pero que a la hora de la verdad tiene sus mismos problemas con defectos, incompatibilidades, etc...
edito: veo en el pdf que sí, que efectivamente es fpga.
Mirad lo que sucede con el core del STE en la Mister.
Que cuando usas el blitter de una forma distinta a como se usan habitualmente; cuando no haces bit-blit con máscaras y tal... los sprites no se ven xD
En realidad te están haciendo todo el lío, porque están implementado electrónicamente las operaciones software que lleva a cabo el emulador.
Y dado que no es flexible como el software, sino totalmente rígido, acaba siendo más complejo hacerlo 100% efectivo.
Con el Amiga debe pasar cuarta parte de lo mismo, seguro que su hardware se puede utilizar de otras formas, más eficientes pero mucho más complejas de entender y por ende más difíciles de replicar sólo con un circuito digital.
Bueno, no sé hasta qué punto han llegado a aprovechar las "bondades" del HW de las máquinas estas. Tampoco creo que sean demasiado complejas ¿no?
En el caso de la GG se van a quitar muchos marrones con la FPGA, porque no necesitan toda la circuitería de encendido de la pantalla (ni los condensadores que se mueren solos :D).
De todas formas, sigo pensando que es muy cara, sobre todo para poder usar mis cartuchos de GG, y que luego en la pantalla se vea todo "estrechado", como en los emuladores. Me sale más barato comprar una GG de segunda mano, o encontrar a X-Code y estar dándole collejas hasta la salida de la Pyra :lol:
y que luego en la pantalla se vea todo "estrechado", como en los emuladores.
Parece que tiene un modo en el que la pantalla se adapta totalmente a como era en la consola clásica, Original Display Mode lo llaman.
Son 199$, si buscáis en eBay una GBA modificada con backlight no sale mucho más barato, y ésta ofrece muchísimo más... a mi no me parece un precio tan descabellado. El modo standby a mi me da toda la vida! :)
Parece que tiene un modo en el que la pantalla se adapta totalmente a como era en la consola clásica, Original Display Mode lo llaman.
Sí, pero hay muchos emuladores que tienen ese modo "resolución original", que lo que hace es buscar la resolución en pixels del original, sin tener en cuenta estas cosas de que un pixel sea más ancho que alto, y pasa eso, así que necesitaría que fueran un poco más específicos con ello :D
Son 199$, si buscáis en eBay una GBA modificada con backlight no sale mucho más barato, y ésta ofrece muchísimo más... a mi no me parece un precio tan descabellado. El modo standby a mi me da toda la vida! :)
Emmm ¿200$? Hombre, a falta de saber lo que vale un kit de backlight me parece excesivamente caro. Una GBA la encuentras por menos de 50$, 30$ si me apuras. Un kit de backlight por 150€... No sé, a mi me parece que la mano de obra se ha inflado un poco en el precio... aunque claro, no todo el mundo puede hacer este tipo de ñapas. ¿De qué consola vi un enlace hace poco que te permitía modificar la pantalla sin soldaduras?
Ah, si:
https://www.gp32spain.com/foros/showthread.php?63582-Hilo-de-Adquisiciones-odio-inside-x-D/page730
Mensaje 10940. Y es un kit de 30€, por lo que el conjunto te sale por menos de 100€
Pero lo dicho ¿una consola por 199$, mas los adaptadores? Juer, es el precio de una GP32 recien salida la GBA a mitad de precio. Ya tiene que ser fiel al 99% de al menos 4 máquinas para que me lo plantee siquiera.
sergiobordon
29/07/2020, 17:20
¿Y esta?
https://www.experimentalpi.com/PiBoy-DMG--Assembled_p_16.html
Yo me lo estoy pensando y todo.
¿Y esta?
https://www.experimentalpi.com/PiBoy-DMG--Assembled_p_16.html
Yo me lo estoy pensando y todo.
Pero en esa se pierde la gracia de poder usar los cartuchos originales :lol:
sergiobordon
29/07/2020, 17:57
Pero en esa se pierde la gracia de poder usar los cartuchos originales :lol:
Yo para los cartuchos originales me acabo de pillar esto:
https://www.amazon.com/-/es/gp/product/B072FRQZ65/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
y espero que no hagan el truco sucio que hacen algunos "emuladores" para fpga, que muchas de sus funciones en vez de simularlas por fpga aprovechan el hardware de la misma para hacer una emulación tipica y topica. xddddd
¿Habéis visto que en el PDF dice que la pantalla está hecha con "Gorrilla Glass"? Espero que no te pida 1 € cada vez que la usas.53811
¿Habéis visto que en el PDF dice que la pantalla está hecha con "Gorrilla Glass"? Espero que no te pida 1 € cada vez que la usas.53811
Pues tu verás, pero como no se lo des, cuando vuelvas a por la consola va a estar la pantalla toda rayada :quepalmo:
¿habéis visto que en el pdf dice que la pantalla está hecha con "gorrilla glass"? Espero que no te pida 1 € cada vez que la usas.53811
jajajajjajajajaja
Mirad lo que sucede con el core del STE en la Mister.
Que cuando usas el blitter de una forma distinta a como se usan habitualmente; cuando no haces bit-blit con máscaras y tal... los sprites no se ven xD
En realidad te están haciendo todo el lío, porque están implementado electrónicamente las operaciones software que lleva a cabo el emulador.
Y dado que no es flexible como el software, sino totalmente rígido, acaba siendo más complejo hacerlo 100% efectivo.
Con el Amiga debe pasar cuarta parte de lo mismo, seguro que su hardware se puede utilizar de otras formas, más eficientes pero mucho más complejas de entender y por ende más difíciles de replicar sólo con un circuito digital.
En una fpga al final estas haciendo la definición por 'software' del hardware, si te equivocas cambias la definición cargas y pruebas de nuevo, mas lento y mas engorroso (aparte de mas caro) seguro que lo es pero no veo que sea menos flexible que por software.
Yo veo mas problema en el FPGA en que hay muy poca gente que trabaje con ellas y muchos de los proyectos se estancan, por lo que si se encuentra un error o no hay gente detras para investigar porque se produce y corregirlo o hay una o dos personas a ratos libres.
¿Habéis visto que en el PDF dice que la pantalla está hecha con "Gorrilla Glass"? Espero que no te pida 1 € cada vez que la usas.53811
Por favor explicadme el chiste que no lo pillo jajaja soy muy lento! Al final me estáis desinflando mamones!!! Con lo contento que yo estaba, desempolvando mi colección de cartuchos! :D
Por favor explicadme el chiste que no lo pillo jajaja soy muy lento! Al final me estáis desinflando mamones!!! Con lo contento que yo estaba, desempolvando mi colección de cartuchos! :D
Creo que en muchos sitios de España se conoce como "gorrillas" a los yonkis que están en las zonas de aparcamiento de las grandes superficies indicando donde quedan plazas libres a cambio de una propina. La propina es "voluntaria", porque si no les das nada es normal encontrarse el coche rayado a la vuelta.
Hombre, no te desinfles, el cacharro está muy chulo y pueda que tengo sus problemillas al principio pero seguro que mola. Yo voy a comprar esta consola porque no tengo tiempo para estas cosas ahora.
¿Habéis visto que en el PDF dice que la pantalla está hecha con "Gorrilla Glass"? Espero que no te pida 1 € cada vez que la usas.53811
:quepalmo: :quepalmo: :quepalmo:
No sabéis la falta que me hacía reírme así :D
Gracias.
masteries
30/07/2020, 12:39
En una fpga al final estas haciendo la definición por 'software' del hardware, si te equivocas cambias la definición cargas y pruebas de nuevo, mas lento y mas engorroso (aparte de mas caro) seguro que lo es pero no veo que sea menos flexible que por software.
Yo veo mas problema en el FPGA en que hay muy poca gente que trabaje con ellas y muchos de los proyectos se estancan, por lo que si se encuentra un error o no hay gente detras para investigar porque se produce y corregirlo o hay una o dos personas a ratos libres.
Me refería a que en muchos emuladores hay varias implementaciones para emular un mismo dispositivo, porque el propio emulador se da cuenta que unas veces usas el hardware de una manera u otra, y entonces tienen implementado el workaround de cambiar el flujo del programa, y con eso se defienden bastante bien.
Pero a nivel de fpga, implica tener varias réplicas / instanciaciones de un mismo elemento hardware; imagina que para el blitter de un STE o un Amiga, el emulador tiene 6 o 7 implementaciones distintas para replicar el comportamiento fiel al 99% de un único elemento hardware; es algo que puede darse de forma común, por unos u otros asuntos... así han logrado emular aquello que no está documentado.
Ahora en una FPGA, esto implica 6 o 7 instancias de un elemento que lo mismo el sólo ya se come 5000 celdas lógicas; y ahora sincroniza bien sus transacciones de datos porque son 6 o 7 hardware distintos pero han de respetar los mismos tiempos... por software es más flexible un workaround así.
En FPGAs trabaja poca gente, y en FPGA con contenido analógico muchos menos (además estas son FPGAs muy especialitas) ¿cómo simulan los chips dedicados cuyo interior es mayoritariamente analógico? Porque de estos en máquinas retro son bastantes,
-----Actualizado-----
y espero que no hagan el truco sucio que hacen algunos "emuladores" para fpga, que muchas de sus funciones en vez de simularlas por fpga aprovechan el hardware de la misma para hacer una emulación tipica y topica. xddddd
Esto es lo que comentabas:
53812
Que no deja de ser implementar en la FPGA un sistema computacional convencional; con su CPU, su controlador de memoria, sus buses, sus interrupciones, su entrada / salida (aquí es donde va conectado el cartucho), su framebuffer (hasta el adaptador de vídeo lo puedes hacer a las brutas, como una tarjeta super vga, que todo lo haga la CPU, como puede ser suficientemente potente) e incluso su memoria de programa ( ROM ) que puede ya tener grabado el programa con los emuladores a ejecutar xD
Hacer eso no tienes mayor historia; con una placa Zynq, le indicas que quieres una CPU ARM Cortex A, o Cortex M, o una CPU MicroBalze que es gratis si usas FPGAs de Xylinx... tal y cual... una ROM de tanto y de tanto ancho de bits, y conectarlo al debug JTAG... sueles tener 1 GB de DDR3... y si no vas inventar más ruedas, puedes empezar a meter programas compilados para esa CPU en la ROM que le has indicado... más quebraderos de cabeza te va a dar la interfaz del cartucho al tener que hacerla sí o sí en VHDL; pero con este "sucio" truco no hay más VHDL que la interfaz del cartucho.
Y ya tienes un sistema "hardware" que emula otros sistemas...
Como decía uno de mis profesores de electrónica digital en la universidad, en los años 80 se necesitaban varios chips para resolver un problema, pero hoy día un chip tiene capacidad para resolver 200 problemas :D
Con las FPGA pasará lo mismo, y como pasa con el software, la gente tendrá tendencia a aprovechar que sobra potencia para hacer las implementaciones de forma fácil en lugar de bien... Y la verdad, si hay recursos de sobra, tampoco es que importe mucho ¿o sí?
No sé, si hay que configurar la FPGA para que haya un retraso exacto de 35ns entre la CPU y el chip de sonido, pues se puede hacer, pero el problema es ¿cómo se sabe que son 35ns? ¿Cómo sabemos que otras partes del sistema no ralentizan ese proceso? Entiendo que hacer un HW 100% fiel mediante "emulación digital" (me refiero al HW de una FPGA) es mucho, pero mucho más difícil y tedioso que hacer ingeniería inversa a un dispositivo digital, si hay que tener en cuenta delays, electrónica analógica...
Ahora, lo que ya he comentado otras veces: no sé hasta qué punto los programadores se han aprovechado de los tiempos exactos del ordenador, la electrónica analógica, y todo lo que se sale de la norma binaria más estricta :D Y no sé si eso es correcto o es "hacer trampa" con el HW :lol:
ah ***** "Gorrilla" JAJAJAJA no había visto la segunda R jajaja Gracias jcom!
Como decía uno de mis profesores de electrónica digital en la universidad, en los años 80 se necesitaban varios chips para resolver un problema, pero hoy día un chip tiene capacidad para resolver 200 problemas :D
Con las FPGA pasará lo mismo, y como pasa con el software, la gente tendrá tendencia a aprovechar que sobra potencia para hacer las implementaciones de forma fácil en lugar de bien... Y la verdad, si hay recursos de sobra, tampoco es que importe mucho ¿o sí?
No sé, si hay que configurar la FPGA para que haya un retraso exacto de 35ns entre la CPU y el chip de sonido, pues se puede hacer, pero el problema es ¿cómo se sabe que son 35ns? ¿Cómo sabemos que otras partes del sistema no ralentizan ese proceso? Entiendo que hacer un HW 100% fiel mediante "emulación digital" (me refiero al HW de una FPGA) es mucho, pero mucho más difícil y tedioso que hacer ingeniería inversa a un dispositivo digital, si hay que tener en cuenta delays, electrónica analógica...
Ahora, lo que ya he comentado otras veces: no sé hasta qué punto los programadores se han aprovechado de los tiempos exactos del ordenador, la electrónica analógica, y todo lo que se sale de la norma binaria más estricta :D Y no sé si eso es correcto o es "hacer trampa" con el HW :lol:
Usando un analizador de bus.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.