Mostrando postagens com marcador Informações. Mostrar todas as postagens
Mostrando postagens com marcador Informações. Mostrar todas as postagens

terça-feira, 20 de março de 2012

CPLD Lab


O CPLD Lab é uma placa de desenvolvimento de dispositivos de lógica programável complexos   (CPLDs)   baseada   num   chip   EPM3064   da   Altera   com   64   macrocélulas   em encapsulamento PLCC 44 e que permite a utilização de até 36 pinos de I/O sendo 4 somente entradas destinadas aos sinais globais (/OE, CLOCK, /CLEAR) e mais 4 compartilhados com o conector de programação JTAG. A placa foi projetada para ser uma ferramenta de experimentação e desenvolvimento de projetos para microcomputadores de 8 bits. A placa conta com três opções para regulador de tensão de +3V3 com LEDs para monitoramento das alimentações;

Imagem da placa. A CPLD fica do lado de baixo

sábado, 3 de março de 2012

Conector de teclado do HotBit

Na documentação existente sobre o HotBit alguns detalhes sobre o teclado estavam faltando, especificamente o funcionamento da chave de desligamento do Slot e qual a função do pino POWERON

Segue abaixo uma figura com a pinagem do teclado mais completa:

segunda-feira, 20 de fevereiro de 2012

Adaptador para teclado PS/2 - Problemas, considerações e idéias .

Antes de me aventurar num projeto de um adaptador de teclado PS/2 é importante estudar bem as particularidades do hardware do MSX.

O teclado do MSX é uma matriz de 11 linhas por 8 colunas. O MSX seleciona a linha através dos 4 bits menos significativos da porta C da PPI que vão a um decodificador BCD-Decimal (74LS145). A leitura das colunas referentes à linha selecionada é feita através da porta B da PPI.

Normalmente, uma leitura do teclado tem a seguinte estrutura:
A=linha selecionada
OUT (0AAh),A
IN A,(0A9H)
Considerando que as intruções OUT/IN executam em 12 ciclos de máquina (no MSX é inserido um 'wait' de um ciclo de clock cada ciclo M1), e que as instruções são normalmente consecutivas, dá pra se notar que o tempo disponível para a leitura de um teclado é bem estrito.

INSTRUCTION   BYTES   M1         M2        M3  
OUT (n),A     2       OCF(4+1)   OD(3)     PW(4)
IN A,(n)      2       OCF(4+1)   OD(3)     PR(4)


Para ser bem preciso, o tempo disponível entre a escrita na porta 0AAh e a leitura na porta 0A9H vai desde o meio segundo pulso de clock do ciclo M3 da instrução OUT (Port Write) até o meio do quarto pulso de clock do ciclo M3 da instrução IN, onde o Z80 efetivamente lê a porta.


Na ponta do lápis temos:
- 2,5 ciclos de clock restantes do ciclo M3 da instrução Write
- 5 ciclos de clock do 'Opcode Fetch' do ciclo M1 da instrução IN
- 3 ciclos de clock da leitura do operando da instrução IN (ciclo M2)
- 3 ciclos de clock da leitura da porta no ciclo M3 (no 3 1/2 o dado já deve estar pronto para ser lido)

Isso nos dá 13,5 ciclos de clock, o que equivale a 3,77 microssegundos numa máquina rodando a 3,58MHz .

Se quisermos ser mais estritos ainda, devemos considerar que nem todo programa precisa escrever na porta C da PPI antes de ler a porta B, pois basta escrever uma vez e ler quando necessário (por exemplo jogos que usem somente as setas cursoras e a barra de espaço).

Assim, considerando somente a leitura na porta B da PPI (0A9h) temos um tempo que vai desde o meio do segundo pulso ate o final do terceiro pulso de clock do ciclo M3 da instrução IN.
Isso equivale a 2,5 ciclos de clock ou 698 nanosegundos.

Penso em duas abordagens para o problema. A primeira é utilizar um CPLD e um microcontrolador. A CPLD é configurada como uma matriz de 10 linhas com 8 flip flops e mais um shift register capaz de endereçar a entrada de cada uma dessas 10 linhas. O microcontrolador lê o teclado PS/2 e cria internamente uma matriz de 11 bytes representando o estado de cada tecla (para o MSX). De tempos em tempos o microcontrolador desloca sequencialmente para o shift register interno cada um dos 10 bytes e apos transferir cada um dos bytes ele atualiza o estado dos flip flops da linha equivalente. A solução mais simples seria encadear todas as 11 linhas e fazer um shift register de 80 bits, mas isso poderia gerar falsos eventos caso o MSX estivesse lendo uma linha do teclado na hora em que o microcontrolador estivesse atualizando o shift register. Isso ia requerer pelo menos (11x8)+8 macrocélulas de uma CPLD, ou seja 98 macrocélulas. Uma abordagem parecida seria fazer um shift register de 88 bits com um latch de saída, mas isso ia requerer pelo menos 168 macro células.
Uma segunda abordagem utiliza somente o microcontrolador. Mas dados os tempos, qual microcontrolador utilizar? Um AVR rodando a 20MHz roda uma instrução a cada 50 nanossegundos, e pode rodar 14 instruções em 700 nanossegundos. Um PIC com mesmo clock teria uma 3 instruções apenas. Um 8051 a 12MHz nem teria como responder tão rápido. Embora seja possível utilizar microcontroladores mais rápidos, não creio que essa seja uma abordagem elegante, ainda mais que o tempo entre eventos de teclado normalmente é bem longo, da ordem de dezenas de milissegundos.

Pensando novamente, este problema de velocidade para atender a uma requisição do microprocessador não é novo, e a solução também não. O Z80 já tem um recurso para tratar esse problema que é a própria linha WAIT. Essa linha é amostrada no terceiro pulso de clock do ciclo M3 das instruções de I/O. Caso essa linha esteja em nível baixo, o Z80 vai fazendo novas amostragens até que a linha volte a nível alto (contudo deve-se tomar cuidado para não deixar o Z80 muito tempo neste estado, pois durante o "wait state" as memórias dinâmicas não sofrem refresh).

Essa segunda abordagem permite o uso de praticamente qualquer microcontrolador, basta adicionar um flip flop e um decodificador para os sinais /RD, /CS e A0 da própria PPI. O microcontrolador pode trabalhar por polling ou por interrupções, reconhecendo a mudança de estado da saída do flip flop (que vai a zero no momento em que /RD=0; /CS=0; A0=1). O microcontrolador então lê o estado dos bits 0-3 da porta C da PPI, determina qual a linha que o MSX deseja ler. Então o microcontrolador coloca na saída os bits correspondentes à coluna lida e reseta o flip flop, liberando a linha Wait. Se quisermos ser preciosistas, após liberar o Z80 basta aguardar por um tempo equivalente a um ciclo e meio de clock do Z80 e então desativar a porta de saída (bits da coluna).



domingo, 22 de janeiro de 2012

TXT para Mega Assembler em Python

Tenho usado o Pasmo para compilar os programas no PC, e depois gerar o bin para copiar pro disquete e carregar no MSX real. Mas como algumas coisas não são emuladas, o melhor mesmo é poder compilar direto no MSX.
Como o Mega Assembler não trabalha com arquivos TXT mas sim com um formato próprio, estudei um pouco esse formato e fiz um script em Python para converter o arquivo em assembly no formato TXT para o formato do arquivo do Mega Assembler.

O script é bem básico, mas funcionou bem nos testes que fiz.
Algumas coisas que precisam ser observadas na hora de gerar o arquivo no PC é se lembrar das caracteristicas do Mega Assembler, como o tamanho máximos dos labels (6 bytes) e a restrição de uso de alguns caracters como o "_" (underline).

Segue abaixo o script.

# -*- coding: cp1252 -*-
#
# TXT2SIMPLE
# converte arquivos Assembly em formato texto para
# arquivo compativel com o Simple Assembly.
# Daniel Jose Viana - Janeiro de 2012
# v0.01 - versao basica 11/jan/2012
#
from struct import *
from string import *

#caminho e nome do arquivo
path='c:\\Documents and Settings\\Danjovic\\Desktop\\'
file='NunJ2C.asm'

f=open(path+file,'rb')
tamanho=0
for line in f:
lline=line.strip() #remove terminador de linha
tamanho=tamanho+len(lline)+3 #2 bytes do numero da linha mais um byte do final de linha
print "Tamanho do arquivo:",tamanho


o=open(path+file+'.as','wb')
o.write('\xFE\x01\x00'+pack('<h',tamanho)+'\xFF\xFF'),
linha=0
incremento=10
f.seek(0) # reset posicao do arquivo
for line in f:
lline=line.strip() # remove terminador de linha
linha=linha+incremento # incrementa contador
print linha,lline #
o.write(pack('<h',linha)), # escreve numero da linha
o.write (lline), # escreve linha
o.write('\x00'), # escreve terminador (zero)

o.close() # fecha arquivos
f.close()

domingo, 30 de novembro de 2008

Expansão de dispositivos

Eis o resultado de mais alguns estudos sobre a expansão de dispositivos no MSX.


O MSX tem alguns dispositivos padrão, a saber: LPT - impressora, CRT - Tela de texto, GRP - Tela gráfica, e CAS - fita cassete.

Mas além destes, outros dispotitivos podem existir, pois os dispositivos são previstos na Bios do MSX como um mecanismo padronizado de buffers para ser fazer operações de entrada/saída de dados.

Um comando típico, para "abrir" um dispositivo personalizado é:

OPEN "MEUDISP:" FOR OUTPUT AS #1,

Quando o Basic recebe um comando como o abaixo, os seguintes eventos acontecem:

- Toda vez que o MSX tenta abrir um dispositivo que não seja padrão, ele chama uma rotina de procura de dispositivos, que analisa a tabela SLTATR à procura de entradas cujo sétimo bit (máscara 0x40) sejam diferentes de zero (Durante o 'boot' a Bios varreu todos os slots e setou estes bits toda vez que encontrou as posições 06 e 07 sejam diferentes de zero)

- Ao encontrar uma ROM que contém uma entrada de dispositivo válida, a BIOS chama esta ROM com o registro A=FF e o nome do dispositivo (no caso MEUDISP) vai estar no buffer PROCNM, terminado em zero.

- O código escrito dentro da ROM do dispositivo tem que, em primeiro lugar, ver se o valor do registrador A é FF. Se for, deve analisar o nome em PROCNAM (da mesma maneira que se faz para criar comandos chamáveis via CALL). Caso o nome não bata, deve-se retornar a flag de Carry 'setada', e a Bios vai procurar pelo 'MEUDISP' em outro slot.

- Mas vamos supor que a ROM tenha o dispositivo MEUDISP e ele seja o terceiro dispositivo (pois uma ROM pode ter até 4 dispositivos expandidos). Daí a rotina deve retornar em A o número 2 e a flag Carry deve estar em zero 'resetada'

- Em seguida a Bios converte a posição do slot em que o dispositivo foi encontrado mais o número do dispositivo em um "código interno" de dispositivo. Este código é colocado no quinto byte do FCB atual. É utilizando este código que a Bios sabe como chamar o dispositivo associado ao FCB.

- Em seguida, a BIOS chama o dispositivo novamente, mas desta vez o registrador A contém o número do dispositivo chamado, o par HL contém o endereço do FCB, o registrador D contém o "código interno" do dispositivo, e o registrador E contém o modo de abertura. O modo pode ser:

"FOR INPUT" (01H)
"FOR OUTPUT" (02H)
"FOR APPEND" (08H)
"RANDOM MODE" (04H), se nenhum modo for especificado


Não vou entrar em detalhes de como abrir o dispositivo, mesmo porque não experimentei ainda o suficiente. Mas uma das coisas necessárias, é mudar o valor do primeiro byte do FCB para o modo correspondente.


Já com o dispositivo aberto, a BIOS passa dados para o dispositivo (que nada mais é do que o manipulador de um buffer) utilizando o registrador C para o dado, o registrador A para a operação desejada e o dispositivo é identificado pela variável DEVICE.

por exemplo, ao se digitar

PRINT #1, "A"

Temos 3 chamadas para o dispositivo. Em todas elas o registrador A tem o valor 6, que significa saída sequencial, e a variável DEVICE guarda o número do dispositivo identificado na hora do "open". Na primeira chamada, o valor de C era 65, que corresponde ao A maiúsculo. Na segunda e terceira, C assumiu, respectivamente, o valor 13 e 10, que correspondem a um CR-LF.

Caso houvéssemos colocado um ponto e vírgula ao final da expressão, apenas o A seria enviado e apenas uma chamada seria feita.







domingo, 28 de outubro de 2007

Paddle do NES no Arkanoid do MSX? (update)

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 (novo link) , 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:





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

sexta-feira, 30 de março de 2007

BUSDIR

Em conversa com o Igor, discutindo a utilização do sinal BUSDIR, chegamos às seguintes conclusões:
  • O MSX não utiliza a linha BUSDIR para fazer DMA (ao contrário do que eu imaginava);
  • O sinal BUSDIR serve para mudar a direção dos 'buffers' de saída colocados no barramento do MSX em três duas situações:
  1. Leitura em memória num SLOT via sinais /RD e /SLTSL;
  2. Leitura de uma porta de I/O via instruçaõ IN/INI/INIR (ou INP do Basic);
  3. Colocação de um vetor de interrupção no barramento, em modo de interrupção 2 do Z80, pois nesta situação o sinal /RD fica em nível alto;
Estas informações podem ser encontradas na página 36 do "MSX Technical Data Book".

Só que em nossa discussão, encontramos um problema no circuito de controlde de busdir da página 35 do 'Data Book'.



O problema desse circuito é que quando DOIS ou mais de um expansores com 'buffer' interno forem ligados ao mesmo tempo, todos os buffers serão acionados, causando assim um conflito que pode inclusive queimar os 'buffers' (isso sem contar que a porta NOR teria que ser 'open collector'). Isso ocorre porque a linha /BUSDIR está ligada diretamente ao controle de habilitação do 'buffer'

Tudo bem que o esquema no 'Data Book' seja mais um 'guideline' do que um esquema propriamente dito, mas uma possível soluão para este problema pode ser "comparando" o comando para habilitar o 'buffer' com o sinal da linha /BUSDIR. Se o sinal /BUSDIR_INTERNO baixar, então o 'buffer tristate' força a linha /BUSDIR a baixar, e na saída da porta OR, o sinal vai zer 'ZERO', acionando assim o 'buffer' do expansor.

Por outro lado, se nenhuma operação deste expansor estiver ativando a linha /BUSDIR_INTERNO, e porventura o outro expansor ativar a linha /BUSDIR, então o sinal na saída da port OR vai ser 'UM', o que não habilita o buffer de saída.




Modificando um pouco o circuito do 'Data Book', e adaptando para usar um 'buffer' bidirecional 'tristate' (LS245), em vez de dois unidirecionais, temos:



Note que foi necessário envolver o sinal de /WR para escolher a direção do 'buffer', e para habililá-lo numa operação de escrita.

Simplificando a lógica, usando apenas um CHIP para fazer as funções das portas AND e OR, e substituindo o 'buffer' tristate por um MOSFET, temos:

quarta-feira, 20 de dezembro de 2006

Direto do Túnel do Tempo...

Reativei hoje, após 12 anos sem uso, meu velho gravador HB2400. Para minha felicidade ele está funcionando em perfeita ordem e para minha surpresa, a maioria das coisas que tenho em fita ainda funciona!!

Eis algumas pérolas, que não constam em nenhum catálogo de programas para MSX:

Seeräuber, ou "pirata" em alemão (ladrão dos mares). Desenvolvido em assembler no Simple. Nunca chegou a ser terminado, pois a faculdade e o namoro consumiram todo o meu tempo, naquele início de década de 90. As cores dos meus programas eram meio esdrúxulas, pois eu tinha uma TV preto e branco, e escolhia as cores simplesmente pelo contraste.
"RightSoft" era minha marca (nunca) registrada, e o nome foi escolhido por ser o único nome bacana que dava pra escrever com o restinho que me sobrara de uma cartela de "letraset" (decalques transferíveis)


Outra tela do programa. Os comandos eram navegáveis via setas de cursor. A seleção era feita por ENTER, ou ESPAÇO, e o retorno ao menu superior era através de "escape". A tela era baseada em scrren1, com caracteres redefinidos, tanto para o logotipo quanto para as letras em fundo invertido. O programa era feito para fita cassete, pois eu nao possuía "disk drive".

Este outro programa era da autoria do irmão de um amigo, com quem eu trocava um monte de programas em fita cassete. Também foi com esses amigos que eu consegui meu "simple" modificado, que tem função "Fsave/Fload", capaz de carregar/ler blocos a 2000bauds.



Outra tela do Pirata em ação, carregando um programa:



Aqui, mais um programa meu, de identificação do cabeçalho dos programas em fita. Ele identificou outro programa, que tinha apenas 30 bytes, chamado LETUDO!!



E para finalizar (por hoje) o último programa que eu havia feito para o MSX, capaz de decodificar código morse a velocidades variáveis, portado de um "paper" para o processador 8080. Havia também um "hardware" externo, que filtrava o sinal captado por um rádio e acionava a entrada de joystick, que era entendida pelo programa.



Quero ver se encontro agora os programas COPY3, cujo menu era inspirado no "PCTOOLS", e o COPY4 (na realdiade, 4.1 ), em Screen2, com janelas semelhantes ao TurboPascal, e navegação por setas de cursor, entre outros avanços introduzidos pela biblioteca de janelas que eu desenvolvi há muito tempo atrás. Esta biblioteca utilizava uma "recursividade lateral", pois recebia um "string" de tamanho variável, que poderia ter como parâmetros ponteiros para outras "strings", que quando selecionadas chamavam a mesma rotina recursivamente. Era legal!!

terça-feira, 28 de novembro de 2006

Touchpads: Primeiras investigações

Controladores Touchpad para MSX

Muito pouco se sabe sobre o funcionamento dos "touchpads" do MSX, desde a pinagem deste dispositivo ao seu protocolo de comunicação. As observações abaixo são o resultado das análises da rotina GTPAD da BIOS.

O Touchpad do MSX é composto de 2 conversores A/D, que transferem seus bits ser

Pinagem do Touchpad:


Pino Direção Nome Função
1 S SENSE Indica quando a caneta do Touchpad toca sua superfície (0=Tocando)
2 S EOC Indica fim da conversão (1=Conversão terminada)
3 S DATA Dados enviados serialmente (MSB primeiro) pelo conversor A/D
4 S BTN Botão da caneta do touchpad (0=pressionado)
5 - Vcc Alimentação +5Volts
6 E CS Inicia uma conversão A/D (0=iniciar conversão)
7 E X/Y Seleciona conversor A/D (X=0, Y=1)
8 E SCK Clock para transferência de dados
9 - GND Negativo da alimentação.


O Pino CS (Trigger A) é levado a "0" (zero) para iniciar uma conversão. O conversor A/D é selecionado pelo pino X/Y (Trigger B; 0=X, 1=Y). O MSX então aguarda até que o conversor A/D termine de realizar sua conversão, liberando a linha EOC (DOWN), fazendo com que esta seja igual a "1" (um). Em seguida o MSX libera a linha CS, que novamente assume o valor "1" (um).

A partir deste momento começa a transferência do valor do conversor A/D. O pino SCK (Pulse) é levado a "1" (um) e em seguida o sinal presente na linha DATA (LEFT) é lido e colocado no registrador L. O pino SCK (Pulse) é então levado de volta a "0" (zero). Desta forma, 8 bis são lidos e armazenados em L. O pino SENSE (UP) é amostrado a cada bit lido, porém somente o estado do pino durante o bit menos significativo é levado em consideração. Caso seja "0" (zero), o MSX assume que a caneta manteve-se em contato com o "touchpad" durante o tempo da conversão, e que portanto, a coordenada lida é válida. Caso contrário, a rotina termina retornando o valor do pino SENSE.

As coordenadas X/Y são amostradas duas vezes seguidas. Caso a diferença de valor de cada eixo seja maior do que 5 (cinco) nestas amostragens consecutivas, ou seja, caso duas leituras consecutivas resultem em posições muito diferentes, todo o processo se repete. Caso contrário, as coordenadas X e Y são armazenasdas em PADX (FC9D) e PADY (FC9C), e a rotina termina, retornando o valor do pino SENSE.