L'ASCII R800 era un microprocessore a 16 bit prodotto da ASCII Corporation (Giappone) nel 1990 che fu usato come CPU nell'home computer MSX Turbo-R. Fu progettato con 2 obiettivi: realizzare la CPU più performante possibile mantenendo però la retrocompatibilità con l'hardware ed il software dei precedenti computer MSX basati sullo Zilog Z80. Per raggiungere quest'ultimo obiettivo l'R800 utilizzava un superinsieme del set di istruzioni dello Z80: in aggiunta a tutti gli opcode di questo, erano aggiunte 2 istruzioni per la moltiplicazione, MULUB (8 bit) e MULUW (16 bit), e tutte le istruzioni non documentate dello Z80 erano state rese ufficiali, compresi gli opcode che gestivano i registri IX e IY come contenitori ad 8 bit (IXh, IXl, IYh, IYl).
Siccome l'R800 non era basato direttamente sullo Z80 ma derivava dalla famiglia dello Z800, non aveva alcune delle caratteristiche non documentate dello Z80, come, ad esempio, i flag nei bit 3 e 5 del registro F che non assumevano lo stesso valore di quelli dello Z80 (facendo così fallire i test di compatibilità ZEXALL); inoltre, l'opcode non documentato SLL era sostituito da un altro opcode non documentato chiamato TST.
Sul lato costruttivo l'R800 era radicalmente differente: l'ALU ad 8 bit dello Z80 era stata sostituita da una nuova unità aritmetica a 16 bit. Come risultato di tale cambiamento gli opcode relativi alle operazioni matematiche, quali ADD HL, BC, che nella vecchia unità richiedevano 11 cicli per la loro esecuzione, potevano essere eseguiti in 1 solo ciclo (in determinate condizioni). Il clock era di 7,16 MHz, il doppio rispetto a quello dello Z80 dei precedenti MSX (3,57 MHz). Il bus dati rimaneva ad 8 bit per motivi di retrocompatibilità con il vecchio hardware.
Fu modificato anche il modo in cui la CPU gestiva gli opcode. Nello Z80 erano richiesti 4 cicli per eseguire una semplice istruzione quale OR A, e nell'architettura MSX era presente anche uno stato d'attesa aggiuntivo. Per capire questa evoluzione del meccanismo di gestione degli opcode dell'R800 rispetto allo Z80 bisogna rivedere come tale gestione operava nell'architettura MSX:
- Z80, ciclo 1: la CPU impostava gli 8 bit più alti dell'indirizzo (la parte H dei registri)
- Z80, ciclo 2: la CPU impostava gli 8 bit più bassi dell'indirizzo (la parte L dei registri)
- Z80, ciclo 3: attesa
- Z80, ciclo 4: refresh, parte 1
- Z80, ciclo 5: refresh, parte 2
Dato che molte implementazioni dell'MSX usavano la RAM a blocchi di 256×256 byte, erano richiesti 2 cicli per impostare l'indirizzo da gestire. L'R800 eliminava questo difetto ricordando l'ultimo stato noto degli 8 bit più alti: se l'istruzione successiva operava nello stesso blocco di 256 byte gli 8 bit più alti non venivano impostati, saltando un ciclo. C'era però da risolvere un altro problema: il ciclo di refresh, sullo Z80, distruggeva le informazioni della parte alta per cui doveva essere studiato un metodo per aggirare questa cosa.
La soluzione utilizzata nell'R800 fu quella di fare il refresh di un intero blocco di RAM piuttosto che una singola linea di RAM per ogni istruzione eseguita. Ogni 30 μs la CPU viene fermata per 4 µs durante i quali viene eseguito il refresh di un blocco di memoria. Siccome non c'è refresh tra l'esecuzione di 2 istruzioni e lo stato d'attesa è rimosso per velocizzare le risposte dei chip RAM, le istruzioni semplici possono essere eseguite impiegando solo 1 ciclo: nell'esempio precedente, questo periodo sarebbe stato sullo Z80 di 2 cicli. Il ciclo 1 diventa opzionale ed è eseguito solo quando il programma esce dai confini di un blocco da 256 byte di memoria.
La soluzione descritta si applicava solo alla memoria RAM usata sull'MSX TurboR: l'hardware esterno, connesso tramite le porte per le cartucce, utilizzava timing simili a quelli dello Z80. Neanche la ROM interna del TurboR era tanto veloce da poter reggere questo schema di funzionamento per cui i chip addizionali del TurboR venivano replicati su RAM così da rendere l'accesso ai dati più veloci.
