Народ, а подскажите, существовал ли софт для работы с фидо (мэйлер/тоссер/трекер/ридер) под CP/M?
Вид для печати
Народ, а подскажите, существовал ли софт для работы с фидо (мэйлер/тоссер/трекер/ридер) под CP/M?
Вроде терминалки существовали. Насчет остального не знаю. Что жеткасается терминалок, то, к примеру, под ATM была одна: http://atmturbo.nedopc.com/download/...r/lnmaster.zipЦитата:
Сообщение от spleen
Правда, сделана она была под специально подключаемый к сабжу HAYES-совместимый момед Z-Contact 1200 (специально разработанный для АТМ), следы которого затерялись в пучинах истории. Но при желании можно покопаться в проге и переписать ее под более другие модемы...
А переработать её под работу через СОМ-порт Камилевской карты ZX-MC с любыми внешними модемами? Не привязыватся к какому-то конкретному млмеду?
Камилевсткая карточка постепенно становится де-факто стандартом как я вижу...
Думаю, что можно. Вот только кто делать-то будет? Спасение утопающих - дело рук самих утопающих. :)Цитата:
Сообщение от falanger
Вообще по идее ведь работа с последовательным портом в CP/M идет через драйвер...
UP-ну ка я древнющщщую тему. Давайте все же разберемся подробно - имеется ли FIDO-шное ПО под CP/M 80 (v2.2)? Пока серфинг в сети дал только утилиты UUENCODE/UUDECODE. Однако, почему-то не верится, что под столь популярную в 80-х гг. ОСь никто не пытался создать пакет софта под сетку, пик популярности которой также приходится на это десятилетие.
Максагор, ZED на сях писан, сырки доступны. ;)
Я не о возможности его создать сейчас. А по наличию по сути.Цитата:
Сообщение от creator
Например, CP/M-совместимая ОС использовалась в Роботроне-1715, а эта машина имел более чем серьезное примерение с соответствующим распространением. Я еще в начале "нулевых" "роботроны" на кассах московских вокзалов. и никто с роботронов в FidoNET не выходил?
creator, zed это не для слабонервных
я помню его дефолтный тоссер
пока номан его не переписал.
- - - Добавлено - - -
Максагор, видимо не нужно было
Максагор, на Профи вроде был Terminal.
На Профи была фидошная терминалка, в двух вариантах - ч/б и цветная, разумеется работали в расширенном экране
. Причем умеющие полноценно работать с почтой, в т.ч. упаковывать пакеты. Работали со стандартным модемом подключаемым через COM-порт.
Ну, если вывод текста осуществлялся через системные вызовы CP/M, то режим графики маловажен. Интересно только на сколько символов в строке - 64 или 80 она рассчитана.Цитата:
Сообщение от alvis
Это здорово. Особенно если работа непосредственно с "железом" модема выделена в отдельный драйвер, который можно сменить.Цитата:
Сообщение от alvis
В общем, если у кого есть - то объявляется поиск хотелось бы "пощупать" самолично на предмет переделки и использования на АТМ.
А почему FIDO? Весьма усложненная система (сети нод у нас нет, как и нет задачи ходить через одну свою ноду и чтобы ноды обменивались базами). Почему не BBS например, большинство из которых имеют не только файловое хранилище, но и личную почту и групповые рассылки/подписки (и работают по telnet)? Вместо модема, та же ESP8266 одной AT-командой подключается на любой IP, любой порт (одна TCPIP-сессия), этого вполне достаточно чтобы зателнетиться к BBS и сидеть там как мы сейчас на форуме тут сидим.
Этот вариант тоже годится.
- - - Добавлено - - -
Хотелось бы поиграться с имеющимся на АТМке COM-портом. Он как-то с ESP8266 может сопрягаться?Цитата:
Сообщение от Error404
ESP8266 по умолчанию управляется AT-командами. Но если надо, я могу написать свою прошивку, опыт есть.Цитата:
Хотелось бы поиграться с имеющимся на АТМке COM-портом. Он как-то с ESP8266 может сопрягаться?
Есть даже моя готовая прошивка, позволяющая весь TCP стек держать на спеке, а ESP будет просто как сетевуха.
Правда, есть ли TCP на спеке - не знаю. Но на ПК тестил - работает на ура. КОМ-портовая сетевуха рулит:)
Это текстовый редактор?Цитата:
Сообщение от jerri
Шынни, да написан на С тормозной как паровой каток
http://triumph.hop.ru/Rick_Murray.html
мне показался zed удобным. на реале не гонял.
C TCP/IP на Z80 вообще проблема. Более-менее серьезная реализация с открытым кодом мне известна одна - Inestor на MSX (сложноватая: написана на АСМ, имеет привязки к мапперам МСХ), все остальное либо частичное, либо без исходником и для давно канувших платформ. На Спеке пошли по пути прикручивания Wiznet-подобных штук (когда TCPIP обслуживает контроллер/"модем") - такое можно реализовать в ESP? Типа Wiznet-а подключенного по ком-порту с неким API по работе с готовыми сокетами?Цитата:
Сообщение от SfS
Важно тем, что в расширенном экране удобнее работать. 64/80 в СР/М на Профи можно переключать "на лету". Весь софт это понимает. Все делается через видеодрайвер.Цитата:
Сообщение от Максагор
Именно через драйвер, т.к. на Профи существует два варианта СОМ-порта, встроенный на платах версий 4 и 5 и в виде внешней платы подключаемой через системный разъем. Эти варианты несовместимы по портам.Цитата:
Сообщение от Максагор
Где-то у меня есть все это на дискетах. Постараюсь найти, если нужно.
Нашел у себя в базе два архива с программами для Profi в среде CP/M-80 для работы с модемом.
http://caro.su/files/terminal.zip и http://caro.su/files/terminal.rar
В первом архиве образ диска, в другом куча файлов.
И еще один архив с Версией терминала для Profi с цветным экраном:
http://caro.su/files/tmcolor.zip
Цитата:
Сообщение от caro
Спасибо!
Кстати, там в дете про сборку АТМ3 идет обсуждение твоих прошивок клавиатуры:
http://zx-pk.ru/threads/27525-novaya...-rev-2017.html
Если будет какая-то информация, подключайтесь.
Собственно, на ESP8266 уже есть весь стек TCP. Поддерживает до 4х соединений одновременно. (Может и больше можно - но я не пробовал и не разбирался).Цитата:
Сообщение от Error404
Про TCP/IP на спеке я написал, что это возможно как вариант. Собственно, реализаций TCP именно на z80 я много видел в инете, но насколько они работают - ХБЗ.
Что касается ESP, то я использую SDK и там творить на C/C++ можно что хошь. Можно и API какое-нибудь.
Насколько я немного пару лет назад почитал про ESP, там стек весьма специфически сделан: сокеты там работают в сторону WIFI-подключений, и уже эти подключения могут опционально помигать светодиодом или что-то выплюнуть в RS-232. Нам же надо развернуть это API наоборот: чтобы движок TCPIP слушал RS-232, а по WIFI общался с внешним миром в зависимости от того что ему хост дует в RS-232. Т.е. в оригинале WIFI-подключения это initiatior, а RS-232/GPIO - target (для управления утюгом по WIFI: его включения, выключения и проигрывания на утюге мелодий). Под это было заточено всё: от LUA до оригинальных прошивок, такое ощущение что на разработчиках одинаковые шоры.Цитата:
Сообщение от SfS
А мы же - наоборот, хотим дать свободу утюгу, чтобы он сам был initiator и по своей инициативе через RS-232 решал к чему он желает подключиться.
Возможно что-то изменилось за прошедшие пару лет?
Про Zifi знаю, но там не то что хотелось бы, а нечто промежуточное между описанными выше вариантами.
Реально работающих - две: от UZIX и от Inestor (т.е. оба раза на MSX). Все остальное - из z88sdk, старые оригинальные CP/M и C64 останки на ассемблере, клоны uIP (моя реализация и варианты с Contiki) - это все профанация ибо не несут по человечески сделанного, т.е. хоть с чем-то совместимого, API (всякие "протосокеты" на макросах - это ананизм а не API :) ), т.е. реально ничего на них не развернешь кроме примитива типа телнета и веб-сервера, для которых строго говоря и TCPIP не то нужен, люди прекрасно делают на голом L2 и процедуре в сотню строк.Цитата:
Сообщение от SfS
Сокет не может быть "в одну сторону". Сокет - это двунаправленный обмен данными.Цитата:
Сообщение от Error404
Пример, я на ESP8266 делал WEB-сайт. Постоянный обмен данными - от ПК или смартфона запросы, а ESP8266 формирует ответы для рисования веб-странички.
Да о чем я? Для PENTEVO уже создан и прекрасно работает ZiFi http://ts.retropc.ru/ . Это программка, которая через esp лезет в инет и качает музон или игры и пишет их на диск. Ну ещё плеер и вьюер там есть.
Но это чисто для Pentevo.
Что такое ESP8266? Это микроконтроллер с вай-фай транспортом. На нем может крутиться RTOS. Производитель поставляет стандартные прошивки, которые управляются с помощью AT-команд. Недостаток AT-команд в том, что ими сложно рулить. Но в Pentevo сделано.
И ещё есть SDK, в исходниках. Там на C/С++ - можно как угодно делать. Хочешь точка доступа, хочешь станция. Хочешь к тебе коннектятся, хочешь ты. Там и роутер сваять можно и веб-сайт и управление реле если надо.
Я так понимаю, что в принципе, даже стандартная прошивка ESP может обинтернетить любой спек с RS232. Только софт где брать?
- - - Добавлено - - -
Вот моя поделка для ESP в исходниках: https://github.com/salextpuru/esp_slip_control
Спеку она не поможет, но зато видно, что ограничений для ESP нету.
- - - Добавлено - - -
В принципе, если кто-нибудь желает - можно сделать ESP-интернет для любого спека. Один я не потяну - со временем не очень. А вот на двоих работа вполне может срастись.
Я возьму на себя реализацию удобного API со стороны ESP. А кто-нибудь, желающий - сделает ПО для спека.
Ограничения, которые я вижу:
1. ESP - только в режиме STATION (точка доступа не нужна).
2. Одновременная поддержка не более 4х соединений.
API- по согласованию с соавтором.
Пока я вижу функции соединиться, разъединиться, отправить данные, принять данные. Ну там видно будет.
Если кому интересно - пишите.
ну там с тоссером от SoK он более менееЦитата:
Сообщение от Шынни
а вот оригинальный никакой вообще
а после появления Lara Croft Zed не более чем курьез для оригинала
Давай вот без этих таких вот фраз через губу? Мы с тобой не первый раз говорим за TCP, и ты прекрасно знаешь, что я в теме куда там направлен обмен. :)Цитата:
Сообщение от SfS
Не канает, по крайней мере в известной мне реализации. Zifi не дает доступа к самому транспорту или сокетам, оно использует доступ у некому API в ЕСП-шке, прослойке, которая сама по себе и не дает произвольного доступа к любому ресурсу, а по некоему списку. Клиентское же ПО не оперирует сетевыми категориями, а скорее работает как BBS-клиент (но при этом ZIFI нельзя использовать для доступа к многочисленным BBS в Инете, о чем я авторов просил - но увы)Цитата:
Сообщение от SfS
Да, в ESP уже есть AT-команда для соедининия с любым портом любого сервера (задается IP). Вопрос в том что за сервис на на том сервере/порту. Если это например BBS по телнет, то не надо вообще ничего - на Спеке достаточно обычного терминала, умеющего в RS-232. По крайней мере на CP/M это вообще не проблема, есть хорошие вещи типа QTERM. Но это не совсем то что нужно, т.к. только один "сокет", чтобы подключить второй сервер, надо закрыть предыдущее соединение.Цитата:
Сообщение от SfS
КМК, c точки зрения интегрирования с уже имеющимися вариантами стека на Z80, могут быть два варианта API (ориентируясь на более-менее уже готовые решения на стороне Z80):Цитата:
Сообщение от SfS
1. API уровня L2 (MAC/PHY) - ESP реализует только функции инициализации и приема-передачи пакетов, весь стек на стороне Z80 - это легко интегрируется в клиентское ПО типа uIP или Inestor (но придется попахать: что та что другая далеко не сахар для портирующего).
2. API уровня L4 (ESP реализует весь TCP/IP, API - BSD-сокеты или подобное) - такое используется на системах с WizNet, готовая реализация - Спектранет с W5100(для ESP потребуется некоторая адаптация).
С первым вариантом я наелся и никому не советую (хотя работающий uIP вроде и получился - на базе NIC RTL8019), второй не изучал вообще. Но может еще кто-то подключится?
Извини, вовсе не через губу:) Не помню хоть убей с кем именно и о чём я говорил и тем более не помню кто что знает, а что нет. Тем более если разговор был относительно давно. Не хотел обидеть.Цитата:
Сообщение от Error404
ESP на уровне AT команд держит до 4х соединений. Так что уже можно "мультисети" строить:) Там проблема больше в том, что ИЗ ESPв спек данные могут прилететь в любой момент. И часть теряется.Цитата:
Сообщение от Error404
Я за второй вариант.Цитата:
Сообщение от Error404
Грубо говоря, пишутся функции-обёртки для Z80. Эти функции-обёртки с помощью протокола (надо его подумать) отправляют запрос на ESP, которая их обрабатывает и высылает ответ.
То есть примерно так:
1. Пользователь вызывает функцию
connect( "192.168.2.200:2100", "TCP")
2. Функция обёртывает это в протокол обмена и шлёт по КОМ-порту запрос к ESP.
3. ESP подтверждает, что запрос принят или возвращает ошибку (например, не хватает сокетов или нет связи с точкой доступа)
4. Если запрос принят, то функция ждёт от ESP результата соединения и возвращает его пользователю. Например - номер сокета или -1 если ошибка.
Точно так же дисконнект.
точно так же - запись данных.
А вот с чтением получается хуже. Там надо на прерывания вешать чтение и буфера делать в ESP и тогда можно вычитывать в фоне.
Вот пока такие сумбурные мысли в голове моей. Вложение 62775
Ненуачо, вполне годно.Цитата:
Сообщение от SfS
Только надо добавить ioctl c переключателем блокирующий/неблокирующий режим (собственно, и все настроечные функции wifi_* туда же в некий case{IOCTL_FUNC}).
Тогда станет так:
int16_t recv(int8_t sockfd, void *buf, int16_t len, int8_t flags); /*Читает данные из сокета.*/
Возвращает: количество считанных байт (>0) или код ошибки (<0, в т.ч. код для "соединение закрыто")
либо возвращает 0, если данных нет (неблокирующий режим) либо управление не возвращается пока не появятся данные (блокирующий режим)
Слушающие сокеты тоже хотелось бы, нам же серверные вещи тоже понадобятся, тот же telnet к консоли z80.
И не вижу ничего плохого в поллинге. На единичном опросе статуса устройства из регистра он даже быстрее работает, чем обработка единичного прерывания от устройства по смене того же статуса (меньше команд на прочитать флаг наличия данных). Один хрен например в Юзиксе по таймеру уже много чего опрашивается, добавим туда еще и вызов esp_poll(). Я вот думаю в своем клоне CP/M отказаться от RS-232 по INT, оставить только по poll (сейчас там оба, для INT нужен кольцевой буфер, обработку переполнения и т.п. при этом скорость получается меньше при прочих равных).
- - - Добавлено - - -
А ограничение в 4 сокета оно реально hardcoded или когда-нить в будущем можно будет его преодолеть?
- - - Добавлено - - -
Кстати, в исходном UZIX для TCPIP применялся RS-232-модем по SLIP или PPP. Просто вспомнилось. Жаль, что потеряны все исходники, относившиеся к TCPIP UZIX.
Ребят, я не фидошник, но кое-какие фразы из темы мне знакомы. Помещаю ccылку на торрент диска cdrom-1994-11-walnutcreek-cpm , в котором нашел пару BBS и почтовых приблуд. Может быть кому и полезно будет...
https://archive.org/download/cdrom-1...rchive.torrent
Ну это можно. Но я сначала хочу на ESP сделать прогу. А потом уж за спековскую часть можно приняться.Цитата:
Только надо добавить ioctl c переключателем блокирующий/неблокирующий режим (собственно, и все настроечные функции wifi_* туда же в некий case{IOCTL_FUNC}).
Я придерживаюсь идеологии линуха-униха.Цитата:
Возвращает: количество считанных байт (>0) или код ошибки (<0, в т.ч. код для "соединение закрыто")
либо возвращает 0, если данных нет (неблокирующий режим) либо управление не возвращается пока не появятся данные (блокирующий режим)
А там в случае неблокируемого сокета, если данных нет возвращается ошибка EAGAIN.
Да и разночтений нет. 0 вернулся - сокет закрыт. Хоть блокируемый хоть нет.
Код ошибки же в любом случае надо анализировать.
Я там про них написал. Но это вторая часть. Там хоть с виду всё и несложно, но потрахаться придётся здорово.Цитата:
слушающие сокеты тоже хотелось бы, нам же серверные вещи тоже понадобятся, тот же telnet к консоли z80.
Да и слона надо по кусочкам есть)
Главное - протокол сделать. Остальное проще.
Ну, в принципе как угодно, обработать можно любой код. В любом случае над библиотекой будет какая-то обертка, а там уж в ней каждый реализует как хочет.Цитата:
Сообщение от SfS
Например в случае многозадачной ОС в ядре сокеты всегда будут открываться как неблокируемые, но если приложением через API ОС этот сокет открыт как блокируемый и при этом не содержит данных, то надо переводить процесс в спячку - решедулить его таймслайсы в пользу прочих активных процессов. А в простом однозадачном клиенте (возможно вообще без ОС как принято на Спеке) удобно использовать блокируемый режим напрямую из API библиотеки ESP.
А код молотить - да, это придется немало. :)
Ну коечто уже есть. Типа закрыть-открыть сокет, SLIP. но это мизерЦитата:
Сообщение от Error404
Разобрался с некими глюками UART. сейчас ваяю отладку через SLIP. без неё никуда
Вот такое API получается пока что. Вложение 62884
Интересно, сильно ли будет тормозякать.
А почему должно тормозить? На стороне Z80 всяко не медленнее скорости порта будет работать, 32-битных типов нет (они основной тормоз если использовать С на Z80). А вот на стороне ESP - ХЗ, не имею опыта с ней.
Там такая неувязка получается.Цитата:
Сообщение от Error404
При скорости 115200, порт выдаёт примерно 10Кбайт в секунду.
То есть за прерывание получается 10000/50 = 200 байт.
Насколько я знаю, буфера у RS232 в спеке - то ли по 16 байт то ли вообще их нет.
То есть не получится прерывание копить буфер, а потом быстро считать. Надо постоянно ждать когда придёт байт.
За время ожидания байта проходит 3500 000 / 10 000 = 350 тактов. Не так уж и много в общем-то. Но всё равно - холостое ожидание.
Если бы буфера были по 256 байт - можно было бы куда эффективнее обмениваться с устройствами.
Просто бы по IM2 повешал опрос буферов - есть данные, считал по быстрому - и дальше что-то делать. Но увы. И прерываний от COM-порта тоже нету вроде.
Но что есть то есть. Пока делаю протокол со стороны ESP8266, как задышит - попробую и на ZX сваять ответную часть.