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

[valerium]

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

Я именно про это же. 115200 это всё-таки ощутимо медленно (кто на PC данные по нульмодему гонял, хорошо ощущает), а работа по параллельному интерфейсу (в данном примере работа с ВГ93 и флопом) дискомфорта не вызывает. Короче, надо будет осваивать GPIO на esp и перестраивать все на параллельный интерфейс. Я попробую, правда вряд ли раньше новогодних каникул, за это время что-то вроде тз должно в голове улечься.

[Advertiser]

[Serg6845]

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

по факту без турбо тянет 300, вряд ли сильно больше. (8085 на 4МГц тянет 500, т.е. HD дискеты, но с привлечением аппаратных средств. но это совсем другая история)

[Kulich]

У вас 250 кбит между дисководом и ВГ93 или между ВГ93 и Z80? ) Это 2 большие разницы. Ну и давайте посчитаем, 3.5 МГц, я прикинул что если не стараться ну сильно извергаться нужно тактов 40 на байт или бит, смотря чем дрыгаем, это будет в районе 87500 байт или бит. Но это минимальное время идеал но железа без вейтов, занятой шины и не занятых портов.

[reddie]

У вас 250 кбит между дисководом и ВГ93 или между ВГ93 и Z80? ) Это 2 большие разницы.

Это скорость потока данных от ВГ93, под неё уже подстраивается протокол обмена с флопом.
Приводилось просто как пример для ориентира. Можно вообще к LDIR весь обмен свести, дело лишь в реализации.

[Kulich]

Это скорость потока данных от ВГ93, под неё уже подстраивается протокол обмена с флопом.
Приводилось просто как пример для ориентира. Можно вообще к LDIR весь обмен свести, дело лишь в реализации.

Это как? Меняет скорость вращения диска чтоль? ) Как-раз скорость чтение диска константна, и она равна 250,500 и прочие кбит, а вот компьютер может читать данные с ВГ как ему удобнее.

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

Кстати для того чтобы успешно работать на шине нужен достаточно быстрый контроллер, чтобы он успевал дергаться.
Т.е. там порядка 500-700 нс на то чтоб получить прерывание и выставить ответ или просто отреагировать.
Вот тут интересная статья про эмуляцию дисковода и картриджа на STM32
https://www.kernelcrash.com/blog/emu...sx/2020/06/14/

[izzx]

То что 115200 у человека получилось получить только сильно извернувшись и поломав голову и говорит о том что где-то в этих пределах и лежит максимальная скорострельность в операциях,

Подождите. На скорпе копирование с карты на карту через SMUC занимает 5 сек целая дискета. В турбе. А это значит около 1.2 мегабита. И причём это сначала чтение, потом запись. А там шина 8 бит.

А при обмене на 57600 процессор даже не в турбе довольно много ждёт. И по одному биту всё проталкивает. А на 115200 предел возможностей, похоже, для нетурбы. Но это для UART протокола.

[reddie]

компьютер может читать данные с ВГ как ему удобнее

Это уже если лезть в технические дебри контроллера и флопа. На стандартном обмене скорость фиксированная, не просто же так существуют эти обороты диска в 300, 360 и другие. Частота ВГ определяет скорость записи данных. Спектрум обязан принять/отослать данные в порт ВГ по сигналу готовности, иначе вылетит ошибка. Вот эта стандартная скорость и есть 250 Кбит (5 оборотов в секунду, 6 Кб на дорожке, итого 30 Кбайт).

Выше уже отписали о копировании дискеты за 5 секунд, что довольно неплохо. Да, с карты на карту, но что мешает реализовать эти скорости для других типов хранения (приема) данных?

[Kulich]

Это уже если лезть в технические дебри контроллера и флопа. На стандартном обмене скорость фиксированная, не просто же так существуют эти обороты диска в 300, 360 и другие. Частота ВГ определяет скорость записи данных. Спектрум обязан принять/отослать данные в порт ВГ по сигналу готовности, иначе вылетит ошибка. Вот эта стандартная скорость и есть 250 Кбит (5 оборотов в секунду, 6 Кб на дорожке, итого 30 Кбайт).

Выше уже отписали о копировании дискеты за 5 секунд, что довольно неплохо. Да, с карты на карту, но что мешает реализовать эти скорости для других типов хранения (приема) данных?

Ну для 7 мегагерц там уже веселее я за 3.5 приводил расчет. Кажется я знаю как работает это копирование, без участия памяти вообще, так-как это тактов 28 на байт из которых in/out 20 съедают точно.

Но вообще это дело десятое, максимальная скорость. Главное чтоб работало=) Я гофернеты в районе 9600 бороздю и не жалуюсь )

[izzx]

То-есть как бы обязательно иметь самописный сервер?

Немного почитал. В общем, с завода умеет работать через TCP, команда
AT+CIPSEND Отправить данные TCP/IP
Как я понимаю, так работает гофер браузер. Посылает текстовые запросы типа GET на HTTP сервер.
Но мне такое не подходит, потому что ответы от сервера могут быть разной длины. Тут нужен контроль передачи, чтобы приостанавливать. А так на 57600 времени на анализ пакета нет. Комп всё время ждёт данные.
А у меня все пакеты от сервера равной длины, поэтому просто.
И размер их около килобайта, потому что у меня не получилось за раз пропихнуть через ESP больше, чем примерно 1200 байт. Если пакет больше, она просто игнорирует его ).

Ещё для ESP бывает FTP клиент, он может тягать файлы с сервера и записывать в свою примитивную файловую систему в память или на SD карту.

Доп.
А когда не знаешь какой длины придёт пакет, вопрос когда остановить приём. Сервер http наверное шлёт в конце пакета символ типа 13 или 0. Значит надо выкроить время анализировать каждый байт на лету. И ещё загвоздка в том, что когда выставляешь бит остановить передачу, она останавливается не сразу. Можно битик и потерять.

[valerium]

Кажется я знаю как работает это копирование, без участия памяти вообще, так-как это тактов 28 на байт из которых in/out 20 съедают точно.

Даже если эту перезапись реализовать сдвигами напрямую из одной карты в другую (по SPI или по полному 4-разрядному интерфейсу SD), то все равно надо много доп.информации передавать каждой из карте для адресации единиц размещения (файловую систему-то она сама по себе не детализирует, а как без ее разбора ?). Но в СМУКе ж и этого нет. Как копировать без участия памяти-то ?
И как за 5 сек вся дискета - разъясните, а то аж уснуть не могу )

Что касается предела скорости обмена, тут Kulich действительно прикинул довольно точно.
Вот такой фрагмент кода читает данные из условного "порта данных" некоей идеализированной железяки, которая в идеальном случае успевает формировать очередной байт данных к каждому новому чтению из порта. После чтения байт сохраняется в буфер в ОЗУ.

	ld hl, srcaddr
	ld de, length
	ld bc, portaddr
loop:	in a, (c)	12T
	ld (hl), a      7T
	inc hl          6T
	dec de          6T
	jr nz, loop     12T

На это уходит 43 (то есть даже больше, чем 40) тактов на один цикл (=байт), и это без какой-либо прочей обработки полученных данных и контроля готовности очередных данных перед приемом. 81395 циклов в секунду. Но это "сферический конь в вакууме".
Если в действительности будет даже вдвое меньше, то ~40Кбайт/с при байтном обмене по 8-разрядной шине уже было бы неплохим результатом (~16 сек суммарное время на получение данных всех фрагментов TRD от сервера + обычное суммарное время записи из памяти на флоп с ожиданием позиционирования).
Если бы такое удалось, уже классно. Все зависит действительно от того, насколько хорошо удастся оптимизировать обработку прерывания при обращении к ESP на чтение. Для нас, начинающих, та еще задачка )