nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 18 Jul 2018 14:40



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

Joined: 19 Feb 2017 04:46
Posts: 109
Location: 600 км от Москвы
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: 248
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: 248
Location: 81.28.208.238
Reply with quote
Ну вот - в первом приближении чтой-то получилось...
Работает TYPE и DIR.
Запускаются (но не совсем работают) транзитные
программы (правда пока небольшие по размеру) - не реализовано создание/запись файла.
Оказывается чтение файла должно возвращать 0 - если все нормально, 1 - если конец файла,
FF - если ошибка...
И столкнулся с такой проблемкой - если файл открыть, и из него только читать,
то его можно не закрывать (как написано в доке CP/M), а как передать серверу
что файл больше не нужен - пока идей нет.
Поэтому TYPE или запуск транзитной программы можно выполнить только один раз...
До перезапуска сервера...


15 May 2018 20:54
Profile
Senior

Joined: 19 Feb 2017 04:46
Posts: 109
Location: 600 км от Москвы
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: 248
Location: 81.28.208.238
Reply with quote
barsik wrote:
При открытии файла на чтение всё его содержимое должно грузиться в буфер, а дисковый файл должен закрываться.

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

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


16 May 2018 21:51
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 50 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.