Эмуляция сети

[b2m]

Ethernet заэмулировали
Ну, снаружи эмулятора я могу WinPcap подключить, а какое железо внутри эмулировать? Надеюсь, не на уровне электрических сигналов Tx/Rx витой пары? :)
Хотя, WinPcap позволяет только слушать, надо будет ещё какой-то пакетный фильтр найти, с возможностью отправки...

---------- Post added at 18:37 ---------- Previous post was at 18:08 ----------

Есть ещё TAP win32 driver из OpenVPN, но с ним тоже разбираться надо. К тому-же, этот драйвер ещё сначала инсталлировать надо.

[Error404]

Ну, снаружи эмулятора я могу WinPcap подключить, а какое железо внутри эмулировать? Надеюсь, не на уровне электрических сигналов Tx/Rx витой пары? :)
Хотя, WinPcap позволяет только слушать, надо будет ещё какой-то пакетный фильтр найти, с возможностью отправки...

---------- Post added at 18:37 ---------- Previous post was at 18:08 ----------

Есть ещё TAP win32 driver из OpenVPN, но с ним тоже разбираться надо. К тому-же, этот драйвер ещё сначала инсталлировать надо.

Эмулируй любой чип, реализующий MAC+PHY. В его типовом включении (только чтобы без всяких ДМА, т.к. на реале такое не полетит). Здесь самое сложное не чип эмулировать или какие-то конкретные порты (а посему не сложно и другие аналогичные чипы эмулировать когда один любой отладишь), а движок самого эмулятора, реализующий физику LAYER2 и ниже. Ведь надо "выпустить" твой виртуальный адаптер эмулятора во внешнюю сеть, чтобы оно нормально коммуницировало с прочим сетевым оборудованием. Чтобы Z80-код IP-стека, выполняемый в эмуляторе, нормально обменивался с прочими хостами в реальной сети.
И да, WinPcap не годится. Полгода назад когда я это обдумывал, ничего более подходящего чем TAP от OpenVPN мне не придумывалось (чтобы уже не всё писать самому, что совершенно неподъемно, а использовать что-то готовое).

[b2m]

Здесь самое сложное не чип эмулировать или какие-то конкретные порты (а посему не сложно и другие аналогичные чипы эмулировать когда один любой отладишь), а движок самого эмулятора, реализующий физику LAYER2 и ниже. Ведь надо "выпустить" твой виртуальный адаптер эмулятора во внешнюю сеть, чтобы оно нормально коммуницировало с прочим сетевым оборудованием.
Я с TAP от OpenVPN не разбирался, но по-моему он как раз и реализует "физику LAYER2 и ниже", раз уж это виртуальный сетевой адаптер. Как я полагаю, он позволяет отправлять и принимать "сырые" пакеты. А это именно то, что и будет считано/передано через порты "виртуального" чипа внутри эмулятора.

[Error404]

Я с TAP от OpenVPN не разбирался, но по-моему он как раз и реализует "физику LAYER2 и ниже", раз уж это виртуальный сетевой адаптер. Как я полагаю, он позволяет отправлять и принимать "сырые" пакеты. А это именно то, что и будет считано/передано через порты "виртуального" чипа внутри эмулятора.

Да. Только всю эту "физику" надо правильно настроить (тот самый виртуальный коммутатор TAP-адаптеров, который надо не только сам настроить, но еще и настроить для него роутер во внешнюю - реальную - сеть). Также надо API, через которое ты с этим адаптером будешь общаться из эмулятора - под NT и ее клонами работать с устройствами такого класса можно только из драйвера, никак не из приложений. То есть нужен драйвер. Я там тому назад предлагал для этого пользоваться драйвером NDIS (конкретно - уже готовый ndisprot, пример использования есть).

Таким образом, как минимум нужна методичка объясняющая назначение всех этих подсистем, и как все это инсталлировать и настраивать, т.к. пользователи, просящие "раскрасить дебугер" сами до этого никогда не допрут. В понятном виде. Я на что уж сам писатель... был..., но твои конфиги до сих пор не осилил. :)

И вот уже всю эту кучу надо увязать в концепции эмулятора и попутно съэмулировать "точку входа" в это безобразие в виде какого-нить Ethernet-чипа в типовом включении (что-нить простое типа RTL8019as или DP8390D).

Т.е. вырисовывается задачка не скажу что грандиозная, но внушает... :)
Сложная, но нужная... Как то так....

[b2m]

Насколько я понял, ndisprot позволяет отправлять и принимать данные непосредственно через имеющуюся сетевую карту (правда, не совсем понятно, как будет обрабатываться входящий траффик по IP - будет он передан только обработчику протокола IP или же обеим обработчикам, и можно ли установить два обработчика протокола IP). Правда, в таком случае у нас не получится соедениться с программами, работающими на том-же компьютере, что и эмулятор. Можно, конечно, установить loopback-адаптер, но будет ли это работать, сказать сложно.

TAP-драйвер, наоборот, выступает в роли сетевой карты, и будучи привязанным к протоколам TCP/IP, позволяет принимать и отправлять данные через сетевой стек на том-же компьютере. А чтобы отправлять через сетевую карту, нужно настроить роутинг во внешнюю сеть, точно также, как между двумя реальными сетевыми картами.

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

Я, правда, не совсем понимаю, как это сделано в VMware - там гостевая ОС может работать и с хостом, и с другими компьютерами в сети.

[Error404]

Насколько я понял, ndisprot позволяет отправлять и принимать данные непосредственно через имеющуюся сетевую карту (правда, не совсем понятно, как будет обрабатываться входящий траффик по IP - будет он передан только обработчику протокола IP или же обеим обработчикам, и можно ли установить два обработчика протокола IP). Правда, в таком случае у нас не получится соедениться с программами, работающими на том-же компьютере, что и эмулятор. Можно, конечно, установить loopback-адаптер, но будет ли это работать, сказать сложно.

TAP-драйвер, наоборот, выступает в роли сетевой карты, и будучи привязанным к протоколам TCP/IP, позволяет принимать и отправлять данные через сетевой стек на том-же компьютере. А чтобы отправлять через сетевую карту, нужно настроить роутинг во внешнюю сеть, точно также, как между двумя реальными сетевыми картами.

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

Я, правда, не совсем понимаю, как это сделано в VMware - там гостевая ОС может работать и с хостом, и с другими компьютерами в сети.

Я себе представлял так:

[Эмулятор->NDIS]->[[TAP1<-бридж->TAP2]->router->realEth]->внешняя сетка

Здесь адаптеры TAP1, TAP1 и виртуальный свитч (бридж) образуют IP-подсеть 1. Наш PC работает роутером из подсети 1 в подсеть 2 куда входит реальный адаптер realEth. Соответственно:
- на адаптере TAP1 кодом Z80 эмулятора через NDIS устанавливается МАС и настраивается IP из сетки1.
- На адаптере realEth средствами Винды настраивается IP из сетки2
- на адаптере TAP2 средствами Винды настраивается IP из сетки1 (типовой случай с РС-роутером, который смотрит двумя адаптерами - TAP2 и realEth - в две сетки)

Как я понимаю, TAP-адаптеры никак не привязаны к IP (LAYER3), они эмулируют на уровне MAC (LAYER2). Хочешь, можно вообще на них IP не поднимать, а поднять что-то другое. Соответственно, в адаптер TAP1 мы можем из эмулятора через NDIS дуть голыми пакетами, которые полностью программно формируются стеком IP, реализованным на Z80 (т.е. они не голые на самом деле, а содержат все нужные структуры для IP). И нормально получать ответы в виде голых же пакетов LAYER2 (это нам обеспечит виртуальный свитч - ему достаточно знать МАС-и TAP1 и TAP2 чтобы понимать что от кого и кому слать).

Сейчас ковыряю, наделал ТАР-ов, пока не понятно что к чему. При создании бриджа ТАР-ы (до того отдельные девайсы со своими MAC) перестают енумероваться по-отдельности, вместо них енумеруется только бридж с единственным MAC-ом. Надо подумать отчего так... :)

[b2m]

Я себе представлял так:
Как-то сложно ты всё представляешь :)
На мой взгляд есть 2 варианта:
1. эмулятор -> ndisprot.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть
2. программы на локальном PC <- winsock <- tcpip.sys <- NDIS <- tap0801.sys <- эмулятор

В первом случае, для взаимодействия с программами на локальном PC нужен loopback-адаптер.
То есть получится так: эмулятор -> ndisprot.sys -> NDIS -> loopback-адаптер -> NDIS -> tcpip.sys -> winsock -> программы на локальном PC

Во втором случае, для выхода во внешнюю сеть нужен сервис, который будет осуществлять роутинг (на уровне IP) между реальной сетевой картой и tap0801.sys
То есть так: эмулятор -> tap0801.sys -> NDIS -> tcpip.sys -> router service -> tcpip.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть

[Error404]

Как-то сложно ты всё представляешь :)
На мой взгляд есть 2 варианта:
1. эмулятор -> ndisprot.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть
2. программы на локальном PC <- winsock <- tcpip.sys <- NDIS <- tap0801.sys <- эмулятор

В первом случае, для взаимодействия с программами на локальном PC нужен loopback-адаптер.
То есть получится так: эмулятор -> ndisprot.sys -> NDIS -> loopback-адаптер -> NDIS -> tcpip.sys -> winsock -> программы на локальном PC

Во втором случае, для выхода во внешнюю сеть нужен сервис, который будет осуществлять роутинг (на уровне IP) между реальной сетевой картой и tap0801.sys
То есть так: эмулятор -> tap0801.sys -> NDIS -> tcpip.sys -> router service -> tcpip.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть

В первом случае на этом физическом адаптере возможна или работа эмулятора, или работа всех прочих IP-программ Винды. Потому что NDIS - это то что "раньше" всего стека IP, доступ к LAYER2 минуя весь стек IP. В параллель два стека (эмуляторский и виндовый) на одном физическом (или виртуальном) приборе канального уровня (MAC) работать не могут.

Второй случай невозможен, потому что через NDIS (не через TAP, TAP это уже ниже NDIS, это сам адаптер, как я понимаю, к которому доступ должен быть через драйвер - NDIS в нашем случае) ты опять же выведешь пакет в канальный уровень. Оттуда этот пакет может быть передан только на другой адаптер. Этот другой адаптер, получив пакет LAYER2, уже "дернет вверх" всю цепочку уровней протокола IP (LAYER3 и выше - TCP/UDP). И вот на этом, другом адаптере уже может жить router, потому что router - это понятие уровня LAYER3.

loopback-интерфейс вообще никогда не пропускает пакеты на уровень LAYER2 (куда мы ходим при помощи NDIS). Пакеты разворачиваются "сами на себя" на уровне LAYER3.

[b2m]

В параллель два стека (эмуляторский и виндовый) на одном физическом (или виртуальном) приборе канального уровня (MAC) работать не могут.
Есть подозрение, что если к сетевой карте привязаны два протокола, то входящие пакеты NDIS будет дублировать для обоих обработчиков протокола. А обработчики должны "отвечать" только на "свои" пакеты.


Второй случай невозможен
Я не понял, так ты разобрался, как работать с TAP-драйвером? Или всё-таки нет?


loopback-интерфейс вообще никогда не пропускает пакеты на уровень LAYER2 (куда мы ходим при помощи NDIS). Пакеты разворачиваются "сами на себя" на уровне LAYER3.
По моему ты путаешь loopback-интерфейс и localhost с адресом 127.0.0.1. Обращения к localhost действительно обрабатываются на уровне tcpip.sys, а loopback-интерфейс выглядит для системы как сетевая карта, которая возвращает все посланные пакеты обратно.

[Error404]

Я не понял, так ты разобрался, как работать с TAP-драйвером? Или всё-таки нет?


Пока нет.
Но других путей не вижу.
Все виртуалки на РС (которые по сути - эмуляторы) работают с сеткой через TAP или его проприетарный аналог.

---------- Post added at 23:29 ---------- Previous post was at 22:11 ----------



Сеть я делать врятли буду, нифига в этом непонимаю.

Дык никто не понимает. Надо разбираться. :)

---------- Post added 15.02.2011 at 00:46 ---------- Previous post was 14.02.2011 at 23:29 ----------

Некоторые приемы работы с TAP прогуглил. Ничего особенного - открыл, читаешь/пишешь. :)
http://www.rsdn.ru/forum/network/3842938.flat.aspx
http://www.rsdn.ru/forum/winapi/2724711.aspx

А вообще, все сразу посылают в исходники OpenVPN - дескать "иди и смотри".

А сама концепция пока не ясна. Неясно главным образом почему при объединении в бридж, и реальные адаптеры и TAP-ы перестают энумероваться (например из NDIS по ndisprotQueryBinding, да везде - даже по ipconfig, т.е. по GetAdaptersInfo) .

Ну, тоесть в man-ax на OpenVPN конечно написано, что в Винде после объединения в бридж адаптеры теряют идентичность, и "сущность адаптера" остается только у бриджа, но нафига это так сделано и как это уложить в башке - пока не понятно. Что самое интересное, в Линухе виртуальные адаптеры после объединения в бридж никуда не деваются, как это происходит в Винде.

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




эмулятор<-------+------->TAP1<-------+-------->router<-----+--->RealEthAdapter
(IP-subnet1) | | is our | (IP-subnet2)
| | PC |
WinAPI (CreateFile, Windows IP stack Windows IP stack
WriteFile, ReadFile,
DeviceIoControl)


Как видим, никакого NDIS.
А РС, на котором будет работать эмулятор, сам будет роутить из сети где находится TAP1 в сеть реального адаптера, надо только галку поставить где надо. Или не ставить, если выход во внешнюю сеть не нужен - тогда взаимодействующий IP-софт (telnet, к примеру) просто запускаем на своем же РС - там же где и эмулятор, натравив его на TAP1.
При этом TAP1 не обслуживается двумя стеками. "IP-стек кода на Z80" транслируется на выходе эмулятора в вызовы WinAPI, которые просто являются симметричной ответной частью для IP-стека Винды (имитирую ответные-парные "отправки и прием пакета" в/из эмулятор).

[Error404]

эмулятор<-------+------->TAP1<-------+-------->router<-----+--->RealEthAdapter
(IP-subnet1) | | is our | (IP-subnet2)
| | PC |
WinAPI (CreateFile, Windows IP stack Windows IP stack
WriteFile, ReadFile,
DeviceIoControl)


Как видим, никакого NDIS.
А РС, на котором будет работать эмулятор, сам будет роутить из сети где находится TAP1 в сеть реального адаптера, надо только галку поставить где надо. Или не ставить, если выход во внешнюю сеть не нужен - тогда взаимодействующий IP-софт (telnet, к примеру) просто запускаем на своем же РС - там же где и эмулятор, натравив его на TAP1.
При этом TAP1 не обслуживается двумя стеками. "IP-стек кода на Z80" транслируется на выходе эмулятора в вызовы WinAPI, которые просто являются симметричной ответной частью для IP-стека Винды (имитирую ответные-парные "отправки и прием пакета" в/из эмулятор).

Правда в последнем варианте канальный уровень "подсети1" и "второй адаптер подсети1" (тот который в эмуляторе) полностью придется обеспечивать эмулятором. Т.е. если в ранней моей схеме в реальный (пускай и TAP) адаптер Винды просто через NDIS передавался пакет (массив) подготовленный Z80-IP-стеком эмулятора, и инкапсуляция этих данных в Ethernet-кадр выполнялась этим адаптером, а передача далее (на второй TAP) производилась бриджем, то в последнем случае и "рисовать исходящий из эмулятора Ethernet-фрейм" и парсить "входящий Ethernet-фрейм" на предмет выделения "на мой MAC пришло или не на мой (да еще в зависимости от promiscuous mode), или это вообще широковещательный пакет" надо будет уже в коде эмулятора.

Все это оттого, что пока никто не сделал под виндой для Ethernet аналог пакета com0com (2 виртуальных адаптера, соединенных кросовером). Если бы это было, можно было бы существенно облегчить себе жизнь. Я думал в этом качестве можно будет использовать схему "TAP-бридж-TAP" (как я это делал бы на реальном оборудовании), но к сожалению бридж в Винде сделан как-то по ублюдочному.

[Error404]

b2m, что скажешь? Реализуемо?

[b2m]

Как мне кажется, внутри эмулятора не надо ничего "рисовать и парсить". После объединения в бридж сетевой карты и TAP-драйвера, пакеты будут без проблем пересылаться между двумя подсетями (точнее, это будет уже одна сеть). Так что с бриджем я планирую разобраться потом. Для начала нужно сделать виртуальную сетевую карту в эмуляторе и какую-нибудь тестовую прогу, например обработчик ARP, это самое простое. :)

[Error404]

Как мне кажется, внутри эмулятора не надо ничего "рисовать и парсить". После объединения в бридж сетевой карты и TAP-драйвера, пакеты будут без проблем пересылаться между двумя подсетями (точнее, это будет уже одна сеть). Так что с бриджем я планирую разобраться потом. Для начала нужно сделать виртуальную сетевую карту в эмуляторе и какую-нибудь тестовую прогу, например обработчик ARP, это самое простое. :)

Ну, дело хозяйское.
Ты делать решил?

[b2m]

Ты делать решил?
Попробую. Уже изучаю даташит на RTL8019AS. :) Начну, наверное, с регистров, совместимых с NE2000. Фактически, этот контроллер подключается напрямую на ISA-шину, так что это будет эмуляция практически любой ISA-шной сетевой карты, совместимой с NE2000.

Если с наскока не получится, отложу до лучших времён.

Просьба к модераторам отделить последние сообщения, связанные с эмуляцией сети, в отдельную тему, и поместить её в форум про эмуляторы.

[b2m]

Error404, вроде получилось. Правильность и полноту эмуляции, естественно, не гарантирую. В качестве тестовой платформы был выбран Радио-86РК, потому что есть текстовый экран и монитор, а также свободны все порты. rtl8019as я повесил на порты 80h-9Fh. Прежде чем запускать, нужно исправить в файле конфигурации имя виртуальной сетевой карты TAP-драйвера. После чего можно запустить программу net_test.rk. IP-адрес и маска подсети зашит в коде (172.20.0.2 255.255.0.0), но можно его исправить: в конце файла net_test.rk байты AC 14 00 02 FF FF 00 00 меняются на любой понравившийся адрес (точнее, на один из адресов в подсети TAP-драйвера). В тестовой программе обрабатываются пакеты ARP и ICMP, так что можно "пинговать" РК-шку :)

emu_net.rar (http://bashkiria-2m.narod.ru/files/emu_net.rar)

[Error404]

Error404, вроде получилось. Правильность и полноту эмуляции, естественно, не гарантирую. В качестве тестовой платформы был выбран Радио-86РК, потому что есть текстовый экран и монитор, а также свободны все порты. rtl8019as я повесил на порты 80h-9Fh. Прежде чем запускать, нужно исправить в файле конфигурации имя виртуальной сетевой карты TAP-драйвера. После чего можно запустить программу net_test.rk. IP-адрес и маска подсети зашит в коде (172.20.0.2 255.255.0.0), но можно его исправить: в конце файла net_test.rk байты AC 14 00 02 FF FF 00 00 меняются на любой понравившийся адрес (точнее, на один из адресов в подсети TAP-драйвера). В тестовой программе обрабатываются пакеты ARP и ICMP, так что можно "пинговать" РК-шку :)

emu_net.rar (http://bashkiria-2m.narod.ru/files/emu_net.rar)

Круто. :)
А как в РК-шку загружать файлы *.rk? Чего-то через OPEN пишет "непонятный формат".
А исходник net_test.rk покажешь? А еще какие покажешь? :) Сам писал или что-то готовое нашел?

Таки как используешь TAP? Единичный адаптер? C бриджем? Пишешь\читаешь по WriteFile\ReadFile самого TAP-устройства или все же через NDIS? Если через WriteFile\ReadFile, то эмулишь "голый канал" или как?
Давай рассказывай. :) Говорю же, понадобится мануал...
А еще надо прикрутить сетку к модели Спека. В ветке концепций подскажут на какие порты - там была такая ветка, может видел... А то там программисты страдают, что им не на чем программировать стеки. :)
Дескать "вот было бы - уж мы уж сразу бы тогда, а т.к. нет - то и мы нет" :)

[Mick]

Просьба к модераторам отделить последние сообщения, связанные с эмуляцией сети, в отдельную тему, и поместить её в форум про эмуляторы.

Перенес, название темы сами придумайте. Пока обозвал так.

[b2m]

А как в РК-шку загружать файлы *.rk? Чего-то через OPEN пишет "непонятный формат".
Мой косяк, не сказал, что в архиве выше это не урезанный эмулятор, а обновление полной версии. Перезалил архив, теперь там есть все нужные файлы (и нет лишних). Также, подправил EMU.ext, чтобы при открытии файлов с расширением .rk автоматически выбиралась конфигурация с сетью, а не обычная РК.


А исходник net_test.rk покажешь? А еще какие покажешь? :)
Программка в принципе не большая, кому надо - дизассемблирует. :) Хотя можно и выложить.


Сам писал или что-то готовое нашел?
Сам писал. Зато - ничего лишнего.


Таки как используешь TAP? Единичный адаптер? C бриджем? Пишешь\читаешь по WriteFile\ReadFile самого TAP-устройства или все же через NDIS? Если через WriteFile\ReadFile, то эмулишь "голый канал" или как?
Я посмотрел исходники QEMU, и сделал аналогично.


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

---------- Post added at 20:17 ---------- Previous post was at 18:42 ----------


Таки как используешь TAP? Единичный адаптер? C бриджем? Пишешь\читаешь по WriteFile\ReadFile самого TAP-устройства или все же через NDIS? Если через WriteFile\ReadFile, то эмулишь "голый канал" или как?
А если подробнее, то так:
1. ищем в реестре guid сетевого адаптера TAP
2. открываем устройство \\.\Global\{guid}.tap, обязательно использовать FILE_FLAG_OVERLAPPED
3. установить статус (TAP_IOCTL_SET_MEDIA_STATUS, номер кода для DeviceIoControl можно взять из исходников QEMU)
4. использовать ReadFile/WriteFile асинхронно (т.е. с параметром lpOverlapped).

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

[Black_Cat]

Эмулируй любой чип, реализующий MAC+PHY. В его типовом включении (только чтобы без всяких ДМА, т.к. на реале такое не полетит). кстати, если осилить эмуляцию 8237, то можно и DMA прикрутить

[Error404]

Программка в принципе не большая, кому надо - дизассемблирует. :) Хотя можно и выложить.

А вдруг я неправильно эмулирую Надо сначала как-то проверить эмуляцию. Вот подключил бы кто сетевуху к какому-нибудь компу, чтобы проверить тестовую программу...



Выкладывай все чего не жалко - так быстрее найдут ошибки, кто начнет заниматься. На реале (тем паче на РК-86) это вообще не известно когда увидит свет.

[b2m]

кстати, если осилить эмуляцию 8237, то можно и DMA прикрутить
Можно. Но зачем?
С железной т.з. гораздо проще прикрутить к портам компьютера какую-нибудь NE2000-совместимую ISA карту (а если системная шина выходит на разьём, то достаточно будет спаять переходник, ну или как максимум буферизировать/инвертировать сигналы, если надо).

---------- Post added at 21:44 ---------- Previous post was at 21:38 ----------


Выкладывай все чего не жалко - так быстрее найдут ошибки, кто начнет заниматься. На реале (тем паче на РК-86) это вообще не известно когда увидит свет.
Исходник я уже поместил в архив. Если кто-то из реальщиков сможет подключить ISA-карту (и не спалить комп), то будет вообще замечательно. А я могу к любому из эмулируемых компов прикрутить.

[Black_Cat]

Можно. Но зачем?
С железной т.з. гораздо проще прикрутить к портам компьютера какую-нибудь NE2000-совместимую ISA карту ты не понял. Карта прикручивается по любому, но можно сэмулировать более полно шину ISA, чтоб использовать её штатные вызовы ПДП и прерывания. Для этого надо дополнительно сэмулировать контроллер ПДП 8237 и контроллер прерываний 8259 - вот что имелось ввиду.

[KokaF77]

Исходник я уже поместил в архив.
Спасибо.


ты не понял. Карта прикручивается по любому, но можно сэмулировать более полно шину ISA, чтоб использовать её штатные вызовы ПДП и прерывания. Для этого надо дополнительно сэмулировать контроллер ПДП 8237 и контроллер прерываний 8259 - вот что имелось ввиду.
Полностью поддерживаю. И процессору полегче будет. Любая NE2000 (и даже NE1000) пошустрее будет нежели наш 8080. :)

[b2m]

ты не понял. Карта прикручивается по любому, но можно сэмулировать более полно шину ISA, чтоб использовать её штатные вызовы ПДП и прерывания. Для этого надо дополнительно сэмулировать контроллер ПДП 8237 и контроллер прерываний 8259 - вот что имелось ввиду.
NE2000 тем и отличается, что не использует ПДП вообще. И речь была пока только о совместимом с ней чипе rtl8019as (аналог NE2000 в одном чипе, плюс некоторые несущественные расширения, касающиеся в основном PnP и bootrom).

---------- Post added at 23:32 ---------- Previous post was at 23:22 ----------


Рекомендуется базовый ISA адрес #320, которому соответствует ZX адрес #2038.
Соответственно диапазон портов будет:
#2038-#3F38 (младший байт адреса - неизменный)
Ладно, с диапазоном портов определились, буду пробовать сотворить что-нибудь для спекки. Только вот для спекки я абсолютно ничего не писал...

[Black_Cat]

NE2000 тем и отличается, что не использует ПДП вообщезамечательно, если так :) Пошёл рисовать упрощённую схему подключения к Спеку :)

---------- Post added at 21:37 ---------- Previous post was at 21:33 ----------

IRQ тож не планируется использовать?

[b2m]

IRQ тож не планируется использовать?
Хороший вопрос. Может быть в будущем. А пока у меня в эмуляторе это не реализовано.

[Black_Cat]

пока у меня в эмуляторе это не реализовано. а в будущем каким методом планируется использовать IRQ - непосредственно каким-то образом подавать на INT CPU? Или периодически читать состояние линии IRQ из какого-то порта?

[b2m]

а в будущем каким методом планируется использовать IRQ - непосредственно каким-то образом подавать на INT CPU? Или периодически читать состояние линии IRQ из какого-то порта?
А нельзя как-то замапить: ISA-шные запросы -> прерывания Z80 в режиме IM2? Как это в спекки вообще сделано? Кто выдаёт вектор прерывания (в режиме IM2)?

[Black_Cat]

Кто выдаёт вектор прерывания (в режиме IM2)? если нет контроллера прерываний (а его обычно - нет), то вектор выдаёт подтяжка шины данных к +5, т.е. вектор всегда #FF, т.е. фактически по умолчанию вечный IM1

---------- Post added at 22:33 ---------- Previous post was at 21:59 ----------

Назначай IM2 и юзай стандартный для Спека метод генерации адреса обработчика - чтением из ПЗУ.
Более глубоко не скажу, эт у программистов надо спрашивать :)

[Error404]

Назначай IM2 и юзай стандартный для Спека метод генерации адреса обработчика - чтением из ПЗУ

Из какого ПЗУ? Бейсика?

Как я понимаю, дивайс в цикле активности сигнала прерывания в какой-то момент по комбинации сигналов ЦПУ должен придавить несколько адресных сигналов в "0" чтобы сформировать адрес вектора обработчика. При этом адрес никак не может быть в ПЗУ Бейсика, т.к. п\п обработки данных контроллера не находися в ПЗУ, оно ничего про нее не знает. Соответственно, значение регистра IM2 (адрес таблицы векторов) будет отличаться от дефолтной, указывающей в ПЗУ, и вызов п\п в ПЗУ, ранее вызывавшейся по кадровому бланку, надо будет дополнительно имитировать обрабатывая Int50Hz уже по новой таблице (где кроме Int50 есть еще и вектор для 8019).
Иначе чего-то там штатное у Спека работать не будет (небось, клавиатура).

В-общем, я наверное на Орионе буду делать без прерывания от 8019. Просто в обработчик Int50 (который уже есть) добавлю процедуру опроса наличия данных в буфере 8019. Иначе дополнительный обработчик запросов 8019 только лишние такты будет кушать на свои push/pop/call/reti (а учитывая что в Орионе вызов обработчиков будет скорее всего осуществлять с переходом в отличные от основной страницы ОЗУ, то это и еще доп. расходы ресурса CPU)

А будет пропускать пакеты, можно в полудуплекс переключить - это сразу снизит скорость в разы, но будет этого все равно достаточно по скорости. Нам же с ним не в космос лететь.

[Black_Cat]

Из какого ПЗУ? Бейсика? да из SOS48, кладёшь в I старший байт адреса в пределах #00-#3F, а младший будет #FF, и по этому адресу из ПЗУ читаешь 2 байта адреса обработчика (выбираешь из таблицы в зависимости от I какой больше нравится)

---------- Post added at 23:02 ---------- Previous post was at 22:52 ----------

..хотя с контроллером прерываний всёж лучше

[b2m]

Назначай IM2 и юзай стандартный для Спека метод генерации адреса обработчика - чтением из ПЗУ.
Более глубоко не скажу, эт у программистов надо спрашивать :)Не, тут вопрос как раз к железячникам - в режиме прерывания, при чтении вектора, процессор выдаёт интересную комбинацию сигналов (M1 и IORQ оба активны), и что будет выдаваться на шину - вопрос. И можно ли в этом случае выдавать некий код, в зависимости от ISA-запросов.

[Black_Cat]

Не, тут вопрос как раз к железячникам - в режиме прерывания, при чтении вектора, процессор выдаёт интересную комбинацию сигналов (M1 и IORQ оба активны), и что будет выдаваться на шину - вопрос. И можно ли в этом случае выдавать некий код, в зависимости от ISA-запросов. некий код может выдавать токо контроллер, а его по умолчанию - нет на Спеке. Если припаять самостоятельно - будет выдавать как запрограммируешь - хоть в IM0, хоть в IM2

[b2m]

..хотя с контроллером прерываний всёж лучше
Ну или с приоритетным шифратором :)

[Black_Cat]

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

[Error404]

Пример c пингом работает. Дамп на экране забавно заполняется - отчего он то в паре байт меняется, а то весь перерисовывается?

Ну чего, господам программистам теперь будет трудно отнекиваться от написания сетевого софта. :)

[b2m]

Пример c пингом работает. Дамп на экране забавно заполняется - отчего он то в паре байт меняется, а то весь перерисовывается?
Пара байт - это когда ICMP пакеты друг за другом идут, а весь - когда между ними приходят UDP пакеты винды (NTLM).

[psb]

Ну чего, господам программистам теперь будет трудно отнекиваться от написания сетевого софта.
отнекиваться будет легко, инфа 100%! :)))))

[Black_Cat]

Схема подключения NE2000 к Спеку: http://zx.clan.su/forum/8-81-1#520

[psb]

Вот лучше бы так опа и дать ссылку на сетевой софт для спека...

[b2m]

Схема подключения NE2000 к Спеку
Пара ламерских вопросов.

Если я правильно понимаю, порты NemoIDE доступны только из ПЗУ в режиме dos. Тогда прога для работы с сетевой картой должна сидеть вместо, например, glukpen.rom, так? В эмуляторе-то я чего хошь на какие угодно порты повесить могу, а вот как на реале будет?

Если порты (при каких-то условиях) доступны и из области 4000-FFFFh, то как удобнее всего перевести скомпилированный бинарник в нечто, загружаемое на реальном компьютере?

[Error404]

Вот лучше бы так опа и дать ссылку на сетевой софт для спека...

Экий вы быстрый. :)

Сначала сделаем стек - возьмем готовый uIP. Там надо обеспечить всего-то 2 подпрограммы: оправить буфер и принять буфер. На это уйдет год, не меньше (тут я ориентируюсь на свою скорость разработки :v2_dizzy_sleep2: ). Затем надо адаптировать библиотеку BSD-сокетов. Это еще год минимум. А уж тогда - заходите. :)

[Black_Cat]

Если я правильно понимаю, порты NemoIDE доступны только из ПЗУ в режиме dosне, NemoIDE в оригинале как раз в режиме DOS не работает, но на части современных компов это изменено, и можно работать везде. Как это реализовано в эмуляторах я не знаю.

---------- Post added at 14:57 ---------- Previous post was at 14:53 ----------


Если порты (при каких-то условиях) доступны и из области 4000-FFFFh, то как удобнее всего перевести скомпилированный бинарник в нечто, загружаемое на реальном компьютере? имхо SNA образ проще всего для современных компов на FPGA, для более старых - TRD, его понимают все без исключения

[b2m]

не, NemoIDE в оригинале как раз в режиме DOS не работает
Ясно, это я смотрел в твой guide по портам, и всё, что ниже shadow ports посчитал доступными только из режима dos. А там, оказывается, ещё отделено peripheral devices ports. Проглядел-с :)


имхо SNA образ проще всего для современных компов на FPGA, для более старых TRD
Придётся доделывать чтение/запись SNA в эмуляторе :)

[Black_Cat]

SNA щас можно запустить токо на ZXEvo, т.к. остальные новые компы не имеют NemoBus и NemoIDE, а более старые - KAY, ZXM-Phoenix, Scorpion - понимают пока токо TRD

[Error404]

Я посмотрел исходники QEMU, и сделал аналогично.



А ты как определяешь длину входящего Ethernet-фрейма? Т.е. сколько читать из TAP. Из-за того, что фрейм Ethernet II не имеет в пакете поля длины, а только поле тип, то не понятно сколько читать. В мануалах пишут "конец фрейма определяйте по концу несущей". Откуда взяться несущей в ТAP-адаптере? :)

В QEMU чтобы определить сколько вычитывать они, как я понял, лезут в тело IP-пакетов, в заголовки (т.е. делают на уровне Layer2 что положено делать уже на Layer3). Т.е. если у меня в IP-стеке глюк, и значения в заголовке не соответствует реальной длине пакета, то в эмуляторе все развалится нафиг. Или нет?
Как ты это порешал?

[b2m]

А ты как определяешь длину входящего Ethernet-фрейма?
А никак :) Сколько считал, столько и есть. Как я понял, TAP-драйвер выдаёт весь пакет за одно чтение. Ему ведь тоже приходит уже полный пакет. На уровне интерфейса минидрайвера пакеты не делятся. Это рутеры в сети могут поделить длинный TCP/IP пакет на более короткие, но это будут вполне полноценные TCP/IP пакеты.

Если вопрос о технике программирования в асинхронном режиме, то количество считанных байт выдаёт функция GetOverlappedResult.

И где ты там нашёл, что QEMU лезет в сам пакет? Вся работа с TAP-драйвером описана в tap_win32.c.

[Error404]

Ну вот, полгода спустя :) собрался с духом и сваял программку для работы с TAP. В примере она делает обслугу TAP-адаптера и генерирует ICMP-reply (по аналогии с тем, что у b2m, только на Паскале) - можно пинговать программку из-под Винды обычным ping-ом (IP-адрес и маска TAP-а естественно должна быть в этой же подсетке, что и у программки).

Во вложении исходники и TAP-драйвер.
Можно использовать как пример методики эмуляции Ethernet в своих эмуляторах, если кому то это интересно (чего по активности в этом треде не скажешь :v2_dizzy_bye: ).

[anasana]

Теперь что бы понять как это заюзать нужно будет перетащить всё с Паскаля в Студию на VС для экспериментов :).
Теперь что можно с этим сделать... на машинке, спрятанной за роутером, уже есть лан-подсеть и выдан адрес 192.168.0.100, я поставил ещё и драйвер TAP (создался новый интерфейс), запускаю TestEth.exe и выбираю его, при нажатии на кнопку "Start Process Packets" (влияние полей ввода "IP address" и "Mask" на что-либо не увидел), TAP интерфейсу "даётся кабель" и присваивается адрес 169.254.154.131, после чего я с этой машины могу этот адрес (169.254.154.131) пинговать, а при попытке пропинговать с соседнего компа (lan адрес 192.168.0.222), тот комп в котором есть ТАР (+ lan адрес 192.168.0.100) отвечает, что недоступен (Ответ от 192.168.0.100: Заданный узел недоступен.).
Какие варианты доступа вообще можно придумать, кроме как по IP, и как издалека, вообще же в будующем, интересует такой сетевой выход, который со стороны эмулятора должен откликаться как "узел" DECNet.
P.S. "Enumerator" под в Вин7 судя по всему не отработал (выпадающее меню Connections пустое, в ХРхе всё есть).

[Error404]

Теперь что бы понять как это заюзать нужно перетащить всё с Паскаля в Студию на VС :).


Не знаю как насчет именно в VC, но в синтаксисе С в исходниках это все есть в эмуляторе Q-Emu (я вприглядку туда писал). Я себе задачу ставил противоположную: для понятности максимально упростить (в исходниках Q-Emu из-за интеграции собственно с остальным Q-Emu в этом модуле много лишних сложностей)



"Enumerator" под в Вин7 судя по всему не отработал (выпадающее меню Connections пустое, в ХРхе всё есть).


Я для простоты просто из реестра читаю. В винде7 видимо это в другом месте. Надо значит делать более сложный енумератор.



Теперь что можно с этим сделать... на машинке уже есть лан-сеть 192.168.0.100, я поставил драйвер TAP, запускаю TestEth.exe при нажатии на кнопку "Start Process Packets" новому TAP интерфейсу "даётся кабель" и присваивается адрес 169.254.154.131, я с этой машины могу его пинговать, а при попытке пропинговать с соседнего компа (lan адрес 192.168.0.222), тот комп в котором есть ТАР (+ lan адрес 192.168.0.100) отвечает, что недоступен.


ТАР-адаптер видимо пытается получать адрес по DHCP, и не получив (оно и понятно - адаптер пока что обособлен от всего) назначает себе автоконфигурируемый IP 169.254.154.131. Соотвтетсвнно в testeth.exe в поле IP-адреса перед выполнением "Start Process Packets" надо назначить IP-адрес из этой же сети (типа 169.254.154.135) и маску такую же). Или для ТАР-адаптера установить фиксированный IP как 172.20.0.13 (к примеру) - т.е. одно из двух, но чтобы и testeth.exe и ТАР-адаптер логически были в общем сегменте IP-сети (физически они и так, понятно, в общем сегменте - типа как кросовером соединены). Тогда из Винды можно будет пинговать IP-адрес, назначенный в testeth.exe. Снаружи ни адрес testeth.exe ни адрес ТАР-адаптера пинговать нельзя, если в Винде не включен форвардинг пакетов (т.е. между реальным адаптером и TAP-адаптером). Также чтобы выпустить эмулятор "наружу" есть вариант с бриджем - когда ТAP и реальный адаптер объединяются в общее (единое) метаустройство с единственным IP (единым), но это уже совсем другая история.



Какие варианты доступа вообще можно придумать, кроме как по IP, вообще в будующем интересует вывод сетевой которая в эмуляторе должна откликаться как "узел" DecNET.

В testeth.exe любые протоколы можно нарисовать, в т.ч. и "узел" DecNET. Она получает сырые пакета уровня Layer2 - это в модуле EthThrd.pas. Если посмотришь, дальше в файле Unit1.pas написан самый начальный уровень стека TCP (столько, сколько по минимуму надо чтобы описать ICMP echo reply). Если вместо него написать инкапсуляцию содержимого пакетов по правилам стека DecNET, то это будет эмулятор "узла" DecNET.

Если же есть реальный эмулятор, то DecNET будет эмулировать сам VAX-код в эмуляторе (самому писать стек не надо будет) - надо только правильно (через эмуляцию Ethernet-чипа/контроллера) предоставить VAX-коду доступ к этим самым сырым пакетам уровня Layer2 (т.е. тогда интерес будет представлять только модуль EthThrd.pas и его интеграция в готовый эмулятор через эмуляцию Ethernet-чипа).

[Error404]

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

b2m, а ты ассемблерный примерчик на основе чего делал? Есть какое-то хавту "программируем rtl8019"? Этого же нет в фирменной спецификации на чип.
Просто я пытаюсь понять что в этом примере к чему, накладывая на фирменную спецификацию, и местами недопонимаю: в исходничке непонятно зачем некие биты в командах дергаются, а некоторые наоборот недодергиваются (если сравнивать с исходниками драйверов на rtl8019, которые удалось найти по инет-помойкам).

[b2m]

Error404, я же сначала эмуляцию rtl8019as сделал, а уж потом писал примерчик, чтобы мой rtl8019as заработал. Фактически, этот пример, может быть, нигде кроме моего эмулятора и не заработает. :) Цель примерчика была иная - проверить, правильно ли я сделал работу с TAP-драйвером.

Я нагуглил какую-то другую доку по NE2000-совместимому чипу (DP83901A), там подробно рассказывается, как работает сетевая карта.

Реальный пример можно взять из софта для ObsoNET на MSX. Я, кстати, пробовал запускать ихний софт в своём эмуляторе. Результат был, вобщем-то, не очень. Я всякие loopback-и не стал пока делать (не разобрался окончательно), а они, похоже, используют эту фичу, чтобы MAC-адрес адаптера получить (при инициализации). Пришлось сделать костыль, чтобы ихний софт всё-таки получил MAC-адрес, заданный для адаптера в конфиге. Потом ещё какой-то бит статуса пришлось подкорректировать. Зато после всех манипуляций ихний аналог telnet-а заработал у меня в эмуляторе! Другой софт, правда, не работает. То ли оттого, что у меня в эмуляторе только первая версия msx dos, то ли где-то глюк в эмуляции. Но главное, это то, что ихний TCP/IP стек и драйвер ObsoNET работает с моей версией rtl8019as.

[Error404]

Error404, я же сначала эмуляцию rtl8019as сделал, а уж потом писал примерчик, чтобы мой rtl8019as заработал. Фактически, этот пример, может быть, нигде кроме моего эмулятора и не заработает. :) Цель примерчика была иная - проверить, правильно ли я сделал работу с TAP-драйвером.

Я нагуглил какую-то другую доку по NE2000-совместимому чипу (DP83901A), там подробно рассказывается, как работает сетевая карта.

Реальный пример можно взять из софта для ObsoNET на MSX. Я, кстати, пробовал запускать ихний софт в своём эмуляторе. Результат был, вобщем-то, не очень. Я всякие loopback-и не стал пока делать (не разобрался окончательно), а они, похоже, используют эту фичу, чтобы MAC-адрес адаптера получить (при инициализации). Пришлось сделать костыль, чтобы ихний софт всё-таки получил MAC-адрес, заданный для адаптера в конфиге. Потом ещё какой-то бит статуса пришлось подкорректировать. Зато после всех манипуляций ихний аналог telnet-а заработал у меня в эмуляторе! Другой софт, правда, не работает. То ли оттого, что у меня в эмуляторе только первая версия msx dos, то ли где-то глюк в эмуляции. Но главное, это то, что ихний TCP/IP стек и драйвер ObsoNET работает с моей версией rtl8019as.

Понятно. А после корректировки эмуляции rtl8019as, твой тутошний пример работает?

Я пытаюсь найти готовый пример, под который подгоню эмуляцию чипа. Т.к. голая спецификация оставляет слишком обширный полет для фантазии.
Соответственно, интересует поправленный пример, а то я там такого наподгоняю. :)
У меня есть на С примеры, но на асм было бы удобнее (его трассировать удобнее).

Во вложении наиболее читабельно оформленный примерчик драйвера rtl8019 из тех что попадались мне, как раз для режима без ДМА и прерываний - для режима поллинга (который, кстати, они делают через опрос регистра ISR, а не по указателям буфера, - может и в ObsoNET так же?). Но опять же - это С. Его еще сначала надо странслировать, и шагать неудобно (в CP/M нет source-level отладчиков для С).

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

[b2m]

Понятно. А после корректировки эмуляции rtl8019as, твой тутошний пример работает?
А что ему сделается то, конечно работает :)


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


Его еще сначала надо странслировать, и шагать неудобно (в CP/M нет source-level отладчиков для С)
Вот, кстати, тоже интересная задачка. А нет ли кросс-компиляторов для i8080/Z80, которые бы отладочную информацию выдавали? В идеале, хотелось бы какой-нибудь source-level отладчик к эмулятору прикрутить. :)

[Error404]

Я нагуглил какую-то другую доку по NE2000-совместимому чипу (DP83901A), там подробно рассказывается, как работает сетевая карта.


Кое-что можно почерпнуть здесь:
"Networking and internetworking with microcontrollers" By Fred Eady

читаю на ночь, засыпаю почти мгновенно. :)

[Error404]

Кое-что можно почерпнуть здесь:
"Networking and internetworking with microcontrollers" By Fred Eady

читаю на ночь, засыпаю почти мгновенно. :)

Допилил таки и я свой эмулятор до эмуляции RTL8019AS.
Примерчик от b2m под CP/M пингуется. :)
Что дальше делать будем?
Что наиболее перспективно для портирования? Особенно по критерию простоты реализации и естественно наличия исходников.

[b2m]

Что наиболее перспективно для портирования? Особенно по критерию простоты реализации и естественно наличия исходников.

А все это obso* - оно в исходниках?
Насколько сложное, привязано ли к MSX? Как оно будет в плане портируемости на другие 8-битки под CP/M (при наличии там rtl8019)?
Можно ознакомится с исходниками INL (они есть на sourceforge). Исходники утилит - прямо на сайте konamiman-а.

Те, что написаны исключительно для MSXDOS2 надо будет адаптировать, т.к. они используют "новые" функции, которых нет в CP/M.

Зато некоторые исходники на С, ты это любишь :)

[Error404]

Можно ознакомится с исходниками INL (они есть на sourceforge). Исходники утилит - прямо на сайте konamiman-а.

Те, что написаны исключительно для MSXDOS2 надо будет адаптировать, т.к. они используют "новые" функции, которых нет в CP/M.

Зато некоторые исходники на С, ты это любишь :)

Посмотрел по диагонали.
Исходники на C заточены под SDCC, его я как раз и не люблю. :)
В принципе не беда, можно было бы адаптировать.
Странно, а на MSX что - нет нормального нативного С-компилятора, что разработка ведется на РС?

Исходники INL на АSM конечно убили. Слабо откоментированы, и 250кб исходника резидента (плюс сколько-то нерезидента) - это конечно перебор чтобы вот так вот снаскоку всё порешать (как я люблю). А что за компилятор ассемблера они используют? Явно не M80\L80. Тож PC-версию какую-нибудь?

Поэтому решил пока ковырять uIP - он очень хорошо описан. Хотя по логике строения программ он мне не нравится - вариант от MSX как-то симпатичнее (и более лег бы как на архитектуру Ориона, так и на ZX). Но в привязках к архитектуре MSX я, боюсь, зароюсь, поэтому пока будем по принципу "лучшее враг хорошего" - ковырять uIP (http://zx-pk.ru/threads/14262-a-ne-pora-li-nam-vzyatsya-za-realizatsiyu-ethernet.html).