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).