Эмулятор УКНЦ - UKNCBTL

[Patron]

Поэтому вероятно мы и видим 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, ни сеть УКНЦ работать не могут.

[Alex_K]

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

Вот такой код в принципе ошибочен:

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
}

А в чем ошибочность кода? Если стоит признак готовности, то данные с приемника не считаны, и при приходе других данных ставится бит переполнения, а принятая посылка теряется.

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

А как это так, что байт не может быть принят, если порт не готов? Может, еще как может. Ведь для приема другая сторона его передает, а если она не следит за состояниями линии квитирования, то она может его передать и возможно переполнение. Единственное 1801ВП1-065 не сможет передать байт, если на линии BSYD нет готовности от приемника той стороны.
И кстати в сетевом адаптере линии квитирования не используются, там только прием, передача и земля.

[Patron]

А в чем ошибочность кода? Если стоит признак готовности, то данные с приемника не считаны, и при приходе других данных ставится бит переполнения, а принятая посылка теряется.

Ошибочность в том, что Windows не исключает приход в программу любого количества байтов без задержки вообще. Это же мы не с аппаратным портом по прерываниям работаем, а опрашиваем входной буфер Windows ёмкостью 3К. Пока Windows занимается своими делами - в этом буфере копятся байты, а когда процесс исполняющейся программы эмулятора получает свой квант - ему вываливаются из буфера все накопившиеся там байты разом.

кстати в сетевом адаптере линии квитирования не используются, там только прием, передача и земля.

И это на скорости 57600.. Круто! Быстро же должны работать программы сетевого обмена, чтобы не потерять ни одного байта.

[Alex_K]

Ошибочность в том, что Windows не исключает приход в программу любого количества байтов без задержки вообще. Это же мы не с аппаратным портом по прерываниям работаем, а опрашиваем входной буфер Windows ёмкостью 3К. Пока Windows занимается своими делами - в этом буфере копятся байты, а когда процесс исполняющейся программы эмулятора получает свой квант - ему вываливаются из буфера все накопившиеся там байты разом.

Это же с какой скоростью по COM-порту идти данные? Да и как же редко программ должна получать кванты времени?
Проблема может быть в другом. UKNCBTL работает по фреймам, 25 фреймов в секунду. Т.е. быстренько эмулируется 1/25 секунды, обновляется экран, а потом спит в ожидании завершения 1/25 секунды на реальном PC. Вот во время этой спячки и могут придти реальные данные. Но однако же в эмуляторе данные с очереди снимаются со скоростью порта внутри фрейма, поэтому между снятиями данных эмулируемая программа должна успеть прочесть приемник. Если успевает, то и переполнения не будет.

И это на скорости 57600.. Круто! Быстро же должны работать программы сетевого обмена, чтобы не потерять ни одного байта.

Быстро. Загрузчик из ПЗУ без прерываний. А в RT-11 драйвер MC.SYS работает в режиме прерываний. Но драйвер MC.SYS не является самим драйвером, а скорее резидентной программой, сидящей на обработке и отправке пакетов по сети.

[Titus]

UKNCBTL работает по фреймам, 25 фреймов в секунду. Т.е. быстренько эмулируется 1/25 секунды, обновляется экран, а потом спит в ожидании завершения 1/25 секунды на реальном PC.

А чего не 1/50? Почему выбрали каждый второй фрейм?

[Patron]

между снятиями данных эмулируемая программа должна успеть прочесть приемник. Если успевает, то и переполнения не будет.

Именно так. И проведённые испытания показывают, что как раз и не успевает.

В настройках COM-порта можно сделать дополнительную опцию: Эмулировать OVERRUN - при включении которой чтение из буфера Windows будет работать как сейчас, а при выключении - как надо.

---------- Post added at 14:11 ---------- Previous post was at 14:08 ----------

А чего не 1/50?

Даже за 1/50 секунды com0com на скорости 9600 насыпет во входной буфер 20 байтов.

---------- Post added at 14:19 ---------- Previous post was at 14:11 ----------

Хочется же иметь возможность эмулировать как работу по кабелю без квитирования, так и работу по кабелю с квитированием.

Вот выбор этих режимов и надо добавить в окно настроек COM-порта.

[Alex_K]

Именно так. И проведённые испытания показывают, что как раз и не успевает.

В эмуляторе еще не сделана корректно эмуляция последовательного порта, вот дождемся нормальной эмуляции, тогда уже можно говорить о переполнении, есть или нет.

Ведь нужно же иметь возможность эмулировать как работу по кабелю без квитирования, так работу и по кабелю с квитированием.

Выбор этих режимов и надо добавить в окно настроек COM-порта.

Эмулятор работает рывками по фреймам, так что довольно сложновато это сделать.

[Patron]

В эмуляторе еще не сделана корректно эмуляция последовательного порта, вот дождемся нормальной эмуляции, тогда уже можно говорить о переполнении, есть или нет.

Т.е. до сих пор неизвестно, устанавливается ли бит переполнения в ходе работы..
А если добавить в это самое место отладочную печать и всё узнать ?

[Alex_K]

Т.е. до сих пор неизвестно, устанавливается ли бит переполнения в ходе работы..
А если добавить в это самое место отладочную печать и всё узнать ?

В эмуляторе есть такая функция для вывода сообщения в консоль вроде DebugPrint. Так что можно в интересующие места программы вставлять вывод на консоль.

[Patron]

Если с выключенной эмуляцией оверрана всё заработает - значит оверран эмулируется плохо. Если же и тогда ничего не заработает - значит качество эмуляции оверрана не при чём.