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

Пара ламерских вопросов.

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

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

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

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

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

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

имхо SNA образ проще всего для современных компов на FPGA, для более старых - TRD, его понимают все без исключения

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

Придётся доделывать чтение/запись SNA в эмуляторе :)

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

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

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

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

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

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

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

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

Теперь что бы понять как это заюзать нужно будет перетащить всё с Паскаля в Студию на 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 пустое, в ХРхе всё есть).

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

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

ТАР-адаптер видимо пытается получать адрес по 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 (единым), но это уже совсем другая история.

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

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

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

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

А что ему сделается то, конечно работает :)

Во-во. Может не стоит ориентироваться на мой пример?

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

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

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

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

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

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

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

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

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

Поэтому решил пока ковырять uIP - он очень хорошо описан. Хотя по логике строения программ он мне не нравится - вариант от MSX как-то симпатичнее (и более лег бы как на архитектуру Ориона, так и на ZX). Но в привязках к архитектуре MSX я, боюсь, зароюсь, поэтому пока будем по принципу "лучшее враг хорошего" - ковырять uIP.