Простой флэш-диск от 16 мб + быстрый SPI для современной периферии

[RyazanNik]

Запилил простой флэш-диск на 16 мб, всего на двух микросхемах. Схема тут http://zvzd3d.ru/orion128/OrionDiskNiky.html
Подключается к порту F5, имитирует стандартный ROM-диск. Можно иметь ряд ROM-дисков и легко их переключать. Поддерживаются ROM-диски более 64 кб (совместимы с DsDos).
Имеются также специальные высокоскоростные режимы чтения. Также к диску можно подключать современную SPI-переферию (например, SD-карты, Ethernet-контроллер, ЦАП).
С ROM-дисками всё понятно, существующий софт (в том числе DsDos) работать будет.
Но для записи на флэш пока софта под орион нет. Вопрос - стоит ли развивать проект дальше или ну на фиг?

[Denn]

Но для записи на флэш пока софта под орион нет.

Интересно. По мере возможности попробую сделать поддержку в DSDOS, но нужна либо живая железка, либо поддержка сабжа в эмуляторе от b2m =)



Вопрос - стоит ли развивать проект дальше или ну на фиг?

Имхо, стоит. Только с прицелом на более высокие тактовые частоты ЦП ;)

[RyazanNik]

Интересно. По мере возможности попробую сделать поддержку в DSDOS, но нужна либо живая железка, либо поддержка сабжа в эмуляторе от b2m =)

Да железка то простая... Вы рассматриваете её только как накопитель или SPI может ещё пригодиться?



Имхо, стоит. Только с прицелом на более высокие тактовые частоты ЦП ;)

Более высокие - это какие? 10 МГц или ещё выше?
Самое сложное - эмуляция ROM с произвольным доступом. Как сейчас сделано - будет работать до 5 МГц Ориона включительно. Выше - крайне затруднительно, тут остаётся только быстрая flash память МК на 64 кб для загрузки Ориона, а далее в коде нужно разносить SHLD F501 и LDA F500.
Что касается быстрых режимов чтения / записи, то это должно спокойно работать на 10 МГц Ориона.
Если надо выше 10 МГц - не знаю, думать и считать надо, тут уже накладные расходы прошивки МК существенны...

[Denn]

Вы рассматриваете её только как накопитель или SPI может ещё пригодиться?

Всегда хотелось решить вопрос с быстрым подключением SDHC. В остальном пока SPI не пригождалось в жизни. Думаю, тут голосовалку можно попробовать устроить, может общественность что-то подскажет.



Более высокие - это какие? 10 МГц или ещё выше?

Если с заделом на будущее (развитие), то 20 МГц. Совсем в идеале - 40. Имхо.



Самое сложное - эмуляция ROM с произвольным доступом. Как сейчас сделано - будет работать до 5 МГц Ориона включительно. Выше - крайне затруднительно...

ROM-диск мне видится средством загрузки, этаким расширенным "монитором". Серьёзно рассматривать его в качестве накопителя в случае развития платформы, думаю смысла нет.

П.С. лучше IDE-винчестера очень сложно что-то придумать, как выясняется. А та же SDHC подключается к IDE через переходник, и никаких расходов кода на Орионе...

[RyazanNik]

Если с заделом на будущее (развитие), то 20 МГц. Совсем в идеале - 40. Имхо.

Ну понятно, что это будет уже не на к580вм80, а на некой хитрой архитектуре, и накопитель / SPI тогда надо предусматривать в рамках этой архитектуры, а не навешивать отдельным МК к порту F5...


лучше IDE-винчестера очень сложно что-то придумать, как выясняется. А та же SDHC подключается к IDE через переходник, и никаких расходов кода на Орионе...

Логично...

Вообщем развивать лишний накопитель смысла не имеет. А для ретро-компа DsDos с ROM-диском на 1 мб - уже отличное решение (спасибо Вам!).
Так что мне остаётся добавить к флэш-диску возможность сохранения/восстановления памяти ориона через мой спец-загрузчик - и достаточно.

[Denn]

Ну понятно, что это будет уже не на к580вм80, а на некой хитрой архитектуре, и накопитель / SPI тогда надо предусматривать в рамках этой архитектуры, а не навешивать отдельным МК к порту F5...

Идеальнее всего - делать универсальный девайс. Как бы предполагая, что у всех платформы могут быть разные. И при этом чтобы была совместимость, в т.ч. с базовой (ВМ80, F5 и т.п.).



Так что мне остаётся добавить к флэш-диску возможность сохранения/восстановления памяти ориона через мой спец-загрузчик - и достаточно.

Произвольный посекторный (по 512 или 1024 байт) R/W-доступ же возможен?

[Error404]

Да железка то простая... Вы рассматриваете её только как накопитель или SPI может ещё пригодиться?




Более высокие - это какие? 10 МГц или ещё выше?
Самое сложное - эмуляция ROM с произвольным доступом. Как сейчас сделано - будет работать до 5 МГц Ориона включительно. Выше - крайне затруднительно, тут остаётся только быстрая flash память МК на 64 кб для загрузки Ориона, а далее в коде нужно разносить SHLD F501 и LDA F500.
Что касается быстрых режимов чтения / записи, то это должно спокойно работать на 10 МГц Ориона.
Если надо выше 10 МГц - не знаю, думать и считать надо, тут уже накладные расходы прошивки МК существенны...

Абстрагируясь, уже Z80 с типовыми 5Мгц (т.е. каких сейчас примерно половина парка) может в заданные временные рамки не влезть, т.к. благодаря тому, что порты ВВ55 в Орионе адресуются "секторами" по 256 байт, Z80 может читать их командой LDI и цикл чтения в тактах свернется вдвое-втрое.

Проект полезный, но одного ПЗУ мало (оно и так у всех есть, хотя у контроллера тут есть некий профит - например в удаленом доступе к нему с PC - для обновления "ROM-дисков" на лету), смысл имеется когда все контроллеры SPI (а их там море, взять хотя бы Ethernet) можно подключать и полноценно с ними обмениваться. Т.е. либо надо хосту (Ориону) давать RAW доступ к регистру SPI (и дорогущий PIK стоимостью почти в PI Zero тогда превращается в просто регистр сдвига) и ПО надо писать на стороне Ориона, либо контроллеру надо и аппаратно давать больший функционал, и ПО в нем допиливать, и опять же поддерживать на стороне Ориона какой-то протокол (хотя тут уже полегче станет, например стек TCPIP можно унести в контроллер а Ориону выдать уже сокеты, и т.п.).

[RyazanNik]

Идеальнее всего - делать универсальный девайс. Как бы предполагая, что у всех платформы могут быть разные. И при этом чтобы была совместимость, в т.ч. с базовой (ВМ80, F5 и т.п.)

Универсальность просто так не даётся... Если надо 20 и 40 МГц, то устройство становится сложным, среди 8-битных МК в паябельных корпусах вообще нет SPI быстрее 16 Мбод. Надо городить какой-нибудь stm32, может с четырехпроводным QSPI... В принципе, тоже можно уложиться в две микры, но по stm32 я не спец.

Другой подход - предусматривать какую-то синхронизацию / замедление, когда ориону приходится ожидать реакции устройства. Для высоких частот это вполне нормально, ибо у периферии всегда есть свои ограничения. Например, те же stm32 не успевают читать флэш-память программы даже на 80 МГц, поэтому там наворочены всякие кэширования...
Но синхронизация сильно бьёт в плане скорости по низкочастотным орионам... А делать разным код конечно плохо (хотя представляю, что будет с обычным кодом опроса клавы на 20 МГц орионе).



Произвольный посекторный (по 512 или 1024 байт) R/W-доступ же возможен?

Читать W25Q128 можно легко и быстро с произвольного адреса. Но минимальный стираемый блок - 4096 байт (хотя на заранее стёртое место можно писать блоками по 256 байт).
Конечно можно (это же МК!) съэмулировать произвольную запись секторами по 512 байт... Но быстродействие записи снизится, а эти w25q128 вообще не быстрые на запись, даже при последовательной записи мне удавалось лишь 20-30 кб/с.
В этом плане куда лучше SDHC-карты, они быстрые и их можно писать секторами по 512 байт (другое дело, что там физический стираемый блок может быть побольше 32 кб и скорость при произвольной записи может просесть очень сильно).

[Denn]

Если надо 20 и 40 МГц, то устройство становится сложным, среди 8-битных МК в паябельных корпусах вообще нет SPI быстрее 16 Мбод. Надо городить какой-нибудь stm32, может с четырехпроводным QSPI...

Сложно тоже смысла нет - в народ не пойдёт.



Другой подход - предусматривать какую-то синхронизацию / замедление, когда ориону приходится ожидать реакции устройства.

Тут какое дело. Если накопитель достаточно объёмный и платформа у нас достаточно быстрая, то автоматом встают требования к быстродействию связки, т.к. собственно весь смысл такого развития только в этом.

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



Но минимальный стираемый блок - 4096 байт

Это просто прекрасно! По моим расчётам, для эффективного использования 16 Мб диска как раз сектор получается 4 Кб, для HDD именно так у меня и организовано в DSDOS.

[RyazanNik]

Абстрагируясь, уже Z80 с типовыми 5Мгц (т.е. каких сейчас примерно половина парка) может в заданные временные рамки не влезть, т.к. благодаря тому, что порты ВВ55 в Орионе адресуются "секторами" по 256 байт, Z80 может читать их командой LDI и цикл чтения в тактах свернется вдвое-втрое.

Конечно, при желании легко придумать код, чтобы эмулируемый ROM-диск дал ошибку. Но какое это имеет значение? Главное, чтобы нормально работал уже существующий реальный код - фактически, Мониторы, OrDosы и DsDos.



Т.е. либо надо хосту (Ориону) давать RAW доступ к регистру SPI (и дорогущий PIK стоимостью почти в PI Zero тогда превращается в просто регистр сдвига) и ПО надо писать на стороне Ориона.

Ну почему дорогущий, 330р в чип-дип в корпусе dip40 (я правда брал куда дешевле, но чип-дип ещё тот магазин), а PI Zero это пара тыщь... Хотя пожалуй да, регистр сдвига.



либо контроллеру надо и аппаратно давать больший функционал, и ПО в нем допиливать, и опять же поддерживать на стороне Ориона какой-то протокол (хотя тут уже полегче станет, например стек TCPIP можно унести в контроллер а Ориону выдать уже сокеты, и т.п.).

По мне лучше работать с Ориона с SPI напрямую. Ибо куда перспективнее изучить реальную переферию, а на какую-то там прослойку на МК. Современная переферия простая - дальше некуда. Вот хоть Ethernet-контроллер W5500, там уже сокеты есть, только клади данные в буфер / читай принятые.

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


Тут какое дело. Если накопитель достаточно объёмный и платформа у нас достаточно быстрая, то автоматом встают требования к быстродействию связки, т.к. собственно весь смысл такого развития только в этом.

Ну не знаю, допустим, сейчас для "флэш-диска" предельная скорость чтения SPI 1.6 мб/с (если Орион достаточно быстр, ну, допустим). По сравнению с теми 44кб/с, которые сейчас достигаются для ROM-диска, очень не плохо!
По современным меркам, конечно, очень мало, но что с этим потоком Орион будет делать, даже на 40 МГц? Хороший звук, например, всего 200 кб/с. Если тупо прочитанное в видеопамять класть, можно получить 66 кадров в сек. Опять же - код программ можно в память подгружать кусками и иметь дико сложные программы.
Писать на SD-карту тоже можно 1.6 мб/с, если не злоупотреблять произвольным доступом.
Есть ли смысл ещё увеличивать скорость накопителя для Ориона?

Меня лично больше напрягает отсутствие многозадачности, т.е. например, что игра звука параллельно с другой работой не возможна, но эту проблему просто не решить...

[ALS]

... на правах оффтопа )
PIC-и неплохо гонятся при внешнем тактировании. Проверял с внешним генератором на 24MHz и включенным умножением х4. Вся набортная периферия работала нормально.

[Error404]

Конечно, при желании легко придумать код, чтобы эмулируемый ROM-диск дал ошибку. Но какое это имеет значение? Главное, чтобы нормально работал уже существующий реальный код - фактически, Мониторы, OrDosы и DsDos.


Потому что делать аппаратную разработку, работающую только в одной конкретной ОС это не наш метод. :)
Есть вполне реальные ОС, написанные под Z80 где полно всяких хаков, в т.ч. и работа из РОМ-диска и с RОМ-диском. Может там тоже захочется такой ROM-диск? Хотя конечно, можно и замедлить чтение в коде, не проблема.



Ну почему дорогущий, 330р в чип-дип в корпусе dip40 (я правда брал куда дешевле, но чип-дип ещё тот магазин), а PI Zero это пара тыщь... Хотя пожалуй да, регистр сдвига.


Я тут отстал от реалий, возможно? Я еще мысленно пребываю во временах когда Pizero=5$, а OrangePI=10$. А когда оно так подорожало?

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



Ибо куда перспективнее изучить реальную переферию, а на какую-то там прослойку на МК. Современная переферия простая - дальше некуда. Вот хоть Ethernet-контроллер W5500, там уже сокеты есть, только клади данные в буфер / читай принятые.


Вот вы сейчас прямо на больное наступаете. Уже года три как сделали аппаратный SPI на 5 микросхемах 1533 тупо со сдвиговым регистром, и ни одного проекта (SDHC я не учитываю т.к. схема для нее и делалась, и прекрасно работает на дюжине платформ от Галаксии и RK-86 с их 16кб ОЗУ до Ориона с его 16Мб, и даже кросплатформенная ДОС есть с FAT16). А уж как я тут расписывал про прелести внешних дивайсов подключенных по SPI. Но нет, суровые парни не одобряэ. Или ленятся (как и я сам, каюсь).



Меня лично больше напрягает отсутствие многозадачности, т.е. например, что игра звука параллельно с другой работой не возможна, но эту проблему просто не решить...

Был проект где в качестве ковокса для проигрывания оцифровки использовался AY. Вот там ЕМНИП слайс для параллельности оставался (хотя и очень небольшой, большую часть все же съедала прогрузка AY), при том что всё делалось из заранее заполненного ОЗУ (подгрузка с носителя все положит, да).

[RyazanNik]

PIC-и неплохо гонятся при внешнем тактировании. Проверял с внешним генератором на 24MHz и включенным умножением х4. Вся набортная периферия работала нормально.

А точно было 24x4 МГц, а то ведь RC-генератор в PLL может тупо такую частоту не потянуть. Но вообще да, спасибо, можно попробовать... А на счет переферии - даже для быстрых dsPic33 со скоростью 70 MIPS заявлена макс. частота SPI в 15 МГц, ну не свинство ли...



Потому что делать аппаратную разработку, работающую только в одной конкретной ОС это не наш метод. :)
Есть вполне реальные ОС, написанные под Z80 где полно всяких хаков, в т.ч. и работа из РОМ-диска и с RОМ-диском. Может там тоже захочется такой ROM-диск? Хотя конечно, можно и замедлить чтение в коде, не проблема.

Я с Z80 не работал. Почитал - пока не очень понимаю, как можно стандартное чтение ROM F5 значимо ускорить. INI конечно хороша, но кто сперва адрес чтения на ППА F5 выставит?
В любом случае, пока 2 мкс от обнаружения адреса до выдачи байта и ещё 1.5 мкс до обслуживания следующего адреса - мой предел (это 5 МГц для Ориона).
Простого и универсального решения тут нет.



Я тут отстал от реалий, возможно? Я еще мысленно пребываю во временах когда Pizero=5$, а OrangePI=10$. А когда оно так подорожало?

Я не спец, тупо посмотрел на али.




Вот вы сейчас прямо на больное наступаете. Уже года три как сделали аппаратный SPI на 5 микросхемах 1533 тупо со сдвиговым регистром, и ни одного проекта (SDHC я не учитываю т.к. схема для нее и делалась, и прекрасно работает на дюжине платформ от Галаксии и RK-86 с их 16кб ОЗУ до Ориона с его 16Мб, и даже кросплатформенная ДОС есть с FAT16). А уж как я тут расписывал про прелести внешних дивайсов подключенных по SPI. Но нет, суровые парни не одобряэ. Или ленятся (как и я сам, каюсь).

И правильно, нафига на Орионе интернет какой-то, его и так везде слишком много :)


Денис, я тут прикинул по скоростям - если делается проброс CS ППА F5 и чтение данных идет каждые 19 тактов (mov a,m; stax d; inx D), то Орион может запросто молотить на 20 МГц. При этом скорость чтения составит 1027 кб/с. На более низких частотах Ориона скорость чтения снижается пропорционально из-за замедления кода на орионе. В этом случае хорошо бы модифицировать код, чтобы он стал быстрее (но наверное это возможно только инструкциями Z80).

Если у Ориона выше 40 МГц - надо увеличивать интервалы в программе, чтобы не превышать эти 1027 кб/с.
В принципе у МК полно таймеров, используя их программа на Орионе могла бы оценить частоту Ориона и загрузить оптимизированный набор функций по работе с SPI (на самом деле нужна только одна оптимизированная функция быстрого SPI чтения большого блока).

Конечно, на высоких частотах SPI на "сдвиговом регистре" был бы быстрее. Но воспользоваться этим на 20МГц можно, опять же, только сперва оптимизировав сам код чтения для Ориона. Что касается 40МГц - на таких частотах уже приходится менять подходы к работе с периферией. Например, чтение из w25q128 при тактовой выше 20 МГц надо делать отдельной командой и первый прочитанный байт пропускать. SD-карту тоже надо инициализировать на более низких частотах. Т.е. на самом деле "сдвиговому регистру" нужен ещё перестраиваемый задатчик скорости...

[ALS]

Сорри, обманул, 20MHz.
Но это точно )
МК - PIC16F1825

https://cs6.pikabu.ru/post_img/2017/09/01/0/1504216762133441030.jpg

[Denn]

если делается проброс CS ППА F5 и чтение данных идет каждые 19 тактов (mov a,m; stax d; inx D), то Орион может запросто молотить на 20 МГц.

По коду "всё печальнее", у меня например в онлайне проверяется возможный выход за границу банка, так что далеко не так быстро ПО читает данные.



Если у Ориона выше 40 МГц - надо увеличивать интервалы в программе, чтобы не превышать эти 1027 кб/с.

Высокоскоростная версия Ориона будет стартовать на дефолтных 2,5 МГц и будет иметь возможность программно задавать клок ЦП. Если ROM-диск рассматривать только в качестве загрузчика, то по идее можно не заморачиваться возможностью работы на 40 МГц. На больших скоростях уже полезут ограничения самих ПЗУшек скорее всего.

[Serg6845]

Сорри, обманул, 20MHz.
Но это точно )
МК - PIC16F1825



x4? т.е. 80МГц тактовой?

[ALS]

Таки да )

[RyazanNik]

По коду "всё печальнее", у меня например в онлайне проверяется возможный выход за границу банка, так что далеко не так быстро ПО читает данные.

Ну если ПО читает не быстро, значит и с Орионом на 40 МГц будет флэш-диск работать :)
Вообще для флэш-диска в режиме прямого чтения проверять банк не понадобится, там же автоинкремент. Свои соображения по эффективной организации циклов я дополнительно выложил тут: http://zvzd3d.ru/Orion128/OrionDiskNiky.html#YaCikli (надо обновить страницу). Конечно, это больше актуально для быстрого чтения.

Посмотрел Вашу реализацию чтения ROM-диска - вижу SHLD и LDA уже раснесены. При желании код можно ускорить. Цикл делать без "mov a,c; ora b". И проверку выхода за банк - делать вне цикла. Пусть HL - начальный адрес чтения, а BC - длина. Тогда если ~HL > BC, то переключения банка не нужно. Иначе читаем сперва (~HL+1) байт, переключаем банк, читаем остаток.



Высокоскоростная версия Ориона будет стартовать на дефолтных 2,5 МГц и будет иметь возможность программно задавать клок ЦП. Если ROM-диск рассматривать только в качестве загрузчика, то по идее можно не заморачиваться возможностью работы на 40 МГц. На больших скоростях уже полезут ограничения самих ПЗУшек скорее всего.

На чем же будет сделан Орион на 40 МГц?

[LeoN65816]

10, 20, 40 МГц... Вот десятку вроде сделали: по мегагерцам вдули в 4 раза больше, а на выхлопе всего 3.5 Маха... Под двадцатку даже и процик существует Z84C0020, а в реале Ориончика такого ПОКА нет... А под сороковку какой процик планируется? Хренсобаки, тьфу, Кавасаки KL5C8400C только 33 МГц позволяет... Хотя наш комрад утверждает, что гонится в лёгкую (https://zx-pk.ru/threads/28423-dvukhportovaya-pamyat.html?p=938305&viewfull=1#post938305).

RyazanNik, предложение: а если взять PIC/dsPIC с Parallel Master Port (PMP) и его тулить не к ВВ55, а вместо ВВ55 на шину, и при необходимости вэйтить основной процик. Уж тогда всё что угодно можно прикрутить. Как тебе идейка?

[RyazanNik]

RyazanNik, предложение: а если взять PIC/dsPIC с Parallel Master Port (PMP) и его тулить не к ВВ55, а вместо ВВ55 на шину, и при необходимости вэйтить основной процик. Уж тогда всё что угодно можно прикрутить. Как тебе идейка?

А Орион что, можно "вэйтить"? Это же какой то Радио-РК86 тогда получается... А если несколько абонентов захотят вэйтить? Конечно, вэйтить понадобится в весьма редких случаях, когда ROM-диск на самом деле не успевает (что легко распознать и выставить соответствующий сигнал).

Идея на первый взгляд чертовски хороша: выкидывается ВВ55, а вместо неё подключается Pic, который эмулирует огромный ROM-диск и имеет при этом кучу реально свободных ног для действительно нужной внешней переферии (АЦП, таймеры, 2 SPI чтобы можно было гнать с SD-карты на звук ЦАП прямым потоком, I2C всякие). Красота!

На самом деле ведомый Parallel Master Port в dsPIC это всего лишь 4 регистра-защелки. Т.е. отличий от ВВ55 почти никаких. Чисто экономия ног у МК.
Увы, не думаю, что кто-то захочет выдирать ВВ55 из ретро-сборки или плату переразводить... Я лично в своём любимом стареньком Орионе ничего кардинального трогать не готов, если только что-то внешнее подключать. Для высокоскоростного режима флэш-диска уже достаточно проброса одной линии CS от ППА. Да и ожидание нужно только для эмуляции ROM-диска выше 5 МГц, а в прямом режиме, как выясняется, даже на 40 МГц софт 1 мб/с с трудом читает...



10, 20, 40 МГц... Вот десятку вроде сделали: по мегагерцам вдули в 4 раза больше, а на выхлопе всего 3.5 Маха... Под двадцатку даже и процик существует Z84C0020, а в реале Ориончика такого ПОКА нет... А под сороковку какой процик планируется? Хренсобаки.

Это получается видеовыход скорость портит?
Ну понятно, что скоростные Орионы это такая проблема, что тут не до флэш-диска...

[Denn]

Ну если ПО читает не быстро, значит и с Орионом на 40 МГц будет флэш-диск работать :)

Значит вопрос можно считать закрытым.



При желании код можно ускорить.

Я когда-то упирался по части ускорения кода чтения ПЗУ, но потом приоритет сменился в сторону компактности кода, а по скорости особой разницы не заметил.



проверку выхода за банк - делать вне цикла... переключаем банк, читаем остаток.

Тоже об этом подумал. Но в данном случае это не требуется, т.к. заметно будет лишь только на больших файлах.



На чем же будет сделан Орион на 40 МГц?

Вот на этом - http://www.cpu-world.com/CPUs/Z80/Kawasaki-KL5C8400C.html

С небольшим разгоном (https://zx-pk.ru/threads/28423-dvukhportovaya-pamyat.html?p=938305&viewfull=1#post938305): 33 -> 40 МГц

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


Увы, не думаю, что кто-то захочет выдирать ВВ55 из ретро-сборки или плату переразводить...

Все расширения лучше делать в пространстве F7xx, а родное пусть действительно будет в первозданном виде.

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


Под двадцатку даже и процик существует Z84C0020, а в реале Ориончика такого ПОКА нет... А под сороковку какой процик планируется? Хренсобаки, тьфу, Кавасаки KL5C8400C только 33 МГц позволяет...

Имхо, для Ориона потолок - 20 МГц. Оно и достаточно. Выше уже нужно архитектурно полностью пересматривать, это будет другой комп.

[RyazanNik]

Я когда-то упирался по части ускорения кода чтения ПЗУ, но потом приоритет сменился в сторону компактности кода, а по скорости особой разницы не заметил.

Сейчас в DsDos чтение ROM - 80т на байт. а классический цикл - 61 такт на байт. Тело цикла - всего 46 тактов на байт, и если читать по 4 байта, то будет 50 тактов на байт. Итого можно ускорить в 1.3 раз просто и в 1.6 раза - потеряв компактность кода (ну как потеряв: лишние 27 байт; для f3xx не желательно, но можно по страницам распихать).


заметно будет лишь только на больших файлах.

На самом деле многое будет работать пропорционально быстрее. Для Ориона файл на 8 кб уже большой. Какой-нибудь Kort$ на 32 кб грузится целую секунду. Если процедура чтения ROM у Вас универсальная и используется везде, то есть не плохая мотивания оптимизировать её по-максимуму.
Конечно, 1.3 раза не много - но только потому, что обычное чтение ПЗУ не быстрое (тело 46 тактов). А если читается напрямую "флэш-диск" или Ваш быстрый RAM7, где тело цикла 19 тактов? Тут терять 34 такта на организацию цикла не хорошо...



Все расширения лучше делать в пространстве F7xx, а родное пусть действительно будет в первозданном виде.

Не, тогда как раз придётся подключаться к системной шине. А мне пока боязно. "Флэш-диск" на F5 этого не требует, хотя по скорости оказывается не хуже (при пробросе только CS ППА F5).
Если уж подключаться к шине - то как сказал LeoN65816, вместо ППА F5. Тогда будет 100% рабочий на любой частоте Ориона большой ROM-диск (с умным Wait выше 5 МГц) + возможноть подключения современной переферии. Уж очень симпатичный вариант...



Имхо, для Ориона потолок - 20 МГц. Оно и достаточно. Выше уже нужно архитектурно полностью пересматривать, это будет другой комп.

Ну если старый софт работать будет - значит формально Орион. Только видеосистема на ПЛИС - совсем уже не орион в плане простоты...

[Denn]

Итого можно ускорить в 1.3 раз

Крайний концепт DSDOS с упором на работу с RAM-накопителями, НЖМД и виртуальным диском. Плюс место для кода "кончилось".
Поэтому ROM-диск только для загрузки ОС и мелких системных утилит. В 1,3 раза - слабая мотивация.



и в 1.6 раза - потеряв компактность кода (ну как потеряв: лишние 27 байт; для f3xx не желательно, но можно по страницам распихать).

С непереключаемым ОЗУ вообще всё очень жёстко. В новом поколении ОС будет немножко полегче, постараюсь (чисто для галочки) оптимизировать процедуры чтения из ROM-диска.



Если процедура чтения ROM у Вас универсальная и используется везде, то есть не плохая мотивания оптимизировать её по-максимуму... А если читается напрямую "флэш-диск" или Ваш быстрый RAM7

RAM7 обслуживает совершенно другой код, там упор на скорость максимальный.



Не, тогда как раз придётся подключаться к системной шине. А мне пока боязно...
Если уж подключаться к шине - то как сказал LeoN65816, вместо ППА F5. Тогда будет 100% рабочий на любой частоте Ориона большой ROM-диск (с умным Wait выше 5 МГц) + возможноть подключения современной переферии. Уж очень симпатичный вариант...

Очень симпатичный вариант надо использовать ;)



Только видеосистема на ПЛИС - совсем уже не орион в плане простоты...

Никаких ПЛИС, конечно! Но "видеокарта" - отдельным асинхронным устройством, чтобы для основной МПС никаких вэйтов и привязок к синхрогенератору видеосистемы.

[LeoN65816]

А если несколько абонентов захотят вэйтить?
А в чем проблема? Каждому абоненту дать по морде октрытому коллектору/стоку! ;)


Идея на первый взгляд чертовски хороша: выкидывается ВВ55, а вместо неё подключается Pic, который эмулирует огромный ROM-диск и имеет при этом кучу реально свободных ног для действительно нужной внешней переферии (АЦП, таймеры, 2 SPI чтобы можно было гнать с SD-карты на звук ЦАП прямым потоком, I2C всякие). Красота!
А то!!!


На самом деле ведомый Parallel Master Port в dsPIC это всего лишь 4 регистра-защелки.
Адресуемый ведомый порт с четыремя адресами. Программно-аппаратная эмуляция ВВ55 и программно-аппаратная обработка смены адреса ROM-диска! А ведь есть ещё автоинкремент и FIFO!


Увы, не думаю, что кто-то захочет выдирать ВВ55 из ретро-сборки или плату переразводить...
Выдёргиваешь из цанговой панельки ВВ55, и втыкаешь в эту же панельку свою платку с dsPIC.


Это получается видеовыход скорость портит?
Синхронное расшаривание одной памяти на два потребителя (процик и видеоконтроллер).


Имхо, для Ориона потолок - 20 МГц. Оно и достаточно.
У-у-у-у-у... Чем больше имеешь - тем ещё больше хочется... Вот увидишь!


Выше уже нужно архитектурно полностью пересматривать, это будет другой комп.
Посмотри на пример из моей подписи. Мой АГАТик остался АРХИТЕКТУРНО тем же самым АГАТиком, и для программ, и для программеров, только процик теперь совершенно не зависит от видеоконтроллера - можно гнать его как угодно, и плюс новые няшки появились.


Уж очень симпатичный вариант...
А то!


Ну если старый софт работать будет - значит формально Орион.
Йа-йа! Архитектурно это тот же Ориончик!


Только видеосистема на ПЛИС - совсем уже не орион в плане простоты...
А при чём тут ПЛИС? Смотри на пример в подписи.

[RyazanNik]

Очень симпатичный вариант надо использовать

Посмотрел более детально: печаль, dsPic33 МК с требуемым Parallel Master Port стоят по 600р и в непаябельных корпусах (хотя нашпигованы интерфейсами они знатно, это плюс).
Но самое плохое: вряд ли одна прошивка будет успевать интеллектуально выставлять сигнал Wait даже для Ориона на 20 МГц.
Тут нужна дополнительная (дискретная?) логика: если была запись в F5, то следующее чтение F5 надо задержать, пока МК не подтвердит готовность данных. Но тогда не особо нужен dsPic, это же можно легко сделать с ППА F5 и МК, какой сейчас...
В этом плане предложенный флэш-диск всё же некий оптимум простоты...



А ведь есть ещё автоинкремент и FIFO!

Что-то не вижу в slave-режиме ни FIFO, ни автоинкремента. МК тупо защелкивают и флаги выставляет, а прошивка пусть сама разбирается. Но даже на 100MIPS при тактовой Ориона в 20 МГц времени прошивке не хватает.



Адресуемый ведомый порт с четыремя адресами. Программно-аппаратная эмуляция ВВ55 и программно-аппаратная обработка смены адреса ROM-диска!

Ну это понятно. Хотя я бы предпочел более амбициозный вариант - замену не одного абонента, а сразу нескольких. Но на dsPic33 с их PMP это не реализуемо...


В этой связи в голове крутится мысль: взять быстрый проц (Z84C0020 или даже KL5C8400C), прилепить память - и МК к системной шине. Чтобы этот МК с wait заменял всю периферию. Получится некий быстрый отладочный Орион. Разве что без дисплея (хотя остановив проц всего на 5 мс можно переслать в IBM-PC содержимое всей видеопамяти).

Только я совсем забыл, когда выдавать wait, можно ли, когда чтение/запись уже идёт, или же надо слово состояния проца ловить...



Никаких ПЛИС, конечно! Но "видеокарта" - отдельным асинхронным устройством, чтобы для основной МПС никаких вэйтов и привязок к синхрогенератору видеосистемы.

Вижу дело сложное, форум гудит...



А при чём тут ПЛИС? Смотри на пример в подписи.

Нихрена не понял, как конкретно сделано. Впрочем, это не моя тема...

[omercury]

Тыц 1 (https://www.mpja.com/download/ch376ds1.pdf)
Тыц 2 (https://aliexpress.ru/wholesale?catId=0&initiative_id=SB_20201127221641&origin=y&SearchText=CH376)

[Error404]

Тыц 1 (https://www.mpja.com/download/ch376ds1.pdf)
Тыц 2 (https://aliexpress.ru/wholesale?catId=0&initiative_id=SB_20201127221641&origin=y&SearchText=CH376)

Оч. прикольная штука. Этакий неправославный/читерский контроллер для 8-битки :) По скорости как схема PVV, НО! - с уже встроенным интерфейсом к FAT16/32.

На МSX это уже прикрутили. Можно было бы портануть. Через дивайс можно подключать флешки, клавиатуры, USB-Ethernet
https://github.com/S0urceror/MSX-USB
https://github.com/Konamiman/RookieDrive-FDD-ROM/blob/master/msx/bank1/ch376.asm
По факту, из полезного для нас (а точнее для неCPM-щиков коих большинство) только флешки, т.к. клавиатура- для ОРДОС нестандарт (в отличии от адаптера PS/2 это не готовая матрица, а нужен драйвер), а Ethernet голый - без стека TCP, а простейший uIP мало кому интересен

[Romych]

Мне тоже понравился этот читерский :) чип. Закажу для экспериментов. Модуль дла ардуины, не дорог, девборда 700р.