He leido sus post, y se escucha muy interesante lo del SO, me gustaria participar pero realmente soy nuevo en esto de ensamblador, ahora trato de hacer un SO para un trabajo de la universidad, pero debido a sus comentarios he quedado con una duda ¿que diferencia hay entre TASM, NASM y FASM?, cual es mejor, cual debo usar?.
si llegamos a empezar el proyecto la eleccion yo la haria entre NASM y FASM por cierto.
Retomando lo de menuet OS..creo que seria un mal horizonte para el proyecto, ya que menuet puede tener muchas cosas buenas a nivel de programacion y que seguro merecen un reconocimiento pero en mi opinion no tiene nada de sistema operativo aunque cuente con cosas que lo hagan ver asi.Menuet en efecto fue desarrollado totalmente en asm, lo cual aunque parezca heroico es una trampa mortal para el desarrollo progresivo de un sistema operativo ya que cualquier mejora que se haga en codigo incluso para hacerlo portable de una maquina a otra o para modificarlo y hacerlo compatible con nuevas funcionalidades de los procesadores... termina siendo una tarea bastante dispendiosa y costosa.Solo deberia ser desarrollado en ensamblador una parte muy pequeña del nucleo que seria la que implementaria una especie de RTL y otras funcionalidades básicas y la cual podriamos llamar una HLA.Una alternativa para no desarrollar un sistema en ensamblador es lógicamente desarrollarlo en algún lenguaje de programacin de más alto nivel... seguramente lenguaje C y despues C++, pero esto implica tener un compilador lo cual facilita mucho el asunto ya que si se necesita generar un ensamblado con caracteristicas diferentes o que genere código de maquina de una manera diferente pues simplemente se cambian los parametros del compilador , se recompila y ya.Alli surge otro problema y es que solo hay dos opciones:1- Crear un compilador nativo para el sistema operativo2- Usar un compilador que ya este hecho en otra plataforma y adecuar el sistema para interpretar ese ejecutableLa primera es la opcion más optima creo yo o al menos seria la que mas me gustaria, pero demanda muchisimo más tiempo ya que la sola creacion de un MUY BUEN compilador podria tomar años, la segunda es más rápida pero implica desarrollar de acuerdo a un estandart ya establecido, es decir si se decide usar el GCC habria que ir pensando en desarrollar el conjunto de llamdas del estandart POSIX.
- Pre-emptive multitasking, multithreading, ring-3 protection- Responsive GUI with resolutions up to 1280x1024, 16 million colours- IDE: Editor/Macro Assembler for building kernel and applications- TCP/IP stack with Loopback, PPP & Ethernet drivers- Network applications include ftp/http/mp3/smtp servers,- irc, http, nntp and tftp clients- Free-form, skinnable application windows- Hard real-time data fetch- Fits uncompressed on a single floppy
Otra alternativa que propongo es que en vez de seguir con POSIX creemos nuestra propia interfaz (tal como Windows) y ya que estamos soportemos algun File System como FAT/32 y COFF. Lo mas interesante de esto es que construyendo un enlazador ya podriamos generar un ejecutable propio apartir de codigo compilado en Windows (VC++, gcc, etc).
Dudo muchisimo de que vayamos a desarrollar un compilador, ciertamente es la mas (sic) optima pero creo que lo mas interesante seria tener ALGO funcionando y no diseñar un nuevo Linux/Windows que nunca logremos implementar. Practicamente estas hablando de lo que queria hacer CodigoDavid con las tarjetas graficas y le dijimos que no se apurara tanto, no podemos pretender diseñar un File System propio, un compilador, un kernel y demas, al final fracasariamos estrepitosamente y no lograriamos tener nada tangible.
Realmente no opino lo mismo, como bien lo dije tiene cosas que lo harian parecer a un sistema operativo pero realmente, ring-3 protection ya viene implementado desde el procesador y por ejemplo sistemas operativos antiguos como por ejemplo DOS no poseian multitasking, multithreading y aun asi eran sistemas operativos, más que por cuestiones de funcionalidad visibles primera vista, no lo considero un sistema operativo es por cuestiones de diseño y mas de fondo que la funcionalidad tangible del programa. Pero creo que ya dejamos ese tema ahi porque seria ubicarlo mejor en otro post.Si claro, lo del gcc era solo un ejemplo porque de hecho si se quisiera hacer algo que funcionara con codigo para mac o para as400 o cosas asi pues igualmente seria viable.Ya les dejo a ustedes como deciden hacerlo, pues logicamente las condiciones cambian si se pretende hacer un SO ASM por ser el foro de ASM, o si se quiere hacer un SO independientemente de la tematica ppal del foro.Ahora si ponemos a volar la imaginacion ( de manera segutramente descabellada o soñadora a extremo) se podria inicialmente utilizar el formato ejecutable de otra plataforma ( linux , windows) y hacer una especie de subsystem para soportarlo, y si todo se diseña y planea de la manera adecuada se podria continuar luego que ya este funcionando, con la creacion del 'subsystem' propio del sistema e implementar los demas subsystems con llamdados al subsystem nativo. tal como lo hace windows, eternal me corregira sino es posible de ese modo.El sistema en el cual estoy(o estasba) participando en la U, lo habiamos comtenplado para hacer lo usando otro ejecutable y a futuro crear un formato ejecutable y un conjunto de lladmas propio tal como se los he propuesto.
Hola, es mi primer post y soy algo novato en asm, estoy trabajando en este proyecto y lo que no logro comprender bien es como escribir en el diskette, entiendo lo del sector 0, y cargar en memoria 7C00, pero me he encontrado con que aparentemente hay que escribir ceros y unos, o un .bin, en realidad no comprendo como, vi el ejemplo aki mostrado (el de BOB) pero lo que necesito saber es como funciona el COPYBOOT.EXE, y tengo la misma duda de otro colega que preguntaba por los parametros, gracias a quien lea esto!