MC68008 no proteus?

[mastk]

Nao consigo emular algo com o MC68008 no proteus, fala que nao tem um modelo a ser simulado, alguem ja fez algo com esse trem?

[tcpipchip]

Tem no Proteus ? Não sabia.

[mastk]

Tem o MC68000 e MC68008, porem estranho essas simulacoes, nao estou vendo os pinos de VCC e GND, ou eles ja estao etiquetas genericas e uma vez provida alimentacao, ok?
Usei o Proteus na faculdade e pensei se dava para brincar um pouco.

[msamsoniuk]

:v

http://hackaday.com/2014/08/21/when-wor ... duino-uno/

[mastk]

Isso eh sacanagem Sam, nos ultimos dias eu ja fiz uma nova sinteze em VHDL de placa de video, para poder operar em clocks mais baixo, facilitando a confeccao de um futuro PCB e usando memoria e logicas baratas.
Agora estou pensando em uma interface de memoria de duas portas, sendo uma para MCU/MPU em geral.

Me mostrar isso, faz a minha cobica e ansiedade crescerem ainda mais.

[mastk]

Legal desse projeto que foi o primeiro passo que dei no 68K, peguei um MC9HC08 e usei para segurar o barramento enquanto colocava codigo na RAM, soltava o barramento e pronto, pong rondando, claro que fiz um protocolo, software em delphi, uma interface de joystick e video a mais que esse camarada.

Na verdade Sam o meu foco agora eh ter um base de video e audio que independa do processador, penso em comprar alguns MC68SEC000, mas depois que a Freescale largou os coldfires, estou desanimado...

[msamsoniuk]

Isso eh sacanagem Sam, nos ultimos dias eu ja fiz uma nova sinteze em VHDL de placa de video, para poder operar em clocks mais baixo, facilitando a confeccao de um futuro PCB e usando memoria e logicas baratas.
Agora estou pensando em uma interface de memoria de duas portas, sendo uma para MCU/MPU em geral.

Me mostrar isso, faz a minha cobica e ansiedade crescerem ainda mais.

pq vc nao usa o modelo de funcionamento dos chipsets do amiga como ponto de partida?

o core da arquitetura consistia em 4 chips importantes: agnus (controlador de memoria), denise (controlador de video), paula (controlador de audio e disco) e o 68000. o coracao do sistema era o ASIC agnus, que controlava ateh 1MB de memoria DRAM que era usada tanto para video, audio e disco quanto para processamento por parte do 68000. alem de controlar a DRAM, o agnus fornecia 28 canais de DMA para video, audio e disco. essencialmente, o agnus gerava o enderecamento e os chips denise e paula continham queues e interfaces de I/O. o clock do sistema era todo sincrono: o agnus rodava a 28MHz e gerava todos os clocks: os 14MHz do denise e os 7MHz para o 68000. infelizmente eu nao lembro de cabeca dos detalhes operacionais, mas nao eh dificil imaginar: lembro que apesar do agnus controlar o DTACK e poder inserir wait-states no 68000, o acesso era otimizado de tal modo que a DRAM fazia dois acessos a cada acesso do 68000 e, como resultado, o 68000 conseguia operar a zero waitstates. bom, note que operando a 7MHz o 68000 consome 4 clocks para cada acesso de 16 bits, portanto, se a DRAM faz dois acessos nesse mesmo tempo, podemos supor que a DRAM requer 4 clocks de 14MHz, o que eh bem coerente: 1 clock para ativar RAS, 1 clock para ativar CAS, 1 clock para a transferencia antes de desativar RAS e CAS e 1 clock com os sinais em idle. nos primeiros dois clocks de 7MHz do 68000 o agnus vai fazer um acesso de DMA para os chipsets, nos dois outros clocks o agnus vai fazer um acesso para o 68000. bom, consumindo 4 clocks de 14MHz em uma DRAM de 16 bits vc teria efetivamente 7Mbytes/s de bandwidth de memoria, sendo metade para o 68000 e metade para os chipsets de audio, video e disco. com 3.5Mbytes/s vc conseguiria fazer 720x480 pixels a 30Hz com 4 bits de cor. efetivamente, nao utilizaria todos os 3.5Mbytes/s, entao sobraria alguma coisa nos intervalos de retraco vertical para tratar audio, refresh da DRAM e aleatoriedades menores.

bom, a descricao eh soh para dar uma ideia de como funcionava mais ou menos os chipsets utilizados no amiga 500... eh um bom ponto de partida e vc pode pensar em algumas variacoes: se dobrar a largura do bus ou dobrar a velocidade da memoria, vc ganha o dobro de bandwidth. e com o dobro de bandwidth vc pode pensar em dobrar o clock do 68000 para 14MHz e melhorar o video: pode manter os 720x480 pixels em 30Hz do NTSC rodando com 8 bits de cor ou ir para os 640x480 pixels em 60Hz do VGA mantendo os 4 bits de cor ou talvez 320x240 pixels em 60Hz no VGA, mas com 8 bits de cor. no caso do NTSC, com 8 bits de cor por pixel vc pode na realidade comprimir 12 bits de cor em YUV fazendo 720x480 para uma compoente Y de 4 bits e pixels alternados UV formando um frame de 360x480 com as componentes UV em 4 bits cada uma. se vc jah viu como funciona o video composto NTSC, vai perceber que faz todo o sentido: a luminancia Y com um pixel clock maior nao eh problema para a TV que possui banda de quase 7MHz, porem a crominancia UV depende do burst de croma de 3.5MHz, o que limita a resolucao horizontal. no caso de 720x480, o pixel clock vai chegar a 14MHz, bem acima do que o padrao NTSC consegue codificar cor. se optar pelo VGA, menos mal, pq opera em RGB e nao possui restricao de bandwidth de cor. eu acho que eh bem razoavel se for pensar que vc tem uma unica memoria unificada para video e processador e que permite um 68000 operar a zero waitstates. claro, se for partir para um 68030 a coisa comeca complica de um lado, mas facilita do outro: se por um lado vc comeca a transferir dados a cada 1 ou 2 clocks, por outro lado vc possui caches on-chip. se por um lado vc vai rodar com clocks maiores, por outro lado vc tem um barramento de 32 bits.

um modelo de arquitetura que eu acho interessante para o 68030 eh o macintosh IIci: ele possui um 68030 de 25MHz e DRAM inicial de 4Mbytes tanto para video quanto processamento. o video, no caso, eh um ASIC da apple capaz de fazer 640x480 a 70Hz e 256 cores. o truque para otimizar as coisas eh que a DRAM opera a 25MHz e o video faz transferencias em burst. acredito que gastem 1 clock com os sinais RAS e CAS em idle, um clock para RAS, 1 clock para CAS e 1 clock para transferencia. como a memoria DRAM nesse caso opera em modo paginado, o tempo de acesso gasto no RAS e CAS eh feito uma unica fez no inicio e vc consegue fazer transferencias sucessivas. no caso, 8 transferencias a 25MHz. portanto vc gastou, na pratica 11 clocks para obter 8x32 bits (novamente, nao lembro mais de cabeca a conta efetiva q usaram no sistema). rodando a 25MHz, vc teria um bandwidth de 72Mbytes/s. como o video em 640x480 a 70Hz e 256 cores consumiria 21Mbytes/s, sobrariam ainda 50Mbytes/s de bandwidth para o 68030, suficiente para chegar aos 25MIPS...poutz! eh F*** lembrar dessas solucoes incriveis e pensar que tem nego hoje em dia que acha que a apple eh um fabricante qualquer no naipe de uma samsung da vida que malemal consegue fazer o feijao com arroz da engenharia! huahuahua

enfim, se usar uma SDRAM moderna, a coisa pode ficar mais facil ainda: tem um montao de bandwidth sobrando!

[msamsoniuk]

Legal desse projeto que foi o primeiro passo que dei no 68K, peguei um MC9HC08 e usei para segurar o barramento enquanto colocava codigo na RAM, soltava o barramento e pronto, pong rondando, claro que fiz um protocolo, software em delphi, uma interface de joystick e video a mais que esse camarada.

Na verdade Sam o meu foco agora eh ter um base de video e audio que independa do processador, penso em comprar alguns MC68SEC000, mas depois que a Freescale largou os coldfires, estou desanimado...

bom, eu comecei a trabalhar em um core RISC proprio de 16 bits proprio, a ideia eh algo muito simples e compacto, tanto para otimizar a velocidade quanto para otimizar o espaco. em uma spartan-3E, por exemplo, eu consigo colocar 2 cores rodando a 100MHz. a ideia inicial era usar isso como coprocessador de IO para processadores maiores, daih os cores ainda estao limitados a blockram interna, mas estou trabalhando em um controlador de cache justamente para permitir usar externamente todo o espaco de 16 bits de enderecamento de instrucoes, bem como fazer os cores funcionarem em uma arquitetura SMP. na real, o hardware em si tem se mostrado bem facil e a maior dificuldade que eu percebi foi no software: portar um compilador C eh incrivelmente complexo. um problema que eu percebi escrevendo cores de processadores RISC e DSPs eh que quanto mais compacto o set de instrucoes, mais complexo fica o hardware e, quanto mais complexo o hardware, pior a performance. dah para vc tentar compensar enchendo de pipelines, mas quanto mais pipelines, mais complexo fica o fluxo de execucao para compensar os pipelines... novamente, mais hardware e mais impacto na performance. uma solucao pratica seria resolver o problema do compilador pegando uma arquitetura pronta, como o 68000, coldfire ou ARM, e implementando um core capaz de decodificar as intrucoes. mas os tres possuem um set de instrucoes muito compacto e otimizado, daih o resultado eh um custo enorme em silicio para transformar as facilidades de software em hardware. como minha ideia eh tentar colocar o maior numero de cores com o clock maximo na FPGA mais barata possivel, resolvi partir para um core proprio mesmo, provavelmente eh um dos cores RISC mais compactos disponiveis para FPGAs! quando estiver mais refinado eu te mando para vc dar uma olhada!

[xultz]

quanto mais compacto o set de instrucoes, mais complexo fica o hardware e, quanto mais complexo o hardware, pior a performance. dah para vc tentar compensar enchendo de pipelines, mas quanto mais pipelines, mais complexo fica o fluxo de execucao para compensar os pipelines...

Então implementa um core de PIC16, com suas maravilhosas 35 instruções, vai ficar uma maravilha

[norad58]

Nao sei até que ponto um simulador via software consegue simular um processador complicado como o 68K.
Hora que começar a usar DMA, Interrupções, acho que o simulador via software não vai conseguir simular tudo.
Melhor base de 32/16/8 bits é o mc68030, mas nao vi até hoje um modulo para 68030 para FPGA, deve ser porque o core é volumoso e ocupa muito espaço, pode ser que na linha fpga Virtex tenha algo Risc equivalente.
Algumas decadas atras vi um simulador de 68k, acho que era da HP, continha uma placa que simulava a cpu, nao usava eprom, o pc carregava o codigo numa ram que simulava uma eprom...
Pra mim a melhor maneira de trabalhar com video e cpu é usar espaço de memoria para acesso da RAM de video que é separada da RAM da cpu principal, nada de deixar a cpu principal fazer os dois trabalhos, perde muito em eficiencia. Como o 68k e 68030 possuem um bom espaço de endereçamento, melhor deixar um espaço reservado a RAM de video e um segundo processador gerencia o video. Nem precisa usar uma RAM de duplo canal de acesso, uns latchs como HC244, HC245, HC573 resolvem o problema.
Usando esta ideia de memorias RAMs separadas, ja vi varios projetos na internet usando placa de video ISA com cpu/mcu simples como AVR e PIC. Eu mesmo fiz uma adaptação de uma placa de video ISA com a cpu mc68030.

[mastk]

O pior eh que isso mesmo, o proteus nao tem o 68k emulado dentro dele.

Sam, entendi a sua abordagem, o problema que eu tenho eh que se fosse trabalhar com video composto, teria problemas analogicos, fidelidade de sinal e assim por diante, o bom eh que a velocidade do barramento cai muito e com isso fica facil inserir um wait state e dele realizar as operacoes de video, mas no caso eu quero trabalhar com vga e dai temos o problema que o clock base vga eh de 25 mhz e dai nao fica banda disponivel para o processador, esse eh o problema do hardware do pong, eu tenho tao pouco, mas tao pouco tempo de banda disponivel que nao posso me dar ao luxo de programar algo mais complexo que o pong e dai vem a vontade de ter uma placa totalmente aparte do processador para que possa programar o que eu quiser, seria bom otimo ter uma interface rapido que vai que eu consiga fazer um jogo com sprites grande e animado, nesse caso se a interface for lenta, ficarei limitado.
Ja no caso de opcoes de CPU o MCF5208 parece legal mesmo, ele aida tem vida e pode me servir como um 68030, o que me preocupa que por uma questao de custo, eu preciso que ele possa, ao menos inicialmente operar com 8 bits de dados, ainda tenho em casa dois mcf5270, o ruim eh que por algum motivo eu nao consigo fazer ele iniciar, talvez seja a capacitancia elevada pela a espesura dos fios que eu usei, em todos, hoje ja tenho dinheiro para mandar fazer placas por hobby em vez de fazer em casa, na verdade sai ate mais barato que o meu tempo vem ficado muito valioso e coisa que nao me divirtam ou que nao me dem dinheiro como processos artesanais e ariscado de confecao de pcb, ja nao me interresam.
Por um acaso poderia usar esse cado para fazer um teste com SDR ram ou DDR, nunca usei essas memoria, nao sei qual eh facil de comprar se precisso de centenas de megas de ram, na pratica acho que uma SRAM de 64 mega bits me atendem perfeitamente, e para comecar ate menos do que isso me serve.
Enfim, opcoes nao faltam, o problema eh o que e como fazer.

[msamsoniuk]

quanto mais compacto o set de instrucoes, mais complexo fica o hardware e, quanto mais complexo o hardware, pior a performance. dah para vc tentar compensar enchendo de pipelines, mas quanto mais pipelines, mais complexo fica o fluxo de execucao para compensar os pipelines...

Então implementa um core de PIC16, com suas maravilhosas 35 instruções, vai ficar uma maravilha

o problema eh que daih eu saio de uma arquitetura que me fornece "100 MIPS RMS" para ir para uma arquitetura que me fornece "100 MIPS PMPO" hehehe embora nao tenha compilador C, a arquitetura que eu montei fornece 16 registros de 16 bits de uso geral, sustenta 100 milhoes de multiplicacoes 16x16 bits por segundo em cada core, permite programas estruturados com ateh 64K instrucoes e configuracoes em SMP!

pronto mastk, arrumei a referencia de performance! :v

[mastk]

Curiosa a sua ideia Sam, vc fala de 100 milhoes de intrucoes, mas por horas ou segundos?

Olhando para o mercado que mais avanca hoje, que eh de o celulares, existem varios problema de performace e indices como o PMPO, coisa de um ano atras ja tinhamos varios com clock de mais de 2ghz e dual core. Alguns apareceram com 8 cores, sendo que apenas dois serao usado, o resto fica empoirando porque o SO nao sabe o que fazer com eles. Porem hoje os clocks estao abaixando e tende-se a aumentar a largura do barramento de dados, as memoria de PC ja estao com 128 bits de dados na ultima vez que olhei, nao sei se ainda se usa hyper transport ou coisa melhor nos lacos de comunicacao.
Gostaria de saber que as RAMs de celular sao como as que estou usando que tem comandos e alguns pouco pinos a mais da interface tradicional de ADR, DATA, RW, CE...
Hoje cada vez mais, comunicacao eh a limitacao e nao processamento.



Se bem que paramos para pensar na situacao atual do uso dos recursos de hardware, penso que estamos em uma crise sem igual, de que adianta algo fantastico como um Iphone, se vao jogar Angry Birds e FaceBook, cade aqueles software que usavam 120% do que era imaginado?
Lhe dou um exemplo, do Street Fighter 4, graficos meia boca para 2006 do que dizer hoje em 2014, o jogo tem erros grotescos, o mais comum entre veteranos eh se frustarem de dar um golpe, ele ter chegado ao corpo do adversarios e nao ser processado, chegando ao ponto de dar tempo do adversario dar outro golpe e para o seu. Para golpes especiais eh praticamente impossivel realizar dois ao mesmo tempo, o processamento para, coisa que jamais acontecia com um 68K com o Z80, ja com um I7, gigas de RAM um soco fraco tem prioridade que impede qualquer luta mais tecnica, chega-se a se chamar o Street Fighter 4 de Jab Fighter 4, eu acredito que isso seja fruto de estar rodando sobre um sistema operacional e disso nao pode realizar tarefas em tempo razoavel, com o tempo isso soh vem piorando, Virtual Fighter 5 eh lento e suas atualizacoes vem piorando isso.

Enfim, estou preocupado em como fazer comunicacao rapidas e eficientes, tal como ter dispositivos que rodem em tempo real, porque se for para trabalhar na casa do mili segundo, faco eu que sou mais rapido que isso.



Eh preciso 400Mhz, placa de video dedicada e serios hacks para um PC conseguir emular essa belezinha, chegasse ao ponto em que tinha que se dar um reset de tanto que se forca a barra.

Nao por acaso, os que sao chamados hoje de jogos premium do PS VITA estao vendendo cada vez menos, mais de 90% dos jogos vendidos sao online, o conceito de cartucho eh mais que nunca coisa do passado. Pirataria perde o sentido frente a servico de qualidade e a precos razoveis.

[msamsoniuk]

sobre o 5270, sera que nao esta faltando os jumpers de setup? quando o 5270 sai de reset, ele faz um latch de varios bits do bus de dados e esses bits setam varias configuracoes internas, como multiplicadores de clock e largura do bus para bootar. normalmente esse setup eh feito com resistores de pullup/pulldown. tendo esse setup, tendo um reset com temporizacao correta e tendo clock e alimentacao (dah uma conferida no reference desing: o chip em si requer um monte de capacitores de desacoplamento de valores especificos), ele deveria aparecer via BDM e/ou bootar, se vc tiver uma EPROM ligada no CS0. de fato, para ele funcionar nao precisa de muita coisa, se for pensar que ele jah tem um monte de perifericos on-chip e tem uma SRAM de 64KB.

sobre a SDRAM, eh relativamente facil e barato de comprar, soh tem que ver se a configuracao de bancos, colunas e linhas eh programavel no 5270:

http://www.digikey.com/product-detail/e ... ND/4234562

essa, por exemplo, multiplexa linha em A0-A12, daih multiplexa coluna em A0-A8, faz pre-charge com A10 e seleciona banco com BA1 e BA0. a largura do bus eh 16 bits e, como o clock maximo eh 143MHz, vc consegue programar o 5270 para a velocidade maxima de bus (os 5270 com encapsulamento TQFP rodam o bus a 50MHz e os BGAs a 75MHz). assim, para o TQFP eh de se esperar que acessos de burst cheguem no pico de 100Mbytes/s. como o controlador de SDRAM nao opera a zero wait-states para fazer o setup da memoria, ou seja, vc perde uns ciclos para comecar a transferir. feito o setup, as transferencias sao feitas clock a clock. supondo entao um burst de 16 bytes na SDRAM, acredito que vc perde uns 3 ou 4 ciclos para fazer o setup da SDRAM e daih ela vai transferir 8 words clock a clock e isso daria uns 66Mbytes/s na realidade. outra coisa ruim eh que feita a leitura, o controlador de DMA do 5270 eh dual-address, entao ele tem que escrever os dados do buffer em algum lugar. se a porta do DAC for de 8 bits, vai gastar mais 16 clocks. entao seria vantagem se a porta do DAC tivesse um mux para a largura maxima de bus: se fosse 32 bits, vc gastaria entao apenas 4 clocks. com isso uma transferencia de 16 bytes teria um total de uns 16 clocks, incluindo 4 para setup, 8 para leitura e 4 para escrita, o que resulta em 50Mbytes/s de bandwidth. uma tela de 640x480x60Hz com 8 bits de cor consumiria algo em torno de 18Mbytes/s.

mas daih, se for pensar bem: se vc colocar uma FPGA vc pode, meio que de boa, colocar no clock maximo de 143MHz e atingir 286Mbytes/s com um bus de 16 bits e consegue fazer single-address, ou seja, a leitura da SDRAM eh casada com a escrita na porta de video. supondo uma logica parecida de tempo de setup da SDRAM, vc teria a vantagem de poder fazer DMA casado, ou seja, gastaria apenas os 4 ciclos de setup da SDRAM e os 8 ciclos de leitura, de modo que a leitura da SDRAM jah implica na escrita direta da queue de saida de video na FPGA. em termos praticos, a SDRAM renderia uns 190Mbytes/s operado com bursts de 16 bytes. partindo do principio que o 5270 consumiria, na pior das hipoteses 100Mbytes/s desse bandwidth (na pratica ele consome muito menos por causa das caches on-chip), vc teria realmente livre 90Mbytes/s apenas para video, suficiente para fazer 5 overlays independentes de 640x480x60Hz com 256 cores cada um.

e daih se vc for ver bem, a grande maioria dos kits de desenvolvimento de FPGA, mesmo os mais baratos, jah vem com uma SDRAM roteada na placa, o que me leva novamente aquele outro assunto: se vc jah tem a FPGA e a SDRAM, e vimos que se vc abusar dos clocks maximos da SDRAM vc tem um bandwidth enorme, pq colocar um processador externo? daih vem a ideia do core RISC de 100MIPS... bom, os 100MIPS de um core RISC em uma FPGA nao tem a mesma qualidade e flexibilidade dos 100MIPS de um coldfire, mas por outro lado eh facil colocar multiplos cores em uma FPGA. e daih 200 ou 400MIPS eu acho que comeca a dar uma compensada bem boa em relacao as deficiencias! hahaha

O pior eh que isso mesmo, o proteus nao tem o 68k emulado dentro dele.

Sam, entendi a sua abordagem, o problema que eu tenho eh que se fosse trabalhar com video composto, teria problemas analogicos, fidelidade de sinal e assim por diante, o bom eh que a velocidade do barramento cai muito e com isso fica facil inserir um wait state e dele realizar as operacoes de video, mas no caso eu quero trabalhar com vga e dai temos o problema que o clock base vga eh de 25 mhz e dai nao fica banda disponivel para o processador, esse eh o problema do hardware do pong, eu tenho tao pouco, mas tao pouco tempo de banda disponivel que nao posso me dar ao luxo de programar algo mais complexo que o pong e dai vem a vontade de ter uma placa totalmente aparte do processador para que possa programar o que eu quiser, seria bom otimo ter uma interface rapido que vai que eu consiga fazer um jogo com sprites grande e animado, nesse caso se a interface for lenta, ficarei limitado.
Ja no caso de opcoes de CPU o MCF5208 parece legal mesmo, ele aida tem vida e pode me servir como um 68030, o que me preocupa que por uma questao de custo, eu preciso que ele possa, ao menos inicialmente operar com 8 bits de dados, ainda tenho em casa dois mcf5270, o ruim eh que por algum motivo eu nao consigo fazer ele iniciar, talvez seja a capacitancia elevada pela a espesura dos fios que eu usei, em todos, hoje ja tenho dinheiro para mandar fazer placas por hobby em vez de fazer em casa, na verdade sai ate mais barato que o meu tempo vem ficado muito valioso e coisa que nao me divirtam ou que nao me dem dinheiro como processos artesanais e ariscado de confecao de pcb, ja nao me interresam.
Por um acaso poderia usar esse cado para fazer um teste com SDR ram ou DDR, nunca usei essas memoria, nao sei qual eh facil de comprar se precisso de centenas de megas de ram, na pratica acho que uma SRAM de 64 mega bits me atendem perfeitamente, e para comecar ate menos do que isso me serve.
Enfim, opcoes nao faltam, o problema eh o que e como fazer.