【 X68000 】 DOOM

Avatar de Usuario
ron
Mensajes: 21855
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 3862 veces
Agradecimiento recibido: 4752 veces

【 X68000 】 DOOM

Mensajepor ron » 22 Nov 2016 21:09

Como suena, finalmente el PORT de DOOM para X68000 funciona !!!!

https://www.youtube.com/watch?v=TzLKMP9yiOc

Y que alguien que sepa, japo...

??????????
????????????????????

X68000?????

X68000XVI Xellent30 cpu40Mhz,sys15Mhz
Memory :12MB+4MB+16MB(X-simmVI+Nereid+MK-HM16)
Hard Disk :4.3GB(??) (QUANTUM FIREBALL ST4.3)
SLOT :MIDI(SX-68MII) :Nereid(LAN+Memory+USB)
MIDI :SC-88PRO
S-CONVERTER:XPC-4
CAPTURE :GAME CAPTURE HD II

http://www.pipitan.com

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: 【 X68000 】 DOOM

Mensajepor Chema » 22 Nov 2016 21:21

Alucino. Va como a medio cuadro por segundo ;) pero los gráficos están clavados. Vaya chulo que se ve!

Avatar de Usuario
kikems
Mensajes: 5502
Registrado: 30 May 2013 19:23
Agradecido : 2638 veces
Agradecimiento recibido: 3112 veces

Re: 【 X68000 】 DOOM

Mensajepor kikems » 22 Nov 2016 21:31

Pero esto va en un 68000 a 12 Mhz?

dancresp
Mensajes: 6224
Registrado: 13 Nov 2010 02:08
Ubicación: Barcelona
Agradecido : 664 veces
Agradecimiento recibido: 1016 veces

Re: 【 X68000 】 DOOM

Mensajepor dancresp » 22 Nov 2016 23:27

Es curioso... pero injugable.

Igual sintetizando un chip Super-FX en una FPGA del ZX-UNO y conectando un SVP de SEGA por el conector VGA en simulación de un doble núcleo, y todo ello conectado por el puerto paralelo, consiguen una mayor velocidad de cálculo. Digo yo.
Buscando la IP de la W.O.P.R. he encontrado mi índice

Avatar de Usuario
Estrayk
Mensajes: 1232
Registrado: 05 Jun 2015 18:36
Ubicación: Valencia
Agradecido : 345 veces
Agradecimiento recibido: 985 veces

Re: 【 X68000 】 DOOM

Mensajepor Estrayk » 22 Nov 2016 23:50

Pues va mejor que el doom en Amiga con 020 a 14Mhz.

https://www.youtube.com/watch?v=7GidMvDThdU

Eso sí, lo mas bestia que he visto en optimización, la versión de Atari Falcon. 030 a 16Mhz.

https://www.youtube.com/watch?v=RiE0Y1su-9g
-j4tar1 ・Falcon 060 ・・MegaSTE ・・STe ・
-coam1・v600・A1000・A1220・A1230・A1260・v1200・CD32・G5 MorphOS・
MiSTMiSTer・X68000・Acorn A3010・Performa 630・PowerMac 4400/7600/G3/G4・Ultimate64・Atari XE 1Mb+VBXE・MSX2F1XD

Avatar de Usuario
Nandove
Mensajes: 1567
Registrado: 10 Ene 2011 12:16
Agradecido : 613 veces
Agradecimiento recibido: 418 veces

Re: 【 X68000 】 DOOM

Mensajepor Nandove » 23 Nov 2016 08:37

Para ser justos, es improbable que un 020 tenga fpu mientras que un 030 es bastante probable, y en estas cosas, la FPU marca muuuucho la diferencia.

Si quieres ser justo compara un Atari con 030 y FPU con un Amiga con 030 y FPU.

Y aun asi es probable que esten muy igualados, en el atari el procesador se come todo, y en el amiga esta mas desahogado por los custom chips, desgraciadamente el amiga en 3D tiene un handicap muy gordo con sus modos de video, los bitplanes le hacen pasar varias veces por el mismo fotograma.

Avatar de Usuario
kikems
Mensajes: 5502
Registrado: 30 May 2013 19:23
Agradecido : 2638 veces
Agradecimiento recibido: 3112 veces

Re: 【 X68000 】 DOOM

Mensajepor kikems » 23 Nov 2016 10:53

En este caso el Atari Falcon literalmente se come a todos sus competidores a la misma frecuencia de reloj y con las mismas especificaciones de de CPU-FPU y RAM. Frente a un Amiga equivalente y concretamente con el DOOM imagino que la diferencia está en que el sistema gráfico del Falcon tiene modo chunky directo.

Avatar de Usuario
minter
Mensajes: 4826
Registrado: 22 Jul 2014 18:51
Agradecido : 6762 veces
Agradecimiento recibido: 2602 veces

Re: 【 X68000 】 DOOM

Mensajepor minter » 23 Nov 2016 10:58

yo diria que en este punto, junto con el wolfstein, fue cuando la gente vio el potencial del PC respecto a los 68000 en el aspecto de los juegos.
Porque hasta entonces, los que había eran practicamente iguales en casi todos los sistemas, amen de colores y sonidos.
Pero de estar en casa jugando al indy, e irme a casa de un amigo, con su 386dx y disco duro de no me acuerdo a jugar al mundo disco, xwins, o doom, cambiaba la cosa un huevo. Luego los juegos como F29 retaliator,comparado con el Bomber...
Se empezaba a notar que los 68000 ya estaban dando sus ultimos coletazos. Sino antes.

Avatar de Usuario
Hodor
Mensajes: 1705
Registrado: 19 May 2015 10:55
Ubicación: A 900km de Oviedo
Agradecido : 438 veces
Agradecimiento recibido: 525 veces

Re: 【 X68000 】 DOOM

Mensajepor Hodor » 23 Nov 2016 11:33

Recuerdo que el Doom necesitaba de todo un señor 486DX para ir fluido a pantalla completa y detalle alto. Incluso la versión Mac pedía un 040 "alegre" puesto que hablamos de un juego ya exigente.

Dentro de las versiones que habéis puesto, el Falcon se merienda a todas las demás tal y como ha comentado kikems.

Un saludo.

Avatar de Usuario
wilco2009
Mensajes: 2141
Registrado: 07 Ene 2013 16:48
Ubicación: Valencia
Agradecido : 202 veces
Agradecimiento recibido: 384 veces

Re: 【 X68000 】 DOOM

Mensajepor wilco2009 » 24 Nov 2016 15:31

En este video se puede ver que el doom era jugable en un 386DX 40MHz
En alta calidad y pantalla completa sacaba 20 FPS.

https://www.youtube.com/watch?v=qQEHHc1q06c&t=63s
"Nada viaja a mayor velocidad que luz con la posible excepción de las malas noticias las cuales obedecen a sus propias leyes."

Douglas Adams. Guía de autoestopista galáctico.

dancresp
Mensajes: 6224
Registrado: 13 Nov 2010 02:08
Ubicación: Barcelona
Agradecido : 664 veces
Agradecimiento recibido: 1016 veces

Re: 【 X68000 】 DOOM

Mensajepor dancresp » 24 Nov 2016 17:42

wilco2009 escribió:En este video se puede ver que el doom era jugable en un 386DX 40MHz
En alta calidad y pantalla completa sacaba 20 FPS.

Yo descubrí este juego en un 386DX a 40MHz, y tuve el honor de hacer mis primeras partidas en el curro, jugando en red con 3 compañeros más, y el juego tiraba a pantalla completa la mar de bien.

En mi casa tenía un 286 a 16 MHz, y allí me tenía que conformar con el Wolfenstein 3D...
Buscando la IP de la W.O.P.R. he encontrado mi índice

Avatar de Usuario
Jinks
Mensajes: 2700
Registrado: 09 Oct 2013 16:47
Agradecido : 348 veces
Agradecimiento recibido: 478 veces
Contactar:

Re: 【 X68000 】 DOOM

Mensajepor Jinks » 24 Nov 2016 20:43

Nandove escribió:Para ser justos, es improbable que un 020 tenga fpu mientras que un 030 es bastante probable, y en estas cosas, la FPU marca muuuucho la diferencia.

Que yo sepa, el Doom para PC no hacía uso de la FPU, usaba aritmética entera porque era más rápido que usar la FPU. No sé si en la familia 68K ocurrirá lo mismo. Hay un libro sobre optimización en general y de gráficos en particular, que cuenta cómo están hechos el Doom y el Quake: Graphics Programming Black Book

Avatar de Usuario
Emerald Golvellius
Mensajes: 392
Registrado: 05 Ene 2017 22:49
Ubicación: Krynn
Agradecido : 273 veces
Agradecimiento recibido: 33 veces

Re: 【 X68000 】 DOOM

Mensajepor Emerald Golvellius » 06 Ene 2017 16:18

Hay algun MONSTRUO de X68000 por ahi que deberia moverlo mejor,de todos modos mola ver el DOOM en esa maquina,
lo que pasa es que sinceramente viendo la maquina que es...yo habria imaginado que funcionaria algo mejor.
Keep the Calm & E N D D E M O G A M I T A I N A

Avatar de Usuario
DyLucke
Mensajes: 4726
Registrado: 30 Oct 2010 12:52
Ubicación: Pompaela vieja
Agradecido : 136 veces
Agradecimiento recibido: 183 veces

Re: 【 X68000 】 DOOM

Mensajepor DyLucke » 06 Ene 2017 16:58

kikems escribió:En este caso el Atari Falcon literalmente se come a todos sus competidores a la misma frecuencia de reloj y con las mismas especificaciones de de CPU-FPU y RAM. Frente a un Amiga equivalente y concretamente con el DOOM imagino que la diferencia está en que el sistema gráfico del Falcon tiene modo chunky directo.


Sí, tiene modo chunky, pero la jugada de la que saca realmente partido el Falcon, es el uso del DSP.
Un PC 386 a 16mhz también tiene modo chunky, pero no esperes rodar Doom en él... Wolf3D y gracias.

El 030 no es mucho mejor que un 020 a la misma frecuencia.

De hecho, se puede comprobar en las aceleradoras de A1200, donde una 020 @28mhz, rinde al nivel de una 030 @25mhz.
"I'm playing games.
You've nowhere to run,
I'm a piece of the sun,
i'm an army of one...
I'm the man with the gun".

Avatar de Usuario
ron
Mensajes: 21855
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 3862 veces
Agradecimiento recibido: 4752 veces

Re: 【 X68000 】 DOOM

Mensajepor ron » 06 Ene 2017 19:14

Hola DyLucke, es que me has dejado ahí el hueso pa morder y vengo !!!

Es aprox como dices pero hay ciertos matices que hacen la diferencia. Vale, digamos que un 020 y un 030 se aproximan, a excepción que el 030 tiene MMU ( Memory Management Unit y no todos la tienen ) y una cache de datos de 256 bytes, cuando el 020 solo tiene caché de instrucciones.

El 030 aparte de los 256 bytes puede operar en mode synchronous y en modo burst, en ambos casos el ancho del bus son 32 bit y en 020 hay un modo de 24 bit.

Un 020 tiene 190000 transistores y un 030 270000. Por tanto un 030 siempre rendirá mejor que un 020.

Motorola, durante todos los años que mantuvo los 68K en producción comentaba que "supuestamente" un 030 era mejor en términos de rendimiento, entre un 30 y un 50% más rápido que un 020 a la misma velocidad de reloj.

Las ventajas de los 68K en Amiga es que van acompañados de custom chips que liberan al Motorola de mucha carga que en otros micros ha de ser este quien realiza, penalizando en el rendimiento y en el caso del Amiga son todo beneficios debido a esto mismo.

Edito: Así no abro otro post y añado un enlace interesante: https://groups.google.com/forum/#!topic ... TJJJ-LYSm8

The following is a letter written by one of our architects to Electronic
Design. I thought that it would be interesting reading on the net and
would be good for creating some discussion.


MC68030 COMPARISON WITH MC68020

I read with interest the "Assessing MC68030 and MC68882 Performance" letter
from Roy Druian, Product Marketing Manager of Motorola, as well as Dave
Burskys "32-Bit Microprocessors 1987 Technology Forecast" in the Electronic
Design magazine of Jan. 8, 1987. Mr. Druians letter tried to demonstrate
that Motorolas 68030 at 20MHz has twice the performance of 68020 at 16.67MHz.
In Mr. Buskys survey, Motorolas 68030 is presented as having 3 times the
performance of 68020.

Using Motorolas own performance data for 68020 and the data available for
68030 (see bibliography below), I calculated the 68030 performance improvement
relative to the 68020. These calculations, presented in detail below, show
that the performance of 68030 is only 18% better than that of 68020 at the same
frequency (20MHz) even if we believe the high hit ratios Motorola claims for
its small (256 byte) internal caches.

Using the data presented by Motorola in [2], the calculated 68030 performance
is 3.3 MIPS at 20 MHz, while 68020 performance is 2.3 MIPS at 16.67 and 2.8
MIPS at 20MHz.

The other 68030 problems that Motorolas papers do not stress are:
-impossible timing for its synchronous bus protocol (very hard and
expensive to run with zero wait-states at 20MHz).
-virtual (logical) caches (see [1] for problems of virtual caches)
-lack of hardware cache invalidation for the internal caches, which
makes 68030 very hard to use in multiprocessing systems or where
external devices (eg. DMA) may change memory values
-long context switching time, because it has to save temporary data
inside the CPU (problem inherited from 68020)
-small TLB (Address Translation Cache) for the 68030 MMU (22 entries
only)

Actually 68030 has no real MMU, as the TLB misses are handled by the 68030
Execution Unit and not by the MMU itself, transparent to the execution pipe.
The high price of a TLB miss (because it is handled in microcode, serial to
the instruction execution), combined with the relatively low TLB hit ratio
(should be 90 - 95% for the 22 entry TLB and not 98% as Motorola claims)
makes the use of the on-chip 68030 MMU expensive in terms of performance.

68030 vs. 68020 Comparison

The improvements of 68030 versus 68020 consist of improvement of the Instruction
Cache hit ratio due to larger line size (16 bytes for 68030 vs. 4 bytes for
68020), addition of a small Data Cache and integration of the MMU on chip.

As for the "internal Harvard architecture", 68020 allows also the overlap of
instruction fetches with data operand access [3]. The 68030 left unchanged
the Execution Unit, except for the addition of some instructions to support
the TLB on chip [4]. As a consequence, the only change in the performance
model of 68030 when compared with 68020 is the improvement in the performance
penalty for addressing instructions and data in memory.

Using Motorolas own data (Table 6 in [2]), the average number of operand memory
access per instruction for 68020 are:
-0.384 reads per instruction
-0.242 writes per instruction

The Data Cache with 48% hit ratio and the 2 clock bus cycle will improve the
68030 execution time by:

0.384 * 0.48 * 2 + 0.384 * 0.52 * 1 = 0.567 clocks

where:
- 0.384 represents the average number of operand reads per instruction,
- 0.48 represents the Data Cach hit ratio,
- 2 represents the difference, in clocks, between 68020 going to
external memory (no wait states) and 68030 finding data in the
internal cache,
- 0.52 (1-0.48) represents the Data Cache miss ratio,
- 1 represents the difference, in clocks, between the 3 clock bus
cycle of 68020 and the 2 clock bus cycle of 68030.

The writes have roughly the same influence on performance for 68020 and 68030,
as the Data Cache is a write-through cache and writes are buffered by the BIU.

The other 68030 improvement is the higher Instruction Cache hit ratio because
of 16 byte line size (the effect of the burst is already taken into account
in the hit ratio of the Instruction Cache and Data Cache).

According to Table 4 in [2], the number of clocks-per-instruction for 68020
drops from 7.159 with a 64% hit ratio instruction cache to 6.373 with a 100%
hit ratio instruction cache (an improvement of 0.786 clocks-per-instruction).
The estimated improvement given to 68030 by its 82% hit ratio instruction
cache and its 2 clock bus protocol (no wait state) is 0.5 clocks-per-instruc-
tion.

The overall performance improvements due to the architectural improvements
of 68030 relative to 68020 is then:

0.567 + 0.5 = 1.067 clocks/instruction

According to Motorolas own calculations in [2], the average performance of
68020 with the Instruction Cache ON for the workload in [2] is 7.159 clocks/
instruction (Table 4 in [2]) when no wait states are present. This translates
into 2.3 MIPS at 16.67 MHz and 2.8 MIPS at 20MHz.

The (7.159 -1.067) = 6.092 clocks/instruction for 68030 translates into 3.3
MIPS at 20MHz.

The relative improvement in performance of 68030 versus 68020 at the same
frequency is then:

(3.3 - 2.8) * 100/ 2.8 = 18%

If the 16.67 MHz 68020 is compared against the 20 MHz 68030, the performance
improvement factor is still only:

(3.3 - 2.3) * 100/ 2.3 = 43%

68030 Synchronous Bus Timing

Even the 18% architectural improvements of 68030 versus 68020 is questionable
because of the way the 68030 2-cycle synchronous bus protocol is designed.

For a Read bus cycle, the 68030 issues the address at the beginning of the
first clock cycle and expects the system to return the ready signal (named
STERM) at the end of the same cycle. Data is sampled by 68030 in the middle
of the second cycle. According to the 68030 spec [6], the read bus timing at
20MHz is:

- Address-to-STERM time = 25 ns
- Address-to-Data time = 40 ns

For a Write bus cycle, 68030 issues the address at the beginning of the first
clock cycle, data at the beginning of the second clock cycle and expects the
system to return ready (STERM) at the end of the first cycle. According to
the 68030 spec, the write bus timing at 20 MHz is :

- Address-to-STERM time = 25 ns
- Write Data Valid time = 25 ns

It is hard to avoid wait-states at 20MHz with such timing even when using
the fastest and most expensive static RAMs. No wonder the Motorola is
unwilling to commit pushing 68030 beyond 20MHz; with the 68030 bus protocol
wait states are unavoidable.

Sorin Iacobovici
Computer and System Architecture
National Semiconductor Corp.
Santa Clara, Ca.

Avatar de Usuario
arananet
Mensajes: 135
Registrado: 23 Oct 2015 19:00
Agradecido : 75 veces
Agradecimiento recibido: 77 veces

Re: 【 X68000 】 DOOM

Mensajepor arananet » 11 Ene 2017 07:40

Mola y un juegazo, privilegiado el q tenga un x68000 :)


Volver a “Sharp X68000”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 3 invitados