Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Scooter

Páginas: [1] 2 3 ... 6
1
General / Re:Commodore P500
« en: Enero 01, 2019, 10:17:30 »
Eso era la serie profesional de CBM, habían varios modelos e incluso habían con coprocesador 8088 y cosas así.
Decían que la carcasa era diseño de Porsche pero se ve que no era verdad.
Se supone que eran profesionales y tal pero un 6502 a 2MHz no daba la talla frente a los PCs.
Yo sí que los recuerdo de verlos en publicidad y cosas así en los 80.
Eran caros de narices.
Se vendió entre poco y nada.

2
Commodore 128 / Re:Commodore 128D
« en: Agosto 03, 2018, 20:47:40 »
En realidad más que restauración es limpieza en este caso porque no toca un circuito.

3
Fuentes de alimentación / Re:Reparación de fuente de C128
« en: Agosto 01, 2018, 15:31:01 »
Yo juraría que todo era made in USA.
Pero al 100% no lo puedo asegurar.

4
Fuentes de alimentación / Re:Reparación de fuente de C128
« en: Agosto 01, 2018, 11:23:10 »
No tengo mi c128, lo regalé hace décadas cuando no valoraba lo retro.

Era PAL, comprado en Alicante en una tienda que se llamaba Micro Centro. Era la versión internacional, no tenía ñ ni tildes.
Fue de los primeros, lo compré a los pocos meses de estar disponible porque mi c64 falló y tardaron un despropósito en repararlo.
La fuente era cuadrada, más grande que la del c64, pesaba menos de la mitad y permanecía absolutamente fría por más que se usase durante horas, por eso me atrevo a asegurar que era conmutada.

5
Fuentes de alimentación / Re:Reparación de fuente de C128
« en: Julio 31, 2018, 23:29:59 »
Yo hubiese jurado por lo más Santo que la fuente de mi C128 era conmutada porque ni pesaba ni se calentaba. Eso sí, era bastante grande.

Si fuese mi caso creo que la vaciaría y la sustitutoria por una fuente comercial de calidad que entrase en la carcasa, hay opciones muy económicas y de calidad industrial que aguantan carros y carretas.

Yo no sería purista en la fuente, y si lo fuese, la guardaría y compraría el dichoso conector ese más una fuente para el uso diario.

6
General / Re:Raspberry PI C64!!
« en: Julio 28, 2018, 09:33:41 »
Si, con un Arduino 0 problemas. Yo tengo un teclado de Oric Atmos con un Arduino enchufado por USB a la rPI (o a un PC, porque es un teclado de PC al final) yo lo decía por eliminar el Arduino habiendo pines.

7
General / Re:Raspberry PI C64!!
« en: Julio 25, 2018, 21:44:28 »
Deberían de hacer algo para conectar el teclado y los joysticks a los pines de la raspi. No debe de ser muy complicado.

8
El problema del 'se desconectan' es que efectivamente no se destruyen pero por ejemplo puede dejar loco al VIC porque le sigan llegando los 5 y no los 12 o viceversa. Cuando se enfrían vuelven a ir hasta que se calientan lo que puede generar un vaivén que te vuelva loco o acabé rompiendo algo.

Hay equivalentes pin a pin conmutados que no se calientan, pero no sé si meterían ruido eléctrico. Habría que probar.
Muchos usuarios de spectrum Cambian el 7805 por uno conmutado y les va bien.

9
Tiene toda la pinta de ser una M bien grande de onda cuadrada patatera.
Si va correcto con onda cuadrada, entonces es sencillo tirando a tonto hacerlo.
No sé por qué pensaba que era necesaria senoidal.
Si va bien con onda cuadrada eso se hace con la gorra.
¿Habéis probado esa placa y va bien?
¿Podéis verificar que es onda cuadrada? Tiene toda la pinta.

Ya puestos..  ¿Es necesario que sea de 50Hz?
Incluso¿Es necesario que sea AC?
¿Que es lo que alimentan esos 9Vac?

10
Son ideas peregrinas.
Una fuente conmutada de calidad es igual de segura que una lineal...de calidad.
Una fuente lineal mala es igual de insegura que una conmutada mala.

Una lineal es mucho más sencilla, mucho más voluminosa y mucho más ineficiente. Todo eso al revés en una conmutada.

Eso sí, los 9Vac son casi imposibles de obtener con algo que no sea un simple transformador. Se podrían generar a partir de una fuente de 24Vcc pero sería una complejidad innecesaria en mi opinión.

11
Commodore Amiga / Re:Amiga cbm
« en: Mayo 12, 2018, 21:46:38 »
CBM es Commodore Business Machines.
Lo que pasa es que esas siglas son más bien de la era del PET que de la era Amiga, pero bueno.

12
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 05, 2018, 22:35:08 »
Pues a lo mejor es un lío que te mueres pero...
Hacer una rutina de movimiento que mueva las variables de dónde se encuentra el Sprite pero no escriba los registros hasta que pase el raster para evitar posible flikeos, que salga repetido un Sprite por moverlo a una posición que está detrás del raster cuando ya había salido.
En los movimientos que no se realizan se hace una verificación por software aunque sea "de caja", o "de núcleo" mientras que en la que si que se pinta se hace caso a la interrupción.
Quizás la interrupción del raster pueda servir de reloj para controlar las velocidades de los movimientos.

No tengo claro que esté esquema sea más rápido o no. Lo que está claro es que complica el código pero puede que deje más tiempo libre ya que solo escribes en el VIC cuando avisa el raster y el resto del tiempo lo tienes par todo lo demás.

Para juegos lentos con la interrupción vale pero para los rápidos está claro que sí o sí hay que hacer algo por software.

13
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 05, 2018, 14:55:24 »
Si mueves tres veces un Sprite entre raster y raster es un esfuerzo inútil porque solo se verá el último.
¿En serio se dispara la colisión en el mismo punto de la colisión o al terminar el cuadro?
Lo digo porque puedes tener dos sprites colisionando y un pixeles más allá otra colisión lo que llevaría a dos interrupcciones demasiado juntas en el tiempo.
Algo pasaba que efectivamente se perdían colisiones.
Me suena que la solución era mover los sprites solo en el tiempo del margen; poner una interrupción del raster en la línea 200 o 200 y poco de la pantalla, nada más terminar y entonces mover lo que sea.
Claro que eso llevaría a que si se refresca 50 veces por segundo limitas mucho la velocidad ya que en recorrer los 200 en vertical o los 320 en horizontal, tardas más de un segundo. Si saltas de 5 en 5 pixeles y la bala tiene 4 pixeles... Te lo puedes saltar. (Bueno, en realidad la suma de los anchos de los sprites...)
Pero claro, es que es tontería pintar más de un movimiento por barrido porque no se va a ver. Dependerá entonces de si es más fácil discriminar para solo pintar uno por barrido o pintar todos igual sin pensar, pero en ambos casos no funcionaría la colisión hardware.
Quizás una técnica mixta funcione bien. No sé.

14
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 05, 2018, 08:18:11 »
Uff, recuerdo haber leído artículos en Commodore World al respecto.
Creo que tiene que ver con el raster, que solo detecta las interrupciones cuando pasa o algo así.
Si los sprites van lentos seguro que pasa pero si el movimiento es rápido no, eso o que detecta en el segundo paso del raster despues de mover el sprite, algo había que lo hacía casi inútil en juegos rápidos.
Creo recordar que ya entonces abogaban por una rutina software.

La ventaja es que la interrupción hardware si que aplica la forma del Sprite mientras que una software sencilla es aplicar formas de caja. Hacer el análisis de si dos formas complejas se tocan o no es trabajoso.

Tiene sentido si pensamos como debe de funcionar, habrá un contador que va pasando por cada bit del bitmap o de la ROM de caracteres y pintando píxeles en la pantalla, mas o menos eso es el raster. Al mismo tiempo comprueba si en esa posición hay un sprite activado y entonces pinta el pixel del sprite en lugar del bitmap o caracer, pero si hay varios entonces pinta el de mayor prioridad y activa la interrupción. Algo pasa que la interrupción no se activa en ese momento, lo mismo se activa al terminar el cuadro para que no bombardee a interrupciones si al lado hay otros dos sprites colisionando. Si cuando termina el cuadro los sprites se han movido y se genera la interrupción y cuando vas al registro a ver cuáles están chicando, como ya no chocan no lo ves. Eso o que directamente no salta la interrupción si al acabar el cuadro los sprites ya no colisionan.

Me suena que la solución era poner una interrupción del raster Al final de la pantalla y solo mover sprites después de haber pintado toda la pantalla y haber atendido a todas las posibles colisiones. Eso además evita posibles parpadeos si da la casualidad de que mueves un sprite a mitad de pintarlo.
Eso también implica que si usas el raster para mostrar mas de ocho sprites a la vez en pantalla o sprites en los bordes ya no puedes usar las colisiones por hardware, o en todo caso solo podrás usar las de la última sección de la pantalla.

Espero no ser del todo inexacto y no haber 'desinformado' porque hace treinta y cinco años desde que leí el artículo y nunca lo apliqué.

15
No estoy muy puesto de lo que hace o deja de hacer una 6526 pero me parece que se podría emular con una cia 6520, via 6522 o riot 6532 estándard más algo de lógica adicional.
¿Hay datasheet detallado del 6526?
¿Se sabe exactamente que propiedades emplea el commodore y cuáles no? Se me ocurre que por ejemplo se pueda perder el puerto serie del user port qué casi nadie usa.

6520 y 6522 hay a mares por ahí.

Edito, parece que todos están aquí.
http://6502.org/documents/datasheets/mos/

Páginas: [1] 2 3 ... 6