68K ou coisa assim, again

[enigmabox]

Marcelo,

Nem me fale em estudo... Se conseguir passar na Fuvest o bicho vai pegar, ai não terei mas tempo pra nada.....

[enigmabox]

Marcelo,

Estou retornando ao projeto do MC68030, agora consegui mais memoria o que será possivel instalar um banco de RAM 512K x 32bits.
No projeto antigo eu tinha somente 512K x 16bits.
Será que é possivel instalar um RTOS, com essa capacidade de memória?
Consegui também um MC6845 e uma memoria de 512K x 8 bits 70ns. Tô pensando em montar uma interface de texto de 80 colunas com o MC6845, talves ligando junto com a placa grafica MC6847, ambas com endereçamento de memoria separadas.
Ou seria melhor fazer uma placa grafica mais robusta com uma CPU e CPLD?
O que tu acha?

[fabim]

Isso quer dizer que o caixinha de surpresa, não passou na fuvest... hehehe

[enigmabox]

Fabim,

A caixinha de surpresa só vai saber se passou no dia 4 de Fev.
Se a caixinha passar o projeto estará abandonado, com possível depenação para venda de peças....
Enquanto isso estou esquentando os neurônios!

[msamsoniuk]

opa, com 2MB de memoria vc consegue fazer o uclinux rodar na boa! talvez o build fique um pouco grande, se isso acontecer eu posso te passar o contato de um amigo meu para ele dar umas dicas de como deixar o build menor.

esse amigo meu conseguiu fazer rodar em um modulo com o MCF5270 que possui apenas 512KB de flash, 2MB de ram e cartao MMC. o truque foi justamente colocar apenas o kernel na flash e entao bootar, quando ele boota ele mantem o filesystem no MMC e assim economiza ram:

http://framework.sourceforge.net/pics/c ... linux.html

bom, vc jah tem o 6847 funcionando neh? eu diria que partir para o 6845 agora seria uma boa jogada, pq vc pode aprender umas coisas interessantes com ele! e na pratica eh possivel usar ele para projetar placas graficas tambem, basta usar a criatividade!

Marcelo,

Estou retornando ao projeto do MC68030, agora consegui mais memoria o que será possivel instalar um banco de RAM 512K x 32bits.
No projeto antigo eu tinha somente 512K x 16bits.
Será que é possivel instalar um RTOS, com essa capacidade de memória?
Consegui também um MC6845 e uma memoria de 512K x 8 bits 70ns. Tô pensando em montar uma interface de texto de 80 colunas com o MC6845, talves ligando junto com a placa grafica MC6847, ambas com endereçamento de memoria separadas.
Ou seria melhor fazer uma placa grafica mais robusta com uma CPU e CPLD?
O que tu acha?

[enigmabox]

Marcelo,

Já começei a desenhar a placa com as memórias RAM 512Kb x 32bits ou 2Mb x 8 bits, possivelmente vou usar também flash memory 29F040 no lugar das eproms, mas ainda não tenho equipamento para gravar estas flash de alta capacidade.
Vou retirar uma parte da fiação da placa e colocar uma PCI com as memorias. Isso evita um pouco o efeito capacitivo que a fiação gera.
Isso que tu falou me lembra dos sistemas da decada de 80 onde o sistema ficava na eprom e o restante na RAM, (tipo Apple Lisa) vai criar economia de ram.
Outra preocupação é com o endereçamento da memoria de video, será que no uclinux dá pra configurar os endereços de RAM, Flash, Video, ou tem que adotar algum padrão PC?
Tava querendo tb colocar junto do MC68030 a FPU 68882, mas vai complicar, vou deixar para depois...
Tenho experiencia na compilação do kernel para linux, sei otimizar, não sei se o uclinux funciona da mesma maneira.
No slackware13 que tenho aqui, parece que gera saida para 68k, posso tentar compilar algum kernel para ver o tamanho. Mas se for linux, tenho que usar a FPU.
A placa de video do MC6847 está funcionando no modo de texto e grafico . Eu tinha experimentado ligar esta placa junto com outra placa de video TMS9928, mas as memorias que tenho 4416 estão com defeito, assim vou partir para o MC6845 e se possivel futuramente implementar uma CPLD como o nucleo do MC6845, ai dá pra usar clocks mais altos para resolução VGA.
A placa com o MCF5270 é bem pequena, diferente do trambolho que estou montando...
Já tenho alguns cartões de memoria SD com fat16 para brincar, falta ligar uma SPI no MC68030

[msamsoniuk]

na verdade se vc tiver 128KB de eprom vc jah consegue rodar o uboot!

rodando o uboot, vc ganha capacidade de bootar o uclinux a partir da serial, flash paralela, flash spi, ethernet, etc. no caso de flash paralela, imagine que vc tem a eprom com o uboot no endereco 0 e numa area lah a flash paralela. normalmente eh complexo o protocolo para apagar e gravar os blocos, mas nesse caso o uboot se vira.

note que o uboot roda direto da flash, ele nao precisa ser transferido para a ram. bom, como vc vai fazer com o kernel jah eh variado. se vc tiver flash paralela, vc pode rodar direto da flash e assim economizar memoria. de fato, se vc tiver flash suficiente, vc pode colocar o filesystem aberto em flash e rodar as aplicacoes tambem direto da flash. nessa configuracao eu vi maquinas com uclinux rodando com apenas 1MB de ram!

mas se vc nao tiver flash paralela suficiente para isso (mais de 2MB), vc vai provavelmente cair em uma flash serial ou cartao de memoria. nesse caso o processador nao tem como rodar direto e tem que transferir para a ram, motivo pelo qual o meu colega q usou o coldfire com mmc precisou de 2MB de memoria.

note que o layout da memoria no uclinux eh totalmente configuravel, incluindo os perifericos. uma boa dica eh que colocar uma ethernet com um CS8900A eh relativamente simples e tanto o uboot quando o uclinux suportam ele bem. no caso do 6847 eu imagino que nao existe suporte, mas se vc tiver um codigo no uboot q passa ele para modo grafico e disponibiliza acesso direto a um framebuffer, sem precisar configurar nenhum registro depois disso, o uclinux pode trabalhar diretamente com ele, desenhando os caracteres do console e arriscando suportar aplicacoes graficas para framebuffer.

mas apesar de vc estar com um 68030 full, acho que a dica eh esquecer mmu e ficar apenas com o uclinux sem suporte a mmu. no caso de fpu, nao sei como anda o suporte, mas me parece q se vc tiver fpu ele vai usar na boa. se vc nao tiver e o software usar, ele vai emular. o caso mais rapido porem seria compilar de modo a nunca usar fpu.

Marcelo,

Já começei a desenhar a placa com as memórias RAM 512Kb x 32bits ou 2Mb x 8 bits, possivelmente vou usar também flash memory 29F040 no lugar das eproms, mas ainda não tenho equipamento para gravar estas flash de alta capacidade.
Vou retirar uma parte da fiação da placa e colocar uma PCI com as memorias. Isso evita um pouco o efeito capacitivo que a fiação gera.
Isso que tu falou me lembra dos sistemas da decada de 80 onde o sistema ficava na eprom e o restante na RAM, (tipo Apple Lisa) vai criar economia de ram.
Outra preocupação é com o endereçamento da memoria de video, será que no uclinux dá pra configurar os endereços de RAM, Flash, Video, ou tem que adotar algum padrão PC?
Tava querendo tb colocar junto do MC68030 a FPU 68882, mas vai complicar, vou deixar para depois...
Tenho experiencia na compilação do kernel para linux, sei otimizar, não sei se o uclinux funciona da mesma maneira.
No slackware13 que tenho aqui, parece que gera saida para 68k, posso tentar compilar algum kernel para ver o tamanho. Mas se for linux, tenho que usar a FPU.
A placa de video do MC6847 está funcionando no modo de texto e grafico . Eu tinha experimentado ligar esta placa junto com outra placa de video TMS9928, mas as memorias que tenho 4416 estão com defeito, assim vou partir para o MC6845 e se possivel futuramente implementar uma CPLD como o nucleo do MC6845, ai dá pra usar clocks mais altos para resolução VGA.
A placa com o MCF5270 é bem pequena, diferente do trambolho que estou montando...
Já tenho alguns cartões de memoria SD com fat16 para brincar, falta ligar uma SPI no MC68030

[enigmabox]

Marcelo,

O sistema já tem 128K de eprom com duas 27C512.
Vou incrementar primeiro a ram de 2mb, depois mudar o codigo do monitor para ver se tudo funciona. Logo apos vou pensar em uma placa de video mais robusta de preferencia algo baseado em MC6845, pois quero ter modo texto de 80 colunas.
Poderia deixar todo o codigo dentro de duas flash 29F040, onde teria espaço suficiente, mas como expliquei ainda não tenho o hardware para gravar.
Interessante este Uboot, vou pesquisar, mas deve ser mais ou menos o simples monitor que fiz, via serial carrego qualquer programa, em qualquer endereço da RAM.
Vou ver se encontro uma CS8900 para por no sistema, o que tenho em mãos é a COM20020I da SMC interface ARCNET, mas ai acho que não serve.
Parece que o uclinux foi feito para quando não há FPU, se o sistema tiver, dependendo da quantidade de RAM, pode rodar direto Linux.
Outra coisa, tenho banco de ram dinamica de 16bits e os soquetes, se não me engano deve ser para 5V, usado nos 386 e 486, cada pente tem 32MB... O problema é fazer o hardware para compatibilizar a coisa entre RAM e CPU.

[msamsoniuk]

a ideia eh justamente vc ter as eproms e as flashes no mesmo sistema: vc boota pela eprom rodando o uboot, dae o uboot por sua vez tem capacidade de gravar as flashes 29F040 com o q vc quiser. mas a flash dae vc trata como se fosse uma unidade de disco, grava nela o kernel do linux e um filesystem com a parte principal do sistema operacional. sobre a ethernet, se for uma placa ISA arrisca existir device driver sim, pois pode ser uma NE2000 compativel. soh tem q ter as manhas de ligar no 68030 simulando o bus ISA do PC, mas nao eh complexo nao.

e veja q a diferenca entre linux e uclinux eh em funcao da mmu, nao a fpu. a fpu pode ser utilizada em ambos, inclusive independente da disponibilidade de memoria. soh depende apenas de compilar o codigo com ou sem suporte. no caso da mmu, a quantidade de memoria eh impactada direto pq o sistema passa a rodar com um kernel muito maior, q se nao me falha a memoria requer algo em torno de 5MB no minimo soh para o kernel!

implementar o suporte a dram no 68030 nao eh complexo, apenas vai consumir alguns ciclos extras de barramento. se vc esta rodando com algo em torno de 16MHz, vc precisa de um clock para RAS, um clock para MUX, um clock para CAS, um clock para tempo de acesso e bingo. acho que vc consegue gerar essa sequencia cascateando flip-flops clockados a 16MHz a partir do sinal AS, ou seja, AS seria o proprio sinal RAS, dae passa por um flip-flop para obter MUX, outro flip-flop para obter CAS, que vc associa com DS e SIZE para ter um CAS# para cada byte.

obviamente o esquema jah por default implica em wait-states. contando mais um par de clocks de guarda de cada lado, vc jah tem 6 clocks no total, entao a 16MHz e largura de 32 bits vc conseguiria uma banda de apenas 10MB/s. uma melhoria para isso seria tentar detectar os ciclos em burst, dae vc consegue quadriplicar a banda gastando 9 clocks por acesso, o que resultaria em 28MB/s! mas dae o bom seria jah tentar usar uma CPLD ou FPGA, podendo melhorar mais ainda a banda e de quebra integrar o video no esquema.

Marcelo,

O sistema já tem 128K de eprom com duas 27C512.
Vou incrementar primeiro a ram de 2mb, depois mudar o codigo do monitor para ver se tudo funciona. Logo apos vou pensar em uma placa de video mais robusta de preferencia algo baseado em MC6845, pois quero ter modo texto de 80 colunas.
Poderia deixar todo o codigo dentro de duas flash 29F040, onde teria espaço suficiente, mas como expliquei ainda não tenho o hardware para gravar.
Interessante este Uboot, vou pesquisar, mas deve ser mais ou menos o simples monitor que fiz, via serial carrego qualquer programa, em qualquer endereço da RAM.
Vou ver se encontro uma CS8900 para por no sistema, o que tenho em mãos é a COM20020I da SMC interface ARCNET, mas ai acho que não serve.
Parece que o uclinux foi feito para quando não há FPU, se o sistema tiver, dependendo da quantidade de RAM, pode rodar direto Linux.
Outra coisa, tenho banco de ram dinamica de 16bits e os soquetes, se não me engano deve ser para 5V, usado nos 386 e 486, cada pente tem 32MB... O problema é fazer o hardware para compatibilizar a coisa entre RAM e CPU.

[enigmabox]

Marcelo,

Vc deu uma boa ideia, se tiver a flash no sistema, nao necessita de gravador, mas tem que continuar com as eproms com o uboot.
Esta placa NE2000 ISA ou PCI devo ter uma aqui mas não sei se está em bom estado, tenho que testar.
Entendi sobre a MMU, confundi com o uso da FPU. No meu caso a MMU está desligada não usarei por enquanto.
Estou usando 16Mhz, como vc disse, devido a efeitos capacitivos da fiação na placa. Ja tinha funcionado com 20Mhz, mas depois de solvar varios componentes e fios ficou instavel com este clock. Penso, que fazendo uma PCI para as memorias, este efeito pode ser minimizado, podendo voltar a trabalhar com clock mais alto. Como todo o sistema é independente do clock, ou seja a placa de video tem seu cristal, o porto serial tem o seu modulo cristal e a cpu tem o seu modulo, fica facil mudar o clock da cpu.
Sobre a Dram, consegui baixar um artigo da Revista do Detua - Vol2 - No 5 -Janeiro de 1996, que explica mais ou menos que tu falou sobre a geração de sinais e clocks do CAS, RAS e MUX. Pena que o MC68030 nao gera os sinais, não é como um Z80 que já tinha tudo pronto...hehehe
Posso estudar isso mais para frente, assim posso colocar no sistema até 64Mb de ram.
Como a logica auxiliar do MC68030 já está meio definida, penso em eliminar os CIs 74hcxxx e usar o XC9572xl no lugar, diminuindo também a fiação na placa. No inicio do projeto eu tinha ligado um Cpld, mas devido a meu baixo conhecimento no 68K, não consegui fazer funcionar.
Não sei se vale a pena mudar a placa principal agora, tem muita coisa ligada, estou pensando em fazer como fez o mastk, uma placa com a CPU, uma placa com a memoria, placa com a serial, etc... Fica mais facil modificar o sistema.

[msamsoniuk]

acho q a regra de ouro eh dividir e separar as coisas conforme o dominio de clock: o que tiver mesmo dominio de clock vc agrupa, o q tiver dominio de clock diferente vc separa. dessa forma vc nao precisa transmitir um clock no backplane e nao precisa se preocupar com skew e jitter no clock que vai chegar na placa periferica, tornando o design muito mais simples.

isso eh uma facilidade pq na pratica vc sinaliza tudo em funcao de AS e DTACK, sendo que AS e DTACK podem ter qq especie de atraso no backplane e isso sera automaticamente compensado pelo processador.

e como a maioria dos perifericos para 68k eh assincrono, fica facil colocar em placas separadas. no caso da memoria, a solucao de maior performance seria fazer sincrono, porem isso requer q fique na mesma placa do processador e tambem eh um pouco mais complexo. eh mais facil de fazer isso quando se fala em memoria cache, composta por sram sincrona de alta velocidade.

no caso de dram, acho que seria um caso ideal para ser assincrono mesmo, pq te dah liberdade de aumentar e diminuir o ciclo de acesso sob demanda, compensando nao apenas os delays de propagacao, como tambem as necessidades operacionais da dram.

uma jogada otima seria implementar suporte a modo de acesso paginado da dram: nesse caso funciona como uma cache, em que vc armazena o endereco de RAS para comparar depois. no primeiro acesso vc tem RAS/MUX/CAS, mas nos proximos vc compara. se o endereco de RAS eh igual ao que acabou de ser usado, vc faz um ciclo mais curto gerando apenas CAS.

o tempo de acesso em geral se reduz pela metade, assim, se vc usa uma referencia de 16MHz, vc teria 3x60ns para um acesso completo com RAS/MUX/CAS, mas apenas 30ns para um acesso com um page hit. para o refresh vc pode prolongar um pouco o acesso e implementar a tecnica de hidden refresh, por exemplo. e tudo isso feito de forma transparente para o processador, apenas controlando DTACK na hora certa.

daih uma vantagem desse sistema assincrono eh que os dominios de clock podem ser bem diferentes: na memoria dram vc pode usar um clock de referencia de 16MHz pq isso eh um multiplo do tempo de acesso dela, enquanto que para o processador e fpu vc poderia despejar 40 ou 50MHz. como vc nao usa esse clock fora do processador, em principio nao deveria afetar o funcionamento.

uma otimizacao extra seria criar uma cache na placa do processador. nesse caso uma FPGA iria bem, pq vc consegue implementar tudo internamente, utilizando memorias sram dual-port. o conceito nao eh tao dificil:

a medida que o processador gera um endereco qq, vc gera um hash ou algo parecido e procura o endereco em uma lookup table. se ele estiver lah, vc tem um cache hit e usa termina o ciclo como sendo sincrono e tenta fazer uma transferencia em burst. no caso de um 68030 de 50MHz, acho que vc conseguiria chegar aos 160MB/s!

se o endereco nao estiver na tabela, vc tem um cache miss e faz uma terminacao assincrona, transferindo o dado da memoria tanto para o processador quando para a memoria cache. assim, no proximo acesso, se vc cair no mesmo endereco, vc tem um cache hit novamente.

[mastk]

As drams sao legais, e se nao fossem o custo seriam uma otima opcao para todos nos, mas como o grande uso delas eh PC, a dram ja tido obsoleto e custa uma fortuna, sdram ja estao indo para esse caminho apesar de serem a picanha das rams para projetos embarcados, dado que nao precissam de esquemas complexos de alimentacao e operacao tal qual a DDR e suas revisoes.

Tem certeza que a sua DRAM esta queimada mesmo Enigma? E ssam velhinho esses esquemas de otimizacao de acesso sempre me chamaram a atencao, na epoca do 486/pentium era o que diferenciava uma placa vagabunda da boa, achava tal otimizacao coisa do capeta, hoje consigo entender, mas ainda assim, sintetizar o comunicacao asincrona com o CPU e fazer praticamente outra cpu para avaliar e mudar o tipo de acesso a dram, pow velhinho isso ai eh coisa de macho de verdade.

Aqui, um frame-buffer feito e ja me serviu para ver que 8 bits de cor nao eh o bastante do preto-pobre:



Pow 3 placas, um FPGA ta valendo cada vez mais a pena...

[enigmabox]

Mastk,

Implementar a Dram não é facil mesmo, na epoca do Z80 era só plugar e pronto, a CPU gerava todos os sinais de refresh.
No caso do 68k que não tem o gerador de CAS, RAS e MUX embutido, tem que usar uma logica a parte, mas não é nada de outro mundo, como o Marcelo explicou, dá pra fazer sim, mas leva tempo.
As Drams que eu tinha para o TMS9928, podem estar com defeito, não tenho como testar, mas tb desconfio que o MC68030 estava enviando dados muito rapidamente para o TMS9928. Pode ser isso o motivo que eu não conseguia gravar nada na RAM, mas configurar e mudar a resolução do TMS9928 estava sendo realizada normalmente, pois eu via o resultado na TV monitor. Com o TMS tem algumas vantagens na geração grafica que o MC6847, mas no modo texto, seria gerado somente 40 col.
Estou partindo para algo que gere 80col em texto e graficos VGA, penso em usar varias XL9572XL que tenho aqui.
Tá dificil achar aquelas placas antigas de video com slot ISA, se encontrar alguma, vai ficar facil ligar no MC68030.
Ficou legal a sua placa de video, mas devido a pouca capacidade de pinos do cpld, vc deve somente gerar 8 bits.
Voce gerou o codigo via VHDL no cpld como tinha nos exemplos da revista Saber?
Outro modo que pensei é usar 3 DACs para gerar RGB, um por canal, mas ai teria que usar 3 RAMS e 3 CPLDs. Pelo menos geraria 256 niveis por canal de cor.
Mastk , o que é esta placa de fenolite cor marrom? Contem a memoria de vídeo?

[mastk]

Corrigindo, EDO e FP dram ja nao acho mais para comprar novas, sera que vale a pena partir logo para as DDR?

Serviu de base, mas ja esta totalmente diferente.
Paletizar eh uma opcao, mas a ideia eh manter tudo simples e claro.
Isso mesmo ta a memoria de video e latchs.

Placa de video ISA eu tenho, ja pensei em usa-las mas eh fazer a minha ja eh uma questao de honra rs

[msamsoniuk]

bom, eu diria que depende muito da tensao de operacao do sistema... com 5V eh tudo raro, mas eh uma tensao soh... quando pula para 3.3V a bangunca comeca!

embora existam 680x0 e 683xx disponiveis em 3.3V, acho que sao meio raros e na maioria dos casos provavelmente vao estar disponiveis em 5V. com isso vc jah elimina a possibilidade de usar algo diferente de SRAM ou DRAM, bem como algo diferente de CPLDs, pq as FPGAs nao toleram 5V!

DRAM eh possivel encontrar ainda:

http://www.jameco.com/webapp/wcs/stores ... =jamecoall

detalhe interessante:

http://www.jameco.com/webapp/wcs/stores ... tId=285667

http://www.jameco.com/webapp/wcs/stores ... ctId=42219

ou seja, sai mais em conta usar um modulo montado que montar chip a chip! mas eh aquele negocio neh, na pratica isso nao eh mais manufaturado e nao se sabe o tamanho dos estoques.

agora, se for para partir para algo mais integrado, o negocio seria pular para 3.3V. nesse caso encontra DRAM ainda em producao:

http://www.jameco.com/webapp/wcs/stores ... Id=1861857

o que poderia ser uma boa jogada para um 680x0 ou 683xx operando a 3.3V. talvez para uma FPGA controlando video tb fique mais facil fazer um design com DRAM, afinal a densidade fica muito boa: com 2MB de memoria de video e acesso em FP, acho que conseguiria fazer 1024x768 entrelacado com 16 bits de cor. mas nessse caso sempre tem algumas opcoes de memorias SRAM e ateh mesmo MRAM, q facilitam bastante a vida.

no caso de processador, dae acho q fica sendo mais vantagem partir para um coldfire mesmo, com controlador SDRAM ou DDR integrado. no caso de SDRAM tem varios, mas imagino q o melhor caso seria um componente barato, com encapsulamento acessivel e de preferencia com ethernet integrada. o 5270 eu sempre cito como referencia pq eh facil de encontrar e suporta SDRAM. outro que parece estar com preco bom seria o 5208, que nesse caso suporta tanto SDRAM quanto DDR. soh que vendo o projetinho dele com DDR eu vi q tem uma desvantagem: DDR soh opera com 2.5V.

dae voltando lah no video, DDR fica uma opcao interessante pq a FPGA tem justamente possibilidade de operar mixada com 3.3V e 2.5V. e olha a salada neh: sistema opera a 3.3V, DDR a 2.5V, core do coldfire a 1.5V e core da FPGA a 1.2V! dependendo do PHY ethernet, pode aparecer mais um 1.8V ae hehehe bem-vindo ao mundo moderno!

outro lembrete importante: pulando para SDRAM ou DDR, as memorias tem que obrigatoriamente estar "coladas" no controlador, seja ele o coldfire ou uma FPGA, pq o negocio eh todo sincrono, ou seja, todos os sinais sao amostrados em funcao de um clock, q eh relativamente elevado.