Página 3 de 3

Re: test0 del core de Amstrad CPC

Publicado: 30 Mar 2017, 23:16
por Robe_Inie
Genial McLeod , tómate el tiempo que necesites , esto es un hobbie y como todo , habrá que tener paciencia pero el resultado a buen seguro valdrá la pena :)

Quería aprovechar para preguntar, aunque no sé si hacerlo en este hilo o mejor en el de MiST (si no procede aquí por favor movedlo).
Entiendo que el core de MiST es reimplemetación (por mucho que algunos digan que es emulación en algunos sitios...) , lo único que parte de un emulador en Java , eso sí es cierto, a través de ingeniería inversa. ¿Cuáles pueden ser las limitaciones de esto? ¿Qué diferencias puede aportar el core de McLeod respecto al de MiST ?

Re: test0 del core de Amstrad CPC

Publicado: 31 Mar 2017, 00:27
por mcleod_ideafix
Robe_Inie escribió:Entiendo que el core de MiST es reimplemetación (por mucho que algunos digan que es emulación en algunos sitios...) , lo único que parte de un emulador en Java , eso sí es cierto, a través de ingeniería inversa. ¿Cuáles pueden ser las limitaciones de esto? ¿Qué diferencias puede aportar el core de McLeod respecto al de MiST ?
Pues no te puedo responder por varias razones:
- No conozco el core del MiST. Es más: ni siquiera tengo ese cacharrico.
- Mi core aún no está terminado. Le falta un montón, así que no tiene sentido todavía hablar de diferencias, y lo que aporta o lo que no, porque ni yo mismo lo sé.

Sí puedo decir lo siguiente: tanto un emulador como una descripción HDL (core) son eso, una descripción más o menos fidedigna de la máquina. Que lo sea más o menos depende de quien ha escrito el emulador o el core. Por ejemplo: tengo entendido que las descripciones de máquinas del MAME, aun siendo software, intentan parecerse a lo que sería conectar distintos "chips" en un sistema y configurarlos. Alguien que quiera hacer un core en FPGA de una máquina arcade partiendo de lo que puede leer en MAME probablemente le salga algo parecido a lo que haría otro alguien partiendo del esquemático de ese mismo arcade.

De mi core, lo único que puedo decir, es que me baso en ingeniería inversa de los chips que lo componen. En concreto, ingeniería inversa del gate array (ya que de los demás se tiene documentado su comportamiento al ser chips estándar de industria) usando analizador lógico. Hasta donde he podido comparar, el comportamiento de mi core de gate array es idéntico al del gate array original. Tanto, que ya estoy en fase de diseño de un módulo para reemplazar el gate array en los Amstrads que estén muertos esperando un recambio de este chip.

En la vista jerárquica de ficheros del core puedo ver que tengo un z80, el mencionado gate array, un MC6845, un i8255, y un YM2149 (clon del AY-3-8912). Me falta añadir un manejador de memoria que multiplexe accesos entre el GA y el Z80 usando las líneas de control del propio GA, y algo parecido a lo que tengo hecho para otros cores, que traduzca pulsaciones en un teclado PS/2 a una matriz como la del CPC, para que al conectar esta matriz al i8255 a través de los puertos del AY, pueda leer el teclado y el joystick. Con esto tendría ya algo con lo que experimentar y ver si se comporta como debe.

Re: test0 del core de Amstrad CPC

Publicado: 31 Mar 2017, 00:45
por Robe_Inie
Agradezco tu respuesta McLeod, en temas tan técnicos me pierdo un poco pero capto la esencia de la idea.
Ánimo con el core y con el reemplazo del gate-array :-)

Re: test0 del core de Amstrad CPC

Publicado: 31 Mar 2017, 01:19
por fbelavenuto
The AZ-80 was upgraded in January and is working, but you're right, not great for synthesis.

I used the Kazuhiro modified T80 only in MSX (because of /WAIT), in TBBlue the core is another, similar to the ZX-Uno, with a slight correction in the timing of the /M1 signal during interrupt acknowledgement. I had issue with Commando game because of this LD A,R/I bug at the beginning of development, so I got another core with the fix.
mcleod_ideafix escribió:
fbelavenuto escribió:I recommend trying out the A-Z80 project too:
https://opencores.org/project,a-z80
I did, but, unless the author has cleaned it up, that core suffers from some limitations: it is not optimized for FPGA design, so the resulting netlist performs very slow. I recall it has also some local clocks (combinational signals that are used as clocks) which, still being accepted in a Spartan 6 design, makes this core to quickly exhaust all global buffers, leaving the P&R process very little to work with. I think it's a core more suitable for performing simulations than for being synthesized.

This, I repeat, unless the author has updated the project, which I don't know if he did.

Fabio, if you have been used the Kazuhiro modified T80 core for the TBBlue core, go and see if it can run King's Valley (the Spectrum version, of course). If that core doesn't update flags correctly when executing LD A,R , I think the screen will freeze, or the game will reset, or something similar.

EDIT: the version I have of TBBlue runs King's Valley correctly :) So, are you using that core?