Emulation/problemkaputt.github.io
1
0
Fork 0
mirror of https://github.com/problemkaputt/problemkaputt.github.io.git synced 2024-05-13 02:04:53 -04:00
Code Issues Packages Projects Releases Wiki Activity
problemkaputt.github.io/x51specs.htm
Matthew Berry 67090afb26 upload of entire dump from archive.org
2021-01-14 23:48:20 -08:00

4483 lines
221 KiB
HTML
Raw Permalink Blame History

<HTML><HEAD>
<TITLE>Specifications</TITLE>
<META NAME="GENERATOR" CONTENT="nocash help engine">
</HEAD><BODY bgcolor="#ffffff" text="#000000" link="#0033cc" vlink="#0033cc" alink="#0033cc">
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="contents"></A>&nbsp;
Contents
</FONT></TD></TR></TABLE><BR>
<A HREF="#nox51featuresabout">No$x51 Features/About</A><BR>
<A HREF="#memoryandregistermap">Memory and Register Map</A><BR>
<A HREF="#externalioports">External I/O Ports</A><BR>
<A HREF="#timers">Timers</A><BR>
<A HREF="#serialuartrs232port">Serial UART/RS232 Port</A><BR>
<A HREF="#seriali2cbusport">Serial I2C-Bus Port</A><BR>
<A HREF="#analogdigitalconverter">Analog/Digital Converter</A><BR>
<A HREF="#pulsewidthmodulatedoutputs">Pulse Width Modulated Outputs</A><BR>
<A HREF="#interrupts">Interrupts</A><BR>
<A HREF="#syschipcontrolregisters">SYS Chip Control Registers</A><BR>
<A HREF="#cpumicroprocessor">CPU Microprocessor</A><BR>
<A HREF="#flasheeprom">Flash EEPROM</A><BR>
<A HREF="#cirbasicconnectioncircuits">CIR Basic Connection Circuits</A><BR>
<A HREF="#auxexternalhardware">AUX External Hardware</A><BR>
<BR>
<B>AMT630A</B><BR>
<A HREF="#amt630amemorymap">AMT630A - Memory Map</A><BR>
<A HREF="#amt630asfrssystemtimersportsetc">AMT630A - SFRs - System Timers/Ports/etc</A><BR>
<A HREF="#amt630afbxxhosdregistersonscreendisplay">AMT630A - FBxxh - OSD Registers (On-Screen Display)</A><BR>
<A HREF="#amt630afcxxhlcdregistersmostly50hz60hzratio">AMT630A - FCxxh - LCD Registers (mostly 50Hz/60Hz/Ratio)</A><BR>
<A HREF="#amt630afdxxhmiscregisterspwmadcpllpinspiflash">AMT630A - FDxxh - Misc Registers (PWM,ADC,PLL,PIN,SPI-FLASH)</A><BR>
<A HREF="#amt630afexxhavregisterscompositevideoinput">AMT630A - FExxh - AV Registers (Composite Video Input)</A><BR>
<A HREF="#amt630affxxhlcdregistersgammabrightnessetcandir">AMT630A - FFxxh - LCD Registers (gamma/brightness/etc and IR)</A><BR>
<A HREF="#amt630acomponentlistspinouts">AMT630A - Component Lists &amp; Pinouts</A><BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="nox51featuresabout"></A>&nbsp;
No$x51 Features/About
</FONT></TD></TR></TABLE><BR>
<B>Heya</B><BR>
If anybody uses this program, or otherwise treats it to be useful, please let
me know - I'd be happy about some feedback :-)<BR>
If using the program for commerical purposes please contact me (see also
chapter about External Hardware for possible support/improvements).<BR>
The program is free for non-commerical use (anyways, small donations would be
highly welcome).<BR>
<BR>
Copyright 2001,2002 by Martin Korth<BR>
http://problemkaputt.de/x51.htm - no$x51 homepage<BR>
http://problemkaputt.de/email.htm - email address (spam shielded)<BR>
http://problemkaputt.de/address.htm - my mailing address<BR>
<BR>
<B>Features</B><BR>
This program is written in tight 80X86 assembler code, and covers the basic
nocash emulation/debugging features:<BR>
<BR>
* 8051/8031/P8xCE558 Emulator<BR>
* Debugger/Disassembler with Symbolic Information (Labels)<BR>
* Assembler (Single-Line Input, and Source Code Assembler)<BR>
* (Dis-)Assembler supports native 8051 and friendly Z80/80X86 syntax<BR>
* Warning Messages on bad I/O and stack overflows, etc.<BR>
* FEEPROM Upload Function (Serial Boot)<BR>
* Emulates External LCD 16x2 Charcters<BR>
* Emulates External Numeric Keypad<BR>
* DOS version for PC/XT 8086 with 80x25 MDA and up<BR>
* Windows version for 80386SX / Windows 95 and worse<BR>
<BR>
The current version emulates the CPU including internal SFR registers such like
timers and prescalers - it still lacks emulation of (or redirection to)
external hardware.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="memoryandregistermap"></A>&nbsp;
Memory and Register Map
</FONT></TD></TR></TABLE><BR>
<B>Internal RAM (MOV,ADD,PUSH,etc.)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
00-07 R0..R7 ;registers R0..R7 (bank 0, default)
;&lt;--- initially SP=07 (stack incrementing at 08 and up).
08-0F R0..R7 ;registers R0..R7 (bank 1) or normal RAM
10-17 R0..R7 ;registers R0..R7 (bank 2) or normal RAM
18-1F R0..R7 ;registers R0..R7 (bank 3) or normal RAM
20-2F ;bit-addressable RAM (16x8 bits) or normal RAM
30-7F ;normal RAM
80-FF ;558 only - extra internal RAM - addressable by @Ri &amp; SP only
</TD></TR></TABLE>
<BR>
<B>External RAM (MOVX only)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0000-00FF AUX RAM
0100-01FF AUX RAM
0200-02FF AUX RAM
...
8000..
</TD></TR></TABLE>
<BR>
<B>Code ROM/EEPROM (MOVC only)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0000-7FFF ;internal EEPROM (P89CE558 only)
8000-FBFF ;external memory / user space
FC00-FFFF ;internal BIOS ROM (all 558 only ?)
</TD></TR></TABLE>
Internal EEPROM and BIOS can be disabled, allowing to use the whole 64Kbytes
address space for external memory. Data can be written into the FEEPROM from
inside of the user program by using BIOS functions.<BR>
Address 0000h is the reset vector (should contain a single JMP instruction),
addresses 0003h, 000Bh, 0013h, 001Bh, ..., 0073h are interrupt vectors.<BR>
<BR>
<B>SFR (Special Function Registers)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
80 P0 A0 P2 C0* P4 E0 A/ACC
81 SP A1 - C1 - E1 -
82 DPL A2 - C2 - E2 -
83 DPH A3 - C3 - E3 -
84 - A4 - C4 - E4 -
85 - A5 - C5 - E5 -
86* ADRSL0 A6* ADRSL2 C6* ADRSL4 E6* ADRSL6
87 PCON A7 - C7* P5 E7* ADPSS
88 TCON A8 IEN0/IEC C8* TM2IR E8* IEN1
89 TMOD A9* CML0 C9* CMH0 E9 -
8A TL0 AA* CML1 CA* CMH1 EA* TM2CON
8B TL1 AB* CML2 CB* CMH2 EB* CTCON
8C TH0 AC* CTL0 CC* CTH0 EC* TML2
8D TH1 AD* CTL1 CD* CTH1 ED* TMH2
8E - AE* CTL2 CE* CTH2 EE* STE
8F - AF* CTL3 CF* CTH3 EF* RTE
90 P1 B0 P3 D0 PSW F0 B
91 - B1 - D1 - F1 -
92 - B2 - D2 - F2 -
93 - B3 - D3 - F3 -
94 - B4 - D4 - F4 -
95 - B5 - D5 - F5 -
96* ADRSL1 B6* ADRSL3 D6* ADRSL5 F6* ADRSL7
97 - B7 - D7* ADCON F7* ADRSH
98 S0CON/SCON B8 IP0/IPC D8* S1CON F8* IP1
99 S0BUF/SBUF B9 - D9* S1STA F9* PLLCON
9A - BA - DA* S1DAT FA* XRAMP
9B - BB - DB* S1ADR FB**FMCON
9C - BC - DC - FC* PWM0
9D - BD - DD - FD* PWM1
9E - BE - DE - FE* PWMP
9F - BF - DF - FF* T3
</TD></TR></TABLE>
Notes:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
* P8xCE558 only (not 8031/8051)
** P89CE558 only (not 8031/8051/P80CE558/P83CE558)
IEN0,S0CON,S0BUF,IP0 are new 558-expressions for original IEC,SCON,SBUF,IPC.
Accumulator may be called A or ACC. In source, ACC forces a "direct" operand.
Registers at SFR addresses n*8 are bit-addressable (eg. P0,TCON,P1,etc).
DPL,DPH are lower/upper bits of DPTR.
</TD></TR></TABLE>
<BR>
<B>Bit-Addressable SFR Registers</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Register Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0
F8 IP1 PT2 PCM2 PCM1 PCM0 PCT3 PCT2 PCT1 PCT0
F0 B B.7 B.6 B.5 B.4 B.3 B.2 B.1 B.0
E8 IEN1 ET2 ECM2 ECM1 ECM0 ECT3 ECT2 ECT1 ECT0
E0 A A.7 A.6 A.5 A.4 A.3 A.2 A.1 A.0
D8 S1CON CR2 ENS1 STA STO SI AA CR1 CR0
D0 PSW CY AC F0 RS1 RS0 OV F1 P
C8 TM2IR T2OV CMI2 CMI1 CMI0 CTI3 CTI2 CTI1 CTI0
C0 P4 P4.7 P4.6 P4.5 P4.4 P4.3 P4.2 P4.1 P4.0
B8 IP0 -- PAD PS1 PS0 PT1 PX1 PT0 PX0
B0 P3 P3.7 P3.6 P3.5 P3.4 P3.3 P3.2 P3.1 P3.0
A8 IEN0 EA EAD ES1 ES0 ET1 EX1 ET0 EX0
A0 P2 P2.7 P2.6 P2.5 P2.4 P2.3 P2.2 P2.1 P2.0
98 S0CON SM0 SM1 SM2 REN TB8 RB8 TI RI
90 P1 P1.7 P1.6 P1.5 P1.4 P1.3 P1.2 P1.1 P1.0
88 TCON TF1 TR1 ZF0 TR0 IE1 IT1 IE0 IT0
80 P0 P0.7 P0.6 P0.5 P0.4 P0.3 P0.2 P0.1 P0.0
</TD></TR></TABLE>
Note that normal Set/Reset operations may be performed for non-bit-addressable
registers by "ANL/ORL &lt;direct&gt;,#Imm" either.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="externalioports"></A>&nbsp;
External I/O Ports
</FONT></TD></TR></TABLE><BR>
SFRs : P0, P1, P2, P3, P4, P5<BR>
<BR>
<B>80h - P0 - 8bit Open Drain Bidirectional I/O Port (Read/Write/Bit-adressable)</B><BR>
<B>90h - P1 - 8bit Quasi-Bidirectional I/O Port (Read/Write/Bit-adressable)</B><BR>
<B>A0h - P2 - 8bit Quasi-Bidirectional I/O Port</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
with internal pull-ups (Read/Write/Bit-adressable)
</TD></TR></TABLE>
<B>B0h - P3 - 8bit Quasi-Bidirectional I/O Port (Read/Write/Bit-adressable)</B><BR>
<B>C0h - P4 - 8bit Quasi-Bidirectional I/O Port (Read/Write/Bit-adressable)</B><BR>
<B>C7h - P5 - 8bit Input Port (Read Only)</B><BR>
<BR>
<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="timers"></A>&nbsp;
Timers
</FONT></TD></TR></TABLE><BR>
<A HREF="#timer0and1">Timer 0 and 1</A><BR>
<A HREF="#timer2">Timer 2</A><BR>
<A HREF="#timer3watchdog">Timer 3 (Watchdog)</A><BR>
<BR>
Additionally, a seconds timer is available (P8xCE558 with 32kHz oscillator
only), for details see PLLCON description in SYS chapter.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="timer0and1"></A>&nbsp;
Timer 0 and 1
</FONT></TD></TR></TABLE><BR>
SFRs : TCON, TMOD, TL0, TH0, TL1, TH1 (and P3.4-5)<BR>
<BR>
<B>8Ah/8Ch - TL0/TH0 - T0 - Timer 0 Counter (Read/Write)</B><BR>
<B>8Bh/8Dh - TL1/TH1 - T1 - Timer 1 Counter (Read/Write)</B><BR>
16bit timer/counter registers for each timer 0 and 1. May be split into 8bit
timer/counters with associated reload value or prescaler, depending on timer
mode.<BR>
When reading a 16bit value, either temporarily stop the timer, or first read
MSB then LSB then re-read MSB - and retry if it has changed in the meantime.<BR>
<BR>
<B>88h - TCON - Timer/Counter Control Register (Read/Write, Bit-Addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0,2 IT0,IT1 Interrupt 0,1 Type Control (0=Low, 1=Falling edge)
1,3 IE0,IE1 Interrupt 0,1 Edge Flag (0=None, 1=IRQ)
4,6 TR0,TR1 Timer 0,1 Run Control (0=Stop, 1=Run)
5,7 TF0,TF1 Timer 0,1 Overflow Flag (0=None, 1=IRQ)
</TD></TR></TABLE>
The four IRQ-bits are automatically set/cleared by hardware when
sensing/excuting an interrupt. The other four bits are controlled by software
only.<BR>
<BR>
<B>89h - TMOD - Timer/Counter Control Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-1 M0-1 Timer 0 Mode (0-3, see below)
2 C/T Timer 0 Selector (0=Timer, 1=Counter)
3 GATE Timer 0 Gating Control (0=Normal, 1=Stop Timer while /INT0=LOW)
4-5 M0-1 Timer 1 Mode (0-2, see below, 3=Timer stopped)
6 C/T Timer 1 Selector (0=Timer, 1=Counter)
7 GATE Timer 1 Gating Control (0=Normal, 1=Stop Timer while /INT1=LOW)
</TD></TR></TABLE>
Timer 0 Modes (for Timer 1 Modes use TH1/TL1 respectively)<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 8bit Timer/Counter TH0, each with 5bit prescaler TL0 (8048 Mode).
1 16bit Timer/Counter, TH0 and TL0 are cascaded.
2 8bit auto-reload Timer/Counter, TL0=timer/counter, TH0=reload value.
3 8bit TL0 Timer/Counter 0, plus 8bit TH0 Timer 1 (Timer 0 only).
</TD></TR></TABLE>
Timer/Counter Selector<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Timer - Incremented at fCLK/12
Counter - Incremented on Falling Edge of external input
</TD></TR></TABLE>
The counter 0/1 input pins T0/T1 (P3.4/P3.5) may be pulsed at 0Hz through max
fClk/24.<BR>
<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="timer2"></A>&nbsp;
Timer 2
</FONT></TD></TR></TABLE><BR>
SFRs : TM2IR, TM2CON, TML2, TMH2 (and P1.4-5) - (Raw Timer)<BR>
SFRs : CTCON, CTL0-3, CTH0-3 (and P1.0-3) - (Timer/Capture/Ext.Interrupt)<BR>
SFRs : STE, RTE, CML0-2, CMH0-2 (and P4.0-7) - (Timer/Compare)<BR>
<BR>
<B>ECh/EDh - TML2/TMH2 - T2 - 16bit Timer 2 Counter (Read Only)</B><BR>
16bit readonly (!) timer/counter register. The register is not loadable,
however, when enabled in T2ER (TM2CON.5), the timer may be reset by 0-to-1
transition of RT2 (P1.5); which'd be normally generated external hardware (but
could be generated by software output to P1.5 either - provided that external
hardware is not dragging that pin to low).<BR>
<BR>
When reading the 16bit value, either temporarily stop the timer, or first read
MSB then LSB then re-read MSB - and retry if it has changed in the meantime.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<B>EAh - TM2CON - Timer 2 Control Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-1 T2MS0-1 Timer 2 Mode Select (0=Halted, 1=Timer, 2=Reserved, 3=Counter)
2-3 T2P0-1 Timer 2 Prescaler (0-3=Divide clock source by 1,2,4,8)
4 T2BO Timer 2 Byte Overflow Interrupt Flag (0=None, 1=IRQ)
5 T2ER Timer 2 External Reset Enable (0=Disable, 1=Enable)
(When enabled, T2 becomes reset on Raising Edge of RT2/P1.5)
6 T2IS0 Timer 2 Byte Overflow Interrupt Select
7 T2IS1 Timer 2 16-bit Overflow Interrupt Select
</TD></TR></TABLE>
Both Byte and 16bit Overflows are sharing the same interrupt vector, either one
or both may be enabled, 16bit Overflow flag located in TM2IR.<BR>
<BR>
<B>C8h - TM2IR - Timer 2 Interrupt Flag Register (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-3 CTI0-3 CT0-3 (Capture) Interrupt Flags (0=None, 1=IRQ)
4-6 CMI0-2 CM0-2 (Compare) Interrupt Flags (0=None, 1=IRQ)
7 T2OV Timer 2 16-bit Overflow Flag (0=None, 1=IRQ)
</TD></TR></TABLE>
Note: Additionally, a 8-bit Overflow Flag is located in TM2CON.4 (T2BO).<BR>
All Timer 2 interrupt flags must be reset by software.<BR>
<BR>
<B>E8h - CTCON - Capture Control Regtister (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0,2,4,6 CTP0-3 Capture Register 0-3 triggered by falling edge on CT0I-CT3I
1,3,5,7 CTN0-3 Capture Register 0-3 triggered by raising edge on CT0I-CT3I
</TD></TR></TABLE>
When triggered, current Timer 2 value is loaded into selected capture register
(see CT0-3), and a "capture" interrupt is requested (see TM2IR and IEN1). May
be triggered on both raising and/or falling edge, when deselcting both edges,
the interrupt input is disabled. When ignoring the captured value, the
'capture' interrupts 0-3 may be treated as 'normal' external interrupts 2-5.<BR>
<BR>
<B>ACh/CCh - CTL0/CTH0 - CT0 - 16bit Capture Register 0 (Read Only)</B><BR>
<B>ADh/CDh - CTL1/CTH1 - CT1 - 16bit Capture Register 1 (Read Only)</B><BR>
<B>AEh/CEh - CTL2/CTH2 - CT2 - 16bit Capture Register 2 (Read Only)</B><BR>
<B>AFh/CFh - CTL3/CTH3 - CT3 - 16bit Capture Register 3 (Read Only)</B><BR>
The 16bit Timer 2 value can be automatically loaded (captured) into any of the
CM0-3 registers upon either raising and/or falling edge of any of the CT0I-CT3I
Pins, see CTCON Register.<BR>
<BR>
<B>EEh - STE - Compare Set Enable Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-5 SP40-45 New state for P4.0-5 upon CM0=T2 (0=Don't change, 1=Set)
6-7 TG46-47 New state for P4.6-7 upon toggle (0=Set, 1=Reset)
</TD></TR></TABLE>
Port 4 can be read and written by software without affecting the toggle, set,
and reset signals.<BR>
<BR>
<B>EFh - RTE - Compare Reset/Toggle Enable Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-5 RP40-45 New state for P4.0-5 upon CM1=T2 (0=Don't change, 1=Reset)
6-7 TP46-47 New state for P4.6-7 upon CM2=T2 (0=Don't change, 1=Toggle)
</TD></TR></TABLE>
<BR>
<B>A9h/C9h - CML0/CMH0 - CM0 - Compare Register 0 (Read/Write) - Set</B><BR>
<B>AAh/CAh - CML1/CMH1 - CM1 - Compare Register 1 (Read/Write) - Reset</B><BR>
<B>ABh/CBh - CML2/CMH2 - CM2 - Compare Register 2 (Read/Write) - Toggle</B><BR>
The 16bit values in each CM0-2 are continously compared with the T2 counter
value. Matches for CM0-2 may set/reset/toggle outputs of P4.0-7 Pins:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Register Action Pins See also
CM0 Set P4.0-5 STE Register
CM1 Reset P4.0-5 RTE Register
CM2 Toggle P4.6,7 STE and RTE Registers
</TD></TR></TABLE>
If CM0 and CM1 match at the same time, CM1 will have priority (Reset).<BR>
Additionally, when a match occurs, a "compare" interrupt is requested (see
TM2IR and IEN1).<BR>
<BR>
<B>Alternative Functions of Port 1 and Port 4 with Timer 2</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Port/Pin Alternative Function
P1.0-3 CT0I-CT3I External Interrupt Inputs 2-5 (with Timer 2 Capture 0-3)
P1.4 T2 T2 event input (counter mode), rising edge triggered
P1.5 RT2 T2 reset input, rising edge triggered
P1.6-7 - No special function
P4.0-5 CMSR0-5 Compare and Set/Reset outputs on T2 match
P4.6-7 CMT0-1 Compare and Toggle outputs on T2 match
</TD></TR></TABLE>
Alias name for CT0I-CT3I would be INT2-INT5 (used when ignoring the capture
function that is associated to the interrupt input).<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="timer3watchdog"></A>&nbsp;
Timer 3 (Watchdog)
</FONT></TD></TR></TABLE><BR>
SFRs : T3 (and PCON.4)<BR>
<BR>
<B>FFh - T3 - Watchdog Timer (Read/Write)</B><BR>
If the /EW Pin is LOW, this 8bit timer register is incremented once every
12*2048 oscillator periods (ie. each 2048 cycles). In case that the timer
overflows, the CPU will be reset, and a reset signal will be output at RSTOUT,
the software must thus permanently reload the T3 timer in order to keep itself
operating.<BR>
Even though this automatic reset function is theoretically a rather dangerous
feature, it becomes useful especially if the microprocessor is not guarded by
human operators, as it allows the system to recover itself even if the software
has locked up either because of a programming bug or hardware malfunction.<BR>
First write "1" to the WLE Bit (PCON.4), this enables writing to T3.<BR>
Then write the reload value to T3, this will reset both the WLE Bit and the
2048-steps-prescaler, and (if WLE was set, and if /EW was LOW), the reload
value will be applied in T3, and the software may continue for the specified
amount of time.<BR>
The Watchdog timeout ranges from 1.5ms (reload FFh) through 0.375s (reload 00h)
when using a system clock of 16MHz - or longer, when using a slower system
clock.<BR>
<BR>
<B>The /EW Pin</B><BR>
When the /EW Pin is HIGH, the Watchdog function will be activated, and the
software MUST reload T3 repeatedly, both the Power Down Mode and the Serial
FEEPROM Programming Function cannot be used.<BR>
When the /EW Pin is LOW, the Watchdog is disabled, writing to T3 will be
rejected, the T3 Timer will be halted, and the Power Down Mode will be
available.<BR>
The state of the /EW Pin can be read-out at LOADEN (PCON.1) ???<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="serialuartrs232port"></A>&nbsp;
Serial UART/RS232 Port
</FONT></TD></TR></TABLE><BR>
SFRs : S0CON,S0BUF alias SCON,SBUF (and PCON.7 and Timer)<BR>
<BR>
Full duplex serial I/O port - it can transmit and receive simultaneosly.<BR>
Received data may be read out by software even when the hardware already
receives a second byte, however, one byte will be lost if the software failed
to read-out 1st data by the time when reception of the 2nd data completes.<BR>
<BR>
<B>98h - S0CON/SCON - UART Serial Control Register (Read/Write, Bit-addressable)</B><BR>
The IRQ flags are set by hardware, and must be cleared by software. In mode 0,
set at the end of the 8th bit. In other modes, set at the beginning (TI), or in
the middle (RI), of the stopbit.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 RI Receive Interrupt Flag (0=None, 1=IRQ)
1 TI Transmit Interrupt Flag (0=None, 1=IRQ)
2 RB8 9th received bit (Mode0=Not used, Mode1=Stopbit, Mode2-3=Bit8)
3 TB8 9th transmit bit (Bit8, set by software, used in Mode2-3 only)
4 REN Serial Reception Enable (0=Disable, 1=Enable)
5 SM2 Receive Interrupt Mode (0=Normal, 1=See below)
6 SM1 SM1=LSB (!) of Serial Mode, see below
7 SM0 SM0=MSB (!) of Serial Mode, see below
</TD></TR></TABLE>
Serial Modes, and meaning of SM2=1:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Mode Expl. Baudrate ;When SM2=1, set RI only if...
0/00h 8-bit Shift register fCLK/12 ;-[Reserved, SM2 should be 0]
1/40h 8-bit UART variable ;-only if received Stopbit valid
2/80h 9-bit UART fCLK/64 or /32 ;-only if received 9th bit RB8=1
3/C0h 9-bit UART variable ;-only if received 9th bit RB8=1
</TD></TR></TABLE>
Mode 2-3 with SM2=1 are somewhat intended for Multiprocessor systems.<BR>
<BR>
<B>99h - S0BUF/SBUF - UART Serial Transmit Data (Write Only)</B><BR>
<B>99h - S0BUF/SBUF - UART Serial Receive Data (Read Only)</B><BR>
Two separate 8bit registers, one for receive, one for transmit, that are
sharing the same SFR address. In all modes, data is transferred LSB first
(shifted to the right), and in modes 2-3 a 9th data bit is transmit/received
from the S0CON register. This 9th bit may be used as Parity bit - which must be
manually produced or verified by software (if so, note that the CPU provides a
Parity bit in the PSW register).<BR>
Transmit is initiated by writing to S0BUF.<BR>
<BR>
<B>UART Transfer Start</B><BR>
Reception is initiated in Mode 0 when R1=0 and REN=1.<BR>
Reception is initiated in Mode 1-3 by incoming Startbit when REN=1.<BR>
Transmit is initiated in all modes by writing to S0BUF.<BR>
<BR>
<B>UART Transfer Notes</B><BR>
Mode 0 uses RXD as data line (for both transmit and receive), and outputs the
shift clock to TXD, writing to S0CON should be avoided during Mode 0
transmission to avoid spikes on RXD/TXD.<BR>
Mode 1-3 are using RXD as Receive data line, and TXD as transmit data line. A
transfer consists of one startbit (0), eight or nine data bits (LSB first), and
one stopbit (1).<BR>
<BR>
UART - See also IEN0 and Timer.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
mov tmod,#00100001b ;\ init timer-1 for auto-reload at 32x2400Hz
mov th1,#0f4h ; &gt; ("for used as gated 16-bit counter" ???)
setb tr1 ;/
</TD></TR></TABLE>
In modes 1-3, the Baudrate may be doubled by setting SMOD in PCON.7.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="seriali2cbusport"></A>&nbsp;
Serial I2C-Bus Port
</FONT></TD></TR></TABLE><BR>
SFRs : S1CON, S1STA, S1DAT, S1ADR<BR>
<BR>
<B>D8h - S1CON - I2C-bus Control Register (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-1 CR0-1 Clock Rate LSBs (MSB see below), depending on System Clock:
Clock 0 1 2 3 4 5 6 7 CR0-2 value
__Divider_60____1600__40____30____240___3200__160___120___osc.periods___
12MHz 200 7.5 300 400 50 3.75 75 100 kHz (kbit/sec)
16MHz 266.7 10 400 - 66.7 5 100 - kHz (kbit/sec)
Values higher than 100kHz for "fast-mode" I2C-bus applications only,
not compatible with older I2C-bus systems. CR0-2 used in master mode
only - slave mode automatically synchronizes to any rate up to 400kHz.
2 AA Assert Acknowledge flag (0=None, 1=Return Acknowledge)
When enabled, acknowledge is returned when:
- Own slave address or General call address is received.
- Data byte is received as master receiver or selected slave receiver.
3 SI Serial Interrupt flag (0=None, 1=IRQ)
While SI is set, SCL remains LOW and the transfer is suspended.
SI must be reset by software. IRQs are generated when:
- A START condition is generated in master mode.
- Own slave address or general call addr has been received during AA=1.
- Data byte has been received or transmitted in master mode
(even if arbitration is lost).
- Data byte has been received or transmitted as selected slave.
- STOP or START received as selected slave receiver/transmitter.
4 STO STOP Flag (0=Nope, 1=Stop/Recover)
In Master mode, issues a STOP condition to the bus. In slave mode,
recovers from error (without issuing STOP to bus). This flag is
cleared by hardware when sensing a STOP on the bus, or when ENS1=0.
5 STA START Flag (0=Nope, 1=Generate start condition, see below)
In Slave mode, start condition is generated once that the bus
becomes free. In Master mode, condition is repeatedly generated.
6 ENS1 Serial I/O Enable (0=Disable,Reset,SDA=SCL=high-Z, 1=Enable)
7 CR2 Clock Rate MSB, see CR0-1 description above
</TD></TR></TABLE>
<BR>
<B>D9h - S1STA - I2C-bus Serial Status Register (Read Only)</B><BR>
The lower 3bits of this register are guaranteed to be always zero, this is
explicitely intended for using the S1STA value as jump vector offset in
increments of eight.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-2 0 All Zeros
3-7 SC0-4 Status Code (with above zero-bits, 00-F8)
</TD></TR></TABLE>
S1STA Codes for MST/TRX Mode:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
08h A START condition has been transmitted
10h A repeated START condition has been transmitted
18h SLA and W have been transmitted, ACK has been received
20h SLA and W have been transmitted, /ACK received
28h DATA and S1DAT have been transmitted, ACK received
30h DATA and S1DAT have been transmitted, /ACK received
38h Arbitration lost in SLA, R/W or DATA
</TD></TR></TABLE>
S1STA Codes for MST/REC Mode:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
38h Arbitration lost while returning /ACK
40h SLA and R have been transmitted, ACK received
48h SLA and R have been transmitted, /ACK received
50h DATA has been received, ACK returned
58h DATA has been received, /ACK returned
</TD></TR></TABLE>
S1STA Codes for SLV/REC Mode:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60h Own SLA and W have been received, ACK returned
68h Arbitration lost in SLA, R/W as MST. Own SLA and W have been
received, /ACK returned
70h General CALL has been received, ACK returned
78h Arbitration lost in SLA, R/W as MST. General CALL has been received
80h Previously addressed with own SLA. DATA byte received, ACK returned
88h Previously addressed with own SLA. DATA byte received, /ACK returned
90h Previously addressed with general call. DATA byte has been received,
ACK has been returned
99h Previously addressed with general call. DATA byte has been received,
/ACK has been returned
A0h A STOP condition or repeated START condition has been received while
still addressed as SLV/REC or SLV/TRX
</TD></TR></TABLE>
S1STA Codes for SLV/TRX Mode:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
A8h Own SLA and R have been received, ACK returned
B0h Arbitration lost in SLA, R/W as MST. Own SLA and R have been
received, /ACK returned
B8h DATA byte has been transmitted, ACK returned
C0h DATA byte has been transmitted, /ACK returned
C8h Last DATA byte has been transmitted (AA=logic 0), ACK received
</TD></TR></TABLE>
S1STA Miscellaneous Codes:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
00h Bus error during MST mode or selected SLV mode, due to an erroneous
START or STOP condition
F8h No relevant information available, SI not set
</TD></TR></TABLE>
Abbreviations used:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
MST Master R Read bit
SLV Slave W Write bit
TRX Transmitter ACK Acknowledgement (acknowledge bit = 0)
REC Receiver /ACK Not acknowledgement (acknowledge bit = 1)
SLA 7-bit slave address DATA 8-data byte to or from I2C-bus
</TD></TR></TABLE>
<BR>
<B>DAh - S1DAT - I2C-bus Data Shift Register (Read/Write)</B><BR>
Contains 8bit serial data, Bit 7 is received or transmitted first, ie. data is
shifted left.<BR>
<BR>
<B>DBh - S1ADR - I2C-bus Address Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 GC General Call address state (0=Not Recognized, 1=Recognized)
1-7 SLA0-6 Own Slave Address (00-7F)
</TD></TR></TABLE>
The Slave Address determines the address to which the controller will respond
when programmed as slave receiver/transmitter.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="analogdigitalconverter"></A>&nbsp;
Analog/Digital Converter
</FONT></TD></TR></TABLE><BR>
SFRs : ADCON, ADPSS, ADRSL0-7, ADRSH (and P5)<BR>
<BR>
<B>D7h - ADCON - ADC Control Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 ADSFE Start A/D conversion on falling edge at ADEXS-Pin (0=No, 1=Yes)
1 ADSRE Start A/D conversion on raising edge at ADEXS-Pin (0=No, 1=Yes)
2 ADCSA Scan Selected analog inputs (0=One-Time, 1=Continous)
3 ADSST Start and Status (0=Inactive/Stop, 1=Active/Start)
4 ADINT ADC Interrupt on completion of selected inputs (0=None, 1=IRQ)
5 ADPOS Reserved for future use (Always write "0")
6-7 ADPR0-1 Prescaler Control (0-3=Divide by 2,4,6,8)
</TD></TR></TABLE>
Scan is started when ADSST changes from 0 to 1 (either by software, or by ADEXS
input), the bit is automatically cleared upon completion of a One-Time scan, in
Continous mode it remains set. Clearing by software ADSST will abort the
current scan.<BR>
Interrupts are requested upon completion of all selected inputs (ie. once in
One-Time mode, and repeatedly in Continous mode). ADINT must be cleared by
software, but it cannot be set by software.<BR>
<BR>
<B>E7h - ADPSS - A/D Input Port Scan-Select Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-7 ADPSS0-7 Select analog input 0-7 at P5.0-7 (0=Skip, 1=Select)
</TD></TR></TABLE>
All selected analog inputs are scanned during the auto-scan loop (starting with
lowest selected bit position) (each one once in One-Time mode, or repeatedly in
Continous mode), A/D conversion cannot be started when all ADPSS bits are zero.
When writing to ADPSS while scan is in progress, changes aren't recognized
until the current auto-scan loop ends, changes are then applied for the next
loop.<BR>
<BR>
<B>86h - ADRSL0 - A/D Result Register 0 (Read Only)</B><BR>
<B>96h - ADRSL1 - A/D Result Register 1 (Read Only)</B><BR>
<B>A6h - ADRSL2 - A/D Result Register 2 (Read Only)</B><BR>
<B>B6h - ADRSL3 - A/D Result Register 3 (Read Only)</B><BR>
<B>C6h - ADRSL4 - A/D Result Register 4 (Read Only)</B><BR>
<B>D6h - ADRSL5 - A/D Result Register 5 (Read Only)</B><BR>
<B>E6h - ADRSL6 - A/D Result Register 6 (Read Only)</B><BR>
<B>F6h - ADRSL7 - A/D Result Register 7 (Read Only)</B><BR>
Lower 8bits of conversion results for each of the eight analog inputs.<BR>
Reading from ADRSL0-7 automatically latches the upper 2bits of the conversion
result (which is sized 10bits in total) into the ADRSH register.<BR>
The latched value remains unchanged even if an active scan-loop samples new
data, thus, when reading ADRSLn and then ADRSH, there is no danger that ADRSH
conatins 'newer' data than ADRSLn.<BR>
<BR>
<B>F7h - ADRSH - A/D Result Register High (Read Only)</B><BR>
Contains the upper 2bits from the most recently read ADRSL0-7 conversion result
(see above). Bit2-7 of ADRSH are always zero.<BR>
<BR>
<B>Alternate use for P5 Digital Input</B><BR>
<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="pulsewidthmodulatedoutputs"></A>&nbsp;
Pulse Width Modulated Outputs
</FONT></TD></TR></TABLE><BR>
SFRs : PWM0, PWM1, PWMP<BR>
<BR>
<B>FCh - PWM0 - Pulse Width Register for /PWM0 (Read/Write)</B><BR>
<B>FDh - PWM1 - Pulse Width Register for /PWM1 (Read/Write)</B><BR>
These registers specify the LOW:HIGH ration for the /PWM0 and /PWM1 output
pins, the /PWMn ration is "LOW=PWMn : HIGH=255-PWMn"<BR>
The PWMn values are compared to a 255-step counter (step-rate as defined by
PWMP Prescaler, see below) and LOW is output if the counter is less or equal
than PWMn. Writes to PWMn are immediately compared and /PWNn outputs are
updated (without having to wait for the completion of the current counter
period).<BR>
<BR>
<B>FEh - PWMP - Pulse Width Prescaler Frequency Control (Read/Write)</B><BR>
Specifies the step-rate (in relation to the system clock), which is shared for
both PWM0 and PWM1. The step rate is:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
fSTEP = fCLK / 2 / (PWMP+1)
</TD></TR></TABLE>
As each LOW:HIGH period consist off 255 steps, the repetition frequency is:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
fPWM = fCLK / 510 / (PWMP+1)
</TD></TR></TABLE>
Ie. the required PWMP value for specific frequency would be calculated as:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
PWMP = fCLK / 510 / fPWM - 1
</TD></TR></TABLE>
With 16MHz system clock, fPWM may range from 123Hz (FFh) to 31kHz (00h).<BR>
<BR>
<B>How to Turn off Pulse output</B><BR>
Setting PWMn to 00h or FFh will result in zero LOW- or HIGH-time, and in
result, the /PWMn output will be constant HIGH (00h) or LOW (FFh).<BR>
By this method, /PWM0 and/or /PWM1 can be used as normal ON/OFF outputs.<BR>
<BR>
<B>Pulse Wave Example</B><BR>
Assuming the following settings:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
fCLK = 16MHz ;System clock
PWMP = 30 ;fPWM = 16MHz/510/31 = 1012Hz
PWM0 = 64 ;ratio = 64:191 = 40h:BFh
PWM1 = 128 ;ratio = 128:127 = 80h:7Fh
</TD></TR></TABLE>
Would result in:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Repitition Rate: &lt;------&gt;&lt;------&gt;&lt;------&gt; each LOW:HIGH=998us (1012Hz)
Output at /PWM0: __------__------__------ each LOW=248us : HIGH=740us
Output at /PWM1: ____----____----____---- each LOW=496us : HIGH=492us
</TD></TR></TABLE>
The PWM outputs may be used to drive DC motors (at variable speed), or as dual
DAC outputs (when using a high frequency, smoothed-down pulses will effectively
appear like analogue levels).<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="interrupts"></A>&nbsp;
Interrupts
</FONT></TD></TR></TABLE><BR>
SFRs : IEN0, IEN1, IP0, IP1 (and IPLAFF)<BR>
<BR>
IRQs<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
TCON.1 IEN0.0 EX0 External Interrupt 0
TCON.5 IEN0.1 ET0 Timer 0
TCON.3+PLLCON.5 IEN0.2 EX1 External Interrupt 1, or Seconds Interrupt
TCON.7 IEN0.3 ET1 Timer 1
S0CON.0+1 IEN0.4 ES0 SIO0 (UART)
S1CON.3 IEN0.5 ES1 SIO1 (I2C)
ADCON.4 IEN0.6 EAD ADC
- IEN0.7 EA Global Enable (0=Disable all Interrupts)
TM2IR.0-3 IEN1.0-3 ECT0-3 T2 Capture 0-3
TM2IR.4-6 IEN1.4-6 ECM0-2 T2 Compare 0-2
TM2IR.7,TM2CON.4 IEN1.7 ET2 T2 Overflow 16bit or Byte
</TD></TR></TABLE>
<BR>
<BR>
<B>Interrupt Vector Addresses</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Address Prio Name Expl.
0003h 1 X0 External Interrupt 0
000Bh 4 T0 Timer 0 Overflow
0013h 7 X1/SEC External Interrupt 1 or Seconds Interrupt
001Bh 10 T1 Timer 1 Overflow
0023h 13 S0 SIO0 (UART/RS232) Send or Receive
002Bh 2 S1 SIO1 (I2C)
0033h 5 CT0 External Interrupt 2 with Timer 2 Capture 0
003Bh 8 CT1 External Interrupt 3 with Timer 2 Capture 1
0043h 11 CT2 External Interrupt 4 with Timer 2 Capture 2
004Bh 14 CT3 External Interrupt 5 with Timer 2 Capture 3
0053h 3 ADC ADC Completion
005Bh 6 CM0 Timer 2 Compare 0
0063h 9 CM1 Timer 2 Compare 1
006Bh 12 CM2 Timer 2 Compare 2
0073h 15 T2 Timer 2 Overflow
</TD></TR></TABLE>
Interrupt Priority 1=Highest, 15=Lowest.<BR>
Address 0000h is the Reset vector, which should have max. priority.<BR>
<BR>
<BR>
<B>A8h - IEN0/IEC - Interrupt Enable Register 0 (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl. (0=Disable, 1=Enable)
0 EX0 External Interrupt 0
1 ET0 Timer 0
2 EX1 External Interrupt 1, or Seconds Interrupt
3 ET1 Timer 1
4 ES0 SIO0 (UART)
5 ES1 SIO1 (I2C)
6 EAD ADC
7 EA Global Enable (0=Disable all Interrupts)
</TD></TR></TABLE>
<BR>
<B>E8h - IEN1 - Interrupt Enable Register 1 (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl. (0=Disable, 1=Enable)
0-3 ECT0-3 T2 Capture 0-3
4-6 ECM0-2 T2 Compare 0-2
7 ET2 T2 Overflow
</TD></TR></TABLE>
<BR>
<BR>
<B>B8h - IP0/IPC - Interrupt Priority Register 0 (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl. (0=Low, 1=High) Normal
0 PX0 External Interrupt 0 1
1 PT0 Timer 0 4
2 PX1 External Interrupt 1 7
or Seconds Interrupt 7
3 PT1 Timer 1 10
4 PS0 SIO0 (UART) 13
5 PS1 SIO1 (I2C) 2
6 PAD ADC 3
7 - Reserved for future use -
</TD></TR></TABLE>
<BR>
<B>F8h - IP1 - Interrupt Priority Register 1 (Read/Write, Bit-addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl. (0=Low, 1=High) Normal
0-3 PCT0-3 T2 Capture 0-3 5,8,11,14
4-6 PCM0-2 T2 Compare 0-2 6,9,12
7 PT2 T2 Overflow 15
</TD></TR></TABLE>
<BR>
<B>'IPLAFF' - Interrupt Priority Level Active Flipflops (Internal, non-SFR)</B><BR>
This is an internal 2bit register, it is not part of the SFR area. The P8xCE558
data sheet didn't described this register very well, the names IPLAFF, IPLAL,
IPLAH, and most of the general description below are raw guesswork and might be
(in-)correct (???)<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 'IPLAL' Low Priority Interrupt Active (1=Disables all low-prio IRQs)
1 'IPLAH' High Priority Interrupt Active (1=Disables all IRQs)
</TD></TR></TABLE>
When an interrupt of low or high priority is executed, the respective flipflop
(IPLAL or IPLAH) becomes set - this disables all other interrupts of same or
lower priority. When the interrupt handler returns (by RETI instruction), the
previous state is restored by clearing IPLAH (if it was set), or (otherwise) by
clearing IPLAL.<BR>
<BR>
<BR>
<B>IRQ Flags</B><BR>
The interrupt request flags are located in the separate Timer, Serial, A/D
Converter, etc. control registers. Whereas external interrupt 0-1 are
controlled by bits in Timer 0-1 control register, and external interrupt 2-5 by
Timer 2 control registers. For Seconds interrupt see PLLCON in SYS Chapter.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="syschipcontrolregisters"></A>&nbsp;
SYS Chip Control Registers
</FONT></TD></TR></TABLE><BR>
SFRs : PCON, PLLCON, XRAMP, FMCON<BR>
<BR>
<BR>
<B>87h - PCON - Power Control Register (Read/Write)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 IDL Idle Mode (0=Normal, 1=Enter Idle Mode)
1 PD Power-Down (only if /EW=HIGH) (0=Normal, 1=Enter Power Down Mode)
2-3 GF0-1 General Purpose Flags (Allowed to be used by software)
4-6 - Unused (except on special revisions, see below)
7 SMOD Double Baudrate Timer Divider in UART mode 1-3 (0=Div 32, 1=Div 16)
P8xCE558:
4 WLE Watchdog Load Enable (0=Lock, 1=Enable Write to Timer 3)
5 RFI Reduced Radio Frequency Interference (1=Suppress unused ALE pulses)
6 ARD AUX-RAM Disable (0=Enable AUX-RAM, 1=Enable External memory)
80C32/52 and up:
4 POF Power Off Flag (uh, is that a status bit, indicating coldboot?)
5-6 - Unused
</TD></TR></TABLE>
For P8xCE558 in power reduction modes, the following is stopped (-), or kept
operating (+), any interrupts caused by the active (+) components will
terminate idle/powerdown mode.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Mode CPU PWM ADC T0 T1 T2 T3 UART I2C INT0 INT1 SECINT
Idle Mode - - - + + - + + + + + +
Power Down - - - - - - N/A - - + + (RUN32)
</TD></TR></TABLE>
When stopped (-), the CPU is halted, PWM is reset (output HIGH), ADC aborts
current loop, timer 2 is stopped and reset (external interrupts 2-5 are
disabled).<BR>
<BR>
<B>F9h - PLLCON - PLL Control Register (Read/Write)</B><BR>
All bits in this register working with XTAL3,4 Oscillator Circuit only, that
is, when operating the chip by 32kHz crystal (SELXTAL1=GND) only.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-4 FSEL.0-4 System Clock Frequency Selection (default=0Dh/11.01MHz)
5 SECINT Seconds Interrupt Flag (Automatically set once per second)
6 ENSECI Seconds Interrupt Enable (1=Enable; INT1 must be enabled also)
7 RUN32 32kHz oscillator during Power Down (0=Halted, 1=Kept Running)
</TD></TR></TABLE>
The SECINT flag can be cleared only by writing "0" to SECINT, also, the flag<BR>
may be set manually by writing "1".<BR>
Possible System Clock Selections (all capable of generating standard RS232
baudrates of 1200, 2400, 4800, 9600, 19200 Bauds with UART and Timer 1):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0Bh=15.73MHz 0Dh=11.01MHz 0Fh=7.68MHz 11h=5.51MHz 13h=3.93MHz
0Ch=12.58MHz 0Eh=9.44MHz 10h=6.29MHz 12h=4.72MHz 0h-0Ah,14h-1Fh=Reserved
</TD></TR></TABLE>
Always recurse the following steps when changing the System Clock Frequency:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
From HIGH to LOW frequencies:
First change FSEL.4-2, then FSEL.0-1 (and then better wait 1ms ?).
From LOW to HIGH frequencies:
First change FSEL.0-1, then wait 1ms, then change FSEL.2-4.
</TD></TR></TABLE>
In detail, FSEL.0-1 are selecting the internal fCCO frequency of 32, 38, 44, or
50 MHz, changing FSEL.0-1 may lock the CPU for up to 10ms, and timing critical
operations should not be executed within the following 1ms stabilization phase.
FSEL.2-4 are dividing the above fCCO frequency into the actual system clock
frequency, changing FSEL.2-4 recovers within 1us.<BR>
<BR>
<B>FAh - XRAMP - AUX-RAM Page Register (Read/Write)</B><BR>
Specifies address bits 8-9 for 8bit "MOVX @Ri" instructions for internal
AUX-RAM (size 300h bytes). XRAMP is used only when ARD (AUX-RAM Disable,
PCON.6) is cleared, otherwise, when ARD is set, a raw 8bit address is output to
external memory.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-1 XRAMP0-1 AUX-RAM Page Selection (0-2, 3=Reserved)
2-7 - Not used / Reserved (always write "0" to these bits)
</TD></TR></TABLE>
Note: The 16bit "MOVX @DPTR" instructions are not affected by XRAMP.<BR>
When ARD=0, DPTR=0..2FFh addresses AUX-RAM, and 300h..FFFFh addresses external
memory. When ARD=1, all DPTR=0..FFFFh will access external memory.<BR>
<BR>
<BR>
<BR>
<BR>
<B>FBh - FMCON - FEEPROM Control Register (Read/Write) - P89CE558 Only</B><BR>
This register does not directly control FEEPROM programming, instead, it is
basically to be used as a 'key' which allows to read/write/erase FEEPROM memory
by using the BIOS-functions in BOOT ROM, see FEEPROM chapter for details.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0-3 FCB0-3 Function Code
4 - Reserved, always write "0"
5 HV High Voltage Indication - Read Only
(Set while high voltage for write/erase operation is present)
6-7 UBS0-1 User/Boot Memory Selection
</TD></TR></TABLE>
User/Boot Memory Selection<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 User memory mapped from 0 to 64K
1 User memory mapped from 0 to 63K, Boot ROM from 63K to 64K
2 Reserved/Internal
3 Reserved/Internal
(User memory may be internal and/or external memory)
</TD></TR></TABLE>
Function Codes<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
00h Value after Reset
05h Byte Write or Byte Read/Verify
0Ch Page Erase (32 bytes boundaries)
03h Block Erase (256 bytes boundaries)
0Ah Full Erase (32 Kbytes)
</TD></TR></TABLE>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpumicroprocessor"></A>&nbsp;
CPU Microprocessor
</FONT></TD></TR></TABLE><BR>
SFRs : A/ACC, B, DPTR (DPH:DPL), SP, PSW -- RAM : R0-R7 (BANK 0-3) -- PC<BR>
<BR>
<B>General</B><BR>
<A HREF="#cpuregistersandflags">CPU Registers and Flags</A><BR>
<BR>
<B>Instruction Set</B><BR>
<A HREF="#cpuarithmeticoperations">CPU Arithmetic Operations</A><BR>
<A HREF="#cpulogicaloperations">CPU Logical Operations</A><BR>
<A HREF="#cpudatatransfer">CPU Data Transfer</A><BR>
<A HREF="#cpuprogrambranching">CPU Program Branching</A><BR>
<BR>
<B>Notes</B><BR>
<A HREF="#cpunotes">CPU Notes</A><BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpuregistersandflags"></A>&nbsp;
CPU Registers and Flags
</FONT></TD></TR></TABLE><BR>
SFRs : A/ACC, B, DPTR (DPH:DPL), SP, PSW -- RAM : R0-R7 (BANK 0-3) -- PC<BR>
<BR>
<B>E0h - A/ACC - Accumulator (Read/Write, Bit-Addressable)</B><BR>
General purpose register, used as accumulator for various maths instructions.<BR>
<BR>
<B>F0h - B - The B Register (Read/Write, Bit-Addressable)</B><BR>
Even though "B" is a pretty nice short name, use of this register will not
actually result in 'short' code - the register is NOT used as implied operand
by any opcodes (except MUL/DIV), thus using R0-R7 instead of B will often
result in smaller (and sometimes faster) program code. However, possible
advantages are that the register is bit-addressable, and that it is not
disturbed by register-bank switching.<BR>
<BR>
<B>00h-07h - R0-R7 - Registers R0-R7 Bank 0 (Read/Write) (default)</B><BR>
<B>08h-0Fh - R0-R7 - Registers R0-R7 Bank 1 (Read/Write)</B><BR>
<B>10h-17h - R0-R7 - Registers R0-R7 Bank 2 (Read/Write)</B><BR>
<B>18h-1Fh - R0-R7 - Registers R0-R7 Bank 3 (Read/Write)</B><BR>
R0-R7 are eight general purpose registers, R0-R1 can be also used for
addressing RAM and XRAM. The registers are usually mapped to the first bytes of
RAM, so those RAM addresses are somewhat reserved for those registers.<BR>
A rather uncommon feature is allowing to map R0-R7 to four different "banks"
(via bits in PSW register). The confusing part is that the bank switching will
affect only opcodes with implied R0-R7 operands; for example, there is no "PUSH
R0" opcode, but one could "PUSH [00h]" instead, however, that method would
always push R0.bank0, regardless of the currently selected bank).<BR>
<BR>
<B>82h/83h - DPL/DPH - DPTR - Data Pointer (Read/Write)</B><BR>
Intended for 16bit memory addressing, DPTR can be used as implied operand by a
handful of opcodes, additionally, lower and upper 8bits can be separately
accessed by DPL and DPH direct operands.<BR>
<BR>
<B>81h - SP - Stack Pointer (Read/Write)</B><BR>
8bit stack pointer into internal RAM - chips with 256 bytes internal RAM (eg.
P8xCE558) may use the whole 8bit range, chips with 128 bytes (eg. 8051) may use
only 7bit range.<BR>
The stack is INCREMENTED when writing data to it (unlike as in most other
CPUs). PUSH/POP store/load 8bit data, CALL/RET (and INT/RETI) store/load 16bit
data (LSB at smaller address). Before writing data, SP is incremented once, ie.
initialize as "MOV SP,#stackbase-1".<BR>
Keep in mind that RAM 00h-1Fh is used for registers R0-R7 in banks 0-3, the
default/reset value (SP=07h, eg. 08h and up) conflicts with register banks 1-3.<BR>
<BR>
<B>N/A - PC - Program Counter</B><BR>
16bit Instruction pointer, incremted each time when reading an opcode or
parameter byte from program code. Any addressing relative to PC (eg. SJMP,
ACALL, CJNE, JZ, @A+PC, etc.) are originated from the end of the current opcode
(=beginning of next opcode), the pushed return address from CALLs points to the
next opcode as well.<BR>
Unlike all other registers, PC is NOT stored in the SFR-area.<BR>
<BR>
<B>D0h - PSW - Program Status Word (Flags) (Read/Write, Bit-Addressable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Bit Name Expl.
0 P Parity of Accumulator (0=Even, 1=Odd) - Read Only
1 F1 Reserved in 8031/51 models
2 OV Overflow Flag (0=No Overflow, 1=Overflow)
3-4 RS0-1 Register Bank Select (Bank 0-3, for registers R0-R7)
5 F0 User Flag 0 (May be used for whatever purpose)
6 AC Auxiliary Carry Flag (For "DA A" opcode)
7 CY Carry Flag (0=No Carry, 1=Carry)
</TD></TR></TABLE>
<BR>
<B>Instructions that affect flag settings</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Instruction CY OV AC Instruction CY OV AC Instruction CY OV AC
ADD X X X CJNE X - - ANL C,bit X - -
ADDC X X X RRC X - - ANL C,/bit X - -
SUBB X X X RLC X - - ORL C,bit X - -
MUL 0 X - SETB C 1 - - ORL C,/bit X - -
DIV 0 X - CLR C 0 - - MOV C,bit X - -
DA X - - CPL C X - -
</TD></TR></TABLE>
<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpuarithmeticoperations"></A>&nbsp;
CPU Arithmetic Operations
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
<B> Mnemonic Nocash Bytes/Cycles Description</B>
ADD A,Rn ADD A,Rn 1/1 Add register to A
ADD A,direct ADD A,[nn] 2/1 Add direct byte to A
ADD A,@Ri ADD A,[Ri] 1/1 Add indirect RAM to A
ADD A,#data ADD A,nn 2/1 Add immediate to A
ADDC A,Rn ADC A,Rn 1/1 Add register to A with Carry
ADDC A,direct ADC A,[nn] 2/1 Add direct byte to A with Carry
ADDC A,@Ri ADC A,[Ri] 1/1 Add indirect RAM to A with Carry
ADDC A,#data ADC A,nn 2/1 Add immediate to A with Carry
SUBB A,Rn SBC A,Rn 1/1 Subtract register from A with borrow
SUBB A,direct SBC A,[nn] 2/1 Subtract direct byte from A with borrow
SUBB A,@Ri SBC A,[Ri] 1/1 Subtract indirect RAM from A with borrow
SUBB A,#data SBC A,nn 2/1 Subtract immediate from A with borrow
INC A INC A 1/1 Increment A
INC Rn INC Rn 1/1 Increment register
INC direct INC [nn] 2/1 Increment direct byte
INC @Ri INC [Ri] 1/1 Increment indirect RAM
INC DPTR INC DPTR 1/1 Increment data pointer (16 bit value)
DEC A DEC A 1/1 Decrement A
DEC Rn DEC Rn 2/1 Decrement register
DEC direct DEC [nn] 1/1 Decrement direct byte
DEC @Ri DEC [Ri] 1/2 Decrement indirect RAM
MUL AB MUL A,B 1/4 Multiply A &amp; B (BA = A * B)
DIV AB DIV A,B 1/4 Divide A by B (A=A/B, B=A MOD B)
DA A DAA A 1/1 Decimal Adjust (after 'BCD+BCD'operation)
</TD></TR></TABLE>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpulogicaloperations"></A>&nbsp;
CPU Logical Operations
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
<B> Mnemonic Nocash Bytes/Cycles Description</B>
ANL A,Rn AND A,Rn 1/1 AND register to A
ANL A,direct AND A,[nn] 2/1 AND direct byte to A
ANL A,@Ri AND A,[Ri] 1/1 AND indirect RAM to A
ANL A,#data AND A,nn 2/1 AND immediate to A
ANL direct,A AND [nn],A 2/1 AND A to direct byte
ANL direct,#data AND [nn],nn 3/2 AND immediate to direct byte
ORL A,Rn OR A,Rn 1/1 OR register to A
ORL A,direct OR A,[nn] 2/1 OR direct byte to A
ORL A,@Ri OR A,[Ri] 1/1 OR indirect RAM to A
ORL A,#data OR A,nn 2/1 OR immediate to A
ORL direct,A OR [nn],A 2/1 OR A to direct byte
ORL direct,#data OR [nn],nn 3/2 OR immediate to direct byte
XRL A,Rn XOR A,Rn 1/1 Exclusive-OR register to A
XRL A,direct XOR A,[nn] 2/1 Exclusive-OR direct byte to A
XRL A,@Ri XOR A,[Ri] 1/1 Exclusive-OR indirect RAM to A
XRL A,#data XOR A,nn 2/1 Exclusive-OR immediate to A
XRL direct,A XOR [nn],A 2/1 Exclusive-OR A to direct byte
XRL direct,#data XOR [nn],nn 3/2 Exclusive-OR immediate to direct byte
CLR A CLR A 1/1 Clear A
CPL A CPL A 1/1 Complement A
RL A ROL A 1/1 Rotate A Left
RLC A RCL A 1/1 Rotate A Left through the Carry
RR A ROR A 1/1 Rotate A Right
RRC A RCR A 1/1 Rotate A Right through the Carry
SWAP A SWAP A 1/1 Swap nibbles within A (4bit rotate)
CLR C CLR C 1/1 Clear carry
CLR bit CLR bit 2/1 Clear direct bit
SETB C SET C 1/1 Set carry
SETB bit SET bit 2/1 Set direct bit
CPL C CPL C 1/1 Complement carry
CPL bit CPL bit 2/1 Complement direct bit
ANL C,bit AND C,bit 2/2 AND direct bit to Carry
ANL C,/bit AND C,/bit 2/2 AND complement of direct bit to Carry
ORL C,bit OR C,bit 2/2 OR direct bit to Carry
ORL C,/bit OR C,/bit 2/2 OR complement of direct bit to Carry
</TD></TR></TABLE>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpudatatransfer"></A>&nbsp;
CPU Data Transfer
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
<B> Mnemonic Nocash Bytes/Cycles Description</B>
MOV A,Rn MOV A,Rn 1/1 Move register to A
MOV A,direct MOV A,[nn] 2/1 Move direct byte to A
MOV A,@Ri MOV A,[Ri] 1/1 Move indirect RAM to A
MOV A,#data MOV A,nn 2/1 Move immediate to A
MOV Rn,A MOV Rn,A 1/1 Move A to register
MOV Rn,direct MOV Rn,[nn] 2/2 Move direct byte to register
MOV Rn,#data MOV Rn,nn 2/1 Move immediate to register
MOV direct,A MOV [nn],A 2/1 Move A to direct byte
MOV direct,Rn MOV [nn],Rn 2/2 Move register to A
MOV direct,direct MOV [nn],[nn] 3/2 Move direct byte to direct byte
MOV direct,@Ri MOV [nn],[Ri] 2/2 Move indirect RAM to direct byte
MOV direct,#data MOV [nn],nn 3/2 Move immediate to direct byte
MOV @Ri,A MOV [Ri],A 1/1 Move A to indirect RAM
MOV @Ri,direct MOV [Ri],[nn] 2/2 Move direct byte to indirect RAM
MOV @Ri,#data MOV [Ri],nn 2/1 Move immediate to indirect RAM
MOV DPTR,#data16 MOV DPTR,nnnn 3/2 Load data pointer with 16bit constant
MOVC A,@A+DPTR MOVC A,[A+DPTR] 1/2 Move code byte relative to DPTR to A
MOVC A,@A+PC MOVC A,[A+PC] 1/2 Move code byte relative to PC to A
MOVX A,@Ri MOVX A,[Ri] 1/2 Move external RAM (8bit addr) to A
MOVX A,@DPTR MOVX A,[DPTR] 1/2 Move external RAM (16bit addr) to A
MOVX @Ri,A MOVX [Ri],A 1/2 Move A to external RAM (8bit addr)
MOVX @DPTR,A MOVX [DPTR],A 1/2 Move A to external RAM (16bit addr)
PUSH direct PUSH [nn] 2/2 Increment SP, push direct byte to SP
POP direct POP [nn] 2/2 Pop direct byte from SP, decrement SP
XCH A,Rn XCHG A,Rn 1/1 Exchange register with A
XCH A,direct XCHG A,[nn] 2/1 Exchange direct byte with A
XCH A,@Ri XCHG A,[Ri] 1/1 Exchange indirect RAM with A
XCHD A,@Ri XCHD A,[Ri] 1/1 Exchange lower digit (4bit) with A
MOV C,bit MOV C,bit 2/1 Move direct bit to Carry
MOV bit,C MOV bit,C 2/2 Move Carry to direct bit
</TD></TR></TABLE>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpuprogrambranching"></A>&nbsp;
CPU Program Branching
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
<B> Mnemonic Nocash Bytes/Cycles Description</B>
ACALL addr11 ACALL addr11 2/2 Absolute subroutine call
LCALL addr16 LCALL addr16 3/2 Long subroutine call
RET RET 1/2 Return for subroutine
RETI RETI 1/2 Return for interrupt
SJMP rel SJMP rel 2/2 Short jump (8bit relative)
AJMP addr11 AJMP addr11 2/2 Absolute jump (11bit absolute)
LJMP addr16 LJMP addr16 3/2 Long jump (16bit long)
JMP @A+DPTR JMP A+DPTR 1/2 Jump indirect relative to DPTR
JZ rel JZ A,rel 2/2 Jump if A is zero
JNZ rel JNZ A,rel 2/2 Jump if A is not zero
CJNE A,direct,rel JNE A,[nn],rel 3/2 Cmp direct byte to A, jump if not eq
CJNE A,#data,rel JNE A,nn,rel 3/2 Cmp imm to A, jump if not eq
CJNE Rn,#data,rel JNE Rn,nn,rel 3/2 Cmp imm to register, jump if not eq
CJNE @Ri,#data,rel JNE [Ri],nn,rel 3/2 Cmp imm to indirect, jump if not eq
DJNZ Rn,rel DJNZ Rn,rel 3/2 Decrement register, jump if not zero
DJNZ direct,rel DJNZ [nn],rel 3/2 Decrement direct, jump if not zero
JC rel JC rel 2/2 Jump if Carry is set
JNC rel JNC rel 2/2 Jump if Carry is not set
JB bit,rel JNZ bit,rel 3/2 Jump if direct bit is set
JNB bit,rel JZ bit,rel 3/2 Jump if direct bit is not set
JBC bit,rel JNZ0 bit,rel 3/2 Jump if direct bit is set, clear bit
(INT vector) (INT vector) -/2? Interrupt (LCALL to vector address)
</TD></TR></TABLE>
The assembler automatically converts JMP and CALL into best matching opcodes.
LJMP/LCALL is choosen in case of forward references. AJMP/ACALL works only
inside of the current 800h-page. SJMP covers a range of -128..+127 bytes, which
may cross page boundaries.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cpunotes"></A>&nbsp;
CPU Notes
</FONT></TD></TR></TABLE><BR>
<B>Notes on instruction set and addressing modes</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Rn - Register R7-R0 of the currently selected register bank
(The register bank is selected by PSW.3 and PSW.4)
(Note that various opcodes support only &lt;direct&gt; operands,
but not &lt;Rn&gt; operands (eg. PUSH/POP). In such cases, the
assembler converts R0-R7 into direct addresses 00h-07h,
which is forcefully accessing register bank 0 only)
direct - 8-bit internal data locations's address. This could be an
internal data RAM location (0-127) or a SFR [i.e. I/O
port, control register, status register, etc. (128-255)].
@Ri - 8-bit internal data RAM location addressed indirectly
through register R1 or R0
#data - 8-bit constant included in instruction
#data16 - 16-bit constant included in instruction
addr16 - 16-bit destination address. Used by LCALL &amp; LJMP. A
branch can be anywhere within the 64K-byte Program Memory
address space
addr11 - 11-bit destination address. Used by ACALL &amp; AJMP. The
branch will be in the same 2K-byte page of program
memory as the first byte of the following instruction
rel - Signed (two's complement) 8-bit offset byte. Used by
SJMP and all conditional jumps. Range is -128 to +127
bytes relative to first byte of following the instruction
bit - Direct addressed bit in internal data RAM or special
function register (SFR)
</TD></TR></TABLE>
<BR>
<BR>
<B>Hardware information (Instruction set)</B><BR>
One cycle equals to 12 oscillator periods.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="flasheeprom"></A>&nbsp;
Flash EEPROM
</FONT></TD></TR></TABLE><BR>
Flash EEPROM is included in P89CE558 chips only.<BR>
<BR>
<A HREF="#feepromuseraccess">FEEPROM User Access</A><BR>
<A HREF="#feepromsecurity">FEEPROM Security</A><BR>
<A HREF="#feepromparallelprogramming">FEEPROM Parallel Programming</A><BR>
<A HREF="#feepromserialprogramming">FEEPROM Serial Programming</A><BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="feepromuseraccess"></A>&nbsp;
FEEPROM User Access
</FONT></TD></TR></TABLE><BR>
FFBAh - BYTE_READ<BR>
FFADh - BYTE_WRITE<BR>
FFAAh - PAGE_ERASE<BR>
FFA5h - BLOCK_ERASE<BR>
FFA0h - FULL_ERASE<BR>
FC07h - SERIAL_BOOT<BR>
<BR>
All functions may be invoked from inside of internal or external memory.
Interrupts should be disabled before the call, and FMCON should be reset to
zero immediately after the call (that is, as far as I understand, both meant to
be for security against piracy). Aside from below return values, all registers
remain unchanged.<BR>
<BR>
<B>FFBAh - BYTE_READ - Read one byte from FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=45h, DPTR=Byte Address
Out: FMCON=15h, A=DATA, DPTR=Unchanged
</TD></TR></TABLE>
Execution time should be only a couple of clock cycles, however, when internal
memory is enabled (/EA=1), then the same result can be gained more easily and
faster by a simple "MOVC A,@DPTR" instruction.<BR>
<BR>
<B>FFADh - BYTE_WRITE - Write one byte to FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=45h, A=DATA, DPTR=Byte Address
Out: FMCON=15h, A=DATA (read-back), DPTR=Unchanged
</TD></TR></TABLE>
Execution time is 2.5ms, the destination must have been previously erased, the
returned DATA contains read-back data from FEEPROM, a write failure may be
detected by comparing the original and returned DATA.<BR>
<BR>
<B>FFAAh - PAGE_ERASE - Erase 32 Bytes of FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=4Ch, DPTR=Page Address, lower 5bits ignored
Out: FMCON=1Ch, A=08h, DPTR=Unchanged, except that lower 5bits reset
</TD></TR></TABLE>
Execution time is 5ms, the erased memory will be FFh-filled.<BR>
<BR>
<B>FFA5h - BLOCK_ERASE - Erase 256 Bytes of FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=43h, DPTR=Block Address, lower 8bits (DPL) ignored
Out: FMCON=13h, ACC=02h, DPTR=Unchanged, except that lower 8bits reset
</TD></TR></TABLE>
Execution time is 5ms, the erased memory will be FFh-filled.<BR>
<BR>
<B>FFA0h - FULL_ERASE - Erase whole 32 KBytes of FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=4Ah
Out: FMCON=1Ah, ACC=0Ah, DPTR=0018h
</TD></TR></TABLE>
Execution time is 5ms, the erased memory will be FFh-filled.<BR>
For obvious reason, a full erase should be attempted only if the return address
is in external memory.<BR>
<BR>
<B>FC07h - SERIAL_BOOT - Download Code/Data via UART/RS232 into FEEPROM</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
In: FMCON=40h, Interrupt Registers, Stack Pointer, Timer 0, UART, P3.0-1
Out: Does never return - system must be manually reset after transfer.
</TD></TR></TABLE>
Execution time is 2.5ms per programmed byte (or slower when using less than
9600 Bauds). Because the function does not return, it should be invoked by JMP
rather than CALL. Aside from FMCON, all of the above listed registers must be
in reset state. Normally, this function is invoked by external signals, see
chaper "FEEPROM Serial Programming" for details.<BR>
<BR>
For (unimportant) details about the FMCON registers, see SYS chapter.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="feepromsecurity"></A>&nbsp;
FEEPROM Security
</FONT></TD></TR></TABLE><BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="feepromparallelprogramming"></A>&nbsp;
FEEPROM Parallel Programming
</FONT></TD></TR></TABLE><BR>
It is possible to program/erase the FEEPROM in the P89CE558 by parallel
programming, similar as a normal EPROM, high programming voltages aren't
required. The programming time is 2.5ms per byte (400 bytes/second),
programming the whole 32KBytes would take approximately 82 seconds. However,
parallel programming requires rather extensive connections:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
15 address lines,
8 data lines,
9 control lines,
and one 4-6MHz oscillator at XTAL1/XTAL2
</TD></TR></TABLE>
For details refer to data sheet. In most cases it'd be less complicated to
chose serial programming (see next chapter), and, when using a serial transfer
rate of at least 9600 Bauds, programming time should be quite as fast as
parallel programming.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="feepromserialprogramming"></A>&nbsp;
FEEPROM Serial Programming
</FONT></TD></TR></TABLE><BR>
<BR>
<BR>
<BR>
<B>Transfer Record Format</B><BR>
Binary data must be converted into Intel Hex Object Format (separate records of
ASCII strings which are formatted as ":BCAAAATTHH..HHCC").<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
: Record Start character
BC Byte Count (number of HH data bytes in this record, 00..FF)
AAAA Destination address of first byte of this record (0000..7FFF)
TT Record Type (00=data record, 01=end record)
HH Data Byte(s)
CC Record Checksum (CC = 00-BC-AA-AA-TT-HH-HH-HH-...-HH)
</TD></TR></TABLE>
Any data between ending "CC" and next following ":" will be ignored (ie.
optional ending carriage returns/linefeeds will not cause transmission errors).<BR>
<BR>
<B>Sending Records</B><BR>
Send any number of data records, each record is allowed to contain any number
of bytes (BC=00..FF), destination addresses (AAAA) are not required to be sent
in sequential order, there is no need to care about page boundaries in the
FEEPROM chip (a record may cross page boundaries, and, when changing only some
byte(s) inside if a page, the unchanged bytes are internally saved in RAM
before erasing that page, both changed and unchanged bytes are then (re-)
written to FEEPROM).<BR>
Send the end record once when all data records have been sent, the end record
must be always ":00000001FF", ie. BC=00, AAAA=0000, TT=01, with proper CC
checksum as usually.<BR>
<BR>
<B>Serial Communication</B><BR>
Data must be transferred as 1 startbit, 8 databits, and at least 1 stopbit.<BR>
The following character messages are sent from P8xCE559 to master.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
"." Acknowledges record type TT=00 received.
"X" Error - Bad CC checksum.
"Y" Error - Bad TT record type.
"Z" Error - Buffer overflow (Check Xon/Xoff)
"R" Error - Verification Error (of last byte written).
"V" End record (TT=01) received, and FEEPROM programming completed.
Xoff Busy. Master may not send further data. ;Xoff=chr(13h)
Xon End of Busy period. Master may continue sending. ;Xon =chr(???)
</TD></TR></TABLE>
No messages are sent if the baud rate for the first ":" character couldn't be
detected, valid baudrates are (provided that the system clock is within
specified min/max ranges):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Baudrate 1200 2400 4800 9600 19200 Bauds
fCLKmin 1 2 4 7.9 15.7 MHz
fCLKmax 3.6 7.3 14.7 29.5 59 MHz
</TD></TR></TABLE>
Notes: When using 'variable' system clock (generated from 32.768kHz oscillator
at XTAL3-4, SELXTAL1=0), then system clock is initialized at 11.01MHz (thus
only 4800 or 9600 bauds will be recognized).<BR>
Otherwise, when using fixed system clock (generated from oscillator at XTAL1-2,
SELXTAL1=1), only 3.5MHz..16MHz are actually supported by the hardware.<BR>
A baudrate of 19200 bauds would not actually increase the performance, the
internal programming time is 2.5ms/byte (400 bytes/sec), and 9600 bauds
(approx. 960 chars/sec = approx. 450 bytes/sec) would be thus more than fast
enough.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cirbasicconnectioncircuits"></A>&nbsp;
CIR Basic Connection Circuits
</FONT></TD></TR></TABLE><BR>
<A HREF="#cirresetcircuit">CIR Reset Circuit</A><BR>
<A HREF="#ciroscillatorsystemclock">CIR Oscillator (System Clock)</A><BR>
<A HREF="#cirpinouts">CIR Pin-Outs</A><BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cirresetcircuit"></A>&nbsp;
CIR Reset Circuit
</FONT></TD></TR></TABLE><BR>
<B>RSTIN-Pin (Reset Input)</B><BR>
Used for Power-on reset (and/or external reset "button", etc).<BR>
Reset is active when the input is HIGH (!)<BR>
<BR>
<B>RSTOUT-Pin (Reset Output)</B><BR>
Upon sensing an incoming reset at RSTIN (or when generating an internal reset
caused by timer 3 watchdog overflow), a reset (HIGH) signal is output to RSTOUT
- this should be used to reset any peripherals which are connected to the CPU.<BR>
<BR>
<B>8xCE558 Power-On Reset Circuit</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
+5V ----[]|---- RSTIN
+ -
</TD></TR></TABLE>
Use at least 2.2uF capaciator when using HF-oscillator at XTAL1/2,<BR>
use 0.1uF capaciator when using PLL-osciallator at XTAL3/4.<BR>
<BR>
After reset, program execution starts at 0000h, and most SFR registers are
reset. Internal RAM is not initialized - its contents are undefined upon
power-on, and are kept unchanged upon 'warm' reset.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="ciroscillatorsystemclock"></A>&nbsp;
CIR Oscillator (System Clock)
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
XTAL3,4 Oscillator Circuit, XTAL1,2 Oscillator Circuit XTAL1 External
PLL Oscillator+Seconds Timer (Standard 80C51 compatible) Clock Input
<B> SELXTAL1 XTAL3 XTAL4 XTAL1 XTAL2 SELXTAL1 XTAL1 SELXTAL1</B>
<B> | | | | | | | |</B>
<B> GND +-|O|-+ +-||-GND-||-+ +5V | +5V</B>
<B> Software-selectable system | | EXT.CLK,</B>
<B> clock rates of 3.93-15.73MHz +----|O|----+ 3.5-16MHz 3.5-16MHz</B>
Use external 32768Hz crystal Use 22pF capacitors, quartz Leave XTAL2
without external capacitors. crystal or ceramic resonator. not connected.
</TD></TR></TABLE>
Note:<BR>
One instruction cycle equals to 12 oscillator periods, that is, assuming a
system clock of approximately 12MHz, a the execution time for one NOP opcode
will be 1us.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="cirpinouts"></A>&nbsp;
CIR Pin-Outs
</FONT></TD></TR></TABLE><BR>
<B>Pinning diagram for the 8051 family</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
__________ __________
| \/ |
P1.0 | 01 40 | VCC
P1.1 | 02 39 | P0.0 AD0
P1.2 | 03 38 | P0.1 AD1
P1.3 | 04 37 | P0.2 AD2
P1.4 | 05 36 | P0.3 AD3
P1.5 | 06 35 | P0.4 AD4
P1.6 | 07 34 | P0.5 AD5
P1.7 | 08 33 | P0.6 AD6
RST,VPD* | 09 8051 32 | P0.7 AD7
RXD P3.0 | 10 31 | /EA
TXD P3.1 | 11 30 | ALE
/INT0 P3.2 | 12 29 | /PSEN
/INT1 P3.3 | 13 28 | P2.7 AD15
T0 P3.4 | 14 27 | P2.6 AD14
T1 P3.5 | 15 26 | P2.5 AD13
/WR P3.6 | 16 25 | P2.4 AD12
/RD P3.7 | 17 24 | P2.3 AD11
XTAL2 | 18 23 | P2.2 AD10
XTAL1 | 19 22 | P2.1 AD9
VSS | 20 21 | P2.0 AD8
|______________________|
</TD></TR></TABLE>
(*) VPD applicable to NMOS versions only<BR>
<BR>
<B>Pinning for P8xCE558</B><BR>
80 Pins SMD - Plastic Quat Flat Pack, 80 leads QFP80 (SOT318)<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1 AVref- 21 P4.2,CMSR2 41 P3.0,RXD 61 P2.6,A14
2 AVref+ 22 P4.3,CMSR3 42 P3.1,TXD 62 P2.7,A15
3 AVss1 23 RSTOUT 43 P3.2,/INT0 63 /PSEN
4 AVdd1 24 P4.4,CSMR4 44 P3.3,/INT1 64 ALE,/WE (*)
5 P5.7,ADC7 25 P4.5,CSMR5 45 P3.4,T0 65 /EA
6 P5.6,ADC6 26 P4.6,CMT0 46 P3.5,T1 66 Vdd4
7 P5.5,ADC5 27 P4.7,CMT1 47 P3.6,/WR 67 Vss4
8 P5.4,ADC4 28 Vdd2 48 P3.7,/RD 68 P0.7,AD7
9 P5.3,ADC3 29 Vss2 49 n.c. 69 P0.6,AD6
10 P5.2,ADC2 30 RSTIN 50 n.c. 70 P0.5,AD5
11 P5.1,ADC1 31 P1.0,CT0I,INT2 51 XTAL2 71 P0.4,AD4
12 P5.0,ADC0 32 P1.1,CT1I,INT3 52 XTAL1 72 P0.3,AD3
13 Vss1 33 P1.2,CT2I,INT4 53 Vdd3 73 P0.2,AD2
14 Vdd1 34 P1.3,CT3I,INT5 54 Vss3 74 P0.1,AD1
15 ADEXS 35 P1.4,T2 55 P2.0,A8 75 P0.0,AD0
16 /PWM0 36 P1.5,RT2 56 P2.1,A9 76 AVdd2
17 /PWM1 37 P1.6 57 P2.2,A10 77 AVss2
18 EW 38 P1.7 58 P2.3,A11 78 XTAL3
19 P4.0,CMSR0 39 SCL 59 P2.4,A12 79 XTAL4
20 P4.1,CMSR1 40 SDA 60 P2.5,A13 80 SELXTAL1
</TD></TR></TABLE>
(*) "/WE" for P89CE558 only. "n.c."=not connected.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="auxexternalhardware"></A>&nbsp;
AUX External Hardware
</FONT></TD></TR></TABLE><BR>
<B>Currently emulated hardware</B><BR>
No$x51 currently emulates a numeric keypad, and a 16x2 character LCD display:<BR>
<A HREF="#auxnumerickeypad">AUX Numeric Keypad</A><BR>
<A HREF="#auxlcddotmatrixmodule">AUX LCD Dot Matrix Module</A><BR>
<BR>
<B>Emulating other hardware</B><BR>
There are certainly millions of external devices which could be connected and
combined in various ways, and emulating all of that would be impossible.<BR>
However, upon request (if somebody would pay for it) I'd be considering to
emulate whatever required standard or non-standard hardware, including other
displays, LEDs, keyboards, buttons, memory, elevators, machines, sensors, etc.<BR>
<BR>
<B>Remote controlled chip</B><BR>
The most obvious (and easiest to implement) way to debug external hardware
would be to link the debugger to a real 8051/family chip by simple RS232
connection - assuming that your project already includes a RS232 interface,
you'd not need any additional hardware (except for a small BIOS loaded into
your (FE-)EPROM.<BR>
All program opcodes and internal timers would be kept emulated on the PC, but
read/write accesses to digital I/O ports P0..P5 or to ADC sensor inputs would
be transferred to/from real hardware.<BR>
This method would not be suitable for timing critical operations, and it'd
become kinda slow when transferring more than 1000 bytes/second. Aside from
that, it should allow to access external keyboards, displays, sensors, and
other inputs and outputs...<BR>
If anybody is interested, please let me know.<BR>
<BR>
<B>Software plug-ins</B><BR>
Another solution would be to provide a plug-in interface which'd allow people
to emulate their own hardware. I've not yet dealt with plug-ins though, and
would definetly need some tips/examples on how to implement such a thing.<BR>
<BR>
<B>Customizing your own software</B><BR>
The emulator may be detected by software (if enabled in setup) by examing the
content of the DPTR register directly after reset (value 0CA5h indicates no$x51
emulator).<BR>
For example, if your program requires a 4-digit LED display and two push
buttons, then (when detecting the emulator) you may redirect input and output
to the emulated 16x2 LCD display and numeric keypad.<BR>
Also, in case that your program 'hangs' in lack of incoming data from external
inputs, then you may want to skip over these inputs when having detected the
emulator.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="auxnumerickeypad"></A>&nbsp;
AUX Numeric Keypad
</FONT></TD></TR></TABLE><BR>
<B>Emulated Keyboard Interface</B><BR>
Currently emulates only access through &lt;direct&gt; operands.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
P4.7-5 Out Select Row, 0=Select
P4.4-1 Out Always output "1" to these bits
P4.4-1 In Read currently selected keyboard row(s), 0=Pressed
P4.0 - Not used
</TD></TR></TABLE>
Keys are mapped to following PC keys:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-9 --&gt; Keypad numbers and normal numbers
* --&gt; Keypad Enter and normal Enter
# --&gt; Keypad "." and Backspace
</TD></TR></TABLE>
<BR>
<B>Keyboard Matrix</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Ports P4.1 P4.2 P4.3 P4.4
P4.7 "1" "4" "7" "*"
P4.6 "2" "5" "8" "0"
P4.5 "3" "6" "9" "#"
</TD></TR></TABLE>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="auxlcddotmatrixmodule"></A>&nbsp;
AUX LCD Dot Matrix Module
</FONT></TD></TR></TABLE><BR>
<B>Emulated LTN I/O Interface</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Instruction Output (RS=0): MOV DPH,#80h / MOVX @DPTR,A
Data Output (RS=1, R/W=0): MOV DPH,#82h / MOVX @DPTR,A
Data Input (RS=1, R/W=1): MOV DPH,#83h / MOVX A,@DPTR
</TD></TR></TABLE>
Currently emulates LTN 211R-10 (16 x 2 characters) only.<BR>
Special functions such like scrolling aren't yet understood.<BR>
<BR>
<B>LTN Instruction Set</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
RS__R/W__D7__D6__D5__D4__D3__D2__D1__D0__Instruction___________
0 0 0 0 0 0 0 0 0 1 Display Clear
0 0 0 0 0 0 0 0 1 * Cursor Home
0 0 0 0 0 0 0 1 I/D S Entry Mode Set
0 0 0 0 0 0 1 D C B Display on/off Control
0 0 0 0 0 1 S/C R/L * * Cursor Display Shift
0 0 0 0 1 DL 1 0 * * Function Set
0 0 0 1 &lt;-------- Acg --------&gt; CG RAM Address Set (0-3Fh)
0 0 1 &lt;------------ Add --------&gt; DD RAM Address Set (0-7Fh)
0 1 BF &lt;------------ Ac --------&gt; Busy Flag/Address Read
1 0 &lt;-------- write data --------&gt; CG/DD RAM data write
1 1 &lt;-------- read data --------&gt; CG/DD RAM data read
</TD></TR></TABLE>
Whereas:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
I/D 0=Decrement, 1=Increment
S 0=Display freeze, 1=Display shift
D 0=Display off, 1=Display on
C 0=Cursor off, 1=Cursor on
B 0=Blinking off, 1=Character at Cursor position blinking
S/C 0=Cursor move, 1=Display shift
R/L 0=left shift, 1=right shift
DL 0=4bits, 1=8bits
BF 0=Not busy, 1=Internal operation busy
* Don't care (?)
</TD></TR></TABLE>
<BR>
<B>DD-RAM Memory Map</B><BR>
LTN 111R-10 DD-RAM (16 x 1 characters):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Line 1 00h 01h 02h 03h 04h 05h 06h 07h 40h ... 47h (!)
</TD></TR></TABLE>
LTN 211R-10 DD-RAM (16 x 2 characters):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Line 1 00h 01h 02h 03h 04h 05h 06h 07h 08h ... 0Fh
Line 2 40h 41h 42h 43h 44h 45h 46h 47h 48h ... 4Fh
</TD></TR></TABLE>
LTN 242R-10 DD-RAM (40 x 2 characters):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Line 1 00h 01h 02h 03h 04h 05h 06h 07h 08h ... 26h 27h
Line 2 40h 41h 42h 43h 44h 45h 46h 47h 48h ... 66h 67h
</TD></TR></TABLE>
<BR>
<B>CG-RAM Memory Map</B><BR>
Character Generator RAM for eight user-defined characters of 8 bytes each.
Format of bitmap for each character not specified/unknown ???<BR>
<BR>
<B>Character Set (5x7 dots, excluding spacing between characters)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
00h-07h CG RAM (1-8)
08h-0Fh CG RAM (1-8)
10h-1Fh Undefined
20h-7Fh Normal ASCII charcters (*)
80h-9Fh Undefined
A0h-FFh Japanese/European characters
</TD></TR></TABLE>
(*) Except non-ascii 5Ch (yen instead "\"), 7Eh (arrow right instead "~"), and
7Fh (arrow left). Some of the E0h-FFh characters are sized 8 dots vertically
and cannot be displayed properly on above listed display types.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630amemorymap"></A>&nbsp;
AMT630A - Memory Map
</FONT></TD></TR></TABLE><BR>
<B>CODE (opcode-fetches and MOVC reads)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0000h..7FFFh Fixed (always 1st 32Kbytes of SPI FLASH memory)
8000h..FFFFh Mappable (usually 2nd 32Kbytes of SPI FLASH memory)
</TD></TR></TABLE>
CPU clock is 6.75MHz (27MHz/4). The code is loaded from serial SPI bus to some
cache. The CPU will be paused for around 43us upon cache misses, causing the
overall CPU clock to drop to around 2.03MHz (as so when executing thousands of
1-cycle NOP opcodes).<BR>
<BR>
<B>RAM/SFR (data/registers accessed via MOV/ALU opcodes)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
00h..07h Standard CPU registers R0-R7 (bank 0)
08h..7Fh Standard RAM
80h..FFh Extended RAM, 80C52-style (via indirect [R0],[R1],[SP])
80h..FFh Standard+Extended SFR Registers (via direct [imm])
</TD></TR></TABLE>
<BR>
<B>XRAM (accessed via MOVX opcodes)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0000h..07FFh Extra RAM (2Kbytes)
0800h..1FFFh Mirror of SPI FLASH addresses 000800h..001FFFh (read only)
2000h..2FFFh Unknown (hardware status regs ?) (read only)
3000h..FAFFh Unused (open-bus)
FB00h..FBFFh I/O Ports (OSD on-screen display)
FC00h..FCFFh I/O Ports (LCD screen ratio)
FD00h..FDFFh I/O Ports (Misc, ADC, PWM, PLL, PIN, FLASH, etc.)
FE00h..FEFFh I/O Ports (AV video input)
FF00h..FFFFh I/O Ports (LCD colors/brightness and IR Infrared)
</TD></TR></TABLE>
<BR>
<B>OSD Memory (VRAM, write-only(?), accessed via FCxxh I/O ports, or FONT-DMA)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
BGMAP RAM: 200h entries (each 10bit character number plus 7bit attribute)
FONT RAM: 1000h words (aka 2000h bytes, aka 8Kbytes)
FONT ROM: 418 characters (16x22pix, 1bpp; uppercase text &amp; exotic symbols)
</TD></TR></TABLE>
<BR>
<B>SPI FLASH (accessed via FDxxh ports, and directly mapped to CPU memory space)</B><BR>
AMT630A boards are commonly fitted with 256-512Kbyte FLASH (though firmware
uses less than 48Kbytes, plus two 1000h-byte sectors at E000h/F000h for saving
user settings).<BR>
First 2x32Kbyte FLASH are usually mapped to CPU's CODE memory (16bit address
space).<BR>
The whole FLASH can be accessed via FDxxh I/O ports (24bit address space).<BR>
The FDxxh I/O ports also have some FLASH DMA support.<BR>
Some FLASH snippet is also mirrored to XRAM memory space (unknown if one can
somehow select WHICH snippet).<BR>
<BR>
<B>Further memory</B><BR>
The AMT630A chip has some memory buffer for resampling scanlines to actual TFT
resolution (with the improper PAL60 support, one can actually see that the
hardware does memorize older scanlines).<BR>
Aside from firmware FLASH, there might be some Boot ROM (for initializing FLASH
acccess, possible with 2bit/4bit databus, depending on the installed FLASH
chip; 25Dxx vs 25Qxx).<BR>
SPI FLASH is somehow cached for reducing SPI bus traffic, details on cache size
are unknown.<BR>
<BR>
<B>Exception Vectors in CODE memory</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0000h reset firmware reset vector (and apparently watchdog, too)
0003h infrared firmware has IR infrared handler (in some versions) (ext.0)
000Bh timer 0 firmware has dummy timer 0 reload handler
0013h spi flash firmware has no handler for this (ext.1)
001Bh timer 1 firmware has timer 1 handler (sensing AV signal etc)
0023h uart firmware has no handler for this
002Bh timer 2 firmware has no handler for this (80C52-style extension)
0033h ? firmware has no handler for this
003Bh ? (if any) firmware has no handler for this (are there IEC/IPC bits?)
0043h ADC firmware acknowledges SFR_IO_xxx91h.bit4 and IO_ADC_status
004Bh ? firmware acknowledges SFR_IO_xxx91h.bit5
0053h ? firmware acknowledges SFR_IO_xxx91h.bit6
005Bh framerate firmware acknowledges SFR_IO_xxx91h.bit7 (vblank/vsync?)
0063h timer 3+4 firmware has no handler for this (timer 3+4 and SFR D8h)
</TD></TR></TABLE>
Blurb from AMT630A spec sheet: "Supports 13 standard interrupt sources include
external interrupt, 3 Timer, watchdog etc"<BR>
Above four unknown vectors might include: I2C, GPIO, and whatever... maybe
watchdog can be re-mapped to another vector than reset?<BR>
<BR>
<B>Open-bus areas in XRAM memory space</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
3000h..FAFFh - Unused (open-bus) (CB00h bytes)
FB8Ah..FBFFh - Unused (open-bus) (76h bytes)
FC11h - Unused (open-bus) (01h byte)
FC47h..FC8Fh - Unused (open-bus) (49h bytes)
FCB9h..FCBAh - Unused (open-bus) (02h bytes)
FCEBh..FCFFh - Unused (open-bus) (15h bytes)
FD60h..FDAFh - Unused (open-bus) (50h bytes)
FDE8h..FDEFh - Unused (open-bus) (08h bytes)
FDF2h..FDFFh - Unused (open-bus) (0Eh bytes)
FEFFh - Unused (open-bus) (01h byte)
FFA4h..FFAFh - Unused (open-bus) (0Ch bytes)
FFDDh - Unused (open-bus) (01h byte)
FFEBh..FFEFh - Unused (open-bus) (05h bytes)
FFFCh..FFFFh - Unused (open-bus) (04h bytes)
</TD></TR></TABLE>
Reading from open-bus areas does usually return FFh, or most recent value being
read from FB00h..FFFFh region (or a mixup thereof, ie. some "0" bits from the
recent value already faded to "1" bits).<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630asfrssystemtimersportsetc"></A>&nbsp;
AMT630A - SFRs - System Timers/Ports/etc
</FONT></TD></TR></TABLE><BR>
<B>SFR 81h - SFR_CPU_sp</B><BR>
<B>SFR 82h - SFR_CPU_dpl ;lsb of 16bit dptr</B><BR>
<B>SFR 83h - SFR_CPU_dph ;msb of 16bit dptr</B><BR>
<B>SFR D0h - SFR_CPU_psw</B><BR>
<B>SFR E0h - SFR_CPU_a</B><BR>
<B>SFR F0h - SFR_CPU_b</B><BR>
Standard 80C31 CPU registers.<BR>
<BR>
<B>SFR 80h - SFR_IO_PORT0_DATA (p0)</B><BR>
<B>SFR 90h - SFR_IO_PORT1_DATA (p1)</B><BR>
<B>SFR A0h - SFR_IO_PORT2_DATA (p2)</B><BR>
<B>SFR B0h - SFR_IO_PORT3_DATA (p3)</B><BR>
Standard 80C31 peripheral I/O ports. Most of the ports are used for LCD video,
some for the SPI FLASH memory system, and some are available for general
purpose, and/or can be switched to special PWM/ADC/REMOTE/I2C modes, the mode
selection for each pin is to be done via special SFR_IO_PORTx_MODE_A/B and
IO_PIN_xxx registers.<BR>
<BR>
<B>SFR 87h - SFR_IO_PCON ;bit0-1:DANGER(halt/idle), bit4-5:NOT R/W(1?), bit6=?</B><BR>
<B>SFR 88h - SFR_IO_TCON ;bit3:NOT R/W</B><BR>
<B>SFR 89h - SFR_IO_TMOD</B><BR>
<B>SFR 8Ah - SFR_IO_timer0_lsb (tl0)</B><BR>
<B>SFR 8Bh - SFR_IO_timer1_lsb (tl1)</B><BR>
<B>SFR 8Ch - SFR_IO_timer0_msb (th0)</B><BR>
<B>SFR 8Dh - SFR_IO_timer1_msb (th1)</B><BR>
<B>SFR 98h - SFR_IO_sio_scon ;serial UART control</B><BR>
<B>SFR 99h - SFR_IO_sio_sbuf ;serial UART data ;read (R) and write (W)</B><BR>
<B>SFR A8h - SFR_IO_iec ;extended, with extra bits in bit5-6 (set to 28h/A8h)</B><BR>
<B>SFR B8h - SFR_IO_ipc ;extended, with extra bits in bit5-6, bit7:NOT R/W</B><BR>
Standard 80C31 control/timer/uart registers. Some register bits are slightly
customized:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
PCON.4 unknown (read-only, always 1) ;maybe whatever 80C52-style POF bit?
PCON.5 unknown (read-only, always 1)
PCON.6 unknown (read/write-able)
IEC.5 and IPC.5 probably 80C52-style Timer2 interrupt (read/write-able)
IEC.6 and IPC.6 unknown... some extra interrupt? (read/write-able)
</TD></TR></TABLE>
<BR>
<B>SFR C8h - SFR_IO_timer2_control ;80C52-style extension</B><BR>
<B>SFR CAh - SFR_IO_timer2_reloadcapture_lsb ;80C52-style extension</B><BR>
<B>SFR CBh - SFR_IO_timer2_reloadcapture_msb ;80C52-style extension</B><BR>
<B>SFR CCh - SFR_IO_timer2_counter_lsb (R) ;80C52-style extension</B><BR>
<B>SFR CDh - SFR_IO_timer2_counter_msb (R) ;80C52-style extension</B><BR>
These Timer2 registers are a fairly common 80C52-based SFR extension. The
firmware tries to initialize these to 57600 baud (but with improper rounding
and insane div32 prescaler), alongsides it does enable Timer2 IRQs (although
not having a proper irq vector for it, not having implemented any serial
get/send byte functions).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________ AMT630A-specific Non-standard SFR's ____________________
</TD></TR></TABLE>
<BR>
<B>SFR E8h - SFR_IO_IEC2 ;Interrupt Enable Flags</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Enable IRQ 0043h (adc)
1 Enable IRQ 004Bh
2 Enable IRQ 0053h
3 Enable IRQ 005Bh (vblank/vsync or so)
4 Enable IRQ 0063h (timer3+timer4)
5-7 Unknown, not R/W (usually/always 111b)
</TD></TR></TABLE>
Firmware initalizes 4bits in this register (and leaves 5th bit unchanged).<BR>
Note: This register is standard in so far as sharing the same SFR address as in
P8xCE558 chips (but with different irq sources in the registers).<BR>
<BR>
<B>SFR F8h - SFR_IO_xxxF8h</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-4 Seems to be related to SFR E8h.bit0-4, see there
5-7 Unknown, not R/W (usually/always 111b)
</TD></TR></TABLE>
Firmware initalizes 4bits in this register (and leaves 5th bit unchanged).<BR>
Maybe Interrupt PRIORITY bits?<BR>
Note: This register is standard in so far as sharing the same SFR address as in
P8xCE558 chips (but with different irq sources in the registers).<BR>
<BR>
<B>SFR 91h - SFR_IO_xxx91h (usually 88h when reading?)</B><BR>
Extra Interrupt FLAGS (and acknowledge).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 Unknown, NOT R/W
4 Write 0 for IRQ 0043h acknowledge (ADC) ;also need to ack IO_ADC_status
5 Write 0 for IRQ 004Bh acknowledge
6 Write 0 for IRQ 0053h acknowledge
7 Write 0 for IRQ 005Bh acknowledge (vblank/vsync or so)
</TD></TR></TABLE>
Oddly, bit4-7 are fully R/W, making it impossible to clear single bits without
destroying the other bits (unless "AND [91h],mask" should happen to leave the
unchanged bits untouched, instead of acting as RMW, which would cause any
transitions between read &amp; modify to get lost). Best might be to IGNORE the
value in SFR 91h, and just write write 00h (clear all bits), and check for
secondary IRQ flags in ADC/etc registers, instead of relying on the SFR 91h
bits (though unknown if there's any such flag corresponding to bit7).<BR>
Bit7 can be acknowledged via SFR 91h.bit7 (without needing to ack any other
registers). Bit7 gets set once per frame (at vsync/vblank or so). The framerate
depends on the AV signal (50Hz/60Hz), if there's no AV signal then bit7 is kept
thrown at the most recent AV framerate (with OSD frames being kept drawn at
that framerate). Bit7 won't get set if the display PLL's are powered off.<BR>
<BR>
Blurb from AMT630A spec sheet: "Supports 13 standard interrupt sources include
external interrupt, 3 Timer, watchdog etc"<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
There seem to be 7 interrupt sources in IEC/IPC
There seem to be 5 interrupt sources in E8h/F8h
And Reset/Watchdog might be the 13th interrupt source.
However, there seem to be 14 exception vectors in total (including reset).
</TD></TR></TABLE>
<BR>
<B>SFR C6h - SFR_IO_memory_system ;DANGER ;flash/osd memory system?</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 DANGER: causes reboot when changed
1 Unknown, NOT R/W
2 Unknown
3 Disable OSD TEXT rendering (should be set during FLASH-to-FONT DMA)
4-6 Unknown
7 Firmware sets bit7 upon power-up, DANGER: hangs when changed
</TD></TR></TABLE>
<BR>
<B>SFR 8Eh - SFR_IO_whatever_config ;-lower 3bits set</B><BR>
Unknown, firmware sets the lower 3 bits during init (and leaves the upper 5bit
unchanged).<BR>
<BR>
<B>SFR D8h - whatever ;bit0-2,6:NOT R/W ;bit5: makes CPU 21.25x slower</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-2 Unknown, not R/W ;not R/W
3 Unknown, somehow forces IRQ 0063h (timer3+4)? ;R/W
4 Unknown ;R/W
5 Unknown, once seemed to make CPU 21.25x slower? ;R/W
6 Unknown, not R/W ;not R/W
7 Unknown ;R/W
</TD></TR></TABLE>
Whatever, parts R/W, not used by firmware.<BR>
<BR>
<B>SFR 92h - SFR_IO_xram_bank</B><BR>
Upper 8bit of XRAM address for 8bit addressing via "movx [r0]" (eg. allows to
access 2K XRAM at 0000h-07FFh, and I/O ports at FB00-FFFFh). Not used by
firmware (the firmware is doing all XRAM addressing via 16bit dptr).<BR>
<BR>
<B>SFR B1h - SFR_IO_timer3_lsb ;\faster timer (incrementing)</B><BR>
<B>SFR B2h - SFR_IO_timer3_msb ;/</B><BR>
<B>SFR B3h - SFR_IO_timer4_lsb ;\slower timer (4x slower than above)</B><BR>
<B>SFR B4h - SFR_IO_timer4_msb ;/</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-15 Incrementing Timer value (R/W)
</TD></TR></TABLE>
Unknown if there's a way to stop the timers, or to change their speed.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Timer 3 is faster
Timer 4 is slower (4x slower than Timer 3)
</TD></TR></TABLE>
<BR>
<B>SFR B5h - SFR_IO_timer34_stat ;NOT R/W ;03h</B><BR>
Reading returns overflow flags:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Timer 3 overflow flag, not R/W (1=overflow occurred)
1 Timer 4 overflow flag, not R/W (1=overflow occurred)
2-7 Unknown/unused, not R/W
</TD></TR></TABLE>
Writing acknowledges bits, oddly using bit1-2 instead of bit0-1:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Unknown/unused
1 Acknowledge Timer 3 overflow (0=No change, 1=Clear overflow flag)
2 Acknowledge Timer 4 overflow (0=No change, 1=Clear overflow flag)
3-7 Unknown/unused
</TD></TR></TABLE>
Not used by firmware. Note: The overflow flags get set even when IRQs are
disabled via SFR B6h and/or SFR E8h.<BR>
<BR>
<B>SFR B6h - SFR_IO_timer34_ctrl ;bit2-7:NOT R/W</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Timer 3 IRQ Enable (when master enable in SFR E8h.bit4 is set)
1 Timer 4 IRQ Enable (when master enable in SFR E8h.bit4 is set)
2-7 Unknown/unused, not R/W
</TD></TR></TABLE>
Not used by firmware. Enables IRQ 0063h (used for both Timer 3+4).<BR>
<BR>
<B>SFR B9h - SFR_IO_watchdog_config1 ;when locked: NOT R/W ;03 ;bit2-7:never R/W</B><BR>
<B>SFR BAh - SFR_IO_watchdog_enable ;when locked: NOT R/W ;00 ;bit1-7:never R/W</B><BR>
<B>SFR BBh - SFR_IO_watchdog_reload ;when locked: NOT R/W ;00 ;bit1-7:never R/W</B><BR>
<B>SFR BCh - SFR_IO_watchdog_config2 ;when locked: NOT R/W ;FF ;fully R/W</B><BR>
<B>SFR BDh - SFR_IO_watchdog_config3 ;when locked: NOT R/W ;8F ;fully R/W</B><BR>
<B>SFR BEh - SFR_IO_watchdog_unlock ;when locked: NOT R/W ;00 ;never R/W?</B><BR>
When enabled, resets the CPU when not reloading it for about 1 second.<BR>
<BR>
<B>SFR E9h - SFR_IO_PORT0_MODE_A ;bit7,6=PWM, bit0,1,2=ADC, bit3=IR</B><BR>
<B>SFR EDh - SFR_IO_PORT0_MODE_B ;bit7,6=PWM, bit0,1,2=ADC, bit3=IR</B><BR>
<B>SFR EAh - SFR_IO_PORT1_MODE_A ;(?)</B><BR>
<B>SFR EEh - SFR_IO_PORT1_MODE_B ;(?)</B><BR>
<B>SFR EBh - SFR_IO_PORT2_MODE_A ;(?)</B><BR>
<B>SFR EFh - SFR_IO_PORT2_MODE_B ;(?)</B><BR>
<B>SFR ECh - SFR_IO_PORT3_MODE_A ;bit7,6,5=PWM</B><BR>
<B>SFR F4h - SFR_IO_PORT3_MODE_B ;bit7,6,5=PWM</B><BR>
Used to configure Port0-3, combined with the 4bit IO_PIN_xxx settings,
following combinations are known:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
A B 4bit
0 1 x000 Digital.output (eg. for LCD SPI writes, or static backlight)
1 0 x000 Digital.input (eg. for LCD SPI reads)
1 1 xxxx ADC (analog/digital converter, eg. keypad button read)
x x xx11 PWM (pulse-width output, eg. for dimmed backlight)
x x 0001 LCD 3.5" (RGB+CLK+DEN+SYNC) and SPI FLASH pins
x x 0002 LCD 4.3" (RGB+CLK+DEN)
1 0 xxxx REMOTE (infrared IR input)
</TD></TR></TABLE>
<BR>
<B>SFR E4h - SFR_IO_IR_data ;NOT R/W ;FFh (Write FFh to acknowledge IRQ?)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Command from REMOTE (further stuff is in FFxxh register area)
</TD></TR></TABLE>
<BR>
<B>SFR E5h - SFR_IO_IR_flags ;NOT R/W ;00h (Write FEh to acknowledge bit0?)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Flag (maybe new command?)
1 Flag (maybe repeat?)
2 Unknown (usually 0, but I think've seen the register being 04h once)
3-7 Unknown (usually 0)
</TD></TR></TABLE>
<BR>
<B>SFR 86h - whatever ;bit0:DANGER, bit1-7:NOT RW</B><BR>
<B>SFR 8Fh - whatever ;bit0:SKIPPED???(force ADC=ready?), bit1-7:NOT R/W</B><BR>
<B>SFR F5h - whatever ;bit1-7:NOT R/W</B><BR>
Whatever, parts R/W, not used by firmware.<BR>
<BR>
<B>SFR E1h - whatever status? ;NOT R/W ;FFh ;\</B><BR>
<B>SFR E2h - whatever status? ;NOT R/W ;FFh ;</B><BR>
<B>SFR E3h - whatever status? ;NOT R/W ;FFh ;/</B><BR>
Whatever, seems to be read-only, not used by firmware.<BR>
<BR>
<B>SFR 84h..85h - whatever, 2 bytes (usually 00h, but read/write-able)</B><BR>
<B>SFR A1h..A7h - whatever, 7 bytes (usually 00h, but read/write-able)</B><BR>
<B>SFR A9h..AFh - whatever, 7 bytes (usually 00h, but read/write-able)</B><BR>
<B>SFR D2h..D5h - whatever, 4 bytes (usually 00h, but read/write-able)</B><BR>
<B>SFR C7h - whatever, 1 byte (usually 00h, but read/write-able)</B><BR>
Whatever, 8bit fully R/W, not used by firmware.<BR>
<BR>
<B>SFR 93h..97h - unknown/unused, 5 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR 9Ah..9Fh - unknown/unused, 6 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR C0h..C5h - unknown/unused, 6 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR CEh..CFh - unknown/unused, 2 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR D6h..D7h - unknown/unused, 2 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR D9h..DFh - unknown/unused, 7 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR E6h..E7h - unknown/unused, 2 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR F1h..F3h - unknown/unused, 3 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR F6h..F7h - unknown/unused, 2 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR F9h..FFh - unknown/unused, 7 bytes (not R/W, returns 00h on reading)</B><BR>
<B>SFR B7h - unknown/unused, 1 byte (not R/W, returns 00h on reading)</B><BR>
<B>SFR BFh - unknown/unused, 1 byte (not R/W, returns 00h on reading)</B><BR>
<B>SFR C9h - unknown/unused, 1 byte (not R/W, returns 00h on reading)</B><BR>
<B>SFR D1h - unknown/unused, 1 byte (not R/W, returns 00h on reading)</B><BR>
These registers seem to be always 00h, not read/write-able. Maybe they are just
unused SFR addresses.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630afbxxhosdregistersonscreendisplay"></A>&nbsp;
AMT630A - FBxxh - OSD Registers (On-Screen Display)
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ Window 0..4 _______________________________
</TD></TR></TABLE>
<BR>
<B>FB07h/FB12h/FB18h/FB1Eh/FB24h - IO_OSD_window_N_size_x (N=0..4)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-6 Horizontal Window Size in Characters (1..127)
7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB08h/FB13h/FB19h/FB1Fh/FB25h - IO_OSD_window_N_size_y (N=0..4)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-5 Vertical Window Size in Characters (1..63)
6-7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB09h/FB14h/FB1Ah/FB20h/FB26h - IO_OSD_window_N_xyloc_msb (N=0..4)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-2 Upper 3bit of 11bit Horizontal Window position
3 ???
4-6 Upper 3bit of 11bit Vertical Window position
7 Upper 1bit of 9bit Window's BGMAP Address ;Window 0: Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB0Ah/FB15h/FB1Bh/FB21h/FB27h - IO_OSD_window_N_xloc_lsb (N=0..4)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 11bit Horizontal Window position (0..7FFh) (10=leftmost)
</TD></TR></TABLE>
<BR>
<B>FB0Bh/FB16h/FB1Ch/FB22h/FB28h - IO_OSD_window_N_yloc_lsb (N=0..4)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 11bit Vertical Window position (0..7FFh) (12=topmost)
</TD></TR></TABLE>
<BR>
<B>FB17h/FB1Dh/FB23h/FB29h - IO_OSD_window_N_vramaddr_lsb (N=1..4 only, not N=0)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 9bit Window's BGMAP Address (0..1FFh)
</TD></TR></TABLE>
Note: Address for Window 0 is fixed (always 000h).<BR>
<BR>
The xloc/yloc values are unsigned 0..7FFh (ie. 7FFh will hide the OSD window,
rather than being treated as "-1"). Nethertheless parts offscreen tiles at
upper/left screen edges are possible with xloc=0..9 or yloc=0..11 (that,
depending on the OSD position defined in FCxxh registers).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
______________________________ Control Regs _______________________________
</TD></TR></TABLE>
<BR>
<B>FB05h - IO_OSD_window_enable_bits</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-4 Enable Window 0..4 (0=Off, 1=On)
5 ???
6 Disable 1bpp Text (0=Normal, 1=Force all 1bpp Tiles Black)
7 Enable 4bpp Bitmap (0=Off, 1=4bpp for IO_OSD_bitmap_start and up)
</TD></TR></TABLE>
<BR>
<B>FB06h - IO_OSD_misc_transp_enable</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-5 ???
6 SemiTransparency Enable for BG (0=Solid, 1=SemiTransp)
7 SemiTransparency Enable for TEXT (0=Solid, 1=SemiTransp, if bit6=1)
</TD></TR></TABLE>
<BR>
<B>FB0Ch - IO_OSD_bright_transp_level</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-2 SemiTransparency (0=OsdIsInvisible, 1..7=more and more opaque)
3-4 ???
5-7 Brightness (0=Black, 1=Dark, 2=Med, 3=Bright, 4=Max/Normal, 5..7=Crop)
</TD></TR></TABLE>
SemiTransparency makes the AV layer visible even underneath of OSD pixels, the
effect can be enabled in FB06h for BG and TEXT.<BR>
Brightness adjust works as "RGB=RGB*Brightness(0..7)/4", and crops the result
to max 0Fh. The firmware does (maybe accidentally) use Brightness=7, resulting
in only 11 different RGB intensities (00h..0Ah, and 0Bh..0Fh all appearing as
dupes of 0Ah).<BR>
<BR>
<B>FB78h - IO_OSD_xyflip (used by unused firmware functions)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 ???
4 Xflip Tiles (0=Normal; 1st Pixel (MSB) is left, 1=Mirror Horizontally)
5 Xflip BGMAP (0=Normal; 1st Tile is left, 1=Mirror Horizontally)
6 Yflip Tiles (0=Normal; 1st Pixel-row is upper, 1=Mirror Vertically)
7 Yflip BGMAP (0=Normal; 1st Tile-row is upper, 1=Mirror Vertically)
</TD></TR></TABLE>
Note: The window positions must be manually adjusted for flipping, eg.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
xloc = osd_base_x + xloc ;\normal
yloc = osd_base_y + yloc ;/
xloc = osd_base_x + screen_width - window_width - xloc ;\flipped
yloc = osd_base_y + screen_height - window_height - yloc ;/
</TD></TR></TABLE>
Flipping affects OSD only. There's no known way to flip AV at AMT630A side
(though maybe it does support xflip somehow, yflip is probably not possible due
to limited line buffer size). However, some LCD displays are supporting
x/y-flipping via SPI bus commands (eg. NV3035C-based Tianma displays, or
HX8238-D-based Noname displays, whilst Innolux displays aren't having SPI bus
at all). For example, one could apply xflip to OSD and also to the whole LCD
image - resulting in mirrored AV image with normal OSD output (due to double
flipping applied to OSD). Moreover, if AV comes from a camera: some cameras
might support flipping.<BR>
<BR>
<B>FB35h - IO_OSD_bitmap_transp_misc (set to 00h by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-2 ???
3 Affects Horizontal Window positions (0=Normal, 1=Shift SOME pixels)
4 Bitmap Color 0 (aka 4bpp tiles) (0=Transparent, 1=Solid)
5 Affects Vertical Window positions (0=Normal, 1=Shift ONE pixel)
6-7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB62h - IO_OSD_whatever_FB62h (bit0 cleared by firmware) (no visible effect)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 ??? (cleared by firmware; alongsides when disabling the 5 windows)
1-7 ???
</TD></TR></TABLE>
<BR>
<B>FB89h - IO_OSD_screen_position (set to 00h by firmware) (window positions?)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Move windows 2pix DOWN, and SOME pix LEFT
1 Jitters! Scanline 1pix shift (with AV: each 2nd line, no AV: each 3rd)
2 ???
3 Move windows SOME pix DOWN (bottom-most pixels wrap to top of screen)
4-7 Not used (always 0)
</TD></TR></TABLE>
Bit1 moves all windows SOME pix RIGHT, and also each 2nd/3rd scanline one more
pixel left/right (without AV that's each 3rd line and it's fixed in all frames,
with AV it's each 2nd line and it's alternating for odd/even lines in odd/even
frames).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ Window Scale _______________________________
</TD></TR></TABLE>
<BR>
<B>FB2Bh - IO_OSD_window_0_vscale_lsb_upper_8_pixels</B><BR>
<B>FB2Ch - IO_OSD_window_0_vscale_mid_middle_8_pixels (if height&gt;8)</B><BR>
<B>FB2Dh - IO_OSD_window_0_vscale_mid_lower_8_pixels (if height&gt;16)</B><BR>
<B>FB2Eh - IO_OSD_window_0_vscale_msb_lowest_8_pixels (if height&gt;23)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-31 Scale 1st..32th pixel within Font tile (bit0=topmost) (0=No, 1=Scale)
</TD></TR></TABLE>
<BR>
<B>FB2Fh - IO_OSD_window_0_hscale_lsb_left_8_pixels</B><BR>
<B>FB30h - IO_OSD_window_0_hscale_mid_middle_8_pixels (if width&gt;8)</B><BR>
<B>FB31h - IO_OSD_window_0_hscale_msb_right_8_pixels (if width&gt;16)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-23 Scale 1st..24th pixel within Font tile (bit0=leftmost) (0=No, 1=Scale)
</TD></TR></TABLE>
<BR>
<B>FB32h - IO_OSD_window_0_scale</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-1 Window 0 Horizontal Scale (0=Double, 1=Triple, 2=Quad, 3=FiveX)
2-3 Window 0 Vertical Scale (0=Double, 1=Triple, 2=Quad, 3=FiveX)
4-7 Not used (always 0)
</TD></TR></TABLE>
For window 0, scaling is applied only to the pixels selected in hscale/vscale
bits. Normally the vscale/hscale bits would be set to all 00h's or all FFh's.
Other settings are resulting in smeared appearance with some pixels being wider
than others. However, that effect may be useful in a few cases: For animated
zoom-in/out effects, for stretching the character spacing (when lower/right
pixels are all blank), or for stretching certain sections of uniformly defined
symbols (eg. the 2nd/4th/6th lines of uppercase letters with 6pix height).<BR>
<BR>
<B>FB33h - IO_OSD_window_1_and_2_scale</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-1 Window 1 Horizontal Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
2-3 Window 1 Vertical Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
4-5 Window 2 Horizontal Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
6-7 Window 2 Vertical Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
</TD></TR></TABLE>
<BR>
<B>FB34h - IO_OSD_window_3_and_4_scale</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-1 Window 3 Horizontal Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
2-3 Window 3 Vertical Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
4-5 Window 4 Horizontal Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
6-7 Window 4 Vertical Scale (0=Normal, 1=Double, 2=Triple, 3=Quad)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
______________________________ Window Palette ______________________________
</TD></TR></TABLE>
<BR>
<B>FB36h+(#*2) - IO_OSD_bitmap_color_#_msb_B (#=0..15) (for 4bpp)</B><BR>
<B>FB37h+(#*2) - IO_OSD_bitmap_color_#_lsb_GR (#=0..15) (for 4bpp)</B><BR>
<B>FB56h/FB58h/FB5Ah/FB5Ch/FB5Eh/FB60h - IO_OSD_color_#_msb_B (#=1..6)</B><BR>
<B>FB57h/FB59h/FB5Bh/FB5Dh/FB5Fh/FB61h - IO_OSD_color_#_lsb_GR (#=1..6)</B><BR>
<B>N/A - IO_OSD_color_0: color 0 is fixed (transparent, aka AV video)</B><BR>
<B>N/A - IO_OSD_color_7: color 7 is fixed (black)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 Red (0-10) ;(11-15 are SAME as 10) ;\LSB (second byte) (!)
4-7 Green (0-10) ;(11-15 are SAME as 10) ;/
8-11 Blue (0-10) ;(11-15 are SAME as 10) ;\MSB (first byte) (!)
12-15 Not used (always 0) ;/
</TD></TR></TABLE>
Intensities 0Ah..0Fh are all max brightness (with default gamma setting,
08h/09h are also looking nearly identical to max brightness). At least that's
so at default configuration - not tested what happens when dividing the
intensities (via bright/semitransp features), maybe that results in cases like
0Fh/2 being brighter than 0Ch/2.<BR>
<BR>
<B>Transparent Color &amp; AV Video/Backdrop &amp; Overlapping Windows</B><BR>
For 1bpp characters, color 0 is always transparent. For 4bpp characters, color
0 transparency is optional (see port FB35h).<BR>
Transparent means displaying the AV Video Layer (or the backdrop if no AV
signal is present; the appearance of the backdrop can be changed via I/O ports
in the AV engine; eg. blue, black or other color, with or without snow effect).<BR>
In case of overlapping windows, window 0 is having highest priority. However,
any transparent pixels in the frontmost window are simply showing AV/Backdrop
(instead of drawing pixels from underlaying windows).<BR>
Moreover, half-overlapping windows are glitchy when their positions aren't
equally aligned to the font character width. Glitches are getting worse if the
overlapping windows are each using different scaling settings.<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ BGMAP Memory _______________________________
</TD></TR></TABLE>
<BR>
<B>FB00h - IO_OSD_bgmap_addr_lsb (lsb with internal auto-incrementing lsb)</B><BR>
<B>FB0Dh - IO_OSD_bgmap_addr_msb (msb fixed, need manual increment for msb)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 9bit BGMAP Address (0..1FFh) ;-LSB
8 Upper 1bit of 9bit BGMAP Address ;\MSB
9-15 Not used (always 0) ;/
</TD></TR></TABLE>
<BR>
<B>FB01h - IO_OSD_bgmap_data_lsb</B><BR>
<B>FB0Eh - IO_OSD_bgmap_data_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 10bit Character Number (0..3FFh) ;-LSB
8-9 Upper 2bit of 10bit Character Number (0..3FFh) ;\MSB
10-15 Not used (always 0) ;/
</TD></TR></TABLE>
<BR>
<B>FB10h - IO_OSD_bgmap_data_attr (for 1bpp tiles)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-2 Text Color (0=Transparent, 1..6=Variable, 7=Black)
3 ???
4-6 Background Color (0=Transparent, 1..6=Variable, 7=Black)
7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>BGMAP Memory</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
200h entries (each entry is 10bit character number plus 7bit attribute)
</TD></TR></TABLE>
<BR>
<B>Character Numbers</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
000h..1BFh Fixed ROM Font (1bpp, with color attributes)
1C0h..xxxh Custom RAM Font (1bpp, with color attributes)
xxxh..xxxh Custom RAM Font (4bpp, aka "16-color bitmap")
xxxh..3FFh Not useable (unless char height&lt;8) (due to font ram limit)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ FONT Memory ________________________________
</TD></TR></TABLE>
<BR>
<B>FB02h - IO_OSD_font_addr_lsb</B><BR>
<B>FB0Fh - IO_OSD_font_addr_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 12bit Font Address (0..FFFh) ;-LSB
8-11 Upper 4bit of 12bit Font Address ;\MSB
12-15 Not used (always 0) ;/
</TD></TR></TABLE>
Used for manual font writes (not used when DMA uploading FLASH-to-FONT).<BR>
<BR>
<B>FB03h - IO_OSD_font_data_lsb</B><BR>
<B>FB04h - IO_OSD_font_data_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 16bit Word (bit0=leftmost pixel) ;-LSB
8-15 Upper 8bit of 16bit Word ;-MSB
</TD></TR></TABLE>
Used for manual font writes (not used when DMA uploading FLASH-to-FONT).<BR>
<BR>
<B>FB76h - IO_OSD_char_xsiz</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-4 Horizontal Character Size in pixels (1..24) (25..32=glitchy) (0=32)
5-7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB77h - IO_OSD_char_ysiz</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-5 Vertical Character Size in pixels (1..32) (33..63=glitchy) (0=freeze)
6-7 Not used (always 0)
</TD></TR></TABLE>
<BR>
<B>FB11h - IO_OSD_bitmap_start_lsb</B><BR>
<B>FB70h - IO_OSD_bitmap_start_msb</B><BR>
Defines the first character number that is to be drawn at 4bpp color depth
(provided that 4bpp is enabled via FB05h.bit7). The value is originated at
character 1C0h (the first custom character).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Lower 8bit of 10bit Character Number (0..(3FFh-1C0h)) ;-LSB
8-9 Upper 2bit of 10bit Character Number (0..(3FFh-1C0h)) ;\MSB
10-15 Not used (always 0) ;/
</TD></TR></TABLE>
The actual first useable 4bpp character number varies depending on the
character width (because 4bpp char numbers are always addressing font memory as
wordaddr=char*ysiz). For example, using start=40h, and width&lt;=16:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1bpp characters = 1C0h..1FFh (40h characters)
4bpp characters = 200h and up
</TD></TR></TABLE>
However, at width&gt;16 some 4bpp chars will overlap the 1bpp font memory area:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1bpp characters = 1C0h..1FFh (40h characters)
4bpp garbage = 200h..21Fh (20h characters)
4bpp characters = 220h and up
</TD></TR></TABLE>
Note: The math for width&gt;16 gets yet more complex when char.ysiz=odd (when
1bpp tiles include a half unused word).<BR>
<BR>
<B>OSD ROM Font</B><BR>
The ROM font is 16x22 pixel, 1bpp. Smaller character sizes are causing cropped
ROM symbols (showing only the upper/left pixels). Bigger character sizes are
inserting additional character spacing. However height 32..63 is wrapping
within the tile bitmap (causing the rows to be displayed twice).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
000h Space
001h..00Ah Digits "0..9"
00Bh..024h Letters "A..Z" (uppercase only)
025h..02Bh Letters "ZSCNLZE" (with accent marks)
02Ch..04Ch Cyrillic Letters (in uncommon order)
02Dh..030h Symbols "&lt;", "&gt;", Arrow/TriangleLeft, Arrow/TriangleRight
031h..032h Symbols for Enter (left, right half)
033h..037h Symbols for Striped Bar (with 0,1,2,3,4 bars)
038h..039h Symbols for Double Arrows (Up+Down, and Right+Left)
03Ah..040h Symbols for Solid Bar (LeftEdge, 0,1,2,3,4 bars, RightEdge)
041h..042h Symbols for Sound or so (SpeakerX and "o))")
043h..0D3h Japanese and/or chinese or so
0D4h..0D5h Symbols for Alert (left, right half)
0D6h..105h Japanese and/or chinese and/or whatever or so
106h..10Bh Symbols for Contrast, Brightness, Palette (left, right halves)
10Ch "."
10Dh "'C"
10Eh..131h Japanese and/or chinese and/or whatever or so
132h..133h Symbol for HandWithFingerRight and ZigZagParagraph
134h ":"
135h "!"
136h "?"
137h..13Bh Symbols for Battery (0,1,2,3 bars, and right half)
13Ch..15Ch Letters "AAAAAAEEEEUUUUIIIIIOOOOOODNGZYYap" (with accent marks)
15Dh..15Fh Symbols for upper border ".---."
160h..164h Letters "zShoC" (with accent marks/variants)
165h..17Ah Japanese and/or chinese and/or dental or so
17Ch..17Dh Symbols for left/right border "|" and "|"
17Eh..197h Japanese and/or chinese and/or dental or so
198h..19Ah Symbols for lower border "'---'"
19Bh..19Eh Japanese and/or chinese and/or dental or so
19Fh Symbol for ClockfaceTrifoldYingYang or so
1A0h Overscore
1A1h Underscore "_" with clean line
1A2h Underscore "_" with noisy line
1A3h..1BFh Unused (solid 16x22pix rectangle's)
</TD></TR></TABLE>
<BR>
<B>Custom Font Memory (RAM)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1000h words (aka 2000h bytes, aka 8 Kbytes)
</TD></TR></TABLE>
<BR>
<B>1bpp font RAM addressing</B><BR>
For 1bpp font RAM addressing, the width is rounded up to 16bits (when
char.width&lt;=16), or to 24bits (when char.width&gt;16).<BR>
The size of each tile is Width (=rounded to 16bit or 24bit), multiplied by the
Height (variable size). The result is then rounded up to a multiple of 16bits
(ie. there'll be a trailing dummy byte in case of 24bit width with odd height).<BR>
The 1bpp tile bitmaps always consist of straight 16pix rows (plus patchwork for
width&gt;16). The pixels arranged as so:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1-8 9-16 17-24 25-31 32 ;&lt;-- pixels
msb(0) lsb(0) msb(ysiz+0) blank buggy ;1st row
msb(1) lsb(1) lsb(ysiz+0) blank buggy ;2nd row
msb(2) lsb(3) msb(ysiz+1) blank buggy ;3rd row
msb(3) lsb(3) lsb(ysiz+1) blank buggy ;etc.
</TD></TR></TABLE>
<BR>
<B>4bpp font RAM addressing</B><BR>
4bpp tileno's are simply addressing memory as "wordaddr=tileno*char.height"
(regardless of char.width). The number of words per 4bpp row is
"N=(char.width+3)/4", so one should use only each N'th tileno for 4bpp tiles
(unless one wants to use overlapping tiles).<BR>
The 4bpp tile bitmaps consist of N*4pix rows. The pixels arranged as so:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1-4 5-8 9-12 13-16 17-20 21-24 25-28 29-32
msb0 lsb0 msb1 lsb1 msb2 lsb2 msb3 lsb3 msb4 lsb4 msb5 lsb5 msb6 lsb6 buggy
</TD></TR></TABLE>
The next row starts with next msb (eg. with msb5 for width=17..20).<BR>
<BR>
<B>1bpp font ROM addressing</B><BR>
The tileno's for the ROM font are always addressing the corresponding ROM
character regardless of the current character width/height (showing only the
upper/left pixels when width/height is less than 16x22, and adding extra blank
space when above 16x22).<BR>
<BR>
<B>Font Write Glitches</B><BR>
Writes to FONT memory can be glitchy (if the write occurs simultaneously when
rendering a tile; statistically that's most likely for 4bpp with 1pix width,
which have the most vram traffic, but the glitch seems to happen at other
width's sometimes too).<BR>
Workaround would be to disable all windows before FONT writes (and use some
DELAY after window-disable, which is apparently taking no effect until next
frame or so) (the SFR_IO_memory_system flag for DMA-FONT writes does NOT work
for manual FONT writes, instead, it does totally screw up such writes).<BR>
Unknown if font writes are more reliable during vblank (see irq flag in SFR
91h).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_________________________BGMAP+FONT Memory Notes __________________________
</TD></TR></TABLE>
<BR>
<B>Data Write &amp; Address Increment</B><BR>
The "addr_lsb" registers are auto-incrementing when writing to "data_lsb" (or
"data_attr"). However, there is no carry-out to "addr_msb", so the msb must be
written manually upon lsb-overflows. Another oddity is that reading "addr_lsb"
does return the must recently written value (not the internally
auto-incremented value; for bgmap, there are separate internal
auto-incrementing addr_lsb's for data and attr writes, so the auto-increments
don't disturb each other).<BR>
Writes to "data_msb" register are just latching the written value (without
forwarding it to vram). Writes to "data_lsb" are forwarding the LSB and MSB to
vram. When zero-filling memory, one needs to write MSB only once, and can then
write LSB several times. For fonts with 8pix width, the pixels are located in
MSB only (but one still needs dummy LSB writes to get the MSBs forwared to
vram).<BR>
<BR>
<B>Memory Restrictions</B><BR>
The OSD is focusing on "on-screen-display", but it's a bit short of memory for
"full-screen display" purposes. Making use of the whole Font, Bgmap memory and
all character numbers works only with well-balanced character sizes (for
example, 16x8 pixels).<BR>
Nethertheless, with a 320x240 pixel display, the following is allowing to
display a near-fullscreen bitmap, using nearly all memory:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
20x25 tiles bgmap, 16x8 pixel tiles at 1bpp = 320x200 pixels
</TD></TR></TABLE>
when manually drawing text pixels, the above could be also used for stuff like
40x25 tiles at 8x8 pixels (though sharing the same color attribute for each two
characters).<BR>
The 16-color mode requires 4x more font memory per pixel, thus allowing use
only about of a quarter of the screen (unless one would scale a low-res 160x100
pixel bitmap to a 320x200 pixel region).<BR>
<BR>
<B>Absent Memory Read Support</B><BR>
There's no known way to read bgmap/font memory (trying to read the data
registers merely returns the most recently written value).<BR>
The absent read-support can be problematic for bitmap graphics (drawing a pixel
will destroy the other pixels within the same word, unless you still know the
value of the old pixels).<BR>
Unless... maybe there are separate "data-read" registers somewhere, or some
kind of "strobe to read" registers?<BR>
<BR>
<B>DMA Transfers</B><BR>
Apart from manually writing font data, one can also DMA transfer data from
SPI/FLASH to FONT memory. Doing so is slightly faster, and allows to use higher
FLASH addresses (exceeding the MOVC opcode's 16bit address space).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ Unknown Registers ____________________________
</TD></TR></TABLE>
<BR>
Below registers are unknown and seem to have no visible effect. Maybe some of
them are for the "OSD blink/highlight" feature which is said to be supported
"for THREE windows"... and which might become visible only if certain window(s)
are displayed, with certain attribute bit(s), and certain blink-timing
settings, and certain blink-enable flags... or whatever.<BR>
<BR>
<B>FB2Ah - Unknown (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FB2Ah - bit7:NOT R/W
</TD></TR></TABLE>
<BR>
<B>FB63h-FB6Fh - Unknown (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FB63h - fully R/W
FB64h - fully R/W
FB65h - fully R/W
FB66h - fully R/W
FB67h - bit7:NOT R/W
FB68h - fully R/W
FB69h - fully R/W
FB6Ah - bit7:NOT R/W
FB6Bh - fully R/W
FB6Ch - fully R/W
FB6Dh - fully R/W
FB6Eh - fully R/W
FB6Fh - fully R/W
</TD></TR></TABLE>
<BR>
<B>FB71h-FB75h - Unknown (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FB71h - bit1-7:NOT R/W
FB72h - fully R/W
FB73h - fully R/W
FB74h - fully R/W
FB75h - fully R/W
</TD></TR></TABLE>
<BR>
<B>FB79h-FB88h - Unknown (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FB79h - bit6-7:NOT R/W
FB7Ah - bit6-7:NOT R/W
FB7Bh - bit7:NOT R/W
FB7Ch - bit7:NOT R/W
FB7Dh - bit4-7:NOT R/W
FB7Eh - bit6-7:NOT R/W
FB7Fh - bit6-7:NOT R/W
FB80h - bit6-7:NOT R/W
FB81h - bit7:NOT R/W
FB82h - bit7:NOT R/W
FB83h - bit4-7:NOT R/W
FB84h - bit6-7:NOT R/W
FB85h - bit6-7:NOT R/W
FB86h - bit6-7:NOT R/W
FB87h - bit7:NOT R/W
FB88h - bit7:NOT R/W
</TD></TR></TABLE>
<BR>
<B>FB8Ah..FBFFh - Unused (open-bus)</B><BR>
These registers appear to be unused (not write-able, always returning FFh on
reading).<BR>
<BR>
<B>FBC6h - Unused (open-bus), or IO_OSD_bugged_color_lsb</B><BR>
<B>FBC7h - Unused (open-bus), or IO_OSD_bugged_color_msb</B><BR>
For some reason (maybe by mistake), the firmware is writing some RGB color
value to FBC6h/FBC7h, oddly done in LSB-first order (unlike the other RGB color
registers), and more oddly with y-flipped tiles, but without visible color
changes on the OSD picture, and without allowing to readback the written value
(so FBC6h/FBC7h are either write-only, or, more likely, they don't exist at
all).<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630afcxxhlcdregistersmostly50hz60hzratio"></A>&nbsp;
AMT630A - FCxxh - LCD Registers (mostly 50Hz/60Hz/Ratio)
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
______________________ 60Hz/NTSC and 50Hz/PAL Registers ______________________
</TD></TR></TABLE>
<BR>
Registers below exist at separate addresses for 60Hz/NTSC and 50Hz/PAL,<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FC91h..FCB6h - IO_60HZ_xxx : used for 60Hz/NTSC (also used for 60Hz/PAL60)
FCBDh..FCE2h - IO_50HZ_xxx : used for 50Hz/PAL (and probably 50Hz/SECAM)
</TD></TR></TABLE>
<BR>
<B>FC91h/FCBDh - IO_60HZ/50HZ_control_lsb ;(should be set to 01h) ;PAL: bit4=?</B><BR>
<B>FC92h/FCBEh - IO_60HZ/50HZ_control_mid ;(should be set to 00h) ;NTSC: bit12=?</B><BR>
<B>FC93h/FCBFh - IO_60HZ/50HZ_control_msb ;(should be set to 00h)</B><BR>
The firmware initializes these registers to 24bit value 000001h (and does
somewhat oddly change NTSC/bit12 and PAL/bit4 in some situation).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1 Move Whole Image ca.80pix LEFT
3 AV Black/Off
5 Weird Diagonal/striped AV Image (ignoreHsync?),
6 PAL: MoveWholeImageCa.12pixDOWN
6 PAL60: ContrastOnPAL60colorError
6 C64: shows SNOW with downwards rolling VSYNC from C64)
8 AV Edgy/Diagonal Color Error,
8 C64: shows SNOW with upwards rolling VSYNC from C64)
11 PAL: AV diagonally messed (ignoredHsync?)
11 PAL60: AV_MOSTLY_BLACK_except_right_edge_and_lowerleft_corner
18 PAL: MoveWholeImageCa.160pixLEFT,
18 PAL60: MoveWholeImageCa.80pixRIGHT,
19 PAL: MoveWholeImageCa.32pixDOWNandWeakPixels
19 PAL60: ContrastOnPAL60colorError
</TD></TR></TABLE>
BUG: The firmware changes PAL/bit4 and NTSC/bit12 (done in response to bit0 of
IO_AV_stat_detect_1), there might be some reason for changing different bits
for PAL and NTSC, but probably it did want to change either bit4 or bit12 in
both cases (neither of those bits has any visible effect though) (alongsides,
it's also changing FCB6h/FCE2h, which is having a more visible effect on
boldness).<BR>
<BR>
<B>FC98h/FCC4h - IO_60HZ/50HZ_15khz_lsb ;fixed (C8h/66h)</B><BR>
<B>FC99h/FCC5h - IO_60HZ/50HZ_15khz_msb ;fixed (03h/04h)</B><BR>
<B>FC9Ah/FCC6h - IO_60HZ/50HZ_15khz_div2_lsb ;fixed (E3h/36h)</B><BR>
<B>FC9Bh/FCC7h - IO_60HZ/50HZ_15khz_div2_msb ;fixed (01h/02h)</B><BR>
These seem to somehow define the expected 15kHz scanline rate (which is
slightly different for PAL and NTSC). The "div2" value should be approximately
half of the other value. The firmware uses the following fixed values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60Hz/NTSC: 03C8h,01E3h (aka decimal 968,483)
50Hz/PAL: 0466h,0236h (aka decimal 1126,566)
</TD></TR></TABLE>
BUG: The 60Hz/NTSC value doesn't match for PAL60 (causing the display to
forcefully insert memorized/old scanlines at random locations in bottom half of
the screen; this can be fixed (eg. change 03C8h to 03C0h, or 01E3h to 01E2h;
even then, the PAL60 colors are still decoded as NTSC though).<BR>
<BR>
<B>FC9Ch/FCC8h - IO_60HZ/50HZ_xloc_av_osd_lsb ;fixed (00h/02h)</B><BR>
<B>FC9Dh/FCC9h - IO_60HZ/50HZ_xloc_av_osd_msb ;fixed (00h/00h)</B><BR>
<B>FC9Eh/FCCAh - IO_60HZ/50HZ_xloc_osd_lsb ;fixed (44h/36h)</B><BR>
<B>FC9Fh/FCCBh - IO_60HZ/50HZ_xloc_osd_msb ;fixed (00h/00h)</B><BR>
<B>FCA0h/FCCCh - IO_60HZ/50HZ_xloc_av_lsb ;fixed (43h/43h)</B><BR>
<B>FCA1h/FCCDh - IO_60HZ/50HZ_xloc_av_msb ;fixed (00h/00h)</B><BR>
<B>FCACh/FCD8h - IO_60HZ/50HZ_ratio_xloc_av_8bit ;fixed (10h/06h)</B><BR>
Allows to change the horizontal position of both AV+OSD layer, or only AV
layer, or only OSD layer. The firmware uses the following fixed values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60Hz/NTSC: both=0000h, osd=0044h, av=0043h, ratio=10h (or unused:1Dh)
50Hz/PAL: both=0002h, osd=0036h, av=0043h, ratio=06h (or unused:0Ch)
</TD></TR></TABLE>
BUG: With the firmware values, the OSD layer appears at different horizontal
locations depending on whether receiving a NTSC or PAL signal.<BR>
Note: Setting "av_osd" or "osd" to too large values causes TFT screen to
freeze.<BR>
Note: Changing the "ratio" value may produce GARBAGE after the scanline end.
The firmware contains tables with several used (unused) "ratio" values (used
are 10h/06h, and whatever unused values would be 1Dh/0Ch).<BR>
<BR>
<B>FCA2h/FCCEh - IO_60HZ/50HZ_xcrop_end_av_lsb ;fixed (8Ah/92h)</B><BR>
<B>FCA3h/FCCFh - IO_60HZ/50HZ_xcrop_end_av_msb ;fixed (01h/01h)</B><BR>
<B>FCA8h/FCD4h - IO_60HZ/50HZ_ycrop_upper_av_lsb ;fixed (10h/0Ch)</B><BR>
<B>FCA9h/FCD5h - IO_60HZ/50HZ_ycrop_upper_av_msb ;fixed (00h/00h)</B><BR>
<B>FCAFh/FCDBh - IO_60HZ/50HZ_ratio_ycrop_upper_av_8bit ;fixed (00h)</B><BR>
<B>FCB0h/FCDCh - IO_60HZ/50HZ_ratio_ycrop_lower_av_8bit ;fixed (00h)</B><BR>
Allows to crop the upper/lower/right areas of the AV layer (causing it to get
black, OSD isn't affected). The firmware uses the following fixed values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60Hz/NTSC: x=018Ah, y=0010h, ratio/upper=00h, ratio/lower=00h
50Hz/PAL: x=0192h, y=000Ch, ratio/upper=00h, ratio/lower=00h
</TD></TR></TABLE>
For the "ratio" values, the firmware contains tables for six ratios for PAL and
NTSC each... but those tables are just containing 00h crop values for all
ratios.<BR>
<BR>
<B>FCA4h/FCD0h - IO_60HZ/50HZ_yloc_av_osd_lsb ;fixed (07h/08h)</B><BR>
<B>FCA5h/FCD1h - IO_60HZ/50HZ_yloc_av_osd_msb ;fixed (00h/00h)</B><BR>
<B>FCA6h/FCD2h - IO_60HZ/50HZ_yloc_osd_lsb ;fixed (09h/09h)</B><BR>
<B>FCA7h/FCD3h - IO_60HZ/50HZ_yloc_osd_msb ;fixed (00h/00h)</B><BR>
Allows to change the vertical position of AV+OSD layer, or only OSD layer. The
firmware uses the following fixed values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60Hz/NTSC: both=0007h, osd=0009h
50Hz/PAL: both=0008h, osd=0009h
</TD></TR></TABLE>
Note: Setting "av_osd" to too large values causes TFT screen to draw single
scanline repeated all over the screen. Too large "av" value causes the AV layer
to get offscreen (and AV area will be drawn as black).<BR>
<BR>
<B>FCAAh/FCD6h - IO_60HZ/50HZ_heavy_flimmer_lsb ;fixed (10h/0Fh)</B><BR>
<B>FCABh/FCD7h - IO_60HZ/50HZ_heavy_flimmer_msb ;fixed (01h/01h)</B><BR>
Whatever, causes heavy flimmering when set to wrong values. The firmware uses
the following fixed values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
60Hz/NTSC: 0110h
50Hz/PAL: 010Fh
</TD></TR></TABLE>
Maybe forces vblank duration, large values cause screen to blink black.<BR>
<BR>
<B>FCB6h/FCE2h - IO_60HZ/50HZ_boldness_contrast ;initially(02h) ;bit2-7 NOT R/W</B><BR>
The firmware does initially set these registers to 02h, but may later change
them to 00h or 02h (in response to bit0 of IO_AV_stat_detect_1).<BR>
For PAL pictures, bit1 affects boldness, and bit0 has no visible effect. For
bugged PAL60 color errors, bit0-1 are somewhat changing the contrast of the
color error.<BR>
<BR>
<B>FC96h/FCC2h - IO_60HZ/50HZ_ratio_whatever_A_lsb ;(61h,7Eh,5Bh/5Ch,84h,63h)</B><BR>
<B>FC97h/FCC3h - IO_60HZ/50HZ_ratio_whatever_A_msb ;(08h,08h,03h/08h,08h,03h)</B><BR>
<B>FCADh/FCD9h - IO_60HZ/50HZ_ratio_whatever_B_lsb ;(00h,00h,09h/00h,00h,06h)</B><BR>
<B>FCAEh/FCDAh - IO_60HZ/50HZ_ratio_whatever_B_msb ;(00h,00h,00h/00h,00h,00h)</B><BR>
Unknown, these registers seem to have no visible effect. The firmware uses
following fixed values, depending on screen ratio:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
NTSC at "16:9" A=0861h, B=0000h
NTSC at "4:3" A=087Eh, B=0000h
NTSC at (unused) A=035Bh, B=0009h
PAL at "16:9" A=085Ch, B=0000h
PAL at "4:3" A=0884h, B=0000h
PAL at (unused) A=0363h, B=0006h
</TD></TR></TABLE>
Whereof, a "4:3" display defaults to using the "16:9" values (not the "4:3"
values).<BR>
<BR>
<B>FC94h/FCC0h - IO_60HZ/50HZ_internal_unused1 (00h) ;</B><BR>
<B>FC95h/FCC1h - IO_60HZ/50HZ_internal_unused2 (00h) ;</B><BR>
<B>FCB1h/FCDDh - IO_60HZ/50HZ_internal_unused3 (14h) ;bit5-7:NOT RW</B><BR>
<B>FCB2h/FCDEh - IO_60HZ/50HZ_internal_unused4 (00h) ;</B><BR>
<B>FCB3h/FCDFh - IO_60HZ/50HZ_internal_unused5 (00h) ;</B><BR>
<B>FCB4h/FCE0h - IO_60HZ/50HZ_internal_unused6 (00h) ;bit2-7:NOT RW</B><BR>
<B>FCB5h/FCF1h - IO_60HZ/50HZ_internal_unused7 (00h) ;bit7:PAL60 minimal effect?</B><BR>
Not used by older firmware. Newer firmware does initialize them (but just using
same values as they are having on power-up anyways). No visible effect (aside
from FCB5h.bit7 slightly affecting PAL60 color errors... the error somewhat
getting moved downwards a bit).<BR>
<BR>
<B>Screen Ratio Notes (4:3 or 16:9)...</B><BR>
The seven "ratio" registers exist for 60Hz and 50Hz each (ie. 14 registers in
total), and their values depend on the selected screen ratio (4:3 or 16:9). Not
quite clear if/how that's working:<BR>
My firmware has some tables with six different values for each register. Of
those six values, the first two values seem to be associated with 16:9 and 4:3
(and the other four values are unused). Since having a 4:3 display, my firmware
is using only one of the aforementioned two values (whereof, it is, oddly,
using the 16:9 value (not the 4:3 value) for my 4:3 display).<BR>
Maybe that's implemented somewhat differently on 16:9 displays with actual
screen ratio options in the user interface.<BR>
Also unknown, WHAT that ratio option is supposed to do: Maybe always stretching
any picture to the full screen width, or maybe doing so only when receiving
certain wide-screen movie signals, or whatever?<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_________________________ General Control Registers _________________________
</TD></TR></TABLE>
<BR>
<B>FC90h - IO_VIDEO_control ;(should be set to 02h)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 On PAL50: causes VerticalScale (force NTSC resolution?),
bit5 Swap AV colors Red &amp; Blue
bit7 MinorEffectOnRightScreenEdge
</TD></TR></TABLE>
<BR>
<B>FC00h - IO_LCD_color_swap (should be set to 05h)</B><BR>
The firmware initializes this register to fixed value. Changing bit0-3 does
somehow "swap" colors.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 Color swap for AV and OSD (ie. LCD databus mode)
4-7 Unknown, no visible effect on PAL+PAL60 image
</TD></TR></TABLE>
<BR>
<B>FCB7h - IO_VIDEO_something_1_lsb (should be set to 16h)</B><BR>
<B>FCB8h - IO_VIDEO_something_1_msb (should be set to 01h)</B><BR>
<B>FCBBh - IO_VIDEO_something_2_lsb (should be set to 1Ch)</B><BR>
<B>FCBCh - IO_VIDEO_something_2_msb (should be set to 01h)</B><BR>
<B>FCE3h - IO_VIDEO_something_3 (should be set to 01h) ;-bit1-2: AV v-position</B><BR>
<B>FCE4h - IO_VIDEO_something_4 (should be set to 45h) ;-bit4: AV h-position</B><BR>
The firmware initializes these registers to fixed values. For whatever reason
it's also ORing [FCE4h] by 40h (done so before switching between 16:9 and 4:3
screen ratio, despite of it containing 45h anyways).<BR>
<BR>
<B>FCEAh - IO_VIDEO_something_5 ;NOT R/W... but firmware writes to it!</B><BR>
Whatever. Looks unused/read-only (always reads FFh), but the firmware writes
00h to this register (within Timer 1 IRQ handler, and after switching between
16:9 and 4:3 screen ratio). Maybe the firmware write is doing some write-only
acknowledge, or maybe it's just a bug.<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
__________________________ More Internal Registers __________________________
</TD></TR></TABLE>
<BR>
<B>FCE5h - whatever_status ;NOT R/W ;(always 36h ?)</B><BR>
<B>FCE6h - whatever_status ;NOT R/W ;(always 02h ?)</B><BR>
Not used by firmware. The two bytes seems to be always 36h and 02h (with SNES
PAL, with C64, and also without AV signal).<BR>
<BR>
<B>FCE7h - whatever ;bit2=R/W! ;other seven bits:NOT R/W (01h)</B><BR>
Not used by firmware. Contains mixed R and R/W bits.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Unknown, read-only (1)
1 Unknown, read-only (zero)
2 Unknown, read/write-able (usually zero, no visible effect when changed)
3-7 Unknown, read-only (zero)
</TD></TR></TABLE>
<BR>
<B>FCE8h - whatever_status_msb ;NOT R/W</B><BR>
<B>FCE9h - whatever_status_lsb ;NOT R/W</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
with PSX/PAL: toggles 11Dh/11Eh
with Commodore C64 toggles 11Bh/11Ch
with ZX Spectrum toggles 11Ch/11Dh
with SNES/PAL: toggles 11Ch/11Dh
with SNES/PAL60: toggles 117h/118h (and has BlackWhiteDither/wrong color)
without signal increasing 0..1xxh
</TD></TR></TABLE>
Not used by firmware.<BR>
<BR>
<B>FC01h - whatever ;no effect on PAL picture?</B><BR>
<B>FC02h - whatever ;bit0,1,2:kills AV image, bit3-7: NOT R/W</B><BR>
Not used by firmware.<BR>
<BR>
<B>FC03h..FC10h - whatever, 0Eh bytes, not used by firmware, no visible effect</B><BR>
<B>FC12h..FC46h - whatever, 35h bytes, not used by firmware, no visible effect</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FC09h.bit5-7:NOT RW ;-
FC0Dh.bit6-7:NOT RW ;-
FC0Fh.bit6-7:NOT RW ;-
FC13h.bit4-7:NOT RW ;-
FC19h.bit3-7:NOT RW ;\
FC1Bh.bit3-7:NOT RW ;
FC1Dh.bit3-7:NOT RW ;
FC1Fh.bit3-7:NOT RW ;
FC21h.bit3-7:NOT RW ;
FC23h.bit3-7:NOT RW ;
FC25h.bit3-7:NOT RW ;
FC27h.bit3-7:NOT RW ;
FC29h.bit3-7:NOT RW ;
FC2Bh.bit3-7:NOT RW ;
FC2Dh.bit3-7:NOT RW ;
FC2Fh.bit3-7:NOT RW ;/
FC31h.bit2-7:NOT RW ;\
FC33h.bit2-7:NOT RW ;/
FC44h.bit4-7:NOT RW ;-
FC46h.bit6-7:NOT RW ;-
</TD></TR></TABLE>
<BR>
<B>FC11h - Unused (open-bus) (1 byte)</B><BR>
<B>FC47h..FC8Fh - Unused (open-bus) (49h bytes)</B><BR>
<B>FCB9h..FCBAh - Unused (open-bus) (02h bytes)</B><BR>
<B>FCEBh..FCFFh - Unused (open-bus) (15h bytes)</B><BR>
Probably unused I/O addresses.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630afdxxhmiscregisterspwmadcpllpinspiflash"></A>&nbsp;
AMT630A - FDxxh - Misc Registers (PWM,ADC,PLL,PIN,SPI-FLASH)
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ PWM Registers _______________________________
</TD></TR></TABLE>
<BR>
PWM0 is wired to the backlight voltage generator. However, the original
firmware fails to use the PWM feature; instead, it's simply switching the pin
to always HIGH, resulting in a painfully bright image, and huge waste of
energy. Using duty 50% (with total=1000h and high=0800h) does produce more
moderate brightness, and does greatly reduce power consumption. Measured at 5V
power line:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
PWM Duty Whole System -- Backlight Part
duty 100% (aka HIGH) = 290mA (1.45W) -- 234mA (1.17W)
duty 50% = 65mA (0.33W) -- 9mA (0.05W)
duty 0% (aka LOW) = 56mA (0.28W) -- 0mA (0W)
</TD></TR></TABLE>
Note: The backlight doesn't work with too small total values (eg. backlight
stays off at total=0100h and high=0080h).<BR>
<BR>
<B>FD1Fh - IO_PWM_enable_flags</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 PWM0 Enable (0=Disable, 1=Enable) ;LCD Backlight
1 PWM1 Enable (0=Disable, 1=Enable) ;LCD Config, SPI.DTA
2 PWM2 Enable (0=Disable, 1=Enable) ;LCD Config, SPI.CLK and SPI./RESET
3 PWM3 Enable (0=Disable, 1=Enable) ;LCD Config, SPI./CS
4-7 PWM0..3 Invert Flags (0=Normal/Duty=HIGH, 1=Invert/Duty=LOW)
</TD></TR></TABLE>
Aside from the enable bits, one will also need to switch the pins to PWM mode
(via IO_PIN_xxx), and also configure the MODE_A/B bits in SFR registers.<BR>
<BR>
<B>FD20h/FD22h/FD24h/FD26h - IO_PWM#_duty_total_lsb (#=0..3)</B><BR>
<B>FD21h/FD23h/FD25h/FD27h - IO_PWM#_duty_total_msb (#=0..3)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-15 Total Duty, in 26MHz cycles (for HIGH and LOW periods)
</TD></TR></TABLE>
<BR>
<B>FD28h/FD2Ah/FD2Ch/FD2Eh - IO_PWM#_duty_high_lsb (#=0..3)</B><BR>
<B>FD29h/FD2Bh/FD2Dh/FD2Fh - IO_PWM#_duty_high_msb (#=0..3)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-15 Duty HIGH, in 26MHz cycles (for HIGH period) (or LOW when inverted)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ ADC Registers _______________________________
</TD></TR></TABLE>
<BR>
ADC Channel 0 is used for Keyboard input, the keypads consist of several
buttons with different resistors (allowing to access multiple buttons via a
2-wire cable). The most common keypad seems to be the "3KEY" keypad with three
buttons, using these ADC values:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
04F0h..05BFh (avg=0564h) ;1.0K ohm (button +) (used as Up/Right)
07A0h..086Fh (avg=0804h) ;2.0K ohm (button menu) (Menu)
0AD0h..0B9Fh (avg=0B38h) ;4.7K ohm (button -) (used as Down/Left)
</TD></TR></TABLE>
Further possible values (not supported by original firmware) would be:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0300h..03D7h (avg=03A5h) ;Menu+Plus+Minus
03D8h..046Fh (avg=040Bh) ;Menu+Plus
0450h..04EFh (avg=04B4h) ;Plus+Minus
0650h..06FFh (avg=06A1h) ;Menu+Minus
0FA0h..0FFFh (avg=0FF5h) ;(when no button pressed)
xxxxh ;(invalid, might happen on transitions)
</TD></TR></TABLE>
CAUTION: Above is for a 3.5" display. Whilst, for 4.3" displays, Plus and Minus
are swapped (ie. the same 3KEY board seems to be mounted the other way around,
probably due to different case design for 4.3" screens).<BR>
Sensing multiple simultaneously pressed buttons is possible, though not too
recommended (first of, it's difficult to press more than one of the tiny
buttons, and, some values are a bit close together which might cause
misreadings in case values differ due to resistor tolerance or temperature).<BR>
Unlike digital signals (which are always 0 or 1), analog signals might
transition through nonsense values when pushing/releasing buttons; to avoid
such problems read more than one ADC value, and then check that at least two
continous readings are reflecting the same button, or, check that at least half
of the last some readings are reflecting the same button(s), the latter method
should also work for multiple buttons, including cases like one button being
held down while another button is changing.<BR>
Note: The firmware contains definitions for 23 different keypads (some having
only 2 buttons, others having up to 7 buttons, including "hotkeys" for volume
up/down, manual power/standby, etc., and some using buttons with ADC value
0FFFh, so those are apparently wired with VCC/GND swapped).<BR>
Further alternate inputs would be IR remote controls (though unknown how to
handle to wire that to the board, and unknown how to use RC-5 protocol;
currently only the messy NEC protocol is known), and, another "standard" input
(unintended by the manufacturer) would be a serial mouse on the UART port.
Other than that, one could brew-up any kind of nonstandard stuff for ps/2
keyboards, gamepads, digital joysticks, analog joysticks, or whatever. Some
display include unused touch screen membranes (or they did so, but were removed
with scissors, as seen on bigby's photo), but connecting the four touch screen
signals to the two spare ADC inputs would require some analog multiplexing.<BR>
<BR>
<B>FDB0h - IO_ADC_ctrl_lsb</B><BR>
<B>FDB1h - IO_ADC_ctrl_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Unknown (initially set to 0, this bit isn't R/W though) (R) or (W)?
1-2 Unknown (initially set to 0, hangs ADC when setting bit1 or bit2)
3 Channel 0 Run ;\firmware sets ONE of these bits on conversion start
4 Channel 1 Run ; (and clears the other three bits)
5 Channel 2 Run ; (required to be "1", ie. start/enable?)
6 Unknown VCOM? ;/
7 Unknown (initially set to 0)
8-11 Unknown (initially set to 1111b) (not required, can be 0)
12 Unknown VCOM? ;\firmware sets ONE of these bits on conversion start
13 Channel 0 ; (and clears the other three bits)
14 Channel 1 ; (not required to be "1", can be "0")
15 Channel 2 ;/
</TD></TR></TABLE>
Firmware does rewrite bit3-6 and bit12-15 upon each conversion start, however,
actually that's required only once (and hardware will then repeatedly throw new
ADC conversion results).<BR>
Bit8-11 and Bit12-15 might select some per channel mode, maybe channel
priority, maybe reference voltage, or maybe speed select (in case FDC8h and
FDCAh are alternate speed's)?<BR>
ADC hangs if bit8-11 AND bit12-15 are BOTH zero (but works if either one (or
both) of them is nonzero).<BR>
<BR>
<B>FDB8h - IO_ADC_status_lsb (Read-only, except: Write 0 to ack)</B><BR>
<B>FDB9h - IO_ADC_status_msb (Read-only, except: Write 0 to ack)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-1 Unknown, maybe channel 0 related
2 Channel 0 Ready (0=Busy, 1=Ready)
3-4 Unknown, maybe channel 1 related
5 Channel 1 Ready (0=Busy, 1=Ready)
6-7 Unknown, maybe channel 2 related
8 Channel 2 Ready (0=Busy, 1=Ready)
9-10 Unknown, maybe channel VCOM? related
11 Channel VCOM? Ready (0=Busy, 1=Ready)
12-15 Unknown
</TD></TR></TABLE>
<BR>
<B>FDB6h - IO_ADC_config_4 - should be set to FFh ;&lt;-- as so disables ADC IRQs?</B><BR>
<B>FDB7h - IO_ADC_config_5 - should be set to FFh</B><BR>
Firmware sets these to FFh. Maybe IRQ Disable flags corresponding to bits in
IO_ADC_status registers, ie. bit0-2 for channel 0, and so on?<BR>
<BR>
<B>FDBCh/FDBEh/FDC0h - IO_ADC_input_#_lsb (#=0,1,2) (R)</B><BR>
<B>FDBDh/FDBFh/FDC1h - IO_ADC_input_#_msb (#=0,1,2) (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-11 Conversion result (0..FFFh)
12-15 Always 0 (assuming ADC cannot be configured to more than 12bit)
</TD></TR></TABLE>
<BR>
<B>FDB2h - IO_ADC_config_1 - should be set to 20h ;DANGER:bit1 ;bit6-7:NOT R/W</B><BR>
<B>FDB4h - IO_ADC_config_2 - should be set to 22h ;DANGER:bit7</B><BR>
<B>FDB5h - IO_ADC_config_3 - should be set to 37h ;DANGER:bit0-1</B><BR>
<B>FDC8h - IO_ADC_config_6 - should be set to FFh ;\maybe another speed?</B><BR>
<B>FDC9h - IO_ADC_config_7 - should be set to 0Fh ;/maybe for VCOM?</B><BR>
<B>FDCAh - IO_ADC_config_8 - should be set to 00h</B><BR>
The firmware initializes these to fixed values. Changing some of those bits can
hang the ADC (see DANGER bits).<BR>
<BR>
<B>FDCCh - IO_ADC_speed_lsb - should be set to FFh</B><BR>
<B>FDCDh - IO_ADC_speed_msb - should be set to 0Fh ;upper bits make ADC slower</B><BR>
ADC Conversion speed, firmware sets this to 0FFFh (4095), and alongsides sets
IO_PLL_adc_clk_divider to 18h (24). With that values, the conversion rate is
around 137Hz (apparently computed as 27MHz/4095/24/2).<BR>
<BR>
<B>FDB3h - whatever ADC related status, 1 byte (R)</B><BR>
<B>FDBAh..FDBBh - whatever ADC related status, 2 bytes (R) maybe VCOM result?</B><BR>
<B>FDC2h..FDC7h - whatever ADC related status, 6 bytes (R)</B><BR>
<B>FDCBh - whatever ADC related status, 1 byte (R)</B><BR>
Whatever, not used by firmware, not read/write-able. Reading these registers
always seems to return 00h.<BR>
<BR>
<B>FDCEh - whatever ADC related control/status (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-6 Unknown, read-only (contains value 1Fh) (R)
7 Unknown, read/write-able (R/W)
</TD></TR></TABLE>
<BR>
<B>FDCFh - whatever ADC related control (not unused by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 Unknown (R/W)
4-7 Unused (not R/W)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ SPI FLASH Registers ____________________________
</TD></TR></TABLE>
<BR>
<B>FDD0h - IO_SPI_transfer_mode</B><BR>
Set ONE bit (used: 04h,08h,10h,40h,80h) ;DANGER<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
01h = Manual read JEDEC Chip ID
02h = Manual read Write-Protect-Status
04h = Manual write Write-Protect-Status
08h = Manual send FLASH command (used for WREN and ERASE)
10h = Manual read FLASH-to-CPU
20h = unknown (not used by firmware)
40h = DMA read FLASH-to-FONT
80h = DMA write XRAM-to-FLASH (max 100h bytes at once)
</TD></TR></TABLE>
Note: For FLASH-to-FONT, one should disable font rendering via
SFR_IO_memory_system during DMA (the OSD will then draw all windows as if FONT
memory were zerofilled, eg. using the BGMAP's BG attr color for 1bpp windows).<BR>
Note: FLASH must be erased (in 1000h-byte units) before writing, writing from
XRAM is restriced to 100h-byte pages (and also to 800h-byte XRAM size), but,
one can erase 1000h bytes, and then write sixteen 100h-byte snippets.<BR>
<BR>
<B>FDD1h - IO_SPI_wprot_stat_write</B><BR>
Allows to change the nonvolatile write-protect bits in the FLASH chip's status
register. The firmware is taking excessive use of this register: Instead of
leaving the firmware block permanently protected (via value 24h), it's changing
the write protect status before &amp; after each write (meaning that the status
bits will get worn out long before the actual data sectors get worn out, and
also meaning that accidental jumps to the write function will automatically
unlock writing).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 BUSY Busy (should be 0)
1 WEL Write Enable Latch (should be 0)
2-4 BP0-2 Number of 64Kbyte Blocks to protect (0=none, 1..7=see below)
5 TB Protect Top/Bottom Blocks (0=Top, 1=Bottom)
6 - Reserved (should be 0)
7 SRP Status Register Protect when /WP=LOW (0=No, 1=Protect if /WP=LOW)
</TD></TR></TABLE>
The BP bits allow to specify the amount of write-protected blocks (either at
top or bottom addresses, depending on the TB bit) (if the amount of blocks is
same or bigger than the chipsize, the ALL blocks are protected, and TB bit is
don't care).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
BP=00h Protect nothing (unlock all blocks)
BP=01h Protect 1 block (64Kbytes)
BP=02h Protect 2 blocks (128Kbytes)
BP=03h Protect 4 blocks (256Kbytes)
BP=04h..07h Same as 00h..03h ;-on W25D10/W25D20
BP=04h Protect 8 blocks (512Kbytes) ;\on W25D40/W25D80
BP=05h..07h Protect all blocks (1024Kbytes) ;/
</TD></TR></TABLE>
The older firmware uses a hardcoded protection value of 0Ch (locking ALL blocks
on W25D10/W25D20, but accidentally locking only the UPPER some blocks on
W25D40, whereas, my board WAS shipped with a 25D40 chip).<BR>
The newer firmware tries to leave the firmware block always protected (unless
the settings are stored in the same block, which is actually happening due to a
bug in the firmware's chip detection).<BR>
NOTE: The MK 25D40 identifies itself with same chip ID as W25D40... but it
doesn't seem to allow to set the TB flag in bit5, unknown if/how protection
works on that chip (except, protecting ALL blocks seems to work).<BR>
<BR>
<B>FDD2h - IO_SPI_manual_data_read (R)</B><BR>
Data, used for manual data read (and also for write-protect-status read). Not
used for DMA access.<BR>
<BR>
<B>FDD3h - IO_SPI_chip_id_read_msb (R) (initially 00h)</B><BR>
<B>FDD4h - IO_SPI_chip_id_read_mid (R) (initially 00h)</B><BR>
<B>FDD5h - IO_SPI_chip_id_read_lsb (R) (initially 00h)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-6 Maker bit1-7 (EFh/2 for Winbond)
7-14 Device Capacity (13h for Winbond W25D40)
15-22 Device Type (40h for Winbond W25D40)
23 Maker bit0 (?) (EFh and 01h for Winbond)
</TD></TR></TABLE>
As shown above, the register is weirdly right-rotated, to fix that hardware
glitch: left-rotate the whole 24bit value (unknown if the carry-in really gives
intact maker.bit0 (JEDEC maker codes are actually 7bit+parity, so maybe the
weird rotation was done intentionally for stripping the parity bit).<BR>
Used by newer firmware only (the firmware does totally discard bit23, ie. it's
merley doing "mul2" instead of "rol").<BR>
<BR>
<B>FDD6h - IO_SPI_flash_addr_lsb</B><BR>
<B>FDD7h - IO_SPI_flash_addr_mid</B><BR>
<B>FDD8h - IO_SPI_flash_addr_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-23 Address in SPI FLASH memory (for read/write/erase operations)
</TD></TR></TABLE>
<BR>
<B>FDD9h - IO_SPI_dma_ram_addr_lsb</B><BR>
<B>FDDAh - IO_SPI_dma_ram_addr_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-14 Address in XRAM or FONT memory (for DMA, not used for manual CPU read)
15 Unknown, used! (maybe DIRECTION, or maybe XRAM vs FONT select?)
</TD></TR></TABLE>
<BR>
<B>FDDBh - IO_SPI_dma_length_lsb</B><BR>
<B>FDDCh - IO_SPI_dma_length_msb</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-15 Transfer length in bytes (MINUS 1) (for DMA, not used for manual read)
</TD></TR></TABLE>
<BR>
<B>FDDDh - IO_SPI_ready_flags (write 00h to reset)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-7 Ready flags (corresponding to start.bits in FDD0h) (1=Ready)
</TD></TR></TABLE>
Maybe these bits (or FDDFh) do trigger IRQ 0013h (aka ext.1 interrupt)?<BR>
<BR>
<B>FDDEh - IO_SPI_kick_stop_reset</B><BR>
Write 80h to start/stop/reset? DANGER: setting bit6 hangs CPU (once caused
weird OSD roll).<BR>
<BR>
<B>FDDFh - IO_SPI_status_ready (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-6 Unknown/unused
7 FLASH Status (0=busy, 1=ready)
</TD></TR></TABLE>
<BR>
<B>FDE4h - IO_SPI_command_write (D8h)</B><BR>
Used for manually writing certain commands (in most/other cases, the memory
system is automatically sending appropriate commands). Used values are:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
04h Write Disable (WEL/WREN=0) (used for whatever reason)
06h Write Enable (WEL/WREN=1) (used before Erase, Write,and WriteWprot)
20h Erase 1000h-byte Sector (used when saving settings)
D8h Erase 10000h-byte Block (used in an unused table entry in old firmware)
D7h Erase whatever? (used in an unused table entry in old firmware)
</TD></TR></TABLE>
<BR>
<B>FDE0h - whatever SPI control, DANGER! crashes CPU (not used by firmware) 03h</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 hangs and draws TWO garbage characters on OSD?
1 hangs and draws TWO garbage characters on OSD?
2 hangs and draws TWO garbage characters on OSD?
3 jumps to a pushed retadr at some/several stages higher stack level?
4 hangs and draws ONE garbage character on OSD?
5 hangs
6 hangs
7 hangs
</TD></TR></TABLE>
<BR>
<B>FDE1h..FDE3h - whatever SPI control, 3 bytes (02h,05h,01h)</B><BR>
<B>FDE5h..FDE7h - whatever SPI control, 3 bytes (9Fh,06h,07h)</B><BR>
Whatever, not used by firmware. Might be 24bit FLASH address(es), but seem to
have no effect the XRAM memory window?<BR>
Or rather... looks as if FDE0h..FDE7h are SPI commands for Read, Write, GetID,
etc. (which could be changed for SPI chips with different command set).<BR>
<BR>
<B>FDF0h - Unknown (not used by firmware) (07h)</B><BR>
Unknown, not used by firmware, seems to have no effect when changed.<BR>
<BR>
<B>FDF1h - IO_SPI_upper_32k_code_base (not used by firmware)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 SPI Base Address for CODE at 8000h-FFFFh in 32Kbyte units (usually 01h)
4-7 Probably MSBs of above (no effect on 512Kbyte flash chip)
</TD></TR></TABLE>
<BR>
Note: There's another/unrelated SPI bus for LCD display configuration (which is
done via manually generating SPI clk/dta/select/reset signals on some other
pins).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ PIN Registers _______________________________
</TD></TR></TABLE>
<BR>
Most of the registers below are probably 4bit mode value for each chip pin...<BR>
<BR>
<B>FD30h - IO_PIN_maybe (not used by firmware) (maybe P04_P05 = UART/I2C?)</B><BR>
<B>FD31h - IO_PIN_P06_P07_pwm ;PWM2/PWM3</B><BR>
<B>FD32h - IO_PIN_P10_P11_spi_flash ;DANGER (11h)</B><BR>
<B>FD33h - IO_PIN_P12_P13_spi_flash ;DANGER (11h)</B><BR>
<B>FD34h - IO_PIN_P14_P15_lcd ;RGB</B><BR>
<B>FD35h - IO_PIN_P16_P17_lcd ;RGB</B><BR>
<B>FD36h - IO_PIN_P20_P21_lcd ;RGB</B><BR>
<B>FD37h - IO_PIN_P22_GPIO0_lcd ;RGB ;bit0:addDarkBLUE, bit4:addMoreBLUE</B><BR>
<B>FD38h - IO_PIN_GPIO1_GPIO2_lcd ;RGB</B><BR>
<B>FD39h - IO_PIN_GPIO3_GPIO4_lcd ;RGB</B><BR>
<B>FD3Ah - IO_PIN_P23_P24_lcd ;RGB ;bit4:addDarkGREEN</B><BR>
<B>FD3Bh - IO_PIN_P25_P26_lcd ;RGB ;bit0:addMoreGREEN, bit4:addManyGREEN</B><BR>
<B>FD3Ch - IO_PIN_GPIO5_GPIO6_lcd ;RGB</B><BR>
<B>FD3Dh - IO_PIN_GPIO7_GPIO8_lcd ;RGB</B><BR>
<B>FD3Eh - IO_PIN_GPIO9_GPIO10_lcd ;RGB</B><BR>
<B>FD3Fh - IO_PIN_P27_P30_lcd ;RGB ;bit0:addDarkRED, bit4:addMoreRED</B><BR>
<B>FD40h - IO_PIN_P31_P32_lcd ;DCK/DOE? ;bit0:StopDotClk, bit1:HIRES, bit2:LORES</B><BR>
<B>FD41h - IO_PIN_P33_P34_lcd ;HOS/VOS? ;bit0-5:Kill/Move/Shake/Freeze Image</B><BR>
<B>FD42h - IO_PIN_P35_P36_pwm ;PWM0/PWM1 ;bit0-2:BacklightBlack</B><BR>
<B>FD43h - IO_PIN_P37_xxx_pwm ;PWM2'/xxx</B><BR>
<B>FD44h - IO_PIN_maybe (set to 01h by firmware) ;bit0:force dotclk stuck/low</B><BR>
<B>FD45h - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD46h - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD47h - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD48h - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD49h - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD4Ah - IO_PIN_maybe (set to zero by firmware)</B><BR>
<B>FD4Bh - IO_PIN_maybe (set to zero by firmware)</B><BR>
The firmware contains functions for switching the PWM pins to PWM mode or to
manual output High/Low mode.<BR>
The firmware initializes all SPI and LCD registers to 11h. The pins for SPI and
LCD are following the chip's physical pin-ordering, ie. with GPIOxx pins
inserted within the Pxx ports (confirmed by messing with the MSBs of the RGB
signals).<BR>
Some of the other/unknown registers might be related to Infrared REMOTE pin,
the three ADC input pins, and to the two UART/I2C pins, and possibly some
further LCD/voltage related pins.<BR>
<BR>
<B>FD50h - IO_whatever_FD50h ;(initially 00h, then set to 0Bh)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit5:KillTftUpdating (force dotclk stuck/low)
</TD></TR></TABLE>
<BR>
<B>FD51h..FD5Ah - IO_whatever_zerofilled, 10 bytes ;fixed (zerofilled)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FD59h.bit2 add some zigzag noise on dotclk ;\normally square wave gets
FD59h.bit3 add more zigzag noise on dotclk ;/zigzag at raising/falling edges
</TD></TR></TABLE>
Maybe 2bit signal strengths for all PINs?<BR>
<BR>
<B>FD4Ch..FD4Fh - whatever, 4 bytes</B><BR>
<B>FD5Bh..FD5Fh - whatever, 5 bytes</B><BR>
Whatever, read/write-able, not used by firmware.<BR>
<BR>
LCD Databus type is controlled by following registers:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FC00h - IO_LCD_color_swap (color swap, eg. RGB vs BGR or so)
FD34h..FD43h - IO_PIN_xxx_xxx_lcd (maybe HV vs DEN mode, or RGB vs YCbCr)
FD50h - IO_whatever_FD50h (no visible effect...?)
</TD></TR></TABLE>
Known settings are:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Tianma 24bit RGB+HV : FC00h=05h, FD34h..FD43h=11h, FD50h=0Bh
Innolux 24bit RGB+DEN : FC00h=00h, FD34h..FD43h=22h, FD50h=0Fh
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________________ PLL Registers _______________________________
</TD></TR></TABLE>
<BR>
The "PLL" registers are configuring several clocks (for AV, LCD, CPU, PWM, ADC,
etc.), allowing to multiply &amp; divide the 27MHz crystal clock, and to
enable/disable some clocks. The firmware initializes several registers during
initialization (in some cases twice writing the same value, which is probably
not required, and in some cases writing 2-3 different values during init, which
might be a bug, or it's required for proper wake-up).<BR>
Apart from initialization, the firmware does also alter FD11h/FD12h/FD13h when
entering/leaving standby mode, probably for some sort of power-saving, either
disabling or slowing down certain clocks.<BR>
<BR>
<B>FD11h - IO_PLL_11h_used (init: MOV FFh, on: OR E0h, off: AND 1Fh) ;Sysclk?</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0? hangs CPU?
1-2? OSDcharerror+hang?
3 unknown, no visible effect
4 OSD_BG_ONLY (no TEXT)
5 scanlinefreeze(AV+OSD)
6-7 unknown, no visible effect
</TD></TR></TABLE>
<BR>
<B>FD12h - IO_PLL_12h_used (init: MOV FFh, on: OR EFh, off: AND 38h) ;ADC</B><BR>
Seems to contain enable flags for AV, TFT, ADC, PWM clocks.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-1 unknown, no visible effect
2 AV filled by most-recent AV pixel color (OSD+backdrop still work)
3 kills TFT screen output (dotclk switched HIGH permanently)
4 DANGER: hangs ADC
5 stops PWM (randomly gets stuck at MAX or MIN backlight level)
6-7 unknown, no visible effect
</TD></TR></TABLE>
<BR>
<B>FD13h - IO_PLL_13h_used (init: MOV FFh, on: OR FFh, off: AND 00h) ;Flag?</B><BR>
There seem to be no noticable effects when changing this register, though it
might affect some less obvious timings? Apart from writing to FD13h, the
firmware is also reading FD13h in several places (for checking if
FD11h/FD12h/FD13h are currently in standby mode).<BR>
<BR>
<B>FD19h - IO_PLL_19h_used ;(initially ORed by 81h, later set to 83h)</B><BR>
The firmware initializes this register twice during initialization: First to
power-up value ORed by 81h, then setting the register to 83h.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 NoSignal, withSmallVsyncRoll
bit6 Darker(AV+OSD) -- PWM is (almost) twice as fast as usually
bit7 NoSignal, occassionally/shortly AV scanlines shown twice/at half width
</TD></TR></TABLE>
<BR>
<B>FD0Bh - IO_PLL_0Bh_used ;(twice set to 40h)</B><BR>
The firmware initializes this register to fixed value, messing with it can have
several effects.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 force NTSC color, or somewhat other/wrong color clock?
bit1,3-7 force NoSignal
bit2 force gray AV at wrong Xloc
bit0,1 C64: temporarily enables C64 image
</TD></TR></TABLE>
<BR>
<B>FD0Dh - IO_PLL_0Dh_cfg ;fixed (F0h) ;15kHz, MSBs: snow+rolling sync?</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit4: flipped changes dotclk to 16.12MHz (instead 8.06) ;\shift/divider
bit5: flipped changes dotclk to 32.26MHz (instead 8.06) ;/for dotclk?
bit6-7: no signal (no AV image)
bit7: no effect on dotclk... but much more white snow
</TD></TR></TABLE>
<BR>
<B>FD0Eh - IO_PLL_0Eh_used ;(set to 20h or 2Ch) ;scanline freeze?</B><BR>
The firmware initializes this register thrice during initialization: First to
20h, then to 20h again, and finally to 2Ch.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit2: freeze dotclk (get stuck in LOW or HIGH state)
bit3: freeze snow (backdrop get stuck with all WHITE or BLUE/BLACK pixels)
</TD></TR></TABLE>
<BR>
<B>FD0Ah - IO_PLL_dotclk_multiplier ;fixed (2Bh) ;15kHz (also SNOW-boldness?)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FD0Ah dotclk: MULTIPLY by N
2Bh = (default) 8.06MHz (0.187MHz * 43)
2Ah = (bit0 flipped) 7.88
29h = (bit1 flipped) 7.68
2Fh = (bit2 flipped) 8.82
23h = (bit3 flipped) 6.56 (0.187MHz * 35)
3Bh = (bit4 flipped) 11.06 (0.187MHz * 59)
0Bh = (bit5 flipped) 2.06 (0.187MHz * 11)
6Bh = (bit6 flipped) 15.74 MAX (0.187MHz * 84)
ABh = (bit7 flipped) 15.74 MAX (0.187MHz * 84)
</TD></TR></TABLE>
<BR>
<B>FD0Fh - IO_PLL_dotclk_divider_1 ;fixed (03h) ;15kHz ...inserts VSYNC's?</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FD0Fh dotclk: DIVIDE by N (with some odd effects in some cases)
03h = (default) 8.06MHz (15.72MHz / 1.95) (24.20MHz / 3)
02h = (bit0 flipped) 12.10MHz (15.72MHz / 1.3) (24.20MHz / 2)
01h = (bit1 flipped) 15.72MHz (15.72MHz / 1) (24.20MHz / 1.54) ;odd
07h = (bit2 flipped) 3.46MHz (15.72MHz / 4.54) (24.20MHz / 7)
0Bh = (bit3 flipped) 2.20MHz (15.72MHz / 7.14) (24.20MHz / 11)
13h = (bit4 flipped) 1.27MHz (15.72MHz / 12.37)
23h = (bit5 flipped) 0.69MHz (15.72MHz / 22.78) (24.20MHz / 35)
43h = (bit6 flipped) unstable (0.3-0.4MHz) (stutters) ;&lt;-- odd
83h = (bit7 flipped) 15.74MHz MAX (MAX) ;&lt;-- odd
</TD></TR></TABLE>
<BR>
<B>FD14h - IO_PLL_dotclk_divider_2 ;fixed (03h) ;similar effects as FD0Fh</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FD14h dotclk: DIVIDE by N
03h = (default) 8.06MHz (24.20 / 3)
02h = (bit0 flipped) 12.10MHz (24.20 / 2)
01h = (bit1 flipped) 24.20MHz (24.20 / 1) ;&lt;-- unlike FD0Fh
07h = (bit2 flipped) 3.46MHz (24.20 / 7)
0Bh = (bit3 flipped) 2.20MHz
13h = (bit4 flipped) 1.27MHz (24.20 / 19)
23h = (bit5 flipped) 0.69MHz
43h = (bit6 flipped) 0.36MHz ;&lt;-- unlike FD0Fh
83h = (bit7 flipped) 24.20MHz ;&lt;-- unlike FD0Fh
</TD></TR></TABLE>
<BR>
<B>FD15h - IO_PLL_dotclk_divider_3 ;fixed (02h) ;similar effects as FD0Fh</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FD15h dotclk: DIVIDE by N
02h = (default) 8.06MHz (16.12 / 2)
03h = (bit0 flipped) 5.38MHz (16.12 / 3)
00h = (bit1 flipped) 16.12MHz
06h = (bit2 flipped) 2.68MHz (16.12 / 6)
0Ah = (bit3 flipped) 1.61MHz (16.12 / 10)
12h = (bit4 flipped) 0.89MHz
22h = (bit5 flipped) 0.47MHz
42h = (bit6 flipped) 0.24MHz
82h = (bit7 flipped) 16.12MHz
</TD></TR></TABLE>
<BR>
<B>FD10h - IO_PLL_10h_cfg ;fixed (twice set to 04h) ;if changed: NoSignal</B><BR>
<B>FD16h - IO_PLL_16h_cfg ;fixed (03h) ;unknown (no visible effect)</B><BR>
<B>FD17h - IO_PLL_adc_clk_divider ;fixed (18h) ;bit5-6:SlowerADC, bit7=HangsADC</B><BR>
<B>FD1Ah - IO_PLL_1Ah_cfg ;fixed (08h) ;unknown (no visible effect)</B><BR>
The firmware initializes these registers to fixed values.<BR>
<BR>
FD0Ah,FD0Fh,FD16h seem to be related to vertical resolution/scaling, used
values are 2Bh,03h,03h for 320x240, and A8h,09h,0Ah for 480x272, the three
bytes are apparently one multiplier and two dividers or vice-versa (confirmed
by replacing 2Bh,03h,03h by stuff like 2Bh*3,03h*3,03h*3, which didn't affect
the picture).<BR>
<BR>
<B>FD00h - IO_PLL_00h (00h)</B><BR>
<B>FD01h - IO_PLL_01h_cpu (01h) ;bit0:hangs CPU</B><BR>
<B>FD02h - IO_PLL_02h_zoom (00h) ;bit0:zoom/wobble</B><BR>
<B>FD03h - IO_PLL_03h (00h)</B><BR>
<B>FD04h - IO_PLL_04h (00h)</B><BR>
<B>FD05h - IO_PLL_05h (00h)</B><BR>
<B>FD06h - IO_PLL_06h (00h)</B><BR>
<B>FD07h - IO_PLL_07h (00h)</B><BR>
<B>FD08h - IO_PLL_08h ;NOT R/W (value 00h) (R)</B><BR>
<B>FD09h - IO_PLL_09h ;NOT R/W (value 00h) (R)</B><BR>
<B>FD0Ch - IO_PLL_0Ch (33h)</B><BR>
<B>FD18h - IO_PLL_18h_pwm (FFh) ;bit7:ForceMaxBacklight/PWMdimmingOFF</B><BR>
<B>FD1Bh - IO_PLL_1Bh (FFh)</B><BR>
<B>FD1Ch - IO_PLL_1Ch (FFh)</B><BR>
<B>FD1Dh - IO_PLL_1Dh (00h)</B><BR>
<B>FD1Eh - IO_PLL_1Eh (00h)</B><BR>
The firmware doesn't use these registers.<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
______________________________ Unused Registers ______________________________
</TD></TR></TABLE>
<BR>
<B>FD60h..FDAFh - Unused (open-bus) (50h bytes)</B><BR>
<B>FDE8h..FDEFh - Unused (open-bus) (08h bytes)</B><BR>
<B>FDF2h..FDFFh - Unused (open-bus) (0Eh bytes)</B><BR>
Probably unused I/O addresses.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630afexxhavregisterscompositevideoinput"></A>&nbsp;
AMT630A - FExxh - AV Registers (Composite Video Input)
</FONT></TD></TR></TABLE><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ AV Status Registers ____________________________
</TD></TR></TABLE>
<BR>
<B>FE26h - IO_AV_stat_detect_0 (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
video DETECT... OFTEN used (bit1,bit2 tested)
</TD></TR></TABLE>
<BR>
<B>FE27h - IO_AV_stat_detect_1 (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
...status (boldness, bit0 tested, used by only ONE opcode)
</TD></TR></TABLE>
<BR>
<B>FED0h - IO_AV_stat_detect_2 (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
...status (sharpness, bit2-5)
</TD></TR></TABLE>
<BR>
<B>FE28h - IO_AV_stat_framerate_flag (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit2 = PAL/NTSC and/or 50/60 Hz
</TD></TR></TABLE>
<BR>
<B>FE2Ah - IO_AV_stat_signal_detect (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
...status (bit6 and bit0-3 used)
bit0,1,2,3=ErrorFlag(s))
bit4:Have Signal on currently selected pin ;\CVBS1 and CVBS3 inputs
bit6:Have Signal on currently de-selected pin ;/
</TD></TR></TABLE>
<BR>
<B>FEAAh - IO_AV_stat_sensitivity_msb (R)</B><BR>
<B>FEABh - IO_AV_stat_sensitivity_lsb (R)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
16bit status/counter? (NoSignal:0FFFh, C64:0287h..028Bh=647..651)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_________________________ AV Misc Control Registers _________________________
</TD></TR></TABLE>
<BR>
<B>FE01h - IO_AV_ctrl_whatever_1</B><BR>
bit1 set/cleared, bit4 set by firmware.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 ForcePALcolors_ButYetPAL60getsWrongYloc,
bit2 ForcePALcolors_But_Only_If_FE00h.bit7 is toggled
(similar as FE01h.bit0, but HERE bit2 has NO effect if FE00h.bit7=x)
</TD></TR></TABLE>
<BR>
<B>FE54h - IO_AV_ctrl_whatever_2</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
initially 00h, bit6 is manipulated later on
</TD></TR></TABLE>
<BR>
<B>FEA0h - IO_AV_force_resync</B><BR>
bit0 manually pulsed with SLOW DELAYS by firmware.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 sometimes causes NoSignal, and simetimes FreezesCurrentScanline
(THAT affecting BOTH OSD AND AV !!!)
bit1 move AV image 1pix UP, and ca.8pix RIGHT
bit2-7 NOT R/W
</TD></TR></TABLE>
C64: UNTOGGLING bit7 does SHOW C64 image for short moment (uh, but b<>t7 isn't
R/W, how did I do that?).<BR>
<BR>
<B>FECBh - IO_AV_ctrl_artifacts</B><BR>
Firmware sets this to 00h, 02h, or 06h.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0: NICE: LessPalArtifactsOnSNES
bit1: Similar as bit0, plus magenta-line at bottom of red-snes-screen
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
______________________ AV Sensitivity Control Registers ______________________
</TD></TR></TABLE>
<BR>
<B>FE15h - IO_AV_ctrl_sensitivity_0</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
set to 00h=max, 05h=med, 09h=low, also checked if 05h
bit2,3:PixelBoldness
</TD></TR></TABLE>
<BR>
<B>FED5h - IO_AV_ctrl_sensitivity_1</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
initially B1h, modified/used later
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________ AV Input Select and On/Off Registers ____________________
</TD></TR></TABLE>
<BR>
Used to select the AV input. The chip does support three AV inputs
(AV1,AV2,AV3), but most boards have the AV2 input unused (GNDed, maybe intended
as shielding between the other two pins), and renamed AV3 to AV2 in the GUI.
The overall input selection flowchart is:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Clear IO_AV_video_on_off bit3,4
Change IO_AV_input_select_reg_0 bit6,7
Set IO_AV_video_on_off bit3,4
Change IO_AV_input_select_reg_1 bit4,5
</TD></TR></TABLE>
Used values are shown below (looks as if newer firmware has swapped AV1+AV3
(though without swapping the corresponding bits in IO_AV_stat_signal_detect,
unknown if/how that's working) and firmware also changed the dummy bits for
unused AV2 input somehow).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
- - - IO_AV_video_on_off
- - - | IO_AV_input_select_reg_0
- - - | | IO_AV_input_select_reg_1
Input FED7h.bit3-4 FED8h.bit6-7 FEDCh.bit4-5
OLDER FIRMWARE:
AV1 0-then-3 2 0 ;&lt;-- CVBS1
AV2 0-then-3 2 3 ;&lt;-- stripes when CVBS3 has signal
AV3 0-then-3 0 2 ;&lt;-- CVBS3
Invalid 0-then-3 3 3 ;&lt;-- stripes when CVBS3 has signal
NEWER FIRMWARE:
AV1 0-then-3 0 ! 2 ! ;&lt;--
AV2 0-then-3 0 ! 3 ;&lt;--
AV3 0-then-3 2 ! 0 ! ;&lt;--
Invalid 0-then-3 3 3 ;&lt;--
</TD></TR></TABLE>
Unknown if there's some way to configure a pin-pair as S-Video input (older
AMT630 chips did support that, but AMT630A specs don't mention any S-Video
support).<BR>
<BR>
<B>FED7h - IO_AV_video_on_off</B><BR>
lcd-control/enable or so<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0+1+6+7:disable SNOW (freeze backdrop-color or snow-color,
and occassionally also freeze current OSD scanline!)
</TD></TR></TABLE>
<BR>
<B>FED8h - IO_AV_input_select_reg_0</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
C64: bit7=whitish stripes when C64 ON
;SNES: bit7=ShortlyWhiteStripes...ThenAllWhite (looks as if snow/random
generator ends up with all-white pixels)
</TD></TR></TABLE>
<BR>
<B>FEDCh - IO_AV_input_select_reg_1</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit4: Toggle=BlueBackdrop(without snow),
Untoggle: ShortlyNoSignal(with snow)ThenNormalPicture
bit5: NoSignal, or, if C64 powered on AV2: white picture with
blue/rolling hsync/vsync signals?
bit6: BlueBackdrop(without snow, except a VERY FEW random/snow pixels
in some rolling-screen-half)
bit6: Like bit6, but with a little bit more random/now pixels)
bit7: C64: minimal SNOW when C64 ON
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ AV Config Registers ____________________________
</TD></TR></TABLE>
<BR>
<B>FE04h - IO_AV_config_FE04h - (should be set to 30h)</B><BR>
<B>FE05h - IO_AV_config_FE05h - (should be set to 40h)</B><BR>
<B>FE13h - IO_AV_config_FE13h - (should be set to 1Eh)</B><BR>
<B>FE56h - IO_AV_config_FE56h - (should be set to 00h)</B><BR>
<B>FE83h - IO_AV_config_FE83h - (should be set to FEh)</B><BR>
<B>FEB5h - IO_AV_config_FEB5h - (should be set to 67h)</B><BR>
<B>FEBAh - IO_AV_config_FEBAh - (should be set to FFh)</B><BR>
<B>FED9h - IO_AV_config_FED9h - (should be set to bit4-5 cleared, bit6 set)</B><BR>
<B>FEDBh - IO_AV_config_FEDBh - (should be set to bit7 cleared)</B><BR>
The firmware initializes these to fixed values. Changing the bits seems to have
no visible effect.<BR>
<BR>
<B>FEC9h - IO_AV_config_FEC9h - (should be set to 01h or left unchanged)</B><BR>
Older firmware leaves this register unused, newer firmware sets it to 01h
(although it's 01h on power-up anyways). Changing bits has some visible
effects:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit1 Less Boldness
bit6 Dithered All Green Image (GREEN !!!)
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
________________________ AV Internal Status Registers ________________________
</TD></TR></TABLE>
<BR>
<B>FE20h..FE21h - 2 bytes - Status (R)</B><BR>
<B>FE84h..FE89h - 6 bytes - Status (R) (two negative 16bit values?, and sth)</B><BR>
<B>FE90h..FE9Fh - 16 bytes - Status (R)</B><BR>
<B>FEA3h..FEA9h - 7 bytes - Status (R)</B><BR>
<B>FEACh..FEB1h - 6 bytes - Status (R)</B><BR>
<B>FEC5h..FEC7h - 3 bytes - Status (R) (values 00h)</B><BR>
<B>FECEh..FECFh - 2 bytes - Status (R) (reads as DFh,73h with PAL/SNES)</B><BR>
<B>FEDDh..FEEBh - 15 bytes - Status (R)</B><BR>
<B>FEF0h..FEFDh - 14 bytes - Status (R) (not FFh)</B><BR>
<B>FE7Eh - 1 byte - Status (R) (value FFh)</B><BR>
<B>FE8Ch - 1 byte - Status (R) (value 17h)</B><BR>
<B>FEA1h - 1 byte - Status (R) (value Fxh)</B><BR>
<B>FEB3h - 1 byte - Status (R)</B><BR>
These registers contain some status information. The firmware doesn't use them.<BR>
Note: FEEAh..FEEBh are usually FFh, but FEEBh can become EFh when (un-)plugging
AV cable.<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
_______________________ AV Internal Control Registers _______________________
</TD></TR></TABLE>
<BR>
<B>FE42h - IO_AV_secret_control (default=20h, better=00h)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0-2 Slight horiz.position changes
bit3 BlurRightScreenEdge
bit4 NoSignal
bit5 C64 does PERFECTLY SHOW C64 IMAGE! (still shows SNOW if C64=Off)
bit6 Wrong Color (Lightblue instead Red in SnesDiag, Washy if C64 on
AV2... hmmm or is that S-Video with Chroma from AV2?)
bit7 no visible effect
</TD></TR></TABLE>
<BR>
<B>FE00h - 1 byte</B><BR>
<B>FE02h - 1 byte</B><BR>
<B>FE03h - 1 byte</B><BR>
<B>FE06h..FE12h - 13 bytes</B><BR>
<B>FE14h - 1 byte</B><BR>
<B>FE16h..FE1Fh - 10 bytes</B><BR>
<B>FE22h..FE25h - 4 bytes</B><BR>
<B>FE29h - 1 byte</B><BR>
<B>FE2Bh..FE2Fh - 5 bytes</B><BR>
<B>FE30h..FE41h - 18 bytes</B><BR>
<B>FE43h..FE4Fh - 13 bytes</B><BR>
<B>FE50h..FE53h - 4 bytes</B><BR>
<B>FE55h - 1 byte</B><BR>
<B>FE57h..FE5Fh - 9 bytes</B><BR>
<B>FE60h..FE7Fh - 1 byte</B><BR>
<B>FE61h..FE68h - 8 bytes</B><BR>
<B>FE70h..FE7Dh - 14 bytes</B><BR>
<B>FE7Fh - 1 byte (FFh, but this one is write-able)</B><BR>
<B>FE80h - 1 byte</B><BR>
<B>FE81h - 1 byte (FFh)</B><BR>
<B>FE82h - 1 byte</B><BR>
<B>FE8Ah..FE8Bh - 2 bytes</B><BR>
<B>FE8Dh..FE8Fh - 3 bytes</B><BR>
<B>FEA2h - 1 byte</B><BR>
<B>FEB2h - 1 byte</B><BR>
<B>FEB4h - 1 byte</B><BR>
<B>FEB6h..FEB9h - 4 bytes</B><BR>
<B>FEBBh..FEC4h - 10 bytes</B><BR>
<B>FEC8h - 1 byte</B><BR>
<B>FECAh - 1 byte</B><BR>
<B>FECCh..FECDh - 2 bytes</B><BR>
<B>FED1h..FED4h - 4 bytes</B><BR>
<B>FED6h - 1 byte</B><BR>
<B>FEDAh - 1 byte</B><BR>
These registers contain some control stuff. The firmware doesn't use them. All
registers are 8bit R/W, except some MSBs aren't R/W:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FE1Dh.bit7: NOT RW
FE1Eh.bit7: NOT RW
FE1Fh.bit7: NOT RW
FE39h.bit4-7: NOT RW
FE3Fh.bit1-7: NOT RW
FE4Bh.bit7: NOT RW
FE4Dh.bit3-7: NOT RW
FE4Fh.bit7: NOT RW
FE8Bh.bit7: NOT RW
FE8Dh.bit3-7: NOT RW
FE8Eh.bit5-7: NOT RW
FEA2h.bit3-7: NOT RW
FEB2h.bit7: NOT RW
FEB6h.bit5-7: NOT RW
FEB7h.bit1-7: NOT RW
FED1h.bit7: NOT RW
FED3h.bit2-7: NOT RW
</TD></TR></TABLE>
In most cases, changing the initial bits doesn't have visible effects, but
there are still a lot of bits that do have visible effects:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FE00h.bit4 Vertical.boldness
FE00h.bit5 Temporarily NoSignal
FE00h.bit7 Force_NTSC_Colors?
FE0Dh:bit7 Untoggle=BlinksAvWhiteRecalib?
FE0Fh.bit0-2 Change=TemporarilyNoSignal
FE0Fh.bit3 ForcePALcolors_ButYetPAL60getsWrongYloc
(similar as FE01h.bit0, but HERE effect is inverse if
FE00h.bit7=x --&gt; then forces NTSC colors)
FE11h.bit2 ShortColorRollThenShowDitheredBlackWhiteAvImage
FE11h.bit4-7 ShortColorRollThenShowDitheredBlackWhiteAvImage
FE17h.bit1 Boldness
FE17h.bit4-5 BoldnessWithContrast
FE17h.bit6-7 PermanentlyToggleColoredAndDitheredBlackWhiteLines
FE18h.bit1-2 BoldnessAndRightScreenEdge
FE18h.bit6-7 PermanentlyToggleColoredAndDitheredBlackWhiteLines
FE1Dh.bit6 NoSignalOrWeirdColorRoll
FE1Eh.bit6 NoSignalOrWeirdColorRoll
FE2Dh.bit7 ShortColorRollThenBlackWhiteDither
FE31h.bit7 NoSignal
FE3Ch.bit5 Boldness
FE3Ch.bit6 BoldnessAndWashyBackground(SnesLooksAsWashyAsC64)
FE3Ch.bit7 BoldnessBrighterBlack
FE3Dh.bit6 UltraWashyBlurr
FE3Dh.bit7 RollingImageAndBlackWhiteDither
FE41h.bit6 TrueSnow?(not the artifical snow effect)
FE41h.bit7 freezeSNOW (stuck BG or WHITE) and/or snow with wandering bars
FE41h.bit6-7 C64:vague picture/sync traces? (uh, was this FE41h, not Fx41h?)
FE43h Somewhat Lumafactor/Lumaoffset for white-pixels getting
brighter, or, if bit7 changed: white pixels are becoming BLACK
FE44h.bit5 LessBoldness
FE44h.bit6 AllMuchBrighter(including brighter black)
FE44h.bit7 AllVERYMuchBrighter(including brighter black)
FE45h.bit7 MonochromeImage(not dithered), with Washyness if C64 on AV2
FE47h.bit7 ReddishMagentaInsteadRed, with Washyness if C64 on AV2
FE48h.bit6 BlackWhiteDitheredImage
FE4Eh.bit6 C64: Untoggling FE4Eh.6 shows C64 image for short moment
(no effect on SNES image)
FE50h.bit6-7 C64: does show C64 image going on/off (no effect on SNES)
FE55h.bit4 AlmostCompletelyOmitsSomePalScanlines(instead of resampling
them from PAL to 240pix-LCD-resolution)
FE55h.bit5 SameAsBit4(but affecting OTHER lines)
FE60h.bit1 When changed: ShortlyFlashesOrShortlyNoSignal
FE60h.bit3 SNES: dims white to BluishGray and/or shortly NoSignal
FE60h.bit3 C64: rolling white stripes when C64 ON
FE80h.bit7 ForcesBlackImage
FEB4h.bit7 Maybe S-Video (picks Snes/Luma from AV1, but C64/Chroma from
AV2, showing hatchy blue borders at wrong hsync)
FEB7h.bit0 Moves image 1pix LEFT
FEC8h.bit0 DitheredBlackWhite
FEC8h.bit7 Move image ca.80pix RIGHT and ca.12pix UP
FECAh.bit0 UntogglingShortlyDimsBrightness
FECAh.bit1 UntogglingShortlyBlinksWhitePixels
FED1h.bit5-6 UponChanges: ShortlyNoSignal
FED4h.bit1 OverBright (andWashyIfC64 is powered on AV2)
FED6h.bit3 Snowy random Red/Magenta pixels (instead of SNES with Red
background) (and if C64 powered on AV2: diagonally striped
Red/Magenta) (might be also S-Video, chroma from AV2?)
FED6h.bit7 ShortlyNoSignal, then UberOverBrightImage (Washy if C64 on AV2)
FED6h.bit7 C64: does show C64 image, only once and then, goes on and off
;C64: FF20h.6-7: C64/SNOW color ;XXX why FFxxh? THIS is FExxh!!!
: (also, FE20h would be read-only)
;C64: FF4Ah.7/FF4Bh.7/C64: bluish ;XXX why FF4xh? THIS is FE4xh!!!
</TD></TR></TABLE>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ AV Unused Registers ____________________________
</TD></TR></TABLE>
<BR>
<B>FE69h..FE6Fh - Unknown/unused, 7 bytes ;(FFh-filled) ;NOT R/W</B><BR>
<B>FEECh..FEEFh - Unknown/unused, 4 bytes ;(FFh-filled) ;NOT R/W</B><BR>
<B>FEFEh - Unknown/unused, 1 byte ;(FFh-filled) ;NOT R/W</B><BR>
Unknown, not R/W, reading always seems to return FFh (but no open-bus garbage).<BR>
<BR>
<B>FEFFh - Unused (open-bus) (1 byte)</B><BR>
Probably unused I/O addresses.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630affxxhlcdregistersgammabrightnessetcandir"></A>&nbsp;
AMT630A - FFxxh - LCD Registers (gamma/brightness/etc and IR)
</FONT></TD></TR></TABLE><BR>
<B>FFD3h - IO_LCD_basic_contrast - Contrast (medium=7Eh)</B><BR>
<B>FFD4h - IO_LCD_basic_brightness - Brightness (medium=8Eh)</B><BR>
<B>FFD5h - IO_LCD_basic_tint - Tint (for NTSC only) (medium=00h)</B><BR>
<B>FFD6h - IO_LCD_basic_saturation - Saturation (amount of color) (medium=38h)</B><BR>
The firmware user interface allows to configure these to
Contrast=7Eh+(-28h..+28h), Brightness=8Eh+(-28h..+28h),
Saturation=38h+(-28h..+28h), and, a bit more weirdly,
Tint=00h+(93h..80h,00h,7Fh..62h), aka "Tint=(+13h..-1Eh), if Tint&lt;&gt;00h
then Tint=Tint XOR 80h".<BR>
BUG: Setting Tint.bit7 does smash PAL color decoding (although Tint should
affect NTSC only, and although the firmware doesn't even allow to change Tint
when receiving a PAL signal; meaning that one could repair faulty PAL settings
only when having a NTSC video source).<BR>
Note: For whatever reason, the firmware is reading the medium values from a
table, with two separate columns for PAL and NTSC (both containing the above
mentioned values: 7Eh,8Eh,00h,38h), plus six unused columns (which are all
having these values: 80h,80h,00h,55h). Moreover, newer firmware changed the
PAL/NTSC values to 80h,80h,00h,30h (and the six unused ones to
80h,80h,00h,36h).<BR>
<BR>
<B>FF01h..FF1Fh - IO_LCD_gamma_ramp_red (31 bytes)</B><BR>
<B>FF20h..FF3Eh - IO_LCD_gamma_ramp_green (31 bytes)</B><BR>
<B>FF3Fh..FF5Dh - IO_LCD_gamma_ramp_blue (31 bytes)</B><BR>
The firmware initializes all three ramps to the following non-linearily
increasing values, starting with small steps (eg. +3 at 03h,06h), then having
bigger steps in the middle (eg. +0Eh at 73h,81h), ending with small steps (eg.
+4 at F6h,FAh), and with bigger final gap (+5/+6 from FAh to FFh/100h).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
03h,06h,0Ah,0Eh,14h,1Ah,21h,29h,34h,40h,4Dh,59h,66h,73h,81h,8Eh,
9Ch,A7h,B1h,BAh,C2h,CAh,D0h,D7h,DDh,E2h,E7h,ECh,F1h,F6h,FAh
</TD></TR></TABLE>
The newer firmware is using slightly different values (for 4.3" display):<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
03h,07h,0Bh,10h,15h,1Bh,22h,2Ah,34h,3Fh,4Bh,58h,65h,72h,7Eh,89h
96h,A2h,AEh,BAh,C4h,CDh,D5h,DCh,E2h,E7h,ECh,F0h,F4h,F8h,FBh
</TD></TR></TABLE>
The power-up/reset values are yet different:<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
07h,10h,1Ah,23h,2Dh,35h,3Ch,43h,4Ah,51h,56h,5Ch,62h,68h,6Eh,74h
7Ah,81h,88h,8Fh,96h,9Dh,A4h,ABh,B2h,BAh,C1h,C9h,D2h,DDh,ECh
</TD></TR></TABLE>
Note that the tables hold only 31 values, whilst internally, they are 33
entries wide (with fixed values 00h for Darkest, and FFh or 100h for Brightest
intensities; accordingly, Darkest/Brightest intensities aren't affected by the
Gamma settings) (OSD is often using dark/bright colors like Black, Cyan, White,
Yellow - which won't get affected, whilst stuff like Gray or Brown would be
affected by gamma - even on OSD layer) (also mind the odd OSD itensities (when
IO_OSD_bright_transp_level is having too large brightness settings): eg. RGB
values CCCh and FFFh both being White, and thus both being unaffected by
gamma).<BR>
Purpose of the gamma ramp stuff is unknown: It might be intended to compensate
incoming non-linear AV signals and/or to produce outgoing non-linear TFT
signals. If it's aimed at AV then it's accidentally also applied to OSD. If
it's aimed at TFT then it's apparently done wrong (because OSD colors look
better with linear ramps) (not to mention that my firmware was compiled for a
LD035H3 display whilst actually being shipped with a TM035KDH03 display).<BR>
<BR>
<B>FFCEh - IO_LCD_backdrop_color_Y (unsigned 8bit)</B><BR>
<B>FFCFh - IO_LCD_backdrop_color_Cb (unsigned 8bit)</B><BR>
<B>FFD0h - IO_LCD_backdrop_color_Cr (unsigned 8bit)</B><BR>
Seems to define the backdrop color in YCbCr (aka YUV) format. Common values are
13h,DDh,72h (Blue), and 00h,80h,80h (Black). The backdrop is shown when AV
signal isn't present, optionally with Snow-effect.<BR>
Uh, the YCbCr theory doesn't seem to be quite right: Changing Y doesn't have
any effect. And, changing MSBs of Cb/Cr does somewhat produce the expected
colors... but unexpectedly having them applied to snow (eg. producing brown
snow on black background, instead of white snow on brown background).<BR>
<BR>
<B>FFDAh - IO_backdrop_snow_level</B><BR>
The firmware sets this register to 6Ch, with Black backdrop (though a
combination that looks neater would be 78h, with Blue backdrop).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-3 Snow Amount (00h,01h=50% White, 06h=ManyWhite, 08h=FewWhite, etc.)
4-6 Snow Width (00h-07h = 1-8 pixels)
7 ???
</TD></TR></TABLE>
The snow color seems to be fixed (always White). However, it is affected by
gamma-ramps, eg. setting blue/green ramps to all zeroes tweaks Red snow pixels
(meaning that Snow is apparently actually VeryBrightGray, because White
wouldn't be affected by the gamma ramps).<BR>
<BR>
<B>FFB0h - IO_LCD_snow_enable_and_misc</B><BR>
The firmware sets this to 22h, and changes bit7 for snow enable/disable, and
alongsides rewrites bit5=1 for whatever reason.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 ??? affects AV picture NTSC? bright?
1-4 ???
5 ??? should be 1 (weirdly firmware often rewrites it as so)
6 ???
7 Snow Enable (0=Off, 1=On)
</TD></TR></TABLE>
C64: bit5,7?=bluish (and bit5: OSD position/yscale depending on C64 on/off?)<BR>
<BR>
<B>FFB1h - IO_LCD_sharpness_or_so</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
bit0 AV bolder/brighter/smeared pixels
bit1-2 also bolder?
bit3 VeryBlurry
bit4,6 C64 becomes bluish?
</TD></TR></TABLE>
<BR>
<B>FFCBh - IO_LCD_whatever_FFCBh</B><BR>
The firmware sets this register to 80h and 2Ah.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0 Darker OSD colors?
1-7 ???
</TD></TR></TABLE>
<BR>
<B>FFD8h - IO_LCD_whatever_FFD8h</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
0-6 ???
7 ??? (firmware sets/clears this bit)
</TD></TR></TABLE>
<BR>
<B>FFD2h - IO_LCD_forced_blank_color</B><BR>
Forced Blank Color (set to 4Fh..55h depending on Settings, and on display
on/off) (4Fh=show AV video (or backdrop/snow), 5xh=force blank screen with
fixed color) (does NOT affect OSD, affects only AV+backdrop+snow)<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
for AV:
0 Swap Red/Blue
1 Mess
2 Dim?
3 AV_OFF/BLACK (show OSD only)
7 C64: bluish on C64
</TD></TR></TABLE>
<BR>
<B>FF00h - IO_LCD_config_FF00h - should be set to 03h</B><BR>
<B>FFB2h - IO_LCD_config_FFB2h - should be set to 20h</B><BR>
<B>FFB3h - IO_LCD_config_FFB3h - should be set to 20h</B><BR>
<B>FFB4h - IO_LCD_config_FFB4h - should be set to 20h</B><BR>
<B>FFB7h - IO_LCD_config_FFB7h - should be set to 90h (done twice)</B><BR>
<B>FFCCh - IO_LCD_config_FFCCh - should be set to 80h</B><BR>
<B>FFCDh - IO_LCD_config_FFCDh - should be set to 2Dh</B><BR>
<B>FFD7h - IO_LCD_config_FFD7h - should be set to 10h</B><BR>
The firmware initializes these registers to fixed values. Changing bits seems
to have no visible effect (except those listed below).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FF00h.bit0/1: Affect AV color/brightness or so, maybe GammaRampMode/Enable?
FFCCh.bit6: Forces whole screen Mintgreen? (disables AV and OSD)
FFCCh.bit7: Brighter black
</TD></TR></TABLE>
<BR>
<B>FFF0h - IO_LCD_config_FFF0h - should be set to 1Ah</B><BR>
<B>FFF1h - IO_LCD_config_FFF1h - should be set to 06h</B><BR>
<B>FFF2h - IO_LCD_config_FFF2h - should be set to D4h</B><BR>
<B>FFF3h - IO_LCD_config_FFF3h - should be set to D2h</B><BR>
<B>FFF4h - IO_LCD_config_FFF4h - should be set to F1h</B><BR>
<B>FFF5h - IO_LCD_config_FFF5h - should be set to 0Eh</B><BR>
<B>FFF6h - IO_LCD_config_FFF6h - should be set to 15h</B><BR>
<B>FFF7h - IO_LCD_config_FFF7h - should be set to E4h</B><BR>
<B>FFF8h - IO_LCD_config_FFF8h - should be set to F6h</B><BR>
<B>FFF9h - IO_LCD_config_FFF9h - should be set to F1h</B><BR>
<B>FFFAh - IO_LCD_config_FFFAh - should be set to 1Bh</B><BR>
<B>FFFBh - IO_LCD_config_FFFBh - should be set to 81h</B><BR>
Related to YCbCr to RGB conversion (affects AV and and backdrop/snow, but
doesn't affect OSD colors). The firmware initializes these registers to fixed
values.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Power-Up/Reset: 65h,C0h,DAh,0Dh,3Dh,19h,DAh,CDh,1Ah,3Dh,19h,81h
Older firmware: 1Ah,06h,D4h,D2h,F1h,0Eh,15h,E4h,F6h,F1h,1Bh,81h
Newer firmware: 11h,00h,00h,E9h,E1h,0Eh,09h,EEh,F4h,F1h,23h,81h
</TD></TR></TABLE>
Unknown what the separate bytes are doing... maybe analog sensitivity settings
or multipliers/dividers/offsets for YCbCr to RGB maths. The above old/new
values are giving slightly different colors, whilst using other values can
totally screw up the AV colors.<BR>
<BR>
<B>FFB5h..FFB6h - whatever, 02h bytes (unused by firmware)</B><BR>
<B>FFB8h..FFBFh - whatever, 08h bytes (unused by firmware)</B><BR>
<B>FFC0h..FFCAh - whatever, 0bh bytes (unused by firmware)</B><BR>
<B>FFDBh..FFDCh - whatever, 02h bytes (unused by firmware)</B><BR>
<B>FFDEh..FFEAh - whatever, 0dh bytes (unused by firmware)</B><BR>
<B>FFD1h - whatever, 1 byte (unused by firmware)</B><BR>
<B>FFD9h - whatever, 1 byte (unused by firmware)</B><BR>
The firmware doesn't use or initialize these registers. The registers are 8bit
R/W, changing bits seems to have no visible effect (except for the two
BrighterBlack bits).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
FFB8h.bit7 ;-changing this bit causes BrighterBlack
FFD1h.bit6 ;-changing this bit causes BrighterBlack
</TD></TR></TABLE>
<BR>
<B>FF5Eh - IO_LCD_whatever_FFh_1 (FFh)</B><BR>
<B>FF5Fh - IO_LCD_whatever_FFh_2 (FFh)</B><BR>
<B>FF60h - IO_LCD_whatever_FFh_3 (FFh)</B><BR>
Unknown, no visible effect when changing bits in these registers. Older
firmware is leaving these registers unused, but newer firmware is setting them
to FFh alongsides with LCD initialization (though the registers are FFh on
power-up anyways).<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
________________________ Infrared IR REMOTE Registers ________________________
</TD></TR></TABLE>
<BR>
The AMT630A is said to support NEC and Philips RC-5 protocols. Existing/known
firmwares are either leaving IR unsupported, or do merely implement the kinda
useless NEC protocol (and without actually coming bundled with any IR
sensor/hardware, neither on the mainboard, nor in the TFT screen unit).<BR>
The RC-5 protocol is a fairly well standarized protocol (eg. RC-5 based TV
Remote Controls will be working with all RC-5 based TV Sets).<BR>
The NEC protocol is shared by numerous japanese companies, each having
different maker/device IDs assigned, and each using different command values
(eg. NEC based TV Remote Controls will be incompatible with almost all NEC
based TV Sets, unless the remote control contains very huge databases for
different TV sets; or unless the TV Set supports some learning function, such
as prompting the user to press the button that is to be used as Standby
button).<BR>
<BR>
<B>FF83h - IO_IR_stat_FF83h_used (R) ;lsb (firmware supports 00h or 86h)</B><BR>
<B>FF85h - IO_IR_stat_FF85h_used (R) ;msb (firmware supports FFh or 6Bh)</B><BR>
These registers seem to contain the received NEC device ID. In original NEC
protocol, the second byte would be just the inverse of the other byte (XOR
FFh). In later NEC extensions, the second byte can have other values.<BR>
The received NEC command (and some flags) are found in SFR area (SFR_IO_IR_data
&amp; SFR_IO_IR_flags). And, External Interrupt 0 is used for IR.<BR>
<BR>
<B>FF61h - IO_IR_config_FF61h ;=05h ;\</B><BR>
<B>FF62h - IO_IR_config_FF62h ;=3Fh ;</B><BR>
<B>FF63h - IO_IR_config_FF63h ;=10h ;</B><BR>
<B>FF64h - IO_IR_config_FF64h ;=04h ; ;&lt;--bit3-7: NOT RW</B><BR>
<B>FF65h - IO_IR_config_FF65h ;=76h ;</B><BR>
<B>FF66h - IO_IR_config_FF66h ;=3Bh ;</B><BR>
<B>FF67h - IO_IR_config_FF67h ;=08h ;</B><BR>
<B>FF68h - IO_IR_config_FF68h ;=15h ;</B><BR>
<B>FF69h - IO_IR_config_FF69h ;=07h ;</B><BR>
<B>FF6Ah - IO_IR_config_FF6Ah ;=00h ;</B><BR>
<B>FF6Bh - IO_IR_config_FF6Bh ;=00h ; ;&lt;--NOT RW (but is written!?!)</B><BR>
<B>FF6Ch - IO_IR_config_FF6Ch ;=00h ; ;&lt;--NOT RW (but is written!?!)</B><BR>
<B>FF6Dh - IO_IR_config_FF6Dh ;=00h ; ;&lt;--NOT RW (but is written!?!)</B><BR>
<B>FF6Eh - IO_IR_config_FF6Eh ;=00h ; ;&lt;--NOT RW (but is written!?!)</B><BR>
<B>FF6Fh - IO_IR_config_FF6Fh ;=76h ;</B><BR>
<B>FF70h - IO_IR_config_FF70h ;=1Ch ;</B><BR>
<B>FF71h - IO_IR_config_FF71h ;=08h ;</B><BR>
<B>FF72h - IO_IR_config_FF72h ;=F5h ;/</B><BR>
<B>FF77h - IO_IR_config_FF77h ;=59h ;\</B><BR>
<B>FF78h - IO_IR_config_FF78h ;=00h ;</B><BR>
<B>FF79h - IO_IR_config_FF79h ;=01h ;</B><BR>
<B>FF7Ah - IO_IR_config_FF7Ah ;=73h ;</B><BR>
<B>FF7Bh - IO_IR_config_FF7Bh ;=FFh ;</B><BR>
<B>FF7Ch - IO_IR_config_FF7Ch ;=02h ;</B><BR>
<B>FF7Dh - IO_IR_config_FF7Dh ;=0Fh ;/</B><BR>
<B>FF82h - IO_IR_config_FF82h ;=01h ;- ;&lt;--bit4-7: NOT RW</B><BR>
Initialized to above fixed values for NEC protocol (unknown how to
use/initialize RC-5 protocol).<BR>
Alongsides, SFR_IO_PORT0_MODE_A/B.bit3 should be configured before using IR.<BR>
<BR>
<B>FF73h..FF76h - probably IR related, 4 bytes</B><BR>
<B>FF7Eh..FF81h - probably IR related, 4 bytes</B><BR>
<B>FF84h - probably IR related, 1 byte (not R/W)</B><BR>
Unknown, not used by firmware. Probably IR related (as they are within the IR
register area).<BR>
<BR>
<B>FF86h - maybe IR related, 1 byte (not R/W)</B><BR>
<B>FF87h - maybe IR related, 1 byte (not R/W)</B><BR>
<B>FF88h..FF8Bh - maybe IR related, 4 bytes</B><BR>
<B>FF8Ch - maybe IR related, 1 byte (bit6-7: not R/W)</B><BR>
<B>FF8Dh..FF91h - maybe IR related, 5 bytes (not R/W)</B><BR>
<B>FF92h..FF9Eh - maybe IR related, 13 bytes</B><BR>
<B>FF9Fh - maybe IR related, 1 byte (bit6-7: not R/W)</B><BR>
<B>FFA0h..FFA3h - maybe IR related, 4 bytes</B><BR>
Unknown, not used by firmware. Maybe IR related (as they are located at the end
of IR register area). Or maybe LCD related, or something completely different.
There's no visible effect when changing bits in these registers.<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
____________________________ LCD Unused Registers ____________________________
</TD></TR></TABLE>
<BR>
<B>FFA4h..FFAFh - Unused (open-bus) (0Ch bytes)</B><BR>
<B>FFEBh..FFEFh - Unused (open-bus) (05h bytes)</B><BR>
<B>FFFCh..FFFFh - Unused (open-bus) (04h bytes)</B><BR>
<B>FFDDh - Unused (open-bus) (01h bytes)</B><BR>
Probably unused I/O addresses.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="amt630acomponentlistspinouts"></A>&nbsp;
AMT630A - Component Lists &amp; Pinouts
</FONT></TD></TR></TABLE><BR>
<B>Component List for 3.5 inch display (nocash)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
mainboard: "ZCD630A-3.5D_V1.1"
main chip: 64pin AMT630A (video controller with 8031 cpu)
firmware: 8pin "MK, 25D40BTIG, 1720" (512kbyte spi flash, D=DualDataPin)
voltage regulator 1: 8pin "XL1509" (pin1=Vin/12V, pin2=Vout/5V)
voltage regulator 2: 3pin (5V to 3.3V)
backlight driver: 6pin "7001" (Micrel MIC3287 or compatible)
connectors: 54pin display, 2pin keypad, 4pin video/supply, 4pin sio/unused
display: "RoHS 1580005880 111020, TM035KDH03, 76DK14A04A1 OMP 11111009, 1"
</TD></TR></TABLE>
<BR>
<B>Component List for 5.0 inch display (bigby)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
mainboard: "BO-39-Y-7795BH1" ?
main chip: 64pin "AMT630A, G171800030"
firmware spi flash: "MK, xxD040BTIG, S782A1"
voltage regulator: "RZC2013S, SZ82"
backlight driver "D2AxD ?"
connectors: 40pin display, 2pin keypad, 4pin video/supply, 4pin sio/unused
display "GP Innolux Display, AT050TN33 V.1 AA0500004101, S/N: 895W 001-000WB"
crystal "X27.000"
</TD></TR></TABLE>
note: firmware seems to be for 4.3 inch (probably AT043TN25, which has same
resolution as 5.0 inch AT050TN33)<BR>
<BR>
<B>Inches, Ratios, Resolutions</B><BR>
Below are some common dimensions for small/medium sized TFT screens. For
internet search engines it's best to enter the size and ratio, eg. "3.5" AND
"4:3" (that's reducing the likelyness of ratio "4:3" being mistreated as "4.3"
inches).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
3.5 inch 4:3 320x240
4.3 inch 16:9 480x272
5.0 inch 16:9 480x272 or 800x480
5.6 inch 4:3 1024x768 or 320x234? or 800x600?
7.0 inch 16:9 1024x600 or 480x234?
8.0 inch 4:3 1024x768
</TD></TR></TABLE>
And,<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
AV-to-USB video grabbers
</TD></TR></TABLE>
AMT630A chips are likely to be found in cheap displays (3.5", 4.3", 5.0" with
resolution 320x240 or 480x272) for around $15-$25. AMT630A chips can be also
found in AV-to-USB video grabbers (with an additional USB chip, instead of the
TFT display).<BR>
Theoretically, AMT630A does also support bigger displays with resolutions up to
1024x768, however, displays with higher resolutions and/or more than 5.0" are
usually more expensive (around $40), and they are likely to contain more
advanced video controllers (with RGB/VGA/HDMI video inputs).<BR>
<BR>
<B>AMT630A (64pin LQFP package)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Pin TYPE Function
1 A CVBS1 ;-external video YELLOW
2 A CVBS2 ;-GNDed
3 A CVBS3 ;-external video WHITE
4 A VCOM_ADC ;-
5 P AVSS_ADC (GND)
6 D P03 REMOTE ;-
7 A P00 SAR2
8 A P01 SAR1
9 A P02 SAR0 ;-Keypad
10 P DVDD 3.3V
11 P GND
12 P VDD 1.2v (build-in LDO for 1.2v core power)
13 P AGND (AVSS33_ANA)
14 A XTAL_OUT ;\27MHz
15 A XTAL_IN ;/
16 P AVDD 3.3V
---
17 D P10 SPI_CS ;\
18 D P11 SPI_SI ; SPI FLASH
19 D P12 SPI_SO ;
20 D P13 SPI_CLK ;/
21 P DVDD 3.3V
22 P VDD 1.2v (build-in LDO for 1.2v core power)
23 P GND
24 D P14 cpu_rstn R0 VOS tcon_r0 ituVDE sVSY ;\LCD. D
25 D P15 cpu_cs R1 HOS tcon_r1 ituHDE sHSY ; LCD. D
26 D P16 cpu_rs R2 DOE tcon_r2 ituDEO sDEN ; LCD. D
27 D P17 cpu_wr R3 DCK tcon_r3 ituclko sCLK ; LCD. D
28 D P20 cpu_rd R4 B7 tcon_r4 itu_d7 sD7 ; LCD. D
29 D P21 cpu_d17 R5 B6 tcon_r5 itu_d6 sD6 ; LCD. D
30 D P22 cpu_d16 R6 B5 STVR itu_d5 sD5 ; LCD. D
31 D GPIO0 cpu_d15 R7 B4 STVL itu_d4 sD4 ;/LCD. D (blue.7)
32 D GPIO1 cpu_d14 G0 B3 tcon_g0 itu_d3 sD3 ;\LCD. D
---
33 D GPIO2 cpu_d13 G1 B2 tcon_g1 itu_d2 sD2 ; LCD. D
34 D GPIO3 cpu_d12 G2 B1 tcon_g2 itu_d1 sD1 ; LCD. D
35 D GPIO4 cpu_d11 G3 B0 tcon_g3 itu_d0 sD0 ; LCD. D
36 D P23 cpu_d10 G4 G7 tcon_g4 ; LCD. D
37 D P24 cpu_d9 G5 G6 tcon_g5 ; LCD. D
38 D P25 cpu_d8 G6 G5 CKV ; LCD. D
39 D P26 cpu_d7 G7 G4 OEV ;/LCD. D (green.7)
40 P DVDD 3.3V
41 P VDD 1.2v (build-in LDO for 1.2v core power)
42 P GND
43 D GPIO5 cpu_d6 B0 G3 tcon_b0 itu_d0' sD0' ;\LCD. D
44 D GPIO6 cpu_d5 B1 G2 tcon_b1 itu_d1' sD1' ; LCD. D
45 D GPIO7 cpu_d4 B2 G1 tcon_b2 itu_d2' sD2' ; LCD. D
46 D GPIO8 cpu_d3 B3 G0 tcon_b3 itu_d3' sD3' ; LCD. D
47 D GPIO9 cpu_d2 B4 R7 tcon_b4 itu_d4' sD4' ; LCD. D
48 D GPIO10 cpu_d1 B5 R6 tcon_b5 itu_d5' sD5' ; LCD. D
---
49 D P27 cpu_d0 B6 R5 STHR itu_d6' sD6' ; LCD. D
50 D P30 cpu_rd B7 R4 POL itu_d7' sD7' ;/LCD.35 D23 (red.7)
51 D P31 cpu_wr DCK R3 tcon_clk ituclko' sCLK' ;\LCD.38 CLK
52 D P32 cpu_rs DOE R2 STHL ituDEO' sDEN' ; LCD.52 DEN
53 D P33 cpu_cs HOS R1 OEH ituHDE' sHSY' ; LCD.36 HSYNC
54 D P34 cpu_rstn VOS R0 tck2 ituVDE' sVSY' ;/LCD.37 VSYNC
55 D P35 DC_PWM0 ;backlight driver (via 1K ohm)
56 D P36 DC_PWM1 TXD'' ;display spi.dta (via 33 ohm)
57 D P37 DC_PWM2 RXD'' ;display spi.clk (via 33 ohm)
58 D P07 DC_PWM3 RXD' ;display spi.cs (via 33 ohm)
59 D P06 DC_PWM2' TXD' ;display spi.reset (via 33 ohm)
60 D P04 SDA TXD ;to external connector
61 D P05 SCL RXD ;to external connector
62 P DVDD 3.3V
63 D RESET ;-reset (active HIGH)
64 P AVDD_ADC 3.3V
</TD></TR></TABLE>
<BR>
<B>Firmware FLASH (8pin "MK, 25D40BTIG", 512kbyte spi flash, D=DualDataPin)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1 /CS
2 DO
3 /WP (VCC'ed)
4 GND
5 DI
6 CLK
7 /HOLD (VCC'ed)
8 VCC (3.27V) (even when video off)
</TD></TR></TABLE>
<BR>
<B>Backlight driver "7001" (aka Microchip/Micrel MIC3287, package TSOT-23-6)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1 SW Switch Node ("Input"): Internal power bipolar collector
2 GND Ground
3 FB Feedback (input): Output voltage sense node.
4 EN Enable (input): High=enable, Low=Shuts Down ;PWM
5 OVP Overvoltage Protection (Input): Connect to the output ;LED Anode
6 VIN Supply (input): 2.8V to 6.5V for internal circuitry ;5V
</TD></TR></TABLE>
Pin3 (FB): Connect the cathode of the LED to this pin. A resistor from this to
ground sets the LED current.<BR>
<BR>
<B>Innolux TFT LCD Panel Driving Section</B><BR>
FPC Connector is used for the module electronics interface. The recommended<BR>
model is FH19SC-40S-0.5SH manufactured by HIROSE.<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
Pin Symbol I/O Function Remark
1 VLED- P Power for LED backlight cathode ;\backlight
2 VLED+ P Power for LED backlight anode ;/
3 GND P Power ground ;\supply
4 VDD P Power voltage ;/
5 R0 I Red data (LSB)
6 R1 I Red data
7 R2 I Red data
8 R3 I Red data
9 R4 I Red data
10 R5 I Red data
11 R6 I Red data
12 R7 I Red data (MSB)
13 G0 I Green data (LSB)
14 G1 I Green data
15 G2 I Green data
16 G3 I Green data
17 G4 I Green data
18 G5 I Green data
19 G6 I Green data
20 G7 I Green data (MSB)
21 B0 I Blue data (LSB)
22 B1 I Blue data
23 B2 I Blue data
24 B3 I Blue data
25 B4 I Blue data
26 B5 I Blue data
27 B6 I Blue data
28 B7 I Blue data (MSB)
29 GND P Power ground
30 CLK I Pixel clock
31 DISP I Display on/off
32 NC - No Connection
33 NC - No Connection
34 DE I Data Enable
35 NC - No Connection
36 GND P Power ground
37 X1 I/O Right electrode - differential analog ;\
38 Y1 I/O Bottom electrode - differential analog ; touchpad
39 X2 I/O Left electrode - differential analog ; (unused)
40 Y2 I/O Top electrode - differential analog ;/
I: input, O: output, P: Power
</TD></TR></TABLE>
<BR>
<B>Tianma Display Pinout (ribbon cable)</B><BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
1 LED_Cathode ;\ ;\GND via 2.2 ohm
2 LED_Cathode ; backlight ;/
3 LED_Anode ; ;\
4 LED_Anode ;/ ;/
5 NC ;\
6 NC ; not connect
7 NC ;/
8 RESET ;-reset
9 SPENA ;\
10 SPCK ; SPI bus
11 SPDA ;/
12 D00 ;\
13 D01 ;
14 D02 ;
15 D03 ; LCD
16 D04 ;
17 D05 ;
18 D06 ;
19 D07 ;/
20 D08 ;\
21 D09 ;
22 D10 ;
23 D11 ; LCD
24 D12 ;
25 D13 ;
26 D14 ;
27 D15 ;/
28 D16 ;\
29 D17 ;
30 D18 ;
31 D19 ; LCD Red (in default 24bit+HV mode)
32 D20 ;
33 D21 ;
34 D22 ;
35 D23 ;/
36 HSYNC ;\LCD Sync (in default 24bit+HV mode)
37 VSYNC ;/
38 CLK ;-data clock
39 NC ;\not connect
40 NC ;/
41 VDD ;\power 3.3V
42 VDD ;/
43 NC ;\
44 NC ;
45 NC ; not connect
46 NC ;
47 NC ;
48 NC ;
49 NC ;
50 NC ;
51 NC ;/
52 DEN ;-LCD data enable
53 GND ;\ground
54 GND ;/
</TD></TR></TABLE>
<BR>
<B>SPI FLASH to Parallel Port</B><BR>
No$x51 includes a function for uploading binaries to SPI FLASH via parallel
port, this is very useful for uploading/testing binaries on hardware (leaving
apart that I don't know of anybody else owning a parallel port).<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
AMT630A side PC Side (36pin Centronics or 25pin SUBD)
DTA.W FLASH.pin5 ----[1K]---- D0 CNTR.pin2 SUBD.pin2
CLK FLASH.pin6 ----[1K]---- D1 CNTR.pin3 SUBD.pin3
/CS FLASH.pin1 ----[1K]---- D2 CNTR.pin4 SUBD.pin4
DTA.R FLASH.pin2 --[74HCxx]-- BUSY CNTR.pin11 SUBD.pin11
RESET AMT630A.pin63 ----|&lt;|----- /INIT CNTR.pin31 SUBD.pin16
GND SUPPLY.Black ------------ GND CNTR.pin19-30 SUBD.pin18-25
</TD></TR></TABLE>
RESET is active HIGH, it's used to stop the 80C52 CPU and to prevent it
accessing the SPI bus during uploads; the diode just prevents it from getting
pulled LOW when not issuing reset.<BR>
D0,D1,D2 are SPI outputs from PC, the 1K resistors NEEDED (else AMT630A won't
work even when PC data lines are HighZ).<BR>
BUSY is SPI input on PC side, passed through some noninvering 74HCxx AND/OR
gate (else FLASH chip freaks out about 5V pullup from PC).<BR>
The above circuit is far from perfection. I've tested it with two parallel
ports, one didn't work, the other does work, although it tends to reply with a
wrong FLASH chip ID after booting the PC - but that can be fixed by unplugging
the AMT630A power supply for a moment.<BR>
When designing a better voltage conversion circuit, mind that PC outputs need
to be switched off after upload, so that the AMT630A can access the SPI bus
once when RESET is released.<BR>
No$x51 software notes: Select the LPT port in no$x51 setup. Load a binary (or
assemble some source code), then use the file/upload function. Upload should
work with known FLASH chip IDs (such as MK 25D40), but may fail if you have
another/unknown FLASH chip.<BR>
<BR>
<BR>
<!--------------------------------------->
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0><TR bgcolor="#cccccc"><TD><FONT SIZE=+2>
<A NAME="index"></A>&nbsp;
Index
</FONT></TD></TR></TABLE><BR>
<A HREF="#contents">Contents</A><BR>
<A HREF="#nox51featuresabout">No$x51 Features/About</A><BR>
<A HREF="#memoryandregistermap">Memory and Register Map</A><BR>
<A HREF="#externalioports">External I/O Ports</A><BR>
<A HREF="#timers">Timers</A><BR>
<A HREF="#timer0and1">Timer 0 and 1</A><BR>
<A HREF="#timer2">Timer 2</A><BR>
<A HREF="#timer3watchdog">Timer 3 (Watchdog)</A><BR>
<A HREF="#serialuartrs232port">Serial UART/RS232 Port</A><BR>
<A HREF="#seriali2cbusport">Serial I2C-Bus Port</A><BR>
<A HREF="#analogdigitalconverter">Analog/Digital Converter</A><BR>
<A HREF="#pulsewidthmodulatedoutputs">Pulse Width Modulated Outputs</A><BR>
<A HREF="#interrupts">Interrupts</A><BR>
<A HREF="#syschipcontrolregisters">SYS Chip Control Registers</A><BR>
<A HREF="#cpumicroprocessor">CPU Microprocessor</A><BR>
<A HREF="#cpuregistersandflags">CPU Registers and Flags</A><BR>
<A HREF="#cpuarithmeticoperations">CPU Arithmetic Operations</A><BR>
<A HREF="#cpulogicaloperations">CPU Logical Operations</A><BR>
<A HREF="#cpudatatransfer">CPU Data Transfer</A><BR>
<A HREF="#cpuprogrambranching">CPU Program Branching</A><BR>
<A HREF="#cpunotes">CPU Notes</A><BR>
<A HREF="#flasheeprom">Flash EEPROM</A><BR>
<A HREF="#feepromuseraccess">FEEPROM User Access</A><BR>
<A HREF="#feepromsecurity">FEEPROM Security</A><BR>
<A HREF="#feepromparallelprogramming">FEEPROM Parallel Programming</A><BR>
<A HREF="#feepromserialprogramming">FEEPROM Serial Programming</A><BR>
<A HREF="#cirbasicconnectioncircuits">CIR Basic Connection Circuits</A><BR>
<A HREF="#cirresetcircuit">CIR Reset Circuit</A><BR>
<A HREF="#ciroscillatorsystemclock">CIR Oscillator (System Clock)</A><BR>
<A HREF="#cirpinouts">CIR Pin-Outs</A><BR>
<A HREF="#auxexternalhardware">AUX External Hardware</A><BR>
<A HREF="#auxnumerickeypad">AUX Numeric Keypad</A><BR>
<A HREF="#auxlcddotmatrixmodule">AUX LCD Dot Matrix Module</A><BR>
<A HREF="#amt630amemorymap">AMT630A - Memory Map</A><BR>
<A HREF="#amt630asfrssystemtimersportsetc">AMT630A - SFRs - System Timers/Ports/etc</A><BR>
<A HREF="#amt630afbxxhosdregistersonscreendisplay">AMT630A - FBxxh - OSD Registers (On-Screen Display)</A><BR>
<A HREF="#amt630afcxxhlcdregistersmostly50hz60hzratio">AMT630A - FCxxh - LCD Registers (mostly 50Hz/60Hz/Ratio)</A><BR>
<A HREF="#amt630afdxxhmiscregisterspwmadcpllpinspiflash">AMT630A - FDxxh - Misc Registers (PWM,ADC,PLL,PIN,SPI-FLASH)</A><BR>
<A HREF="#amt630afexxhavregisterscompositevideoinput">AMT630A - FExxh - AV Registers (Composite Video Input)</A><BR>
<A HREF="#amt630affxxhlcdregistersgammabrightnessetcandir">AMT630A - FFxxh - LCD Registers (gamma/brightness/etc and IR)</A><BR>
<A HREF="#amt630acomponentlistspinouts">AMT630A - Component Lists &amp; Pinouts</A><BR>
<BR>
[extracted from no$x51 v1.5 documentation]<BR>
</BODY></HTML>
Reference in a new issue View git blame Copy permalink