Гы, работает!
- - - Добавлено - - -
А как это в жизни должно было быть? Раз работает загрузчик, значит это в какой-то мере совместимо с реалом. У Векторовского адаптера ЛВС было три вв51?
Гы, работает!
- - - Добавлено - - -
А как это в жизни должно было быть? Раз работает загрузчик, значит это в какой-то мере совместимо с реалом. У Векторовского адаптера ЛВС было три вв51?
Больше игр нет
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
В открытых источниках готового описания протокола вроде не видел. Много лет назад, восстанавливал протокол ЛВС по дизасму штатного загрузчика. На этом форуме выкладывал результаты, вместе со схемой реверса контроллера (ещё наверное на AVR), описаниями протокола (как смог).
Хотя помню, что пришел к выводу, что в загрузчике урезанный и оптимизированный под загрузчик вариант реализации протокола, так как передача инфы идёт только в одну сторону,
хотя видно, что есть свободные биты состояния для передачи от Вектора в сеть.
Вот своё нашел
https://zx-pk.ru/threads/8669-vektor...l=1#post713864
Кстати, алгоритм определения наличия подключенного к Вектору контроллера ЛВС, очень жесткий, видимо предполагает наличие перемычки между пинами порта ПУ. Так как определение происходит по отслеживанию состояния одного бита, после смены состояния другого бита. И команда чтения порта идёт сразу за командой записи, без задержки. В виртуальном контроллере спас стек, т.к. известно, сколько перепадов уровня контролируется, просто загнал в сокет нужное количество "правильных" байт
b2m, а как должен был выглядеть "правильный" конфиг для проброса "ПУ" на сокеты ?
- - - Добавлено - - -
Самый простой способ понять протокол, это сделать общий лог портов 05,06,07. Писать в лог в какой порт, что пишется, и из какого порта, что читается (всё с точки зрения Вектора).
Потом переслать 512Байт (два блока загрузочной сетки). И изучать лог. В нём будет видны и "конверты" для данных и синхра готовности/подтверждения.
Хотя алгоритм загрузчика, при приёме байта, явным образом выставляет признак, что байт принят (xra a; out 05), а вот дождавшись от контроллера признака, что байт на шине уже не актуален, высокий уровень бита выставляет не явно, а меняя настройки ВВ55 (mvi a,xxh; out 04). В своей реализации "виртуального контроллера" я этот момент не отслеживал, так как нет явной записи в порт 05, то по сокету ничего не прилетает, и контроллер не может узнать об изменении состояния портов без отслеживания ещё и порта 04. А вешать ещё один сервер, ещё на один порт... и без него работает
- - - Добавлено - - -
Вроде обсуждали, что скорее всего, на реальном контроллере ЛВС стояла одна ВВ51, с обвязкой.
Правда я не могу себе представить, как на СОМ-портах можно собрать одноранговую сеть, в которой любой комп может общаться с любым другим компом.
Хотя мы достоверно не знаем как была организована реальная сеть компьютерного класса на основе учительского ДВК и ученических Векторов. Возможно была возможность только загрузить программу с ДВК на все (или любой на выбор) ученические компы, а обратная связь не предусматривалась. И ученические рабочие места между собой не могли связаться.
Сейчас таких подробностей уже наверное никто и не вспомнит.
Последний раз редактировалось KTSerg; 04.06.2020 в 05:56.
Если предположить, что в реальном контроллере стояла ВВ51, то порт В ПУ должен идти на порт данных ВВ51, а биты порта С соответственно на управляющие биты ВВ51. Но на данный момент такого подключения ВВ51 в эмуляторе не предусмотрено.
Непонятно только, как в адаптере ЛВС происходила инициализация ВВ51.
Пакет (токен) передается от машины к машине. Каждая машина ловит свой пакет, а чужой передает дальше. Если пакет пустой, его можно захватить и передать свои исходящие данные. РМУ с номером 0 декларируется инициатором и периодически отправляет токены.
Вроде не рокет саенс, но это требует надежного приема данных от сетевого модуля, что без прерываний и FIFO не то что бы невозможно, но требует практически непрерывного опроса портов. Вариант: когда сетевой Бейсик хочет общаться, он щелкает реле, и включается в сетевую жизнь, например чтобы запросить загрузку программы с РМП, или сохраниться туда же. После этого реле щелк RxD на TxD, и машина из сети выключается. Компромисс, но для своего времени это могло бы быть терпимым решением.
План простой:
- делаем условный интернет-РМП, который хранит программы на Бейсике
- эмуляторы и железки включаются в такой эмулируемый токен ринг. вместо номера РМУ можно использовать GUID или мало ли что.
- дело за малым, написать Бейсик с поддержкой такой сети
- все Векторы, виртуальные или нет, объединяются в компьютерный класс
- Вектор-06ц становится Нью Блокчейн, Блокчейн переименовывается в Старый Вектор-06ц
Больше игр нет
tnt23(10.06.2020)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)