Вектор-06Ц: Эмуляция - Виртуальные контроллеры

На всякий случай, открою тему.

Цитата:

---

Сообщение от b2m

И как? Подключил? Мне просто интересно, это был только концепт или что-то реальное?

---

Это проект на плате с stm32, подключенной к "ПУ".
Один из способов загрузить в Вектор программу (реализованных в этом модуле), это по WiFi.
Сверх-задачи не ставил, просто загрузить с компа программу без подключения проводов между Вектором и РС.

Цитата:

---

Ничего из перечисленного сейчас не используется. Исключительно JavaScript (а это совсем не Java).

---

При настройке доступа к сайтам, регулярно сталкиваюсь с сообщениями типа : "на вашем компе ... Актив-Х... " и т.д.
И порой сайты требуют установить на комп Джава.

Цитата:

---

Ой-ли? Для FTP соединения нужны два канала, и куча команд перед тем, как файл начнёт передаваться (и не забываем анализ ответов на команды). Для HTTP нужно лишь соедениться, выплюнуть GET и если файл найден, он тут-же вернётся по тому-же соединению обратно. Пропустить заголовок ответа сложности не составит.

---

Надеюсь ни кто не собирается реализовывать сокеты и стек на Векторе. В описании модулей написано, что в них уже реализован UDP, FTP, HTTP, POP, ... и пр. дребедень.

Цитата:

---

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

Что-то такое припоминаю. Но способов взаимодействия с внешней программой пока никто не предложил. Наиболее простой вариант - это расширение в виде .dll, которую будет подгружать эмулятор. Нужно лишь договориться об API.

---

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

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


Чтобы не искать по всей ветке, ссылки на сообщения:
Исходники (проект на Delphi7) виртуального контроллера ЛВС для эмулятора emu.
https://zx-pk.ru/threads/31876-vekto...=1#post1067977
И сам виртуальный контроллер с конфигом для эмулятора emu.
https://zx-pk.ru/threads/31876-vekto...=1#post1066541

Возможно для связи эмулятора с "виртуальным контроллером" подойдут сокеты.
Но сокет это поток, а в реале могут возникать ситуации, когда данные в порт выдаются, но они не воспринимаются (пропускаются) получателем, по каким-то причинам.
Соответственно, эмуляцию этой ситуации нужно обмозговать.
Возможно эмулятор принимая поток должен просто обновлять инфу в регистре (эмулируемого порта Вектора), а выдавать программе Вектора соответственно текущее значение этого регистра, актуальное на момент чтения порта.

Цитата:

---

Сообщение от KTSerg

При настройке доступа к сайтам, регулярно сталкиваюсь с сообщениями типа : "на вашем компе ... Актив-Х... " и т.д.
И порой сайты требуют установить на комп Джава.

---

А что если всё это возложить на внешний контроллер, а он путь выдаёт Вектору уже готовый текст? Насколько это будет возможным для контроллера...

Цитата:

---

Сообщение от Improver

А что если всё это возложить на внешний контроллер, а он путь выдаёт Вектору уже готовый текст? Насколько это будет возможным для контроллера...

---

На несколько порядков возможней, чем для Вектора. Даже думать о настоящем tcp/ip на Векторе... я не хочу сказать, что это нелепо, учитывая то, чем мы тут вообще занимаемся в этом даже что-то есть, но это непропорциональная для него задача.

На Векторе даже последовательного порта стандартного нет, вот с этого нужно начинать. Прерываний нет, поэтому нужна толстая FIFO на килобайт, иначе без шансов как-то серьезно общаться с внешним миром. Когда есть последовательный порт, к нему можно подключить ESP8266 со стандартной AT прошивкой. Это фактически как модем, только вместо ATDT1234567 мы говорим AT+CIPSTART, получаем CONNECT и чатимся с сервером. Поверх этого можно реализовать на самом примитивном уровне HTTP протокол.

Хотя, если бы это делал я, я бы все проблемы буфера оставил ESP, поскольку в ней его как раз достаточно, а общение с Вектором реализовал бы не последовательным портом, а каким-нибудь чудом-юдом на ПУ, чтобы не заморачиваться слишком сложным подключением. Стандартную AT-прошивку в таком случае пришлось бы выкинуть наверное.

Что до контента, вполне очевидно, что Вектор немного опоздал показывать современный web-content. Проще реализовать свой несложный протокол (назвать это модным словом REST API), который отдает Вектору только то, что тот может без особого труда переварить. Например, если это картотека, то один урл будет для текстового описания карточки, другой для каталога файлов в зипе, третий для запроса конкретного файла.

Цитата:

---

Сообщение от svofski

...
На Векторе даже последовательного порта стандартного нет, вот с этого нужно начинать. ...

---

Жаль, что не сохранилась схема или хотя-бы сама плата контроллера СОМ-порта, а только её фото (низкого какчества).
Можно было-бы хотя-бы представление получить о задумке автора.

Сегодня начну эксперименты с сокетами, на предмет возможности общения (с их помощью) эмулятора и "виртуального контроллера".

По-моему в наше время делать отдельный COM-порт для Вектора это лишняя работа. Для ESP12F и прочих Ардуин проще всего забацать расширитель портов типа MCP23S17, который подключить к ПУ. Преобразование уровней только не забыть между 3V3 и 5V частями. Собственно, та же ESP12F может работать как вайфай-модемом, так и просто логической реализацией ком-порта.

Цитата:

---

Сообщение от KTSerg

Сегодня начну эксперименты с сокетами, на предмет возможности общения (с их помощью) эмулятора и "виртуального контроллера".

---

Кстати, СОМ-порт в моём эмуляторе может соединяться с сокетом или ждать соединения. Примеры есть в конфигах Башкирии-2М и Корвета РМП/РМУ.

А можно твой COM-порт подключить к Вектору? Откуда списать конфиг и где найти как его настроить, чтобы он соединялся с сокетом?

- - - Добавлено - - -

Извини, я идиот. Вижу, что "примеры есть в конфигах....". Вечер, понедельник.

Очень хотелось избавиться от заморочек с идентификацией данных для разных портов в одном потоке.
Хотелось открыть сокет (порт на сервере) в эмуляторе, в программе контроллера открыть нужное кол-во сокетов (клиентов портов) и подключиться ими к серверу. Надеялся, что сервер сможет идентифицировать каждого клиента как определённый порт (соответствующий порту Вектора). Но для сокетов клиента не могу указать конкретный порт (по умолчанию), каждый раз при подключении порты клиентских сокетов меняются.
Сервер конечно их между собой не путает, но как серверу указать, что конкретный порт, будет соответствовать конкретному порту Вектора?
Если только предусмотреть "рукопожатие" - т.е. после подключения клиент шлёт 2-3 байта-идентификатора, указывающие серверу, к какому порту Вектора привязать данного клиента (данный сокет, порт).
Тогда вполне может получиться.
И будет вполне универсально, контроллер можно настроить на любые адреса Ветора без переделок эмулятора.

Я вот как попробовал:

Программа для Прекрасного + конфиг b2m с двумя компортами на портах $30/tcp:15015 и $32/tcp:15016

https://gist.github.com/svofski/da44...690d6463044820

Там же скриншот с запущенной программой и двумя сокатами. Вроде все на удивление просто.

Цитата:

---

Сообщение от b2m

Кстати, СОМ-порт в моём эмуляторе может соединяться с сокетом или ждать соединения. Примеры есть в конфигах Башкирии-2М и Корвета РМП/РМУ.

---

Удобный инструмент для отладки программ. Не нужно выводит на экран флаги состояния, а потом их (точки) разглядывать и интерпретировать.

Цитата:

---

Сообщение от svofski

Вроде все на удивление просто.

---

Это потому-что в эмуляторе не требуется настройка компота. Если бы этот компот был на реале, такое бы не сработало :)

Цитата:

---

Сообщение от b2m

Это потому-что в эмуляторе не требуется настройка компота. Если бы этот компот был на реале, такое бы не сработало :)

---

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

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

b2m, а какой размер буфера/стека у сокетов на приём у эмулятора emu ?
Сколько байт можно отправить (без потери данных) в сокет эмулятора до того как Вектор начнёт чтение "порта" ?

Цитата:

---

Сообщение от KTSerg

b2m, а какой размер буфера/стека у сокетов на приём у эмулятора emu ?
Сколько байт можно отправить (без потери данных) в сокет эмулятора до того как Вектор начнёт чтение "порта" ?

---

Теоретически - определяется системой, потерь быть не должно. Но команда инициализации ВВ51 вычитывает все имеющиеся данные и игнорирует их.

Цитата:

---

Сообщение от b2m

Теоретически - определяется системой, потерь быть не должно.

---

Примерно так и предполагал, но лучше было уточнить.

Цитата:

---

Но команда инициализации ВВ51 вычитывает все имеющиеся данные и игнорирует их.

---

"Команда инициализации" - это при рестарте "Вектора" - системный сброс, или что-то другое имеется в виду ?

Цитата:

---

Сообщение от KTSerg

"Команда инициализации" - это при рестарте "Вектора" - системный сброс, или что-то другое имеется в виду ?

---

Имеется ввиду команда "сброс" ВВ51, число 40h посланное в порт управления, более подробно читать в даташите. Ну и системный сброс тоже.

Цитата:

---

Сообщение от b2m

Имеется ввиду команда "сброс" ВВ51, число 40h посланное в порт управления, ...

---

Упс. Похоже я в конфиге эмулятора совсем убрал ВВ55 с "ПУ" и воткнул вместо него 3 шт ВВ51. Да ещё и без настроек (без порта управления).

У кого есть желание проверить "виртуальный контроллер ЛВС" ?
Который подключается к Вектору в эмуляторе emu, и грузит в него программу по протоколу ЛВС штатного загрузчика.

Во вложении программка виртуального контроллера и конфиг для emu (как я его смог понять).
В конфиге вырезан ВВ55 на порты 04...07, и на эти порты повешены ВВ51 с СОМ-портами.

Программа контроллера просто демка возможностей. Со своими заморочками.
Поскольку загрузчик Вектора "дёргает" портами при рестарте, то запуск связки "контроллер"-эмулятор работает только в строгой последовательности:
1. Запустить программу контроллера (т.к. он выступает в роли сервера для сокетов).
2. Запустить эмулятор emu.
3. В эмуляторе перезагрузить Вектор в режим загрузки с кассеты (F1+F11).
4. В контроллере выбрать файл, который нужно загрузить в Вектор (кнопка "Open File").
5. В эмуляторе перезагрузить Вектор в режим загрузки с ЛВС (F1+F3+F11).
Собственно должна начаться загрузка.

Эта инструкция есть на форме программы контроллера.

Гы, работает!

- - - Добавлено - - -

А как это в жизни должно было быть? Раз работает загрузчик, значит это в какой-то мере совместимо с реалом. У Векторовского адаптера ЛВС было три вв51?

Цитата:

---

Сообщение от svofski

У Векторовского адаптера ЛВС было три вв51?

---

Нет, конечно, обычный ВВ55 (ПУ) служил интерфейсом к адаптеру - три восьмибитных порта.

- - - Добавлено - - -

А протокол где-то описан? Может мне виртуальную ЛВС сделать, с доступом к картотеке? :)

Цитата:

---

Сообщение от b2m

...
А протокол где-то описан? Может мне виртуальную ЛВС сделать, с доступом к картотеке? :)

---

В открытых источниках готового описания протокола вроде не видел. Много лет назад, восстанавливал протокол ЛВС по дизасму штатного загрузчика. На этом форуме выкладывал результаты, вместе со схемой реверса контроллера (ещё наверное на 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. А вешать ещё один сервер, ещё на один порт... и без него работает :)

- - - Добавлено - - -

Цитата:

---

Сообщение от svofski

А как это в жизни должно было быть? ... У Векторовского адаптера ЛВС было три вв51?

---

Вроде обсуждали, что скорее всего, на реальном контроллере ЛВС стояла одна ВВ51, с обвязкой.
Правда я не могу себе представить, как на СОМ-портах можно собрать одноранговую сеть, в которой любой комп может общаться с любым другим компом.
Хотя мы достоверно не знаем как была организована реальная сеть компьютерного класса на основе учительского ДВК и ученических Векторов. Возможно была возможность только загрузить программу с ДВК на все (или любой на выбор) ученические компы, а обратная связь не предусматривалась. И ученические рабочие места между собой не могли связаться.
Сейчас таких подробностей уже наверное никто и не вспомнит.

Цитата:

---

Сообщение от KTSerg

Хотя мы достоверно не знаем как была организована реальная сеть компьютерного класса на основе учительского ДВК и ученических Векторов. Возможно была возможность только загрузить программу с ДВК на все (или любой на выбор) ученические компы, а обратная связь не предусматривалась.

---

Про сеть с ДВК есть еще какая-то информация? В вектор-user 7 есть про КУВТ ВЕКТОР+ с РМП ЕС 1840 и РМУ Векторы, я думал это был основной вариант.

Цитата:

---

Сообщение от ivagor

Про сеть с ДВК есть еще какая-то информация? В вектор-user 7 есть про КУВТ ВЕКТОР+ с РМП ЕС 1840 и РМУ Векторы, я думал это был основной вариант.

---

Нет, только какие-то остатки не понятно какой инфы. Возможно даже не достоверной.
Знаю точно, что ДВК использовался как учительский комп в классе с учиническими на основе БК0010. Т.к. в технаре в таком классе (С ДВК и БК0010) Бейсик и Фокал изучал.

Цитата:

---

Сообщение от KTSerg

а как должен был выглядеть "правильный" конфиг для проброса "ПУ" на сокеты ?

---

Если предположить, что в реальном контроллере стояла ВВ51, то порт В ПУ должен идти на порт данных ВВ51, а биты порта С соответственно на управляющие биты ВВ51. Но на данный момент такого подключения ВВ51 в эмуляторе не предусмотрено.
Непонятно только, как в адаптере ЛВС происходила инициализация ВВ51.

Цитата:

---

Сообщение от b2m

Если предположить, что в реальном контроллере стояла ВВ51, то порт В ПУ должен идти на порт данных ВВ51, а биты порта С соответственно на управляющие биты ВВ51. Но на данный момент такого подключения ВВ51 в эмуляторе не предусмотрено.

---

Я немного не о том.
Вот я подгоняя конфиг эмулятора под проброс портов разъёма "ПУ" на сокет, удалил ВВ55 из "Вектора" и воткнул на эти порты ВВ51 (предполагаю, что аж 3шт.).
Можно ли было записать эти настройки в конфиге как-то по другому, или как это должно выглядеть правильно.
Хотя если ВВ51 это один порт, то в любом случае прописывать в конфиг их нужно 3 штуки.

Цитата:

---

Непонятно только, как в адаптере ЛВС происходила инициализация ВВ51.

---

В алгоритме есть какая-то запись в порт данных, может это и есть инициализация ВВ51. Нужно внимательнее посмотреть.
Я предполагал, что в самом начале опрашивается номер контроллера и возможно сравнивается с адресом получателя/адресата для сеанса.
Возможно это не так.

Цитата:

---

Сообщение от KTSerg

Правда я не могу себе представить, как на СОМ-портах можно собрать одноранговую сеть, в которой любой комп может общаться с любым другим компом.

---

Пакет (токен) передается от машины к машине. Каждая машина ловит свой пакет, а чужой передает дальше. Если пакет пустой, его можно захватить и передать свои исходящие данные. РМУ с номером 0 декларируется инициатором и периодически отправляет токены.

Вроде не рокет саенс, но это требует надежного приема данных от сетевого модуля, что без прерываний и FIFO не то что бы невозможно, но требует практически непрерывного опроса портов. Вариант: когда сетевой Бейсик хочет общаться, он щелкает реле, и включается в сетевую жизнь, например чтобы запросить загрузку программы с РМП, или сохраниться туда же. После этого реле щелк RxD на TxD, и машина из сети выключается. Компромисс, но для своего времени это могло бы быть терпимым решением.

План простой:

- делаем условный интернет-РМП, который хранит программы на Бейсике
- эмуляторы и железки включаются в такой эмулируемый токен ринг. вместо номера РМУ можно использовать GUID или мало ли что.
- дело за малым, написать Бейсик с поддержкой такой сети
- все Векторы, виртуальные или нет, объединяются в компьютерный класс
- Вектор-06ц становится Нью Блокчейн, Блокчейн переименовывается в Старый Вектор-06ц

Цитата:

---

Сообщение от svofski

Пакет (токен) передается от машины к машине. Каждая машина ловит свой пакет, а чужой передает дальше. Если пакет пустой, его можно захватить и передать свои исходящие данные. РМУ с номером 0 декларируется инициатором и периодически отправляет токены.
...

---

Физически, это соединение всех компов в классе в одно кольцо: Rx - подключен к Tx предыдущего, а Tx - к Rx следующего в кольце. И гонять пакеты по кольцу, пока они не достигают адресата.
Так получается? Если задержка не критична, вполне может быть...

Да, именно так. Быстродействие это явно не то, чем мы, как Вектористы, можем соблазнить мир на сегодняшний день.

Цитата:

---

Сообщение от KTSerg

Можно ли было записать эти настройки в конфиге как-то по другому

---

Для твоего случая - всё верно.

Цитата:

---

Сообщение от KTSerg

Хотя если ВВ51 это один порт

---

ВВ51 это два порта: 0 - данные, 1 - управление/инициализация

- - - Добавлено - - -

Цитата:

---

Сообщение от KTSerg

В алгоритме есть какая-то запись в порт данных, может это и есть инициализация ВВ51.

---

Готовый дизасм есть?

С 99-го по 2000-ый играл (на РС) в "VGA Planets" - пошаговая стратегия. Просто мечтал, что-бы что-то подобное было для Вектора. Т.к. ни ресурсов ни быстродействия не требует.
Игра по переписке. Получил по почте файл от сервера, открыл его в интерфейсе, сделал ходы своими кораблями, отправил файл на сервер для обработки хода.
Один был у игры минус... "быстрая" партия длилась от полутора до двух лет, это те игры в которых я участвовал. Такой своеобразный был сеанс одновременной игры в нескольких партиях.
Хотя опытные игроки говорили, что на турнирах (когда все участники собирались в одном игровом зале), умудрялись одну игру (партию) за ночь закончить.

- - - Добавлено - - -

Цитата:

---

Сообщение от b2m

...ВВ51 это два порта: 0 - данные, 1 - управление/инициализация

---

Один UART, два внутренних (данные/управление), это я понял.

Цитата:

---

Готовый дизасм есть?

---

Вечером дома гляну, где-то была вырезка "только полезное" из загрузчика.

в оффтопку

Зачетная игра по переписке, изначально для Game Boy Advance: https://awbw.amarriner.com/

[свернуть]

Цитата:

---

Сообщение от KTSerg

Вечером дома гляну

---

Посмотрел в эмуляторе. Не похоже это на ВВ51. Моё предположение такое:
8 двунаправленных сигналов данных, направлением рулит сервер (управляющий сигнал не показан на схеме)
1 управляющий сигнал от сервера команда/данные (на твоей схеме обозначен "передача")
1 сигнал запрос/подтверждение от сервера к клиентам (у тебя "байт на шине", запрос это или подтверждение зависит от направления передачи)
1 сигнал запрос/подтверждение от клиентов к серверу (у тебя "байт прочитан")

После того, как клиент обнаружил команду, предназначенную ему, он подтверждает её. И это единственный вывод в порт В в загрузчике. Формат команды NNNAAAAA, где N - номер команды (0 - начальная загрузка), а A - адресат.
Номера других команд и формат их пакетов, естесственно, неизвестен.

Да, согласен. Не похоже на ВВ51.
Глянул код инициализации, не вижу классической инициализации (загрузки настроек и команд в регистры контроллера), в порт В выводится только то, что до этого считывается из порта А (с маской 1Fh). И сразу после этого Вектор ожидает начала сеанса.
Вроде как прочитал из порта А свой адрес, выдал его в контроллер (порт В), и ждёт что контроллер будет готов к работе.
После начальной билитристики, ВВ55 настраивает младшие биты порта С как вЫходные сигналы (при этом в загрузчике используется только один бит - подтверждение приёма байта), а старшие биты порта С - входные сигналы (старший бит в загрузчике не используется).
Т.к. нет ни настоящего контроллера, и нет родного ПО с полноценной реализацией протокола, нам остаётся только гадать на кофейной гуще.

b2m, у описания соединения:
com5 : K580ww51 {
connect="tcp:30360:127.0.0.1"
}
есть ещё какие-то параметры?
"логин/пароль" например, или ещё что-то, что могло-бы идентифицировать данного "клиента" на стороне "сервера", кроме номера порта клиента, который выбирается системой случайным образом (первый из свободных).

Нет, либо с IP адресом, чтобы сам коннектился, либо без, чтобы ждал соединения. В последнем случае первым байтом выдаст номер соединения (нужен для сетей). Когда работает в качестве сервера, то данные рассылает всем клиентам.

Сомневаюсь, что это представляет для кого-то интерес.
Но выложу папку с проектом виртуального контроллера ЛВС на Delphi7.
Удобно, что эмулятор emu удерживает данные (отправленные в сокет) для порта Вектора даже когда порт уже был прочитан программой Вектора.
Например при опросе наличия контроллера, программа читает из порта 3 байта (с ожиданием синхры передачи байта) и проверяет на соответствие 55h.
А виртуальному контроллеру, в этой ситуации достаточно один раз отправить в сокет байт 55h и три пары байт синхры - передачи байта информации. Программа Вектора читая порты воспринимает это как положено.

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

Сомневаюсь, что это представляет для кого-то интерес.
Но... Прикрутил я к эмулятору язычёк под названием Lua (ниже ссылка на архив с плагином). Очень уж захотелось сделать виртуальный контроллер ЛВС.

Сначала я не хотел выкидывать ВВ55, чтобы не париться с её реализацией в Lua, но как выяснилось, при настройке порта на ввод, эмуль ничего не пишет в связанное с этим портом устройством (на ввод же программируем). Т.е. привязка к еденице в реальном устройстве не будет эмулироваться как хотелось бы. В связи с этим пришлось полностью заменить ВВ55 виртуальным устройством на Lua.

Для начала меняем конфиг:

Код:

---

ext : lua-script {
  script="Vector06c\lua\locnet.lua"
  data.onread="read"
  data.onwrite="write"
}

---

Тут мы задаём имя файла со скриптом и имена функций для устройства ext.data (вместо data могло быть что-то иное, но я решил оставить имя, которое было у ВВ55).

Привязка к портам процессора осталась как и была у ВВ55:

Код:

---

CPU : K580wm80a {
...
  port~[04-07]=ext.data
...

---

Минимальный .lua в данном случае мог выглядеть так:

Код:

---

function read(addr)
  return 0
end
function write(addr, val)
end

---

То есть при чтении всегда выдаётся 0, а при записи ничего не делаем.

Первым делом я сделал протоколирование обращения к устройству:

Код:

---

local f = io.open("test.txt", "w+")

function read(addr)
  local val = 0
  f:write("rd ", addr, " ", val, "\n")
  return val
end

function write(addr, val)
  f:write("wr ", addr, " ", val, "\n")
end

---

Далее, в зависимости от режима ВВ55 (поддерживаются только некоторые из всех возможных) я сделал возможность выполнять разные действия, и одним из первых стал режим детектирования контроллера ЛВС:

Скрытый текст

Код:

---

local function zero() return 0 end
local function nop(val) end

local detval = 0
local function rdet() return detval end
local function wdet(val) detval = (val&0x80)>>4 end

local default = {
name = "default",
read = {zero,zero,zero,zero},
write = {nop,nop,nop},
enter = nop
}

local recv = {
name = "recv",
read = {zero,zero,zero,zero},
write = {nop,nop,nop},
enter = nop
}

local send = {
name = "send",
read = {zero,zero,zero,zero},
write = {nop,nop,nop},
enter = nop
}

local detect = {
name = "detect",
read = {zero,zero,rdet,zero},
write = {wdet,nop,nop},
enter = nop
}

local modesel = {
[0x9B] = default,
[0x9A] = recv,
[0x98] = send,
[0x8B] = detect
}

local mode = default

local f = io.open("test.txt", "w+")

function read(addr)
  local val = mode.read[addr+1]()
  f:write("rd ", addr, " ", val, "\n")
  return val
end

function write(addr, val)
  if addr==3 then
    mode = modesel[val] or default
    mode.enter()
    f:write("mode ", mode.name, "\n")
  else
    mode.write[addr+1](val)
    f:write("wr ", addr, " ", val, "\n")
  end
end

---

[свернуть]

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

Ну а далее шаг за шагом реализовывался весь (известный) протокол ЛВС. Конечный вариант есть в архиве. Имя загружаемого файла задаётся в самом скрипте.

Архив с плагином: luaplug.zip

Я пролистал тред и только запутался. Вся борьба за эмуляцию чего? подключенного к Вектору через ВВ51 некоего LAN-устройства? какого именно? А то уже тут ЛУА, и неясно во что именно в железе выльются все эмуляторские изыски.

Цитата:

---

Сообщение от Error404

Я пролистал тред и только запутался

---

Название треда вроде говорит само за себя: эмуляция виртуального контроллера. Гипотетическое устройство, подключаемое к портам эмулируемого Вектора. При желании, можно реализовать какое-либо реальное устройство. В данном случае рассматривался контроллер локальной сети, который в железе теперь очень сложно найти. И найдёт ли кто-нибудь - неизвестно.