Снова о подключении ZX-PC

[polikarpov76]

А esp8266 сам не умеет как-то обратиться к сетевой шаре (NFS или SMB, пусть даже на роутере, многие роутеры это умеют) с темой 'слыш дай мне список файлов, или 'хочу скачать файл такой-то'? То-есть как бы обязательно иметь самописный сервер?

[izzx]

Если контроль передачи файла с сервера на клиента осуществляет клиент на спеке (серией запросов вида "дай файл имя такое-то, смещение такое-то, длина блока такая-то"(например, равная 1 сектору флопа), то можно получать блок данных (сектор, один или несколько) в буфер ОЗУ, затем передача на AY уходит в ожидание и Спек пишет данные на флоп. и т д. со следующими блоками.

Так и есть.

Надо только проверить, какова будет реальная скорость записи на настоящий флопик

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

Что у нас может аппаратно реализовывать передачу по параллельному интерфейсу аналогично всяким ИРПР, существует ещё такое ?

Вот этого не знаю. Были наработки в теме про WiFi. Или какой-нибудь BB55. Хотя у AY 8 бит шина IO, должно хватить и на передачу, и на контроль.

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

А esp8266 сам не умеет как-то обратиться к сетевой шаре (NFS или SMB, пусть даже на роутере, многие роутеры это умеют) с темой 'слыш дай мне список файлов, или 'хочу скачать файл такой-то'? То-есть как бы обязательно иметь самописный сервер?

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

Upd. Забыл сказать главную фишку: тут нет аппаратного контроля передачи. Просто сервер шлёт пакеты всегда определённого размера, а клиент пока не примет нужный объём, не остановится.

[Kulich]

А вообще лучше брать нормальный FIFO UART да с контролем потока. А не дергать ноги ай думая о турбо или нет оно.

[izzx]

Потестил скоростя в режиме 3.5 герц:
С карты CF на дискету - 2:10
С сервера на карту CF - 3:30 (без контрольных сумм)
С сервера на дискету - 5:38 (без контрольных сумм)

Наверное, можно чуть ускорить, если писать по дорожкам, а не по 1024 байт. То есть сделать буфер 16*256. И, возможно, отформатировать дискету с другим интервалом.

А вообще лучше брать нормальный FIFO UART да с контролем потока.

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

[valerium]

А вообще лучше брать нормальный FIFO UART да с контролем потока. А не дергать ноги ай думая о турбо или нет оно.

Ну сейчас есть прототип, какой есть, автор молодец, что в целом концепцию охватил. Сейчас можно по частям все обдумать и проработать.
А вообще любую передачу, конечно, надо взваливать на контроллер интерфейса, чтоб работа с обменом со стороны cpu выглядела как запись данных в один порт, запись команды в другой порт, а затем циклическое считывание статусного регистра на предмет переваривания/готовности ответных данных от контроллера.
Последовательный интерфейсы - это тепло и лампово, как магнитофон с полосками на бордюре, но мне кажется, что параллельная передача здесь была бы куда более к месту.
И если уж говорить про ESP, то у него должно быть достаточно своих gpio-ног для реализации слейв-устройства с параллельным обменом по 8-разрядной шине данных, адресации регистров импровизированного контроллера и линий управления (rd и wr). То есть аппаратно спековскую часть можно бы сократить до дешифратора адреса(ов) и самого esp, а уж потом он будет цепляться к серверу и по сути реализовывать проксирование, отдавая спеку данные небольшими блоками.
Про то, что хватит быстродействия, я особо не сомневаюсь - хотя бы потому что подобный интерфейс реализовывали неплохо даже на avr-ках (эмулятор вг93+флопа by Helbr тому пример).
У меня есть несколько идей, но пока нет опыта в работе с esp, я пока только чужие проекты собирал и вливал в него. Поизучаю, может чего и придумается.

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

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

Там скорость его [FIFO UART] передачи определяется его собственным кварцем и делителем, записанным в один и его специальных регистров. То есть отдал ему данные в буфер - и он их на соответствующей скорости со всеми дополнительными битами (старт/стоп/четность) передал. Если в ответ чего-то ждём, поллим статусный регистр, как в нем увидели готовность принятых данных - забрали их чтением из соотв.регистров. За счёт FIFO можем не очень мгновенно и не очень равномерно принятые данные забирать. Так что это значительно удобнее.

[izzx]

Теперь я понял весь план.
Делаем универсальную платку с портом кондратьева для системного разъёма и ZX BUS.
Подключаем к ней ESP на скорости 921600.
Включаем турбо на ZX, если есть.
Гоняем образы TRD с космической скоростью через мой сервер или бродим по инету через браузер Nihirash.

Возможно, сервер не понадобится, потому что Nihirash что-то говорил про облако (ЕМНИП).
И возможно, ребята такое устройство уже допилили и откроют продажи к рождеству. Говорю наугад, инфы у меня нет.

Только если оставлять UDP сервер и ESP режиме моста, то как её переводить в заводской режим для браузера? Хоть две делай.

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

И если уж говорить про ESP, то у него должно быть достаточно своих gpio-ног для реализации слейв-устройства с параллельным обменом по 8-разрядной шине данных, адресации регистров импровизированного контроллера и линий управления (rd и wr). То есть аппаратно спековскую часть можно бы сократить до дешифратора адреса(ов) и самого esp, а уж потом он будет цепляться к серверу и по сути реализовывать проксирование, отдавая спеку данные небольшими блоками

Да, только тут наверное придётся программировать ESP.

[Kulich]

Вооо, в правильном направлении мысль пошла. Сделать ком порт совместимым с каким-то хоть стандартом , реализованном например в Эво и ZXMCARD. Всю грязную работу свалить на какой-нить 16550. Разве что мегабит это перебор и смысла не имеет. Спектрум и 115200 с трудом вытягивает насколько я вижу. Дело за выбором про окола обмена. И главное в написании софта который будет эту самую сеть реализовывать.

[valerium]

. Разве что мегабит это перебор и смысла не имеет. Спектрум и 115200 с трудом вытягивает насколько я вижу.

Тут мы опять путаем теплое с мягким. 115200 не удается вытянуть в _программном_ режиме, отдавая весь проц на построение потока данных (и считая такты). А это куча пауз и в общем-то выкинутого впустую времени.
Если обмен сделать на чем-то автономном относительно cpu, то и скорость можно получить иную, а может и вообще иначе реализовать обмен. Никто ж не ругается, что обмен с ВГ93 по 8-битной шине медленный - я вот за такой же вариант обмена, хоть и программного, но весьма продуктивного.

16550 можно пересадить на действующую схему, поиграть с ней в плане "а надо ли вообще", а потом углубляться в реализацию параллельного обмена (на avr я себе это представляю, неужто на esp с этим несправиться?)

[reddie]

Никто ж не ругается, что обмен с ВГ93 по 8-битной шине медленный

При этом скорость потока чтения/записи дискеты 250 Кбит, или 30 Кбайт в секунду, что явно больше, чем 115200. В два раза. Но это параллельный интерфейс, причём с ожиданием готовности. Вот хотя бы на эти цифры стоит ориентироваться.

[izzx]

Разве что мегабит это перебор и смысла не имеет

Ну не совсем. Я вот прикинул, что мне для потока видео надо 1600 000 бит/с. Смотреть фильмы прямо с сервера ).

16550 можно пересадить на действующую схему,

Да. Я клиента подправлю для железного порта и готово.

Глянул на ZXMC - что-то мне кажется, что там 115200 максимум. Маловато будет.