SoloCodigo

lo de bienvenido a la programacion no es poque seas nuevo sino porque tenes que tomar las cosas con calma y hacer avances chicos

obvio que a todos nos gustaria escribir todo lo que vos decis pero ni siquiera se me ocurre empezar a escribir una linea de eso porque se que si lo empiezo ahora no va a funcionar  

lo de las cosas "simples" que hice no es sarcasmo es en serio nunca logre programar algo totalmente completo sino que hice cosas incompletas con el fin de aprender en el proceso despues de varios fallos y con un proceso "iterativo e incremental" (paresco mis profesores) se puede lograr algo pero la regla general es que si apuntas a algo muy alto de entrada nunca lo terminas....

espero ver avances tuyos por aca

si ya hiciste algo estaria bueno que lo postees

no es de amargo es que me ha pasado de encarar un proyecto muy grande y no llegar a nada y te da bronca

Interesante charla y solo acotar algo sobre programacion de graficos bajo DOS. Me refiero a que no se debe confundir el programar graficos utilizando el driver VESA para DOS con programar graficos utilizando la especificacion VESA. En el primer caso requiere de un driver, un archivo aparte. En el segundo caso tenemos el uso de una interrupcion (metodo lento) o el acceso directo a direcciones de memoria que en modos VESA depende del fabricante.  Por este motivo programar un juego en modos VESA sin driver era un dolor de cabeza porque tenias que buscar mil especificaciones de fabricantes para determinar las direcciones para sus respectivos modelos de tarjeta y encima marcas.

  Algo mas, programar con acceso directo a memoria grafica no es para nada lento.  Por el contrario, es lo mas rapido que existe puesto que estamos escriiendo directamente en los chips de memoria de la tarjeta grafica ¿Existe algo mas rapido? Posiblemente si, la telepatia, pero hasta alli no ha llegado la programacion  


saludos y si que preguntas ah,


Furious Logic [aRC]

Parece que no leiste con detenimiento lo que indique. Lo resumiremos así:
¿Desde donde lee los datos el GPU? Desde la memoria que lleva en la tarjeta. No hablo de la ram hablo de los chips de memoria que vienen en toda tarjeta grafica.  Esa es la forma mas rapida de escribir graficos.

Cuando deseamos enviarle datos al GPU, en el DOS en lugar de utilizar interrupciones utilizabamos escritura directa en memoria. Leiste la parte en que escribi "solo acotar algo sobre programacion de graficos bajo DOS".

Ahora bien, el tema bajo Windows es distinto y mas facil en cierto modo. OpenGL es un standard tan bueno que aun sigue en la version 1.x en tanto que DirectX ya va por la 10 y requiere instalar como 30 MiB para tener la 9.0c que tengo entendido que es la ultima. Bueno, no quiero destapar el tema de OpenGL vs DirectX porque de hecho se arma la discusion. El punto es que sea que uses OpenGL o uses DirectX, estas accediendo directamente al hardware.  Esa es la idea de ambas librerias y de alli mi comentario sobre la dificultad de la programacion bajo DOS-especificacion VESA vs los distintos modelos-marcas de tarjetas.  Es decir, que bajo windows, se intento evitar todo ese lio de averiguar marcas, direcciones de memoria particulares y todo ese rollo, y se crearon OpenGL por un lado DirectX por otro lado. Ambas se encargar de determinar la mejor forma de acceso directo al hardware. De este modo ya no tienes que preocuparte por averigual la informacion no documentada sobre en que direccion de memoria escribir si es la tarjeta Perico 8000, Coquito ABC o Fulano "Budú".  Simplemente le dices a la API si es OpenGL o al objeto COM si es DirectX que escriba un pixel y listo, asunto arreglado ellos se encargan de averiguar que es mas rapido.
Los fabricantes de tarjetas envian esa informacion a Microsoft que para nosotros en DOS era rebuscada, no documentada o como sea.  De alli que es improbable que al menos 1 compáñia te vaya a dar gratis su informacion privada. (Microsoft paga por esa informacion y paga en serio, aunque nos cobra mucho mas de lo que paga)

Volviendo a tu tema grafico. Tienes 2 alternativas: la primera es crear un kernel que base su parte grafica en la informacion que las corporaciones graficas te hagan llegar a ti.
La segunda es que hagas un kernel que base su parte grafica en los drivers existentes de Windows o en los de Linux.

Es un tema bastante complicado para que empiezes a crear algo. Es admirable tu emocion por crear algo asi pero de alli a la realidad, pues te diria que le des una miradita al codigo de un kernel, el mas simple que exista y a ver como vamos.

suerte y empieza por algo mas a tu alcance,


saludos,


Furious Logic [aRC]
www.arc3000.com
(SITE CENSURADO)


PD: Te sugeriria que leas la enorme cantidad libros que tenemos en la web pero nos censuraron hace tan solo 2 semanas. Si tienes paciencia, en un tiempo migramos todo a un nuevo servidor y alli podras leer libros de programacion hasta que termines pensando en binario y hablando en hexadecimal  

hola CodigoDavid

Solo ten presente que te han hablado con consejos muy practicos y queno han adquirido de la noche a la mañana...
muchos hemos sido los que hemos querido iniciar por la senda que pretendes ... para despues de un tiempo darnos cuenta que no ea la manera correcta de empezar...
sigue el consejo de los que ya han pasado por ahi...

cuando el rio suena...
piedras lleva.

Ok, lo que pasa es que a mi esto de utilizar librerias ya "prefabricadas" supongo que tambien tienen sus limitaciones, y entonces, si hay algo que quieres hacer pero no esta implementado en la API pero tampoco lo puedes programar directamente en el hardware por que el sistema no te deja que haces? no creo que hayga muchas limitaciones hoy en dia con la cantidad de cosas que tienen las API pero siempre hay excepciones..........................y mi mayor dificultad es que no se por donde empezar, supongo que primero seria estudiar la api de windows, y luego DirectX o OpenGL, pero, y mi talon de aquiles es el mega-ultra-super-bajo nivel de ingles que tengo y claro, cuanto tiempo cuesta aprender un ingles decente? 1 año? pffff...... y tambien me encuentro por internet algunos tutoriales que alomejor pone la descripcion por ejemplo de la estructura WNDCLASSEX asi:


"
cbSize
El tamaño de la estructura
style
El estilo de la clase (CS *), no confundirse con el estilo de la ventana (WS *). Generalmente este campo puede ser puesto en cero.
lpfnWndProc
Puntero al Window Procedure de esta clase.
cbClsExtra
Cantidad extra de asignación de memoria para datos de la clase. Generalmente cero.
cbWndExtra
Cantidad extra de asignación de memoria por ventana de este tipo. Generalmente cero.
hInstance
Handle a la instancia de la aplicación (la que obtenemos en el primer parámetro de WinMain( ) )
hIcon
Handle al ícono grande (32x32), mostrado cuando el usuario presiona Alt+Tab.
hCursor
Handle al cursor que será mostrado sobre la ventana.
hbrBackground
Pincel para fijar el color de fondo de nuestra ventana.
lpszMenuName
Nombre del recurso Menú para usar con las ventanas de esta clase.
lpszClassName
Nombre para identificar la clase.
hIconSm
Handle al ícono pequeño (16x16), usado en la barra de tareas y en la esquina superior izquierda de la ventana.
"

vale, ok, bien, pero para que sirve concretamente cbClsExtra? es que dice que es generalmente 0, vale, generalmente, pero por que no dice exactamente para que sirve? ami esta falta de informacion es lo que me "mata" en esto de la programacion................estos son en resumen con los problemas con los que me encuentro con el API de windows

Cita de: "CodigoDavid"

Ok, lo que pasa es que a mi esto de utilizar librerias ya "prefabricadas" supongo que tambien tienen sus limitaciones, y entonces, si hay algo que quieres hacer pero no esta implementado en la API pero tampoco lo puedes programar directamente en el hardware por que el sistema no te deja que haces? no creo que hayga muchas limitaciones hoy en dia con la cantidad de cosas que tienen las API pero siempre hay excepciones..........................y mi mayor dificultad es que no se por donde empezar, supongo que primero seria estudiar la api de windows, y luego DirectX o OpenGL, pero, y mi talon de aquiles es el mega-ultra-super-bajo nivel de ingles que tengo y claro, cuanto tiempo cuesta aprender un ingles decente? 1 año? pffff...... y tambien me encuentro por internet algunos tutoriales que alomejor pone la descripcion por ejemplo de la estructura WNDCLASSEX asi:

vale, ok, bien, pero para que sirve concretamente cbClsExtra? es que dice que es generalmente 0, vale, generalmente, pero por que no dice exactamente para que sirve? ami esta falta de informacion es lo que me "mata" en esto de la programacion................estos son en resumen con los problemas con los que me encuentro con el API de windows

Cuando quieras hacer algo muy especifico pensa en hacer un driver que se ejecute en modo kernel, por lo menos si queres que sea usado por mas de cinco personas en el mundo.

En cuanto a lo de la API lo lamento mucho pero tengo que decir que es tu culpa. Ese campo en particular esta explicado al detalle en la MSDN:

cbClsExtra
Specifies the number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.

¿Que significa esto? Este campo especifica el numero (cantidad) de bytes extra para reservar justo despues de la estructura de la Ventana. El sistema INICIALIZA los bytes a cero, eso quiere decir que la memoria esta toda puesta a cero, cada uno de sus bytes.
La ayuda que tenes dice que generalmente se inicializa a cero porque la gente o no necesita guardar variables de la ventana o utiliza otros metodos.

Realmente yo me saco el sombrero ante la MSDN y el DDK, si tuviera que programar en Linux con el man mi vida seria mucho mas complicada  

Sabes si la MSDN esta en español?

PD: Va ser que no.....

no me gusta empezar otro flamewar pero tampoco me gustan las injusticias,
comparar MSDN con el man es como comparar el notepad con openoffice ( para que no surja otro flamewar agrego: office es mucho mejor que openoffice pero con openoffice me sobra ).

el man es una simple documentacion sobre PROGRAMAS explicando su funcionamiento y los parametros que se le pasan con una breve explicacion.

queres las APIS:

la que usa gnome (gtk): http://www.gtk.org/api/
la que usa Kde (qt): http://doc.trolltech.com/3.3/
la de c para linux: www.srsplus.com/en-def-d82f4a834d85/ en/srsplus/api_c_linux.pdf
la de python: docs.python.org/api/api.html
la del kernel: kernelnewbies.org/documents/ kdoc/kernel-api/linuxkernelapi.html

y asi puedo seguir,m no te preocupes que uno de los fuertes del opensource es que hay documentacion de sobra  para las aplicaciones y librerias extendidas lo que pasa es que no estan en una sola pagina ( o si... en google ), te recomiendo esto

www.google.com
pone xxx API reference
www.google.com/linux
pone xxx API reference

y va a aparecer mucha documentacion.

la primera vez que lei la comparacion de MSDN  con el man la deje pasar, pero esta mal que a los que recien empiezan se los asuste con "el monstruo de linux"

que el man sea mejor que el MSDN es una gran mentira en eso concuerdo con vos

Mis dudas son unas "cuantas", y esque, estoy en estas:


(1)Quiero programar directamente el hardware, graficos, teclado, raton, sonido.

{
Estamos en que para hacer esto, de buen principio ni pensarlo de hacerlo bajo, por ejemplo WinXP por que simplemente protege la memoria asignandole una zona virtual de memoria a cada proceso y analizandola a su voluntad para que el proceso no acceda a zonas de memoria de otro proceso(problema numero 1), me direis muy bien, utiliza la API de windows y ya esta, pero yo digo, no esta!! por que no pienso utilizar esa API........no de momento, la solucion mas facil seria programar en entorno MS-DOS, pero tenemos el problema de la barrera de los 640 Kbytes, podria utilizar directamente el hardware y tal con las interrupciones, pero........... y si mi programa que haga ocupa mas de 640 Kbytes en memoria que?, ahy viene una duda/pregunta, aunque todos sabemos que MS-DOS tiene la barrera de los 640 Kbytes, y aun teniendo la memoria extendida su uso es muy limitado, como al fin y al cabo MS-DOS es un programa mas echo en ensamblador, hay alguna manera de poder utilizar toda la memoria disponible en el PC mediante algunas rutinas en ensamblador y tambien extender los 16 bits a 32 bits, superando asi las barreras, es decir, si yo tengo por ejemplo 512MB de memoria RAM fisica en el ordenador, pues poder utilizarlos todos y no 640KB solamente, igualmente el tema de la cantidad de bits, osea que aunque los programas de MS-DOS sean de 16 bits, de alguna manera yo puedo hacer programas corriendo en 32 bits aunque MS-DOS no lo sea mediante el apoyo de algunas rutinas de ensamblador? no pido que me digais como se hace, simplemente pido que alguien me diga si se puede hacer lo que yo he dicho o no, lo demas ya es trabajo mio.........,
}



(2)Programar graficos, pero nada de VGA ni SVGA, sino una GPU(si si, una aceleradora en el AGP)
{
aqui viene mi mayor duda, y es que por internet veo montones de tutoriales del modo 13h, que si VGA, que si SVGA, VESA 1.0 y 2.0, tenemos que:

VGA: 256 colores, caca de la vaca, no me sirve, no me conformo.........
SVGA: otro tanto de lo mismo.....
ESTANDAR VESA: 16 millones de colores y todo lo que tu quieras, pero tampoco me conformo por su lentitud

explicacion de por que no me sirve lo del vesa:

por la profundidad de color si me serviria, pero, imaginaros que tengo que hacer un sistema operativo como el windows, con 32 bits de color, esto es, 16 millones de colores, pero como imaginareis, ni de coña tendra la velocidad que tienen los graficos del windows, por que aunque alguien no lo sepa y aunque lo parezca, windows NO esta echo con vesa, ese sistema accede directamente al hardware, y en ordenadores modernos ya no estamos hablando de VGA ni SVGA si no de GPU o "Graphics Accelerated Unit", o lo que es lo mismo, targetas aceleradoras 3D de alto rendimiento, con procesador propio, algunas que llegan a tener 256MB de memoria de video GDDR3(la mia, una 6800GT........), y ahi viene el problema, veo un monton de paginas de los modos anteriores, pero todavia no he encontrado ninguna que hable de como acceder directamente a ese tipo de hardware, y mis preguntas son, ¿se accede directamente a la aceleradora 3D o tan solo al bus AGP?¿que interrupcion es la encargada del bus AGP o de la targeta aceleradora?¿cuales son las direcciones de memoria?¿que registros tiene el procesador(GPU) propio de la targeta aceleradora?¿alguien sabe el nombre de estos registros? pues eso, alguien sabe "algo" sobre el tema? por que, existir tiene que existir algo por c******, por que los sistemas operativos que existen como windows, no salen de la parrilla como por arte de magia..............................................e inevitablemente deben usar alguna "cosa" para realizar sus cometidos, "algo" que si ellos pueden utilizar programandolo en ensamblador y ese "algo" como por ejemplo una Nvidia GeForce 6800GT 256MB GDDR3 esta en mi ordenador, pues por c****** debo de poder programarlo yo de alguna manera utilizando ensamblador, ¿existe algun libro al respecto a poder ser en castellano?, recuerdo, que nada de APIS ni DirectX ni OpenGL ni nada por el estilo, empezando desde 0(programacion del hardware pura y dura.....)MUCHAS GRACIAS

me parece que hay un poco de confusion en el tema.

Si, si se puede programar la VGA y la SVGA, lo que falta es informacion sobre los registros . un driver propio en ASM no suele ocupar mas de de dos mil o tres mil lineas e incluso menos si solo queremos algunos modos graficos.

hay un libro bastante antiguo PC INTERNO 5 que muestra como crearnos nuestros driver graficos tanto en ASM ,C y PASCAL.
el código fuente no suele pasar de cien lineas en asembler para modos graficos en concreto. de todas maneras no profundizan mucho y lo que puedas obtener será de los codigos fuente,que por supuesto están en ingles.

Suelen partir de una idea tan basica como iniciar el modo primitivo mediante el bios , para que este haga el trabajo sucio por ejemplo 640x480 16 colores , y mediante manipulacion de registros propios de VGA pasarlo a 256 colores o mas.
hay quien se atreve desde cero pero para eso se necesita conocer donde se toca -

- Aviso de que te puedes quedar sin monitor al forzar la frecuencia del mismo.
de echo estube practicando bastante con los registros aleatoriamente y fue la primera vez que vi al monitor generar ruidos- curioso- ,no me lo cargé pero duro poco aquel monitor - casualidad?-.

de este mismo modo se crean los tan famosos modos  chain X hasta 320x400x256 colores , tener en cuenta que en el libro no mencionan las SVGA solo las VGA , estos registros tienen que ser compatibles hacia abajo osea que siempre estan ahí.

yo estube practicando con modos 640x400 y 800x600 y 1024x768 pero en estos últimos modos, habia problemas con la visualizacion del raton , al final lo dejé todo porque aunque sigas los ejemplos al pie de la letra hay cambios bastante decepcionates cuando cambiamos de tarjeta grafica, o dicho de otro modo lo que programaste para una ya no vale para otra salvo si vas probando con bastantes numeros para el mismo modo graficos. un ejemplo del libro para 800x600 es ir probando con llamadas bios con varios numeros supuestamente estandar , algo parecido a lo que hace el windows cuando cambia el modo grafico , y te pregunta si lo puedes ver correctamente.

creo que se puede programar los modos graficos partiendo del bios y usar drivers propios , estoy en ello , lo que pasa que en internet y en español no pasan del modo 13h.
parece que internet hay algo de TABU sobre la manipulacion de las SVGA ni el propio google se atreve - ¿SVGA? quizas quiso decir pasar del tema -

Para el resto de las preguntas usa dow4gw dos en modo protegido , el resto de tus dudas es facil de encontrar en internet .
crear un S.O desde cero creo que deberias ver algo de linux que muestran el codigo fuente .

Aun asi es una tarea bastante ardua para una sola persona , y el probema no es saber programar ni el tiempo que haga falta para ello , si no la falta de informacion.

ahi van un par de paginas para "empezar" eso si en ingles, no te pierdas por que hay de todo.
si consiges algo no dudes en comunicarlo .

http://textfiles.tqhosting.com/programming/
http://geocities.yahoo.com.br/conexaopcpc/...os/Hardware.txt

saluDoS  

me parece que hay un poco de confusion en el tema.

Si, si se puede programar la VGA y la SVGA, lo que falta es informacion sobre los registros . un driver propio en ASM no suele ocupar mas de de dos mil o tres mil lineas e incluso menos si solo queremos algunos modos graficos.

¿Que confusion? Solo para empezar estas respondiendo a una pregunta de hace seis meses y dos pagina atras ...

VGA, SVGA, VESA ya fueron programados por varios de los que participamos en este hilo. Un driver para Windows no se suele hacerse en assembly, es mas, Microsoft jamas lo certificaria.