Вопрос к тем, кто сам прошивал АТ89С2051 через LPT

[eprinter]

А ещё точнее - к тем, кто использовал вот этот программатор (схема прилагается). Я решил немного его улучшить (добавить возможность чтения ПЗУ), и заодно поупражняться с LPT при написании своей программы. Нашёл две версии программ для этой схемы:
- BlowIt2051, 1996 Silicon Studio, входной файл .bin
- py2051, 10.06.2001 Dincer Aydin, входной файл .hex
Стал разбираться как они работают и обнаружил, что в обеих режим программирования и режим стирания не соответствуют схеме и даташиту:
prog_mode = 0x0f
erase_mode = 0x07
Если посмотрим на схему, то нужно либо поменять местами проводники к Р3.3 и к Р3.4...7, либо поменять значения режимов стирания и записи данных. Например, для стирания на PIN17 DB-25M должна быть "1", а подаётся "0".
Меня очень озадачил этот нюанс, хотелось бы разобраться - то ли я что-то не понимаю, то ли все доводили схему до ума, но почему тогда она в инете до сих пор в таком виде 8O

-- Прилагается рисунок: --

[eprinter]

Ларчик просто открывался
Когда дошло дело до наладки, обнаружилось, что бит 3 порта Control (&H37A) инверсный (а также бит 0 и 1), а значит всё работает как надо. Кроме того, в LPT обнаружился ещё один порт с инверсным битом 7 - Status (&H379), правда он в схеме не задействован.
Хитро...

[eprinter]

Разобрался во всех нюансах, написал прогу, теперь могу читать и прошивать АТ89Схх51. Невелико достижение по сравнению с мировым прогрессом , но сложностей хватало, т.к. я в этом деле новичок. Если кому интересно - подробное описание интерфейсов LPT и COM:
http://silver-dog.narod.ru/hands/ports/ports.htm
Пока не зашёл сюда, не получалось чтение данных с МК.

Кстати вот какой нюанс проявился. Микропрограмма длиной 75 байт (тестовая, моргание светодиодов):

data  x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF
0000  01  43  00  32  00  00  00  FF  FF  FF  FF  32  00  00  00  FF
0010  FF  FF  FF  32  00  00  00  FF  FF  FF  FF  32  00  00  00  FF
0020  FF  FF  FF  32  00  75  88  00  75  89  00  75  D0  00  75  A8
0030  00  22  7F  00  0F  EF  B4  FF  FB  22  7E  00  0E  11  32  EE
0040  70  FA  22  11  25  05  90  11  3A  01  45

Записалась с первого раза, всё моргало как надо. При чтении этого же кода с МК периодически происходит "пропажа" одного байта в диапазоне от 1Dh до 22h:

data  x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF
0000  01  43  00  32  00  00  00  FF  FF  FF  FF  32  00  00  00  FF
0010  FF  FF  FF  32  00  00  00  FF  FF  FF  FF  32  00  00  00  FF
0020  FF  FF  32  00  75  88  00  75  89  00  75  D0  00  75  A8  00
0030  22  7F  00  0F  EF  B4  FF  FB  22  7E  00  0E  11  32  EE  70
0040  FA  22  11  25  05  90  11  3A  01  45

Более точно определить не могу, т.к. там идут подряд четыре FFh, какой из них пропадает неясно.
Получается, что в этом месте МК "перескакивает" через один адрес. Пропуск происходит первые 1-2-3 считывания, следующие как правило все удачны, если интервал между считываниями небольшой. Через паузу в несколько минут опять первые считывания с пропуском байта там же. В других диапазонах ни разу ни одного байта не пропало. Изменение временных задержек для сигналов управления ничего не дали. Видимо это дефект конкретного МК?