Um Modo pouco usado em PROGRAMAÇÃO de MEGA DRIVE.

Página do episódio: www.manualdocodigo.com.br/curso-assembly-snes-mega-parte59/ Como montar o ambiente: www.manualdocodigo.com.br/curso-assembly-snes-mega-parte47/ Página do Fabien Sanglard (CPS-1): fabiensanglard.net/cpsb/index.html Código do episódio para rodar: github.com/Dgdiniz/retro-level-programming/tree/master/megadrive/tutorials/addressing-modes-absolute-short

[@alca-techsoftwarestudio9140]

Muito bom o video, é raro ver alguém trazendo esse tipo de conteúdo em português (apesar do Brasil ter uma comunidade bem ativa de desenvolvimento Retro)... Espero que você poste mais em breve, estou ansioso pelos próximos videos! Um complemento: Se não me engano os endereços na maioria dos modos de indexação de memoria são calculados via displacement do Program Counter, ou seja, o que o assembler coloca ali na verdade é um offset que somado ao valor atual do program counter resulta no endereço que você esta indexando, justamente por isso a extensão do endereço é "signed", se fosse Unsigned você até poderia pular 64Kib de memoria, mas só permitiria indexar endereços maiores do que o endereço atual do program counter, então só daria pra pular "pra frente", com a extensão do endereço sendo signed significa que você pode pular para endereços maiores e menores.... Algumas instruções permitem você usar até mesmo um Displacement de 8bits, isso permite indexar apenas 127 bytes pra frente ou para trás, mas a vantagem é que o offset pode ser encapsulado no próprio opcode da instrução o que reduz o numero de ciclos de acesso ao barramento, isso economiza um bom numero de ciclos de Clock, principalmente em loop's! Alguns assemblers fazem esse gerenciamento para você automaticamente, eles calculam o endereço que você esta indexando e ajustam automaticamente o data wide do displacement para ser o menor possível a comportar esse endereço.

[@EuSouRCS]

Que universo interessante esse da programação,você é ótimo explicando,eu sou completamente novo no assunto e já consegui absorver o conceito! Muito obrigado por fazer o que Ama!

[@pablouesc]

Vim pelo Akita! Tenho certeza que vou curtir o canal

Valeu Pablo, espero que goste...

[@widneysilvarj]

Vim através do canal do Fábio Akita...parabens pelo conteudo

Valeu Widney...

[@ronaldlima9231]

seria muito legal vc fazer uma playlist de estrutura de dados em c, lista estática, lista dinâmica, pilha, filas e etc.

Tem coisas do tipo espalhada em vários vídeos meus. Quero explicar algumas estruturas de dados usando assembly tb.

[@nelioalves4185]

Fala Douglas, parabéns pelo seu canal e obrigado por compartilhar seu conhecimento. Sou fã de games retrô e estou acompanhando o seu curso de Assembly. Gostaria de pedir se poderia numerar os videos pra quando a gente parar com a numeração ajudaria voltar na aula pra rever. Obrigado meu amigo.

Acessa o site do canal que lá tem tudo numerado e vários vídeos tem os tutoriais em texto.

[@wsricardo23]

Vim através do canal do Fábio Akita. Legal seu conteúdo.

Valeu Wanderson, seja bem-vindo.

[@MultiCuzido]

Quando o Akita menciona ele? Queria dar uma olhada.

[@wsricardo23]

@@MultiCuzido Nesse vídeo kzbin.info/www/bejne/q5_Te5qjn7l_e8k

[@ryonagana]

Em C na teoria então o absolute long seria um ponteiro far e absolute short ponteiro near como era usado antigamente na era DOS ate meados dos anos 90?

Acho que até poderia ser, mas acho que os ponteiros far/near tem mais a ver com o absolute e absolute long do Snes, onde o absolute normal seria um endereço de 16 bits dentro do banco (segmento) atual. Já o far seria um endereço de 32 bits que especifica a posição final.

[@ryonagana]

@ entendi, parabens pelo seus video to sempre assistindo, adoro esse tipo de conteudo: programação e jogos hahaha

[@diegocrusius]

me pergunto se é possivel fazer essa otimização usando o SGDK

[@1975rcm]

Olá amigo. Deixe-me tirar uma dúvida com vc: O MD foi baseado no X68000, não foi? Agora, da mesma forma que existe emuladores para diversos sistemas, também existe para o sharp x68000. Não é possível pegar o melhor emulador para este computador e "ampliar" as especificações do sharp para bem acima da última versão de 93. Ou seja: performance da cpu, Vram, Rom, Ram, Sram, mais cores, mais sprites, etc.., e ao mesmo tempo compativel com o MD? Talvez duas ou três vezes a capacidade do último modelo lançado? Criar um excelente emulador de 16 bits, utilizando as caracteristicas dos processadores atuais? Assim , vc tem desde os jogos do MD até a possibilidade de criar jogos, ou reprogramar jogos do MD, para ter muito mais qualidade de imagem e som? Obrigado pela atenção.

Olá, você poderia fazer isso que você falou. Você poderia pegar o melhor emulador de Mega por exemplo e colocar mais clock, melhorar o chip de vídeo e de som e turbinar da maneira que você imaginar. Porém isso seria outro console e os jogos provavelmente não seriam compatíveis. Os jogos originais de Mega por exemplo foram feitos para o console do Mega, então eles usam os endereços dos registradores dos chips dentro do console pra acessar as funcionalidades disponibilizadas. Se vc mudar algum desses endereços o jogo já não vai funcionar. Se adicionar mais efeitos de vídeos os jogos originais não vão usar pois não sabem da existência desse novo efeito. Se aumentar o clock pode causar problemas na lógica do jogo, pois vai conseguir fazer muito mais coisa por frame, o que pode quebrar alguma coisa dependendo de como o jogo foi implementado. Então vc poderia fazer o que vc disse e criar um videgame único seu com muitos efeitos novos, porém teria que criar os jogos do zero ou fazer uma boa adaptação em jogos já existentes. Abraço....

[@1975rcm]

Obrigado irmão pela resposta. Agora, eu quero levantar a bola pelo lado não do leigo, com eu, ,mas sim do profissional da programação. Eu me lembro, acredito que foi na época do Saturn, uma das reclamações feitas para a SEGA, foi de não consultar, não procurar saber o que os desenvolvedores queriam. O que estes buscavam em termos de hardware, possibilidades de ferramentas novas, poder de processamento, facilidade de programação, mídia utilizada, (esta no caso do N64), que, por fim, não foram escutadas pelos criadores de hardware. É daí que nasce a minha pergunta: Se perguntassem a você o que deveria ter um equipamento ou emulador que pudessem elevar a geração dos 16 bits a ter jogos ao nível "state of art" ? Uma configuração que todo programador, design, pudessem criar o jogo do seus sonhos, (lembrando que falamos em termos de 4ª geração), sem limitações impostas pelo hardware. Mais uma vez, obrigado pela atenção.

[@carloshenrique-ov5nk]

@@1975rcm a gente vivencia isso hj em dia. sem limitações impostas pelo hardware, ou quase isso .