Español/Portugues abajo
Service Release
JTOUTRUN update: (Out Run support)
JTSHANON update: (Super Hang-On support)
JTPANG, JTCPS1 update: (Pang! Super Pang!, Pang! 3 and others…)
JTTORA, JTSECTNZ, JTBIOCOM, JT1942, JTSF (Tiger Road, Section Z, Bionic Commando, 1942, SF1, etc.)
JTS16B (Golden Axe, Altered Beast, etc.)
Development News
We fixed two bugs on the NeoGeo Pocket CPU, but it didn’t make much of a difference on the games, so work on it will continue next week.
Work started on JTSHOUSE, a Namco System 1 compatible core (Splatter House, PacMania, etc.). This is a very sophisticated system with four CPUs that can all talk to each other through several devices. This is quite unusual. Most arcade systems feature two CPUs and only one of them can talk to the other.
Systems with bi-directional or multi-directional communication among all the CPUs are very sensitive to timing. MAME source code is full of comments about synchronization problems in these kind of systems because the original software relied too often on very precise timings. So even if your CPUs are moving at the right speed, you can still have problems if their relative phases are not right.
If the FPGA core has plenty of fast access RAM to keep all CPUs happy, these timing issues should never occur. But on most cores, there is not enough fast memory and the SDRAM is used instead. In these cases, the CPUs inside the FPGA may be temporarily late by 0.1 micro seconds, only to catch up soon after. This is due to the CPU waiting for the data to come from the SDRAM. I am concerned about any race condition rising among the CPUs related to a temporary delay in one of them. To minimize this risk, the new core is built with full system synchronization in mind.
The relative phase of all four CPUs will be preserved by design on this core. Temporary delays due to SDRAM waits will hold all CPUs together and the clock speed up to recover time will be done for all elements at the same time.
Hopefully, this will lead to a very stable system that preserves the timing of the CPU interactions on the original board.
Español
Actualización de JTOUTRUN: (soporte de Out Run):
Actualización de JTSHANON: (compatibilidad con Super Hang-On)
Actualización de JTPANG, JTCPS1: (Pang! Super Pang!, Pang! 3 y otros...)
JTTORA, JTSECTNZ, JTBIOCOM, JT1942, JTSF (Tiger Road, Section Z, Bionic Commando, 1942, SF1, etc.)
JTS16B (Golden Axe, Altered Beast, etc.)
Noticias de desarrollo
Hemos corregido dos errores en la CPU de NeoGeo Pocket, pero no ha supuesto una gran diferencia en los juegos, así que seguiremos trabajando en ella la semana que viene.
Estamos ya con el JTSHOUSE, un núcleo compatible con Namco System 1 (Splatter House, PacMania, etc.). Se trata de un sistema muy sofisticado con cuatro CPUs que pueden comunicarse entre sí a través de varios dispositivos. Esto es bastante inusual. La mayoría de los sistemas arcade cuentan con dos CPU y sólo una de ellas puede hablar con la otra.
Los sistemas con comunicación bidireccional o multidireccional entre todas las CPU son muy sensibles a la sincronización. El código fuente de MAME está lleno de comentarios sobre problemas de sincronización en este tipo de sistemas porque el software original dependía demasiado a menudo de sincronizaciones muy precisas. Así que incluso si tus CPUs se mueven a la velocidad correcta, puedes tener problemas si sus fases relativas no son correctas.
Si el núcleo de la FPGA tiene mucha RAM de acceso rápido para mantener a todas las CPUs contentas, estos problemas de temporización no deberían ocurrir nunca. Pero en la mayoría de los núcleos, no hay suficiente memoria rápida y en su lugar se utiliza la SDRAM. En estos casos, las CPUs dentro de la FPGA pueden retrasarse temporalmente 0,1 micro segundos, y se recuperan poco después. Esto se debe a que la CPU espera a que los datos lleguen de la SDRAM. Me preocupa que surjan problemas entre las CPUs por culpa de un retraso temporal en una de ellas. Para minimizar este riesgo, el nuevo núcleo se ha construido teniendo en cuenta la sincronización total del sistema.
La fase relativa de las cuatro CPU se preserva por diseño en este núcleo. Los retrasos temporales debidos a las esperas de la SDRAM mantienen todas las CPU juntas y el aumento de la velocidad de reloj para recuperar el tiempo se hará para todos los elementos a la vez.
Esto debería conllevar un sistema muy estable y que conserva la sincronización de las interacciones de la CPU de la placa original.
Portugues
Atualização JTOUTRUN: (Suporte Out Run)
• Corrigida uma linha estranha no meio da estrada
• Correção dos sons PCM
• Menu OSD corrigido (MiSTer)
• Adicionada a gravação automática das definições de serviço (Pocket)
Atualização JTSHANON: (Suporte para Super Hang-On)
• Corrigida a linha estranha no meio da estrada
• Adicionada a gravação automática das definições de serviço (Pocket)
Atualização JTPANG, JTCPS1: (Pang! Super Pang!, Pang! 3 e outros...)
• Adicionada a gravação automática das definições de serviço (Pocket)
JTTORA, JTSECTNZ, JTBIOCOM, JT1942, JTSF (Tiger Road, Section Z, Bionic Commando, 1942, SF1, etc.)
• Pequenas correções nos nomes dos interruptores DIP e nas predefinições
JTS16B (Golden Axe, Altered Beast, etc.)
• Promovido a lançamento público (Pocket)
Notícias de desenvolvimento
Corrigimos dois bugs no CPU NeoGeo Pocket, mas não fez grande diferença nos jogos, por isso o trabalho vai continuar na próxima semana.
Começámos a trabalhar no JTSHOUSE, um núcleo compatível com o Namco System 1 (Splatter House, PacMania, etc.). Este é um sistema muito sofisticado com quatro CPUs que podem comunicar entre si através de vários dispositivos. Isto é bastante invulgar. A maioria dos sistemas de arcade tem dois CPUs e apenas um deles pode falar com o outro.
Sistemas com comunicação bidirecional ou multidirecional entre todas os CPUs são muito sensíveis ao tempo. O código-fonte do MAME está cheio de comentários sobre problemas de sincronização neste tipo de sistemas, porque o software original dependia muitas vezes de tempos muito precisos. Assim, mesmo que os CPUs estejam a mover-se à velocidade correta, pode haver problemas se as suas fases relativas não estiverem corretas.
Se o núcleo da FPGA tiver bastante RAM de acesso rápido para manter todos os CPUs satisfeitos, esses problemas de temporização nunca devem ocorrer. Mas na maioria dos núcleos, não há memória rápida suficiente e a SDRAM é usada em seu lugar. Nesses casos, os CPUs dentro do FPGA podem estar temporariamente atrasadas em 0,1 microssegundos, apenas para recuperar o atraso logo em seguida. Isto deve-se ao facto do CPU estar à espera de que os dados venham da SDRAM. Preocupa-me a possibilidade de surgir uma condição de corrida entre os CPUs devido a um atraso temporário numa delas. Para minimizar este risco, o novo núcleo foi construído tendo em mente a sincronização total do sistema.
A fase relativa de todas os quatro CPUs será preservada por design neste núcleo. Atrasos temporários devido a esperas de SDRAM manterão todas os CPUs juntas e a velocidade do relógio até o tempo de recuperação será feita para todos os elementos ao mesmo tempo.
Espera-se que isto conduza a um sistema muito estável que preserve o tempo das interações dos CPUs na placa original.
Wayne
2025-01-23 21:34:45 +0000 UTCJoe303
2024-04-15 14:02:23 +0000 UTCJoe303
2024-03-21 06:31:15 +0000 UTCBig Al.
2023-10-14 18:39:36 +0000 UTCBig Al.
2023-10-11 12:59:24 +0000 UTCJOTEGO
2023-10-06 18:39:34 +0000 UTCSteven S
2023-10-06 17:44:17 +0000 UTCVINSTER
2023-09-28 07:12:13 +0000 UTCMichael McCann
2023-09-26 20:32:22 +0000 UTCTerry Goodwin
2023-09-26 20:25:57 +0000 UTCFender
2023-09-25 14:42:02 +0000 UTCJOTEGO
2023-09-25 14:41:00 +0000 UTCJOTEGO
2023-09-25 14:40:07 +0000 UTCJOTEGO
2023-09-25 14:39:39 +0000 UTCJOTEGO
2023-09-25 14:38:58 +0000 UTCJOTEGO
2023-09-25 14:37:36 +0000 UTCMichael McCann
2023-09-25 14:23:28 +0000 UTCOvean , LLC
2023-09-24 05:32:33 +0000 UTCronalvel .
2023-09-23 19:39:16 +0000 UTCMark Saunders
2023-09-23 18:19:06 +0000 UTCFender
2023-09-23 18:01:00 +0000 UTCFender
2023-09-23 17:53:12 +0000 UTCjose rosales
2023-09-23 16:36:56 +0000 UTCAlberto Albericio
2023-09-23 08:19:11 +0000 UTCSteven Kirkham
2023-09-23 04:58:39 +0000 UTCTetra
2023-09-23 02:34:33 +0000 UTCMichael Johnson
2023-09-23 01:22:51 +0000 UTCBit2018
2023-09-22 22:57:04 +0000 UTCMiSTer Retro Wolf
2023-09-22 20:36:48 +0000 UTCMat Azel
2023-09-22 20:06:24 +0000 UTCSalvador Perugorria Lorente
2023-09-22 20:01:04 +0000 UTCAdrien Duchemole
2023-09-22 19:42:13 +0000 UTCJOTEGO
2023-09-22 19:36:19 +0000 UTCMichele Fornasini
2023-09-22 18:25:10 +0000 UTCKent Pendragon
2023-09-22 17:56:27 +0000 UTCMat Azel
2023-09-22 17:53:12 +0000 UTCAndreas Watzinger
2023-09-22 17:43:24 +0000 UTCFrancisco Blazquez
2023-09-22 17:13:01 +0000 UTCMichael Johnson
2023-09-22 16:52:18 +0000 UTCIan MacPherson
2023-09-22 16:49:36 +0000 UTCFlyingCheese
2023-09-22 16:38:24 +0000 UTCJOTEGO
2023-09-22 16:36:20 +0000 UTCJOTEGO
2023-09-22 16:35:51 +0000 UTCJOTEGO
2023-09-22 16:35:31 +0000 UTCJOTEGO
2023-09-22 16:34:07 +0000 UTCOnkelPipi
2023-09-22 16:29:09 +0000 UTCGeckofingers
2023-09-22 16:08:33 +0000 UTCIan MacPherson
2023-09-22 16:01:36 +0000 UTCFilip Kindt
2023-09-22 15:58:42 +0000 UTCPixel Cherry Ninja
2023-09-22 15:56:32 +0000 UTCEspiox
2023-09-22 15:53:27 +0000 UTCRachel Schaeffer
2023-09-22 15:49:33 +0000 UTCDarren Newman
2023-09-22 15:46:41 +0000 UTCDenny Letourneau
2023-09-22 15:46:27 +0000 UTCMuriel Melvin
2023-09-22 15:43:25 +0000 UTCTom Moretti
2023-09-22 15:37:12 +0000 UTC