z80-telnet

[asve79]

asve79, отличный проект , буквально сегодня лазил по BBS , через telnet на PC.
нет ли мыслей сделать клиента под разрешение 512x256 или половинный шрифт ?

Спасибо за поддержку! )

512x256 это ж Под профик?
Под ts-conf я уже нашел окошки которыми можно пользоватся и что является частью API wc.
Текущий размер экрана явно маловат, это очевидно. Текущую реализацию, как я уже отметил, я делал с использованием окошек от @Barmaley_m, и под стандарное разрешение. Про разрешение профи тоже думал (пока не заказал EVO ), но мысли остались не материализованными т к по факту нужно написать некую простую оконную систему на что уйдет время, а столько всего еще хочется ). С окошками оно и выглядеть прилично будет. Если у кого есть в разработках свой интерфейс без проблем адаптирую под него. Можно конечно все переделать на "без окошек", а-ля "под консоль", но в настоящее время на это уйдет больше времени.

Про работу с ББСками - тогда надо еще проработать реализацию xmodem или zmodem-а, чтобы можно было что-то скачивать/отправлять.

Очень прошу автора разделить ESP-программы на 2 части, взаимодействующие через некое API (функции, керналь, что угодно): в одной части логика, во второй - системно и аппаратно-зависимая часть (все вот эти выводы на экран и ввод с клавиатуры, IO в COM-порт, чтение-запись файла, etc). Разместить эти части по возможности в пространстве 4000h...0BFFFh. Это даст возможность минимальной ценой и с бинарной совместимостью сделать порт на большинство 8-битных платформ (написав свою аппаратно-зависимую часть и используя логическую часть "как есть").

Посмотрю что с этим можно сделать. Текущее размещение больше продиктовано работой оконной системы. Я опирался на примеры работы с окошками и не особо вдавался о особенности его реализации.
По части взаимодействия через APi - сейчас я этот момент решал с помощью макросов. Почти все узкоспециализированные ф-ции вызываются макросами которые идут в связке с модулями. Потому сейчас не такая уже и проблема переключится на использование других окошек или модуля ESP.

Пока только догадываюсь в чем ценность именно такого подхода. В моем понимании что в макросах вызывать печать символа, что тем же макросом вызвать какое-то APi по адресу. Это выглядит одинаково по трудоемкости, но всецело открыт для новых знаний, постижения и получения нового опыта. )

[Advertiser]

[Error404]

Можно конечно все переделать на "без окошек", а-ля "под консоль", но в настоящее время на это уйдет больше времени.
Про работу с ББСками - тогда надо еще проработать реализацию xmodem или zmodem-а, чтобы можно было что-то скачивать/отправлять.

Я за консоль.
И BBS-ки - это крутецкая круть! И очень надо.
Вот тут исходники реализации xModem: xGet от Камиля (caro) и xPut моя; окружение там для CP/M, но основные процедуры (rx_file, tx_file) - абстрактные (ну, почти) и можно прикрутить куда угодно: https://github.com/serge-404/AltairD.../source/xmodem

ZModem (который ЕМНИП в реализации лишь небольшая надстройка над XMODEM) мне понравился из QTerm, который сам по себе очень классный терминал с поддержкой VT100 (его исходники тут: http://www.classiccmp.org/cpmarchive...em/qt43src.lbr , CP/M-овские архивы LBR на PC распаковываются при помощи утилит: Linux DOS/WIN32 или в CP/M утилитами типа LU.COM)

По части взаимодействия через APi - сейчас я этот момент решал с помощью макросов. Почти все узкоспециализированные ф-ции вызываются макросами которые идут в связке с модулями. Потому сейчас не такая уже и проблема переключится на использование других окошек или модуля ESP.
Пока только догадываюсь в чем ценность именно такого подхода. В моем понимании что в макросах вызывать печать символа, что тем же макросом вызвать какое-то APi по адресу. Это выглядит одинаково по трудоемкости, но всецело открыт для новых знаний, постижения и получения нового опыта. )

Ну, меня макросы конечно не остановят, но многим другим было бы наверное проще имея один единожды написанный платформенно-зависимый BIOS для всего множества ESP-программ, запускать у себя прямо любые бинарники семейства (программы с логикой only), без перекомпиляции (а логический код пускай делает вызовы в тот BIOS по фиксировнным точкам входа). Т.е. как приложение ОС (а есть там дальше ОС или нет в реализации того BIOS - уже личное дело каждого). Почему я говорил про использование области 4000...BFFF под код - это в связи с тем, что на большинстве платформ в начале или в конце адресного пространства размещены ПЗУ или окна диспетчеров или ОЗУ области связи, и использование ОЗУ там может быть затруднено.

[JV-Soft]

512x256 это ж Под профик?

Да ,но и пентагон может такое использовать аппаратно. Если пока не очень хочется заморачиваться ,то можно выводить шрифтом 4x8 ,будет 64 символа в строке , могу дать исходники и шрифт если надо.

И BBS-ки - это крутецкая круть! И очень надо.

Да ,да ,да !

[asve79]

И так, добавил на главную страничку todo и wish-листы. todo - это то что прям надо и над чем работаю, wish - то, что в очереди.
Это как бы не "прибито гвоздями", так что пожелания/замечания приветствуются.

Да ,но и пентагон может такое использовать аппаратно. Если пока не очень хочется заморачиваться ,то можно выводить шрифтом 4x8 ,будет 64 символа в строке , могу дать исходники и шрифт если надо.

Конечно не откажусь. Там автосролл есть? Добавлю с SDK с твоего разрешения.
Все-таки вырисовывается потребность доработки решения в сторону "консольного режима". )

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

Ну, меня макросы конечно не остановят, но многим другим было бы наверное проще имея один единожды написанный платформенно-зависимый BIOS для всего множества ESP-программ, запускать у себя прямо любые бинарники семейства (программы с логикой only), без перекомпиляции (а логический код пускай делает вызовы в тот BIOS по фиксировнным точкам входа). Т.е. как приложение ОС (а есть там дальше ОС или нет в реализации того BIOS - уже личное дело каждого).

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

Почему я говорил про использование области 4000...BFFF под код - это в связи с тем, что на большинстве платформ в начале или в конце адресного пространства размещены ПЗУ или окна диспетчеров или ОЗУ области связи, и использование ОЗУ там может быть затруднено.

в #4000 это ж экран...
В целом, как я говорил текущее размещение продиктовано больше оконной системой. А сделал через оконку потому что:
1. нужно было куда-то выводить, и желательно не в 32x22
2. красиво
3. быстрое и четкое решение, автору интерфейса огромный респект!
4. в консоле телнетовской мне не нравилось что командный режим включается по комбинации клавиш и выводится в рабочее поле. Проще би наглядней вводить команды в отдельное окно. Сейчас вот пришло осознание что можно и через консоль сделать удобно.

Но переразмещение в адресном пространстве пока не считаю приоритетной задачей. Вижу приоритет в том, чтобы сделать решения под разные порты. Глядишь, кто-нибудь и с библиотекой вывода в 512x256 подтянется)

[Максагор]

Вот тут исходники реализации xModem

Есть ли где исходники реализации Y и Z-модемов?

[solegstar]

512x256 это ж Под профик?

нет, Профик это 512х240. Пентагон возможно сделать под 512х192. Описание построения экрана Профи есть во вложении.
profi_extended_screen.zip

[Максагор]

Есть пожелание, сделать драйвера низкого уровня по приему передаче через COM(или иные)-порты в виде подгружаемых внешних файлов (как в прежние времена в некоторых программах и играх делали внешние драйвера по доступу к памяти свыше 128Кб). Ну и стандартизировать, соответственно точки входа в них. А то, например, если брать ZX-Evo и ATM-turbo 2+, то при одинаковых экранах там совершенно разный тип доступа к COM-порту. На каком-нибудь Профике, вангую, еще один тип и т.д.

[Error404]

Вот поэтому, ввиду зоопарка режимов, в идеале экраном и надо заниматься не самой программе, а некоему обособленному BIOS-у. Примерно как на линухе, где культурная терминальная программа перед началом работы делает запрос и получает текущие параметры консоли, и вывод управляющих последовательностей тоже делает абстрактно - через конвертирующую к реальности прослойку (либу termcap). А выводом в RS-232 также абстрагированно там занимается termios. Они конечно сильно навернуты, нам же надо только сугубо то что нужно тут, упомянул их всуе сугубо для примера. Автор напишет биос для себя, а весь остальной зоопарк терминалов сами потребители допишут.

[Максагор]

Вот поэтому, ввиду зоопарка режимов, в идеале экраном и надо заниматься не самой программе, а некоему обособленному BIOS-у. Примерно как на линухе, где культурная терминальная программа перед началом работы делает запрос и получает текущие параметры консоли, и вывод управляющих последовательностей тоже делает абстрактно - через конвертирующую к реальности прослойку (либу termcap). А выводом в RS-232 также абстрагированно там занимается termios. Они конечно сильно навернуты, нам же надо только сугубо то что нужно тут, упомянул их всуе сугубо для примера. Автор напишет биос для себя, а весь остальной зоопарк терминалов сами потребители допишут.

Уважаемый asve79, кстати, делает сейчас примерно то же, что и я - я сейчас тоже пишу терминалку, только под ОС TASiS, чтобы запускать ее на АТМ2+ и Пентеве. Уже готов ANSI-драйвер (на его основе сделал просмотрщик ANSI-графики - на форуме ссылку уже кидал: http://atmturbo.nedopc.com/download/...w/ansiview.ipc) и частично оконный интерфейс - работа в самом разгаре. Пока еще не брался за коммуникационные процедуры. Только накачал пока материалы по X- Y- Z- "модемам", по АТ-командам для модем. А за телнет (а у меня планируется возможность коннектиться как дозвоном по диалапу - такие BBS еще есть) еще пока вообще не брался. Если есть у кого подробная инфа (желательно на русском), буду благодарен.

[Error404]

Уважаемый asve79, кстати, делает сейчас примерно то же, что и я - я сейчас тоже пишу терминалку, только под ОС TASiS, чтобы запускать ее на АТМ2+ и Пентеве. Уже готов ANSI-драйвер (на его основе сделал просмотрщик ANSI-графики - на форуме ссылку уже кидал: http://atmturbo.nedopc.com/download/...w/ansiview.ipc) и частично оконный интерфейс - работа в самом разгаре. Пока еще не брался за коммуникационные процедуры. Только накачал пока материалы по X- Y- Z- "модемам", по АТ-командам для модем. А за телнет (а у меня планируется возможность коннектиться как дозвоном по диалапу - такие BBS еще есть) еще пока вообще не брался. Если есть у кого подробная инфа (желательно на русском), буду благодарен.

Задача стоит принципиально написать что-то своё с окошками? Если нет, то я бы смотрел в сторону портирования общепризнанных терминальных утилит с соседних платформ. Например, можно взять Кермит или Qterm с CP/M. Ссылку на исходники последнего я приводил чуть ранее по треду, пробовал его на Орионе. Этот терминал большинством пользователей CP/M признавался лучшим, там есть эмуляция VT-100 и VT-52, AT-команды со скриптованием (целый квази-язык для дозвона по условиям), два окна (а больше - зачем), совместимость с Кермит, поддержка X-modem и Z-modem. Поправить вывод на экран, RS-232 и файловое IO, и вперед за орденами.

X-модем в принципе не сложен, я как-то даже сам писал (получение файла скопипастил у caro, отправление дописал сам - там похоже и единственная заковыка была с CRC, исходник тоже есть выше по треду). На основе этого слепил на скорую руку BIOS для Ориона где комп стартуя загружался по RS-232 (типа как LAN-boot). Бессмысленно конечно (как любая завязка на пристяжной PC), но забавно.