Цитата Сообщение от nzeemin Посмотреть сообщение
Поэтому вероятно мы и видим overrun.
А мы таки видим именно overrun ?

Мы видим именно бит 010000 в регистре статуса приёмника ?

Если да - это неправильная эмуляция.

Вот такой код в принципе ошибочен:
Код:
if (m_SerialInCallback(&b))
{
	if ((pMemCtl->m_Port176570 & 0200) == 0)  // Ready?
	{
		pMemCtl->m_Port176572 = b;
	}
	else
	{
		pMemCtl->m_Port176570 |= 010000;  // Set Overflow flag
	}
	pMemCtl->m_Port176570 |= 0200;  // Set Ready flag
}
Вообще общение с COM-портом у меня построено не на overlapped и не на событиях, а по более простой схеме -- чисто байтовое чтение и запись. При чтении если очередной байт не готов -- он не отдаётся. Но при записи пишется всё не взирая на возможные переполнения.
Так и надо.

Но ещё надо учитывать, что драйвер com0com - пакетный. Он не следит за промежутком времени между байтами ( в Windows вообще ни одна программа этого не делает ), поэтому, если эмулятор допускает формирование признака overrun - при работе в Windows этот признак обязательно будет формироваться.

---------- Post added at 11:38 ---------- Previous post was at 11:35 ----------

Здесь даже промежутки времени не столь важны.

Ведь в реальном порту действует квитирование, т.е. байт не может быть принят, если порт не готов. А в эмуляторе может! И даже признак overrun формируется!

---------- Post added at 11:41 ---------- Previous post was at 11:38 ----------

Поэтому - в нынешнем состоянии эмулятор эмулирует работу 1801ВП1-065 по кабелю без линий квитирования. А по такому кабелю ни TU58, ни сеть УКНЦ работать не могут.