68K ou coisa assim, again

por **mastk** » 14 Out 2006 21:06

Bem só pra continuar

consegui comprar um 6845 essa sexta, parece q ele vai me facilitar muito a vida. Quando ao q vc tinha comentado no outro forum, eu coloquei slot pra até 2 megas de memoria eeprom na placa-base (acho q não irei fazer um programa maior q isso por hora XDXD ), e espero conseguir usar um HD, mas depois q tudo tiver OK.

Vcs teriam algum info a mais do 6845? Só achei o Ds dele, mas não entendi como opera-lo...

por **msamsoniuk** » 15 Out 2006 01:15

bom, o 6845 foi utilizado originalmente nas placas IBM MDA, que geravam apenas texto, e mais tarde adaptado nas placas IBM CGA, onde conseguiram fazer ele gerar tambem graficos. eu recomendo vc procurar por aih os projetos destas duas placas e compreender o mecanismo, pois o 6845 precisa de alguns circuitos adicionais para que tudo funcione bem.

bom, soh para adiantar, o 6845 usado na placa MDA gera a temporizacao necessaria para uma tela 80x25 caracteres, onde os caracteres sao gerados por um circuito gerador de caracteres, que contem uma ROM com caracteres 9x14. em cada acesso do 6845, ele puxa uma word de 16 bits, que contem o caracter ascii a ser exibido e um atributo (piscante, intensificado, sublinhado, video reverso, etc). o caracter ascii eh enviado ao gerador de caracteres, que retorna um stream de 9 bits. entao a cada linha temos 80 caracteres, que geram um stream de 720 pixels. as linhas sao incrementadas no gerador de caracteres atraves de um enderecamento separado no 6845, entao vc vai ver exatamente isso: enderecamento de memoria (q endereca os 80x25 caracteres) e enderecamento de linhas (q endereca as 14 linhas de um caracter). 25 linhas de caracteres vezes 14 linhas do gerador totaliza 350 linhas, portanto a resolucao grafica do circuito MDA eh de 720x350 pixels, embora ele se limite a gerar apenas os 80x25 caracteres possiveis.

note bem: o 6845 possui enderecamento de memoria (80x25 caracteres) e enderecamento de caracter no gerador 9x14, onde ele gera a sinalizacao para as 14 linhas. em essencia, o 6845 eh um classico CRTC orientado a caracter.

bom, a evolucao do CGA consiste em incluir circuitos adicionais no 6845 para fazer ele gerar graficos. isso nao eh tao dificil quanto parece, pois vejamos: uma tela 80x25 puxa em cada linha 80 bytes para o gerador de caracteres. se considerarmos um pixel como sendo um bit, temos entao 640 pixels e podemos trocar o gerador de caracteres por um shift registers de 8 bits, que opera a cadencia de 14MHz. assim, sem grandes modificacoes, o circuito do MDA geraria graficos de 640 pixels na horizontal. no caso da vertical, o MDA possui 25 linhas de 14 linhas cada, totalizando 350. no CGA, diminuimos o numero de linhas do caracter para 2 na programacao do 6845 e aumentamos o numero de linhas de 25 para 100, ou seja 100 caracteres de 2 linhas, assim temos 640x200 pixels, mapeados diretamente pelo 6845, dentro de um quadro de sincronismo compativel com NTSC, de 15750Hz x 60Hz (262 linhas). o motivo de nao usar o valor 200 diretamente eh que o 6845 nao pode contar ateh o 262, pois os registros sao de 8 bits, entao contamos ateh 131 e quebramos a tela em 2 metades, ficando um buffer com as linhas pares e outro com as linhas impares, o que eh gerado pelo contador de linha de caracter, que passa a ser o bit de endereco MSB.

existe uma outra versao da historia sobre o motivo de existir um buffer para linhas pares e outro para linhas impares na CGA, mas efetivamente eu nunca olhei o projeto e, olhando para os recursos do 6845 e a forma com que ele funciona, achei que a explicacao acima eh consistente. de qq forma, como vou explicar na sequencia, vc nao precisa seguir essa construcao da IBM.

uma coisa que vc poderia fazer eh criar um prototipo usando o 6845, para testar a programacao dele, gerando os sinais de hsync, blank e vsync. depois poderia bolar uma forma inteligente de usar os sinais de enderecamento e sincronizar isso com os DACs ou shift-registers principais. uma dica que eu posso te dar eh que muita da complicacao q a IBM colocou no CGA, de separar a imagem em 2 buffers, pode ser evitada usando resolucoes do tipo 2^n, como 256x192 ou 512x384, pois isso permite intercalar bits de enderecamento com bits de varredura de linha de caracter diretamente. de fato, usando essa ideia, vc poderia enderecar nada menos que 512KB usando o 6845 e gerar resolucoes tao altas quanto 1024x768.

claro q dai tem o problema da limitacao de clock no componente, mas nesse caso, vc simplesmente aumenta a largura do bus de memoria, usando 16 ou 32 bits. um detalhe extra: o 6845 nao preve uso de memoria dram (nao multiplexa linhas, nao faz refresh) e nao preve mecanismo de partilhamento do bus de memoria.

por **KrafT** » 15 Out 2006 10:59

MTASk... Não seria de vc direcionar todo esse esforço a um ColdFire e eventualmente um FPGA?

Eu também já me empenhei a fazer algo com um Z80, mas depois de fazer funcionar o básico e começar a juntar as coisas, ví que não valia apena...

A não ser que vc seja tão maníaco como: http://www.homebrewcpu.com/

Mas de qualquer forma, admiro seu empenho.

EDIT: Confundir FPGA com BGA foi soda...

por **fenix3** » 16 Out 2006 19:37

Eu tambem, eu tambem...

por **msamsoniuk** » 16 Out 2006 22:16

imagina vc fazendo um destes aqui kraft:

http://www.howell1964.freeserve.co.uk/p ... pp_f02.png

o problema eh que o coldfire nao tem um CRTC integrado, mas o coldfire nao eh uma mah ideia: eu estava dando uma olhada no MCF5270 e gostei dele, pois alem de possuir controlador sdram e ethernet integrado, ele possui um pratico encapsulamento QFP-160 e canais de DMA.

em relacao ao video, uma possibilidade muito interessante que eu estava analisando seria ativar um destes canais de DMA a cadencia fixa de 3.5795 MHz, assim ele iria transferir da memoria para uma porta de 32 bits um fluxo continuo de 14.318 MB/s, transferindo um block de 477750 bytes, que compoe um quadro de video inteiro de 910x525 pixels, inclusive com os sinais de sincronismo, que seriam pixels especiais. claro que a cada transferencia completa de um frame seria necessario bolar um mecanismo para o controlador de DMA voltar ao inicio do buffer automaticamente. uma solucao seria usar dois canais de DMA, de modo que enquanto um esta transferindo, o outro seta sendo setado para o inicio do buffer de video, assim, eles ficam se alternando um atras do outro.

da imagem 910x525, apenas 768x480 pixels seriam efetivamente visiveis na imagem, sendo o resto preenchido com zeros e, nas devidas posicoes, pixels especiais que ativam os sinais hsync e vsync.

embora a ideia seja meio cru e tenha alguns detalhes cabeludos para resolver, acho que seria uma alternativa aos CRTCs, como o 6845 e, eventualmente, poderia ser implementado algo similar mesmo usando uma logica mais convencional, questao pensar um pouco mais.

um aprimoramento interessante nessa ideia seria implementar um ADC para digitalizar video e, seguindo a mesma ideia, pegando um frame NTSC inteiro, inclusive com os sinais de sincronismo. se botar um LCD e um software decente, vira quase um carissimo AWG da tektronix!

embora ninguem provavelmente vah usar, por via das duvidas, eu corrigi os divisores para gerar uma temporizacao NTSC mais correta...

por **Fábio Pereira** » 17 Out 2006 09:44

Também tem de ver o que exatamente o Mastk pretende fazer com esse vídeo.

Se for algo relacionado a video-games, aí acho que a CPU pode ficar bem argolada se tiver de gerar vídeo e cuidar da manipulação da imagem.

Uma alternativa para geração de vídeo seria utilizar um CPLD ou mesmo um FPGA (dependendo da complexidade do hardware) para implementar o circuito de geração de vídeo (como aquele que o Marcelo citou).

Até +

por **mastk** » 25 Out 2006 20:30

Eh q eu gostaria de pegar um coldfire, eu gostaria, mas no momento estou sem recursos e sem tempo, projeto da escola vai me drenar umas semanas, espero q no começo de dezembro resolva todos os problemas.

Pra CLPDs/FPGAs msm problema, só q vou de altera, q são compraveis, pretendo usa-los em breve pra servir de CTRC, mais parrudos.

BGA pra mim é uma coisa muito distante, vcs conseguem lidar com eles, já? tem como fazer projetos "caseiros" com BGAs?

O 6845, agora tá parecendo bem simples, nesse APP q o SAM postou tudo tá bem simples tirado aquele 7493 e a porta E com as entradas invertidas, não é mais natural jogar o sinal do osc. pro shifter logo?

por **msamsoniuk** » 25 Out 2006 23:53

eu acho que aquilo eh para sincronizar os delays do 6845/memoria/rom com o andamento do shift register. note que aquele circuito eh para gerar uma tela texto, provavelmente de 80x25 caracteres, entao o 6845 puxa da memoria um byte q indica o caracter e entao uma rom manda para o shift register o bitmap do caracter, exatamente no instante em que o ultimo pixel do caracter anterior saiu do shift register.

se vc tirar a rom de caracteres, os bytes puxados pelo 6845 iriam direto para o shift register e ainda assim teria que existir esse tipo de sincronismo. o 6845 iria pensar q sua tela eh 80x100 caracteres, por exemplo, mas na verdade vc teria 640 pixels nesses 80 bytes. e nas 100 linhas, na verdade, vc teria caracteres de 2 linhas de altura, usando o pino RA0 como um truque, selecionando linhas pares/impares e dobrando a resolucao final, para 640x200 pixels, que eh a resolucao do CGA. por sinal eu descolei uma tabela com os valores utilizados no 6845 para texto e graficos no PC:

Código: Selecionar todos: Registers: Accessed through ports 3B5 & 3D5 VALID VALUES MONO CO40 CO80 GRPH 00 - Horiz. total characters 61 38 71 38 01 - Horiz. displayed characters per line 50 28 50 28 02 - Horiz. synch position 52 2D 5A 2D 03 - Horiz. synch width in characters 0F 0A 0A 0A 04 - Vert. total lines 19 1F 1F 7F 05 - Vert. total adjust (scan lines) 06 06 06 06 06 - Vert. displayed rows 19 19 19 64 07 - Vert. synch position (character rows) 19 1C 1C 70 08 - Interlace mode 02 02 02 02 09 - Maximum scan line address 0D 07 07 01 0A - Cursor start (scan line) 0B 06 06 06 0B - Cursor end (scan line) 0C 07 07 07 0C - Start address (MSB) 00 00 00 00 0D - Start address (LSB) 00 00 00 00 0E - Cursor address (MSB) (read/write) 00 -- -- -- 0F - Cursor address (LSB) (read/write) 00 -- -- -- 10 - Light pen (MSB) (read only) -- -- -- -- 11 - Light pen (LSB) (read only) -- -- -- -- - Registers 00-0D are write only, registers 0E-0F are read/write and registers 10-11 are read only - Cursor address is calculated with using the following (row*80)+col

quem quiser tomar como exercicio, tem q converter, pq tah em hexa. e alinhar a tabela, pq tah tudo torto! hehehe

nota que no grafico ele seta o tamanho da tela em 40x100 (registro 1 e 6) e seta a altura do caracter para 1 (registro 9), isso significa que o 6845 gera temporaizacao para 40x200 bytes, daih a placa de video propriamente dita se vira com o resto. com 40x200 bytes, vc teria 320x200 monocromatico. dobrando e recalculando os valores, vc teria uma configuracao para 640x200.

outra opcao seria nao usar um shift register, mas sim um DAC. nesse caso eu suspeito que o 6845 nao conseguiria gerar a temporizacao para algo alem de 160x200 pixels se vc usasse um DAC de 8 bits. se usar um bus de 16 bits, puxar uma word e alternar os bytes, conseguiria dobrar isto, ou seja, teria 320x200. se aumentar o tamanho da word ou diminuir o tamanho dos pixels, usando 16 bits e pixels de 4 bits (16 cores), vc teria 640x200. suspeito que seria possivel fazer ateh mesmo 640x400 pixels, entrelacado, nesse caso vc teria que aumentar a altura de caracter de 2 para 4 (seria o valor 3 no registro 9), mas vc teria o buffer de memoria quebrado em 4 partes distintas, ficaria um pouco confuso para programar.

algumas ideias adicionais de uso do 6845:

http://www.howell1964.freeserve.co.uk/l ... _clone.htm

ali explica sutilezas do 6845, como alguns registros cujo valor eh o valor total-1.

uma forma interessante de contornar essa separacao do buffer em linhas pares/impares ou mais separacoes seria usar resolucoes q sao potencia de 2, como 256, 512, 1024, etc. isso facilita bastante pq permite encadear os pinos RAx com os pinos MAx: por exemplo, supondo um display de 64x48 caracteres e caracteres de 8x8, para uma tela monocromatica vc poderia idealizar caracteres 8x8 imaginarios. os 64 bytes que chegam fornecem 512 pixels monocromaticos, que vao para um shift register. os 64 bytes sao enderecados pelos 6 bits menos significativos do bus de endereco (MA0-5). entao vc tem 48 linhas de caracteres, sendo cada caracter com 8 linhas, enderecados pelos pinos RA0-2 e pelos restantes MA6-A11, com mais 6 bits. como os pinos avancam em sequencia e temos potencia de 2 ali, vc poderia simplesmente construir:

[MA0-5 RA0-2 MA6-11] = 15 bits de endereco (na ordem mostrada)

e isso forma um buffer linear de 512x384 pixels (precisa ajustar isso dentro de um quadro NTSC e ativar o interlace ou ajustar em um quadro VGA/70Hz, de 400 linhas). talvez existisse algum detalhe extra relacionado a delay, enfim, uma outra opcao seria usar o 6845 apenas para gerar as temporizacoes, de modo que o buffer mesmo estaria sendo varrido por um canal de DMA (ou circuito equivalente, como 4x 7493 ou um chip de DMA de Z80, formando os 15 bits do buffer de video) que manda os bytes para um DAC.

enfim, eu diria que para comecar, se vc conseguir gerar os sinais de sync e blank corretamente, formando um quadrado branco com bordas pretas (sinal fixo mesmo, ativado pelo pino blank), jah eh meio caminho andado. depois tem q escolher uma arquitetura para memoria e pixels, o que vai definir se vai usar shift register, latches, DACs, etc.

por **mastk** » 06 Nov 2006 19:46

Maravilho o 6845 XD

Esse fim de semana trabalhei no placa, não estou conseguindo fazer o 68K operar em loop aberto, com a memoria RAM.

Quando inicio o PIC, deixo ele fora do barramento. Depois seto apenas o BR e aguardando o BG para assumir o barramento. Limpo todo a RAM e quando entrego o barramento o 68K fica em HALT pra sempre, msm dando um pulso de reset, nem do PIC, nem na mão.

Tó meio perdido, não sei onde pode haver erro, no teste com resistores de pull-down, não tive problemas com os controles asinc.

por **msamsoniuk** » 07 Nov 2006 12:12

voce pode debugar os sinais do 68000 para ver efetivamente o que esta ocorrendo. vc pode montar um circuito simples do tipo set/reset para controlar o pino DTACK, mantendo ele normalmente negado. creio que vc pode usar o sinal AS para resetar DTACK e um botao para setar, assim, cada vez q o 68000 inicia um ciclo de barramento o sinal DTACK vai ser negado e ele vai inserir infinitos wait states, permitindo vc tranquilamente verificar o estado de todos os sinais. entao vc aperta o botao para liberar DTACK, ele completa o ciclo e o proximo AS bloqueia ele novamente. vc pode fazer o debounce do botao usando o PIC.

por outro lado, se ele esta ativando HALT (ele eh bi-direcional), eh porque ele esta detectando uma dupla falha de barramento, o que eh acionado externamente atraves do sinal BERR (bus error) ou internamente quando os registros PC ou USP apontam para um endereco impar (tanto o PC quanto o USP sao obrigatoriamente pares pq possuem alinhamento multiplo de 16 bits). se tudo estiver ok no debug dos sinais, essa condicao pode estar sendo gerada por falha no clock ou falha na alimentacao, nesse caso o conteudo do PC ou USP pode estar ficando corrompido e forcando eles a apontar para enderecos impares.

por **mastk** » 26 Nov 2006 20:01

Esse fds esqueci meu gravador na empressa e tive q fazer com 555, 74hc74 e um 74hc00 o circuito pra negar o DTACK a cada subida de nivel do AS. Com a memoria não iniciada fica tudo instavel, tb vai saber o q aparece na memoria durante o power-up.

Outro erro q achei foi nas rotinas de limpeza da memoria no PIC, o q estava fazendo o HALT fica ativo sempre.

Estou desenvolvendo uma placa no KICAD pro sistema tb, mas só vai ficar pronta nas ferias...

Imagem

por **msamsoniuk** » 27 Nov 2006 15:59

eu pensei em uma outra forma talvez mais simples de gravar uma eprom/sram utilizando o proprio 68000 para gerar enderecos, dispensando o uso de latches e buffers extras. a ideia seria fazer um emulador de rom, usando apenas o bus de dados e os pinos AS, A23 e DTACK. o pino AS em conjunto com A23 seria utilizado para indicar o inicio do ciclo, de modo que o espaco para a emulacao de rom seria quando A23=0, ficando os dispositivos reais na outra metade do espaco de memoria. como o 68000 apenas pode ler words da rom, podemos ignorar os sinais RW, UDS e LDS. a temporizacao nao eh muito critica: AS indica o inicio do ciclo corrente, o microcontrolador coloca uma word de 16 bits no bus e ativa DTACK, que por sua vez deve ser negado quando AS for negado pelo 68000, permitindo que o proximo ciclo comece sem pegar a ponta do DTACK do ciclo anterior.

o truque para gravar dados consiste justamente em enviar sucessivamente para o 68000 varias instrucoes "move.l valor,endereco", que consistem cada uma em nada menos do que 5 words de 16 bits e permite gravar um valor de 32 bits em um endereco qualquer do espaco de 32 bits dele. feita a gravacao na memoria ram, voce pode simplesmente enviar a instrucao "jmp endereco", que consiste em 3 words de 16 bits e ele vai saltar para o endereco que contem o codigo que vc acabou de enviar. acho que se for bem bolado o circuito, eh possivel eliminar praticamente todos os circuitos de apoio e produzir um circuito com o 68000 extremamente simples e didatico.

por **mastk** » 18 Dez 2006 11:09

Com as ferias, retoemi o projeto, os problemas q tinha era é o seguinte, o 68K nao roda em loop aberto como deveria, disso, implementei uma rotinas simples pra checar toda a memoria, e apresentar no terminal qlqr valor diferente de zero, disso obtive milhares de erros, como resultado pude encotrar uma linha de endereco aberta, reparando-a tudo o sistema funciona conforme o planejado.

No momento tenho apenas o comando de RESET operando devidamente das funcoes de debug, creio q com o hardware q tenho no momento nao poderei implemente funcoes como passo-a-passo, mas ate ai basta algumas pequenas alteracoes ( q vou evitar por hora ).

Uma duvida q me surgiu agora e quanto ao conteudo da EEPROM se colocado na RAM, qual o MSB/LSB do S19 e ate msm qual o primeiro byte da word q recebo.

Essa ideia e muita sam, mas se for pra desmontar tudo o q ja fiz -.-'

por **msamsoniuk** » 19 Dez 2006 00:06

questao interessante hehehe.

o 68000 nao tem pino A0, pois ele eh decodificado internamente nos pinos UDS e LDS, que sao justamente os strobes de dados superior (D8-15, quando A0=0) e inferior (D0-7, quando A0=1). acessos no tamanho de word sao obrigatoriamente alinhados em enderecos pares, portanto uma word de tamanho D0-15 estaria posicionada no endereco A0=0. se vc tentar ler ela com A0=1, o 68000 ativa uma excessao para tratamento de erro de alinhamento de endereco.

baseado nisso, teriamos algo como:

Código: Selecionar todos: |D15 D8|D7 D0| |---------------+---------------| |endereco 000000|endereco 000001| |---------------+---------------| |endereco 000002|endereco 000003| |---------------+---------------| |endereco 000004|endereco 000005| |---------------+---------------| | ... | ... |

assim, um sequencia de dados byte a byte 0x12, 0x34, 0x56, 0x78 seria colocada na memoria assim:

Código: Selecionar todos: |D15 D8|D7 D0| |---------------+---------------| | 0x12 | 0x34 | |---------------+---------------| | 0x56 | 0x78 | |---------------+---------------| | ... | ... |

o que eh a mesma sequencia que vc usaria se fosse interpretar como word (0x1234, 0x5678) ou como longword (0x12345678). em resumo, a organizacao de memoria do 68000 eh do tipo MSB-first. se vc tiver acesso, pega o PDF chamado M68000UM/AD, na pagina 2-6 e 2-7 tem um desenho mais bonito indicando a posicao dos bytes, words e longwords.

relativo ao S19, voce pode avaliar ele byte a byte. o bit A0 do endereco inicial vai indicar se vc comeca a colocar dados pelo MSB ou LSB do bus. se for par, voce comeca pelo MSB e o proximo byte vai no LSB desse mesmo endereco. se for impar, voce comeca pelo LSB e o proximo byte vai ser o MSB do proximo endereco.

supostamente, o compilador deve otimizar para que os enderecos sejam sempre pares, pois o PC e SP soh enderecam valores pares.

por **mastk** » 27 Dez 2006 15:39

Desculpe a pergunta idiota sam.

Consegui o 68K esta respondendo as intruções q coloca no EEPROM, enfim fui um programa muito complexo, mas deu certo XD, UM ORG 0X0000 e um STOP, a CPU parou como o esperado, porem estou tendo problemas novamente, o PIC16f877 q estava usando saturou, comprei um substitudo ( PIC16f877a) pra ele ontem e ele não esta rodando.

68K ou coisa assim, again

68K ou coisa assim, again

Quem está online