68K ou coisa assim, again

[chrdcv]

hahahaha que maravilha hein colega?
O cara já está é divertindo e tirando onda de montão!

Parabéns pela iniciativa, trabalho e perseverança!

christian

[mastk]

bem, agora estou em um dilema.

A topologia do sistema esta errada graças a essa placa de video atual, se trabalhar na anterior e resolver seus problemas, poderei chegar a resolucao de 320x240x256bpp, ou poderia deixar tudo do jeito que esta e planejar novas placas de apoio, pena que estou com poucos slots disponiveis.

Como estao indo as coisa para vcs engma e sam?

[msamsoniuk]

eu estou tentando me preparar psicologicamente. talvez demore anos, mas certamente o dia q eu comecar eu termino o sistema em 3 dias hehehe

mas bom, qual problema esta ocorrendo ae na sua placa que esta limitando tanto o sistema ?

[mastk]

Bem, o 68K esta ocupado o tempo todo gerando video e nao posso assumir o BUS a qlqr hora, isso nao chega a ser um problema dependendo do objetivo, mas quero algo assim:



Com essa placa de video eh impossivel (320x240x1bpp, forçando um pouco), adicionando uma ROM e uma porta para o SD ou CF, teria um MAC 128, que ja seria legal, isso no ponto que a coisa esta daria um trabalhinho, e insistindo em ideias anteriores poderei ter um resultado melhor...

[enigmabox]

Bom, até agora não terminei a interface do teclado, que por sinal é bem facil.
A placa já tem 2 interfaces seriais, intrada para 7 IRQs, falta ligar o teclado para depois começar com o Boot loader, pois ficar gravando eprom a cada mudança de software, é um saco...
Depois disso quero tb fazer uma placa mais elaborada de video de preferencia com saida para monitor VGA e com processador de video proprio, penso em usar os 68010 que tenho aqui. Tb estou pesquisandp algumas cpus de video da Toshiba e Texas, para realizar esta função.
Pra terminar isso me falta tempo e coragem, hehe, espero concluir isso logo...
A tecnica que usei para a interface de video é como foi feita para os Apple, onde tenho um banco de memoria que pode ser acessado pelo 68030 e 6847, isolados com buffers tri-state. Assim não sobrecarrega o 68030 no processo de varredura que é feito pelo mc6847.
Mastk, acho que vc poderia fazer o mesmo assim sobra mais tempo para que o 68000 faça outras tarefas.
Uma coisa que o Marcelo Sam. sugeriu um tempo atras, usar uma CPU 68k para video e outra para processamento normal e outra pra I/O. Assim deixa o sistema mais rapido e eficiente, ficando com a eficiencia que vc necessitaria pra fazer um videogame.

[msamsoniuk]

eu nao entendi bem como vc esta fazendo mastk. vc esta usando uma memoria de video separada ou esta compartilhando ? acho que com algumas leves otimizacoes eh possivel melhorar o resultado sim.

[enigmabox]

Marcelo Sam,

Revirando o passado...hehe
Preciso de sugestões, o que seria mais viavel e facil de enviar um programa do PC para a placa do 68030. No caso de um bootloader para a placa do 68030, tenho duas ideias:


1)Se eu enviar o programa via serial 8 bits, a placa do 68030 tem que juntar os bytes enviados em uma word, e depois alocar na ram do sistema que é 16 bits. No final do carregamento executar o programa na ram.
Tenho que ver no meu compilador qual formato vou enviar, ou seja binario ou motorola e se é em 8,16 ou 32 bits.
A placa do 68030 já está preparada para ter o ckt de swap automático entre ram e eprom.

2) Será que é possivel usar um cartão SD, que contem o programa para a placa do 68030, assim tambem, teria que ter um chip conversor do cartão SD para dados paralelos como aqueles PCF8xxx da Philips.
Neste caso posso gravar no PC e depois plugar na placa 68030.
Qual cartão seria mais apropriado?

Teria mais alguma ideia de como adotar um bootloader?


Grato

[mastk]

1) Eu uso o S19, para serial nao vejo coisa melhor.

2) Acho qual cartao, nao influencia muito, desde que seja menor que 4 gigas.

Nao sabia que tinham conversores, SD-card/IDE...

eu nao entendi bem como vc esta fazendo mastk. vc esta usando uma memoria de video separada ou esta compartilhando ? acho que com algumas leves otimizacoes eh possivel melhorar o resultado sim.

Estou compartilhando, sam.

[msamsoniuk]

bom, eu acho que o formato S19 eh particularmente melhor, pq jah eh um padrao universal. neste software eu tenho um parse meia boca do S19, na funcao SerialUpload():

http://framework.sourceforge.net/hc908sh/hc908sh.c

basicamente ele recebe uma linha e faz o parse dos diversos campos para obter o endereco, tamanho do bloco e os bytes que compoe aquele bloco. vc nao precisa se preocupar com ordem dos bytes, pois jah estao na ordem correta. o 68000 usa a ordem natural de armazenamento, portanto a imagem binaria e seu espelho em S19 jah usam armazenamento na ordem correta. para facilitar, vc pode simplesmente gravar byte a byte, as sequencias gravadas vao compor words e long words corretamente.

quanto a interface com cartao de memoria, o que vc pode operar o cartao em modo mmc, que basicamente eh uma interface spi. daih fica facil neh! e sobre o cartao, imagino que o enderecamento da memoria esta orientada a blocos, como em um hd. no caso de um mpu como o 680x0, a interface paralela para o disco IDE pode ser mais simples que a interface spi do cartao!

vc poderia entao dar uma olhada na interface IDE paralela, ela eh de implementacao eletrica relativamente simples e, no lado da interface de aplicacao, eh basicamente alguns registros onde vc endereca setores de 512 bytes. assim, para manter coerencia dos blocos na forma de um filesystem, todo o enderecamento eh feito com inteiros de 32 bits, o que permitiria entao 4 bilhoes de blocos de 512 bytes (2TB!).

e falando em IDE paralela, um cdrom tambem seria uma possibilidade, porem o padrao ATAPI nao eh tao simples quanto interfacear um HD ou compact flash diretamente.

sobre o acesso para a memoria de video, talvez a forma de ganhar velocidade fosse ter uma pequena fifo entre a memoria e o pixel shifter. por exemplo, uma fifo de 40 bytes usando 1 bit por pixel jah daria conta de armazenar uma linha inteira, de modo que a arbitragem funcionaria com mais eficiencia:

a) requisitar o bus para o 68000
b) ler 40 bytes para a fifo
c) liberar o bus para o 68000

eu acho que os pontos que tomam mais tempo sao os pontos a e c. depois q o dispositivo obtem o controle ao bus, ele pode simplesmente ler a memoria na sua maxima velocidade de transferencia. e claro, usar dma com transferencia casada: a leitura na memoria jah trigga o write na fifo destino.

em essencia: agrupar os 40 acessos em um bloco seria melhor que ter acessos espalhados. em teoria, uma memoria com 70ns e largura de 16 bits poderia fornecer uns 25MB/s de dados. se vc tiver um sistema bem afinado, operando em NTSC com 1/4 da resolucao vc teria 320x240 pixels a 60Hz e 8 bits por pixel e isso requer apenas 4.6MB/s.

ou seja, o impacto na performance do 68000 seria de menos de 20% e vc teria a vantagem de poder usar toda a memoria como frame buffer, permitindo swap rapido de telas ou scroll xy apenas trocando o offset do controlador de dma de video!

olha que bacana: para scroll vertical, se vc somar no offset base 320, ele vai fazer scroll de 1 pixel para cima. se vc subtrair 320, vai fazer scroll de 1 pixel para baixo. somando 1 byte, a tela toda vai fazer scroll de 1 pixel para a esquerda e, subtraindo 1 byte, a tela toda vai fazer scroll de 1 pixel para a direita. eh claro que para usar o recurso vc tem que prever uma tela virtual bem maior, o que vai ocupar mais memoria. uma jogada tambem eh aplicar uma mascara de bits no controlador de dma, assim ele fica preso numa determinada area de memoria.

por exemplo, se vc alocar 1MB de memoria para video e criar uma area virtual de 1024x1024, bastaria aplicar uma mascara de 20 bits, de modo que os 20 bits MSB nunca mudem. assim quando o video vai para a beirada da memoria durante um scroll continuo, ele renasce lah no topo da memoria naturalmente!

para o caso de uma tela menor, 320x240, poderia mascarar offset para ele ficar preso numa area de 128KB, por exemplo. da mesma forma, vc continuaria usando a facilidade de alternar entre varias telas trocando o offset completo para apontar para qq area da memoria (o amiga fazia animacoes em realtime dessa forma).

[enigmabox]

Mastk,
No seu caso, acho que no seu caso não tem problema porque gera o arq. S19 em 8bits e envia para o 68K que tem memoria de 8 bits. Ai fica fácil.
O conversor que mensionei é aquelas interfaces I2C,SPI ou CAN para 8 bits. Tem varios mcu que tem esta interface dentro.
Quando não tem, tem que usar algo que converta, pois não dá pra ligar uma memoria serial no bus de dados diretamente. Alem disso tem que criar o Dsack 0 e 1, pra variar.

[enigmabox]

Marcelo Sam,

Vou dar uma estudada no seu codigo S19, já que fica mais facil adaptar, pois minha placa já tem 2 portas seriais com o SC68681.
Eu devo ter em algum canto aqui um artigo sobre interface IDE usando CPLD, devo ter tb um hd velho daqueles da epoca do 386, que vai me servir de cobaia.
Se a implementação do IDE é mais facil que usar cartões, vou partir para este caminho, pelo menos, não preciso gastar nada.
Depois preciso estudar como funciona o padrao IDE e o sistema de partição.
Já tenho um Atmega16 para o teclado e possui uma interface SPI, assim posso tb tentar adaptar futuramente isso para trabalhar com o cartão tb.

[msamsoniuk]

a interface IDE eh basicamente um sub-set do bus do 8086 fixo em 16 bits e operando em 8MHz. portanto basta ajustar uma terminacao assincrona sempre em 16 bits e com o numero certo de wait-states, dae fechou. talvez um par de 74F245 para dar um reforco no sinal de dados e um 74F244 para reforcar sinalizacao e enderecamento e fechou!

note que os registros da IDE basicamente sao porta de dados para leitura e escrita, registro de status e enderecamento de setores no disco, que pode ser linear ou CHS (cilindro, cabeca, setor). basicamente, escreve o endereco, envia o comando no registro de status e faz um polling para ver quando esta ready. o disco normalmente possui uma cache on-chip, entao vc pode escrever ou ler o setor inteiro o mais rapido possivel. seta novo endereco, espera ficar ready e desce lenha.

de saida, vc pode espetar na interface HDs e compact flashes, mas uma coisa que eu jah havia pensado eh que um bus destes na verdade serve como uma tremenda interface de IO, pq eh praticamente uma porta paralela de 16 bits em um espaco de IO de 16 bytes operando sincrona em 8MHz, onde vc pode tanto ligar coisas por um cabo flat de 40 pinos quanto espetar diretamente no conector na placa... bem melhor que uma interface centronics!

como referencia, veja as adaptacoes de discos IDE para o amiga 500, ele possui um 68000 e normalmente nao se usa mais que um par de 74F245 e alguma glue logic basica para wait-states (quando se usa! hehehe).

[enigmabox]

Marcelo,

Valeu pela ajuda....
A interface parece facil. No meu sistema já tenho os pontos de Dsack para 32,16,8 bits, assim acho que não será necessário usar muitas logicas auxiliares.
Estou usando logicas HC e HCT em toda a placa, assim o consumo ainda está baixo. Todo o circuito, placa 68030 + placa de vídeo, está consumindo 600mA em 5V, mas com a ligação do HD vou usar uma fonte de computador pois será necessário o 12V e o 5V.
Praticamente, quando fiz o barramento para ligar a placa de vídeo, usei um barramento de 8/16 bits, no caso do IDE somente tem que mudar a configuração dos pinos.
Já que a coisa tá crescendo, estou pensando em usar a logica de montagem do Mastk. Vou fazer uma placa base somente com a cpu e espetar as placas com memoria, interface video, interface IO, IDE, etc, ai fica mais facil adaptar e ampliar o sistema.
Agora falando em partição, qual seria mais facil de usar? Um FAT16, FAT32, ou alguma outra?

[msamsoniuk]

soh tem que adaptar algumas logicas, tipo no bus intel o read e write sao pinos separados, enquanto no 68k eh um pino soh r/w... mas fica bem compcto:

http://www.students.tut.fi/~leinone3/ide/ide68k.html

sobre fs, acho que fat16 eh mais facil de suportar, pq eh mais simples. se vc depois precisar de discos maiores, vc implementa fat32.

[enigmabox]

Até esta logica minha placa já tem. Pois tive que usar os sinais R/W com DS para gerar o RD e WR das Rams.
O que esta meio dificil de achar, para deixar um sistema com mais memoria é RAM estatica acima de 1Mb.