nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 18 Sep 2019 03:50



Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4
Маленький комп. 
Author Message
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 261
Location: Россия
Reply with quote
Post 
Продолжение темы о ПО данного "маленького компа" вот отсюда.

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


10 May 2018 13:26
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Post Re:
barsik wrote:
Адаптация CP/M под конкретное железо заключается в основном в написании всего двух подпрограмм низкого уровня в CP/M-BIOS. Это считать и записать логический блок размером в 128 байт.

Я поначалу тоже решил так поступить.
Но нужно-было найти какй-то подходящий образ, а потом его настроить под конкретную карту памяти.

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

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

Что-то похожее хочу сделать в CP/M. Поэтому BDOS приходится довольно сильно править.
В дальнейшем его скорее всего придется переписать заново.
Надо придумать в каком месте FCB хранить идентификатор полученный от сервера.


10 May 2018 19:24
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Ну вот - в первом приближении чтой-то получилось...
Работает TYPE и DIR.
Запускаются (но не совсем работают) транзитные
программы (правда пока небольшие по размеру) - не реализовано создание/запись файла.
Оказывается чтение файла должно возвращать 0 - если все нормально, 1 - если конец файла,
FF - если ошибка...
И столкнулся с такой проблемкой - если файл открыть, и из него только читать,
то его можно не закрывать (как написано в доке CP/M), а как передать серверу
что файл больше не нужен - пока идей нет.
Поэтому TYPE или запуск транзитной программы можно выполнить только один раз...
До перезапуска сервера...


15 May 2018 20:54
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 261
Location: Россия
Reply with quote
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.


16 May 2018 03:29
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
barsik wrote:
При открытии файла на чтение всё его содержимое должно грузиться в буфер, а дисковый файл должен закрываться.

Да, наверное примерно так и поступлю - как только файл весь прочитался - его можно закрывать.
barsik wrote:
Насколько я понял у Вас сервер эмулирует не подпрограммы низкого уровня из BIOS, а дисковые функции BDOS. Но это же невыгодно, т.к теряется совместимость.

Да именно так устроено.


16 May 2018 21:51
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Ну вот появилось немного свободного времени...
Немного подделал 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 23:04
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 261
Location: Россия
Reply with quote
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, а носитель.


17 Aug 2019 06:01
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
>>Байты со смещением 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 21:25
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
aav8 wrote:
Операционка в принципе у меня есть, некоторые идеи в ней были использованы
из RT-11. Но ест-но ни с чем не совместимая.

А какая операционка, что-то взято за основу или просто полностью самописная?

_________________
iLavr


18 Aug 2019 05:43
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Полностью самописная.
В свое время не успел наиграться с RT-11 и нарисовал свое (по мотивам).
Мне у этой ос (RT-11) нравилась полная асинхронность:
Файловые операции можно было выполнять в 3-х видах:
просто ждать завершения
не ждать завершения (потом вызвать функцию для проверки состояния)
по окончании вызвать свою функцию
В обаботчике прерываний мжно было снова разрешить прерывания,
и поставить в очередь свой код для завершения обработки.


18 Aug 2019 16:27
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
aav8 wrote:
Полностью самописная.
В свое время не успел наиграться с RT-11 и нарисовал свое (по мотивам).

То есть вы адаптировали "вкусные" моменты RT-11 под другой процессор?
RT-11, насколько я помню, дековская под PDP-11...

_________________
iLavr


18 Aug 2019 19:03
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Все с нуля. Просто использовались эти идеи.


18 Aug 2019 19:19
Profile
Maniac

Joined: 05 Nov 2008 20:47
Posts: 259
Location: 81.28.208.238
Reply with quote
Ну вот, странслировалась программа примерно на 130 строк
микродосовским ассемблером. На это дело ушло примерно 30 сек.
Линкера не мерил.
Главное, что оно заработало...


20 Aug 2019 03:41
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 58 posts ]  Go to page Previous  1, 2, 3, 4

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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.