Как получить CP/M для своего железа

[Shaos]

Как тяжело портировать на что-то ещё?

P.S. Партнёр надо бы в РК-86 переместить, нет?

[aav8]

Как тяжело портировать на что-то ещё?

P.S. Партнёр надо бы в РК-86 переместить, нет?

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

Нет - перемещать не надо - эта ветка про CP/M,
а у меня есть Партнер. Заодно и драйвер
карточки сделал.

[barsik]

SUBMIT так и не заработал

Если МНИП, SUBMIT работает с оригинальным CCP и BDOS. XSUB тоже. BDOS не смотрел, но ваш CCP похоже не оригинал (в оригинале идут 2 JMP-а, затем буфер ввода, а у вас после двух JMP-ов сразу какой-то программный код.

Возможно эти сделанные американским любителем исходники CCP и BDOS из какого-то американского компьютера у которого в дистрибутив входили свои SUBMIT, XSUB и MOVE (который тоже кстати жёстко привязан к конкретному коду CCP и BDOS, т.к при перемещении кодов на другие адреса корректирует адреса всех переходов). Если изменить хоть байт в оригинальном CCP или BDOS, то MOVE перестаёт работать.

И зачем в исходнике постоянно чередовать сегменты данных и кода? Например, уже в первом же фрагменте CCP стоит процедура, причём открытая (т.е не оканчивающаяся RET-ом или JMP-ом) с указанием конца сегмента, а далее блок DS-ов для переменных параметров и раб.ячеек, затем снова продолжение кода. Компилятор конечно сгруппирует одноимённые сегменты вместе, но смотреть такой листинг неудобно.

И зачем так сложно транслировать CP/M (из более, чем 20-ти файлов). Достаточно 4-х файлов кода - стартёр и 3 стандартных для CP/M модуля: CCP, BDOS и BIOS. Плюс файл макро-определений (обычно MACRO.INC) и для гибкости в роли HEADER-а - INCLUDE-файл, который подставляется в каждый модуль и задаёт все глобальные параметры (чтобы менять их приходилось только в одном месте, а не во всех отдельно транслируемых файлах). Из make-файла видно насколько убог инструментальный пакет AVSIM85/AVLINK. CP/M-компилятор Microsoft M80/L80 освобождает от 80% этих операций (для M80, чтобы работал TSR-эмулятор CP/M надо иметь Win XP).

Не нашёл в вашем коде исходника драйвера VT52 для Партнёра. Вряд-ли он в вашем Партнёре уже прошит в ROM-BIOS-е (а загрузить внешний драйвер не удастся, если не предусмотрены вектора для его загрузки в CP/M-BIOS или ROM-BIOS). А без VT52 не будут работать экранные программы, даже повсеместный WM.COM для редактирования текстов. А используя строчный редактор ED.COM, у Вас возникнет желание повеситься уже через 10 минут его использования.

И, естественно, поимев CP/M для какого-то железа, первым делом пишется нортон. Который, кстати, можно писать корректно, т.е без залезания в железо используя только вызовы CP/M-BDOS и CP/M-BIOS или не корректно (тогда, естественно, можно лезть программой прямо в экран, иметь цвет, сканировать матрицу клавиш напрямую через ППА, выводить музыку через ВИ53, лезть программой прямо в дисковый привод и т.п).

[aav8]

Если МНИП, SUBMIT работает с оригинальным CCP и BDOS.

Скорее всего так оно и есть.
CCP и BDOS я подстраивал, чтоб псе работало сразу в ПЗУ.
А для SUBMIT часть данных вытащил перед ПЗУ - но не прокатило...

И зачем в исходнике постоянно чередовать сегменты данных и кода?

Мне это кажется очень удобным - код и рядом с ним описаны данные для этого кода.
А если нужен отдельный код инициализации - его можно пихнуть в отдельный сегмент.
Который тоже будет рядышком описан.
Линкер все это перетасует как надо.

И зачем так сложно транслировать CP/M (из более, чем 20-ти файлов).

Это мои добавки... Редактировать файлы на несколько тысяч строк не очень удобно.

Не нашёл в вашем коде исходника драйвера VT52 для Партнёра.

Пока с этим и не заморачивался.

[aav8]

вот получилось сделать диск B: типа сетевой.
можно без проблем копировать файлы между дисками.
конечно первым делом запустил M80 для файла ~20К.
время на трансляцию (сетевое устройство) ушло примерно 1м40сек.
тот-же самый файл на карточке обработался за 1м30сек.
конечно примерно.
MBASIC не захотел работать на сетевом устройстве.
он использует запросы произвольного доступа к файлам, которые я еще и не делал.
на карточке (где файловая система CP/M) все работает ok'.
так-же и SUBMIT (точнее $$$.sub) нормально работает
на файловой системе CP/M.
CCP в пакетном режиме конкретно лезет в FCB и правит байты s1 s2.
Заодно нашел косячек (а может недоработку) в SUBMIT.COM.
Файл $$$.SUB создается на выбранном диске а не диске A:,
откуда он должен запускаться.
... примерно вот-так...
будем копать дальше

[barsik]

SUBMIT (точнее $$$.sub) нормально работает на файловой системе CP/M.

Если МНИП, SUBMIT работает с оригинальным CCP и BDOS.

Скорее всего так оно и есть.

Не совсем так. Я имел ввиду, что связка SUBMIT-XSUB работает лишь при стандартном коде CCP и BDOS. А SUBMIT-у отдельно без разницы код CCP и BDOS. SUBMIT просто создаёт файл, представляющий собой нарезку строк командного файла с шагом в 128 байт. А вот XSUB уже лезет в код DOS, делая перехват ввода при работе программ.

CCP в пакетном режиме конкретно лезет в FCB [файла $$$.SUB] и правит байты s1 s2.

Так он укорачивает файл на 128 байт, потому что строки в файле $$$.SUB нарублены в обратном порядке. Не намного сложнее было бы использовать нормальный текстовый формат и сдвигать при обработке текст на одну строку. Это у них пережиток от ранних версий, что должны были работать при ОЗУ 16К, отчего обязательно требовалось уместить CCP в 2 кб.

Заодно нашел косячок (а может недоработку) в SUBMIT.COM. Файл $$$.SUB создается на выбранном диске, а не диске A:, откуда он должен запускаться.

Это уже левизна, точнее исправление левизны оригинала. Оригинальный SUBMIT как раз и создавал $$$.SUB всегда на диске A:. Что невыгодно из соображений дискозапильности. В частности, при использовании SUB-механизма для автонастройки DOS при загрузке, что есть в развитых адаптациях CP/M (обычно есть обработка файла PROFILE.SUB, например, так в ОС SCP Роботрона-1715). Также в ранних версиях адаптаций CP/M для ОРИОНА обслуживание файла AUTOEXEC.SUB при загрузке DOS делалось традиционно по CP/M-овски с использованием SUB-механизма.

Для чего стартовый модуль CP/M считывал с дискеты файл AUTOEXEC.SUB, из него создавал файл $$$.SUB и записывал его на диск A:. Это приводило к дискозапильности дискет и у системной дискеты нельзя было заклеить прорезь защиты от записи. А любая запись чревата дохлотой, т.к переписывается каталог.

Из этого был выход лишь, если в системе был эл.диск и была возможность назначить его диском A:. Или, если в DOS не предусмотрена возможность эл.диск переназначить на A:, то достаточно изменить CCP, чтобы искал $$$.SUB на другом диске или на текущем диске (а более грамотно, чтобы искал сначала на диске A:, потом на B:), соответственно изменяется и SUBMIT. Такие трюки позволяли использовать SUB-механизм не запиливая системную дискету, так что в ней можно было заклеить прорезь защиты от записи.

Позднее я отказался от ретро методов обслуживания командных файлов, чтобы совсем не было записи на дискету. Для этого в поздних адаптациях CP/M я применял тимплет и автозамену консольных кодов. Тимплет символов это буфер в который можно загрузить текст. И при чтении с консоли этот текст будет последовательно выдаваться строка за строкой. А автозамена кодов полезна не только, чтобы нажатием одной (например функциональной) клавиши выдавать ключевые команды (также как в SCP настраиваемые пользователем), но это заменяло XSUB.

А сама XSUB CP/M у меня никогда не работала.

PS. При оценке быстродействия обмена с диском по времени трансляции информативнее сравнение с временем трансляции на реальном DD-дисководе. Сетевой диск в CP/M это круто. Возможно это даже впервые в России.

[aav8]

А подскажите/напишите/посоветуйте/а может уже есть/или сам нарисую
некий тест для ОС CP/M
что-бы можно было проверить все основные вызовы системы.
Особенно файловые операции.
Есть мысля, файловую систему CP/M вынести в отдельный модуль.
А в самой ОС оставить только ОС.
А собственно файловые системы сделать как подключаемыми модулями.
Планирую ОС чисто сетевую - т.е. все файлы будут на сервере.
И хочется добиться 90++ совместимость со стандартной ОС.
В принципе оно все работает (сервер немного попозже выложу).
И пока все влезает в 8К (7989 байт).
CCP ~ 1800 байт
BDOC ~ 3000 байт
Если из системы убрать все не сильно нужное все поместится в 4К.
Или даже в 2
И диски пилиться не будут

[barsik]

А подскажите/напишите/посоветуйте/а может уже есть/или сам нарисую некий тест для ОС CP/M, что-бы проверить все основные вызовы системы.

Вряд-ли у кого из любителей отечественных ретро-компов была такая задача. Но текстовые редакторы, базы данных и компиляторы ассемблера и ЯВУ используют большинство функций BDOS и некоторые функции CP/M BIOS (в BIOS рекомендуется не лезть без нужды). BIOS вызывают программы работающие низкоуровнево (те, что используют альтернативный ввод/вывод, тестируют диски или лезут в каталог посекторно) и есть несколько задач DOS, которые или без вызовов п/п-м BIOS вообще не решить или так получается проще или быстрее. При тестировании DOS надо имитировать и дохлоту. Обработку дисковых ошибок (4 вектора ошибок на BDOS+3) сохранили? Почти все профессиональные программы подменяют процедуры обработки ошибок на свои.

Похоже реализация сетевого диска родственна эмуляции дискеты в эмуляторах CP/M. В эмуляторах CP/M для MSDOS почти всем функциям CP/M находятся аналоги в MSDOS. Кроме доступа к Allocation Table (таблице занятости блоков), которой в MSDOS нет. А в эту таблицу как-раз лезут грамотные программы, которым перед записью файла хочется узнать, что на диске ещё есть место для его записи. И проще всего это проверить посмотрев число свободных блоков в Allocation Table.

Альтернатива этому (хотя и совместимая с эмуляторами, но тормозная) - это сканировать каталог и суммировать размеры всех файлов и (зная из параметра в DPB размер всего диска в блоках) высчитать сколько блоков свободно на диске. И даже эта задача быстрее решается низкоуровнево - каталог быстрее сканируется функциями BIOS, а не BDOS (это в реале получается раз в пять быстрее). А т.к в плохих эмуляторах для MSDOS нет эмуляции каталога CP/M со всей его структурой, то в таких эмуляторах вполне грамотные CP/M-программы не работают. Это я к тому, что в сетевом диске лучше повторять структуру CP/M-диска, а не хранить файлы как-то иначе.

Есть мысля, файловую систему CP/M вынести в отдельный модуль. А в самой ОС оставить только ОС. А собственно файловые системы сделать подключаемыми модулями.

Не ясно о чём речь. Может быть под "только ОС" имеются ввиду лишь те функции BDOS и те п/п-ммы BIOS, что работают с дискетой. Т.е "в самой ОС" останутся только консольные функции BDOS и консольные п/п-ммы BIOS. А если речь о вынесении в отдельный модуль аппаратозависимых процедур, так они в CP/M вроде бы и так отделены в CP/M BIOS (или Вы это изменили смешав в своей реализации код BDOS и код процедур низкого уровня вместе?).

 мысли на тему

.
Вообще, т.к дискеты почти исчезли, идея использования в качестве диска и его контроллера интеллектуального внешнего устройства актуальна. Да и хлопотно делать КНГМД, тогда как для квази-сетевого диска достаточно лишь решить проблему скоростного интерфейса. Кстати, совершенно не обязательно использовать CP/M, удобнее для этих целей как раз своя DOS (транслировать всё-равно удобнее на PC кросс средствами или в эмуляторах, а по всему остальному любая другая DOS может не хуже решать задачи хранения и запуска программ).

Такая концепция имеет плюсом то, что DOS не требуется хранить на ретро машине, что выгодно потому что DOS обычно отнимают 8-10 кб памяти (что не позволяет запустить программу размером со всё ОЗУ, а лучшие программы обычно занимают всё ОЗУ). А также это выгодно потому, что тогда дисковод это полностью внешнее устройство и т.о может подключаться к бытовому компьютеру изначально не рассчитанному на расширение. Дисковод в Commodore-64 (и во всех остальных их компьютерах) не встраивался вместе с КНГМД внутрь машины, а по последовательной линии подключался к дисководному блоку, где было своё МП-ядро на 6502. И DOS работала в этом МП-ядре. А на Commodore-64 в ОЗУ был лишь крошечный CCP, который принимал с клавиатуры команды и транслировал их в дисковый модуль. От этого на нужды DOS тратилось мало ОЗУ (что позволяло загрузить программу размером со всё ОЗУ), но скорость обмена у них получилась низкой.

К сожалению, в IBM PC теперь не ставят ни последовательного, ни параллельного интерфейсов, лишь USB. Потому для не особо фанатичных любителей удобно было бы поиметь DOS для ретро-ЭВМ на базе ненужного мобильного телефона. Т.к полоса AUDIO до 20 КГЦ, а ошибки из-за дефектов механники и носителя вообще отсутствуют, то даже используя МГ-интерфейс, в частности двухфазный МГ-формат, можно поднять скорость обмена в 5 и более раз. Скорость обмена 1-2 кб в секунду многих удовлетворит. Проблема в том, что кто-то должен написать соответствующую DOS для телефона/планшета (для Android, можно и для Windows Mobile, - у меня есть ненужные устройства с обоими OS). Сам я сделать это не могу. Если такое сделать, то это стало бы самым нехлопотным способом решения проблемы загрузки программ в ретро-ЭВМ.

Другим существенно более хлопотным, зато уже реализованным вариантом этого является использование контроллеров для карточек памяти micro-SD. Увы, на CP/M авторам разработок было наплевать, потому это реализовано в виде готового нортона для конкретной ретро-машины, а не в виде контроллера с блоком п/п-мм низкого уровня (что позволило бы использовать контроллер для своих целей, в частности позволило бы совсем нехлопотно и однообразно для всех ретро-машинок ставить на них CP/M).
.

[aav8]

Обработку дисковых ошибок (4 вектора ошибок на BDOS+3) сохранили?

Да, конечно. Стараюсь добиться максимальной совместимости.

А если речь о вынесении в отдельный модуль аппаратозависимых процедур, так они в CP/M вроде бы и так отделены в CP/M BIOS (или Вы это изменили смешав в своей реализации код BDOS и код процедур низкого уровня вместе?).

Да примерно так и есть.
Т.е. получается не драйвер устройства, которое умеет читать/писать
сектора, а более интелектуальное устройство, которое умеет работать с файлами.
А как устроены файлы система не знает.
Такая ОСь у меня была в начале века.
Занимала всего примерно около 3-х К. И конечно ни с чем не совместимая.
А сейчас запускается basic, fortran, а вот ada компилить
на сетевом диске не хочет (а на карточке все нормально) - может
конечно у меня какой-то косяк с сервером. Только вчера вечером попробовал.
Наверное самое идеальное в качестве устройства использовать
какой-нибудь PIC с PSP и на него переложить все файловые функции.
... примерно такие мысли ...

PS:

Вот и ADA заработала - на сервере не хватало файлов...

[aav8]

прикрутил свою CP/M к РК86 (вместо ВВ55 прописал В51).
почистил BDOS.
Все влезло в чуть больше 4K.
Довольно сносно работает (M80) - 700 строк за примерно минуту.
MBASIC сказал что всего свободно 482 байта.
Можно еще сократить почти в 2 раза - сделать CCP выгружаемым...