68K ou coisa assim, again

[enigmabox]

Marcelo S.

Grato pelas informações.
Outro mais antigo que tb parece usar a mesma tecnologia é o Apple Lisa, que tb baixei o esquema. Mas deve usar o mesmo conceito dos primeiros Macs.
Vc sabe se nos micros da Sun antigos (Sparc 68k), usando frame-buffer, usam o mesmo conceito do Amiga/Mac? Existiam algumas estações graficas, onde tinham saida para monitor modo texto e uma outra saída para monitor modo gráfico. Será que usam o mesmo endereço de framer-buffer ou ha espaço diferente na ram(2 frame-buffer)?

[msamsoniuk]

as maquinas da sun jah eram outro patamar neh. soh para vc ter ideia, essa referencia de 1982 dah uma nocao do naipe da primeira maquina deles:

ftp://reports.stanford.edu/pub/cstr/rep ... 82-229.pdf

ou seja, a primeira maquina deles em 1982 jah rodava com um 68000 de 10MHz, 256KB de memoria, video 1280x800 monocromatico, rede ethernet e mouse! convenhamos, isso eh absolutamente incrivel para a epoca, pois o PC ainda era uma maquina embrionaria com um 8088 de 4.77MHz, 16KB de memoria (mais memorias apenas em 1983 com o PC XT), video 80x25 monocromatico sem suporte a graficos (video CGA 640x200 monocromatico apenas em 1983 com o PC XT) e cujo principal meio de armazenamento era fita K-7 (novamente, floppies e HDs soh em 1983 com o PC XT). mesmo com o lancamento do lisa em 1983, uma maquina muito similar em varios aspectos, as estacoes da sun estavam 10 anos a frente e jah operavam em redes IP.

na parte grafica, a primeira maquina jah era interessante: usava memoria de porta dupla e permitia usar essa memoria para outras finalidades alem do proprio buffer de imagem, para armazenar, por exemplo, bitmaps de cursores, fontes, etc. ou seja, jah tinha conceitos primitivos de aceleracao grafica! isso para a primeira maquina, imagina as que vieram depois hehehe

de fato, essa eh uma perspectiva diferente de desenvolvimento: se vc monta uma arquitetura em volta de um backplane, vc pode quebrar os problemas em placas diferentes totalmente independentes.

por exemplo, construir uma placa com um 68030/68882 e bancos de memoria locais sincronos operando em alta velocidade. uma outra placa vc coloca um banco de memoria independente para video e um 68000 dedicado para primitivas graficas em noutra placa vc monta um 68000 dedicado para controle de discos e ethernet, por exemplo. assim vc tem um sistema com um processador otimizado para processamento bruto e dois processadores otimizados para atividades independentes de IO.

isso resulta em um sistema de alta performance, mas claro que muito mais complexo e caro que um sistema pequeno como um macintosh ou amiga, onde o design eh orientado a uma boa relacao entre custo e performance.

sao dois caminhos diferentes, mas interessantes. por outro lado, existe um exemplo nao muito bom: os PCs da decada de 80 tentavam imitar o design de alta performance de uma workstation, modularizando tudo em placas diferentes, mas eram placas burras de baixo custo que dependiam da performance do processador central. o resultado eram sistemas mais caros e de baixa performance.

[mastk]

Mas ai que ta enigma, tipo fazer DMA nessas MCU vai comprometer consideravelmente o desempenho e tera um hardware moderamente complexo, se quiser usar um MCU a parte para controlar video seguindo os principios da placas dos anos 80/90, tipo sprite e efeitos, vai ser osso de verdade, todo o caso, que pretende? O video do MAC 128K em video composto eh bem simples, com o xc9572 vc deve conseguir sinteizar sem grandes crises, negocio eh quao periodico sera o 68K...

Eu to terminado uma aqui, e para fechar o 68K precisso resolver o boot dele...

[enigmabox]

Marcelo,
Na época dos primeiros SUN 3/80 e outros, eles nao pensavam muito em economisar, mas sim na eficiencia, como vc disse, botaram tudo de bom e do melhor.
Como tu disse, nao dá pra comparar Sun com PCs.
A historia da IBM em computadores pessoais, foi de criar um micro barato para competir na epoca com a Apple, que vendia computadores pessoais que nem água. Pois o forte da IBM era os servidores e tb queria abraçar o mercado dos PCs.
Eu tive a oportunidade de testar ambos, um PC XT(4Mhz) e um AppleIIplus, na época(1MhZ), tinha casos que a eficiencia, principalmente em jogos, ou seja processamento de video, o Apple era mais eficiente, mesmo trabalhando com clock baixo.
Depois da uniao da IBM e Microsoft para a realização do PC. O tio BILL descontente do que tinha em mãos, comprou 3 maquinas MAC ou LISA, para fazer engenharia reversa...para depois criar o windows.
Bom, nem o DOS a microsoft criou do zero, segundo diz a historia comprou o SO de um programador e modificou.
Tô pensando em fazer mais ou menos como tu disse, sistema modular, tenho que pensar bem que sinais boto no barramento, senão perco tudo.
Já tenho 02 68882, 02 MC68030, 02 MC68010 e 02 MC68HC000. Assim dá pra brincar bastante com todas estas CPUs. O segredo da coisa é saber interligar tudo da melhor forma.
Pra vc ter ideia, trabalho com um equipamento que contem uma placa master com z80 que controla até 12 placas Slave tb com z80. A comunicação entre elas é feito atraves de flatcable e os dados das perifericas são colocados numa ram 61256 na placa master. Ha uma outra placa com monitor e teclado dedicado com um outro z80 que comunica com a placa master. Isso foi criado na decada de 80, mas se fosse usado o conceito do PC..placas burras, isso não funcionaria.


Mastk,
Penso em fazer tudo modular, placa cpu, placa memoria, placa I/O, placa de Video. Fazendo assim, posso modificar qualquer parte quando quiser.
Conectadas via Flat-cable ou futuramente com cartões eurocard e conector de 64pinos.
Por enquanto vou criar video composto, nao pretendo ligar o video em monitor vga.
Como tenho varios MC6847 aqui, pretendo primeiro fazer uma placa com este CI, no futuro desenvolver algo com cpld pra gerar vga.

[msamsoniuk]

acho que depende mastk!

para um bom sub-sistema de memoria baseado em sram de 16 bits e um clock de 14MHz, vc conseguiria uma banda total de 28MB/s. usando 640x400 a 30fps (NTSC), vc efetivamente consumiria algo como 7MB/s, o que dah 25% da banda. para um 68000 compartilhando este mesmo bus, isso impactaria em uma reducao equivalente a cair de 14MHz para 10MHz o clock. por outro lado, o 68000 nao usa efetivamente toda a banda sempre, entao na pratica as instrucoes abririam gaps entre sucessivos acesso ao bus e estes 25% de consumo de banda simplesmente poderiam sumir, dependendo do software em execucao.

essa seria uma primeira abordagem, com o 68000 efetivamente recebendo BR/BG do sub-sistema de DMA. o amiga usa algo um pouco mais inteligente, apesar de compartilhar a memoria principal e os buffers de video, na verdade ele separa o 68000 do bus.

assim, no lugar de gastar os 4 clocks totais do ciclo de acesso do 68000, este ganharia acesso ao bus de memoria apenas durante um clock. para isso bastaria um latch no meio do caminho, de forma que, do ponto de vista do 68000, ele pode gastar 4 clocks e do ponto de vista do sub-sistema de memoria apenas 1 clock eh gasto.

como o consumo de banda do 68000 de 14MHz no pior caso possivel (rodando NOPs) seria da ordem de 7MB/s, com os outros 7MB/s do video vc teria apenas 50% da banda total da memoria consumida. poderia adicionar ainda um canal de DMA para capturar video consumindo mais 7MB/s e talvez canais de DMA para audio ou outros recursos extras de video, como um DMA para auxiliar operacoes de geometria 2D e DMAs para canais de audio... isso explica em parte o sucesso do amiga: um controlador de memoria dram muito inteligente (o chipset agnus).

entao, sao dois casos a considerar no caso da memoria compartilhada. no primeiro existe boa possibilidade de nao haver impacto na performance e o sistema eh mais simples, no segundo essa possibilidade nao existe e vc ganha banda extra para mais coisas, mas requer alguns latches extras. em ambos os casos, vc tem toda a memoria de sistema disponivel tambem como buffer de video e isso parece uma vantagem em relacao a um sistema com memoria principal e memoria de video separadas.

no fim das contas, o que vale mais a pena: mais performance no processador central para desperdicar movendo bytes para a memoria de video (frame buffer separado da memoria principal) ou menos performance no processador central para nao precisar mover nada pela memoria (frame buffer na memoria principal) ?

[mastk]

Como diria zeh pequeno "na mao ou no pe, vai fala!" , mas mesmo usando um buffer da memoria principal, havera o trafego intenso de dados para video, eh de se avaliar, em caso de animacao, sei nao, para texto eh otimo usar a mesma memoria da cpu creio.

Meu Boot do meu sistema foi resolvido, tinha um curto do BG para o Vcc , mas agora ta resolvido , espero essa segunda postar algumas fotos...

[enigmabox]

Mastk,

Não usando a tecnica do AppleII antigo, ou seja, dependendo da fase do clock, funcionava, cpu-video-cpu-video-cpu....o sistema não fica tão amarrado.
Se nao me engano, na linha ZX spectrum, a cpu estava livre para processamento, nas bordas da imagem de video, ou seja antes de começar a area de apresentação do video no frame da tv, a cpu podia fazer outras tarefas, pois nao havia a interrupção do video.
O negocio é nao deixar a cpu do sistema fazer tudo. Acho que somente a cpu deve deixar a informação na area de video e o resto do sistema, ou seja dma ou outra cpu faz o resto do processamento de video.
O ideal seria memoria de porta dupla, ou sistema via dma que faz uma copia da ram principal para a ram de video, não usando a cpu principal do sistema para esta tarefa de copia.
No meu caso , vou usar o MC6847, mas poderia ser tb o TMS9928. A Cpu principal do sistema bota a informação na area de video que é isolada via latch e endereçada como I/O e o processador de video faz o resto. A cpu principal, atualizará a ram de video, somente quando a página de video dentro do frame for terminada, assim sobra bastante tempo.

[msamsoniuk]

o negocio eh ir montando os prototipos e ir testando! no meu caso quero estudar a implementacao de SMP mesmo, mas depois eu dou uma analisada se eh viavel adicionar um frame buffer nessa implementacao. depois a gente cria um benchmark padrao para ver quem faz a placa 68k mais veloz! como eu usei sram de 20ns, acho que estou em vantagem! hahaha

[enigmabox]

Marcelo Samsuniuk,

Meu proposito é conhecer mais a arquitetura do 68k, por isso estou montando a interface grafica de baixa resolução, mas futuramente quero fazer igual ao chaveamento de banco de ram/rom como o do MAC para implementar o frame-buffer. Esta logica de chaveameto de banco vem desde o AppleII, pois eu ja usava isso com banco de 128k e cpu z80. Se precisar reativo meu Apple II que tenho aqui pra relembrar.
Tu saiu na frente, eu tô com dois processadores velhos 68030 a 20mhz, com ram de 70ns. Nao sei se te alcanço!!!hehe
Será que existe ainda soquete PGA ou vou ter que soldar a cpu direto na placa?

[msamsoniuk]

vc pode montar um socket usando algumas barras de pinos torneados lado a lado. o acabamento nao fica tao bom como um socket especifico, mas funciona e com o chip em cima ninguem nota a diferenca.

[mastk]

mas para podemos comparar a performace dos nossos sistemas precissariamos ter uma certa compatibilidade, seria muito bacana se tivesemos...

Eu msm pretendo nao ter ROM no meu sistema, inicialmente.

[enigmabox]

Mastk,

A quantos MHZ está rodando seu 68K?
Vou iniciar o meu 68k com 7,31mhz, depois aumento até 20mhz.
Vou montar com eprom, tenho varias 27c512. Com flash 29f040, por enquanto nao dá pois tenho que montar outro gravador.

[msamsoniuk]

tendo um printf e compilando com o gcc jah fica meio que compativel neh ? hehehe eu estou montando com um clock de 14.7456MHz, talvez depois eu teste subir ateh 20MHz para ver se aguenta overclock.

[mastk]

ai ja comecam as diferencas, minha serial eh indireta vou determinar um buffer para o GP32 capitar e enviar pela serial, o engima para que vai usar CI dedicado da familia 68xxx.

GCC para mim eh coisa de outro mundo, sempre que fiz pesquisas sobre me vinha um rio de informacao e paths tal qual me perdia completamente.

[msamsoniuk]

como sao montagens experimentais realmente fica mais complexo planejar algo em termos de compatibilidade, principalmente pq os projetos vao sendo adaptados e alterados conforme surgem problemas.

eu estou usando o bus VME16 como referencia, mas acho dificil dizer que sera realmente compativel, em principio vou tentar colocar todos os sinais, mas nao sei se consigo tratar todos adequadamente como o padrao requer.

jah em relacao ao software, me parece q as diferencas se resumem mesmo a device drivers em particular para cada caso. o maior obstaculo, no entanto, acho que seria a disponibilidade de memoria. eu montei apenas 256KB e ainda nem tenho muita ideia do que vou rodar nesse sistema, mas possivelmente eu nao vou muito longe com tao pouca memoria! o bom mesmo seria montar um sistema com pelo menos 1MB, para rodar uclinux ou minix, mas vou continuar com essa configuracao para fazer mais testes em relacao a interface HC908 com 68000 e em relacao ao 68000 em configuracao SMP.

como eh facil desmontar os componentes pequeno, eu posso reutilizar no futuro esses 256KB em uma placa de video, por exemplo, e implementar uma placa SMP melhorada com pelo menos 1MB de dram, daih daria para rodar uclinux.