Маленький комп.

Микропроцессоры и микроконтроллеры от фирмы Zilog, а также компьютеры на них построенные

Moderator: Shaos

User avatar
barsik
Doomed
Posts: 585
Joined: 19 Feb 2017 03:46
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь

Post by barsik »

Продолжение темы о ПО данного "маленького компа" вот отсюда.

Не понимаю как можно применить процедуры чтения/записи целого файла при адаптации 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 кб удобно читается в массив целых. Вот так:

Code: Select all

DIM DAT%(31 * 512)
. . . . 
OPEN "R", #2, FILNAME$
        FIELD #2, 128 AS BUFFER$:
        FOR S = 0 TO 31 * 4 - 1
          GET #2, S + 1
          FOR I = 0 TO 127
            Y$ = MID$(BUFFER$, I + 1, 1)
            DAT%(S * 128 + I) = ASC(Y$)
          NEXT I
        IF EOF(2) <> 0 GOTO LOADED
        NEXT S
LOADED:
Здесь файл размером в 31 кб читается стандартными единицами обмена по 128 байт и запаковывается в массив целых, с которым бейсику удобно работать.

А на Паскале и Си, где нет никаких ограничений на размер массива и тип его компонент, написать сервер выполняющий чтение (запись) с винчестера фрагментов по 128 байт и их передачу (и приём) с линии ещё проще.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re:

Post by aav8 »

barsik wrote:Адаптация CP/M под конкретное железо заключается в основном в написании всего двух подпрограмм низкого уровня в CP/M-BIOS. Это считать и записать логический блок размером в 128 байт.
Я поначалу тоже решил так поступить.
Но нужно-было найти какй-то подходящий образ, а потом его настроить под конкретную карту памяти.

А потом:
Допустим у нас есть 8-и разрядный сферический конь (прога для i8080).
Каким-то способом закидываем прогу в образ.
Так-же кидаем туда (в образ) данные.
Запускаем нашего коня - получаем результаты.
Каким-то похожим способом вынимаем результаты с образа...

В предыдущей ОС я поступил очень просто:
ОС ничего не знает о треках, секторах и чего-то еще в этом роде.
Есть файл, которые можно открыть, прочитать...
При открытии файла на сервер передается имя файла, а возвращается какой-то идентификатор,
понятный серверу. Для остальных операций мы передаем серверу этот идентификатор.
А потом передаем или принимаем данные.

Что-то похожее хочу сделать в CP/M. Поэтому BDOS приходится довольно сильно править.
В дальнейшем его скорее всего придется переписать заново.
Надо придумать в каком месте FCB хранить идентификатор полученный от сервера.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

Ну вот - в первом приближении чтой-то получилось...
Работает TYPE и DIR.
Запускаются (но не совсем работают) транзитные
программы (правда пока небольшие по размеру) - не реализовано создание/запись файла.
Оказывается чтение файла должно возвращать 0 - если все нормально, 1 - если конец файла,
FF - если ошибка...
И столкнулся с такой проблемкой - если файл открыть, и из него только читать,
то его можно не закрывать (как написано в доке CP/M), а как передать серверу
что файл больше не нужен - пока идей нет.
Поэтому TYPE или запуск транзитной программы можно выполнить только один раз...
До перезапуска сервера...
User avatar
barsik
Doomed
Posts: 585
Joined: 19 Feb 2017 03:46
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь

Re: Маленький комп.

Post by barsik »

aav8 wrote:столкнулся с проблемкой - файл открываемый на чтение не закрывают... как передать серверу, что файл больше не нужен - пока идей нет.
А я вообще не вижу проблемы. Зачем оставлять открытым файл на стороне сервера? При открытии файла на чтение всё его содержимое должно грузиться в буфер, а дисковый файл должен закрываться. Потому, если на строне 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.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

barsik wrote:При открытии файла на чтение всё его содержимое должно грузиться в буфер, а дисковый файл должен закрываться.
Да, наверное примерно так и поступлю - как только файл весь прочитался - его можно закрывать.
barsik wrote:Насколько я понял у Вас сервер эмулирует не подпрограммы низкого уровня из BIOS, а дисковые функции BDOS. Но это же невыгодно, т.к теряется совместимость.
Да именно так устроено.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

Ну вот появилось немного свободного времени...
Немного подделал 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), а на
сервере сделать таблицу соответствия этих идентификаторов
конкретным дискам/каталогам (типа точки монтирования)?
User avatar
barsik
Doomed
Posts: 585
Joined: 19 Feb 2017 03:46
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь

Re: Маленький комп.

Post by barsik »

aav8 wrote:хранится в 15-ом байте FCB CP/M. (CCP его не меняет, что с ним делают другие
программы пока неизвестно).
Байты со смещением 12...15 в FCB и экстентах используются самой CP/M, программы туда вообще не имеют привычки лазить. Хотя в каталоге экстенты некоторые программы просматривают, чтобы так узнать размер файла.
aav8 wrote:В emu M80 грузится примерно 20 сек
Не указано какой М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 с двумя процессорами.
aav8 wrote:свободной памяти 40Кб... Насколько это достаточно для M80, C80, L80?
Непонятно, что Вы имеете ввиду под термином "свободная память". Есть понятия - память что есть в данной машине для программ (это объём ОЗУ в банке минус экран и минус сист.ячейки 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 кб будет мало.
aav8 wrote:Сервер пока может работать только с одним файлом. Буду расширять до 5-10, наверное для начала хватит?
Тоже непонятно, что имеется ввиду. Число одновременно открытых файлов или максимальное число файлов на диске. Если число открытых файлов, то обычно CP/M-программы (если не считать SuperText) не открывают более двух файлов сразу.

А если речь о числе файлов на диске, то это зависит от задачи. Если просто запустить что-то посмотреть, то хватит. А для компиляторов вряд-ли. Они обычно имеют размер от 150 до 350 кб и состоят из десятка файлов оверлеев и библиотек. А ещё при работе они создают обычно несколько своих временных файлов (например, PLMX в ходе трансляции создаёт 4 своих временных файла, удаляя их по завершении трансляции) и ещё файлами надо считать файлы исходника и выходной файл компилятора.

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

Потому, чтобы получился нормальный эмулятор CP/M, а не полуфабрикат, надо не имитировать работу CP/M, а прогонять её родной код, т.е имитировать надо не DOS, а носитель.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

>>Байты со смещением 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) по..сь.
Надо будет поставить кнопочку защиты записи. И записать туда что-то
более продвинутое.
User avatar
Lavr
Supreme God
Posts: 16689
Joined: 21 Oct 2009 08:08
Location: Россия

Re: Маленький комп.

Post by Lavr »

aav8 wrote:Операционка в принципе у меня есть, некоторые идеи в ней были использованы
из RT-11. Но ест-но ни с чем не совместимая.
А какая операционка, что-то взято за основу или просто полностью самописная?
iLavr
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

Полностью самописная.
В свое время не успел наиграться с RT-11 и нарисовал свое (по мотивам).
Мне у этой ос (RT-11) нравилась полная асинхронность:
Файловые операции можно было выполнять в 3-х видах:
просто ждать завершения
не ждать завершения (потом вызвать функцию для проверки состояния)
по окончании вызвать свою функцию
В обаботчике прерываний мжно было снова разрешить прерывания,
и поставить в очередь свой код для завершения обработки.
User avatar
Lavr
Supreme God
Posts: 16689
Joined: 21 Oct 2009 08:08
Location: Россия

Re: Маленький комп.

Post by Lavr »

aav8 wrote:Полностью самописная.
В свое время не успел наиграться с RT-11 и нарисовал свое (по мотивам).
То есть вы адаптировали "вкусные" моменты RT-11 под другой процессор?
RT-11, насколько я помню, дековская под PDP-11...
iLavr
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

Все с нуля. Просто использовались эти идеи.
aav8
Maniac
Posts: 287
Joined: 05 Nov 2008 19:47
Location: 81.28.208.238

Re: Маленький комп.

Post by aav8 »

Ну вот, странслировалась программа примерно на 130 строк
микродосовским ассемблером. На это дело ушло примерно 30 сек.
Линкера не мерил.
Главное, что оно заработало...