วีดีโอ

Na linha 6 vai dar erro. O kernel.asm lá no final tem que ser kernel.bin. Troca a extensão. Ele monta do .asm para o .bin. (arquivo binário). No vídeo também eu mostro montando os arquivos na pasta Binary/, no seu caso, os seus arquivos serão montados na pasta raiz do projeto, já que você não colocou "Binary/".

@@rafa_cartoons Aí eu tenho que saber se você está colocando certo as instruções. Quando der o erro no arquivo, coloque aqui nos comentários o código completo que você escreveu e o tipo de erro que apresentou no CMD, aí eu vou avaliar as linhas que você escreveu e o nome do arquivo que apareceu no CMD dizendo onde estava o erro, aí te falo o que tem que corrigir. Outra dica: Se você quer de fato desenvolver e ter tudo certinho, não tente compilar os códigos das próximas aulas até corrigir o erro nas aulas anteriores, se não você não consegue desenvolver. Eu vi que você ainda não corrigiu os erros anteriores e tentou colocar novos códigos.

@@KiddieOSCommunity coloquei assim ECHO OFF cls echo Montando arquivo "bootloader" nasm -f bin bootloader.asm -o bootloader.bin echo Montando arquivo "kernel" nasm -f bin kernel.asm -o kernel.asm pause

@@rafa_cartoons Eu respondi o outro comentário que você colocou esse código. O erro ta aí no 2ª nome "kernel.asm", é kernel.bin.

@@rafa_cartoons Este é um erro no arquivo boot.asm, olhe na linha 16. Está dizendo que tem um erro de expressão na sintaxe. Responda essa comentário aqui colocando o que você colocou lá na linha 16 desse arquivo.

@@KiddieOSCommunity HelloWorld:

@@rafa_cartoons ?? Só isso? E o que tem uma linha antes e uma linha depois dela?

@@KiddieOSCommunity Agora já consertei o bug

Qual é a mensagem do erro exatamente? Pode me enviar?

@@antoniohenriquefigueiralou9771 🤣🤣 Eae, não não, na verdade no curso não trabalho com Diskette. O sistema é focado inicialmente em pendrives, igual Linux live... Acho que eu tinha dito em relação a Diskette porque o formato de bootloader e disco era RAW, sem formatação de arquivos, pelo tipo de imagem ser .IMG, era o tipo usado em Diskettes no passado, mas é completamente compatível com pendrives. No entanto, em uma certa parte do curso pra frente, eu abandono o formato raw .IMG e passo a trabalhar com .VHD, tornando compatível sistemas de arquivos maiores, como o FAT16 pra frente. O VHD você pode bootar direto na máquina virtual da Oracle, sem precisar de pendrive. No QEMU você já tem a possibilidade de usar diretamente também, mesmo sendo IMG. Só introduzi essa forma de IMG no curso pra habituar a galera que tava iniciando em OSes de como as coisas eram feitas no passado, pra depois ir elevando o nível pra forma mais recente. No entanto, quero poder atualizar mais os conceitos neste curso.

@@KiddieOSCommunity bastava omitir a referência ao dito cujo e se referir apenas ao pen-drive.

@@antoniohenriquefigueiralou9771 Pensei em omitir, mas assim, o sistema inicialmente é compatível com disquete e começou nessa perspectiva. Tem pessoas que preferem não usar o seu PC real e usar um PC antigo para se desenvolver um sistema operacional, ainda mais quando fazemos todo em Assembly, já que há uma chance de danificar o seu computador se fizer as coisas da forma errada. O Assembly ele tem acesso direto ao hardware e no modo real você é livre pra fazer qualquer coisa, isso aumenta e muito as chances de danificar seu computador. Por este motivo, muitos tem medo de usar o hardware mais moderno de utilização. Claro que tem a máquina virtual pra resolver esse problema, mas a máquina virtual fere o desempenho real do S.O. E aí, ficamos naquele dilema: "Eu quero usar o hardware real, mas não o meu PC de utilização, quero usar um PC mais antigo que não uso aqui". É neste cenário que alguns optam por disquete. Vou dar um exemplo: O MikeOS, que é um sistema operacional de 16-bit para disquetes com FAT12 e que ainda tem uma comunidade bem ativa criando aplicações BASIC. A missão desse curso, foi possibilitar que a galera use o S.O para um disquete em um PC antigo em modo real 16-bit, mas que não fique só limitado a isso. Que possa também rodar em um pendrive e fora dele (diretamente pelo VHD). Então não dava pra omitir, porque há essa possibilidade. Quem quiser usar o hardware real moderno, sem problemas, fica a critério de quem tá fazendo o curso. Pode-se ver que no início do curso usamos o programa FergoRaw, e ele automaticamente transforma o seu pendrive em uma capacidade de disquete, o modelo de trilhas, setores, até porque FergoRaw era usado para disquetes. Igual o exemplo que dei do MikeOS, quem optasse por fazer o curso e quisesse seguir na mesma trilha que o MikeOS, e não quisesse usar um PC moderno, usaria um PC mais antigo, com suporte a Disquete.

@@Mimamu_Nueskuro Então Man, daria sim, é super possível, no entanto, é extremamente trabalhoso. No caso, a engine facilitaria mais para criar games. Se você quer criar uma engine pra desenvolver SOs, eu super apoio pois é uma idéia bem legal. Esta pode ser uma das minhas metas e ambições (veja no meu canal o compilador Plax, ela pode ser utilizada exatamente para isso).

Para OS, na primeira vista, não, não é necessário. Pode começar a desenvolver um OS bem legal com pouco conhecimento em Assembly ou C, ou pelo menos, um conhecimento "base" de programação nestas linguagens. A medida que você for avançando, automaticamente o seu interesse por engenharia reversa será natural, porque vai ser um complemento de OS, até porque vai te ajudar mais tarde a desenvolver loaders de aplicativos e compreender como as aplicações de software funcionam, mas neste primeiro momento, engenharia reversa não é obrigatório.

@@KiddieOSCommunity Show de bola!! Me interessei mais ainda. Obrigado pelos cursos.

Olá Saulo, fico feliz por você querer entrar na área. Então, a questão de mercado, C e Assembly não é concorrido, na verdade, quase não tem vaga. E quando tem, são poucas vagas em áreas bem específicas pagando um valor absurdamente alto. Logo, são profissionais caros, porém com pouca oferta e pouca demanda. Se você quer iniciar essa jornada de sistemas operacionais, programação Assembly e C, te indico não pensar muito em mercado/dinheiro, mas pensar mais no contexto científico e de aprendizado.

Fico muito grato por isso, por você gostar do conteúdo desse canal! De fato, são tipos de aulas muito raras de se encontrar, ainda mais em canal BR. Em canal gringo costuma encontrar mais desse tipo.

Opa, fico feliz por ter ajudado!! :D

Valewzão friend! Maneiro que gostou!

Sim, inclusive estas são uma das minhas intenções: Criar APIs para o KiddieOS e uma linguagem de programação nativa do Kid.

Sim, BÁSICA mesmo kkk o próprio nome já diz. A sigla significa outra coisa, mas até eu achava que o significado era este rs. Pois é, o basic mais antigo é aquele bem simpleszão mesmo, quando o Bill Gates escreveu para os computadores Altair 8080, antes do Windows nascer ali. Mesmo assim, tinha muitos comandos legais, até hoje dá pra usar umas IDEs aí pro Basic e criar algumas aplicações maneiras. Depois que o Windows nasceu, o basic virou Visual Basic, abreviado como VBS, e ganhou outra forma, com aplicações ainda mais avançadas. Sobre projetos, minha missão é rodar os jogos do MikeOS, aliás, esse interpretador basic veio de lá, só estou refatorando e "portando" pro KiddieOS, ou seja, compatibilizando toda a API do MikeOS para o KiddieOS e eu poder rodar todos os programas do MikeOS, são programas bem legais. Vou mostrar pra você lá no Discord um dos jogos que eu já consigo rodar aqui em basic, o advnture.bas.

@@KiddieOSCommunity Sim, eu já fiz uns projetos em Basic, é bem simples, é um bat2.0, não sabia que era tão antigo assim! Manda lá!

Ela vai vir nativa, assim, a linguagem em si é interpretada pelo programa basic.bin, que futuramente se tornará o basic.exe. Este é o interpretador basic, logo se a pessoa excluir este programa do KiddieOS, ela pode, mas aí ela não vai rodar os jogos e aplicações em basic. Os jogos basic vão ficar na pasta Users\...\Apps\, onde '...' é o seu usuário. E aí o usuário vai poder criar seus próprios jogos e também modificar os existentes, já que é código-aberto. Mas o basic será só um entre vários interpretadores que pretendo ter, exemplo: Klang - O interpretador do KiddieOS.

@@CrazyDatabyteOne Valeu friend, que bom que gostou! 😊

@@CrazyDatabyteOne kk dei uma remodelada nos vídeos, fazendo coisas novas! Decidi aparecer.. 😅

@@KiddieOSCommunityLegal mano!

Muito obrigado meu amigo por gostar do sistema!

Teria como vocé me dizer se tem como fazer um so no termux pelo celular

Olá Gsouza, já tem um tempinho que não entro aqui, mas estou vendo seu comentário agora. Então, é uma questão que não posso te ajudar muito, mas pra facilitar, eu gostaria de saber como você ta tentando imprimir estes caracteres. Tem como me enviar um código exemplo aqui? Possa ser que de fato o código tenha algum erro que esteja substituindo o valor de backcolor, aí teríamos que investigar no código. Porque assim, qualquer caractere que tiver em AL e você usar as funções certas, ele vai ter o fundo e o texto... Existe outra forma também, que na verdade é usado em 32 bits, que no caso é usar a memória de texto diretamente para escrever dados no monitor. É o endereço 0xB800:0x0000. Ou 0x000B:0x8000. Cada caractere na tela deste endereço contém 2 bytes: 1 byte para a cor e o outro byte para o caractere ASCII. Então você usa o mesmo formato de fundo-texto, tanto em binário ou em hexadecimal, pra colocar no 1ª byte do endereço e o 2ª byte você coloca o caractere ASCII e aí você consegue até colorir cada caractere individualmente desta forma se você quiser. É só escrever um loop que salta a cada 2 bytes escrevendo a cor (Se caso quiser alterar só a cor dos caracteres sem apagar os caracteres). Tenta usar desta forma como uma alternativa pra ver se resolve, aí o caractere que retorna em AL, você vai colocando a cada 2 bytes, começando do 2ª byte pra frente. E as cores começando do 1ª byte pra frente. Desta forma, você não precisa nem usar a BIOS para escrever dados na tela, ainda é mais dinâmico e mais rápido.

@@KiddieOSCommunity Olá amigo. Pelo tempo que passei a msg achei que vc não tivesse visto, mas que bom que respondeu. Após pintar o fundo com a rotina backcolor, utilizando um vermelho escuro 111, com certeza esse valor está em AL, utilizando a função dO BIOS 0CH. Depois eu chamo a função int 16h, chamo a rotina de teclado e quando escrevo na tela, obviamente, o que estava em AL (a cor), nesse trecho da tela, vai embora, colocando fundo preto e letra da RGB, mas o fundo não muda. Eu tenho que fazer de uma outra forma, quem sabe usando essa dica que vc deu, mas confesso que não sei como dar os primeiros passos para fazer isso. Quanto ao trecho de codigo vc ja deve imaginar. Uso a int 16, capturo a entrada e utilizo alguma subfunção de escrita de caracteres do BIOS. Trivial. Deixa uma dica de codigo. Vai ajudar muito. Obrigado mais uma vez.

@@gsouzar Ah sim, entendo, lembrando que se você usa a função 0Ch, você tem que assumir que está no modo gráfico e não no modo texto. E criar fontes de caracteres pixel a pixel. Para ir ao modo texto na resolução 80x20, basta usar: Mov ah, 00h Mov al, 03h Int 10h E modo gráfico na resolução 300x200 é: Mov ah, 00h Mov al, 13h Int 10h Ou seja, no modo gráfico não pode imprimir diretamente o caractere em AL retornado pela INT 16h. Quanto a substituição da cor em AL pelo retorno da INT 16h, você pode "salvar" a cor de AL na pilha antes de usar INT 16h, exemplo: push AX Mov ah, 00h Int 16h ; Aqui no meio você pode salvar o caractere em AL em algumas variável ou outro registrador. Mov [keycode], al pop ax ; Aqui em cima você recupera a cor que estava em AL, pois foi salvo antes na pilha pela instrução PUSH. Você também não perde o caractere da INT 16h, já que ela foi salva em na variável keycode. Agora, se você tá na resolução de modo texto, você pode usar a função 0Eh ou 09h da BIOS pra imprimir o caractere que está em keycode, movendo novamente o keycode para AL: Mov al, [keycode] E assim imprimir o caractere e pode fazer isto para toda a String se quiser. Mas agora, se você está na resolução de vídeo no modo gráfico, aí você deve considerar usar uma fonte bitmap de texto e um sistema de escrita de fontes (FontWritter) no modo gráfico, desenhando pixel por pixel formando o caractere.. exemplo: Digamos que sua rotina de escrita de fontes é "textwritter" e ela espera como parâmetro a cor em AL e o caractere em BL, e digamos que você não desempilhou o AX salvo de antes (a cor), então você faria assim: pop ax Mov bl, [keycode] call textwritter Considerando que a rotina textwritter vai transformar o ASCII Code de BL em um conjunto de pixels na tela na cor AL, lendo um vetor de dados de bitmap que são os desenhos de caracteres em bits. Este vetor faz parte do arquivo de fontes. Ou este arquivo pode ser carregado do disco pelo textwritter antes dele fazer o mapeamento, ou o arquivo já pode estar incluído no kernel e o textwritter já ler diretamente do vetor.

Entendi. Então não tem jeito, vou ter que criar uma fonte de escrita no braço. Obrigado amigo.

Obrigado por gostar Gabriel! Eu gostaria muito de ter este reconhecimento, se puder divulgar o canal, isso me ajudaria muito a conseguir isto!

Ah sim, então ta explicado. É porque o seguinte, se você tem um arquivo de inclusão que tem código executável ali dentro e você incluir ele no início do kernel (ou outros binários), você tem que certificar que exista uma instrução JMP antes destas inclusões, porque o processador ler a memória sequencialmente, e ele vai começar do início da memória, e todos os arquivo incluídos farão parte de um só binário, o processador não vai saber quem é só uma inclusão e etc.. então ele executa tudo sequencialmente. Porém, existe uma coisa sobre isso, é que se estes arquivos de inclusão não tiver código executável, algo como: Apenas "Macros" e outras diretivas, como "%define", etc.. aí você não precisaria colocar o JMP antes das inclusões, pois macros e diretivas não são códigos executáveis pelo processador. Isto se dá o motivo de que, após as compilações finais do código-fonte Assembly (mnemônicos) para opcodes (Códigos de máquina, .bin), macros e diretivas são excluídas da compilação, pois elas só servem para compilação, depois disso, só resta código. O que era macros nos arquivos incluídos, se tornarão código em outras partes do kernel, partes estas onde elas foram chamados e aquelas macros que estavam no arquivo incluído e que não estão sendo utilizadas, elas são descartadas na compilação, ou seja, no final é como se você não tivesse incluído estes arquivos no início, então não dá problema no processador, ele vai executar o seu código no endereço correto. Então apenas nestes casos onde só tenha macros e diretivas nos arquivos de inclusão, aí não precisa se preocupar. Outro fator importante, seguindo sobre estas coisas, é que você deve verificar o conteúdo destes arquivos e ver se realmente pode excluir elas dos sistemas, porque normalmente tem um motivo para elas estarem lá, ou seja, você deve se perguntar o seguinte: "O conteúdo que eu tenho nestes arquivos de inclusão, eles tornam o sistema operacional dependente deles? Há dependências reais? Quais? Onde? Onde estão as referências desses conteúdos incluídos em todo o kernel? São esta perguntas que você deve fazer antes de alterar/excluir qualquer coisa relacionado a arquivos de inclusão. Eu até gostaria de saber qual linha exatamente você modificou, qual arquivo de inclusão, o que tinha nele, eu gostaria de saber todos os detalhes possíveis pra poder te auxiliar nisso e não acarretar problemas pra você ao longo do desenvolvimento. Se puder enviar código por aqui, melhor ainda, aí eu conseguiria ser mais assertivo nas minhas ajudas, vendo o que você tem na sua máquina, o que tinha quando não estava funcionando e o que tem agora quando está funcionando e assim, eu faria uma espécie de comparação linha a linha do que eu já tenho armazenado das versões anteriores... porque aí provavelmente eu consigo até encontrar exatamente os problemas que você está enfrentando, pois eu também já passei por muitos problemas, e alguns eu só resolvo depois de dias ou horas matutando até conseguir. Mesmo assim, se deu tudo certo aí e não tem nada estranho aconteceu, eu fico feliz. Sobre o mouse, ainda não tenho nenhuma referência no canal sobre isso, comentei sobre isso em alguns dos seus comentários. Mas em breve estarei desenvolvendo e postando nos vídeos, até falei em alguns dos comentários que minhas intenções reais é uma criar uma série completa só envolvendo Drivers, porém seria uma série paralela ao D.S.O.S, pois a galera que gostaria de aventurar por drivers de dispositivos poderia transitar para esta série periodicamente a medida que sai novos drivers pro KiddieOS e o Mouse é um deles, provavelmente seja os próximos vídeos da série é relacionado ao mouse, pois já fiz uma enquete aqui perguntando sobre isto e a galera optou por mouse, então se eu for criar vídeos de Drivers, é muito provável que minhas prioridades sejam pro mouse. Apesar de eu também querer postar sobre outros drivers, como: rede, disco, teclado (O controlador do teclado é o mesmo do mouse e usam o mesmo tipo de barramento, então uma coisa leva a outra, dá até pra mostrar os dois). Existe um fator muito relevante também, que é a "parte gráfica", isso conta muito, inclusive para desenhar inúmeros tipos de ponteiros de mouse, e no KiddieOS vou seguir uma estratégia diferente para determinar estes ponteiros, de uma maneira mais personalizável por usuário, então não vai ser algo tão fácil do que simplesmente "desenhar" pixels de ponteiro, vai ter todo um ecossistema envolvido aí nesse meio (Ecossistema de instalação e configuração dinâmica de Drivers, Via Scripts, como uma espécie de "Gerenciador de Dispositivos" igual tem no Windows/no Linux eu não sei como se chama este tipo de gerenciamento). Portanto, possa ser que os vídeos de Drivers, tanto relacionado ao mouse, quanto relacionado a outros drivers, sejam um pouco mais complicado apresentar eles... Então vou começar pelo funcionamento simplificado de cada um deles de maneira funcional (sem tanto gráficos), depois eu apresento o gerenciamento. Sem contar também que meu gerenciador gráfico ta cheio de bugs/defeitos que eu ainda não conseguir encontrar tempo pra depurar e resolver todos eles... Então esses defeitos acabam me atrasando em outros possíveis projetos, porque não vou nem pra trás, nem pra frente, fico parado no tempo então pra não ficar parado, desenvolvo outros projetos que sejam mais possíveis neste momento (Até porque encontrar bug é um negócio muito ruim e difícil, as vezes até mais do que desenvolver algo novo). É isso... tenha uma boa noite.

@@KiddieOSCommunity Valeu meu amigo pela resposta. Boa noite para vc tambem.

Quem me dera... kk estes são uns dos meus sonhos. Para isso ser possível, eu só preciso criar um montador Assembly.

Pelo menos já dá pra criar um programa usando o FASM que vem incluído no kiddieOS e o editor WRITE.

⁠Uma vez você já criou um, tinha feito até IDE (se chamava PlaxideOS)

@@kokitelin Ah sim, sim, é verdade. Criei apenas 40 instruções Assembly naquela época... mas não quero seguir aquele código, porque ele era quando eu tava iniciando ainda kkk O FASM que eu estou fazendo, eu comecei de outra forma, de uma maneira mais limpa e organizada... Eu vou desenvolver ele de forma que seja escalável e fácil de adicionar novas instruções. É igual no Shell, uma lista de comandos e um único loop conseguir percorrer essa lista e executar diretamente o evento do comando, sem precisar criar 1001 comparações sabe, pra cada comando. É este mesmo método que quero fazer no montador, diferentemente de antigamente, que eu fazia 1 comparação pra cada instrução/comando, então o código de antes ta foda kkk Exemplo: Já pensou ter 400 instruções e 400 comparações? Aí é bem foda né rs Mas agora posso fazer com 1 comparação para as 400 instruções, aí é mais legal. O interpretador BASIC mesmo... ele é bem lento porque faz da 1ª forma (1 comparação pra cada comando), não dá pra deixar ele assim, eu tenho que mudar para este 2ª método também no BASIC.

Lindo de se ver! Parabéns!

Eu vi os outros comentários, não tinha conseguido responder ainda, mas assim, se não é o DD, foi o que exatamente? Era alguma coisa boba no kernel?

@@gsouzar Sem problemas, quanto mais perguntas, melhor ainda! Então, na verdade eu já estou louco pra criar estas aulas. Vai ser logo mesmo, só vou terminar de apresentar alguns sistemas que estão dentro do meu Script planejado aqui, só umas questões fundamentais do Shell referente a programas... Mas já quero paralelamente já ir desenvolvendo o driver de mouse pra mostrar em aula. Quero apresentar outros drivers também. Pretendo fazer uma série só de drivers também pra gente pegar firme essa questão.

Encontrou o problema do comentário anterior? Dá o feedback pra gente. Por que o kernel não estava inicializando? EDIT: Ah ta, você fala é sobre o botão de download né?...

Estranho, aqui apareceu o botão verde. É um botão com o nome "<> Code". Ele tem em cada repositório, e é através dele que você pega o link pra dar o git clone e clonar o repositório pra sua máquina ou o link SSH também se for o caso. O link que você gera lá é esse aqui "github.com/FrancisBFTC/KiddieOS_Development.git". É o mesmo link da URL, porém com a extensão ".git" no final. Basta você copiar este link e colar após o comando "git clone" no seu Bash do Git. vai ficar assim "git clone github.com/FrancisBFTC/KiddieOS_Development.git". Então, ele clona o repositório criando uma pasta "KiddieOS_Development" no lugar que você abriu o Git Bash. Através deste repositório, você pode trabalhar nele, criando novas funcionalidades ou acompanhando os códigos desenvolvidos nas aulas. Pode também usar ele para dar suas contribuições a este sistema também.

@@gsouzar Eae brother... Maneiro kkk deu uma vasculhada aí nas interrupções né... Pois é, eu também já tinha mexido no INT 33h mas parece que não funciona na BIOS. É provável que essa INT é utilizada em um sistema completo como o Windows/Linux, para usar o Driver de mouse. Até porque pra ter o mouse, você precisa criar o ponteiro usando a interface gráfica e conversar com o controlador PS/2. Vou responder as outras perguntas.

Olá Gsouza, como vai? Pelos setores que você colocou está tudo certo, mas você chegou a entrar na versão 1.1.0 na etapa 3? Pode ver que nas descrições do README, ele tem ali os links das etapas e no KiddieOS versão 1.1.0, você entra no 3ª link, que é a "Etapa 3". Nos minutos 02:04, eu até falo também que "Se você chegou a fazer alguma alteração ou algo diferente das aulas, que você tenha esse cuidado em substituir tudo, porque pode quebrar o sistema, agora se você fez exatamente igual e tudo tava funcionando, até a aula 29, aí você poderia só substituir porque o código seria o mesmo das aulas, então ele faria a substituição de maneira correta". Se seu kernel não inicializa, vai ter que fazer uma busca excessiva no problema, ver o que foi alterado da aula anterior pra esta aula, ver o que foi substituído. Vi que também na aula eu tinha feito a alteração no arquivo .BAT o número do "Drive", mas talvez no seu caso nem precise alterar esse número. Então a gente vai ter que estudar passo a passo o seu problema de acordo com esta aula. Se possível, reassista ela e vai anotando aí cada parte que eu falo sobre as mudanças, e aí você vai me mandando mensagem aqui e dando seu feedback... Verifique também se estes mesmos números de setores que você colocou, se eles não mudaram com as atualizações, ou seja, se não está exigindo mais setores pro kernel, pro window, pro keyboard....

Olá Francis, tudo bem? Conforme tinha comentado, eu fiz todo o processo de download, agora para o ambiente windows, fiz as alterações no autogen e esta tudo funcionando. O comentario anterior refere-se ao ambiente Linux, que nesse eu utilizo o dd na linha de comando, como sempre fiz e funcionava tranquilamente, com aqueles setores corretos mas ao carregar o arquivo de imagem no QEMU o boot não encontra o kernel. Tranquilo. O objetivo da msg anterior era para saber se poderia existir algo mais ja que no linux todo o processo de montagem e geração da imagem esta sendo manual. Obrigado pelo retorno.

Rpz, seguir todo o procedimento, tanto assim que coloquei para funcionar no windows, como ja foi dito. Seguinte: rpz, analisando friamente acho que o problema esta com o dd, ou seja, ele não esta gravando nada e é por esse motivo que a imagem já se perde desde o boot. Com certeza deve ser iddo. Não tem outra explicação ate mesmo pelo sintoma.

Olá meu amigo, como vai? Vi que você desapareceu por uns tempos mas o bom que está de volta! kk Então friend, gostei muito deste comentário, só que atualmente estou enfrentando uns problemas de saúde e não vou conseguir responder de maneira melhor, por enquanto. Estou acamado até, doente. Mas resumindo o seu problema: Você não está conseguindo definir um endereço via ORG por um ELF né? E isto impossibilita de saltar pelo bootloader. Então, o que eu posso te dizer sobre isso é que a partir do momento que você começa a trabalhar com ELF e C, você trabalha com endereços dinâmicos. O ORG é utilizado para arquivos binários, sem nenhum formato de estruturas, enquanto que o ELF é utilizado para executáveis Linux (E vários outros tipos de arquivos). Então você deve ler os campos da estrutura ELF no início do Kernel e tentar interpretar isto, conhecendo os endereços, linkagens, dentre outras coisas. Ainda não cheguei nesta parte do ELF, só fiz o Loader MZ, mas quero fazer um Loader ELF só pra programas/aplicações. Mas o que eu sei sobre estas estruturas (assim como o MZ), que você deve primeiro identificar sua assinatura no início do arquivo (No caso do ELF vai está E L F como String). Depois de identificar a assinatura, você deve procurar o entry point, que é um campo específico da estrutura ELF que diz o "deslocamento" até o ponto de entrada principal (onde está o código Main), e aí você pega este deslocamento, calcula ele e salta para ele. Percebeu a diferença? Não é mais como você fazia nos códigos binários puros (sem formatação), onde dava um JUMP para um Endereço, isso aí é o método estático, onde os endereços são fixos. A partir do momento que trabalha com ELF, PE, MZ ou qualquer outra estrutura de executável, estes endereços são determinados dinamicamente. De toda forma, se você carregou o seu kernel.bin no endereço 3000h:0000h por exemplo, o segmento sempre será 3000h, então sem problemas, DS pode ter este endereço, e 0000h, okay, então sabemos que o kernel.bin vai começar do offset 0000h, agora basta procurar o deslocamento do entry point e somar + 0000h e saltar para esta posição.

@@KiddieOSCommunity Trm alguma ideia de como fzr isso? Algum codigo de exemplo? Melhoras meu caro. Ate a proxima.

@@gsouzar Tenho mais ou menos uma ideia, assim por estes dias eu criei um novo repositório, porém não fiz nada nele ainda. Ele será um projeto desenvolvido em paralelo referente ao KiddieOS 64-bit. E será desenvolvido em C mesmo. Quem sabe eu faça algumas vídeo aulas mostrando o desenvolvimento desse projeto. A idéia inicial é simples: Você precisa conhecer a estrutura ELF primeiro pra fazer a verificação que eu mostrei no comentário anterior. Não consigo agora te fornecer um código completo ou exemplos exatos, mas o que posso fazer é te passar um norte de como desenvolver este novo projeto. O que eu expliquei no comentário anterior você faz em Assembly mas existem alguns passos importantes antes disso: No seu bootloader em Assembly você deve primeiro carregar o kernel ELF na memória usando interrupção da BIOS (INT 13h de disco) e só depois passar para o modo protegido 32 bits. Para entrar nesse modo, é preciso configurar uma flag da CPU e ter duas estruturas: IDT e GDT. Estas duas estruturas depois de configuradas certinho, você carrega elas no processador. Depois destes procedimentos, você dar um salto longo para um endereço de memória em modo protegido. Tudo isso é feito ainda no Bootloader em Assembly. Nessa nova memória em modo protegido, você vai fazer as verificações mencionadas no comentário anterior. A partir daí é mais fácil, pois pra verificar se o início de um arquivo é ELF, basta usar instruções CMP em Assembly, as comparações que você já está acostumado a fazer. Exemplo: Digamos que você carregou o kernel.bin no endereço 2000h:0000h. Se for um arquivo ELF, no início dele terá uma assinatura com a String "ELF", basta usar a instrução CMP em memória pra analisar se o offset 0000h == "E" e se o offset 0001h == "L" e o offset 0002h == "F", se for tudo igual, então é um arquivo válido. Então você vai procurar um campo específico da estrutura ELF que diz o número de deslocamento pro ponto de entrada. Isto é feito somando o offset atual + o número encontrado neste campo, usando a instrução ADD. No entanto, existem algumas pegadinhas aí, esqueci de mencionar que a memória em modo protegido é linear e não segmentada, então você passa a trabalhar com "seletores" ao invés de "segmentos" como em modo real. Então se você carregava o kernel em 2000h:0000h o que seria numa memória segmentada, agora você carregaria em 0x20000 num endereço absoluto. Eu não vou me lembrar aqui o offset do campo que tem o ponto de entrada, mas eu posso te passar dois links no próximo comentário: Um é da Wiki pra OSDevs onde explica sobre a estrutura ELF e o outro é um repositório de um kernel em 32-bit em C do GramadoOS, que inclusive será dele que eu vou me basear para o projeto do Kiddie64. Também indico procurar alguns tutoriais mostrando como fazer o kernel 32-bit em C, tem muitos destes vídeos na internet, pra início de desenvolvimento isto vai te ajudar.

@@gsouzar Estrutura ELF: wiki.osdev.org/ELF Kernel do GramadoOS: github.com/gramado/kernel Procure também na sessão BareBones & Baby Steps no Wiki OSDev. Lá você encontra os tutoriais pra construir kernels em várias linguagens, C, ADA, Pascal, etc. Aqui um link que mostra de forma mais completa pra construir em C: wiki.osdev.org/Bare_Bones

@@KiddieOSCommunity Rpz, ajudou e muito inclusive eu estou com um boot que sai do modo real para o protedito verificando inclusive essas tabelas de descritores mencionadas por vc. Mande os links please...Obrigado mais uma vez. Finalizando, a insistencia de fazer um kernel em C é para saber como funciona ja tantan gente ja fez por ai.

Fico muito grato por você gostar do canal! Realmente, estes tipos de vídeos são encontrados mais na gringa mesmo e costuma ter muito mais acesso lá do que aqui no brasil. Se você já encontro a Playlist do Curso de S.Os, então desejo bons estudos e qualquer dúvida, só comentar que a gente ajuda.

Olá @kokitelin! Sim, aos poucos estou trabalhando em novas funcionalidades. Eu tenho alguns planos de tempos que vou fazer nestas próximas versões... +3 novos comandos pra finalizar as questões do Shell: INIT, ASSOC e AUTH. Mas eu vi o seu sistema Arnix e ta ficando legal, é só ter paciência e persistência, você está no caminho certo!

⁠​⁠​⁠​⁠​⁠​⁠​⁠​⁠​⁠​⁠@@KiddieOSCommunityOk Francis, já estou desenvolvendo a MBR agora, mas depois vou partir para a VBR, o BOOTMGR.SYS, KERNEL.SYS, … vou implementar FAT12, FAT16, FAT32 e talvez o ExFat. Vou colocar área de trabalho gráfica e programas de padrão. Sobre drivers de rede eu posso implementar um que eu escolha talvez.

@@kokitelin Maneiro Kokitelin!! Gostei do seu conjunto de extensões. .SYS para Sistemas. Então você pretende fazer um Gerenciador de Inicialização, certo? Eu vi pelo nome que você colocou "BOOTMGR = Boot Manager = Gerenciador de Inicialização". Então, sobre isso, nas versões mais atuais do KiddieOS, voltei para a MBR e personalizei ainda mais a questão de bootloader, até porque eu estava trabalhando no particionamento de disco e isto me exigiu criar um gerenciador mais personalizado. Agora, não tenho só uma MBR e uma VBR, mas sim, um gerenciador com uma mini-API que fiz em outros setores. Acredito que isto pode te ajudar na sua jornada, enquanto assiste estas aulas atuais. Basta procurar nas Branchs mais recentes ou no próprio Main (Já fiz Merge). Você vai ver que é muito legal criar a VBR, vai te dar um norte para os FileSystems. A maior utilidade e diversão da VBR está na questão de particionamento, não explorei isso bem nas durante as aulas mas você encontra nos repositórios KiddieOS mais recentes (Tendo uma conexão com o comando DISK e gerenciamento completo do disco). Vai aprender muita coisa nesta jornada de pesquisas. Depois que eu fiz o FAT16, minhas intensões se tornou apenas ir para frente, para FAT32 e ExFAT, até porque FAT12 é quase igual ao FAT16, só que uma versão bem mais simplificada e limitada... Por intuitos de Compatibilidade com sistemas open-source que usa FAT12 (Como o MikeOS), será muito bom a sua implementação do FAT12. O FAT12 é utilizado mais para Disquetes... você pode ter uma versão do seu S.O simplificado com o FAT12 só para disquetes, aliás, apoio total nessa ideia! Quanto ao Driver de rede, existem alguns parâmetros que alguns mestres me ensinaram... um deles é você estudar o seu controlador de rede, entender qual é o seu modelo e verificar se você quer compatibilizar pra máquina real ou virtual. Dependendo da sua prioridade neste momento, você vai escolher um driver de uma fabricante específica. Exemplo: Eu escolhi o RTL da Realtek porque além do modelo do meu controlador ser da Realtek, eu poderia executar na máquina real, que era minha intensão... no entanto RTL não executa na máquina virtual, daí você teria que optar por algum driver da Intel, tipo i8254x ou E1000 ou outros... Eu tenho só o i8254x porém ele é de outro S.O baremetal em 64-bits (Não é meu, é de outro Dev), aí eu teria que compatibilizar com o KiddieOS igual fiz pro RTL8169 (Que se tornou 81XX, adaptei para vários modelos da Realtek). No entanto, minhas intensões maiores é o E1000, porque meus amigos veteranos em S.Os já implementaram o E1000 e eles já tem o código-fonte em C, o que vai se tornar mais fácil pra mim adaptar pra Assembly 32-bit. Mas aí a questão do Driver de rede, realmente vai das suas necessidades. Outro fator importante é sobre estudar as camadas da ISO, eu também vou voltar a estudar pra entender mais e entender o papel do driver atual (RTL ou E1000 ou outro) nas camadas da ISO dentro do seu S.O. Isto é fundamental, porque você vai se situando no tempo cronológico de desenvolvimento, ou seja, entender qual driver vai fazer primeiro e o porquê disso e como irá implementar a comunicação entre as camadas. Bom, o que eu posso te dizer é que vários OSDevers tem inúmeras formas/soluções de implementar estas camadas e isto te permite também partir de alguma referência no Github... poderá também usar sua criatividade e implementar sua própria forma. De toda forma, você vai aprender muito durante esta jornada. Apoio total nas suas ideias e projetos, estamos juntos friend!!

Valeu Francis! O boot manager eu vou fazer ele como o BOOTMGR do Windows, que vai ter um arquivo separado para as opções (BOOTCFG.INI) Sobre o driver de rede, vou implementar bem depois, porque vai ter que fazer mais coisas além disso. Estou pensando em fazer um Multitasking para que vários programas sejam executados ao mesmo tempo também. Já que o KiddieOS está já suportando até FASM, vou tentar usar o NASM para DOS e fazer uma versão do DD. Se esse experimento der tudo certo nós vamos poder compilar o KiddieOS com ele mesmo! Se o meu experimento der certo eu te mando os arquivos no Discord para você tentar fazer

Olá Cabralito, boa madrugada! Então, aí está dizendo que seu subcomando "createrawvdk" está deprecado, ou seja, nesse caso não estaria sendo mais utilizado, ao invés disso teria que usar createmedium para as máquinas virtuais atualizadas. Mas perceba que ele mostrou o subcomando incorreto, porque o correto é "createrawvmdk" e não "vdk" no final, faltou um "M". Provavelmente você digitou o comando incorreto. Mesmo se tiver digitado corretamente e ele mostrar esse erro de deprecado, eu testei aqui e esse subcomando ainda funciona. Ele tambem diz que dá acesso negado ao tentar abrir o disco RAW PhysicalDrive1... Verifique se este é o número correto mesmo (o meu é o 6) e veja se o pendrive está conectado no PC, ele tem que está conectado pra funcionar. Se não tiver conectado, ele vai apresentar este erro. E sempre verifique o número do disco pelo DiskPart, porque este número pode mudar. O meu era o 5 e depois se tornou o 6, saber o porquê eu não sei. E outra coisa, tenta mudar o nome do arquivo VMDK que você vai criar, eu fiz isso e deu certo muitas vezes. Tá vendo este nome "usb.vmdk" no final do comando? Então, muda ele, coloca tipo usb2.vmdk, ou sei lá "myOS.vmdk". Cada vez que você testar esse comando, mesmo se não der certo, muda esse nome desse arquivo... Porque se já tiver um arquivo lá com o mesmo nome, ele pode dar esse erro também de acesso negado. Só pra garantir, recomendo que faça isso. Me fala aqui se deu certo seguindo estas dicas, se não der, vou continuar a te ajudar, pois eu também estava enfrentando estes erros e fiz estas coisas e funcionou... Mas aí vou te mostrar os passo a passos que eu fiz se você tentar e não der certo.

@@KiddieOSCommunity Obrigado pelo suporte professor, eu tive que reinstalar o Oracle VirtualBox, isso por que se você iniciar pelo menos 1 vez ele sem administrador, aparentemente ele não vai ter mais acesso ao armazenamento (pendrive) do dispositivo, eu não entendi muito bem, mas basicamente esse e o problema, agradeço muito pelo suporte e também pelo tutorial de sistema operacional, vai ser muito útil pra eu estudar sistema de baixo nível e computação mais a fundo 💖🙏

@@Cabralito Entendo, isso é um pouco estranho pois isso nunca aconteceu comigo, de iniciar 1 vez e nunca mais ter acesso. Já iniciei a máquina sem ser admin. Isso deve ser na hora de criar a máquina virtual, talvez se criar ela sem ser administrador, a máquina virtual que foi criada não terá mais acesso ao pendrive, aí teria que criar uma nova máquina virtual (é só uma teoria). Mas você reinstalou o VirtualBox né, se conseguiu resolver então já foi ótimo e fico feliz por isso. De qualquer forma, estou aqui pra ajudar e boa jornada no desenvolvimento de O.Ses.

Que bom que pelo menos alguém valoriza esse conteúdo! Dá trabalho sim, a gente fica algumas horas aí só pra fazer funcionar completamente 1 só comando, dentre uns 30 possíveis restantes.

@@dgmstudios1 Olá, boa noite!! Este tipo de conteúdo você vai encontrar nas últimas aulas ali da playlist (vou gravar em breve e falar melhor sobre isso). Na verdade, eu escrevi no Github sobre os conceitos principais para executáveis DOS (.COM e .EXE). Procura as "pull-requests" fechadas do repositorio "KiddieOS_Development", será um dos últimos pull-requests. Lá terá uma rica descrição das últimas atualizações, que inclusive falo sobre isso. Mas te adiantando, o .COM é um arquivo binário comum, igual .BIN, mas ele utiliza as interrupções do DOS implementadas no seu kernel (veja no Github dentro de kernel.asm a label DOS_INT_21h. Normalmente um programa .COM é carregado no endereço 100h de memória. Já o EXE você precisa ler uma estrutura inicial do executável, fica no cabeçalho e tem o tipo "MZ" no campo inicial. Então o EXE do MS-DOS além do binário, ela também contém esta estrutura do MZ. Já o EXE do Windows tem tanto o MZ quanto a estrutura PE. Na descrição do Github eu falo sobre cada campo dessa estrutura e como eu cálculo eles pra carregar o arquivo EXE. Procure também no wiki.osdev.org a sessão onde tem o link PE, existem alguns conceitos interessantes lá que vale a pena você verificar.

@@victorhuggobianco5209 Valeu Victor, bom que gostou!!

@@renatamonteiro7365 Por nada Renata, eu que agradeço por você assistir! Dá uma olhada no canal, também tenho outros vídeos relacionados a programação.

Muito bom!! Eu também adoro este sistema de arquivos. Valeu pelo Gramado, o que você fez me ajudou muito! Se quiser entrar lá no servidor da comunidade, seja bem-vindo: discord.gg/JfXXV9sY

Olá, boa noite! Eu precisaria saber como está o seu código. O que você escreveu de código depois de dar errado? E como está a sua rotina de cores do logotipo? Se puder me enviar aqui pra me analisar e comparar, eu agradeço.

@@Chr_04 Valeu por seguir o conteúdo! 🤩