RUЭВМ
Вы хотите отреагировать на этот пост ? Создайте аккаунт всего в несколько кликов или войдите на форум.
Сентябрь 2020
ПнВтСрЧтПтСбВс
 123456
78910111213
14151617181920
21222324252627
282930    

Календарь Календарь

Последние темы
» Тема для вопросов, консультаций и т. д...
автор Atari1974 Вчера в 16:12

» ZX Microdrive
автор barsik Вчера в 02:44

» Флейм только по теме "Радио-86РК".
автор barsik Пн Сен 28 2020, 09:24

» Трансформатор электронный Taschibra 230/12В 60Вт для галогенных ламп. Перестал работать.
автор Viktor2312 Ср Сен 23 2020, 15:05

» Купил с али БП 12в 100w для питания LED лент подсветки. Проблема
автор Viktor2312 Вс Сен 20 2020, 18:07

» Жалобы/пожелания по работе форума
автор Viktor2312 Вс Сен 20 2020, 11:54

» Стабилизированный преобразователь напряжения.
автор Viktor2312 Пн Сен 14 2020, 23:12

» Простые доработки ZX-48К: RAM-монитор в ПЗУ и экран на E000
автор barsik Сб Сен 12 2020, 23:47

» Применение КР580 ВИ53 для генерации музыки
автор Viktor2312 Сб Сен 12 2020, 20:09

» STM32. Статьи, заметки, очерки, разное...
автор Viktor2312 Чт Сен 03 2020, 12:09

» STM32G0. Документация (Datasheet, разное).
автор Viktor2312 Чт Сен 03 2020, 11:52

» Новинки. Книги. Часть 1.
автор Viktor2312 Ср Сен 02 2020, 14:21

» STM32F4. Статьи, заметки, очерки, разное...
автор Viktor2312 Вт Сен 01 2020, 14:44

» Ленинград-0,-1,-2,-3. Статьи, заметки, очерки, разное...
автор barsik Вс Авг 30 2020, 08:32

» Ленинград-0
автор barsik Вс Авг 30 2020, 08:01

» STM32F4. Изучение.
автор Viktor2312 Пт Авг 28 2020, 00:07

» Орион-128: Полезные доработки ПЭВМ
автор barsik Чт Авг 27 2020, 11:21

» STM32H7. Статьи, заметки, очерки, разное...
автор Viktor2312 Вт Авг 25 2020, 10:43

» Радио-86РК: По страницам журнала "Радио" и не только...
автор barsik Вт Авг 25 2020, 01:28

» STM32L0. Документация (Datasheet, разное).
автор Viktor2312 Вс Авг 23 2020, 10:10

» STM32L0. Отладочные платы.
автор Viktor2312 Сб Авг 22 2020, 20:22

» STM32L0. Программное обеспечение, разное...
автор Viktor2312 Сб Авг 22 2020, 17:24

» STM32L0. Статьи, заметки, очерки, разное...
автор Viktor2312 Чт Авг 20 2020, 19:37

» STM32H7. Документация (Datasheet, разное).
автор Admin Чт Авг 20 2020, 13:33

» STM32F7. Документация (Datasheet, разное).
автор Admin Чт Авг 20 2020, 13:32

Самые активные пользователи за месяц
Viktor2312
Примитивная DOS размером 2 Кб Vote_l10Примитивная DOS размером 2 Кб Voting10Примитивная DOS размером 2 Кб Vote_r10 
barsik
Примитивная DOS размером 2 Кб Vote_l10Примитивная DOS размером 2 Кб Voting10Примитивная DOS размером 2 Кб Vote_r10 
Atari1974
Примитивная DOS размером 2 Кб Vote_l10Примитивная DOS размером 2 Кб Voting10Примитивная DOS размером 2 Кб Vote_r10 

Поиск
 
 

Результаты :
 


Rechercher Расширенный поиск


Примитивная DOS размером 2 Кб

Перейти вниз

Примитивная DOS размером 2 Кб Empty Примитивная DOS размером 2 Кб

Сообщение  barsik в Чт Мар 05 2020, 09:52

1
Тема о примитивной DOS размером в 2 кб, которую можно прошить в ПЗУ 573РФ2 расширяющее базовое ПЗУ РК86 и установленное в адресах F000...F7FF. Понятно, что в 2 кб можно уместить только примитивную DOS. Хотя РК86 это достаточно примитивный компьютер, но примитивность DOS вовсе не следует из примитивности самого компьютера, а лишь характеризует уровень сложности DOS.

Спойлер:

За прошедшие 35 лет только ленивый не ругал и не плевался в адрес РК86, обсуждая недоработки его конструкции. Но разработчики РК исходили из тогдашних реальностей, уровня знаний, информированности и требований редакции. Так им представлялось целесообразным тогда, а обвинять их по сути в необладании возможностями Ванги, - глупо и несправедливо.

Авторов РК можно упрекнуть лишь в том, что они не занимались сопровождением и развитием своего компьютера. Тем не менее, авторы РК своим трудом по популяризации компьютерных знаний заслужили себе памятник при жизни. Они вполне решили поставленную задачу и породили хобби любителей самодельных 8-ми разрядок. Кстати, хотя недоработки РК известны, но и исправить их за столько времени ни у кого не хватило ума, энергии и энтузиазма. Единственным значимым улучшением РК смог стать лишь РК-КНГМД с RK-DOS опубликованный в 1993 году Е.Седовым, хотя эта публикация была бы намного полезнее на несколько лет раньше.

И всё-же РК86 с полным правом можно назвать примитивным компьютером. И даже не столько из-за неудачной архитектуры и неразумного неиспользования даже тех возможностей, что даёт БИС ВГ75 (что даже не привело бы к усложнению схемы). А потому, что низкие параметры РК позволяют иметь на нём лишь именно примитивные некрасивые игры, что были уместны лишь в середине 70-тых годов XX-века.

Применение ПДП лишило РК86 возможности работать в реальном времени, программно выводить звуки без искажений, затормозило его CPU на 25%, лишило возможности подключить дисковод с помощью БИС 1818 ВГ93, а отсутствие буфера ОЗУ снизило нагрузочную способность шины до нуля и лишило возможностей расширений путём наращивания периферии и турбирования.

В 80-тые годы XX-века, когда РК и его клонам пришлось конкурировать с полноценно графическими бытовыми компьютерами (а позднее и с IBM PC), которые обладали лучшими изобразительными возможностями и быстродействием, имели дисководы и изобилие качественных программ, характеризовать РК86 как-то иначе просто невозможно.

Для сравнения в развитых странах бытовые компьютеры без графики были только в 70-тые годы, а с начала 80-тых годов бытовой игровой компьютер без графики это нонсенс. К несчастью появление РК86 спровоцировало промышленность на выпуск так называемых РК-подобных вместо более приличных графических компьютеров.
.

В оригинальном виде РК86 малопригоден для DOS. Нужны аппаратные доработки. Полноценные DOS требуют больших доработок. Когда стоИт задача только запускать программы, то достаточно даже примитивной DOS. Кроме подключения контроллера дискового привода, доработка, которая позволяет иметь минимальную DOS на РК86, заключается лишь в добавлении на плату РК дополнительного ПЗУ в 2 кб. Это минимальное вторжение в плату РК86. При наличии небольшого опыта эта доработка делается за полчаса.

Задача примитивной DOS лишь обеспечить хранение и запуск программ немного быстрее, чем это делается при загрузке с магнитофона. Примитивная DOS в качестве функций программного интерфейса предоставляет только чтение и запись файла целиком (что ограничивает макс.размер файла размером TPA DOS), не использует фрагментацию файлов, не делает обработки физических дефектов носителя и по существу является лишь дискетным вариантом МГ-ленты, - файлы просто кладутся на диск впритык друг к другу (из-за чего удаление файла, как и на МГ-ленте, не приводит к высвобождению места на носителе) и в отдельном секторе диска создаётся каталог - список файлов с их именами и адресами размещения на диске.

Примером отечественной примитивной DOS является Hameleon-DOS для компьютера Львов ПК-01. ORDOS ОРИОНА, кстати, тоже примитивная, но не в смысле программного интерфейса, а в смысле идеологии. ORDOS даже ОС может называться с натяжкой, т.к не соотвествует общепринятым концепциям DOS (скорее является системой управления ROM-картриджем, адаптированной для доп.банки памяти, именуемой квазидиском) и вообще не поддерживает дисковод или другой массовый носитель.

Очевидно, что и для РК86 тоже были бы созданы самодельные любительские DOS (и естественно, поначалу они были бы именно примитивными), если бы в 1986...1991 годах и для РК86 имелось бы техническое решение по подключению дисковода или эл.диска из ОЗУ. Увы, такие технические решения появились лишь много лет спустя, когда это уже мало кому было надо.

Подключить дисковод в машину, в которой прогон программы непрерывно рвёт ПДП, реально сложно, а вот использовать RAM-диск (внешний или из добавленного ОЗУ в самом компьютере) было совсем несложно. Этому помешало скорее то, что большинство программистов и аппаратчиков любителей вскоре бросили РК86, т.к стали доступны платы для самосборки ZX-Spectrum и Специалиста.

Загружаться (например из ROM-диска) и работать в ОЗУ DOS для РК не удастся, т.к она должна обеспечить запуск программ размером в 28.5 кб, ибо такие программы для РК86 есть. Таким образом DOS должна размещаться где-то выше 8000.

И возникает вопрос - добавлять выше 8000 область ОЗУ или ПЗУ (или и то и другое). ПЗУ для пользователя удобнее, т.к в него грузить с МГ-ленты DOS не надо. Аппаратно вполне возможно совместимо установить доп.ПЗУ в каких-то дырках адресного пространства выше 8000, ибо у РК86 в адресах выше 8000 используется всего около 30 адресов, т.е найти место для дополнительного окна ПЗУ не трудно. Для установки доп.ПЗУ типа РФ2 достаточно один из четырёх восьмикилобайтовых участков для БИС разделить дешифратором. Например так, как предлагали И.Крылова или Е.Седов на страницах журнала "Радио". Всё-равно для подключения контроллера массового носителя (винта, флопа или флэша) нужен дополнительный чип-селект.

Хотя на оригинальной плате РК нет участка слепыша для доработок, всё-же одну панельку для РФ2 можно запаять в ряды отверстий рядом с разъёмом ГРПМ-61. При этом удобно (т.к недалеко) соединять проводками контакты этой доп.панельки с контактами имеющейся панельки ПЗУ F800. Разумнее всего доп.ПЗУ РФ2 адресовать в области F000...F7FF, что даёт 4 кб сплошного ПЗУ F000...FFFF. Кстати, и сами разработчики РК86 планировали включать доп.ПЗУ именно в области F000.

Всего 4 кб ПЗУ, если тут надо уместить и DOS и стандартные подпрограммы ввода/вывода (экран/клавиатура/магнитофон) - это очень мало. Полноценные DOS для КР580 обычно имеют размер порядка 8 кб. Самой компактной из DOS для КР580 вероятно можно считать RK-DOS, она имеет размер около 6 кб. Причём BDOS и ядро CCP размещается в ПЗУ 4 кб, а исполнительная часть CCP (т.е сами команды) размещаются в виде файлов на дискете (что не очень удобно). RK-DOS использует дефрагментацию, позволяет файлы любого размера и имеет развитые функции программного интерфейса и не может относиться к примитивным DOS.

Кстати, RK-DOS это довольно грамотный, но увы, опоздавший продукт. Эта DOS появилась, когда это уже перестало быть актуальным, - в 1993 году популярность РК86 уже упала почти до нуля и дисковый ассемблер для RK-DOS никому не помог писать программы для РК86. Т.к последние программисты для РК86 покинули его ещё за несколько лет до этого.

Сейчас польза от DOS только в повышении удобства пользования, - с помощью DOS удобнее запустить игру, чем загружая с магнитофона. А такую задачу вполне в состоянии выполнить даже самая примитивная DOS. А во времена, когда 8-ми разрядки были единственной возможностью иметь собственный компьютер, наличие DOS приносило большую пользу программисту.

Наличие дискового ассемблера существенно ускоряет и облегчает разработку программ. И речь не о большей скорости загрузки с дискеты, чем с МГ-ленты. Главное, что тогда объём исходника на ассемблере не ограничен всего в 23 кб (т.к на РК из 29 килобайт доступного ОЗУ, 4 отнимал транслятор и 2 кб - буфер трансляции). С дискетным ассемблером размер исходника ограничивает только объём дискеты.

Без дисковода в буфер текста редактора/ассемблера умещался исходник дающий всего ~1.5 кб объектного кода (хотя в начале 90-тых появились методы сжатия исходников позволяющие транслировать аж до 2 кб). Программы большего объёма приходилось компоновать, вручную переписывая и вставляя в текст модулей адреса перекрёстных ссылок (причём при каждой перетрансляции). Учитывая, что каждый ассемблерный модуль приходилось грузить 3-4 минуты с ленты, и ещё 3-4 минуты тратить на сохранение после модификаций, было почти невозможно написать программу из более, чем двух модулей (т.е макс.объём собственно кода редко превышал 3.5 кб). Потому более крупные программы для РК86 писали кросс-ассемблерами на ДВК.

Кстати, даже примитивная DOS позволяет транслировать программы с исходником имеющим размер более объёма TPA, только исходник тут не может быть одним большим файлом, а должен состоять из одного основного файла и нескольких инклюдэ-файлов, каждый из которых умещается в буфер ассемблера в ОЗУ.

В 1989 году появились сведения о (как минимум) двух вариантах успешного подключения к РК86 дисковода с CP/M. Однако они не получили широкого распространения и даже известности, т.к дисководы тогда были практически недоступны. Дисководы на нелегальных рынках стали появляться лишь в 1990 году, а цена упала до более-менее приемлемой лишь в 1991.

Но и тогда, увы, для РК86 это ничего в плане дисковода не изменило. Т.к известные решения КНГМД на базе ВГ93 работали на основе программного обмена, а в РК86 этому препятствует работа ПДП. В итоге число пользователей РК86 стало быстро сокращаться. Лишь в 1993 году Е.Седов, пусть и весьма запоздало, но наконец решил проблему дисковода для РК86 и Микроши.

Однако, оказывается, уже намного ранее существовала реальная возможность получить DOS и, соответственно, дисковый ассемблер на РК86. Речь о DOS работающей с RAM-диском. Я купил банку ОЗУ 565РУ7 для электронного диска в 1988 году, а статика 62256 стала доступной чуть позднее в 1989-1990.

Внешний электронный диск на 565РУ7 довольно сложен (~25 корпусов) и не энергонезависим, его надо загружать/выгружать. А электронный диск выполненный на статике намного проще (лишь ряд панелек), и хоть по стоимости байта тогда получался примерно вдвое-втрое дороже, но может хранить данные и без питания за счёт крошечной пуговичной батарейки. На статике с батарейкой получается как бы крошечный аналог современного SSD-винчестера (кстати, уже в XXI веке стали доступны скоростные ОЗУ, которые не забывают данные по выключению питания).

Электронный диск (например 256 кб) на статическом ОЗУ может подключаться как полностью внешнее устройство через пользовательский ППА D14 (при необходимости может также иметь и свой собственный ППА для интерфейса). Такие электронные диски на статике всё-же появились на РК86, хотя уже слишком поздно и потому существовали лишь в единичных экземплярах.

Таким образом несложное расширение ПЗУ на одной дополнительной микросхеме типа 573 РФ2 (что требует монтаж на основной плате РК микросхемы 555ИД7 и панельки для ПЗУ РФ2) и подключение внешней несложной платки электронного диска на статике позволяло уже в 1989 году получить железо пригодное для работы более эффективного инструментария программиста, т.е дискового ассемблера. А впоследствии, после появления информации по использовованию на РК86 дисковода с помощью РК-КНГМД, DOS работающую на RAM-диск можно было очень легко (путём замены подпрограмм чтения/записи сектора) конвертировать для работы на дисковод.

К сожалению, среди пользователей РК86 к тому времени уже не было достаточно квалифицированных людей, способных придумать и спаять внешний RAM-диск на статике и написать даже самую простейшую DOS. Т.к все более-менее грамотные владельцы РК86, обнаружив предельную аппаратную ущербность РК86, предпочли перейти на другие компьютеры имеющие полноценную графику.

Рассмотрим набор подпрограмм нужных в примитивной DOS, которую любой любитель немного знакомый с ассемблером мог написать ещё в 80-тые годы XX века.

Естественно, первым делом нужны две подпрограммы чтения/записи сектора. Хотя эмуляторы не поддерживают внешний эл.диск на статике, но при разработке и отладке нет особой разницы, если в эмуляторе под эл.диск использовать резидентное дополнительное ОЗУ РК86, которое прокачивается в окне в 8 кб на A000...BFFF (и для чего у меня уже имеется соответствующий конфиг для эмулятора).

При смене носителя меняются только две подпрограммы чтения/записи сектора, а на остальной код DOS это не влияет (хотя для разных устройств размер этих подпрограмм разный). Подпрограммы чтения/записи сектора имеют минимальный размер для эл.диска, для контроллера на БИС ВГ93 и винчестера IDE их размер немного больше, а ещё больший размер имеют подпрограммы для программного РК-КНГМД.

Вот драйвер RAM-диска (т.е две подпрограммы чтения и записи сектора) для варианта расширения ОЗУ в РК86 в окне A000...BFFF:

Спойлер:

OKNO    EQU     0A000H              ; адрес окна коммутации размером в 8 кб
BNKSEL  EQU     08800H

; ----------------------------------------------

EDIWR:  CALL    CMPADR
        CALL    MOVSEC
        CALL    ADRCHS
        LD      (HL),A
        XOR     A
        RET

; ----------------------------------------------

EDIRD:  CALL    CMPADR
        EX      DE,HL
        CALL    MOVSEC
        CALL    ADRCHS
        CP      (HL)
        JP      NZ,BADOP
        XOR     A
        RET

; ----------------------------------------------

MOVSEC: LD      BC,512
        PUSH    HL
        PUSH    BC
        CALL    @LDIR
        POP     BC
        POP     HL

        LD      A,0             ; начальная CH.SUMM
CHSLOO: ADD     A,(HL)
        INC     HL
        LOOP    CHSLOO

        PUSH    AF
        XOR     A
        LD      (BNKSEL),A
        POP     AF
        RET

; ----------------------------------------------

ADRCHS: LD      HL,(KLAST)      ; высчитаем адрес для К.С.
        EX      DE,HL
        LD      HL,PLCCHS
        ADD     HL,DE
        RET

; ----------------------------------------------

RR_HL:  LD      A,H
        RRCA
        LD      H,A
        LD      A,L
        RRCA
        LD      L,A
        RET

; ----------------------------------------------

TRKSEC: LD      C,L
        CALL    RR_HL           ; /2
        CALL    RR_HL           ; /4
        RRA                     ; /8
        RRA                     ; /16
        AND     00111111B
        INC     A               ; эл.диск начинается в странице 1
        LD      B,A

        LD      A,C
        AND     00001111B
        RET

; ----------------------------------------------

CMPADR: LD      HL,(KLAST)
        LD      A,H
        AND     11111110B       ; не больше ли макс. NKL ?
        JP      NZ,BADPOP

        CALL    TRKSEC

;        INC     A               ; если нумерация секторов начинается с 0
        LD      HL,OKNO-512     ; начальный оффсет во всех страницах
        LD      DE,512
ADDLOO: ADD     HL,DE
        DEC     A
        JP      NZ,ADDLOO

        LD      A,B
        LD      (BNKSEL),A

        EX      DE,HL
        LD      HL,(UK_DMA)
        RET

; ----------------------------------------------

BADPOP: POP     AF
BADOP:  XOR     A
        DEC     A
        RET


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

Механический дисковый носитель обычно работает с треками и секторами, но все винчестеры с размером от 1 гигабайта используют адресацию LBA, а не трек-секторную. Сама DOS не знает о треках и секторах, но они нужны для ретро-винчестера на 40 мб и дисковода, потому в данном драйвере подпрограмма TRKSEC пересчитывает номер кластера в трек и сектор.

Для эл.диска из ОЗУ прокачиваемым в окне в 8 кб естественно сделать размер трека в 8 кб. Тогда в таком треке умещается 16 физ.секторов по 512 байт. Сектор это минимальный элемент обмена в данной DOS (также сделано в RK-DOS), потому она работает намного быстрее, чем CP/M (которая тормозит из-за того, что в ней минимальный элемент обмена не равен размеру физ.сектора, что требует наличия промежуточных буферов и кучу копирований, что фатально замедляет обмен с диском).

Как видите, при грамотной схемотехнике подпрограммы для организации эл.диска совсем просты. Подпрограмма CMPADR рассчитывает адрес сектора в эл.диске, включает нужный его участок в окне 8 кб и возвращает в HL адрес начала сектора в ОЗУ. Попрограмма ADRCHS возвращает адрес для хранения контрольной суммы текущего сектора. Эти контрольные суммы хранятся в основном ОЗУ (или в странице 0 доп.ОЗУ, если оно есть) начиная с адреса PLCCHS (Place Check Sum) и на каждый сектор тратится один байт. КС представляет просто арифметическую сумму байтов сектора (плюс нач.оффсет).

Контрольные суммы секторов необходимы, даже если в системе не бывает сбоев, т.к в ходе отладки программ бывают улёты и процессор может "плюнуть" что-нибудь в эл.диск, что может привести к размножению дохлоты (так было в ранних CP/M для ОРИОНА, что в последующих версиях заставило ввести КС). И, естественно, подпрограмма MOVSEC копирует сектор размером в 512 байт.

Для внешнего VDISK-а, т.е при использовании внешней платки RAM-диска подключенной через ППА D14 и представляющей собой просто набор панелек со статическими ОЗУ, подпрограммы чтения/записи сектора отличаются только подпрограммой MOVSEC. Для реального дисковода (особенно, если он программный, как РК-КНГМД) подпрограммы чтения и записи сектора намного более сложные (и соответственно бОльшие по объёму кода).

Для работы с каталогом, как и в любой другой DOS необходим отдельный буфер, называемый CATBUF. В него DOS считывает сектора каталога и выполняет поиск каталоговых записей о файлах по имени. Естественно размер этого буфера д.быть равен размеру физического сектора. При отсутствии другого ОЗУ выше 8000 этот буфер приходится помещать в основное ОЗУ (т.е ниже 8000). Даже в системе, где эл.диск организован в окне A000 дисковый буфер д.быть в основном ОЗУ, т.к иначе потребуется копирование между страницами доп.ОЗУ, что не только резко тормознёт, но и потребует модификации ПЗУ F800 для введения подпрограмм F836/39 для чтения/записи байта из страниц ОЗУ.

Важное значение в любой DOS имеет формат каталоговой записи. Вот минимально желаемая каталоговая запись для простой (т.е нефрагментирующей файлы) DOS:


юзер               1
имя                8
расширение         3
адрес загрузки     2
число блоков       1
размер посл.блока  1
дата файла         2
N_кластера         2


Здесь шаг каталоговых записей - 20 байтов. N_кластера это номер первого кластера файла, т.е по сути адрес начала файла на диске. Под юзером понимается область диска пользователя аналогично CP/M. При шаге в каталоге в 20 байт в одном секторе каталога умещается 25 каталоговых записей.

Кстати, в терминологии CP/M каталоговые записи называются экстентами, т.к там каталоговая запись одного файла может состоять из нескольких экстентов. В примитивных DOS такого нет и для каждого файла выделяется только одна каталоговая запись или экстент.

Свободное место каталога естественно, как и общепринято, обозначает первый байт каталоговой записи равный E5 (т.к именно так заполняют сектора форматёры дисков в КНГМД на БИС). Если первый байт каталоговой записи меньше 80H, то это место в каталоге занято записью о файле. А если этот байт >80H, но не E5, то это или удалённый или невидимый для поиска и не выводимый по DIR файл-дохляк.

Понятие блок в 256 байт введено ради сокращения размера каталоговой записи при возможности иметь размер файла кратный одному байту, а не целому сектору (что обычно имеет место для простых DOS). В некоторых DOS, чтобы поиметь любой размер файла в каталоговой записи хранят число секторов и отдельно два байта отводятся под размер последнего сектора байта. При размере сектора в 512 байт и расходе в один байт для хранения числа секторов файла макс.размер файла - 512*256 байт (т.е 128 килобайт). При этом в целом для задания размера файла с точностью до байта тратится целых три байта (или даже четыре  байта, если нужны файлы крупнее 128 Кб и приходится тратить 2 байта под размер в секторах).

Разумнее сделать чуть экономнее. Размер файла храним в блоках по 256 байт, выделяя под это также всего один байт, что позволяет иметь лишь файлы с максимальным размером в 64 кб (чего для DOS с цельно-файловой загрузкой и CPU адресующим лишь 64 кб вполне достаточно). И ещё один байт я трачу на хранение размера последнего блока, что и позволяет знать размер файла с точностью до байта. Из размера файла в блоках по 256 байт не проблема получить размер файла в секторах по 512 байт (это делается с помощью арифметики с помощью операции деления на два, что в двоичной арифметике всего одна команда сдвига).

Т.к в крошечном ПЗУ в 2 Кб нет места для обслуживания юзеров, даты файла и размера файла с кратностью до байта, то для примитивной DOS разумно сократить каталоговую запись до 16 байт, что позволяет уместить в один сектор каталога аж 32 каталоговых записи. Тогда формат каталоговой записи в примитивной DOS такой:


имя                11
адрес загрузки     2
число секторов     1
N_кластера         2


В самой первой каталоговой записи в самом первом секторе каталога, как и в Хамелеон-ДОС храним основные параметры всего диска. А именно, - имя диска, атрибут разрешения записи (флаг R/O) и номер кластера, начиная с которого будет записываться очередной файл.

Таким образом всё, что требуется сделать для записи очередного файла, - это считать первый сектор каталога (чтобы из 0-вой каталоговой записи узнать размер заполненной части) и затем записать на диск нужное число секторов начиная с номера первого свободного кластера, после чего занести в каталоговую запись нулевого файла новый текущий номер первого свободного кластера и в конец каталога записать каталоговую запись с именем и параметрами записанного файла.

Для считывания файла требуется сначала найти в каталоге каталоговую запись по имени файла. Для этого нужна подпрограмма сканирования каталога для поиска нужной каталоговой записи. Неплохо работает вот такая подпрограмма:

Спойлер:

       .phase  6A00H

        JP      DOS1
DOSVEC:                         ; вектора обработки дисковых ошибок

AOBLRD: DW      RD_ERR          ; адрес ухода при обломе при чтении
AOBLWR: DW      WR_ERR          ; адрес ухода при обломе при записи
AOBLRO: DW      RO_ERR          ; адрес ухода при обломе из-за R/O

VECLEN  EQU     $-DOSVEC

DOS1:   RST_18
        defb    1FH,10,'PR-DOS 0.1',13,10+128
        .....

; ----------------------------------------------

FNDEXT:              ; Поиск в каталоге экстента с именем из RFCB

                     ; ВХОД:  RFCB - диск и имя файла
                     ; ВЫХОД: CY=0 - экстент не найден
                     ;        CY=1 - OK и тогда:
                     ; HL - указывает на экстент в CATBUF
                     ; (UKAZ1) - номер кластера каталога


        CALL    USTDIR
FNDLO1:
        CALL    RD1DIR          ; считать сектор (UKAZ1) В CATBUF

; Теперь просматириваем CATBUF и ищем нужный файл

        LD      HL,CATBUF
        LD      B,RECS          ; число экстентов в секторе
FNDLO2:
        LD      A,(HL)
        OR      A
        JP      Z,FNDEX3        ; если обычный файл
        INC     A               ; CP 0FFH
        JP      Z,FNDEX2        ; КОНЕЦ КАТАЛОГА
FNDNXT:
        LD      DE,EXTLEN       ; размер экстента
        ADD     HL,DE
        DEC     B
        JP      NZ,FNDLO2
                                ; СЕКТОР ОБРАБОТАН
        CALL    NXTSEC          ; к следующему сектору каталога
        JP      NZ,FNDLO1       ; если был не последний сектор
FNDEX2: XOR     A               ; CY=0 - экстент не найден
        RET

FNDEX3: PUSH    BC              ; B- осталось экстентов в секторе
        INC     HL              ; пропустим байт FLAG
        LD      DE,NAME
        LD      B,11
        CALL    CMPSTR          ; HL не портит
        DEC     HL
        POP     BC              ; B- осталось экстентов в кластере
        JP      NZ,FNDNXT
        SCF
        RET

NXTSEC: INCWORD UKAZ1           ; к следующему сектору каталога
        LD      HL,RAB1         ; ЧИСЛО ОСТАВШИХСЯ СЕКТОРОВ
        DEC     (HL)            ; это был последний сектор ?
        RET

; ----------------------------------------------

RD1DIR: CALL    SETDBF          ; читать кластер (UKAZ1) в CATBUF
        LD      HL,(UKAZ1)
GET1HL: LD      (KLAST),HL
        CALL    READ
        JP      Z,JJJ_03
OBLOMR:
        LD      HL,(AOBLRD)
        JP      (HL)

JJJ_03: LD      HL,(KLAST)
        LD      (READED),HL
        RET

; ----------------------------------------------

USTDIR: LD      A,CATSIZ
        LD      (RAB1),A        ; ЧИСЛО ОСТАВШИХСЯ СЕКТОРОВ

UK1_00: LD      HL,0
        LD      (UKAZ1),HL      ; текущий кластер каталога на диске
        RET

; ----------------------------------------------

SETDBF: LD      HL,CATBUF
        LD      (UK_DMA),HL
        RET

; ----------------------------------------------

CMPSTR: PUSH    HL              ; сравнение строк по HL и DE
CMPST1: LD      A,(DE)          ; B - длина
        CP      (HL)
        JP      NZ,POPHL
        INC     HL
        INC     DE
        DEC     B
        JP      NZ,CMPST1
        XOR     A
POPHL:  POP     HL
        RET

; ----------------------------------------------

RO_ERR: RST_18
        defb    13,10,'FILE R/','O'+80H
        JP      CCP

; ----------------------------------------------

RD_ERR: RST_18
        defb    13,10,'R','D'+80H
        JP      WRERR1

; ----------------------------------------------

WR_ERR: RST_18
        defb    13,10,'W','R'+80H
WRERR1: LD      SP,DOSSTK
        RST_18
        defb    ' ERR TRK',32+80H
        LD      HL,(KLAST)
        CALL    TRKSEC
        PUSH    AF
        LD      A,B
        CALL    HEX_A
        RST_18
        defb    ' SEC',32+80H
        POP     AF
        CALL    HEX_A
        JP      CCP
       
; ----------------------------------------------

RFCB:

DRIVE:  DS      1       ; номер диска

NAME:   DS      11      ; имя файла
FADDR:  DS      2       ; адрес загрузки
FSIZE:  DS      1       ; длина в блоках
NKLAST: DS      2       ; первый кластер файла

EXTLEN  EQU     $-NAME  ; длина каталоговой записи


Как видите эта подпрограмма поиска в каталоге очень проста и легко пишется человеком, кто лишь вчера узнал о работе основных команд микропроцессора. И по сути это все самые сложные части примитивной DOS. Для получения DOS (для RAM-привода) нужна ещё подпрограмма форматирования эл.диска при первом старте (это просто заполнение кодом), процессор команд CCP (который писать не надо, т.к в качестве него используется CCP монитора) и реализация очень простых процедур LOAD, SAVE и KILL. Кстати, заметьте, что (в отличие от Хамелеон-ДОС) я предусмотрел в примитивной DOS и обработку дисковых ошибок.

Благодаря простоте алгоритма примитивная DOS умещается в 2 кб, а, благодаря обмену физическими секторами (а не логическими в 128 байт), работает на порядок быстрее, чем CP/M, что особенно заметно при использовании больших (по меркам 8-ми разрядки) партиций винчестера в 8...16 мб. Значительно большее напряжение мозга требуется, чтобы ввести в примитивную DOS возможность повторно использовать место занимаемое удалёнными файлами.

Для этого подпрограмма FNDREC (которая в примитивном варианте ищет лишь первую свободную каталоговую запись в каталоге) существенно дополняется и теперь на входе получает размер файла в секторах и сначала просматривает все удалённые каталоговые записи, с целью определить среди них такой удалённый файл размер которого максимально близок к размеру записываемого файла. Так чтобы после записи на это освободившееся (после удаления) место нового файла, оставшийся неиспользованным остаток занимал бы минимальное число секторов (т.к на это место уже нельзя будет записать другой файл и оно пропадёт для использования).

Как и для всех DOS без фрагментирования, чтобы получилась пригодная для эксплуатации система нужна ещё сервисная программа SQEEZE. Такая же встроенная команда для "сборки мусора" имеется в CCP ОС ДВК. Эта команда опасна, т.к может привести с гибели данных, потому её рекомендовалось применять лишь на качественных дискетах. При её запуске задаётся вопрос "Are You sure?" и работает она иногда очень долго, т.к сдвигает большой массив информации схлопывая пустоты между файлами. Кстати ОС ДВК, хоть и профессиональная система, но судя по необходимости "сборки мусора", в ней не используется фрагментация файлов, хотя повторное использование места от удалённых файлов есть.

Выполнять сдвижку файлов можно без опасения на RAM-дисках. И также на винчестерах, т.к на них обычно не бывает дохлых секторов. Хотя для винчестеров, как раз освобождение места на диске после удаления файлов не столь актуально, т.к на винчестерах которые можно поиметь сейчас места очень много.

DOS расположенная в ПЗУ и работающая на РК с базовой архитектурой, т.е только с ОЗУ в 32 кб не в состоянии полностью заменить магнитофон. Т.к, в любой DOS в этом ОЗУ требуется размещать, как минимум, один дисковый буфер размером с физический сектор (в данной DOS это CATBUF), который в случае дисковода и древнего винта имеет размер в 512 байт (а у современных винтов и флэшей аж 4 кб). Таким образом программу размером в 28.5 кб дисковая DOS без наличия дополнительного ОЗУ выше 8000 никак загрузить не сможет. По этим же причинам отладчик Г.Штефана загружающийся сразу ниже RAMTOP 7500 не запустить из DOS.

Если же требуется запуск программ размером в 28.5 кб, то это потребует расширения не только ПЗУ на 2 кб, но и ОЗУ. В минимуме достаточно расширения ОЗУ на 8 кб в окне A000...BFFF, что можно сделать (в случае 565РУ5) несложной коррекцией схемы приводящей к "открытию ОЗУ" в области A000...BFFF, или (в случае двух банок РУ3) путём монтажа статического ОЗУ 6264 (у которого объём как раз 8 кб). Речь о DOS не для RAM-диска из ОЗУ A000, а для дисковода.

Такая более сложная (чем удвоение объёма ПЗУ до 4 кб) доработка позволяет не только убрать дисковые буфера и раб.ячейки DOS из основного ОЗУ РК ниже 8000, но и позволяет в этом же доп.ОЗУ работать самой DOS. Если часть кода переместить в ПЗУ, то даже CP/M для дисковода сможет работать в этом окне ОЗУ A000...BFFF.

Однако для тормозного РК с его крошечным ОЗУ применение тормозной CP/M - это всё-же не лучшее решение. По сравнению с RK-DOS или любой другой DOS с цельносекторным обменом, ОС CP/M работает, как минимум, раз в 5 медленнее, и если стоИт задача только запустить игру, нет смысла тратить в ПЗУ целых 8 кб вместо 2 кб.

Всё-равно из-за нехватки объёма ОЗУ на РК не удастся прогонять фирменные CP/M пакеты и компиляторы ЯВУ. Даже самый примитивный CP/M бейсик-интерпретатор размером в 24 кб оставляет в ОЗУ РК слишком мало ОЗУ для бейсик программ (а MSX бейсик в 33 кб вообще не запустить на РК86). Хотя для программиста 80-тых годов ОС CP/M даже на машине со столь крошечным ОЗУ была бы очень полезной, т.к CP/M ассемблер позволил бы транслировать исходники любого размера.
barsik
barsik
Мастер++

Сообщения : 701
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Вернуться к началу Перейти вниз

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения