Орион-ПРО. Софтверные дела

[ivagor]

Спасибо за работу над плагином, но пока совсем хорошо не стало. Файл в 55 Кб теперь скопировал в .ohi нормально, а вот файлы 130 и 256 Кб обрезал

[Advertiser]

[Black Cat / Era CG]

o32

А расскажите про формат. Что там внутри?

[Error404]

Спасибо за работу над плагином, но пока совсем хорошо не стало. Файл в 55 Кб теперь скопировал в .ohi нормально, а вот файлы 130 и 256 Кб обрезал

Тогда, дубль два. Нашел еще один недочет в odi.wcx (заменяя его, надо прибивать и odi.wcx0,1,2,3).
Попробуй пожалуйста вот эту версию (во вложении).
Сегодня проверялся на файле размером 670кб (книга, txt), плагин в итоге нормально стал ее копировать в обе стороны, а вот в эмуляторе в CPM2.2 почитать из нее дает только первые 512кб. Похоже в BDOS CPM 2.2 где-то или в разрядность счетчиков упирается, или тупо где-то там есть баг (т.к. из описания тех. характеристик ФС CP/M я не припоминаю ограничения на файл в 512кб, возможно это глюк того реализа, который размножился по миру как версия 2.2 - фактическое ограничение в силу бага).

[Denn]

А я просто выключал турбу, писал/читал таймер, включал турбу.

Мне приходится на два фронта работать (О-128 и О-ПРО), поэтому проще и логичнее по возможности использовать универсальное решение проблемы для обеих платформ.

П.С. "писал/читал таймер, включал турбу" - а если комп уже по каким-то причинам работает не в турбе?

[ivagor]

Error404, этот вариант работает хорошо, так и с ohi стало можно работать.
Насчет 512 Кб - пробовал старые векторовские cp/mы, орионовские - в них это ограничение есть. В новых векторовских досах это ограничение, насколько могу судить, убрали, по крайней мере в рамках дискеты файлы можно не разбивать.

Black Cat / Era CG, мне было лень разбираться в своих старых исходниках вывода bmp на экран вектора и пошел легким путем - палитра+картинка по плоскостям. Не думаю, что где-то еще стоит делать поддержку такого формата.

Denn, причина проблем, как я понимаю, в том, что обычные ВИ53 были официально рассчитаны максимум на 2 МГц, а в орионах работали/работают на 2,5. Некоторые экземпляры это переносят, некоторые нет. 2,5 официально поддерживает ВИ53Д.
Насчет того как бороться - вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия). Если придется - может сделаю "тормозное" обращение к таймеру. Но имхо в идеале на про нужно использовать микросхемы стабильно работающие даже в турбе, не говоря уже про 2,5 МГц.

[Denn]

вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия)

Чёрт возьми, спасибо за идею! Как же я не додумался-то... точно, ведь это же таймер!

[Error404]

Error404, этот вариант работает хорошо, так и с ohi стало можно работать.
Насчет 512 Кб - пробовал старые векторовские cp/mы, орионовские - в них это ограничение есть. В новых векторовских досах это ограничение, насколько могу судить, убрали, по крайней мере в рамках дискеты файлы можно не разбивать.

Это таки "фича" BDOS CP/M 2.2 - ограничение в 512кб для последовательного чтения/записи, по крайней мере об этом знали и на прочих непатченных клонах CP/M 2.2. Вот например это обсуждают для AppleII (с платой Z80 и CP/M2.2):
http://www.verycomputer.com/74_3c7b339c31ec863b_1.htm
В более поздних CP/M это скорее всего исправили (что могли унаследовать и векторовские поздние Микродос-ы).
Искать этот баг дизассемблером я вряд ли буду, но в статье (а точнее переписке) по ссылке выше народ считает, что эта "фича" ограничивает только последовательное чтение (функция 014h BDOS), а функциями произвольного чтения (21h) типа должна читать и сверх 512кб т.к. разрядность номера записи - позволяет, а неправильно написанная процедура проверки переполнения экстента в этом случае не влияет. Т.е. можно было бы плагином записать нерезанные WAV-ы, а в проигрывателе для чтения использовать ф-ю произвольного чтения, просто номера секторов (а их для этой функции придется явно указывать в FCB файла) увеличивать последовательно. И работать это должно на всех версиях CP/M 2.х и выше (поддерживающих произвольный доступ)

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

Насчет того как бороться - вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия). Если придется - может сделаю "тормозное" обращение к таймеру. Но имхо в идеале на про нужно использовать микросхемы стабильно работающие даже в турбе, не говоря уже про 2,5 МГц.

Наверное этот способ хорош для компа на 8080 где нет прерываний. Где прерывания есть (8080 или Z80) ИМХО для вычисления быстродействия удобно посчитать количество инструкций выполнившихся между двумя соседними "приходами" прерываний регулярного таймера (в Орионе это таймер кадрового бланка - 50Гц)

[Denn]

Где прерывания есть (8080 или Z80) ИМХО для вычисления быстродействия удобно посчитать количество инструкций выполнившихся между двумя соседними "приходами" прерываний регулярного таймера (в Орионе это таймер кадрового бланка - 50Гц)

Тогда сперва встаёт задача определить, есть ли на данной платформе прерывания или нет

[OrionExt]

Это таки "фича" BDOS CP/M 2.2 - ограничение в 512кб для последовательного чтения/записи, по крайней мере об этом знали и на прочих непатченных клонах CP/M 2.2. Вот например это обсуждают для AppleII (с платой Z80 и CP/M2.2):

Вот. Я тему поднял (вот и аукнулось у других). Когда хотел за раз образ диска записать 800К)
Сорцы то открыты СПМ2.2, зачем их дизассемблировать?
Дальше ничего не понял. Подпрограмма (разрядность вх. параметров), позволяет читать более 512КБ?

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

Только сейчас дошло. А зачем последовательно вычитывать в память овер дохрена. В буфер. Скинули. И сначала. Это какой-то экстрим. Го 8 Гбайт за раз читать

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

А с макс размером файла х.з. Надо читать. Пока я тут не видел пруфоф на документацию .

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

Тогда сперва встаёт задача определить, есть ли на данной платформе прерывания или нет

Вы какие-то максим планки берете. Хоть Ось (ПРО-ДОС), тут нормально работает?

[Error404]

Сорцы то открыты СПМ2.2, зачем их дизассемблировать?

Сорцы Килдалла - на PLI (это язык подремучее фортрана-77), одно дело в тех сорцах разбираться глаза сломаешь, другое - что уже и скомпилировать это хрен знает чем (даже если найдешь чего править). А ассемблерное всеми получалось дизасмом, понятно какая там степень комментирования и вообще читаемости. Самое правильное - разобраться в ассемблерном, я примерно сегодня уже нашел где, но с наскока не выйдет, надо вникать.

Дальше ничего не понял. Подпрограмма (разрядность вх. параметров), позволяет читать более 512КБ?

Программа в которой ограничение до 512кб - там вообще только один параметр: имя файла (открываешь его по имени, затем read_next-read_next-read_next-.....until_eof). Только вот EOF подпрограмма read_next в непатченной 2.2 возвращает не по концу файла (большого), а по границе в 512кб.

А с макс размером файла х.з. Надо читать. Пока я тут не видел пруфоф на документацию .

Макс. размер файла 32мб, макс. размер файловой системы - 512мб. Там есть ньюансы (чем больше ФС, тем больше под нее нужно места в ОЗУ под хранение битовой карты занятых блоков), но если есть вагон ОЗУ которого под это не жалко - все возможно.