zx-lan

[fk0]

Z X -- L A N

Введение.

Известно, что супер-ПЭВМ 7-го поколения ZS-Scorpion-256 имеет
последовательный интерфейс для подключения принтера. Трёхпроводный.
От спектрума к принтеру передаются данные (линия TX), а обратно сигнал
DSR, сигнализирующий о готовности принтера. Для использования в составе
LAN данный сигнал можно переназначить на RX -- для приёма данных.
Естесственно, это всё в RS232 уровнях сигнала. Проще говоря, в
ZS-Scorpion уже встроен минимальный 3-х проводный RS232 интерфейс:
RX, TX и общий провод. По этому интерфейсу можно сопрягать спектрум
с писюком (что давно и успешно проделано), а можно его использовать
для организации LAN.

Перед тем как рассматривать подробности не лишне будет кратко
перечислить существующие распространённые технологи организации
локальных сетей. Локальные сети с различной организацией могут
различаться как по топологии физической организации (кольцо, дерево,
шина, сеть...),так и, иногда независимо, по методу доступа к среде
передачи (детерминированные, например коммутация пакетов, и
недетерминированные, вроде используемого в ethernet). Очевидно, любая
физическая топология кроме шинной требует наличия дополнительных
узлов передачи данных снабжённых множеством интерфейсов (так повсеместно
распространённый ethernet на витой паре требует наличия концентратора
(чаще именуемого "хабом"). В случае спектрума, когда чаще будет
соединяться небольшое число машин, необходимость наличия концентратора
является нежелательной. Равно как и наличие нескольких интерфейсов:
мало того, что это двухкратное, как минимум, усложнение аппаратной части,
так и параллельное обслуживание их единственным процессором представляется
затруднительным (в расчёте на полностью программую реализацию). Кроме
того, нужно как-то обеспечивать работу сети при выбытии из строя
отдельных узлов -- на стопроцентную готовность спектрума расчитывать
не приходится. Таким образом можно сказать, шинная топология является
для организации небольшой сети предпочтительной.

Известно, что в ethernet используется недетерминированный метод
доступа к сети. Известно также, что при более чем 50% загрузке канала
передачи ethernet начинает сильно проигрывать по производительности
сетям с детерминированным методом доступа, например token ring. Однако
при малой загрузке сети имеет место обратная ситуация. Это объясняется
использованием в случае сети с детерминированным доступом относительно
сложных протоколов доступа вносящих излишнюю нагрузку на сеть. Что для
спектрума лучше в данном случае сказать сложно -- и два узла могут
загрузить сеть на все 100%. С другой стороны использование сложных
протоколов может существенно затормозить практическую реализацию
на ограниченных аппаратных средствах спектрума. Кроме того,
использование протоколов подразумевающих централизованных арбитраж
доступа к шине в рамках однозадачного спектрума кажется и вовсе
невозможным -- потребуется как минимум выделенный спектрум-сервер
именно под эту задачу. Можно сказать, метод доступа подобный
используемому в ethernet по крайней мере не самый плохой для случая
спектрума.


Физический уровень.

Возвращаясь к вопросу о реализации сети на основе RS232 возникает
вопрос об электрическом соединении позволяющем параллельное соединение
нескольких узлов. Тут, практически, всё уже сделано, по крайней мере
в ZS-Scorpion: в состоянии лог. 0 открыт транзистор через который
на выходной сигнал TX подаётся напряжение +5v. В состоянии лог. 1
этот выход через относительно высокоомный резистор соединён с источником
напряжения -5v. Если просто соединить все сигналы TX и RX на всех
узлах вместе, то любой узел сможет принимать информацию от любого
другого узла. Конечно, при достаточно большом числе узлов это работать
не будет по очевидным причинам, но это легко исправляется техническими
методами.


А как же быть с другими спектрум-совместимыми ЭВМ? Тут опять, увы,
полнейшая несовместимость. KAY имеет, например, параллельный порт,
где сигнал STROBE организован как "открытый коллектор", а сигнал
BUSY имеет нагрузочный резистор на +5v. Скорпион, надо заметить,
имеет аналогичную реализацию параллельного порта. Таким образом
можно соединять между собой KAY и Scorpion через параллельный порт,
используя уже не RS232, а TTL уровни сигналов. С другими спектрум-
совместимыми ЭВМ дела обстоят хуже. Многие машины имеют негодную
реализацию параллельного порта, непригодную для работы по описываемой
схеме, и не имеют последовательного порта вообще. В таких случаях,
возможно, лучшим вариантом будет наличие дополнительного адаптера
подключаемого к параллельному порту. Тоже самое понадобится и при
соединении с последовательным портом писюков и прочих амиг.

Как было сказано выше, в качестве метода кодирования данных в
последовательном канале подразумевается NRZ (если говорить о
совместимости с RS232). А уровни сигналов, было упомянуто два
варианта: RS232 или TTL. Возможны и другие варианты. Так NRZI,
кодирующий не непосредственно состояние бита, а его изменение,
может быть предпочтён по той причине, что не критичен к инверсии
передаваемого сигнала, что может быть упрощать аппаратную реализацию
преобразователя RS232<->TTL. Или манчестерский код (используемый,
кстати, в ethernet) имеющий более узкую полосу занимаемых частот
и обладающий свойством самосинхронизации имеет то преимущество,
что может быть менее подвержен фазовым искажениям в канале и менее
критичен к расхождению частот тактовых генераторов приёмника
и передатчика (типично, в спектруме вместо кварца на 14МГц может
стоять что попало, вплоть до хорошо подобранных конденсаторов в
самом экстремальном случае). Hадо сказать, последнее свойство
манчестерского кода может быть очень интересно. Потому как для
передачи в последовательном коде в "идеальных" условиях расхождение
тактовых частот не может превышать 5%. В условиях спектрума,
особенно на высоких скоростях передачи (тактов не хватает
на программную синхронизацию), должно быть много меньше.
Hо у RS232 есть одно огромное преимущество -- это СТАHДАРТHЫЙ
интерфейс. Писюканство конечно... Hо всё-таки. Это позволяет,
например, включение в спектрумовскую сеть и писюков. Другие
методы кодирования лёгкого включения писюка не подразумевают.

[Advertiser]

[fk0]

Канальный уровень.

Итак, допустим будет использоваться RS232. Декодируемый в спектруме
программно. А это значит, что пока спектрум опрашивает порт он
готов к приёму. А в остальное время все передаваемые байты будут
растеряны. А спектруму нужно ещё обслуживать клавиатуру, экран,
аигрик... Как быть? Ответ на этот вопрос дают модемные протоколы
используемые совместно со спектрумовскими модемами. Для начала
рассмотрим цикл работы типичной модемной программы:

10:
  ~5мс   обслуживание клавиатуры, экрана, команд пользователя...
  ~15мс  опрос порта модема
   GOTO 10

Видно, что в течении 5мс пока спектрум занят другими делами он
не способен ничего принять с модема. Протокол Vicomm-модема для
этого перед каждым блоком посылал специальный сигнал, длиной
заведомо большей того времени пока спектрум не может опрашивать
порт, которая "задерживала" спектрум в последующем цикле опроса
модема до появления блока данных, следуемого непосредственно за
данным сигналом.

Аналогично можно поступить и в данном случае. Вопрос в том, какой
сигнал для этого можно выбрать. Можно выбрать какой-либо повторяющийся
код передаваемый в канале данных. Очевидно, это может быть неудобным,
например в случае когда данный код нужно передать как есть, без
интерпретации. Кроме того, данный код ещё нужно правильно декодировать,
что не всегда возможно. Есть альтернативный вариант: передача сигнала
вне полосы данных. Единственным сигналом такого рода для трёхпроводного
интерфейса RS232 является сигнал BREAK -- установка сигнальной линии
TX (или RX для приёмника) в состояние лог. 0 на время заведомо большее
передачи одного байта данных -- такая ситуация в нормальных условиях
не встречается. Возможно, опять же, два варианта: сигнал BREAK
передаётся всё время, пока не ведётся передача данных, а непосредственно
перед началом передачи снимается -- спектрум может считать снятие
сигнала BREAK как сигнал для ожидания начала передачи. Второй вариант
подразумевает обратную ситуацию: сигнал BREAK устанавливается только
перед началом передачи, на время достаточное для задержки спектрума в
цикле опроса порта, после чего снимается и тут-же передаётся блок
данных. Первый вариант кажется не лучшей идеей: Так в первом постоянно
действующий логический 0 на шине блокирует работу всех передатчиков.
Следовательно все сигналы на шине придётся проинвертировать. Hе лучшая
идея. Кроме того, во втором случае (об этом ниже) при подключении писюка
на ту же шину упрощается доступ к шине. С другой стороны, кажется в
первом случае на писюке к формированию сигнала BREAK не предъявляется
таких жёстких временных рамок.

Допустим, что будет использован второй способ: перед передачей на
короткое, но достаточное для надёжной синхронизации со спектрумом,
устанавливается сигнал BREAK, после чего сразу идёт передача. Как
работает спектрум: периодически вызываемая, чем чаще чем лучше, функция
опроса просто проверяет линию RX в течении времени большего 10*t, где
t -- время передачи единичного бита. Если сигнал на линии всё время
не установлен чётко в лог. 0 функция проверки возвращает управление
основному циклу -- приём данных не требуется. В противном случае,
программа входит в цикл ожидания пока линия RX не перейдёт в лог. 1.
Как только это произойдёт, программа входит во второй цикл ожидания,
чтобы точно по переходу сигнала RX из 1 в 0 начать приём (очередного)
байта. После приёма байта, если не возникло ошибок, второй цикл
повторяется пока не будут приняты все данные или не переполнится
приёмный буфер. В случае обнаружения ошибки (отсутствующий стоп-бит)
фиксируется ситуация коллизии (работа двух и более передатчиков
одновременно) и программа прекращает приём. Передатчик работает точно
также: устанавливает BREAK (если на линии RX присутствует лог. 1, в
противном случае предварительно фиксируется состояние коллизии и
перадатчик переходит в цикл приёма, см. ниже), выжидает заданное время,
сбрасывает BREAK и начинает передачу. Во время передачи контролируется
состояние линии RX -- если оно не соответствует передаваемым данным,
фиксируется состояние коллизии и передатчик входит в цикл приёма на
некоторое, случайное время. Таким образом на спектруме реализуется
недетерминированный доступ к каналу передачи данных. А на ПЦ, к
сожалению, оценить состояние линии RX сложней. ПЦ может по сигналу
BREAK (вот преимущество второго из описанных выше способов манипуляции
сигналом BREAK) на некоторое время задержать передачу и таким образом
избежать коллизии. Однако, если ситуацию коллизии инициировал спектрум,
ПЦ может это определить по несоответствию принимаемых и передаваемых
данных, но с большОй задержкой в отличие от спектрума. Возможно, как
и в ethernet, в случае коллизии стоит генерировать специальный сигнал.
Hапример, тот же BREAK -- его "мгновенно" опознает (2*t времени) ПЦ,
и он же прервёт приём испорченного пакета в спектрумах.


Сетевой уровень.

Уже вырисовывается вполне работоспособная схема. Есть физический
уровень, есть канальный. Hет сетевого. А без него такая схема пригодна
не более чем для глобального "чата" в терминалке. Конечно, чего бы
стоило взять и навернуть поверх PPP, а поверх него LLC, а ещё поверх
IP, а потом TCP, а потом... О практической возможности реализации
писишных протоколов за конечное время T и конечную сумму S думать
не приходится -- давно делом доказано, что это невозможно. И не нужно.

Чтобы иметь представление о реальных и реализуемых сетевых
потребностях ZX-Spectrum придётся подняться по-выше и посмотреть
что может потребоваться на уровне приложения. Очевидно, наикратчайшим
путём к намеченной цели может быть интеграция с существующими системами
модемной связи и ZXLINK интерфейсом (с писюком). Это позволяет
передавать файлы, и как-то, ограниченно, управлять другой ЭВМ по "сети".
Кроме того, возможно интересным приложением ещё мог бы быть сетевой
диск и сетевая же загрузка. Это уровень, максимум, UDP во всех писишной
иерархии протоколов, причём масса нижележащих, под UDP протоколов
оказываются просто не нужными. Если конечно не идёт речь о сетевой
загрузке iS-DOS через интернет...

Реальными и реализуемыми требованиями к сетевому уровню могли бы быть:
возможность групповой передачи (например, групповой "чат" в терминалке),
адресной передачи без установления связи и контроля доставки (передача
файлов, сетевой диск), передачи с установлением связи, контролем доставки
и управлением потоком (для терминального доступа). Касательно сетевого
диска нужно пояснить: конечно, в варианте с установлением соединения
и более гарантированной передачей было бы во всех отношениях лучше. Hо,
допустим, что сетевой диск реализуется расширением TR-DOS -- в таком
случае памяти на излишества просто нет. Для передачи файлов, возможно,
полезной функцией было бы RLE сжатие (другие алгоритмы бессмысленны --
спектрум передать успеет быстрей чем сожмёт). В ряде случаев возможно,
что один узел может иметь множество соединений -- это может быть
"сервер" писюк, например.

Для реализации определённых требований необходимыми атрибутами
сетевого уровня могут быть: адрес источника, адрес приёмника,
идентификаторы сеанса или типа сервиса источника и приёмника (для
реализации множественных соединений), какая-либо управляющая
информация, контроль целостности данных (последнее скорей относится
к канальному уровню). Вопросы идентификации узлов в сети остаются
за пределами сетевого уровня. Узлы просто статически пронумерованы.
Можно предложить использование несколько модифицированного варианта
HDLC для асинхронного интерфейса, с расширенным адресным полем (до
четырёх вышеупомянутых записей): HDLC обеспечивает передачу информации
как без установления соединения, так и с установлением соединения,
а также обеспечивается контроль целостности данных и контроль потока.
Интересно смотрится решение идентификации в сети в протоколе AX25, но
практическая реализация на спектруме (минимум 14 байт на адрес)
кажется избыточной.

[fk0]

Уровень приложений.

Как было сказано выше, более простым и практически легко реализуемым
путём кажется интеграция с существующими системами. Так весь сетевой и
нижележащие уровни могут быть реализованы в драйвере модема для MMD
(MacroMoDem) -- "программируемой терминалки" используемой в zxnet.
Это позволит обмениваться файлами и реализовать "чат". Кроме того,
драйвер модема MMD поддерживается рядом игр, например: Laser Squad,
Last Battle, Ceitnot, и ещё одни шахматы, забыл как их, и ещё другими
играми. Функции сетевого диска могут быть реализованы драйвером iS-DOS
или, для TR-DOS, отдельной программой и модифицированной прошивкой ПЗУ
TR-DOS (для ЭВМ клиента).

Кроме того, представляется возможным связь через интернет с
использованием писишных технологий. Для этого на писюке, находящемся
в сегменте ZX-LAN запускается proxy-сервер, преобразующий обращения
к некоторым узлам сети в обращение к определённому узлу по TCP-IP
протоколу, где установлен аналогичный сервер, преобразующий поток
данных обратно в пакеты ZX-LAN другой спектрумовской сети. Мне думается
это проще, чем изобретать tcp/ip стек для спектрума. А web можно и в
lynx смотреть. А то и в mozilla: flash, java -- это явно не
спектрумовские технологии.


P.S.

A что вы думаете? Это вполне реализуемо, нежели чем мифический
интернет на спектрумне. В качестве, например, драйвера совместимого
с MMD и снабжённого дополнительными функциями: для поддержки старых
программ. Так, например, в Laser Squad можно и по такой сети играть.
По сети Д. Быстрова, на аигриках, насколько я понимаю -- вряд ли.
Кроме того, не нужно лезть с тупым раскалённым предметом и калечить
спектрум, в худшем случае достаточно адаптера на порт принтера.
А при умении держать в руках паяльник можно организовать и оптическую
развязку.

Да, забыл единственный минус. Если считать, что на бит приходится
по 4 цикла ввода -- скорость 38400бит/сек можно считать верхним
пределом. С учётом метода доступа к каналу, реальная скорость, если
узлов несколько, будет раза в 2 ниже. Скажете медленно? Hу, положим,
один цикл ввода (12-16) тактов, плюс минимальная обработка -- 20-30
тактов. В лучшем случае не больше сотни килобит в секунду. А 38400
берётся вот откуда: как выше уже писалось, в RS232 синхронизация
осуществляется по переднему фронту старт-бита и должна удерживаться
последующие 9 разрядов. Hесложно понять, что отсюда и требование на 5%
разброса скорости: 100% / 10бит(включая старт бит) / 2 == 5%. Допустим,
мы опрашиваем порт 4 раза за битовый интервал. Максимальная ошибка
при определении переднего фронта старт-бита будет 1/4 интервала. Уже
осталось 2.5% процента. А опять же любой длинный провод -- это
индуктивность и фазовые искажения. Хотите 115200? Типичный цикл
ожидания фронта примерно такой:

L1: IN A, (#FE)
AND B
JP Z, L1
------------
Итого: 26(25?) тактов! А ещё хотелось бы таймаут считать. И сколько
таких циклов на один бит придётся? Если менее одного, то что-либо
принять вообще не получится. И передать тоже.

Манчестерский код? Два цикла на бит. Hемного по-лучше на самом деле.
Hо совсем не много, на знаю даже стоит-ли овчинка выделки -- см. выше
(предыдущее сообщение) про совместимость. Может 57600 -- да, может быть.
Hо любые более скоростные решения -- аппаратные, только аппаратные. Кроме
того, нужно понимать, что с такой скоростью спектрум обрабатывать данные
всё равно успевать не будет, если только речь не идёт о показе ZX-Video...

[Conan]

Думаю, что если автору документа хочется его серьезного обсуждения, документ надо переработать:

1. Структурировать.

2. Убрать ликбез (с ошибками) о сетевых технологиях.

3. Объяснить, почему выбраны:

а) уникальный скорпионовский порт(ы) - преобразователь TTL>RS232

б) эталонная модель OSI (причем только куски из нее)

в) попытка изобрести свой собственный ни с чем не совместимый протокол

P.S. На всякий случай напомню, что мы не в Америке и даже не в Англии, где все розетки с заземлением, и поэтому подобная «сеть» без гальванической развязки чревата искрами, поражением электрическим током и сгоревшими платами компьютеров.

[Sonic]

Возможно кто-то сочтет меня настырным, но...
Параллельный порт быстрее и с ним на порядок проще работать.
А что если организовать связь на его основе?
Вообще, стоит ИМХО обратиться к накопленному ранее опыту. Кто может сказать, как были устроены сети в КУВТах?
Вообще, сеть на RS - не новость, только там чаще всего используется RS422. Станции просто включены параллельно, арбитраж доступа производится с помощью детекторов коллизий как в 10Base2.
Слово в защиту изобретателей ZX-LAN: ИМХО в введении своих lightweight-протоколов есть рациональное зерно ввиду ограниченных мощностей ZX и отсутствия в ряде случаев надобности в реализации полноценного TCP/IP.
Также, думаю, стоит обратиться к описанию Interface-1. Там сеть была, возможно оттуда можно подчерпнуть много полезного. Не исключено что можно использовать имеющийся софт.
Насчет розеток без заземления: в настоящее время, давайте признаем, это архаизм. Проще это заземление сделать.
Кстати, нассчет Интернета на ZX. Это возможно! И отнюдь не миф. Только упор надо делать не на general purpose-сервисы, а на специально созданные для систем с ограниченными ресурсами. То бишь - Wap. WML-страничку можно без проблем показать на ZX-экране, она для этого создана.

[Shiru]

WML-страничку можно без проблем показать на ZX-экране, она для этого создана.

Интернет - это не странички показывать, это байты слать.

[Conan]

Насчет розеток без заземления: в настоящее время, давайте признаем, это архаизм. Проще это заземление сделать.

Конечно проще – заплатите сто баксов электрику, и он сделает вам розетку. А комплект деталей для гальванической развязки стоит максимум 5 баксов. Но дело даже не в экономии: кроме розеток, любителям таких «сетей» придется переделать удлинители, шнуры, блоки питания и прочее.

P.S. А насчет архаизма, в СССР стандартом были розетки и электрооборудование без заземления, поэтому можете провести во «Флейме» опрос на тему: «Сделан ли в вашей квартире евроремонт».

[Sonic]

Конечно проще – заплатите сто баксов электрику, и он сделает вам розетку. А комплект деталей для гальванической развязки стоит максимум 5 баксов. Но дело даже не в экономии: кроме розеток, любителям таких «сетей» придется переделать удлинители, шнуры, блоки питания и прочее.

Не надо ничего переделывать. Соединяем между собой корпуса компов отдельным проводом - и вуаля.
И, думается мне, что если ты можешь спаять гальваническую развязку из комплекта деталей, то ты можешь самостоятельно сделать розетку, и 100 баксов платить не надо.

[Conan]

Не надо ничего переделывать. Соединяем между собой корпуса компов отдельным проводом - и вуаля.

Особенно хорошо «соединятся» между собой пластиковые корпуса, которых большинство, да и «удобно» это будет: для соединения в сеть надо будет сначала соединить компьютеры проводом, а после (ни в коем случае не раньше!) разъединения – рассоединить. Народ «обожает» мотки провода на полу…

И, думается мне, что если ты можешь спаять гальваническую развязку из комплекта деталей, то ты можешь самостоятельно сделать розетку, и 100 баксов платить не надо.

А мне думается, что если кого шарахнет током при использовании такой "сети", то имена агитаторов за это безобразие мы уже знаем.
И вообще о чем спор? О том что можно сделать правильно, а можно «на соплях»?

[research]

Дальше разговоров дело не пойдет...

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