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 4 ... 6
16
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.

17
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.

18
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é.

19
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é.

20
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/

21
Programación / Re:Debuggear paso a paso en un C64 real ¿ES POSIBLE?
« en: Febrero 18, 2018, 19:30:30 »
Seguramente se puede hacer pero me parece que hace falta hard adicional.
Yo tenía un entrenador de 6502 que lo hacía, pero el 6502 tiene todos esos Pines 'que nadie usa' que no tiene el 6510 porque tiene los seis pines del puerto 0 y puede que sin ellos no se pueda saber en qué paso de la instrucción se está.
Hace mil años, ese entrenador leía las señales de control del procesador y lo paraba a cada paso usando la MMI, creo recordar.
El circuito eran un par de puertas hábilmente colocadas.

Enviado desde mi Redmi Note 4 mediante Tapatalk

22
General / Re:MINORITARIO MIS COJONES!!!
« en: Enero 18, 2018, 08:23:13 »
Después de la época de los ocho bits, la inmensa mayoría fuimos directamente al PC. Algunos se fueron al Atari st y pocos al amiga. Al final casi todos acabaron en PC.
Bueno, una excepción. Un amigo tenía un Mac modelo 1 con 128kB desde el 85 o así . Era de 110V importado directamente de gringolandia. Curiosamente este sujeto luego se pasó al PC. Luego significa ya con W98 o así, no pasó por el DOS.

La etapa Amiga la vi de lejos. Y echo de menos no haberme metido en ese lío.

Enviado desde mi 5056D mediante Tapatalk


23
General / Re:MINORITARIO MIS COJONES!!!
« en: Enero 15, 2018, 08:22:23 »
No estoy pontificado, solo cuento mi experiencia.
En mi instituto y entorno próximo no había nadie que yo conociese que tuviese un commodore. Spectrums había legión, y amstrad media legión, Msx unos pocos.
Nunca tuve datassette así que nunca cambié una cinta.
Solo intercambié algunos discos por correo con uno de no me acuerdo dónde que se puso en contacto conmigo a través de commodore word a raíz de alguna carta que mandé o algo así.
Puedes creerlo o no, eres libre, pero en la práctica no conocí a "nadie". Había un vecino con un c64 que creo que ni lo sacó de la caja prácticamente.
En el 87 me fui a estudiar a Valencia a la UPV lo mismo, había un club de usuarios de amstrad. Si lo hubo de commodore no lo conocí. Por aquella época ya me cambié al PC y de eso todo el mundo tenía de todo, abandoné la plataforma C=.
Puedes acusarme de poco sociable por no buscar mas commodorianos en mi entorno y probablemente tengas razón, pero obviamente tampoco busqué usuarios de spectrum ni amstrad ni commodore y los encontré porque estaban ahí, al lado mío. Los usuarios de commoodore no estaban.

25
General / Re:MINORITARIO MIS COJONES!!!
« en: Diciembre 13, 2017, 18:06:44 »
En mi entorno solo yo tenía commodore. Habían 15 spectrums y un par de amstrad.

Si que era minoritario.

Enviado desde mi 5056D mediante Tapatalk


26
Los zener van en continua, no en alterna.
Si es raro que se estropee un 7805 y de más tensión, es aún más raro que lo haga un transformador. Mucho pero que mucho más raro.
Normalmente cuando se rompe algo se corta, no se cruza, con lo que la salida de tensión es cero.
Para el resto de casos un zener + fusible vale. El zener solo tiene que sobrevivir el tiempo necesario hasta que se funda el fusible. El resto del tiempo no hará nada.
Eso solo pasará si el 7805 muere en cruce y deja pasar la continua sin estabilizar que serían unos 9V. Creo que seo solo pasa una de cada mil veces que se rompe un 78xx y los 78xx se rompen poco.
En cualquier caso no está mal un circuito de protección porque hay chips muy difíciles de reemplazar, no porque sea común.
No es que esté mal el circuito del tiristor, es que no aporta mucha ventaja y es más conplicado, y sobre todo caro.

Enviado desde mi 5056D mediante Tapatalk


27
Commodore PET / Re:Superficies de revolucion
« en: Septiembre 30, 2017, 15:42:05 »
Ya no me acuerdo si fue en commodore world o en commodore magazine, habia in programa en basic que dibujaba cualquier cuerpo de revolución en hites. Cosa no trivial ya que como sabéis todo iba con pones por culpa del cutrebasic V2

Enviado desde mi 5056D mediante Tapatalk


28
¿De verdad hay tantos problemas de sobretensiones?
Llevo toda la vida haciendo mantenimiento de equipos electrónicos y con los dedos de una mano ma sobran para contar las veces que me ha pasado.

Con un zener de 5V1 de 1W , y un fusible sobra. 1€ echando por lo alto.



Enviado desde mi 5056D mediante Tapatalk


29
General / Re:c64 MINI - Anunciado
« en: Septiembre 29, 2017, 21:02:23 »
Yo que se, si las teclas son de pega... Que no las pongan.
Si las ponen que funcionen.

Enviado desde mi 5056D mediante Tapatalk


30
Problemas Hardware y Software / Re:Ventilación
« en: Agosto 27, 2017, 12:13:42 »
Pues entonces has hecho mal en quitar la chapa, creo yo.
Al menos en el 128 iba de cine.

No sabía que también habían 64s con esa chapa.



Enviado desde mi 5056D mediante Tapatalk


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