Tela preta no VESA [Resolvido]
Closed this issue · 25 comments
Tava testando o KiddieOS mas dá tela preta ao entrar no VESA (obs: sou o mesmo cara da antiga Mega Studios)
Tava testando o KiddieOS mas dá tela preta ao entrar no VESA (obs: sou o mesmo cara da antiga Mega Studios)
Se tiver mais algum bug pra reportar, fique a vontade. Porque aí na próxima versão eu já dou merge com todos eles corrigidos, eu já tenho um bug pra resolver também no comando de deleção.
Inclusive quando testo o KiddieOS no Windows 8.1 com virtualbox antigo (meu caso, versão 5.x.x) ao entrar no VESA acontece um Guru Meditation. Provavelmente deve ser a memória.
Sim, pode ser a memória. No entanto essa mensagem Guru Medidation muitas vezes acontece por motivos desconhecidos. Até uma vez fiz uma pesquisa, e muita gente estava enfrentando esta mensagem em versões específicas do VirtualBox até pro Windows e Linux também. Alguns teorizaram ser bugs do próprio VirtualBox, em algumas versões. Mas pode ser problema no KiddieOS também, já que ta dando tela preta no VESA. Isso eu vou concertar neste mês. Eu vi que tu postou um comentário no canal mas apagou, eu ia responder só que depois vi que sumiu.
Sumiu porque eu apaguei. Tava fazendo um outro S.O baseado no seu mas não deu para implementar uma melhoria. Daí eu ia comentar mais depois apaguei.
Sumiu porque eu apaguei. Tava fazendo um outro S.O baseado no seu mas não deu para implementar uma melhoria. Daí eu ia comentar mais depois apaguei.
Ah sim, entendi, precisava apagar não rs Fui ver nas notificações e parecia um comentário bem interessante, além de gerar engajamento pro canal. Eu falo assim porque já vi outros usuários lá que comentam qualquer besteira ou que não tem relação com o sistema, e eles não apagam, sendo que é os que deveriam apagar né kkk eu acabo até deixando, mas tem uns que ave maria, eu apago. Só que seu comentário foi bem inteligente. De toda forma vou responder por aqui...
Sumiu porque eu apaguei. Tava fazendo um outro S.O baseado no seu mas não deu para implementar uma melhoria. Daí eu ia comentar mais depois apaguei.
Então, a questão de fazer um outro sistema com melhorias baseado no meu, pode ser um tanto quanto complicado se você não conseguir compreender completamente o que todo o sistema está fazendo. Neste caso, é recomendável que você siga do início, cada aula, desenvolvendo junto e enfrentando desafios ao longo das aulas, porque aí só dessa forma que você consegue criar uma "intimidade" com o sistema, cada linha de código, cada instrução, cada função. Se você tiver algum tipo de dificuldade com o Assembly ou com o tipo de programação que eu abordo, você vai se aperfeiçoando e aprendendo naturalmente com as aulas e os obstáculos,... eu mostro um pouco de teoria também, tem vídeos que é 60% de teoria, mas a maioria são mais práticos. Daí, após um tempo de desenvolvimento, que você já tiver assistido muitas aulas, você vai criando ideias ali e muitas das vezes identificando erros cometidos ou querendo programar uma nova forma de resolver aquele problema. Por exemplo: Digamos que você está na aula de interface gráfica e eu faço um retângulo horizontal verde... e aí você acompanhando e programando, eu vou explicando na aula como é feito e o porquê, aí você escreve e reescreve, pesquisa nos links que eu divulguei, tira dúvidas no canal, e aí você acaba compreendendo realmente o que aquele trecho de código faz e até descobre nas suas pesquisas que tem como fazer este mesmo retângulo usando outros códigos. O que você faz: Você pensa assim "Ah eu não quero um retângulo horizontal, eu quero um vertical, e não na cor verde, mas na cor vermelha", então você começa a fazer as primeiras modificações de parâmetros que você já conhece, ou na verdade você só experimenta modificar pra ver no que vai dar, a medida que você ver os resultados, você continua modificando e testando, até chegar no retângulo vermelho vertical. Outro exemplo, é se lá na frente você descobriu como fazer um objeto se mover na tela, e eu apenas mostro isso em algum vídeo, só que você não quer só fazer "mover", mas você quer que ele tenha um efeito "boomerang", sei lá, ir em alguma região da tela e voltar, como se tivesse abrindo pra lateral... porém tu já estudou e testou 1 milhão de vezes como seria um movimento de objetos/janelas manualmente, então você simplesmente tenta "automatizar" este código pra ir a dada região x e voltar para uma região x original, sem sair da posição y... aí você vai alterando parâmetros de velocidade, etc. É nessas mudanças que você faz as melhorias e sistemas únicos, pensados por você. É por isso que você precisa acompanhar o desenvolvimento passo a passo pra criar intimidade e só depois de algumas pesquisas e testes você realizar mudanças pequenas até as mudanças grandes, é um processo gradual.
Sumiu porque eu apaguei. Tava fazendo um outro S.O baseado no seu mas não deu para implementar uma melhoria. Daí eu ia comentar mais depois apaguei.
Lembrando que o mesmo exemplo que eu dei no texto anterior pode ser aplicado também não só pra interface gráfica mas pra sistema de arquivos, ou seja, você querer modificar algumas funções do sistema, a forma de organizar o código ou funções pra fazer uma mesma operação do sistema de arquivos e infinidade de coisas.
No caso o que eu tentei implementar foi carregar o kernel com o nome completo do arquivo. Já tinha feito um S.O baseado no seu e isso deu certo (inclui comando de mostrar partição) mas daí eu apaguei ele. Já eu tinha recomeçado e não deu.
Entendo man, em breve aí vou poder te ajudar mais nestas questões, mas pra tudo sair certinho é bom você seguir tudo passo a passo e só modificar mesmo quando você tiver já confiante e entendendo tudo o que tiver fazendo, por enquanto faça modificações pequenas. Carregar o kernel são as aulas iniciais ainda, depois disso tem muita coisa pra pegar, além do mais carregar o kernel (ou qualquer outro sistema) através do "nome do arquivo" é algo um pouco mais complicado pois é preciso ter elaborado uma série de funções do sistema de arquivos, e isso são as aulas mais avançadas no Curso, por isso é importante ter paciência e fazer tudo aos poucos. Sobre o comando de mostrar partição, interessante, gostei muito disso mas não precisava ter apagado sabe... o que você pode fazer é versionar o sistema, tipo, salvar ele no Github no estado que ele estiver funcionando e criar uma nova branch, e aí fazer as alterações só nesta branch, aí quando tudo sair do controle neste código da branch e você não conseguir voltar ao normal, então você recupera a branch anterior que tava salva e reinicia tudo.
Entendo man, em breve aí vou poder te ajudar mais nestas questões, mas pra tudo sair certinho é bom você seguir tudo passo a passo e só modificar mesmo quando você tiver já confiante e entendendo tudo o que tiver fazendo, por enquanto faça modificações pequenas. Carregar o kernel são as aulas iniciais ainda, depois disso tem muita coisa pra pegar, além do mais carregar o kernel (ou qualquer outro sistema) através do "nome do arquivo" é algo um pouco mais complicado pois é preciso ter elaborado uma série de funções do sistema de arquivos, e isso são as aulas mais avançadas no Curso, por isso é importante ter paciência e fazer tudo aos poucos. Sobre o comando de mostrar partição, interessante, gostei muito disso mas não precisava ter apagado sabe... o que você pode fazer é versionar o sistema, tipo, salvar ele no Github no estado que ele estiver funcionando e criar uma nova branch, e aí fazer as alterações só nesta branch, aí quando tudo sair do controle neste código da branch e você não conseguir voltar ao normal, então você recupera a branch anterior que tava salva e reinicia tudo.
É que o NASM estava acusando erros que não existiam um dia que fui compilar em meu outro computador mais antigo (É o que estou usando neste exato momento, já formatei o computador e consigo compilar o KiddieOS) daí eu apaguei.
Sim, o NASM ele pode encontrar apenas erros de sintaxe, aqueles de programação mas as vezes o arquivo pode incluir certos caracteres ocultos e aí o montador pensa que é um erro, já aconteceu isso comigo e com alguns. Vi que você tá fazendo o KBOS, bem interessante, acredito que vai ficar legal, queria conhecer suas ideias. Sobre ler o arquivo do nome completo, existem algumas considerações: Uma delas que no FAT16 o padrão é 8.3, isto significa que você só pode ler/armazenar nomes de arquivos com 8 caracteres no nome e 3 caracteres na extensão, totalizando 11. Se optar por aumentar esta quantidade, deverá processar a tabela de LFN (Long Files Name ou Nome longo de arquivos). Esta tabela LFN ela fica após a tabela 8.3 normal, fica na área de diretórios, cada arquivo tem um. Estas tabelas são chamadas de "Entradas".
Normalmente, a forma de ler dados de arquivos inicia-se pela busca, a busca é você ler cada entrada (Tabela) da área de diretórios, iniciando pelo 1ª byte da entrada, cada entrada tem 32 bytes, no entanto, o 1ª campo da entrada se refere ao nome do arquivo, que tem 11 bytes. Você ler do byte 0 até o byte 10, comparando cada byte com uma String, Ex.: KERNEL BIN. Se algum byte for diferente, você encerra essa execução e parte pra ler a próxima entrada, isso é um loop, se o 1ª byte da entrada for 0, significa que você chegou no final das entradas e este arquivo não foi encontrado, então você pode imprimir esta mensagem ao usuário. Porém se os 11 bytes (Byte 0 ao 10) forem lidos sucessivamente, então você vai ter que procurar nos outros campos da entrada pra ler os dados deste arquivo, após isto você passou da etapa de busca. A próxima etapa é a leitura encadeada de clusters, então este outro campo da entrada será o campo de LowCluster (Tem 16 bits ou 2 bytes). Este número de Cluster vai apontar para um endereço específico do FAT (Tabela de Alocação de Arquivos), tudo que você deve fazer é converter este número de cluster para um número lógico que vai apontar para um setor na área de dados, é só ler este setor e jogar os dados em uma memória específica. O endereço no FAT no qual o número de cluster apontou por sua vez vai apontar pra outro endereço, antes de pegar o próximo endereço deve fazer o mesmo processo de conversão lógica, aí sim você pega o próximo endereço. E neste próximo a mesma coisa, até você encontrar o valor 0xFFFF, se for este valor, significa que você chegou no final do arquivo e não precisa mais ler dados dele, portanto pode encerrar a execução.
Este trecho acima é a função mais básica de uma leitura de arquivos no FAT16, mas você pode otimizar e personalizar, criando outras funcionalidades dentro desta execução, como no caso do que o KiddieOS faz que é gerenciar permissão de acesso e "abrir" arquivos antes de ler, ou seja, criar uma tabela temporária de abertura de arquivos pra gerenciar melhor o acesso. E dentre várias outras coisas que você pode fazer.
Sim, o NASM ele pode encontrar apenas erros de sintaxe, aqueles de programação mas as vezes o arquivo pode incluir certos caracteres ocultos e aí o montador pensa que é um erro, já aconteceu isso comigo e com alguns. Vi que você tá fazendo o KBOS, bem interessante, acredito que vai ficar legal, queria conhecer suas ideias. Sobre ler o arquivo do nome completo, existem algumas considerações: Uma delas que no FAT16 o padrão é 8.3, isto significa que você só pode ler/armazenar nomes de arquivos com 8 caracteres no nome e 3 caracteres na extensão, totalizando 11. Se optar por aumentar esta quantidade, deverá processar a tabela de LFN (Long Files Name ou Nome longo de arquivos). Esta tabela LFN ela fica após a tabela 8.3 normal, fica na área de diretórios, cada arquivo tem um. Estas tabelas são chamadas de "Entradas".
Normalmente, a forma de ler dados de arquivos inicia-se pela busca, a busca é você ler cada entrada (Tabela) da área de diretórios, iniciando pelo 1ª byte da entrada, cada entrada tem 32 bytes, no entanto, o 1ª campo da entrada se refere ao nome do arquivo, que tem 11 bytes. Você ler do byte 0 até o byte 10, comparando cada byte com uma String, Ex.: KERNEL BIN. Se algum byte for diferente, você encerra essa execução e parte pra ler a próxima entrada, isso é um loop, se o 1ª byte da entrada for 0, significa que você chegou no final das entradas e este arquivo não foi encontrado, então você pode imprimir esta mensagem ao usuário. Porém se os 11 bytes (Byte 0 ao 10) forem lidos sucessivamente, então você vai ter que procurar nos outros campos da entrada pra ler os dados deste arquivo, após isto você passou da etapa de busca. A próxima etapa é a leitura encadeada de clusters, então este outro campo da entrada será o campo de LowCluster (Tem 16 bits ou 2 bytes). Este número de Cluster vai apontar para um endereço específico do FAT (Tabela de Alocação de Arquivos), tudo que você deve fazer é converter este número de cluster para um número lógico que vai apontar para um setor na área de dados, é só ler este setor e jogar os dados em uma memória específica. O endereço no FAT no qual o número de cluster apontou por sua vez vai apontar pra outro endereço, antes de pegar o próximo endereço deve fazer o mesmo processo de conversão lógica, aí sim você pega o próximo endereço. E neste próximo a mesma coisa, até você encontrar o valor 0xFFFF, se for este valor, significa que você chegou no final do arquivo e não precisa mais ler dados dele, portanto pode encerrar a execução.
Este trecho acima é a função mais básica de uma leitura de arquivos no FAT16, mas você pode otimizar e personalizar, criando outras funcionalidades dentro desta execução, como no caso do que o KiddieOS faz que é gerenciar permissão de acesso e "abrir" arquivos antes de ler, ou seja, criar uma tabela temporária de abertura de arquivos pra gerenciar melhor o acesso. E dentre várias outras coisas que você pode fazer.
Eu já enfrentei problemas com caracteres ocultos. Consegui resolver pelo editor hexadecimal. Sobre o KBOS, eu havia meio que excluido o projeto porque eu não tinha ideias para colocar mais comandos, e, além disso, eu estou desenvolvendo outro sistema operacional chamado Arnix.
Arnix é um sistema 32-bits Unix-Like feito em assembly e C e que é multitasking e usa o sistema de arquivos FAT16. Optei pelo FAT16 porque além de eu já conhecer a estrutura FAT, eu não preciso me preocupar com carregar apenas alguns bits em cada cluster (como acontece no FAT12) e sim apenas ler 2 bytes. Por enquanto, estou desenvolvendo o segundo estágio do bootloader (que entra no modo protegido, configura o VESA e executa o kernel). Sobre o primeiro (VBR) eu usei uma de um projeto no github chamado BootProg (que o criador deixa as pessoas usarem sob uma licença).
Sim, o NASM ele pode encontrar apenas erros de sintaxe, aqueles de programação mas as vezes o arquivo pode incluir certos caracteres ocultos e aí o montador pensa que é um erro, já aconteceu isso comigo e com alguns. Vi que você tá fazendo o KBOS, bem interessante, acredito que vai ficar legal, queria conhecer suas ideias. Sobre ler o arquivo do nome completo, existem algumas considerações: Uma delas que no FAT16 o padrão é 8.3, isto significa que você só pode ler/armazenar nomes de arquivos com 8 caracteres no nome e 3 caracteres na extensão, totalizando 11. Se optar por aumentar esta quantidade, deverá processar a tabela de LFN (Long Files Name ou Nome longo de arquivos). Esta tabela LFN ela fica após a tabela 8.3 normal, fica na área de diretórios, cada arquivo tem um. Estas tabelas são chamadas de "Entradas".
Normalmente, a forma de ler dados de arquivos inicia-se pela busca, a busca é você ler cada entrada (Tabela) da área de diretórios, iniciando pelo 1ª byte da entrada, cada entrada tem 32 bytes, no entanto, o 1ª campo da entrada se refere ao nome do arquivo, que tem 11 bytes. Você ler do byte 0 até o byte 10, comparando cada byte com uma String, Ex.: KERNEL BIN. Se algum byte for diferente, você encerra essa execução e parte pra ler a próxima entrada, isso é um loop, se o 1ª byte da entrada for 0, significa que você chegou no final das entradas e este arquivo não foi encontrado, então você pode imprimir esta mensagem ao usuário. Porém se os 11 bytes (Byte 0 ao 10) forem lidos sucessivamente, então você vai ter que procurar nos outros campos da entrada pra ler os dados deste arquivo, após isto você passou da etapa de busca. A próxima etapa é a leitura encadeada de clusters, então este outro campo da entrada será o campo de LowCluster (Tem 16 bits ou 2 bytes). Este número de Cluster vai apontar para um endereço específico do FAT (Tabela de Alocação de Arquivos), tudo que você deve fazer é converter este número de cluster para um número lógico que vai apontar para um setor na área de dados, é só ler este setor e jogar os dados em uma memória específica. O endereço no FAT no qual o número de cluster apontou por sua vez vai apontar pra outro endereço, antes de pegar o próximo endereço deve fazer o mesmo processo de conversão lógica, aí sim você pega o próximo endereço. E neste próximo a mesma coisa, até você encontrar o valor 0xFFFF, se for este valor, significa que você chegou no final do arquivo e não precisa mais ler dados dele, portanto pode encerrar a execução.
Este trecho acima é a função mais básica de uma leitura de arquivos no FAT16, mas você pode otimizar e personalizar, criando outras funcionalidades dentro desta execução, como no caso do que o KiddieOS faz que é gerenciar permissão de acesso e "abrir" arquivos antes de ler, ou seja, criar uma tabela temporária de abertura de arquivos pra gerenciar melhor o acesso. E dentre várias outras coisas que você pode fazer.Eu já enfrentei problemas com caracteres ocultos. Consegui resolver pelo editor hexadecimal. Sobre o KBOS, eu havia meio que excluido o projeto porque eu não tinha ideias para colocar mais comandos, e, além disso, eu estou desenvolvendo outro sistema operacional chamado Arnix.
Arnix é um sistema 32-bits Unix-Like feito em assembly e C e que é multitasking e usa o sistema de arquivos FAT16. Optei pelo FAT16 porque além de eu já conhecer a estrutura FAT, eu não preciso me preocupar com carregar apenas alguns bits em cada cluster (como acontece no FAT12) e sim apenas ler 2 bytes. Por enquanto, estou desenvolvendo o segundo estágio do bootloader (que entra no modo protegido, configura o VESA e executa o kernel). Sobre o primeiro (VBR) eu usei uma de um projeto no github chamado BootProg (que o criador deixa as pessoas usarem sob uma licença).
Esta VBR ainda é provisória, planejo criar uma eu mesmo em breve
Eu já enfrentei problemas com caracteres ocultos. Consegui resolver pelo editor hexadecimal. Sobre o KBOS, eu havia meio que excluido o projeto porque eu não tinha ideias para colocar mais comandos,
Ah entendo man, normalmente também utilizo editores hexadecimais, principalmente o HxD, ele é bem simples. Atualmente estava utilizando ele junto com a depuração do VirtualBox pra comparar caracteres hexadecimais de uma Imagem BMP, pois estou tentando resolver uns bugs agora. Sobre as ideias de comandos, é algo que vem com o tempo, eu poderia te ajudar nessa questão, eu tenho várias ideias de comandos, só não tive tempo pra implementá-los. Porém já tenho tudo planejado para as próximas versões. Pode começar dos comandos mais básicos e essenciais que tem na maioria dos sistemas operacionais, com isso vai surgindo ideias.
eu estou desenvolvendo outro sistema operacional chamado Arnix.
Arnix é um sistema 32-bits Unix-Like feito em assembly e C e que é multitasking e usa o sistema de arquivos FAT16. Optei pelo FAT16 porque além de eu já conhecer a estrutura FAT, eu não preciso me preocupar com carregar apenas alguns bits em cada cluster (como acontece no FAT12) e sim apenas ler 2 bytes. Por enquanto, estou desenvolvendo o segundo estágio do bootloader (que entra no modo protegido, configura o VESA e executa o kernel). Sobre o primeiro (VBR) eu usei uma de um projeto no github chamado BootProg (que o criador deixa as pessoas usarem sob uma licença).
Sim, esse caso do FAT16 optei por ele por causa do mesmo motivo, ele não é tão limitado como o FAT12 mas também não é tão custoso de implementar como o FAT32 ou outros sistemas, ele ta ali no nível intermediário, por isso gostei dele também. Agora que legal que você tem outro SO, ainda tendo multitasking :D nem o KiddieOS tem isso ainda. Me lembro do vídeo de um gringo que ensinava a desenvolver exatamente isso, um kernel 32-bit multitasking em C e Assembly, mas não cheguei a ver pois não era minha prioridade no momento pois eu já tinha vários outros planos primeiro. O bom é que você pode juntar os conceitos, ao invés de desenvolver separadamente, implementar certos códigos Assembly do KiddieOS no Arnix ou você adaptar o código Asm para C, que é o que muitas vezes faço só que ao inverso, eu costumo adaptar códigos em C para Assembly. No caso dos estágios, eu só tenho o 1ª estágio, que é a VBR, que aliás você também poderia pegar alguns exemplos do meu código porque ele ta completo e é bem simples. O Modo protegido eu só alterno quando há um programa sendo executado em tempo real, pelo Shell16, aí eu posso executar programas de 32 bits em um kernel de 16 bits, já o VESA eu só configuro quando o usuário escolhe o modo gráfico (onde ta dando a tela preta). Ou seja, meu segundo estágio está tudo na execução do Kernel. A única coisa que eu faço antes da VBR é a execução da MBR, que lá terá a tabela de partição. Vamos dizer que meu 1ª estágio é a MBR e sua partição, e o 2ª a própria VBR. Daí pra frente tudo é o Kernel.
Então, estou há alguns dias tentando corrigir o bug da Tela preta no VESA, no entanto, não estou ficando o dia todo nisso, só algumas horas por dia, e enfrentei alguns problemas. Estou usando o depurador do VirtualBox e o editor hexa HxD pra comparar os bytes de uma imagem BMP. Um dos problemas são o seguinte:
Há alguns meses (acho que tem mais de 1 ano) eu estava trabalhando no modo gráfico, como: configurar o VESA, desenvolver janelas gráficas via Interrupção de software, criando o gerenciador gráfico, etc. Estava só nesta parte, e aí decidi depois focar no Shell com seus comandos, até pra mostrar em aulas e regularizar a questão do sistema de arquivos. Nesta regularização, acabei mexendo muito com o fat16.osf (sistema para operações de arquivos) e até criando rotinas personalizáveis para formatação de nomes de arquivos via Strings, deixando tudo mais fácil de implementar a longo prazo, assim um usuário/programador poderia inserir um diretório completo como "C:\users\myfile.txt" e as rotinas iriam processar isso automaticamente, se adaptando para o FAT16, e também implementei várias rotinas de permissão, etc... Só que aí eu acabei me esquecendo do Gerenciador gráfico que eu estava desenvolvendo kkkk Aí meio que abandonei ele temporariamente. Quando fui testar o VESA depois de meses, ele tava dando Tela preta e aí com as depurações eu percebi que um dos motivos era que ele dependia de muitas operações antiga do FAT16 (antes das atualizações) e eu não tinha modificado nada nele, e isso nos complicou. Uma das primeiras mudanças que tive que fazer foi a alteração do endereço antigo para o endereço novo dentro do gerenciador gráfico, pois eu tinha já feito as mudanças em outras partes do Kernel, como do endereço 0xC00 para 0x3000, e assim ele poderia ler as variáveis da tela em outro arquivo. Outra mudança que tive que fazer eram as formas que eu chamava operações de leitura dos arquivos BMP e do próprio Gerenciador por outro arquivo chamado WINMNG.OSF. Como eu já tinha mudado antes no FAT16.OSF, eu precisei alterei os caminhos de diretórios destes dois arquivos (BMP e OSF) e depois usar a implementar das rotinas do DOS, já que se tornaria bem mais fácil, pois o DOS já está praticamente completo certas rotinas. Outro problema que tive que adaptar foi no próprio Gerenciador, excluindo (ou pelo menos comentando) as chamadas da Interrupção 0xCE, que era pra ler arquivos no modo protegido, porém o modo de leitura era usando o Modo Virtual8086 do Processador, e esse modo não está funcionando mais no meu sistema, não consigo encontrar uma solução, já tentei de tudo. Então eu optei por não utilizar mais o modo virtual 8086 e adaptar tudo isso para um ATA Driver (Driver de Disco), algo que irei fazer em breve. Então, as mudanças que estou fazendo agora são provisórias, como carregar dois arquivos ainda em modo real para serem desenhados no gerenciador gráfico em modo protegido usando a memória alta. Depois do ATA Driver, aí irei modificar isso de novo.
Eu sinto que estou quase resolvendo os erros aqui, o outro problema que encontrei aqui é que os arquivos carregados pelo FAT16 eles apresentam divergências de leitura quando se trata de "Deslocar" o ponteiro do arquivo (Algo feito pela função seek porém a leitura de arquivos no DOS atualiza automaticamente o ponteiro). Quando os dados do arquivo ultrapassava o tamanho de 1 segmento (65535 bytes), era como se os dados voltasse a repetir lá do início, eu não deveria acontecer isso, quando fui ver agorinha, era simplesmente porque eu estava usando AX ao invés de EAX na leitura do ponteiro, ou seja, ele considerava apenas os 16 bits mais baixo de EAX,... agora eu consegui recuperar todos os dados de um arquivo de 192054 bytes divididos em 3 segmentos diferentes (Já depurei e confirmei estes dados hexadecimais), agora só resta eu juntá-los no gerenciador gráfico em uma única memória alta e assim continuar fazendo o que eu fazia como realizar a conversão dos dados BMP e desenhar na tela. Daí pra frente dando tudo certo, é só verificar as janelas gráficas se tá tudo em ordem. Então em breve estarei fechando essa Issue como concluída, enquanto isso vamos utilizá-la pra conversar sobre os sistemas. :)
Esta VBR ainda é provisória, planejo criar uma eu mesmo em breve
Sim, criar uma própria é uma boa escolha, se quiser usar a minha pra ajudar, sinta-se a vontade. :) Então, enquanto isso eu gostaria de perguntar algumas coisas: Até quantas Threads você consegue gerenciar no Arnix? Você utiliza algum tipo de estrutura como o TSS? (Ou alguma própria?); Utiliza interrupção de hardware ou de software para gerenciar as Threads? Você está carregando as estruturas do FAT16 na memória baixa (abaixo de 1 MB) ou na memória alta (Acima de 1 MB)? Se carrega na memória alta, utiliza algum tipo de driver para disco em modo protegido? Há quanto tempo está desenvolvendo o Arnix?
São só algumas perguntas pra gente se interagir e aprender um com o outro, acredito que através destas issues podemos tornar nossa interação produtiva também.
Eu sinto que estou quase resolvendo os erros aqui, o outro problema que encontrei aqui é que os arquivos carregados pelo FAT16 eles apresentam divergências de leitura quando se trata de "Deslocar" o ponteiro do arquivo (Algo feito pela função seek porém a leitura de arquivos no DOS atualiza automaticamente o ponteiro). Quando os dados do arquivo ultrapassava o tamanho de 1 segmento (65535 bytes), era como se os dados voltasse a repetir lá do início, eu não deveria acontecer isso, quando fui ver agorinha, era simplesmente porque eu estava usando AX ao invés de EAX na leitura do ponteiro, ou seja, ele considerava apenas os 16 bits mais baixo de EAX,... agora eu consegui recuperar todos os dados de um arquivo de 192054 bytes divididos em 3 segmentos diferentes (Já depurei e confirmei estes dados hexadecimais), agora só resta eu juntá-los no gerenciador gráfico em uma única memória alta e assim continuar fazendo o que eu fazia como realizar a conversão dos dados BMP e desenhar na tela. Daí pra frente dando tudo certo, é só verificar as janelas gráficas se tá tudo em ordem.
Eae meu amigo, consegui resolver aqui, deu tudo certo! Agora conseguimos entrar no gerenciador gráfico usando VESA e carregar imagens BMP completas, como no caso dessa flor. Agora vou testar com outras resoluções maiores (arquivos maiores) e as janelas gráficas pra ver como ta. Terminando isso, upando no git e você testando aí, vamos pra outra Issue. Só vou terminar aqui, aí te aviso tudo certinho.
Esta VBR ainda é provisória, planejo criar uma eu mesmo em breve
Sim, criar uma própria é uma boa escolha, se quiser usar a minha pra ajudar, sinta-se a vontade. :) Então, enquanto isso eu gostaria de perguntar algumas coisas: Até quantas Threads você consegue gerenciar no Arnix? Você utiliza algum tipo de estrutura como o TSS? (Ou alguma própria?); Utiliza interrupção de hardware ou de software para gerenciar as Threads? Você está carregando as estruturas do FAT16 na memória baixa (abaixo de 1 MB) ou na memória alta (Acima de 1 MB)? Se carrega na memória alta, utiliza algum tipo de driver para disco em modo protegido? Há quanto tempo está desenvolvendo o Arnix?
São só algumas perguntas pra gente se interagir e aprender um com o outro, acredito que através destas issues podemos tornar nossa interação produtiva também.
Eu ainda vou implementar o multitasking (estou desenvolvendo o bootloader segundo estágio). Mas eu carrego o FAT na memória baixa, porque a configuração do modo real padrão não permite. Ainda posso ativar o A20 mas eu pretendo copiar o kernel para memória alta no modo protegido. Inclusive eu tinha escrito com base na sua a leitura de disco para setores mas eu havia substituido ela e agora vou reescrever. O Arnix está sendo desenvolvido há bastante tempo de eu tentando códigos para a VBR e demorando. Agora que eu tinha decidido o rumo comecei.
Percebi que o KiddieOS está crescrendo mais e mais. Já tem leitura BMP e bastante coisa.
Estou pensando em criar driver ATA no Arnix que interage com o disco sem interrupções para não ter que trocar para o modo real e voltar para o protegido.
Quando lançar a versão corrigida eu vou testar com alguns BMP. Inclusive consegui um BMP de teste:
Esta VBR ainda é provisória, planejo criar uma eu mesmo em breve
Sim, criar uma própria é uma boa escolha, se quiser usar a minha pra ajudar, sinta-se a vontade. :) Então, enquanto isso eu gostaria de perguntar algumas coisas: Até quantas Threads você consegue gerenciar no Arnix? Você utiliza algum tipo de estrutura como o TSS? (Ou alguma própria?); Utiliza interrupção de hardware ou de software para gerenciar as Threads? Você está carregando as estruturas do FAT16 na memória baixa (abaixo de 1 MB) ou na memória alta (Acima de 1 MB)? Se carrega na memória alta, utiliza algum tipo de driver para disco em modo protegido? Há quanto tempo está desenvolvendo o Arnix?
São só algumas perguntas pra gente se interagir e aprender um com o outro, acredito que através destas issues podemos tornar nossa interação produtiva também.Eu ainda vou implementar o multitasking (estou desenvolvendo o bootloader segundo estágio). Mas eu carrego o FAT na memória baixa, porque a configuração do modo real padrão não permite. Ainda posso ativar o A20 mas eu pretendo copiar o kernel para memória alta no modo protegido. Inclusive eu tinha escrito com base na sua a leitura de disco para setores mas eu havia substituido ela e agora vou reescrever. O Arnix está sendo desenvolvido há bastante tempo de eu tentando códigos para a VBR e demorando. Agora que eu tinha decidido o rumo comecei.
Percebi que o KiddieOS está crescrendo mais e mais. Já tem leitura BMP e bastante coisa. Estou pensando em criar driver ATA no Arnix que interage com o disco sem interrupções para não ter que trocar para o modo real e voltar para o protegido.
Quando lançar a versão corrigida eu vou testar com alguns BMP. Inclusive consegui um BMP de teste:
OBS: Converti em JPG para o github suportar
Eu ainda vou implementar o multitasking (estou desenvolvendo o bootloader segundo estágio). Mas eu carrego o FAT na memória baixa, porque a configuração do modo real padrão não permite. Ainda posso ativar o A20 mas eu pretendo copiar o kernel para memória alta no modo protegido. Inclusive eu tinha escrito com base na sua a leitura de disco para setores mas eu havia substituido ela e agora vou reescrever. O Arnix está sendo desenvolvido há bastante tempo de eu tentando códigos para a VBR e demorando. Agora que eu tinha decidido o rumo comecei.
Ah muito legal sobre o multitasking. Vai ver podemos compartilhar esses conhecimentos juntos. Também carrego o FAT na memória baixa devido eu não ter o Driver ATA. Vi que você falou que vai desenvolver este Driver, é uma boa, estou prestes a fazer isso também, até a próxima versão quero está resolvendo isso. Mas realmente, eu entendo a demora, também passo por isso, sinto que estou bem atrasado no sistema, muitas vezes demoro demais pra implementar um certo sisteminha, ainda mais quando tem pouco material disponível e didático na internet.
Percebi que o KiddieOS está crescrendo mais e mais. Já tem leitura BMP e bastante coisa. Estou pensando em criar driver ATA no Arnix que interage com o disco sem interrupções para não ter que trocar para o modo real e voltar para o protegido.
Quando lançar a versão corrigida eu vou testar com alguns BMP. Inclusive consegui um BMP de teste:
Sim, ta crescendo aos poucos, mas já era pra tá mais avançado kkk Negócio que não anda, agora que fui arrumar um tempo pra mexer mesmo, acabei me inspirando na resolução desse bug e fiz um novo sisteminha, tipo um programa DOS que carregar o gerenciador gráfico, só que ao invés de só carregar ele também pode fazer o usuário escolher sua própria imagem pra ser imprimida na tela. É aí que sua ideia entra, de exibir o seu BMP de teste, agora você vai poder fazer isso de forma bem mais prática sem nem precisar incluir diretamente no código. Só passar no argumento via linha de comando no executável "winsetup.exe" do diretório "K:\KiddieOS\Users". Mas também pode incluir no código se quiser algo mais fixo.
Você pode ta consultando lá a última versão postada mais recente, postei agorinha e fiz um vídeo mostrando isso também no Youtube, mas se tu quiser, posso te passar o link aqui, tanto do repositório atualizado, quanto da Pull Request, que vai conter as descrições detalhadas do que foi atualizado:
Repositório atualizado:
https://github.com/FrancisBFTC/KiddieOS_Development/tree/KiddieOS_v1.3.10
Descrições dos bugs corrigidos e novas features:
#15
Aí você testa no seu PC, pode não estar 100% perfeito em algumas situações, mas pelo menos a tela preta no VESA foi corrigida e agora pode ser iniciada pelos dois métodos: Entrar no menu inicial do Kernel e executar o programa winsetup no Shell escolhendo sua própria imagem ou deixando sem argumentos no comando pra imprimir a imagem padrão. Vou te passar o vídeo, e aí você testando e estando tudo Okay, fechamos essa Issue, realizo o merge e partimos para as próximas issues lá:
https://www.youtube.com/watch?v=z_pFiyRMbts
Uma imagem que usei como thumb, mas ela também mostra a outra maneira de mostrar sua própria imagem pelo Shell16 pelo "winsetup.exe" (A tela verde ao lado):
Deu certo aqui.
Okay friend. Lagartixinha fofa kkk. Então deu certo. Se você puder ler as instruções lá na Pull Request pra compreender algumas orientações, eu agradeço (Se já não tiver lido). Eu faço algumas considerações lá. Eu vou fechar lá dando o merge na Main, mas você ainda consegue encontrar na parte de fechados. Essa Issue também será fechada com este comentário. Vamos nos interagir agora na outra Issue do "Travamento quando não há comandos". Valeu man!