68K ou coisa assim, again

[msamsoniuk]

urra! ficou rapido hein, vc esta usando que resolucao no frame buffer? ficou cheio de placas a caixa hehehe, posta uma foto para a gente ver com mais detalhes! enfim, ficou realmente *muito* bom! se o steve jobs visse isso, ele chorava! hehehe

soh para constar: este topic comecou em 14 de outubro de 2006, tem 225 replies e jah foi visualizado 9273 vezes. a maquina com 68030 do enigmabox nao fica muito atras e a minha ainda nem comecou a funcionar...

[mastk]

Valeu sam, estou usando 320x240x1bp, a caixa esta cheia sim, por isso tenho problemas em fazer uma placa de video grande.

Agora ja adicionei 8Mb de flash ao sistema e estou fazendo uma placa de som bem simples, afinal nao tenho um bom conhecimento sobre som e nem tenho uma ideia muito clara sobre, falar de frequencia soa muito mais agradevel mas enfim.

soh para constar: este topic comecou em 14 de outubro de 2006, tem 225 replies e jah foi visualizado 9273 vezes. a maquina com 68030 do enigmabox nao fica muito atras e a minha ainda nem comecou a funcionar...

Nossa 2 anos e pouco

[msamsoniuk]

no macintosh antigo o audio rodava sincronizado com o intervalo de refresh horizontal e simplesmente transferia uma amostra de 8 bits de um buffer para um DAC, mas era meio simplorio. no caso amiga, existiam 4 canais separados, com 4 DAC separados de 16 bits, sendo 8 bits da amostra em si e mais 8 para controle de volume. as saidas analogicas eram mixadas para formar a saida, de modo que era possivel fazer musicas com 4 instrumentos diferentes simultaneamente... vc consegue ver esse esquema naquelas musicas em formato mod, onde os caras faziam magicas trocando os instrumentos para conseguir musicas bem elaboradas.

uma outra solucao seria imitar o chip de audio do msx, que gerava uma serie de ruidos e sons pre-programados, mas a qualidade da musica fica meio baixa, fica parecendo msx hehehe

ou seja, o bom mesmo eh ter canais de DMA de montao hehehe

[enigmabox]

Marcelo Samsoniuk

uma outra solucao seria imitar o chip de audio do msx, que gerava uma serie de ruidos e sons pre-programados, mas a qualidade da musica fica meio baixa, fica parecendo msx hehehe

Marcelo,

Nem precisa imitar, ainda dá pra encontrar na santa efigenia o chip AY3-8910 ou AY3-8912 da Yamaha, ou o usado em caça niqueis KRxxxx (não me lembro do numero.)
O AY3-8910 tem 3 canais de saida com controle de volume e porta I/O para uso generico.
Eu mesmo comprei varios AY3-8910 por um valor bem baixo, junto com varios CIs de Atari.

[enigmabox]

Marcelo Sam,

Já que tu tem mais experiencia em motorola que eu, gostaria de saber se tu pode me dar uma ajuda, pergunto:

Fiz um programa em assembly com rotinas para interrupções para minha placa com mc68030, mas usando somente opcodes do mc68000 para poder simular no Easy68K. O programa funcionou sem problemas no simulador, sem simular o ativamento da INT5 da cpu.
Quando fui rodar este programa na placa com MC68030 aconteceu alguns problemas quando a interrupção era ativa. Não sei se a cpu reconheceu a interrupção ou ficou rodando em algum loop de software.
Lendo o "pai dos burros" parece que o hardware do mc68030 tem que programar o master stack, supervisor stack, user stack e ISP.
Então um programa com interrupções feito para mc68000 é incompativel diretamente se for rodado em um hardware com mc68030?
Grato

[mastk]

Bem enigima, vc colocou os 3 stacks em possicoes distinas certo? seu hardware nao tem chances de estar gerando outro nivel de interrupcao que nao esta esperando? o lance de odd e even byte, conseguiu lhe dar com ele, que tipo isso muda bem do 68K para o 68030 ne? nem tenho A0 aqui para vc ter uma ideia.

[msamsoniuk]

pois eh, essa separacao em master supervisor mode e interrupt supervisor mode foi introduzida no 68020 para permitir threads no nivel de master supervisor mode... o truque seria justamente como compatibilizar isso com o 68000 e, de fato, nao eh complexo: normalmente a primeira coisa que fazemos durante o startup do codigo eh setar um valor legal no SR e depois setar o SSP. se vc simplesmente setar o SR com valores compativeis com o 68000, o flag M tera valor zero e o funcionamento sera equivalente ao 68000, pois o 68030 estara em modo interrupt e estara utilizando o ISP como SSP.

isso realmente nao faz muita diferenca para ele, pq eh um mero flag no SR, mas quando uma interrupcao ocorrer, ele vai se manter utilizando o mesmo ISP, como ocorre com o SSP no 68000. quando ocorrer o retorno de interrupcao, ele vai retornar o SR anterior e, portanto, continuara em interrupt mode e continuaram utilizando o ISP, exatamente o mesmo comportamento do 68000.

outras sugestoes adicionais: desligue a MMU e as caches para fazer os testes iniciais (vc pode fazer isso por hardware, atraves de pinos de configuracao). os 680x0 sao normalmente meio incompativeis entre si quando vc explora os recursos adicionais, mas com alguns cuidados eh possivel encontrar uma solucao parcial

bom... essa nao eh toda a verdade! suponho que vc NAO esta usando modo usuario no momento... ocorre que em modo usuario, se vc chamar as instrucoes trap, provavelmente o 68030 vai para modo master e vai querer usar o MSP. entao se for usar o modo usuario, tera que programar o MSP corretamente.

mas nesse caso vale uma dica similar:

1) programe o SR com o flag M desativado
2) programe o SP para a area que seria o ISP
3) programe o SR com o flag M ativado
4) programe o SP para a area que seria o MSP
5) termine a inicializacao e salte para modo usuario

quanto ocorrer interrupcao, ele vai usar o ISP, quando ocorrer trap, ele vai usar o MSP... entao a solucao final vai depender de vc querer usar ou nao o modo usuario.

Marcelo Sam,

Já que tu tem mais experiencia em motorola que eu, gostaria de saber se tu pode me dar uma ajuda, pergunto:

Fiz um programa em assembly com rotinas para interrupções para minha placa com mc68030, mas usando somente opcodes do mc68000 para poder simular no Easy68K. O programa funcionou sem problemas no simulador, sem simular o ativamento da INT5 da cpu.
Quando fui rodar este programa na placa com MC68030 aconteceu alguns problemas quando a interrupção era ativa. Não sei se a cpu reconheceu a interrupção ou ficou rodando em algum loop de software.
Lendo o "pai dos burros" parece que o hardware do mc68030 tem que programar o master stack, supervisor stack, user stack e ISP.
Então um programa com interrupções feito para mc68000 é incompativel diretamente se for rodado em um hardware com mc68030?
Grato

[enigmabox]

Mastk,
Quando faço um software sem uso de interrupções, funciona normalmente na placa do MC68030.
Domino bem a gravação de eprom em even e odd. Tanto que no inicio o hardware tinha memoria de 8 bits e depois passei para 16 bits sem problemas. Inclusive agora, tenho que trabalhar com endereços pares para a memoria ram e eprom e posso usar impares somente com I/O de 8 bits(video 6847 e 68681)
Acho que entendi a salada que fiz! O problema é que somente defini o SP e não expecifiquei os outros Stacks(Master e ISP). Somente declarei o espaço de User e Supervisor Stack. Ai pode ter dado caca quando chegou as interrupções.
Não uso o A0 para as memorias de 16 bits, mas somente para os perifericos de 8 bits, a placa de video e interface serial.

Marcelo,
Grato pelas dicas, acho que não funcionou porque não defini o ISP e nem mexi no bit do SR e SSP.
Fiquei dois dias testando o software , pensando que tinha defeito, no simulador rodova 100%....hehe
Depois lembrei e fui verificar as diferenças de uma cpu para outra ai surgiram as duvidas!
A MMU está desligada via software, usei uma microchave de 8 bits. Vc pode ver ela na foto da placa cpu.
Deixei o hardware 68030, o mais proximo possivel de um hardware com 68000, para nao dar confusão.
Não estou forçando um TRAP.
Defini o end. $3000 para a subrotina de interrupção da interface serial(68681) via interrupção INT5. No endereço $74(INT5) ele aponta para $3000 e a subrotina retorna com um RTE. Dando a interrupção o mc68030, guarda os registros A0 e D0 que serão utilizados com MOVEM, captura o registro SRA do 68681 e guarda na ram e verifica se o byte recebido é valido ou contem erros, depois devolve os valore de Ao e D0, via MOVEM e retorna da int com um RTE.
Verificando os led conectados na cpu observo que estou usando espaço do supervisor e fica piscando rapido o espaço do usuario, porque a ram esta em endereço apartir de $80000 com o Stacks e variaveis do meu S.O.
Depois da interrupção, vendo os leds parece que a cpu fica em loop em algum canto da eprom, ou seja , endereços baixos!
Depois no endereço $3100, $3200 e $3300, estao as subrotinas que informam erros de BUS, addrees error,illegal instruction. Usando as micro chaves de 8 bits tento forçar uma interrupção, mas nada acontece.
Outra coisa importante, eu uso o Easy68K para simular mas não para gerar codigo para eprom, assim uso o GNU AS, onde defino como cpu68030 e gero o bin e o Linker gera o EVEN e ODD da eprom.
Vou seguir suas dicas e depois conto se funcionou.
Obrigado.

[msamsoniuk]

bom, eu dei uma olhada melhor... e segundo o capitulo 4 do datasheet do 68030, ele boota por padrao usando o ISP (bit M zerado) e qq interrupcao usa o ISP. incrivelmente, no capitulo 8 ele fala sobre o tratamento de exceptions geradas por software e cita novamente apenas o ISP!

entao, ao que parece, se vc nunca setar o bit M para 1, o 68030 nunca usa o MSP, apenas o ISP! esse comportamento deve ser, portanto, equivalente ao 68000, ou seja, o problema pode ser outra coisa diferente!

curiosidade: vc esta usando AVEC para disparar um auto-vetor? minha sugestao eh vc comecar testando uma rotina apenas com um RTE direto. enquanto a interrupcao estiver presente, ele vai ficar interrompendo e voltando continuamente. no instante que vc desliga a interrupcao, ele deve continuar processando normal.

[enigmabox]

Caro Marcelo,


No inicio do codigo coloquei:


org 0
DC.L $00080040 ;sp
DC.L $00000400 ;pc
DC.L $00003100 ;bus error
DC.L $00003200 ;address error
DC.L $00003300 ;illegal instruction

org $74
DC.L $00003000 ;desvio da INT5 serial recepcao


A subrotina para interrupção serial:

org $3000
movem.w D0/A0,$80200 ;guarda valor dos registros D0 e A0
clr D0
move.l #$200001,A0 ;A0 com endereço do SRA
move.b (A0),D0 ;D0 tem valor SRA do 68681
movea.l #$80110,A0 ;Carrega A0 com endereço srabit
move.b D0,(A0) ;guarda valor SRA em srabit
movem.w $80200,D0/A0 ;restaura registros D0 e A0
rte

************************************
;* subrotina BUS ERROR
org $3100 ;bus error msg linha 12
movea.l #$100180,A5 :end ram de video
move #$45,D5 ;e
move.b D5,(A5)
adda #1,A5
move #$52,D5 ;r
move.b D5,(A5)
adda #1,A5
move #$52,D5 ;r
move.b D5,(A5)
adda #1,A5
move #$20,D5 ;espace
move.b D5,(A5)
adda #1,A5
move #$42,D5 ;b
move.b D5,(A5)
adda #1,A5
move #$55,D5 ;u
move.b D5,(A5)
adda #1,A5
move #$53,D5 ;s
move.b D5,(A5)
adda #1,A5
paracpu nop
jmp paracpu

******************************************

Será tb porque quando uso o MOVEM, que é uma instrução previlegiada, dentro da interrupção, pode haver algum problema, se não definir a area do ISP? Será que a cpu pega por engano o ultimo dado do registro A7?
Outra diferença entre o 68000 e o 68010/20/30 quando retorna de um RTE:

68000
retorna com novo conteudo de SR
retorna com novo conteudo de PC

680x0
retorna com novo conteudo de SR
retorna com novo conteudo de PC
Format | vector offset




Em relação ao hardware, acho que está tudo em ordem, pois se recebo algo via serial, automaticamente é ativada a INT5. Posso simular via microswich as outras interrupções, como o BUS error, Address error, etc, mas ativando manualmente não acontece nada, teria que apresentar na tela a msg de erro.
Por segurança tb, tenho uma subrotina que zera o espaço ocupado pelas variaveis do sistema, tais como, as variaveis de linha, coluna, contadores hexa, srabit, etc
Tb não estou usando o AVEC .

Acho que todo o erro é porque não defini a area do ISP, pois quando aparece alguma interrupção ele deve ter pego o valor de A7 e desviou para algum canto da memoria, apos ter recebido o RTE da subrrotina.
Vou ver se consigo hoje ou amanhã fazer mais alguns testes.

[mastk]

mas se nao usa o AVEC, tem que implementar a rotina de busca de vetor da respectiva interrupcao acionada, o que complica a coisa, certo?

[enigmabox]

Mastk,

mas se nao usa o AVEC, tem que implementar a rotina de busca de vetor da respectiva interrupcao acionada, o que complica a coisa, certo?

Acho que não. É só definir o desvio no endereço $74, como citei, que quando ocorrer a INT5 a cpu vai para o endereço indicado, e depois retornar com RTE.
No databook do mc68030 mostra uma tabela dos endereços para desvio no primeiro 1k da memoria, começando pelo endereço $00 que é o endereço do SP.
Os endereços iniciais de $0000 a $03FF são destinados a desvios por interrupção, erros, vetores, etc.
Se for usar interrupção que não seja por vetor, é só ver na tabela o endereço correspondente a interrupção e deixar ali o endereço do desvio para subrotina de tratamento da interrupção.
Por ex. TRAP#xx tb tem os endereços definidos no primeiro 1k da memoria onde podem ser colocados os endereços de desvios.
Sendo TRAP #xx uma interrupção forçada via software, o restante é via hardware.

[msamsoniuk]

Caro Marcelo,

No inicio do codigo coloquei:

org 0
DC.L $00080040 ;sp
DC.L $00000400 ;pc
DC.L $00003100 ;bus error
DC.L $00003200 ;address error
DC.L $00003300 ;illegal instruction

org $74
DC.L $00003000 ;desvio da INT5 serial recepcao

segundo as ultimas interpretacoes dos capitulos 4 e 8 do datasheet, vc inicializou corretamente o ISP com o valor 0x80040 e ele sera utilizado para exceptions (TRAP, etc) e interrupcoes.

A subrotina para interrupção serial:

org $3000
movem.w D0/A0,$80200 ;guarda valor dos registros D0 e A0
clr D0
move.l #$200001,A0 ;A0 com endereço do SRA
move.b (A0),D0 ;D0 tem valor SRA do 68681
movea.l #$80110,A0 ;Carrega A0 com endereço srabit
move.b D0,(A0) ;guarda valor SRA em srabit
movem.w $80200,D0/A0 ;restaura registros D0 e A0
rte

cuidado: vc salvou os registros usando movem.w (word), mas logo abaixo vc puxa a0 com move.l... entao a interrupcao suja a word MSB de a0 e provavelmente causa algum crash quando retorna

alternativamente, vc poderia salvar e restaurar os registros na stack mesmo:

Código: Selecionar todos

interrupcao:
  movem.l d0-d7/a0-a6,-(sp)
  codigo
  movem.l (sp)+,d0-d7/a0-a6
  rte


e claro, lembre-se que o 68030 eh CISC e portanto nao eh necessario um par de instrucoes load/store para cada operacao com dados: vc poderia carregar apenas o endereco do buffer de memoria em A0 e ler do endereco absoluto da UART direto para o buffer de memoria. a vantagem eh que se o buffer da memoria for um pequeno ring buffer de recepcao, vc pode auto-incrementar A0 na mesma operacao, algo como:

Código: Selecionar todos

  move.l uart_ring_buffer_ptr,a0
  move.b uart_rx_fifo_ptr,(a0)+
  move.l a0,uart_ring_buffer_ptr


obviamente esse buffer vai aumentando, entao como adicional vc precisaria testar se ele nao chegou ao limite e entao fazer ele voltar ao inicio.

************************************
;* subrotina BUS ERROR
org $3100 ;bus error msg linha 12
movea.l #$100180,A5 :end ram de video
move #$45,D5 ;e
move.b D5,(A5)
adda #1,A5
move #$52,D5 ;r
move.b D5,(A5)
adda #1,A5
move #$52,D5 ;r
move.b D5,(A5)
adda #1,A5
move #$20,D5 ;espace
move.b D5,(A5)
adda #1,A5
move #$42,D5 ;b
move.b D5,(A5)
adda #1,A5
move #$55,D5 ;u
move.b D5,(A5)
adda #1,A5
move #$53,D5 ;s
move.b D5,(A5)
adda #1,A5
paracpu nop
jmp paracpu

******************************************

geralmente nas exceptions fatais, como o bus error, eu mascaro as interrupcoes e depois faco um dump de 256 bytes da stack, para ver o endereco da instrucao que gerou o bus error

Será tb porque quando uso o MOVEM, que é uma instrução previlegiada, dentro da interrupção, pode haver algum problema, se não definir a area do ISP? Será que a cpu pega por engano o ultimo dado do registro A7?
Outra diferença entre o 68000 e o 68010/20/30 quando retorna de um RTE:

68000
retorna com novo conteudo de SR
retorna com novo conteudo de PC

680x0
retorna com novo conteudo de SR
retorna com novo conteudo de PC
Format | vector offset

o ISP vc esta definindo na tabela de vetores e, por compatibilidade, o 68030 boota com o ISP ativo, portanto qq acesso ao SP ou A7 eh feito no ISP e ele esta inicializado automaticamente no boot.

sobre o movem.l, nao eh instrucao privilegiada e nao possui problemas. ateh onde eu lembro, eh uma instrucao que opera de forma simetrica, nao tem muito como errar... mas se vc tiver duvidas, tente usar move.l normal no lugar. eu tive uma surpresa no coldfire com movem.l pq ela usava acessos burst e a minha sdram estava configurada errada hehehe

mas depois, configurando corretamente, movem.l funcionou perfeitamente.

sobre os quadros de stack, nao precisa se preocupar, pq cada cpu armazena e restaura os quadros automaticamente.

Em relação ao hardware, acho que está tudo em ordem, pois se recebo algo via serial, automaticamente é ativada a INT5. Posso simular via microswich as outras interrupções, como o BUS error, Address error, etc, mas ativando manualmente não acontece nada, teria que apresentar na tela a msg de erro.
Por segurança tb, tenho uma subrotina que zera o espaço ocupado pelas variaveis do sistema, tais como, as variaveis de linha, coluna, contadores hexa, srabit, etc
Tb não estou usando o AVEC .

Acho que todo o erro é porque não defini a area do ISP, pois quando aparece alguma interrupção ele deve ter pego o valor de A7 e desviou para algum canto da memoria, apos ter recebido o RTE da subrrotina.
Vou ver se consigo hoje ou amanhã fazer mais alguns testes.

na verdade ISP deve estar ok, ele eh carregado no boot como sendo o SP inicial para o modo supervisor... talvez a falha seja vc ter usado movem.w ao inves de movem.l

uma estrategia que eu usei bastante foi fazer rotinas para o 68681 trabalhar apenas com polling, assim podia fazer testes iniciais sem muitos problemas e colocar mensagens em todas as exceptions, por exemplo.

apenas mais tarde implementei o acesso a serial via interrupcao e dma, para permitir velocidade maior, mas todas as rotinas basicas de erro continuam com polling, para permitir continuar debugando durante as falhas

[msamsoniuk]

eh que normalmente as fontes internas usam vetores de 0 a 63 e as externas de 64 a 255, por isso confundimos com o AVEC... para o 68681, que trabalha com interrupcao vetorada externamente, o ideal seria usar o vetor 64, justamente para ficar diferente e poder monitorar os outros vetores. desta forma, todas as entradas nao utilizadas da tabela de vetores deveriam ser inicializadas com uma rotina de tratamento generica de erro e isso garantiria um completo monitoramento para eventuais falhas

Mastk,

mas se nao usa o AVEC, tem que implementar a rotina de busca de vetor da respectiva interrupcao acionada, o que complica a coisa, certo?

Acho que não. É só definir o desvio no endereço $74, como citei, que quando ocorrer a INT5 a cpu vai para o endereço indicado, e depois retornar com RTE.
No databook do mc68030 mostra uma tabela dos endereços para desvio no primeiro 1k da memoria, começando pelo endereço $00 que é o endereço do SP.
Os endereços iniciais de $0000 a $03FF são destinados a desvios por interrupção, erros, vetores, etc.
Se for usar interrupção que não seja por vetor, é só ver na tabela o endereço correspondente a interrupção e deixar ali o endereço do desvio para subrotina de tratamento da interrupção.
Por ex. TRAP#xx tb tem os endereços definidos no primeiro 1k da memoria onde podem ser colocados os endereços de desvios.
Sendo TRAP #xx uma interrupção forçada via software, o restante é via hardware.

[enigmabox]

Marcelo,

Tu ta enxergando melhor que eu...hehe
Deve ser isso mesmo , esqueci e deixei como MOVEM.W no lugar de MOVEM.L. Por isso que depois da interrupção, bagunça o A0 e D0, pois movimenta apenas o LSB do LONG A0/D0.

As rotinas de erro, fiz de modo simples para apenas ver qual erro deu na tela e parar a cpu, depois implemento com outros recursos. O legal seria como vc falou, na interrupção de erro, visualizar em qual ponto deu pane.

Por enquanto no 68681, estou lendo byte por byte, depois vou habilitar a leitura da fifo(3bytes) quando tiver cheia. Agora somente verifico o bit RxRDY e os de erro do SRA, se tiver tudo OK, transfiro o byte recebido pela porta A (RHRA) para uma variavel na memoria RAM, para posterior conversão ASCII para HEXA.
Quanto vc recomenda de espaço para as stacks? Estou usando 50h de espaço para cada stack onde posso guardar até 20 endereços. Acho que somente vai dar problema se tiver muitas subrotinas chamando outras, ai pode encavalar um espaço de stack com outro.
Valeu pela ajuda, vou ver se continuo com os testes hoje.