|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
Author |
Message |
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Продолжение темы о ПО данного "маленького компа" вот отсюда. Не понимаю как можно применить процедуры чтения/записи целого файла при адаптации CP/M на другое железо Адаптация CP/M под конкретное железо заключается в основном в написании всего двух подпрограмм низкого уровня в CP/M-BIOS. Это считать и записать логический блок размером в 128 байт. В случае сетевой DOS даже не требуется писать так называемую процедуру деблокирования (чтение в дисковый буфер физического сектора или целого CP/M-блока, поиск в буфере и пересылка на DMA участка в 128 байт), а достаточно написать только подпрограмму запроса и приёма из линии прямо на DMA нужного логического блока в 128 байт и передачу в линию из DMA такого же логического блока. Со стороны сетевого сервера Вам не надо иметь BDOS, а надо иметь доступ к массиву секторов по 128 байт любой природы. Это может быть как ОЗУ, так и физический носитель, - файл размером в размер диска (образ диска). Можно сразу использовать формат образа диска CP/M ОРИОНА. А я делал образ состоящий из множества файлов, каждый из которых представляет CP/M-трек. CP/M допускает до 255 лог.секторов в треке (т.е до 31 кб в треке). Это удобнее тем, что размер диска можно держать минимальным и при нужде очень просто увеличить размер диска. Большие диски не выгодны, т.к растёт размер требуемых буферов, отчего сокращается уровень TPA и быстро падает скорость работы, особенно если скорость чтения/записи секторов невелика. Работа с фрагментированным на файлы-треки образом диска происходит быстрее, чем с одним гигантским файлом. Еще одним плюсом разбиения образа диска на файлы-треки является возможность буквально за полчаса написать сервер обслуживания сетевой DOS на бейсике-компиляторе (Power Basic, Quick Basic и т.п). Бейсик не работает с данными больше, чем в 64 кб, потому файл с размером в 31 кб удобно читается в массив целых. Вот так: Здесь файл размером в 31 кб читается стандартными единицами обмена по 128 байт и запаковывается в массив целых, с которым бейсику удобно работать. А на Паскале и Си, где нет никаких ограничений на размер массива и тип его компонент, написать сервер выполняющий чтение (запись) с винчестера фрагментов по 128 байт и их передачу (и приём) с линии ещё проще.
|
10 May 2018 12:26 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Я поначалу тоже решил так поступить. Но нужно-было найти какй-то подходящий образ, а потом его настроить под конкретную карту памяти. А потом: Допустим у нас есть 8-и разрядный сферический конь (прога для i8080). Каким-то способом закидываем прогу в образ. Так-же кидаем туда (в образ) данные. Запускаем нашего коня - получаем результаты. Каким-то похожим способом вынимаем результаты с образа... В предыдущей ОС я поступил очень просто: ОС ничего не знает о треках, секторах и чего-то еще в этом роде. Есть файл, которые можно открыть, прочитать... При открытии файла на сервер передается имя файла, а возвращается какой-то идентификатор, понятный серверу. Для остальных операций мы передаем серверу этот идентификатор. А потом передаем или принимаем данные. Что-то похожее хочу сделать в CP/M. Поэтому BDOS приходится довольно сильно править. В дальнейшем его скорее всего придется переписать заново. Надо придумать в каком месте FCB хранить идентификатор полученный от сервера.
|
10 May 2018 18:24 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Ну вот - в первом приближении чтой-то получилось... Работает TYPE и DIR. Запускаются (но не совсем работают) транзитные программы (правда пока небольшие по размеру) - не реализовано создание/запись файла. Оказывается чтение файла должно возвращать 0 - если все нормально, 1 - если конец файла, FF - если ошибка... И столкнулся с такой проблемкой - если файл открыть, и из него только читать, то его можно не закрывать (как написано в доке CP/M), а как передать серверу что файл больше не нужен - пока идей нет. Поэтому TYPE или запуск транзитной программы можно выполнить только один раз... До перезапуска сервера...
|
15 May 2018 19:54 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
А я вообще не вижу проблемы. Зачем оставлять открытым файл на стороне сервера? При открытии файла на чтение всё его содержимое должно грузиться в буфер, а дисковый файл должен закрываться. Потому, если на строне 8-ми разрядки файл не закрыли, это не играет роли. При открытии очередного файла он тоже загрузится в буфер. Но задача решается, даже если файл открыт и не закрыт на стороне сервера. Нужно только как-то получать информацию о том, что файл больше не нужен. Лобовая идея - это использовать тайм-аут. Если файл открыт на чтение, и, допустим, 15 секунд не было вызовов подпрограммы READ в CP/M-BIOS, то файл следует закрыть. А также можно использовать идею Pyk по эмуляции МГ-ввода из его эмулятора. Там файл открывается по первому вызову стандартной п/п-ммы LDBYTE и считывается в буфер ввода. И все последующие вызовы п/п-ммы LDBYTE выдают очередной байт из этого буфера. Конец ввода определяется по вызову п/п-ммы CONIN ROM-BIOS-а. Таким образом, даже если пользователь прервал ввод (например, на Специалисте нажав функц.клавишу) и из буфера считались не все байты МГ-записи, по выходу в монитор будет вызвана п/п-мма CONIN и произойдёт досрочное "закрытие файла". В противном случае, если файл не закрыть, то при вводе следующего файла происходило бы дочитывание не до конца загруженного первого файла, а не открытие нового. Чтобы использовать эту идею, функция BDOS открытие файла на стороне 8-ми разрядки должна ставить флаг. Который установлен пока файл не закрыт. А при вызове п/п-ммы CONIN и наличии установленного флага открытия файла к серверу должно уходить сообщение о том, что открытый файл больше не нужен и его можно закрыть (а флаг, естественно, сбрасывается). Насколько я понял у Вас сервер эмулирует не подпрограммы низкого уровня из BIOS, а дисковые функции BDOS. Но это же невыгодно, т.к теряется совместимость. Многие программы работают с каталогом диска напрямую процедурами BIOS, считывают Allocation Table (отчего такие CP/M-программы и не работают в TSR-эмуляторах на MSDOS, т.к нет каталога в CP/M-формате и Allocation Table). Идея хранения файлов одной файловой системы на носителе с форматом другой системы вполне применима. Например, когда-то я хотел сделать для ОРИОНА DOS, файлы которой хранились бы в формате ORDOS в квазидисках. Это может быть очень простая DOS, например, с LOAD, SAVE только целыми файлами, но в ней, в отличие от ORDOS, нет кучи мелких квазидисков, а есть один большой диск из излишнего ОЗУ, включающий и R/O файлы ROM-диска, и дисковод. А при желании функции BDOS можно на 90% совместить с CP/M, причём формат файлов в квазидисках останется ордосовским. Это позволит в такой DOS использовать как ORDOS-программы, так и некоторое число CP/M-программ, а также писать программы, которые будут работать и в данной DOS и в CP/M.
|
16 May 2018 02:29 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Да, наверное примерно так и поступлю - как только файл весь прочитался - его можно закрывать. Да именно так устроено.
|
16 May 2018 20:51 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Ну вот появилось немного свободного времени... Немного подделал BDOS и сервер. Сейчас к серверу подключается Proteus (com0com) и emu (tcp). Могут работать одновременно. Идентификатор файла, полученный с сервера хранится в 15-ом байте FCB CP/M. (CCP его не меняет, что с ним делают другие программы пока неизвестно). При открытии/закрытии/поиске файла этот байт проверяется и файл принудительно закрывается. Таким образом избавился от необязательности закрытия файла, если он только читается. В emu все работает в несколько раз быстрее чем в Proteus. Но в протеус можно отлаживать в исходниках. Сейчас работают все команды CCP. В emu M80 грузится примерно 20 сек. Конфигурация Партнер 01.01, карта памяти 060h (свободной памяти 40Кб). Насколько это достаточно для M80, C80, L80? Сервер пока может работать только с одним файлом. Буду расширять до 5-10, наверное для начала хватит? Позже будет динамически. Сейчас в CP/M доступен только один диск, переназначенный на сервер. На сервер для файловых операций передается только имя файла. Наверное стоит перед именем файла передавать еще какой-то идентификатор (типа имени диска CP/M), а на сервере сделать таблицу соответствия этих идентификаторов конкретным дискам/каталогам (типа точки монтирования)?
|
15 Aug 2019 22:04 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Байты со смещением 12...15 в FCB и экстентах используются самой CP/M, программы туда вообще не имеют привычки лазить. Хотя в каталоге экстенты некоторые программы просматривают, чтобы так узнать размер файла. Не указано какой М80 (они имеют разные размеры), но у вас получилась скорость лишь в ~4 раза быстрее, чем с магнитофона. Если CP/M-компилятор ЯВУ транслирует программу 3 минуты, то в вашей системе это займет многие часы. Кстати, распространены вот такие версии М80: MACRO-80 3.36 17-Mar-80 MACRO-80 3.4 01-Dec-80 MACRO-80 3.44 09-Dec-81 MSX_M-80 1.00 01-Apr-85 и все они в оригинале сбрасывают старший бит в текстах (потому для русских текстов надо использовать кракнутые). Последняя версия поддерживает ключ .6502, что позволяет транслировать программу для Apple-II с двумя процессорами. Непонятно, что Вы имеете ввиду под термином "свободная память". Есть понятия - память что есть в данной машине для программ (это объём ОЗУ в банке минус экран и минус сист.ячейки ROM-BIOS) и TPA, что обычно на ~7-8 кб меньшая (сколько ОЗУ отнимает CP/M зависит от размера CP/M-BIOS и размеров дискового буфера для чтения физического сектора и CP/M-буферов). Обычно говорят CP/M-36K (ОРИОН в банке 0), CP/M-44К (Apple-II) или CP/M-51K (ОРИОН в банке 1 или 2), цифрой указывая размер TPA. Про C80 не слышал, а M80 и L80 и вообще всем ассемблерам достаточно и 20 кб, просто чем меньше ОЗУ, тем активнее будет дисковый свопинг и трансляция будет длиться дольше. А вот для большинства ЯВУ и многих деловых программ даже TPA в 40 кб будет мало. Тоже непонятно, что имеется ввиду. Число одновременно открытых файлов или максимальное число файлов на диске. Если число открытых файлов, то обычно CP/M-программы (если не считать SuperText) не открывают более двух файлов сразу. А если речь о числе файлов на диске, то это зависит от задачи. Если просто запустить что-то посмотреть, то хватит. А для компиляторов вряд-ли. Они обычно имеют размер от 150 до 350 кб и состоят из десятка файлов оверлеев и библиотек. А ещё при работе они создают обычно несколько своих временных файлов (например, PLMX в ходе трансляции создаёт 4 своих временных файла, удаляя их по завершении трансляции) и ещё файлами надо считать файлы исходника и выходной файл компилятора. А вообще у Вас производится эмуляция CP/M и значит будут те же проблемы несовместимости, что и при эмуляции функций CP/M функциями MSDOS. Чтобы работали все программы надо эмулировать и структуру каталога и иметь или имитировать Allocation Table. Allocation Table некоторые программы используют, чтобы узнать есть ли на диске свободное место. Это можно узнать или очень долгим способом, запрашивая размеры каждого файла в каждом юзере и суммируя их, а затем вычтя полученную сумму из размера диска из DPB или просто посчитать нулевые биты (показывающие свободные группы) в Allocation Table. Потому, чтобы получился нормальный эмулятор CP/M, а не полуфабрикат, надо не имитировать работу CP/M, а прогонять её родной код, т.е имитировать надо не DOS, а носитель.
|
17 Aug 2019 05:01 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
>>Байты со смещением 12...15 в FCB и экстентах используются самой CP/M Я искал этот байт для хранения идентификатора файла сервера. До 15 байта CCP чистит. А дальше начинается имя файла для функции переименования файла. >>Непонятно, что Вы имеете ввиду под термином "свободная память". Это реальная свободная память. Карта памяти 60h - это 40Кб ОЗУ потом 8К ПЗУ (где и находится собственно система) потом 12К снова ОЗУ а потом устройства и монитор. Во второй области ОЗУ организована экранная память и все остальное. Наверное в начало 40кб ОЗУ надо будет копировать примерно 10 байт начала BDOS? >>А если речь о числе файлов на диске, то это зависит от задачи. >> Если просто запустить что-то посмотреть, то хватит. Имеется в виду ко-во открытых файлов в программе. У меня этот вопрос возник по причине необязательности закрытия файлов. Наверное нужно будет при горячем старте отправлять на сервер что-то похожее на RstDsk (сброс дисковой системы)? >>А вообще у Вас производится эмуляция CP/M и значит будут те же проблемы >> несовместимости, что и при эмуляции функций CP/M функциями MSDOS Несовместимость будет проялявляться при использовании системных утилит типа STAT (надо будет попробовать). XDIR выдает, что все файлы размером в 4К (наверное у меня корявый BIOS, не помню откуда взял исходный, и он был для z80). >>Потому, чтобы получился нормальный эмулятор CP/M, а не полуфабрикат, >> надо не имитировать работу CP/M, а прогонять её родной код, >> т.е имитировать надо не DOS, а носитель. Да вот я хочу иммитировать именно DOS. В случае иммитации носителя будут нужны какие-то утилиты для обмена данных с этим носителем (они в принципе существуют).
Операционка в принципе у меня есть, некоторые идеи в ней были использованы из RT-11. Но ест-но ни с чем не совместимая. Решил на основе ее сделать эммуляцию CP/M, но надо как-то проверить что все работает правильно. В процессе экспериментов по разгону ВВ51 вся флэшка (AT28C64) по..сь. Надо будет поставить кнопочку защиты записи. И записать туда что-то более продвинутое.
|
17 Aug 2019 20:25 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
А какая операционка, что-то взято за основу или просто полностью самописная?
_________________ iLavr
|
18 Aug 2019 04:43 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Полностью самописная. В свое время не успел наиграться с RT-11 и нарисовал свое (по мотивам). Мне у этой ос (RT-11) нравилась полная асинхронность: Файловые операции можно было выполнять в 3-х видах: просто ждать завершения не ждать завершения (потом вызвать функцию для проверки состояния) по окончании вызвать свою функцию В обаботчике прерываний мжно было снова разрешить прерывания, и поставить в очередь свой код для завершения обработки.
|
18 Aug 2019 15:27 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
То есть вы адаптировали "вкусные" моменты RT-11 под другой процессор? RT-11, насколько я помню, дековская под PDP-11...
_________________ iLavr
|
18 Aug 2019 18:03 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Все с нуля. Просто использовались эти идеи.
|
18 Aug 2019 18:19 |
|
|
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
|
Ну вот, странслировалась программа примерно на 130 строк микродосовским ассемблером. На это дело ушло примерно 30 сек. Линкера не мерил. Главное, что оно заработало...
|
20 Aug 2019 02:41 |
|
|
Who is online |
Users browsing this forum: No registered users and 1 guest |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|