domingo, 9 de dezembro de 2007

Adaptador CF Interno

Condensando alguns projetos de ZX Spectrum ([1], [2]) e fazendo algumas medições no adaptador CF-IDE que possuo (idêntico ao modelo à direita nesta foto) cheguei à seguinte pinagem:



A interface IDE-CF pode ser alimentada pelo pino 20 a partir dos 5Vcc do micro.

O sinal Y7 é o /CS (Chip Select) na faixa de endereços 0B8h~0BFh, disponível no pino 7 de IC5 (74LS138) no HotBit (mesmo pino de IC29 no Expert).

Uma observação importante é que esta faixa de endereços é reservada para a "light pen" da SANYO, e para controle do "VHD".

sexta-feira, 16 de novembro de 2007

Pseudo DMA para o VDP

A porta de dados do VDP do MSX1 faz um incremento automático do endereço de acesso a cada instrução de transferência. Isso pode ser usado para simular um DMA no VDP. Um exemplo semelhante pode ser visto neste link.

O princípio de funcionamento consiste na manipulação dos sinais de escrita e de leitura, tanto do periférico quanto do VDP de tal forma que quando o Z80 lê um determinado endereço, o sinal de decodificação aciona tanto o sinal de leitura do periférico quando o sinal de escrita do VDP, e vice-versa para uma transferência VDP->periférico. Em ambos os casos, é utilizada a instrução de leitura do Z80, de forma que não há a necessidade de resistores de isolação de barramento, como no exemplo com o AVR. Contudo,m é importante que tal como o VDP, o periférico também possa realizar transferência em modo "burst", como é o caso de um cartão SD/MMC.






A velocidade de transferência é igual à velocidade de acesso à memória ou de acesso de I/O do Z80, ou seja, praticamente a mesma velocidade que se obteria com um acesso direto à VRAM.

Uma estimativa desta velocidade, para uma transferência de 16K, com um clock de 3,579MHz é:

LD B,0
TRANSF:
IN A,(P_DMA) (64x) 12 x 64
DJNZ TRANSF 14 / 9

Ao todo são 256 * ( (12*64) +14 ) - 5 = 200187 ciclos.

Num Z80 a 3,579MHz, isso significa 55,933ms

Então temos uma taxa de pico de aproximadamente 16K/55,933ms = 286,05Kbytes/segundo.

quarta-feira, 14 de novembro de 2007

SPI na porta de Joystick

O barramento SPI é muito utilizado como interface diversos tipos de CIS: ADCs, RTCs, DIGIPOTS, SERIAL FLASHes, e mesmo cartões SD/MMC.

Este barramento constitui-se dos seguintes sinais
MOSI - Master Out, Slave In, ou seja (Saída, do ponto de vista do MASTER)
MISO - Master IN, Slave Out (Entrada)
SCLK - Serial Clock (Saída)
SS - Slave Select

Um inconveniente do SPI é a necessidade de se utilizar um sinal SS para cada periférico conectado. Principalmente porque na porta de Joystick do MSX temos apenas 3 pinos de saída, ou seja, apenas um pino disponível para Chip Select.

A solução foi utilizar esta saída livre para realizar ao mesmo tempo o 'reset' e o 'clock' de um contador. Para distinguir um evento do outro, foi utilizada uma rede RC, de forma que um pulso mais longo provoque o 'reset' do contador, e um pulso mais curto provoque uma contagem.

Na implementação para o MSX, o pino escolhido para RESET/COUNT foi o pino 8 (pulse), que fica normalmente em 0 (zero). Para prevenir que uma contagem aconteça durante um pulso de leitura de 'paddle', uma segunda constante RC foi adicionada.

O diagrama de blocos encontra-se na figura abaixo:



E o código de seleção de dispositivo pode ser visto abaixo.

;
; Seleciona dispositivo SPI
; Entrada:
; D: número do device SPI
; Saida:
; B: estado registro 15 do psg
; Modifica:
; A, D, DI,
SELDEV:

; seleciona e salva registro e 15 do PSG
CALL SAVEPSG

; saída PULS (p 8) nível 1 por 1ms
SET SHFT,A ; PULSE 1
RES ABSEL,A ; JOY 1
OUT [PSGWR],A
CALL WAIT1MS
RES SHFT,A
OUT [PSGWR],A


; gera D pulsos
; cada pulso tem 100us de largura
; para o circuito não se confundir
; com pulso de leitura de paddle
SLDV0:
CALL WAIT100US
SET SHFT,A
OUT [PSGWR],A
CALL WAIT100US
RES SHFT,A
OUT [PSGWR],A
DEC D
JR NZ,SLDV0
; salva valor reg 15 psg
LD B,A
EI
RET

sexta-feira, 9 de novembro de 2007

Enviando dados via RS232 na porta de Joystick

Em muitos microcontroladores sem UART real é comum emular este periférico gerando os bits, um a um, via Software. Mas para fazer isso é necessário saber exatamente o tempo de execução de cada instrução, de forma a se produzir as temporizações corretas.

No MSX deve-se levar em consideração não somente os ciclos de máquina gastos com cada instrução, mas também o WAIT STATE inserido a cada ciclo M1.

O Ciclo M1 é gerado durante a busca de instruções do Z80 ("opcode fetch"), mas há algumas instruções onde esse ciclo ocorre mais de uma vez, ou seja, é necessário somar um ciclo a mais para cada ciclo M1 gerado.

Um exemplo é a instrução NEG:

INSTR BYTES M1
NEG 2 OCF(4)/OCF(4)
Esta instrução gasta ao todo 10 ciclos de máquina para ser executada no MSX.

Uma relação completa das instruções do Z80, bem como da quantidade de ciclos por instrução, e a quantidade de ciclos M1 pode ser encontrada neste link: http://www.z80.info/z80ins.txt

A rotina abaixo envia um byte recebido no registrador A pelo pino 6 da porta B de joystick.


;
; Bits do Registro 15 do PSG
;
BTXD EQU 2
ABSEL EQU 6

;
; Registros do PSG
;
PSGAD EQU 0A0H
PSGWR EQU 0A1H
PSGRD EQU 0A2H


;
; Constantes

; BaudRates
;BAUD EQU 8 ; 19200 Bauds, -0.32% erro
;BAUD EQU 14 ; 14400 Bauds, -1.8% erro
BAUD EQU 25 ; 9600 Bauds, -0.32% erro
;BAUD EQU 59 ; 4800 Bauds, -0.32% erro
;BAUD EQU 127; 2400 Bauds, -0.32% erro
;BAUD EQU 255 ;1200 Bauds, 2.6% erro



;
; A: Byte a ser transmitido
; B: Estado atual do registrador 15 do PSG
;
SND232:
LD C,A
LD A,B

; Start bit
LD L,BAUD
CALL SND0 ; 17+1 + (SEND0)

; 8 bits
LD B,08H ; 7+1
LD L,BAUD ; 8

S20:
RRC C ; 8+2
CALL C,SND1 ; 17+1 + (SEND0)/ 10+1 F
CALL NC,SND0 ; 17+1 + (SEND0)/ 10+1 F
DJNZ S20 ; 13+1 b<>0/ 8+1 b=0

; Stopbit - return line to IDLE state
LD L,BAUD ; 8
CALL SND1 ; 17+1 + (SEND0)
LD B,A ; 4+1
RET ; 10+1


SND0:
RES BTXD,A ; txd=0 8+2
OUT [PSGWR],A ; 11+1
S01: DEC L ; 4+1
JP NZ,S01 ; 10+1 ;
RET ; 10+1


SND1:
SET BTXD,A ; txd=1 8+2
OUT [PSGWR],A ; 11+1
S01: DEC L ; 4+1
JP NZ,S01 ; 10+1 ;
RET ; 10+1


E Antes de imprimir, é necessário desabilitar as interrupções e inicializar o registro 15:
PRNTJ232:
DI
LD A,15
OUT [PSGAD],A
IN A,[PSGRD]
LD [PSGSAV],A

SET ABSEL,A ; JOY B
SET BTXD,A ; SDA=1
OUT [PSGWR],A
LD B,A

domingo, 28 de outubro de 2007

Paddle do NES no Arkanoid do MSX?

Estava investigando o código desassemblado do Arkanoid1 para procurar uma maneira de fazer um "patch" para colocar um paddle, quando me deparei com um trecho de código bem interessante, que sugere que o MSX possa utilizar o mesmo controlador de Arkanoid do NES, mudando apenas o conector.
O pino 6 é utilizado como sinal de clock, o pino 8 como sinal de select/LOAD e os dados vêm pelo sinal UP do joystick.

O trecho de código abaixo ilustra o protocolo.
...
42fc 3e0e      ld      a,0eh
42fe d3a0      out     (0a0h),a
4300 dba2      in      a,(0a2h)
4302 67        ld      h,a
4303 0608      ld      b,08h       ; 8 bits
4305 0e00      ld      c,00h
4307 1e00      ld      e,00h
4309 3e0f      ld      a,0fh
430b d3a0      out     (0a0h),a
430d 3e1e      ld      a,1eh
430f d3a1      out     (0a1h),a    ; clock low
4311 3e1f      ld      a,1fh
4313 d3a1      out     (0a1h),a    ; clock high
4315 3e0e      ld      a,0eh
4317 d3a0      out     (0a0h),a
4319 dba2      in      a,(0a2h)
431b 5f        ld      e,a
431c cb3f      srl     a           ; lê bit
431e cb11      rl      c           ; armazena em C
4320 10e7      djnz    4309h       ; próximo bit
4322 79        ld      a,c
4323 32c1e0    ld      (0e0c1h),a  ; armazena byte recebido 
4326 7c        ld      a,h
4327 e601      and     01h
4329 32c2e0    ld      (0e0c2h),a
432c 3e0f      ld      a,0fh
432e d3a0      out     (0a0h),a
4330 3e1f      ld      a,1fh
4332 d3a1      out     (0a1h),a    ; pino8 high
4334 3e0f      ld      a,0fh
4336 d3a1      out     (0a1h),a    ; pino8 low
4338 3e1f      ld      a,1fh
433a d3a1      out     (0a1h),a    ; pino8 high
433c 3e0e      ld      a,0eh
433e d3a0      out     (0a0h),a
4340 dba2      in      a,(0a2h)
4342 5f        ld      e,a
4343 21c4e0    ld      hl,0e0c4h
4346 7e        ld      a,(hl)
4347 73        ld      (hl),e
4348 e60f      and     0fh
434a a3        and     e
434b ab        xor     e
434c 32c5e0    ld      (0e0c5h),a
434f 47        ld      b,a
4350 3a0be0    ld      a,(0e00bh)
4353 b7        or      a
4354 c0        ret     nz

4355 cb48      bit     1,b
4357 c8        ret     z

4358 3a0ae0    ld      a,(0e00ah)
435b b7        or      a
435c ca7043    jp      z,4370h
435f af        xor     a
4360 320ae0    ld      (0e00ah),a
4363 213ce5    ld      hl,0e53ch
4366 113de5    ld      de,0e53dh
4369 3600      ld      (hl),00h
436b 010700    ld      bc,0007h
436e edb0      ldir 
4370 3e01      ld      a,01h
4372 320ce0    ld      (0e00ch),a
4375 c9        ret  
...

quarta-feira, 3 de outubro de 2007

Copy 3

Usando um compilador chamado "pasmo" consegui compilar o código de um copiador para fita cassete chamado copy 3, que "imitava" o estilo do PCTOOLS.

Este copiador foi o primeiro programa "sério" que fiz para o MSX em Assembly. Um detalhe interssante é que os caracteres em fundo inverso eram simulados com caracteres redefinidos.

Seguem abaixo 2 screenshots, rodando no BlueMSX:





domingo, 23 de setembro de 2007

Sistema de arquivos TIC-TAC

TIC-TAC: Sistema de arquivos para pequenos dispositivos.

O sistema de arquivos TIC-TAC foi concebido para utilização com pequenas unidades de armazenamentos de memória, com capacidade de até 128Kbytes. Apesar de ter sido projetado inicialmente para os "picodrives" conectados via interface I2C no MSX, outros dispositivos de memoria podem ser utilizados, bem como outros processadores ou microcontroladores.

O nome TIC-TAC vem de:

TIC Tabela identificação de caracteres
TAC Tabela de alocação de cadeias

Estas tabelas são utilizadas para organizar o armazenamento dos arquivos de forma semelhante a uma FAT. Devido à limitação de espaço, o número máximo de arquivos que podem ser armazenados é de 64. Dessa forma os arquivos podem ter nome com 8 caracteres de comprimento e um byte de atributos.

A TIC ocupa os primeiros 768 bytes da memória serial. Compõe-se de um cabeçalho com 64 bytes de cabeçalho, e de 64 entradas de arquivos (com 11 bytes). A estrututa da TIC encontra-se na tabela abaixo:

Cabeçalho:

Bytes Função/descrição
02 Assinatura - "ST"
10 Nome do dispositivo (volume)
01 Bit 7: Flag de Boot
Bits 5..0: Entrada da TIC (bits 5..0) do programa de boot.
01 Tamanho em setores) do dispositivo (Máximo 128K)
01 Tamanho da página de escrita da Flash
49 Vazio. Reserva para expansões
-----
64 Total de bytes do cabeçalho da TIC


Entradas:

08 Nome do arquivo
01 Atributos
Bit 7: Indica uma entrada apagada
Bit 6: Indica proteção contra escrita/apagamento
Bits 1..0: Tipo de arquivo
00 - Basic
01 - Binário
10 - Dados
11 - Tela
01 Tamanho do arquivo (quantidade de entradas na TAC)
01 Ponto de entrada na TAC
------
11 x 64 = 704 bytes

Total 64+704=768 bytes

Para calcular a quantidade de setores ocupados por um arquivo, a seguinte fórmula é utilizada:

QUANT = 1 + [ ( TAMARQ - 1) DIV 512 ] , onde TAMARQ é o tamanho em bytes do arquivo.

Já a TAC ocupa 256 bytes e corresponde a um mapa de setores (512bytes) da memória serial. A posição da entrada na TAC (1 byte) corresponde à posição de um setor (512 bytes) no dispositivo. Assim, a primeira entrada na TAC corresponde aos Bytes (0..511), a segunda aos bytes (512..1023), a terceira aos bytes (1024-1535) e assim sucessivamente.

O conteúdo de uma entrada da TAC armazena a posição da próxima entrada, formando assim uma cadeia de entradas. A última entrada é utilizada para armazenar quantos bytes (em múltiplos de 4) são armazenados no último setor. Como uma entrada de valor "0" (zero) significa um setor vazio (não utilizado), o valor do último setor é acrescido de um, ficando então entre 01 e 128, representando de 04 a 512bytes.

Para calcular o valor do último byte da seqüencia a seguinte fórmula é utilizada:

VALOR = 1 + [ ( TAMARQ MOD 512 ) DIV 2)

Preâmbulo dos arquivos:

Os 16 primeiros bytes do arquivo são utilizados para armazenar algumas informações que não cabem nas entradas de arquivo, como data e hora, e configuração da máquina.

Os bytes 0 a 6 armazenam informações de data e hora:

Byte Conteúdo
0 Bits 6..0 Segundos (00..59) em BCD
1 Bits 6..0 Minutos (00..59) em BCD
2 Bits 5..0 Horas (00..23) em BCD
3 Bits 5..0 Dia do mês (00..31) em BCD
4 Bits 2..0 Dia da semana (0..6), Domingo=0
5 Bit 7: Século, 0=2000, 1=1900;
Bits 4..0: Mês (1..12) em BCD
6 Bits 7..0 Ano (dezena, 00..99) em BCD

O formato dos bytes 7 a 15 depende do tipo de arquivo. Para arquivos Basic ou de Dados, estes bytes ficam sem uso. Para arquivos binários e de tela, o formato encontra-se abaixo:

Para aquivos binários:

Byte Conteúdo
7,8 Endereço de de entrada (carga) do programa na memória
9,10 Endereço de execução do programa
11 Configuração de Slots primários para carga do programa
12 Configuração de Slots secundários para carga do programa
13..15 Reservado para uso futuro

Para aquivos de tela:

Byte Conteúdo
7,8 Endereço de entrada na VRAM
9 Modo de tela (screen)
10..15 Reservado para uso futuro

segunda-feira, 27 de agosto de 2007

Simple com FSAVE/FLOAD

Fiz hoje o 'backup' da imagem da ROM do meu cartucho com uma versão do Simple Assembler hackeada, capaz de gravar/ler o código fonte em um único bloco da fita, a uma velocidade de 1800 bauds através dos comandos FSAVE e FLOAD.

Este cartucho me acompanha até hoje.

Titulador de Vídeo com TMS9128

A revista "Radio Electronics" publicou em novembro de 1985 a primeira parte de um artigo ensinando a construir um titulador de vídeo a partir de um TMS9128. Tenho somente a primeira parte, mas descobri que ao todo o projeto foi dividido em 4 artigos. A primeira parte explica os segredos para a sincronização do TMS9128 com um sinal de vídeo externo: quais as dificuldades envolvidas e como superá-las.


A sequência de artigos é a seguinte:

Video titler. Keyboard device is used to superimpose titles on video images. May also be interfaced with a home computer to superimpose computer-generated graphics or real-time animation on a standard video signal. Est. cost: $300. Part 1.
RADIO-ELECTRONICS Nov 1985 (v.56#11) pg. 45

Video titler. Part 2.
RADIO-ELECTRONICS Dec 1985 (v.56#12) pg. 65

Video titler. Part 3.
RADIO-ELECTRONICS Jan 1986 (v.57#1) pg. 57, 77, 79

Video titler. Part 4. Software and how to interface the titler to a home computer.
RADIO-ELECTRONICS Mar 1986 (v.57#3) pg. 62

(fonte)

segunda-feira, 13 de agosto de 2007

MorseX

Encontrei alguns programas numa fita antiga, junto com o código fonte de vários deles.
Um que merece destaque é o MorseX, de 1994, cujo código foi a adaptação para o Z80 do artigo "Designing with the 8080 microprocessor. Part 4. A typical program. Sample program converts Morse code to ASCII code", da autoria de Randy Carlstrom, publicado na revista Popular Electronics, volume.19 Número 12 (pg. 74) em dezembro de 1981. Infelizmente não consegui localizar ainda o artigo, mas pelo menos localizei a fonte, a partir dos comentários da versão desenvolvida em pascal para o PC.

A entrada de código morse é lida a partir do botão de tiro do joystick "A". O artigo também tinha
um detector de tom baseado num 556 (não tenho mais o esquema, infelizmente). O algoritmo de detecção se adaptava à velocidade, e o programa 'basic' permite alterar 2 parâmetros de funcionamento: 'Noise' e 'Delay'.

Abaixo alguma fotos:

Tela de Abertura em Basic:


Tela de abertura (pressione ENTER para avançar):



Eu tentando manipular alguma coisa:



O programa pode ser baixado neste link

quarta-feira, 8 de agosto de 2007

Layouts para Mapper Simplificada

Terminei o roteamento da placa de memória para o Hotbit e para o Expert. Fiz algumas otimizações de forma a facilitar a soldagem dos chips de DRAM, e diminuir o 'excesso' lateral da placa, para não encostar nos capacitores de desacoplamento.

Placa do Hotbit:


Placa do Expert:

domingo, 5 de agosto de 2007

Clock para Hotbit convertido em 2.0

Eu hoje retirei um VDP original de um Hotbit transformado em 2.0 através de um cartão de 80 colunas modificado, mas depois vi que o VDP antigo tinha uma única função: gerar o 'clock' pro Z80.

Projetei então um adaptador pra ser colocado onde antes era colocado o VDP original, com um oscilador de 3,578MHz e um pull-up pra linha INT.

Eis abaixo a placa já roteada



E o circuito.


sábado, 4 de agosto de 2007

Mapper simplificada - Placas

Montei as duas placas da 'Mapper' simplificada. Agora falta fazer alguns testes. Seguem abaixo as fotos.

Detalhe da soldagem do 74LS32


Mapeador


Estudo de posicionamento

sábado, 28 de julho de 2007

Mapper 256K simplificada (2)

Complementando o post anterior, fiz o roteamento da placa do mapeador e da placa com os pentes de memória e o controle do sinal /CAS

A placa do mapeador tem um conector de entrada de 20 pinos cuja pinagem foi disposta de forma a poder ser interligada apenas com fios retos ao conector de 50 vias do slot (lateral no Hotbit, frontal no expert). Dessa placa saem 4 fios, sendo 2 com as linhas AA14 e AA15, que devem ir aos LS157 na placa do MSX, e 2 com as linhas AA16 e AA17 que devem ir à placa de memória.



Conector do mapeador:



No Hotbit a conexão fica mais ou menos como na figura abaixo (os LS157 podem não estar na posição certa pois não me lembro de cabeça da placa, e não estou com um Hotbit à mão agora).



A placa de memória foi roteada para ser plugada em cima do banco de memória. Ainda tenho que fazer um ajuste fino, para poder fazer a pinagem bater com o micro. É bem provável que o espaçamento seja diferente para o Hotbit e para o Expert (e para outros MSX), mas o 'layout' foi roteado para ser facilmente adaptável.

quinta-feira, 26 de julho de 2007

Mapper 256K simplificada

O objetivo deste circuito é implementar uma Mapper com um mínimo de componentes.

Utilizando um LS670, um LS688, um LS32 e dois chips de DRAM de PC de 1M x 4 é possível implementar uma 'Mapper' de 256K rapidamente.

O 688 serve para decodificar os sinais A2-A7, /IORQ, /WR e /M1 e gerar o sinal /GW para o LS670, que recebe em sua entrada sinais D0~D3 e gera os sinais AA14~AA17.

AA14 e AA15 vão aos multiplexadores (LS157) na placa do MSX. Os pinos destes CIs devem ser levantados, pois são conectados originalmente às linhas A14 e A15 do Z80. Os pinos levantados recebem os sinais AA14 e AA15.

A tabela abaixo contempla a pinagem dos multiplexadores de interesse tanto no Hotbit quanto no Expert

MSX A14 A15
HOTBIT: IC23,Pino 10 IC24,Pino 10
EXPERT: IC23,Pino 13 IC23,Pino 14



AA16 e AA17 vão às linhas de endereço AA8 e AA9 das DRAMS, para selecionar 4 colunas diferentes, ou seja, quatro bancos diferentes de 64Kbytes, totalizando assim 256Kbytes.

Duas portas de um LS32 servem para forçar as linhas AA8 e AA9 da DRAM sempre num mesmo nível (nível 1) enquanto o sinal CAS ainda não foi disparado, garantindo assim que as linhas a serem acessadas (e refrescadas) sejam sempre as mesmas. Duas portas restantes deste CI servem para atrasar ligeiramente o sinal CAS de forma a garantir que as linhas AA8 e AA9 já tenham estabilizado quando o CAS for a nível zero.

O circuito da 'Mapper' pode ser visto abaixo. Clique na imagem para ampliar:


OBS: Adicionando-se um segunto LS670 e mais um LS157 e um LS393 é possível expandir a capacidade deste circuito para 1Mbyte, mas isso aumenta a complexidade da montagem.

sexta-feira, 6 de julho de 2007

DRAM de PC como VRAM (2)

Montei o circuito para proporcionar 192Kbytes, e aparentemente está funcionando OK. A Vram detectada durante o boot é sempre 128K, mas isso, pelo que encontrei em algums posts, é coisa da BIOS, pois o padrão do MSX2 é 128K. Seguem abaixo algumas fotos:

Vista geral do circuito instalado sobre os soquetes da DRAM. Os 3 fios ligados ao VDP vão aos sinais /CAS0 /CAS1 e /CASX (pinos 59, 60 e 61 do V9938)




Detalhe da placa. Clique na imagem para ampliar.

terça-feira, 3 de julho de 2007

HB1240: HUB I2C

O HUB I2C foi batizado, seguindo a nomenclatura do Hot-Bit de HB-1240. Eu incorporei 2 leds ao projeto, e atualizei o 'lay-out':



Segue abaixo o diagrama do HUB I2C. A alimentação para os dispositivos I2C é mantida desligada enquanto o dispositivo não está sendo acessado, a fim de economizar energia e de não interferir com o funcionamento do joystick. Caso seja necessário manter algum dispositivo alimentado o tempo todo, ele pode ser conectado à porta destinada ao 'joystick'.

Cada uma das 4 portas possui 2 resistores de 'pull-up' ou 'pull-down' de forma a fornecer um sub-endereço, permitindo assim conectar mais de um dispositivo de mesmo endereço principal à uma mesma porta de joystick.



Os dispostivos I2C podem ser acionados através das ritinas básicas de acesso, publicadas em post anterior.

O projeto inteiro pode ser baixado na página de projetos do Igor

terça-feira, 26 de junho de 2007

VRAM de 192Kbytes com 2 chips de DRAM de PC comuns

Eu penso que é possível obter os 192Kbytes para a VRAM do MSX utilizando apenas 2 chips de DRAM comuns, de 1024x4 bytes através da seguinte configuração:


PINO DRAM SINAL VDP
A8 DRAM (ambas) /CAS0
A9 DRAM (ambas) /CAS1
/CAS /CAS0 and /CAS1 and /CASX


o AND dos sinais /CAS0, /CAS1 e /CASX pode ser obtido através de um 74HC11 ou de uma cascata de algumas portas de um 74HC08.


A ligação dos outros sinais fica assim:
SINAL VDP   PINO DRAM
D0..D3 D0..D3 DRAM 1
D4..D7 D0..D3 DRAM 2
A0..A7 A0..A7 (ambas)

No caso da DRAM de 16 bits, basta ligar o sinal /CASX na linha A8 ou A9, e ligar um dos sinais UCAS ou LCAS através de um AND do sinal /CASX com /CAS0 ou /CAS1.

Diagrama:


Placa:

quarta-feira, 20 de junho de 2007

HUB para dispositivos I2C

Eis uma foto do HUB para dipositivos I2C na porta de Joystick. O Layout é do Igor.

Este HUB comporta 4 dispositivos I2C e não atrapalha o uso do Joystick. Cada um dos 4 conectores DB9 utilizados para as estações, possui 2 pinos para designar o sub-endereço I2C, e as linhas SDA e SCL são comuns a todos.


DRAM de PC como VRAM

Recentemente utilizei um módulo de memória retirado de um PC como VRAM para um KIt MSX2.0 feito a partir do cartão de 80 colunas da EPCOM. O módulo de memória utlizado possui 16 bits, acessados 8 a 8, através de 2 sinais: UCAS e LCAS. Dessa maneira, podemos conectar os sinais d[0..7] aos sinais [d8..15], e controlar a seu acesso a partir dos sinais CAS0 e CAS1 do VDP.

Abaixo seguem algumas fotos do sistema modificado. Depois coloco mais detalhes (diagrama, placa, etc).

Vista Geral:


Vista da placa com a DRAM. Detalhe da ligação do sinal /CAS1:


Vista lateral:


Detalhe da ligação ao sinal /CAS1 (pino 60 do VDP 9938)

sexta-feira, 15 de junho de 2007

Mega-Flash

Após gastar algum tempo analisando os circuitos de chaveamento de sub-rom baseada em memória FLASH dos posts anteriores, fiquei pensando em fazer algo ao mesmo compatível com MEGAROM e que use poucos CHIPS. Daí nasceu a MEGA-FLASH:

O funcionamento é o seguinte:
O acesso às páginas 1 e 2 da MEGA-FLASH é exatamente igual ao acesso à MEGAROM, ou seja, Leitura em Memória, Escrita nos registros mapeadores (de acordo com o estado das linhas A13 e A14):

(A15) A14 A13 Endereço Página Registro
0 1 0 4000-5FFF 1.0 R0
0 1 1 6000-7FFF 1.5 R1
1 0 0 8000-9FFF 2.0 R2
1 0 1 A000-BFFF 2.5 R3


A escrita na FLASH se dá na página 0 (zero) onde acontece o espelhamento das sub-páginas 2.0 (0000-1FFF) e 2.5 (2000-3FFF), pois A14=0. Assim, todo o espaço de endereçamento para escrita pode ser selecionado a partir dos registros R2 e R3.

A grande vantagem disto é que usar apeanas o mesmo número de CIs necessários para se construir uma MEGA-ROM, ou seja, um decodificador e o(s) registro(s). Para uma MEGAFLASH de 512K, serão necessários apenas os seguintes chips:

1x AM29F040 - Flash 512K
1x 74LS138 - Decodificador
2x 74LS670 - Registro 4x4

Mas nada impede que se utilize RAM no lugar da FLASH, para fazer um dispositivo baseado em RAM



O 'Mapa' da MEGAFLASH é o seguinte:

Endereço Página Escrita Leitura
0000-1FFF 0.0 P2.0 valor (a leitura é feita pelo
2000-3FFF 0.5 P2.5 indefinido sinal CS12)
4000-5FFF 1.0 R0 P1.0
6000-7FFF 1.5 R1 P1.5
8000-9FFF 2.0 R2 P2.0
A000-BFFF 2.5 R3 P2.5
C000-DFFF 3.0 Sem Valor
E000-FFFF 3.5 Ação indefinido

Diagrama da Mega-Flash

quinta-feira, 14 de junho de 2007

Mapeador para Flash

Andei pensando numa SUB-ROM baseada em memória Flash, composta por um bloco fixo seguido de um bloco selecionável, ambos de 8Kb, localizados na página 2 (8000h a BFFFh). O primeiro bloco é sempre "mapeado" para o primeiro bloco físico da FLASH, e o segundo é selecionável via um registrador de 6 bits (para uma Flash de 512Kbytes).

A estrutura é a seguinte:


A programação da flash se dá através da escrita da sequência de comandos (de acordo com a flash) escritos na página selecionável. Uma escrita no bloco fixo (8000h-9FFFh) ativa o registrador de mapeamento.

Este circuito pode ser implementado com apenas 3 CIs mais a Flash (74LS138, 74LS00, 74LS373/574).


Outra possibilidade é um mapeador semel semelhante, mas chaveando blocos de 16K, sendo um bloco fixo na página 1 e um bloco variável na página 2: De igual forma, a escrita no bloco fixo aciona o registrador de mapeamento.



Esta segunda alternativa pode ser montada utilizando-se um 74LS32, um 74LS139 e um 74LS373/574.

segunda-feira, 28 de maio de 2007

Primeira versão operacional

Terminei hoje de debugar a primeira versão do 'bootloader' J2C. Havia um pequeno erro na rotina de leitura de blocos, mas este erro (basicamente de conceito) foi corrigido e o carregador está funcionando legal, carregando 32Kbytes em 14 segundos (2,28KBytes/segundo).

Para experimentar via Basic (sem ter que gravar uma ROM), basta carregar o arquivo .rom a partir do comando:
bload"SUBROM.BIN",&H3F72:DEFUSR=&HC000:a=usr(0)
Isso vai carregar um bloco 32Kbytes na memoria a partir do bootloader ou de um picodrive conectado na porta de joystick 1.

Detalhe importante é que esta versão procura pela e2prom no sub-endereço 0 (zero) da porta 1 de joystick, por isso, pra funcionar no expert (ou qualquer outro MSX que possua resistores de 'pull-up' nas linhas de 'joystick', é necessário forçar a nível baixo os pinos 1 e 2 do conector de joystick, para forçar o endereço da e2prom a zero, ou então conectar na porta 0 (zero) de um HUB para picodrives.

(ou então, carregar via o seguinte comando):
bload"SUBROM.BIN",&H3F72:DEFUSR=&HC000:
poke&HC004,&HA6:poke&HC011,&HA6:a=usr(0)

Interface Compact Flash Interna

Vasculhando os sites do ZX spectrum encontrei um site com um projeto muito interessante, chamado ZXCF. O mais importante neste projeto é a informação do que os cartões Compact Flash possuem um modo de acesso por memória (não IDE). Isso significa que com um mínimo de componentes é possível fazer uma interface para cartões Compact Flash.

No caso do MSX, é possível utilizar uma saída livre de um decodificador interno, obtendo-se assim uma interface sem utilizar componente algum, apenas o soquete do cartão.

Eis o diagrama:



A página de onde retirei estas informações tem ainda as rotinas básicas de acesso ao cartão. No caso de usar-se a saída Y7 do decodificador interno, isso equivale a utilizar o endereço 0B8h como base e os seguintes valores de portas devem ser utilizados no código do 'driver'.


DAT EQU 0B8H
PAR EQU 0B9H
SEC EQU 0BAH
STA EQU 0BBH
ZYL EQU 0BCH
ZYH EQU 0BDH
HEA EQU 0BEH
COM EQU 0BFH

quinta-feira, 17 de maio de 2007

Novos Requisitos

Dei uma revisada nos requisitos do 'bootloader' após várias considerações que estão surgindo durante o desenvolvimento do mesmo. Eis a lista atualizada.

Requisitos de Hardware:

O 'Hardware' do carregador de boot:

  • Deverá ser uma interface conectada entre o PC e o MSX;
  • Deverá permitir duas possibilidades de conexão ao PC, nas portas Serial e Paralela;
  • Deverá possuir uma opção com eeprom serial de 32Kbytes;
  • Deverá possuir uma opção com plug P2 estéreo com os sinais I2C;

Requisitos de Software:

O 'Software' do carregador de boot deverá:
  • Ser capaz procurar por um picodrive em até 4 sub-endereços I2C da porta A de joystick, totalizando assim 4 possibilidades de 'boot';
  • Executar a seguinte sequência de varredura durante o boot (PORTA.SUB_END): A.0; A;1; A.2; A.3;
  • Selecionar o primeiro dispositivo encontrado com a sequência de varredura acima;
  • Implementar o recarregamento através do comando IPL, a partir do dispositivo selecionado durante o boot, se este ainda estiver presente. Caso contrário deverá fazer uma nova varredura;
  • Identificar o conteúdo da e2prom com base no primeiro 'byte' e carregar o conteúdo da e2prom de acordo com o tipo de conteúdo, definido na tabela abaixo:

Identificador

Tipo

Ação

FEh

Binário

Carrega um arquivo .bin. Os 7 primeiros bytes têm a mesma função que no Basic Disco (endereços Inicial, Final e

FFh

Basic

Carrega programa BASIC

41h

Imagem ROM

Carrega uma ROM de 32K entre 4000h a BFFFh

4Ah

Tic-Tac

(reservado para implementação futura)

segunda-feira, 14 de maio de 2007

Testes do final de semana

Eu e o Igor testamos neste final de semana o circuito da interface SD/MMC funcionando a 14MHz com um 'clock' gerado a partir de um cristal. O Objetivo é transferir os dados em até 1,7uS após a instrução INI/OUTI, pra poder funcionar no TurboR em modo R800.

O crítico é o circuito de adaptação de lógica TTL para 3V, que até 3,5MHz funciona bem, mas com uma frequência mais alta ele simplesmente não consegue acompanhar. Vamos agora testar circuitos de adaptação baseados em um transistor na configuração Base Comum, dotado de um 'pull up' ativo.

Nas medições que fizemos descobrimos também que que o inversor a transistor demora muito tempo para desligar (sair da saturação ao corte) e o substituímos por uma porta lógica, aproveitada do próprio circuito oscilador.

quarta-feira, 2 de maio de 2007

PonyProg

O programa Ponyprog também serve para programar a E2PROM do 'bootloader'. A configuração é a seguinte:

quinta-feira, 26 de abril de 2007

Rev A do 'Bootloader'

Fiz uma revisão no circuito do BootLoader, pois a versão anterior se mantinha normalmente acionada, forçando a nível baixo as linhas SDA e SCL, requerendo assim que o ICPROG fosse executado ao menos uma vez, ou que o cabo ao PC fosse desconectado

A revisão atual corrigiu isso utilizando uma porta que estava livre no 74XX125.




E a configuração do ICPROG tem que mudar, em relação à anterior para desinverter os sinais de VCC e MCLR. As outras configurações permanecem as mesmas.



A placa também foi atualizada. Um arquivo com os arquivos em formato eagle estão neste link.

terça-feira, 24 de abril de 2007

Testes com o 'Hardware" para porta serial

Terminei o teste do Hardware do Bootloader para a porta serial. Do Lado do PC, estou usando o ICPROG. O circuito foi baseado no SI Prog, mas tive que acrescentar um 74HC125 pois no final da gravação o ICProg leva as linhas a nível baixo, em vez de deixá-las livres (em aberto).

O Igor me ajudou no 'Layout' da Placa de circuito impresso. A placa da direita é opcional, e pode ser substituída (com vantagens) por um cabo retirado de um 'joystick' de MegaDrive.

(clique na imagem para ampliar):


O diagrama final do circuito encontra-se logo abaixo (clique na imagem para ampliar):



As configurações necessárias do ICPROG para trabalhar com este circuito são:

Ajustes de Hardware: É necessário inverter os sinais Vcc e MCLR.


Nas opções, é necessário habilitar o 'driver' para NT/2000/XP, caso um destes sistemas estaja sendo utilizado.




E as opções específicas para I2C devem ser selecionadas. Note que o endereço de 'hardware' desta tela tem que ser mudado de 0 para 3 quando usado no Expert, pois este tem resistores de 'pull-up' em todos os pinos do joystick. Como o Hotbit não tem tem 'pull-up' nestas linhas, a e2prom, que é um dispositivo CMOS entende uma linha aberta como um sinal em nível. Outro caso em que é necessário mudar este endereço na faixa de 0 a 3, é quando a interface estive conectada a uma 'HUB' para picodrives.



E por último, uma opção que, quando desmarcada agiliza um pouco o processo, é a verificação logo após a escrita:



E por último, uma captura da tela após a leitura da EEPROM.

Bootloader J2C: Requisitos

Esta é a lista dos Requisitos do carregador de 'Boot' serial (bootloader):

Requisitos de Hardware:

O 'Hardware' do carregador de boot:

  • Deverá consistir de uma interface a ser instalada entre o PC e o MSX;
  • Deverá permitir duas possibilidades de conexão ao PC, nas portas Serial e Paralela;
  • Deverá possuir uma eeprom serial de 32Kbytes;

Requisitos de Software:

O 'Software' do carregador de boot:
  • Deverá ser capaz procurar por um picodrive em até 4 sub-endereços I2C de cada porta de joystick, totalizando assim 8 possibilidades de 'boot';
  • Permitir a seleção do dispositivo manualmente, através do pressionamento das teclas 0-7, durante o boot da máquina;
  • Permitir a seleção do primeiro dispositivo encontrado com a seguinte sequência de varredura, caso nenhuma tecla seja pressionada durante o boot (PORTA.SUB_END): A.0; A;1; A.2; A.3; B.0; B.1; B.2; B.3;
  • Selecionar o primeiro dispositivo encontrado com a sequência de varredura acima, caso o dispositivo selecionado manualmente não seja detectado;
  • Carregar os 32KBytes dados da memória serial nas páginas 1 e 2 da RAM.
  • Implementar o recarregamento através do comando IPL, a partir do dispositivo selecionado durante o boot, se este ainda estiver presente. Caso contrário deverá fazer uma nova varredura;

segunda-feira, 23 de abril de 2007

'Driver' J2C Básico já funciona!

O 'Driver' para dispositivos I2C conectados à porta de 'Joystick' já está funcionando.

As seguintes Funções são providas:

J2CINIT: Inicializa Porta 1 ou 2, conforme 'flag' Cy (0=Joy 1, 1=Joy2) ;
J2CLOGON: Acessa um dispositivo I2C ;
J2CP8ADR: Inicializa o registrador de endereço de 8 bits do dispositivo I2C;
J2CP16ADR: Inicializa o registrador de endereço de 16 bits do dispositivo I2C;
J2CPB: Escreve um 'byte' no endereço atual do dispositivo I2C;
J2CGBYTE: Lê um 'byte' no endereço atual do dispositivo I2C;
J2CSTOP: Gera uma condição de Parada no barramento I2C
J2CSTART: Gera uma condição de Inicio no barramento I2C
J2CPAK: Gera um ACK no barramento I2C cujo valor é igual ao da 'flag' Cy
J2CGAK: Recebe o ACK de um dispositivo I2C;
WAIT1MS: Aguarda 1 mili-segundo.

Na imagem abaixo, a captura de uma região já conhecida da E2PROM do PicoDrive.



Conexões:

Sinal I2C Pino Joystick MSX
SDA 6 (TRGA)
SCL 7 (TRGB)
VCC 5 +5Volts
GND 9 GND