AMT630A firmware for mini TFT screens

AMT630A
The AMT640A is a relative common video controller chip found in cheap mini TFT screens with composite input.
Those screens are often sold as "car rear view monitor" (or by similar names), although they are essentially fully-fledged portable TVs (minus tuner/speaker, and without advanced inputs like S-video or RGB).
The chip contains a 8031/8051 microprocessor, with firmware stored on an external SPI-bus FLASH memory chip.
Theoretically, it could be used as miniture monitor for gaming consoles. Unfortunately, it's working rather disappointing in practice:

• Display is having some vertical-interlace-style flickering (even on non-interlaced pictures).
• With 320x240 pix screen, resampling is smeared, possibly a bit uglier than required...
• For NTSC, one could theoretically leave blank lines (with black borders)
• For PAL, one could theoretically crop lines (eg. on homecomputers with 200 lines)
• PAL60 produces wrong colors.
• PAL60 forgets to update some scanlines (and draws wrong/older lines).
• Backlight is at max brightness and cannot be changed.
• Reportedly, signals from C64 aren't recognized (not tested myself yet).

Some of that issues might be firmware related. So I've spent 2-3 weeks on disassembling it: http://problemkaputt.de/amt630a.htm (AMT630A firmware disassembly, for 320x240 pixel 3.5" screen with 4:3 ratio). The disassembly is working as source code and can be re-assembled via no$x51. All code addresses are represented by lablels, so inserting custom stuff in code memory should work (whilst RAM/XRAM addresses are still hardcode, so better don't insert new stuff there; there are unused locations that could be used though).

I would be also interested in dumps from other firmware versions...

• firmware for screens other than 320x240 pixels
• firmware for 16:9 wide screens
• firmware with infrared IR input support
• firmware with volume control support
• AMT630 firmware (to see if it's similar/compatible to AMT630A)
• other older/newer firmware revisions
• etc.

That stuff would help on finding which I/O ports have which functions (eg. for changing the screen resolution/resampling).

More notes on the hardware's component list and on SPI FLASH dumping are at the bottom of the disassembly. The AMT630A spec sheet doesn't contain any info about I/O ports, but the disassembly should explain the coarse functionality of the ADC, PWM, OSD registers, as well as SPI busses for FLASH (and LCD). For the composite to LCD video conversion, there are a lot of fixed initialization values - which, one could try to change them & see what happens...

A random source claims it is a clone of the MST703, for which I was able to find a datasheet that includes register definitions... in case that helps.

I've also been able to find a reference schematic on baidu ("AMT630_CAR_V3.4") , but they won't let me download it without logging in :/

Yes, I know that claim about AMT630 being a MST703 clone.... if the AMT630 is working similar to AMT630A then it's nonsense: The AMT630A registers at FB00h-FFFFh don't match up with the MST703 datasheet at all.

Apropos registers. The AMT630A spec sheet claims that it has some "standard" stuff like timer2 and watchdog. I know some 8031 variants with watchdogs at either SFR register FFh, or A6h. But the AMT630A seems to have the watchdog controlled via SFR registers B9h, BAh, BBh, BCh, BDh, and BEh. Are that really standard registers used in other 8031 variants, too?

The jittery vertical lines are this sort of thing : http://www.lagom.nl/lcd-test/inversion.php

If you're lucky there's a small pot that allows to change the bias point and make both sides equal and reduce the flicker effect (it will not however completely fix it).

There are also some other controllers out there which require external MCU to do the work, and some do have their registers all available in a datasheet. I have one such somewhere and one day when I'm no longer lazy I'll write up a new MCU that enables RGB input (or very least YC) and adjusts geometry and timings etc. to suit particular machines.

If you manage to make it work, I'd get one, and probably many others too. Lots of sales for the chinese

Got a new firmware update finished. The original firmware code is used only for initializing some I/O ports, and then it's jumping to my own custom code, which is experimental stage at the moment: It's going right to a debug menu allowing to test various hardware functions; memory dump, color changes, bitmap rendering at different font widths/color depths, flipping I/O bits, ADC button reading, etc.

Apart from the newly added firmware code, the disassembly of the original code is a bit more complete (with symbolic names for all used hardware registers), the rev-engineered hardware registers are now also described in a fullsnes/gbatek-style document, and after getting bored of reflashing the firmware, I've also emulated the amt630a hardware in no$x51.

And... I guess now somebody will shout "I knew it, I really really knew it, I knew that he would port the game to the AMT630A" - there's also a Magic Floor version included in the firmware. It's been helpful to get familar with the odd OSD video memory addressing, and it's been a bit challenging to get it working with 3-button keypad (it's using MENU to toggle horizontal/vertical direction, and tapping/holding Plus or Minus for short/long moves - which, I thought it would become rhetorically (un-)playable, but it's actually working quite well, apart from the buttons being quite small).

http://problemkaputt.de/amt630a.htm - new AMT630A firmware disassembly with added custom source code
http://problemkaputt.de/x51.htm - AMT630A emulator/debugger
http://problemkaputt.de/x51specs.htm - specifications for AMT630A memory map and hardware registers

For fixing the original firmware issues: I've found a bit that makes it recognize C64 video signals (another approach without firmware pataching, discovered by other people would be using an external sync separator, and then merging the extracted sync signal back to the C64 composite signal). Displaying PAL60 is possible, but it's still a bit flimmering, and the PAL60 patch will make it incompatible with NTSC signals (and might currently even screw up PAL50, though that would be fixable). And the painfully bright backlight, I got it dimmed using a PWM signal with 50% duty, which is looking much more moderate. And, if I have measured it properly, it seems to have dramatically reduced the power consumption from 1.17W to 0.05W for the backlight (plus 0.28W for the remaining hardware).

Ah, and here are some pictures showing the original 3.5inch screen with dangling cables in the weird case with 16:9 form factor, and my own case with rear sockets and true 4:3 form factor.

Is the backlight CCFL or LED? I'm having difficulty coming up with obvious explanations for why 50% duty would consume 1/26th the current, even assuming some kind of boost converter

I don't know what happened there, or if I screwed up generating an exact 50% duty signal, or failed on measuring the amperes. What I can tell for sure is that the backlight is darker, and that the screen doesn't warm up any longer, so I've definetely saved some energy.

And, what I've noticed is that 50% isn't always 50%. The backlight stays black when using duty=0080h/total=0100h, but it's neatly dimmed when using duty=0800h/total=1000h (ie. same signal 16x slower). Maybe something is clipping too short pulses (and if my current pulses are still too short, then I might be effectively below 50%). The PWM cycles are counted in in 26MHz units, so total=100h should be 101kHz, and total=1000h should be 6.3kHz.

I have no idea which PWM rate would be optimal for backlights, the datasheet for the backlight driver is confusing me (as far as I understand one can use PWM or analog/resistor for selecting the brightness, and the datasheet says that the advantage would be that PWM works without needing PWM for generating the analog level... or something like that).

The backlight driver is a 6pin "7001" (seems to be Micrel MIC3287 or compatible).
The display is "Tianma TM035KDH03" (which is said to have a WLED backlight).

Optimal at least for light pen use with Zapper-style hit detection would be 15.7 kHz, same as SDTV line rate. Because all the rows are lit, you won't get the positional output that things like Operation Wolf rely on. But at least we can see some ducks die.

The display's datasheet claims each strand of LEDs wants ≈20mA at ≈6×3.3V, or roughly 20V; at peak power that should be roughly 400mW ... I guess 800mW for both strands? Obviously running the LEDs hotter does make them brighter (at the cost of shortening their lifetime)... Theoretically the current-setting resistor should be 6 ohms.

Assuming that the MIC3287's datasheet is representative, it says that
Even though the boost converter says it operates at 1.2MHz, it takes many cycles for the output voltage to stabilize; the reference schematic uses a 10µH inductor and 220nF capacitor and that has a time constant of roughly 70kHz . So the system can't really respond faster to perturbation than that... which doesn't really explain why 101kHz almost doesn't work at all. (Of course, maybe the actual board here uses parts with a slower time constant)

I have a display with one of these controllers, and it's a nice 640x480 one that'll take VGA. I hoped to modify the firmware to have it line double a 15KHz RGB source instead.

The flickering I think is a result of the LCD itself, not the display controller. I am pretty sure a regular progressive scan is sent to the LCD.

Uhm, I am feeling a bit uneasy about that game, I get the idea about shooting enemies because they are ugly, dangerous, or guilty... but shooting cute harmless innocent ducks just for the fun of it - that's about the scariest killing game that I could think of (next to PSX fishing games).
Technically, yeah, the 15.7kHz backlight might work for early lightgun games (ie. those that display a white rectangle at the target location), I guess, for distinguishing between TV and normal light sources, that games check for 15.7kHz light flashes, and/or for no light during vblank? The latter would be more difficult.

Oh, and another unexpected side effect would be classic 15.7 kHz noise. I've just noticed that I am hearing some feeeep sound on my PC's speakers, especially with higher backlight duties in 70%...99% range (and the sound it goes off when using 100%). The PC and TFT screen are sharing the same GND, and also the same 5V supply. Easiest workaround would be to use some higher/inaudible PWM rate like 30kHz.

And I am wondering, what is better for backlights: A constant HIGH duty, or a constant TOTAL duty? At the moment, my PWM output uses constant TOTAL (6.3kHz), and the backlight slider allows to change the HIGH duty from 0% to 100%, one small problem is that 1%..13% are leaving the screen completely black.
Ie. instead of dimming by decreasing the HIGH time, it might be better to maintain some fixed HIGH time, and instead increase the LOW time?


Are you sure that you have VGA input... on these AMT630A chips? As far as I know they support composite only (and maybe S-Video, at least on older AMT630's).
The flickering occurs on the floor cells in Magic Floor SNES version. On the other hand, the Magic Floor AMT630A version doesn't flicker. So the TFT seems to be okay, but the displaying the AV signal is somewhat unstable. Not sure what is happening there, the theory about interlace might be wrong, maybe the thing is permanently trying to re-calibrate itself to the incoming signal, or maybe the SNES signal itself is unreliable (gotta check back if the game has similar flicker on a real CRT).

---

Btw. can somebody recommend an audio amplifier for the two speakers? I have 5V power supply, and the speakers are around 1W each, and it would be nice to some volume regulator that could be driven via PWM, and, some way to force the amplifier to low power standby mode (or automatically having near zero power consumption when receiving "nothing" on the L/R audio inputs).

What I have at home is a TDA1308 Class-AB stereo headphone driver (might be a bit weak, but maybe better than raw unamplified audio), and two mono LM386N-1 amplifiers (which might be more suitable). The TDA and LM's don't have a volume regulator input though.
And the speakers are two "VECO 35KN04" ripped from some old dead notebook. I've somehow managed to find some specs on http://www.veco.com.tw/cgi-bin/product-search.cgi (despite of 99% broken links at veco.com.tw):
So 35KN08 would be 35x16x4.2mm, 8 ohms, and, hmmm, 1000-1500 "mini watts", whatever that is, probably milliwatts.
And mine are 35KN04, which should translate to same size, 4 ohms, and... maybe similar watts.

Unfortunately, it depends on the boost converter that's used to drive the backlight itself.

But, given your previous observation that too-high PWM frequencies cause the backlight to not light, I wouldn't be surprised if the boost converter consistently takes some small number of microseconds after its ENABLE input goes true before the output voltage is high enough to light the LEDs.

So ... yeah, your guess of only adjusting the off time sounds good to me.

Quickly looking through digikey's selection for audio amplifiers with both volume control and standby or shutdown modes, the first cheapest options are: LM4811, TDA8551, MAX9723, TPA6130, TPA2028, LM48824, TPA6140, LM4875, and AN7510. All of these are 1 to 2 USD in qty 10, although obviously availability and pricing for you will vary.

Dear nocash.

I want to ask few questions, if you can reply, i will be happy.

I have an electronic device, it's sizes are 25 mm x 25 mm about, it has 2 side PCB, one side is AMT630 + 25S40 flash and other side is V399 + 24C32 flash and some resistors and capacitors, etc... Device has a 12.00 MHz crystal on it. It has auto select for PAL and NTSC cameras.

I am connecting 5.8 GHz AV wireless Receiver to my device IN ports (Video signal and Ground) and OUT ports (5V, Ground, D- and D+) to Android phones with micro USB, with a Google Play app, it shows Video on the phone's screen. (V399 is for USB connection) Device is working good on 640 x 480 resolution as well. But I have problem with BLUE SCREEN (when no signal from AV Receiver)

My questions :

1) I think so, there are 3 type AV input sensitivity level og AMT630 (FE15h - IO_AV_ctrl_sensitivity_0 , max, med and low) What is the advantage of mid and high? High level can be good solution for to boost of weak signal of AV Receiver's Video signal.

2) AV Receiver produce its own static snow when get "no signal" from AV Transmitter. For to eliminate the BLUE SCREEN, can i use AV Receiver's SNOW SIGNAL on the Phone's screen?.

3) If it is not possible, can i use AMT630's generated SNOW SCREEN?

I don't need OSD, my only problem is Blue Screen. I am using your No$x51 emulator as well, it show SNOW Screen (that i want) on and under the OSD band, when your BIN code animate.

Many thanks for your help.

Your device doesn't have any LCD screen at all - and instead it's having USB video output? Interesting to know. I wasn't aware of the AMT630's being used that way, but now that you mentioned it, I've found some webpages about AV to USB video grabbers with AMT630(A) chips.

What is the problem with BLUE screen? It's showing up fine - and you just want it to show the SNOW effect instead of the BLUE screen? If your firmware works similar as mine: Try the secret key combos: Menu,+,-,-,+,+ or Menu -,+,+,-,- that should get you to the Version and Factory Menu screens. EDIT: If you do have any buttons on the video grabber device at all?

Be careful with changing some of the factory settings. Best scribble down the original settings on a piece of paper before messing atound with them (in case there are any calibration values in there). And don't change the KEYpad type (that'll make the keypad input nonfunctional, unless you do actually connect the newly selected keypad hardware, or until you reflash the firmware chip). Apropos firmware - any chance that you could dump the flash chip(s)?

Not sure what port FE15h is doing, or if I've really named it properly when calling it IO_AV_ctrl_sensitivity_0. I guess it does just help on recognizing the incoming AV signal, it isn't directly related to BLUE-or-SNOW, but it might effect Signal-or-NoSignal, and maybe also the appearance of Snow (it looks as if the Snow is generated by digital random generator, but rather by amplifying analog noise from the AV inputs). For the other register, I've just observed that changing to 00h (or the power-up default value A1h) helps on reducing power by 2mA in standby mode, whilst using setting 00h outside of standby mode does produce oddly different gray snow when having NoSignal.

---

Btw. does anybody know how to deal with the russian http://remont-aud.net/dump/car_audio/ca ... nitors/356 ? Going by the word "dump" in the URL, that page seems to have firmware dumps for dozen(s) of AMT630 and AMT630A displays? Using translate, the separate pages are saying that one must register & login & solve some electronics test before being allowed to download "the file" (which might be a firmware dump... which would be actually interesting).

The registration form is in russian, and it looks rather indiscrete (like asking for the name & nationality of your grandmother), and it's announcing severe punishments in case of incorrect answers, and seems to want to enter cyrillic text for the captcha. Fortunately, there are fake accounts, like this:
user: nbm
pass: bugmenot
That did actually work for me. The problem is that it does no longer display the public webpage at all once when logged in (least allowing to download the damn files), instead it did merely say "technical work under way" in russian. Some hours later it changed to saying that "you belong to a group of members that is not allowed to view this page" also in russian.

So, logging in seems to make things worse and just adds further restrictions. Maybe passing that electronic test would unlock those restrictions... though, once when logged in, it doesn't even show the link for getting to the damn test anymore (when not logged in, it's saying one must register and login before allowing to accomplish the damn test).

Looking at other forums that are discussing AMT630(A) chips, most of the western world is annoyed by that russian page prohibiting to download their firmware dumps - suckers - then on other hand, maybe it'd be time for some non-russians to do their dumps instead of complaining about it ; )

---

So far, I've my own firmware for 320x240 pixel Tianma 3.5" display. And also got another dump for a 480x272 pixel Innolux 4.3" (and 5") display. The 2nd dump did help to track down settings for different resolutions (though I still haven't completely figured out which value is having which effect on horizontal and/or vertical AV and/or TFT timings/scalings).

And the Innolux dump also contained code for Infrared support - it seems to support a few nonstandard codes for NEC protocol only. Going by the datasheet, the hardware should also support the more standarized Philips RC-5 protocol, but I don't know how to implement that in software yet (nor what kind of IR components it would require to be connected to the REMOTE pin).

Many thanks for your reply nocash.

I will buy an EZP2010 type flash programmer. I will try to read the BIN code in my 25S40 chip, but i am not familiar to protected or unprotected chips. I hope i can read easily.

I want to ask a question nocash, I am using your No$x51 emulator and i am loading your AMT630A.BIN file.
Please look to attached photo : https://i.hizliresim.com/z0MaYD.jpg

My question : Red color place codes are special for your AMT630A.BIN ??? or if i load my flash chip's BIN file, can i get similar codes in Red color place? (different than your BIN code, is the red color place will be empty?)

Many thanks for your help.

I've updated the emulator/debugger, the AMT630A hardware specs, the firmware disassembly - and also finished my own custom firmware, which is fixing many of the issues found in original firmware.

The disassembly does now cover two different firmware versions.
The hardware specs include a lot more info on SPI-FLASH ports, Infra-red, PLLs, IRQs.
The magic floor game is more polished, with fade-in/out effects, and text line wrapping matched to screen size, and more floor sizes (the bigger sizes being unlocked after solving several games; with game position stored in FLASH memory).
The emulator/debugger now has support for Font DMA, more IRQs (adc conversions, and the newly discovered framerate irq), and fixes an assembler bug for "or c,bit" and "and c,bit" opcodes.
The new firmware has a bunch of features:
- backlight dimming (saving energy and being less painfully bright)
- low power standby mode with 8.4mA at 5V (unlike 33mA in original firmware)
- support for C64 video signal
- support for PAL60 (still imperfect, it works, but there's some flimmering, probably needs better timings)
- better GUI (without the annoying timeouts, and with black outlines on font characters for better visibility on bright backgrounds)
- xflip/yflip gimmick (except: doesn't work with Innolux displays as they don't have any spi bus).
- support for four display types (Tianma3.5", Noname3.5", Innolux4.3" and Innolux5.0") (the firmware should prompt for display type upon first use, or, to change it at later time: hold down MENU at power up).


The window at left side is showing the disassembled code from your BIN file, you can use any BIN file you want. If you dump your own firmware would be very interesting - I guess it's using different picture resolutions than the TFT screens, and as far as I understood, it's a AMT630, not a AMT630A? That might be yet different, but also interesting. There is no read protection on the flash chips so reading should be no problem. For writing, you may need to clear some write protect flags before writing, but it isn't too difficult (and your flash software should probably support doing it automatically).


V399 doesn't sound like a valid part number. This page http://foscam.us/forum/mjpeg-cameras-ha ... tml#p34007 says that the full name might be "Arkmicro ARK3399" - there's some sort of datasheet for that chip, but it's in "doc" format, with online viewers it's showing only more or less garbled text. It seems to be a 48pin chip (?) and maybe one could view the pinout using whatever dedicated "doc" viewing tools (microsoft word maybe) (if anybody succeeds, please post a screenshot).

I found an "online viewer" of a PDF file. I think it wanted me to sign up to download the original PDF, so I just took screenshots and copied the text:
ark3399.zip, 2.92 MB.

(I also found an "online viewer" of a DOC file, but it seemed to be a text-only conversion from the original PDF.)

Many thanks! The pin-out picture looks nice, and the .txt file with the pin/descriptions also looks less distored than what I had found online. Now I am wondering if the pinout does match for the V399 chip on Bipsiljo's board.

Couple of years ago I bought really cheap a few non-working portable LCDs for testing.
One of them that gave the best results (*) was based on MST702 chip.

The one I bought had the chip burnt, but I was able to order a few on aliexpress and replace them (really cheap, around 1.5$/piece).
I was able also to find use case datasheet, they work with LCD screens with 26 pin ribbon cable.

(*):
* Very good image quality, without adding any dostortion/vertial lines/noise, no picture shaking
* Works both with PAL/NTSC, colours are correct
* Has built in support for 4:3/16:9 ratio switch, colour/brightness adjustment
* Works with zapper

I would be interested in properly enabling the S-video input on many of these. The Sega Nomad produces S-video internally already from the CS1645, and people tend to use these screens with composite video when replacing a Nomad display. It would be a big improvement to use S-video here.

What do you mean when saying "of these"? This thread is about AMT630A chips, or, if you are talking of something else, please clarify which chip you are talking about.

I've been able to register AND succeeded the electronic test. But there is still a limitation on downloading : a credit system, and a 4 files / day limitation.

Attached are the dump I found, and I still have to dump the two screens I have : a 320x240 like yours, and a bigger one, with IR and buttons.
But I can't use parallel port on my computer, I'll try with a teensy.
Maybe you should upgrade your connection method : instead of using parallel, try a microcontroller with USB.

Cool, I had given up any hope to see any of those remont files (and wasn't even sure if those files were meant to contain flashrom-images).
The third file, "56231_backup_SPI_014.rar [20.96 KiB]" looks corrupted, I can't decompress it.

The other two files have some ascii strings in there that I haven't seen in the two previously dumped firmwares: The monitor.bin files seems to contain another language. And the 25q40_old.bin file has stuff like VERTICAL, HORIZONTAL. and FM 88.7 MHZ and A: 2.3M - 2.8M and PAL60. Hmmm, but the file is from 2015, and the later version from 2016 doesn't support PAL60, maybe those strings are just unused/garbage, unrelated to AMT630A hardware.

I haven't looked at the binary code yet, and didn't check which resolutions they are for (too busy with the new unlaunch exploit for DSi). A firmware with resolution other than 320x240 and 480x272 would be interesting. And a AMT630 firmware would be also interesting. Is it possible to download more files, or does that credit system prevent that?

I've downloaded most of AMT's firmwares I've seen, but there may be more. Searching on a russian forum isn't easy ^^
Attached are the firmware I downloaded, and 56231_backup_SPI_014 repacked.

another one firmware for AMT630 with 1024x600 resolution.

Thanks, 1024x600 sounds interesting (especially for better understand of how to compute the resolution-specific values). The file is a good bit smaller than expected... did you crop the FFh-filled bytes (and user settings)? And is it really for AMT630? The binary looks more like AMT630A.

I've downloaded two pre-AMT630A versions (with help from Zonomi), the files are attached below, one is for "AMT630", the other for "AMT629" (which I didn't even knew that it does exist before downloading the file (meanwhile I noticed that some webpages also mention "AMT628")).
Running in no$x51, both AMT630 and AMT629 firmwares are doing an access to an uncommon I/O address, I haven't really investigated why they are doing that, maybe it's just a minor software difference, or the hardware is having different I/O ports (or different addresses for the ports).
Anyways, they are still similar to AMT630A, and I think it's now safe to say that AMT630 is definetely NOT a MST703 clone.

Hello from Russia!

I have read about your problem and can help download files from the Russian site. It uses the points system. The beginner is given 50 points, download one file costs 2 points. I have 30 more points left.
For uploading 1 file is given 1 point, firmware 5 points, etc.
Now I'm working with a small auto monitor. Its firmware coincides with WD-888 from the post of Zonomi.

My goal is to disable the blue screen. For disassembling I use the IDA pro.
I tested your firmware (amt630a.bin), but it does not work with my keyboard, although it also has three buttons and resistors.
Apparently it's connected to the wrong pin. In my monitor it's pin 8 of the AMT630a chip. How is it connected to your monitor? Which AMT630a pins correspond to the TX and RX of the UART port?

Pinouts are shown in the "AMT630A - Component Lists & Pinouts" chapter (in no$x51 help text, or in the x51specs.txt/htm files on the no$x51 webpage). The keypad resistor values are also in that document (in the chapter with AMT630A Misc I/O ADC/etc). The keypad common pin could be GND (usually) or VCC (seems to exist, too).

Pin8 would be ADC1 input, the firmwares I know are using Pin9/ADC0, so your board actually won't work for that reason. Does your board have anything wired to the other two ADC inputs (aka SAR inputs which seems to be their official name)?

My firmware source code would be worth 5 points? If I would have known that, then I would have been better off to get a newbie account with 50 points for free ; )

Wow! It really work.
It turns out the pinout AMT630 vs AMT630a is very different.I used the wrong datasheet.
Now I have connected pin8 & pin9 with a soldering iron and added resistor between this input and 3.3v, so that the divider voltage falls within the required range.
All three buttons work fine! Thank you!
Maybe in source code you can add the ADC input definition?

I will check the remaining firmware for AMT630a on the site and post it here.

Yeah, adding a hardcoded adc-channel selection would be easy. Nicer would be auto-detecting the used channel if possible.

I don't understand what kind of hardware you have there...

ADC0 and ADC2 are not connected to anything (on the unmodded board)?

ADC1 is the keypad input... and you've short-cut it with ADC0 pin?

Why did you need the extra resistor? Is that because short-cutting ADC0+ADC1 somehow changed the voltages? Or is your keypad board different - ie. which resistor values do you have on the keypad board? 1K, 2K and 4.7K ohm?

And is there a pull-up resistor on the ADC pin on mainboard, with how many ohms?
I don't remember how that's wired on my own mainboard, but I guess there must be some pull-up (since unused ADC pins are floating somewhere between VCC and GND).

Oh, and what firmware did you have on that board originally? Or was it the 1024x600pix firmware you posted earlier? My firmware doesn't properly support that resolution though.

And what is the yellow thing on the photo, is that a LED? A PCB photo would be nice too, and the TFT display part number (and info on size/resoltution).

For downloading: Best start here, with the first page, http://remont-aud.net/dump/car_audio/ca ... nitors/356 and download all AMT6xx related files (including AMT628 or AMT629 or whatever) (ie. use your browser's search-in-page to find anything with "AMT"), and then continue at second, as far as you can get (in total there are currently 5 pages (the older pages have fewer AMT chips, so maybe 50 points are enough to get through all pages).
Important please include some info what you have downloaded where from. In the two files I have posted above (for AMT630 and AMT629), I've included an extra txt file (inside of the archives) with the URL where each file was downloaded from, and copy/paste of the text on that page (showing only the latin/ascii part though). Adding that info will probably make downloading a bit more time consuming, but it could be quite valueable to have that info included.

five files per day.
Why No$x51 do not understand asm51 command CJNE ?

Next five files.

next files

last three files

Thanks! But... oh no, you did it! You didn't include the URL's and other text/info ; (
Hmmm, it looks a bit as if the first 5 digits of the zip/rar name are matching up with the last 8 digits of the URL?
So this http://remont-aud.net/dump/car_audio/ca ... -1-0-57157 would correspond to file 57157_AMT630A.rar [13.79 KiB]?
On the other hand, looking at two other URLs, http://remont-aud.net/dump/car_audio/ca ... -1-0-57877 and http://remont-aud.net/dump/car_audio/ca ... -1-0-56231 - I can't find files for them.

No$x51 supports two asm syntaxes, ".native" and ".nocash", in the latter one, CJNE is called JNE (and it differs on using round/square brackets and # prefixes). The syntaxes are described in CPU Microprocessor chapter.
Btw. did you read my previous post, with the questions about what hardware you have?

Do not worry! I have prepared a file to organize the data.

About hardware.
I have small 4.3" car monitor. Its native firmware - WD-888-V1.0 CRX441.zip
Its keyboard have 3 buttons with resistors 1k, 2k, 4.7k, but in another order and another ADC input. Pull-up resistor 12k, so voltage on input of ADC change in another range. I corrected your firmware and keyboard works good. Yes I added power LED, because blackscreen idle mode and autoswitch to second AV input annoyed me. TFT panel 480x272 size, marked on te connector ZNL043T702-P40.
It remains to solve two problems:
1. Settings are not saved. May be your firmware do not work with my flash chip? I tried three different chips - no result Which chip exactly works with your firmware? Now I changed presetting in your firmware to my needs.
2.Not sure it possible. Can AMT630a zoom picture in small limits (3-5%)? The fact is that all picture does not fit in screen. I need "underscan" picture. Pleases that menu item "signal decoding - pal/ntsc/pal60" change size of picture.

And yet one questons: How Nocash works with local/global labels as is "@@...", what determines its scope area?

Last news.
1.Сombining the PLL multiplier and the total number of points in a line, I achieved a vertical scaling. But to scale horizontally, it is necessary to change the sampling frequency of the input analog signal. I do not know yet how.
2.Strange things: an unknown command (20h to reg FDD0h)allows write one byte into a flash. The written byte I put in the reg FDD1h

[FDD0h]=20h for manual flash write sounds right, I was wondering if the chip might support such a thing. And sharing [FFD1h] for write data and write status does make sense, too. For daily use I would stick with 100h-byte DMA write instead manual 1-byte writes; the DMA is probably faster (and maybe it's also better for chip lifetime to do a single 100h-byte write instead many 1-byte writes). But good to know that the 1-byte write feature does exist!

For vertical scale, changing "total number of points" means... that you are changing "total including hblank"? Which/how many registers did you need to change?

For horizontal scale, isn't the 4:3 vs 16:9 ratio option already doing right that? I do only have a 3.5 inch 4:3 display, so I've never actually seen how 16:9 would look like, but I thought it's mainly affecting horizontal scale.
Looking at the 4.3/5.0 inch firmware, the ratio is mainly changing the words at FC96h-FC97h (NTSC) and FCC2h..FCC3h (PAL).
And, maybe only less important fine-tuning, also the word (or 2 bytes?) at FCADh-FCAEh (NTSC) and FCD9h-FCDAh (PAL).

Oh, and about your previos post (sorry for not replying earlier):

The local labels (with @@-prefix) are erased whenever defining a global label (without @@-prefix), that behaviour is adopted from borland's turbo assembler.

Did you get the "firm_do_save_settings" function working with your flash chips? It should work with anything that's 128Kbyte or bigger, unless some chips need different write-protect-status values, or extra delays, or different erase commands or so. Best check the chip part numbers and the datasheets for that chips.

For the keyboard, did you get it working without additional/external resistor? Ie. by just changing the ADC range values in the firmware? If yes, would be interesting to see which values you are using.

for vertical scaling I change FD0Ah, now 9Dh and FCC5h/FCC4h = 43Ah.(only for 50Hz) The image is slightly reduced vertically and completely enters the screen. And I little adjust offset and crop.
Changing 16x9/4x3 does not matter to zoom input image.
In the scaler, as I understand it, there are two independent processes:
The first digitizes the input analog signal with ONE frequency and fills the memory buffer.
The second - outputs data from memory buffer to the screen with a another frequency.
In AMT630a datasheet ADC clock frequency may be 13.5 - 54 MHZ. I need to increase this frequency a little, but I do not yet know how.
With the flash while the troubles, your firmware does not read the ID of my chip, only FF FF FF.
The keyboard I redid over your resistors with my was a lot of bugs.

Yes, I guess so, too (concerning the first/second step).
But 16x9/4x3 does affect the zoom (of the output), doesn't it?
Though I guess it might add black borders or the like (when the zooming out too far, ie. when the input buffer did store data outside of the usual screen boundaries).

Yeah, changing the ADC input clock might do it (no, I don't know how). If you want to "zoom out" then you would need to decrease it a bit. And alongsides you would probably also need to adjust the sample starting point in some other register (and maybe also the sample width or end point... unless it ends automatically when the buffer for the line gets full).


The ID is used only in the diagnostic screen (not needed for my flash write function)...
But yeah, the read ID command should work for all chips...
Looks as if something is wrong there (and, yes, that same problem might also affect writing).

Thank you very much, I did so. I completely removed crops and lowered the scale. Now almost the whole picture is included in the screen.



all succeeded, saving parameters works without reading ID.
I also turn on chips UART with baudrate -27000000/-22/32 = 38 352 bauds. It's very close to 38 400 and work fine with PC. My simple terminal code allows add a color OSD on the screen from another device (arduino etc).
Thats all with AMT630a.
In the future I start a similar work with MST720 and RTD2660.

Hi,
First of all, @nocash it's impressive what you did. Thanks for your work.
I found this forum, just because I started thinking about custom free available firmware for cheap LCD monitors, which are used by RC maniacs, for FPV flights. There are a lot of them on the market, but I think, that all are based on firmware provided by chip manufactures. My goal is to add OSD which will visualize flight parameters, draw artificial horizon, display GSP coordinates, etc. Exactly what analog OSD based on MAX7456 does, but with colours and draw directly on LCD screen by video processor.
There are a lot of displays based on TW8820 or other chips, but ATM630A is cheapest i think and maybe it's good point to start with it.
I wonder what do you think, about it, do you think that, there is possibility to use C compiler (SDCC is free available) to build firmware from scratch, just based on your reverse engineering?

Anyway, I found two pieces of small 3.5inch lce in my drawer looking exactly the same like your.
I can enter service menu and change some parameters, but i don't really know what does VCOMAC and VCOMDC means...
But snow is working, fine I'm not sure if when is ON, the displays shows composite input event when sync is lost, or it's just replacement of static black/blue screen turing on, when level of signal is lower then defined value (something like noise gate?).





So i'm going to try replace the firmware by one provided by you, but don't know if it's any way to do it without flash programming devices. I only have JTAG devices used by me to program STM32 hw, and it look not suitable for SPI flash programming
Maybe you have any idea how to do it, maybe arduino boards which some smart software?

I also run your emulator, it works fine;) but don't have idea how to simulate menu/+/- buttons ? to get the menu )?
Best regards
Kris

With a ST Nucleo board and STLink utility, you could do an SPI flash programmer fairly easily. STLink utility comes with "external loaders", which can be used to flash external memories connected to a ST mcu. You can thus wire up a Nucleo to the SPI Flash, and then use an external loader that works with SPI Flash chips, and you're done.

Thanks,
I was not aware, that STLink can do that I was using openocd only..
Anyway it looks like st does not provide external loader for 4Mbits flash like t52s40 used on my board
Or maybe i can use loader for different flash size, need to check... and first find connection diagram for SPI flashing.
Thanks again.
Kris

One more question,
Is it ATM630A reset pin anyware on the board? Or should i solder GND directivity to the chip?

Hi,
I managed to read/write flash without pulling reset pin, and i upladed AMT630A.BIN but, with this firmware nothing is displayed. When video signal is not connected screen is black, when it's connected it's brighter that's all.
What do i wrong?
Kris
PS
Maybe attached original firmware will be useful for somebody.