Тема не флеймовая, а информационная (т.е просто небольшая статья), обсуждать здесь что-то не планируется, но короткие вопросы, если что не ясно уместны.
PVV wrote:
... заодно, пошагово рассказать, как нужно собирать файлы CP/M
В принципе вопрос по адресу (т.к я трансляцию CP/M для кучи 8-ми разрядок делал много раз), но как нужно я не в курсе (не читал вражьих форумов на эту тему, т.к не имел Интернета). Могу рассказать лишь как это делаю я. В принципе, полезно что-то такое написать (пока я ещё жив), а то вижу, как некоторые собирают CP/M в более примитивных вариантах и неудобным способом.
Не важно для какой это конкретно машины, как пример, думаю повести речь о CP/M Специалиста, т.к это я делал относительно недавно (года 2 назад) и есть (или по крайней мере был) эмулятор EMU80, где это можно было посмотреть, причём и при работе на эл.диск из дополнительного ОЗУ (которого у обычного Специалиста нет) и при работе на РК-КНГМД. Сделать CP/M с работой на КНГМД с ВГ93 (по любому из 4-х изощрённых вариантов КНГМД) на базовый Специалист с клоком всего 2 МГЦ - пока не могу (и из вариантов лишь КНГМД от Специалиста-MX вроде бы эмулируется).
Хотя чужие подпрограммы для этих вариантов я выдрал из соответствующих версий DOS Специалиста, но не использовал, не проверял в реале. Пока для ВГ93 я могу гарантировать лишь, что корветовские подпрограммы на корветовском же КНГМД будут работать, но это годится лишь для турбированного до 2.5 МГЦ Специалиста. Да и EMU80 не поддерживает пока контроллер на БИС ВГ93. Клок 2.5 МГЦ плющит экранчик.
Чтобы странслировать работающую версию CP/M даже не нужны ВГ93-дисководные или винтовые подрограмм (они у меня тоже есть: в двух вариантах для ВГ93 и одном для IDE-винта). Достаточно написать простейшие подпрограммы для эл.диска из ОЗУ (основного или дополнительного).
По сути адаптация CP/M под конкретное железо заключается лишь в настройке параметров (т.е адресов, где размещаются блоки и другие константы), настройке консольных п/п-мм CP/M-BIOS, а основной объём работ сводится к получению подпрограмм чтения и записи сектора (а в случае эл.диска и форматирования его). Подпрограммы чтения/записи в моих исходниках CP/M для физически разных носителей располагаются в инклюдах - FLOP.INC (или RKFLOP.INC), VDISK.INC и VINT.INC.
CP/M я обычно гружу не из дискеты как было принято в 70-тые, а из ROM-диска (но не проблема тот же код считать и с дискеты). И, также (но это моя "фишка", не стандарт CP/M) в BIOS, для многобанковых машин (или ROM-диск версий) я модифицирую процедуру Warm Boot, чтобы по горячему рестарту BDOS и CCP подкачивались не с дискеты, а из специального буфера (в другой банке или из ROM-диска). Это приводит к тому, что на дискетах не нужны системные дорожки (но и не вредят), не надо держать на них код CP/M и возникает всеядность дискет.
Если на первых версиях CP/M ОРИОНА из 1991-93 вставить в флоповод A: несистемную дискету, или дискету с чуть-чуть иной версией CP/M-BIOS или, например, дискету Роботрона/Профи/АТМ и попытаться её считать, то произойдёт улёт.
А главное, это даёт возможность хранить файлы разных версий CP/M и других DOS в виде файлов ROM-диска и использовать их даже не имея дисковода (т.к привод A: организуется как эл.диск из какого-нибудь ОЗУ). Тем самым мы не привязаны к единственной версии CP/M, мы можем иметь их десятки (прошитыми в ROM-диск), причём не требуется для каждой из них иметь свой комплект дискет.
Подпрограммы в BIOS для чтения/записи лог.блока называются READ и WRITE. Они проще всего, если физ.сектор имеет размер в 128 байт, - тогда отпадает так называемая процедура деблокирования. Потому в VDISK-ах в деблокировании нет нужды, там сразу идёт чтение лог.сектора в 128 байт на DMA. А вот для дисководов и винтов физический сектор имеет размер в 512 или 1024 байта. Тогда приходится скачивать физ.сектор в дисковый буфер, и специальной процедурой копировать из него (или в него) на DMA лог.сектор в 128 байт (хотя пересылки делаются стеком, но всё-равно тормозит). Процедуру деблокирования Вам писать не надо, только чтение/запись физического сектора.
Для сравнения, RK-DOS работает физическими, а не логическими секторами, потому физический сектор там сразу читается на DMA (чтение в промежуточный буфер и пересылки отпадают). Из-за этого CP/M тормознее, чем RK-DOS в ~10 раз (даже с учётом того, что скорость обмена с дискетой у RK-DOS вдвое ниже из-за SD плотности).
Фирменным способом адаптация CP/M делается так (в литературе описано). По руководству от Digital Research, используя предложенный фирмой "скелетон", пишется CP/M-BIOS, в котором меняют только консольные и дисковые процедуры. После чего с помощью программы MOVCPM.COM сохраняют на диске DAT-файл CP/M настроенный на конкретные адреса BDOS и BIOS (что зависит от RAMTOP машины). Затем отладчиком встраивают в этот код свой самодельный CP/M-BIOS и затем любой программой, что позволяет читать/писать треки (обычно POWER-ом), записывают полученный блок CP/M на системные треки дискеты.
Но MOVCPM не работает с тем кодом BDOS и CCP, что был доступен в 1990 году. Может код исказился на пару байтов или ещё что. Читал, что те 6 байтов, что идут перед BDOS, в частности, использовались для идентификации конкретного кода CP/M (они также используются и CCP, для обнаружения затирания BDOS). Короче, MOVCPM нам не поможет.
Остаётся только вариант полноценно дизассемблировать CCP, BDOS и CP/M-BIOS чужой машины, изменить как надо CP/M-BIOS и затем странслировать заново под адреса уже конкретного железа. После этого, имея исходники, все дальнейшие адаптации под любое железо делаются очень легко. Потому говорить фразу "я сделал CP/M для XX-машины" неверно (это сделал Гарри Килдэлл), надо говорить "я странслировал CP/M". В качестве донора кодов использован Корвет.
В принципе мой вариант версий CP/M сложнее, чем просто странслировать базовые CCP, BDOS и BIOS, загрузить их холодным загрузчиком в ОЗУ на их адреса и сделать JMP WBOOT. Это совсем просто. Несколько усложняет мой блок стартёра, который добавляет сервис при старте и необходим, если в системе есть VDISK, который надо форматировать.
Трансляцию я делаю с использованием M80/L80 от Microsoft, т.к CP/M это модульная программа. Простой ассемблер (типа тех, что сами любители пишут для Windows), не поможет, даже если в исходнике убрать макро-команды, поменять лексику операторов из интелловской на моторолловскую и склеить все файлы в один огромный.
M80/L80 (кстати, как и большинство компиляторов ЯВУ) работают под TSR эмулятором CP/M для MSDOS, потому транслировать удобно в Windows XP, которая позволяет прогон MSDOS программ. Для более поздних Windows нужно использовать DosBox. Для трансляции нет необходимости вводить команды по одной, т.к MSDOS поддерживает BAT-файлы. Достаточно запустить вот такой BAT-файл. Т.к в CP/M компиляторы не меняют переменную окружения error level, то после каждого этапа делается остановка, чтобы глазами убедиться, что ошибок не было, иначе надо нажать ^C.
Здесь происходит сборка из 5-ти блоков, кроме стандартных CCP,BDOS,BIOS есть стартёр AUTO и драйвер VT52. Драйвера может не быть (в частности для обычного Специалиста его нет, т.к его там некуда грузить), тогда роль CONIN/CONOUT играют подпрограммы родного ПЗУ (при этом экранные CP/M-программы рассчитанные на VT52 не работают). Блока стартёра тоже может не быть, тогда надо грузить модули CCP+BDOS+BIOS на адрес CCP. Это не всегда возможно, например, ORDOS ОРИОНА не может загрузить, затирая сама себя. Потому блок снабжается стартёром и грузится максимально высоко (чтобы не затирать ОЗУ с адреса с $100, тогда после перезагрузки можно делать SAVE).
В оригинале CP/M с системных треков грузится несколько извращённо. Из-за чего порядок модулей на дискете не сплошной по адресации. Сначала там стоит CP/M-BIOS, далее CCP и BDOS. Это потому, что холодный загрузчик грузит с начальных треков дискеты лишь CP/M-BIOS и передаёт ему управление на начало, а это вход Cold Boot. После инициализации железа происходит переход на Warm Boot (WBT). По Warm Boot грузятся уже CCP и BDOS. Это несколько тормозит. Потому с 1994 я гружу с дискеты (или ещё откуда нибудь) CP/M одним сплошным блоком. Это даёт ускорение загрузки, как минимум, вдвое и преимущества.
В моих CP/M (и других DOS) добавлен блок AUTO. Это стартёр, он получает управление сразу же как только блок загрузился в ОЗУ холодным загрузчиком (с ROM-диска или с дискеты). Т.к в машине программы грузятся обычно в банку 0, то сначала, если это CP/M для другой банки, блок перекидывает себя в эту другую банку. Затем он раскидывает все модули на их рабочие адреса. В случае ОРИОНА и CP/M в банке 1, драйвер перегружается в банку 0 (где экран), а A+CCP+BDOS+BIOS перемещаются на адрес A, тем самым все блоки оказываются на своих рабочих адресах.
Затем блок стартёра сохраняет CCP+BDOS в буфере хранения, откуда в дальнейшем, они будут подкачиваться по горячему старту, и форматирует электронный диск (если ранее был установлен флаг его форматированности, то это, естественно, не делается). Если эл.диск отформатировался нормально, то он назначается диском A:, что нужно потому, что CP/M любит плеваться всякой гадостью именно на диск A:, потому если привод A: это дисковод, то дискета зазря будет изнашиваться записью при каждой загрузке и пакетном прогоне, и включить (или заклеить) защиту дискеты нельзя.
Затем стартёр делает попытку считать дискету в дисководе. Если флопа нет или не читается, то делается JMP WBOOT на горячий рестарт и происходит выход в CCP. Если же флоп читается, то там ищется файл с именем AUTOEXEC.SUB, его содержимое считывается и на диске A: (что уже м.быть эл.диск или дисковод) создаётся файл с именем $$$.SUB (т.к CCP имеет свойство запускать команды из этого файла и, пока все команды оттуда не обслужены, клавиатура не обслуживается).
Иногда (если нет ЭД с целью избежать записи на диск, т.к писать на дискету при каждой загрузке чревато быстрой дохлотой) обработка AUTOEXEC делается без $$$.SUB, т.к в моих CP/M-BIOS есть тимплет символов процедуры CONIN. Содержимое файла AUTOEXEC.SUB просто сливается туда и делается JMP WBOOT. Когда CCP начнёт работу он начнёт читать CONIN, который пока в тимлете что-то есть, будет выдавать на выход символы из тимплета один за другим (тимплет также используется, чтобы программировать функциональные клавиши, например, можно по нажатию F2 выдавать длинную команду на линковку). После получения в конце строки символа <ВК> CCP выполнит эту команду, как будто она введена с консоли (а на самом деле получена из файла AUTOEXEC.SUB) и так выполнятся все команды из файла AUTOEXEC.SUB.
В оригинальной CP/M конечно нет ни эл.дисков, ни резерва BDOS, ни обработки AUTOEXEC.SUB, ни использования RST. Большинство из этого делает добавленный крошечный модуль AUTO.ASM в 1 кб. В ранних версиях было обслуживание и файла CONFIG.SYS, это полезно, если надо одной и той же универсальной версией DOS обслуживать дисководы на 40, 35 или 80 дорожек, односторонние, двухсторонние. С 1992 это уже не надо. Если уж нужна поддержка ретро экзотики не проблема перетранслировать.
При адаптации на другую машину приходится менять модуль AUTO и модуль BIOS. Модуль AUTO в минимуме это просто LDIR - перекидыш CCP+BDOS+BIOS на адрес CCP и JMP WBOOT. А если есть эл.диск, то добавляется его форматирование. В конкретном примере CP/M Специалиста это инклюде EFORMAT.INC. Формат ЭД может быть очень медленным, когда работает функциями CP/M (это несколько секунд, что раздражает), но может быть просто заполнением банок ОЗУ кодом E5, что раз в 10 быстрее.
Для каждого лог.сектора эл.диска при его записи записывается КС (это сумма байтов с оффсетом), КС каждого сектора можно писать сразу после сектора (тогда секторный шаг 129 и сектора примыкают с разрывом в один байт), но лучше писать КС в отдельном буфере контрольных сумм (тогда файлы в ОЗУ в исходном виде). Оффсет подобран так, что КС сектора заполненного Е5 также равен Е5, потому заливка всего ОЗУ кодом Е5 эквивалентна медленному посекторному форматированию.
Т.к адаптация состоит в принципе из двух частей - из модификации CP/M-BIOS и из изготовления подрограмм записи/чтения сектора реальных физических устройств, то обычно я начинаю с отладки консольных процедур BIOS и общей работы CP/M (для машины с одной банкой это не так уж полезно, а вот когда CP/M для машины с банками и хитрым диспетчером памяти, лучше отлаживать по частям).
Для отладки общей работы модулей CP/M не нужен ни дисковод, ни большой эл.диск из доп.ОЗУ. Под эл.диск используем обычное основное ОЗУ. Можно отвести под VDISK сколько-то килобайт под RAMTOP, а CP/M загрузить ниже.
Конкретнее на примере Специалиста-Экспресс. У него есть сплошные 35.75 кб ниже 9000 и ещё "открытое ОЗУ" в 10 кб в адресах D000...F7FF. С целью отладки CP/M, отдаём 9 кб в окне D000...F7FF под эл.диск из ОЗУ (это в принципе то же основное ОЗУ). Но можно было выделить под ЭД и традиционное ОЗУ в адресах 6F00...8EFF, опустив RAMTOP для CP/M на 8 кб.
Из 9-ти килобайт один килобайт отнимет каталог, значит VDISK будет иметь полезный объём 8 кб. Этого хватит даже чтобы запустить DDT и ZSID. Эл.диск нам нужен не для использования, он просто должен быть, чтобы CP/M стартанУла (без диска она не может), так что можно отвести на VDISK всего 2 кб и даже стартануть совсем без него (тогда READ должна всегда читать сектор состоящий из E5). Цель такой версии лишь убедиться, что блоки правильно грузятся и консольные и простые дисковые подпрограммы BIOS работают. Берем файл VDISK.INC и изменяем его так, чтобы сектора хранились в основном ОЗУ с D000.
VDISK.INC
Code:
; VDISK в основном ОЗУ с BEGDSK размером в ETRK секторов
EDIWR: CALL CMPADR
EDIWR1: LD A,(DE) ADD A,C LD C,A PUSH BC ; К.С. LD A,(DE) LD C,A ; LD A,1 CALL WRAM POP BC INC HL INC DE DEC B JP NZ,EDIWR1
CALL ADRCHS LD A,BNKCHS CALL WRAM ; записать К.С. EDIWR2: XOR A RET
ADRCHS: LD A,(TRACK) ; высчитаем адрес для К.С. LD B,A INC B LD HL,PLCCHS-EPARM LD DE,EPARM EDW_01: ADD HL,DE DEC B JP NZ,EDW_01 LD A,(SECTOR) if SEC_N0 eq 0 DEC A endif AADDHL: ADD A,L LD L,A RET NC INC H RET
CMPADR: LD B,ETRK LD A,(TRACK) CP B JP NC,BADPOP
LD HL,BEGDSK-400H LD B,A INC B LD DE,400H CMPLOO: ADD HL,DE DEC B JP NZ,CMPLOO
LD A,(SECTOR) if SEC_N0 INC A endif LD DE,80H DDIS5: DEC A JP Z,DDIS4 ADD HL,DE JP DDIS5
DDIS4: LD BC,8065H ; Начальная контр.сумма EX DE,HL LD HL,(DMA) EX DE,HL RET
EDIRD: CALL CMPADR EDIRD1: PUSH BC ; LD A,1 CALL RRAM LD A,C POP BC LD (DE),A ADD A,C LD C,A ; контр.сумма INC HL INC DE DEC B JP NZ,EDIRD1
LD A,C PUSH AF CALL ADRCHS LD A,BNKCHS CALL RRAM POP AF CP C JP NZ,BADOP EDIRD2: XOR A RET
PLCCHS EQU 8F00H ; буфер хранения контрольных сумм секторов BNKCHS EQU 0 ; номер банки, где находится буфер хранения КС
BEGDSK EQU 0D000H EPARM equ 8 ; сколько логических секторов в треке ETRK equ (0F800H-BEGDSK)/400H ; всего уместилось треков в D000...F7FF
K_CPM equ 8 ; сколько лог.секторов в блоке EDSIZE equ (ETRK * EPARM) /K_CPM - 1
PUBLIC NUMEL
NUMEL: defb 255 ; если =FF, то VDISK - диск A: DEVE: DW 0 ; DPH для VDISK-а DW 0 DW 0 DW 0 DW DIRBUF DW DPB03 DW 0 DW ALL03
DPB03: DW EPARM ; * КОЛИЧ-ВО ЛОГИЧ.СЕКТОРОВ ПО 128 БАЙТ НА ТРЕКЕ defb 3 ; * РАЗМЕР БЛОКА (3- 1K ,4- 2K) defb 7 ; * РАЗМЕР БЛОКА (7- 1К ,15- 2K) defb 0 ; * РАЗМЕР ЭКСТЕНТА (0- 16K) DW EDSIZE ; * РАЗМЕР СВОБОДНОГО ПРОСТРАНСТВА В БЛОКАХ DW 1FH ; * КОЛИЧЕСТВО ЗАПИСЕЙ В КАТАЛОГЕ минус 1 defb 080H ; * МАСКА ЗАНЯТЫХ БЛОКОВ (high) defb 00H ; * МАСКА ЗАНЯТЫХ БЛОКОВ (low) DW 0 ; * КОЛИЧЕСТВО КОНТРОЛИРУЕМЫХ СЕКТОРОВ DW 0 ; * КОЛИЧЕСТВО РЕЗЕРВНЫХ ДОРОЖЕК
В этом драйвере VDISK-а всего 4 подпрограммы: записать сектор EDIWR, считать сектор EDIRD и вспомогательные подпрограммы CMPADR, рассчитывающая по TRACK и SECTOR адрес хранения сектора в ОЗУ D000, служащим эл.диском и ADRCHS рассчитывающая адрес, где хранится КС текущего (записываемого/читаемого) логического сектора (в области PLCCHS в банке BNKCHS).
Параметры эл.диска видны: 8 секторов по 128 байт на треке, т.е в каждом треке 1024 байта. ETRK это число треков по 1К, что умещается в ОЗУ D000...F7FF. EDSIZE это размер диска в блоках (размер блока выбран 1К, это 8 лог.секторов). Всё что требуется при модификациях под конкретный диск (неважно ЭД или дискетный) это подставить числа, остальное из параметров CP/M ассемблер сам рассчитает. PLCCHS и BNKCHS это адрес и номер банки, где хранятся контрольные суммы секторов (обычно это в других банках, но здесь только банка 0). В данном случае число секторов 72 и они все умещаются с адреса 8F00 в основной банке 0.
Сделав таким образом VDISK.INC уже можно было бы странслировать CCP+BDOS+BIOS. Но VDISK при старте CP/M нуждается в форматировании. Потому CP/M с VDISK-ом не обойдётся без модуля A.ASM. В нём нам надо изменить только процедуру формата, которая целиком в инклюде файле EFORMAT.INC.
FORMAT: LD SP,STK2 .RST18 defb ' FORMAT 9','K' OR 80H CALL FORMVD .RST18 defb 8,8 OR 80H JP TEST
FORMVD: ; ПОДПРОГРАММА .RST18 defb 1BH,59H,32+1,(32+22) OR 80H
LD HL,ADRTYP LD C,VDTYPE ; LD A,BNKTYP CALL WRAM
LD C,N_EDSK CALL BSELDSK
CALL HOME CALL BDMA80
LD HL,80H LD A,L FRMT1: LD (HL),0E5H INC HL DEC A JP NZ,FRMT1 WRLP1: LD (NTRK),A CP ETRK RET NC
LD C,A CALL BSETTRK
LD B,EPARM LD C,1
WRLP2: PUSH BC CALL BSETSEC CALL EDIWR POP BC OR A RET NZ INC C DEC B JP NZ,WRLP2
defb 3EH ; LD A,(NTRK) NTRK: DS 1 INC A PUSH AF
DEC A LD B,'9'+1 CNT1: DEC B ; CY не меняет SUB 1 ;5 ; ставит CY JP NC,CNT1
CNT2: LD A,B
PUSH AF RST 10H EMIT 8 POP AF
LD BC,4000H JJJ_01: LOOP JJJ_01
POP AF JP WRLP1
CLIK: LD HL,PPA+3 LD BC,0410H CLK1: LD A,B CLK2: LD (HL),00001011B DEC A JP NZ,CLK2 LD A,B CLK3: LD (HL),00001010B DEC A JP NZ,CLK3 DEC C JP NZ,CLK1 RET
HOME: CALL BHOME LD C,1 JP BSETSEC
BDMA80: LD BC,80H JP BSETDMA
Обратите внимание на подмену векторов ошибок BDOS, это надо чтобы в случае ошибки BDOS, не вываливаться в CCP (как бывает в программах дилетантов в случае дисковых ошибок). Перед выходом из процедуры форматирования VDISK-а вектора ошибок BDOS восстанавливаются. Видно, что перед форматированием делается попытка читать с эл.диска. Если это удаётся, то проверяется, что тип эл.диска (VDTYPE) тот же самый, что поддерживает данная версия. Это надо, когда версий DOS много.
Code:
ADRTYP EQU 8F00H + (ETRK * EPARM) ; это за концом блока КС BNKTYP EQU 0 VDTYPE EQU ETRK
Если эл.диск читается и тип формата тот же, то выполняется тест диска. Если диск форматирован в иной DOS или не читается, то выполняется формат эл.диска, а по окончании делается тестирование. Если VDISK исправен, то он назначается диском A:, а привод B: достаётся дисководу с РК-КНГМД. Если же VDISK-а нет, то привод A: - дисковод с РК-КНГМД. Не считая настройки подпрограмм BIOS и задания констант в хеадере PARAMS.INC, это в принципе всё, что достаточно, чтобы странслировать пробную CP/M для Специалиста. Вот какой BIOS был в этой стартовой версии двух летней давности:
BIOS для CP/M-36К
Code:
; CPM-BIOS СПЕЦИАЛИСТА 36К .Z80
PUBLIC BSETTRK,BSETSEC, BSELDSK, BSETDMA, BHOME PUBLIC RESET, WBT, EDIRD, EDIWR, ERRTON, PILIK, SCOUTA PUBLIC SUMMA, DSKNEW, DSKNAM, POPREG, CLRLOC PUBLIC LENGTH, RRAM, WRAM, RUSLAT, @LDIR, CHSUM
include LOCKS.INC include PARAMS.INC include MACRO.INC
SETSEC: LD A,C if SEC_N0 DEC A endif LD (SECTOR),A RET
;--------------------------------------------
HOME: LD C,0 SETTRK: LD A,C LD (TRACK),A DUMMY: RET
;--------------------------------------------
SETDMA: LD H,B LD L,C LD (DMA),HL RET
;--------------------------------------------
CONST: CALL CHKSYS defb 3EH ; LD A,(FLSIO) FLSIO: defb 0 OR A JP Z,CNSTL1 ; Если цикл завершен то проверка готовности CALL CNSTL2 LD A,0 JP Z,CNSTL3 ; Если клавиатура не готова то сброс флага LD A,(FLSIO) DEC A ; Уменьшение счетчика CNSTL3: LD (FLSIO),A XOR A RET
CNSTL1: CALL CNSTL2 INC A RET Z RET_FF: LD A,0FFH RET
ESC_6B: defb 21H ; вернуть позицию курсора TMPKOO: DS 2 ESC6B1: LD (V_CUR),HL JP RESESC
; ----------------------------------------------
ESC_4B: LD HL,(V_CUR) ; очистка до конца строки PUSH HL LD A,H OR A RRA OR A RRA LD H,A LD A,64-1 SUB H ESC4B0: LD B,A ESC4B1: CALL BSPACE POP HL JP ESC6B1
; ----------------------------------------------
ESC_6C: LD A,(V_CUR) ; очистка строки LD L,A LD H,90H LD C,64 XOR A ESC6C1: LD E,L rept 7 LD (HL),A DEC L ENDM LD (HL),A LD L,E INC H DEC C JP NZ,ESC6C1 LD H,A JP ESC6B1
; ----------------------------------------------
BSPACE: LD C,20H CALL MCOUT DEC B JP NZ,BSPACE RET
; ----------------------------------------------
ESC_54: LD (HL),0 ; ролик вниз LD A,C ADD A,A ADD A,A ADD A,A ADD A,C ADD A,C LD C,A LD HL,0 ADD HL,SP LD (TMPSTK),HL LD H,90H LD B,30H OBR1: LD L,251 LD SP,HL LD L,240 LD A,C CP L JP Z,OBR4 OBR2: LD D,(HL) DEC L LD E,(HL) DEC L PUSH DE CP L JP NZ,OBR2 OBR4: LD D,H LD HL,(INVERS) rept 5 PUSH HL endm LD H,D INC H DEC B JP NZ,OBR1
DRVRET: defb 31H TMPSTK: DS 2 RET
;--------------------------------------------
GOCONI: LD A,255 LD (FLSIO),A LD DE,MCONIN
; Подпрограмма связи с драйвером (нужна для перестановки стека) ; Вход: DE - адрес вызова, HL портит
; ВХОД: C - номер диска (0 - A:,1 - B:) ; ВЫХОД: HL - адрес блока адресов переменных диска или ; HL=0, если диск не существует или не готов
SELDSK: PUSH BC CALL FLUSH POP BC JP NZ,BAD SET0 GETFLG
LD A,C LD (DEV),A OR A LD HL,DEVE RET Z
DEC A JP NZ,NODISK
LD A,(FLAGA) INC A CALL NZ,RDNAME ; настройка на формат диска LD HL,DEVA RET Z NODISK: LD HL,CURDEV LD A,0F0H AND (HL) ; устанавливаем DISK=0, USER не меняем LD (HL),A XOR A LD H,A LD L,A ; HL=0 LD (FLAGA),A RET
@BIOSIZ EQU @ENDCOD-BIOS if @BIOSIZ gt BIOSIZ if1 .printx * BIOSIZ over ! endif endif
ZZZ aset $-BOOT
if ZZZ and 0FH LENGTH EQU (ZZZ and 0FFF0H) +10H rept 10H-(ZZZ and 0FH) defb 0 endm else LENGTH EQU ZZZ endif
DW 0EEEEH
if @ENDCOD gt (BIOS+BIOSIZ) if1 .printx * CODE over BIOS_TOP ! @OVER aset @ENDCOD - (BIOS+BIOSIZ) endif else if @ENDCOD eq (BIOS+BIOSIZ) if1 .printx * Totally fit in code size ! * endif else @FREE aset (BIOS+BIOSIZ)-@ENDCOD endif
endif
if PLACE+LENGTH gt BOOT if1 .printx * CODE at PLACE over BOOT ! @SHIFT EQU PLACE+LENGTH - BOOT endif endif .dephase
YY EQU (20H+LENGTH) and 7FH
rept 80H-YY+9 defb 0FFH endm
END
Эта версия конечно, не для работы, а просто стартовая. В ней далее надо заняться увеличением TPA (подняв код CP/M в верхнее ОЗУ) и увеличить VDISK используя банки. Вот пара скриншотов работы этой стартовой версии в эмуляторе EMU80 (с доработанным конфигом): при загрузке формат VDISK-а, загрузка с МГ-ленты.
Т.к ПЗУ Специалиста, не обрабатывает даже минимальный набор искейп-команд, то как видите, ввиду отстутствия драйвера, пришлось их эмулировать. Для чего на входе CONOUT отлавливается код 27. Этот эмулируемый набор искейп-кодов позволяет пользоваться текстовым редактором WM.COM. Есть даже коды для аппаратных роликов, что резко ускоряет текстовые редакторы. Из подпрограмм ПЗУ Специалиста используются только C803, С809 и C81B.
В этой версии использующей под VDISK только основное ОЗУ, под буфер хранения CCP+BDOS использовано $1600 байтов с адреса $7510. В итоге, в этой версии для TPA остаётся менее 24 кб.
Во всех моих DOS (не только CP/M) есть RST-входы. Содержимое файла RST.INC по горячему старту кидается на адрес 0008. Потому RST в CP/M доступны всегда, хотя некоторые отладчики портят RST 30 (но по WBOOT всё восстанавливается). Чаще всего используются функция RST 18. Это аналог MSSG C818, но текст располагается сразу за командой RST и останов не только по 0, но и по символу с выставленным старшим битом (в некоторых моторолловских ассемблерах есть оператор похожий на DEFB, но выставляющий старший бит у последнего символа). А с М80, чтобы выставить старший бит последнего символа приходится писать 'буква' OR 80H. Такой вывод экономит байты, (экономия в 5 байтов на каждом вызове), а данная конкретная версия (со стопом по биту D7=1) не позволяет КОИ-8 (но это и не надо для системных сообщений, тем и фонта КОИ-8 нет).
Т.к в специалистовском ПЗУ вывод лишь в КОИ-7, а для CP/M нужны и мелкие латинские буквы, то добавлена загрузка мелких латинских букв (на 8B00, а выше дисковый буфер 512 байт для РК-КНГМД). Чтобы не грузить заглавные латинские буквы, раз уж они и без того есть в ПЗУ (экономия $200 байтов), драйвер CONOUT при получении символа с кодом выше $60 переставляет адрес фонта (8FE5, он там делённый на 8 ) на загруженный в ОЗУ фонт мелких латинских букв. Естественно, чтобы не тратить объём в BIOS, перекидыш фонта (LFONT.INC) на 8B00 делает стартёр, а не сам BIOS.
Теперь о добавленных в CP/M-BIOS подпрограммах. Они добавляются в мои DOS с 1994. Подпрограмма DSKNEW BIOS+33 нужна для машин у которых не один формат дискеты, а много. Эта подпрограмма вызывается ф-цией BDOS дисковый RESET. DSKNEW настраивает BIOS на формат текущего диска. BIOS+36 и BIOS+39 это RRAM и WRAM, аналоги п/п-рамм ОРИОНА предназначеные для доступа в ОЗУ других банок. Именно этими подпрограммами (и только через них) организуется VDISK. BIOS+3C это DSKNAM, возвращает имя дискеты, для чего читаются 11 байтов из BOOT-сектора. И BIOS+3F это ERRSND противный звук выводимый при ошибках.
Отладив CP/M с таким простейшим VDISK-ом из основного ОЗУ, т.е работу VDISK-а и консольные функции, далее уже совсем просто перетранслировать CP/M с размещением CCP+BDOS+BIOS в верхнем ОЗУ в области D000...F7FF и VDISK-ом уже не из основного ОЗУ, а из ОЗУ других банок.
Получится CP/M почти такая же как использовалась на Специалистах в начале 90-тых (тогда естественно были только дискетные приводы, VDISK-а не было). Я это (версию с доп.банками) отладил не в реале, а в эмуляторе EMU80, куда его автор Pyk любезно добавил другие банки ОЗУ по 62 кб (как в Специалист-MX), но коммутиремые как в ОРИОНЕ по OUT F9.
Не обязательно транслировать CP/M с VDISK-ом, можно упростить BIOS и стартёр, выкинуть VDISK и использовать дискетные подпрограммы для РК-КНГМД. Для этого достаточно закомментировать include VDISK.INC и отредактировать п/п-мму SELDSK. Тогда единственным приводом (A:) будет дисковод с РК-КНГМД, а эл.диска совсем не будет.
Но в любом случае для любых интересантов будут полезны готовые исходники CCP, BDOS и рабочий BIOS Специалиста, все без Z80-команд. Здесь CCP почти оригинал (добавлена лишь команда CLS). Для Z80 у меня есть улучшенные CCP. В принципе, как пример для трансляции лучше использовать более простой вариант (без эл.диска, AUTOEXEC-а, с упрощённым BIOS), чисто дискетную версию. Может сделаю. Есть кстати и CP/M для РК86, но она тоже с эл.диском.
По ссылке можно скачать исходник этой стартовой версии CP/M для Специалиста с VDISK-ом в 9 кб (из основного ОЗУ) и TPA в ~24 кб (работает с любым ПЗУ C000). Чтобы получить RKS-файл CP/M достаточно запустить BAT-файл, компилятор в папке уже есть. Если не Win XP, то под DosBox.
В папку по ссылке также добавил исходник копировщика файлов на одном дисководе, - этого мне очень не хватало в 1990/91, приходилось копировать POWER-ом (загружаем файл с 4000 по LOAD, затем меняем диск, ^C и SAVE под тем же именем). К сожалению, т.к POWER сам здоровый в ~16 кб, а TPA в базовом Специалисте всего 35.5 кб, то с ним мне удавалось копировать файлы размером лишь до 20 кб (позднее я использовал ZSID3, который имел размер всего в 9.5 кб, что позволяло с его помощью копировать файлы аж в 26 кб). Для копирования файлов весной 1991 мне пришлось купить второй дисковод 5311. А первый копировщик файлов на одном дисководе появился лишь в самом конце 1991.
Кстати и вторая версия CP/M тоже промежуточная, использовалась для тестирования работы эмулятора с поддержкой других банок. VDISK в 32 кб в ней потому что, сначала в эмуляторе была сделана коммутация банок лишь до 8000. После это было исправлено и была странслирована версия с VDISK-ом в 500 кб (препятствий для 2 мб тоже не было). Но недавно у меня винт сдох и многое утратилось или не под рукой (в архивных носителях).
Я уже позабыл как конфигурировать EMU80, чтобы были доп.банки ОЗУ, а эмулятора и старых конфигов для этого уже нет. Забыл даже назначение бита D7 порта F9. "Открыть ОЗУ" D000...F7FF я смогу, а вот сходу разобраться как сделать доп.банки вряд-ли быстро смогу. Надо читать переписку с автором. Вообще, всем нужно иметь собственные эмуляторы, чтобы не зависеть...
UPD. Версию EMU80 с поддержкой банок всё-же удалось найти на архивном CD-RW (правда пока не знаю окончательная ли это версия банковости с окном в 62 кб или предшествующая, лишь с окном в 48 кб). Так что вскоре, наверное, странслирую CP/M Специалиста с эл.диском в ~400 кб, а может быть даже оригинал CP/M Специалиста из 1990 года с КНГМД на ВГ93 (но это можно прогнать только в EMU). И может быть также чисто для примера скомпоную простой классический вариант CP/M из 3-х модулей.
Тема, то что надо! Я хоть и читал описание ср/м, да и Роботрон-1715 у меня был какое то время на первом курсе с принтером, надо все выше написанное переварить и осознать. Однако, в целом, у меня план такой, запустить систему в эмуляторе emu с SD на стандартном Специалисте, в варианте когда система живет в ПЗУ (0xD000 -...). Далее сделать доработку по открыванию с перекидыванием ОЗУ из под адресов ПЗУ и УВВ, так же, отладив это под emu, да, ну и в Протеусе. Для cp/m идея с перекидыванием отличная. И на финальном этапе провести все эксперименты с реальным железом. [На вопрос зачем все это нужно? отвечу так - ровно затем, зачем мы в принципе занимаемся нашими древними компьютерами - интересно и разминка для мозгов...]
Что касается SD. для SD интерфейса нужно два адреса, SD_CONF_PORT - один бит, включение и выключение чипселекта карты и SD_DATA_PORT - данные в и из карты. Для работы с картой ее нужно предварительно инициализировать. Соответственно, в каком месте этот инит правильнее всего разместить в cp/m? Для начала можно использовать простейший инит, который работает и в emu и в Протеусе, без поддержки SDHC карт (те, больше 4ГБ). В финальной же версии можно будет добавить поддержку SDHC карт, а для этого нужно зарезервировать одну ячейку памяти, для хранения типа карты (по факту - один бит), тк это используется в функции расчета номера сектора SD карты. Эта ячейка должна сохраняться до следующей процедуры инициализации. А где ее разместить в cp/m для меня следующий, и очень большой, вопрос...
Дальше куски кода из SDOS, в мнемониках ВМ80, (для Z80 они, так же есть, в ветке про msx)
Code:
SD_INIT: CALL SD_OFF MVI B,10h CALL SD_FIN DCR B JNZ $-4 CALL SD_ON MVI C,040h ;CMD0 CALL SD_CMD CPI 1 RNZ SDI_L1: MVI C,041h ;CMD55 CALL SD_CMD ANI 0FEh RNZ MVI C,041h ;ACMD41 CALL SD_CMD CPI 1 JZ SDI_L1 ORA A RET в флаге Z признак, есть ошибка при ините карты или нет. после инита чипселект карты можно выключать и включать только когда идет к ней обращение.
для работы инита и последующей работы с картой еще нужны такие подпрограммы:
Code:
SD_ON: MVI A,01h JMP SD_CONF SD_OFF: MVI A,00h SD_CONF: STA SD_CONF_PORT RET
SD_FIN: MVI A,0FFh SD_PUT: STA SD_DATA_PORT RET
SD_GET: CALL SD_FIN LDA SD_DATA_PORT RET SD_CMD: LXI H,0 SD_CMDW:LXI D,0 SD_CMDD:CALL SD_FIN MOV A,C CALL SD_PUT MOV A,D CALL SD_PUT MOV A,E CALL SD_PUT MOV A,H CALL SD_PUT MOV A,L CALL SD_PUT MVI A,95h CALL SD_PUT LXI D,8080h SD_WAIT:LXI H,20000 SDW_L1: CALL SD_GET MOV C,A SUB D CMP E MOV A,C RNC DCX H MOV A,H ORA L JNZ SDW_L1 SUI 1 RET и такие дефайны: CMD0 EQU 040h | 0 ; resets the card CMD17 EQU 040h | 17 ; read block CMD24 EQU 040h | 24 ; write block CMD55 EQU 040h | 55 ; next command is ACMDxx ACMD41 EQU 040h | 41 ; send host capacity support, init card
дальше работа с секторами:
Code:
SD_READ: ;сектор для чтения в DEBC, адрес для сохранения данных в HL PUSH H call SD_RWR JC POPHRET MVI C,CMD17 CALL SD_CMDD ; чтение блока в 512 байт, сектор для чтения в формате карты в DEHL JC POPHRET LXI D,0FF01h CALL SD_WAIT POP H CPI 0FEh RNZ MVI B,0 SDR_L1: CALL SD_GET MOV M,A INX H CALL SD_GET MOV M,A INX H DCR B JNZ SDR_L1 CALL SD_FIN ; добиваем еще два пустых байта CRC CALL SD_FIN RET
SD_WRITE: ;сектор для записи в DEBC, адрес данных для записи в HL PUSH H call SD_RWR JC POPHRET MVI C,CMD24 ;запись блока в 512 байт, сектор для записи в формате карты в DEHL CALL SD_CMDD JC POPHRET POP H MVI A,0FEh ; отправляем подтверждение CALL SD_PUT MVI B,0 SDR_WL1: ;отправляем 512 байт MOV A,M INX H CALL SD_PUT MOV A,M INX H CALL SD_PUT DCR B JNZ SDR_WL1 CALL SD_FIN ; добиваем еще два пустых байта CRC CALL SD_FIN ora A RET
POPHRET:POP H RET SD_RWR: ; расчет номера сектора SD карты PUSH D PUSH B LXI D,0FFh CALL SD_WAIT POP B POP H RC ; LDA SDTYPE ; переменная в которой тип SD карты ; CPI 00h ; JZ SD_RWR0 ; переход если карта обычная SDC ; mov E,C ; MVI D,0 ;SDHC... ; stc ; cmc ; ret ;SD_RWR0: MOV A,C DAD H ADC A MOV D,A MOV E,H MOV H,L MVI L,0 RET
для первого запуска, я так понимаю, этого достаточно, а вот далее надо будет думать.
На SD карте формат разделов изначально отсутствует, и система должна сама ее разметить. Опять же, для первого запуска можно игнорировать размер сектора в 512 байт и использовать только первых 128 байт из 512 (не делать процедуру деблокирования). В финальной же версии хочется иметь образ cp/m системы в файле на разделе fat16, используя механизм назову его так 'косвенное монтирование'. Здесь, https://zx-pk.ru/threads/29690-sd-karta ... ctrum.html , я уже озвучивал подобную идею, модифицирую ее. Используем список указателей на сектора носителя с нужным образом cp/m, и при монтировании этот список указателей просто актуализируем. Объем данных, которые надо обработать существенно меньше, запись выполняется автоматически в правильном месте на носителе и никакое размонтирование не требуется. Для SD размер сектора 512 байт, если используется файловая система FAT16, то для раздела больше 256МБ размер кластера 8КБ, и это нам дает такой расклад - получив один номер сектора - указатель ( а это 4 байта), можно адресовать непрерывных 8КБ данных (не нужно заботиться о фрагментированных файлах образов). Файл указателей занимает как минимум один кластер (условимся, что только один кластер), те 8КБ непрерывных данных. В одном 8и Кбайтном кластере можно записать 2048 четырех байтных указателя на образ, где один указатель это 8КБ данных, те получится 8кб*2048=8МБ - это максимальный размер образа в таком раскладе. Этот Файл указателей будет храниться в простом бинарном файле - базе_указателей - на файловой системе рядом с образом! (один файл образ, и соответствующий ему файл базы указателей). При монтировании образа будет определяться номер первого сектора с данными файла базы_указателей и сохраняться куда то на носитель, в некий сектор. Вот куда эти четыре байта сохранять это вопрос, к примеру, здесь и далее, 1й сектор... Итог, как все должно работать - при монтировании, программа монтировщик ищет файл базы_указателей, вычисляет номер сектора с данными указателей и сверяет со значением в первом секторе по оговоренному смещению, при не совпадении актуализирует. После чего выполняет запись указателей монтируемого образа с шагом в 8КБ в файл базы_указателей. Все, монтирование выполнено! В системе cp/m, работа с образом выглядит так - на входе функции обращения к диску мы имеем номер сектора, стороны и трека диска, вычисляем по этим данным позицию нужного сектора в образе и дальше используя лишь функцию чтения сектора носителя, читаем наш некий (первый) сектор, вычитываем 4 байта указателя для начального сектора файла базы_указателей, читаем сектора с базой_указателей, по базе находим место с запрошенным сектором данных в образе, читаем(пишем) запрошенный сектор, все! Таким образим на чтение(или запись) требуемых данных выполнится - чтение некого(первого) сектора, сектора с базой и сектора с требуемыми данными для ПК. Чтение первого сектора можно опустить, запомнив эти 4 байта. Программу монтирования(на базе xsd) по алгоритму описанному выше я уже сделал, и вычитку данных по сектору базы_указателей на СпециалистеМХ уже отладил...
14 Nov 2019 14:07
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
Программу монтирования(на базе xsd) по алгоритму описанному выше я уже сделал, и вычитку данных по сектору базы_указателей на СпециалистеМХ уже отладил...
Вобще говоря, если есть работающий именно Специалист_МХ (два банка памяти по 64 К), то CP/M можно поставить на него более удачно и без особых аппаратных переделок.
CP/M работает во второй странице памяти, где нет экранного ОЗУ, и ничто ей не мешает использовать память по максимуму. Первая страница с экранным ОЗУ и BIOS Специалиста притворяется терминалом и не мешает CP/M.
Вобще говоря, если есть работающий именно Специалист_МХ (два банка памяти по 64 К), то CP/M можно поставить на него более удачно и без особых аппаратных переделок.
А ставить то что, cp/m, работающую с дисководом? такое уже существует, не интересно. У меня есть желание использовать SD карту в качестве носителя и ни каких дисководов. Еще хочется иметь простой способ обмена файлами между этой cp/m и 'большим ПК', используя fat16. Значит нужно разобраться как к cp/m добавить SD карту, а на какой машине это будет потом работать уже не будет иметь принципиального значения. Будут исходники, в которых нужно будет только поправить адреса загрузки и все! Для этого и нужна эта тема.
Я в РАМФОСе сделал правки для поддержки SD, но понял, что это бесперспективно, тк нужно уложиться в строго выделенные адреса, выбрасывая часть функционала, и тогда от РАМФОСа ничего не остается, кроме именно загрузчика с карты. Дальше больше, что грузить, какую ОС? тот же cp/m или МХДОС, но их, так же, надо обучить работе с SD! Так что версия ОС, находящаяся в ПЗУ, и умеющая работать с SD, выглядит очень привлекательно.
15 Nov 2019 02:44
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
Вобще говоря, если есть работающий именно Специалист_МХ (два банка памяти по 64 К), то CP/M можно поставить на него более удачно и без особых аппаратных переделок.
А ставить то что, cp/m, работающую с дисководом? такое уже существует, не интересно. У меня есть желание использовать SD карту в качестве носителя и ни каких дисководов.
Ну я и не навязывал cp/m, работающую с дисководом, просто заметил, что так аппаратно проще и TPA - больше. При этом Специалист_МХ им самим и остаётся. А привязку к SD карте в качестве носителя вам придётся делать в любом случае.
_________________ iLavr
15 Nov 2019 06:51
fifan
Devil
Joined: 06 Oct 2006 03:17 Posts: 859 Location: г.Лянтор,Сургутского р-на,ХМАО
что грузить, какую ОС? тот же cp/m или МХДОС, но их, так же, надо обучить работе с SD! Так что версия ОС, находящаяся в ПЗУ, и умеющая работать с SD, выглядит очень привлекательно.
А я научил работать систему с SD картой. Новую ОС я назвал MX-DOS (по аналогии с DOS, работающей с дискетой в Специалисте МХ) и присвоил ей версию 4. Новая ОС грузится с ROM-диска под RAMFOS'ом 6.4 и подменяет последнюю при обращении к SD карте.
PVV ваяет свою поддержку SD карты программно и ПО занимает несколько килобайт. Я же использую уже готовые вызовы подпрограмм от Vinxru с соответствующей железкой.
P.S. только сейчас заметил, что всё это пишется в рубрике Ориона, кто это увёл в сторону разговор? Наверное часть постов нужно переместить в Специалист?
15 Nov 2019 23:39
aav8
Maniac
Joined: 05 Nov 2008 19:47 Posts: 287 Location: 81.28.208.238
Так что версия ОС, находящаяся в ПЗУ, и умеющая работать с SD, выглядит очень привлекательно.
У меня получилось запустить CP/M из ПЗУ. Правда довольно кривовато. Но странслировать/слинковать программу получилось (M80/L80). В качестве накопителя - Windows(серверная программа) через COM порт.
16 Nov 2019 03:04
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
PVV ваяет свою поддержку SD карты программно и ПО занимает несколько килобайт. Я же использую уже готовые вызовы подпрограмм от Vinxru с соответствующей железкой.
P.S. только сейчас заметил, что всё это пишется в рубрике Ориона, кто это увёл в сторону разговор? Наверное часть постов нужно переместить в Специалист?
Ну коллега же сразу пояснил:
PVV wrote:
На вопрос зачем все это нужно? отвечу так - ровно затем, зачем мы в принципе занимаемся нашими древними компьютерами - интересно и разминка для мозгов...
Пусть так и будет, если ему интересно сделать по-своему.
_________________ iLavr
16 Nov 2019 04:53
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
Чисто из интересу: а что из программ CP/M вы используете с пользой для себя?
Я к тому что у меня есть CP/M для "Специалиста", но за много лет из её ПО не пришлось использовать ничего. В то же время пакет RAMFOS для "Специалиста" в качестве IDE ассемблера 8080 я использую часто и по сей день.
_________________ iLavr
16 Nov 2019 05:01
Alekcandr
Doomed
Joined: 01 Oct 2007 10:30 Posts: 665 Location: Ukraine
Не, то, что предложил Lavr, конечно интересно для буржуев образца 79г. Но не в этом сила CP/M была в 85-95г. для наших людей (вот тут можно …., но не стоит ) .
не в этом сила CP/M была в 85-95г. для наших людей ...
Да вы что? Какая там CP/M была в 85-95г. для наших людей? Не было CP/M в 85-95г. для наших людей, как меня тут убеждали!
P.S. И, кстати, не я это предложил для каких-то буржуев образца 79г., а сделал это Александр Шевцов как раз для наших людей ...
Attachment:
cpm.gif [ 1.56 KiB | Viewed 10287 times ]
Сабж как звучит? Как получить CP/M для своего железа. Так вот для "Специалиста_МХ" - это самый оптимальный вариант CP/M, на мой взгляд, с учетом наличия драйвера 80 символов в строке.
_________________ iLavr
16 Nov 2019 17:26
Alekcandr
Doomed
Joined: 01 Oct 2007 10:30 Posts: 665 Location: Ukraine
Если речь о установке СР/М во вторую банку озу, то это нормально. Вот для Орион-128 нужно 256кБ, что бы такое провернуть. Хотя нормально это так себе. Для MSX нужно всего 64кБ без танцев с бубнами, вот это действительно нормально.
А так то я немного о другом говорил. Когда предложили брать ПО для СР/М и адаптировать его локально под существующие подпрограммы монитора. Теряется весь смысл СР/М от таких телодвижений. По мне не оспоримым плюсом СР/М является возможность собирать программы значительно превышающие доступное озу в машинке.
Когда предложили брать ПО для СР/М и адаптировать его локально под существующие подпрограммы монитора. Теряется весь смысл СР/М от таких телодвижений.
Я почему и спросил там выше коллегу: а что из программ CP/M вы используете с пользой для себя?
Так случилось, что из программ CP/M я лично использовал SID и ZSID на "Микроше" и "Специалисте". Но лишь до пакета RAMFOS, в нём собственный DEBUG пракически повторяет возможности SID. Так что смысл совсем не теряется, но и громадного профита нет...
_________________ iLavr
18 Nov 2019 12:00
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Ладно, не проблема, - пусть эта тема будет широкой для обсуждения разных моментов при использовании на 8-ми разрядке CP/M и других DOS (это намёк, что давно пора написать для Специалиста, ОРИОНА и РК примитивную DOS для ВГ93 имеющую размер всего в 2 кб - если пользователю нужны только цельно-файловые LOAD/SAVE, то это ничуть не хуже, чем сложная DOS с подкаталогами размером в 15 кб).
Я тут три дня разбирался в эмуляции дисковода на ВГ93 в эмуляторе EMU80 от Pyk. Ведь пример инсталляции CP/M на VDISK из излишнего ОЗУ ЭВМ (и где п/п-ммы чтения записи блока в 128 байт просты) это не для реального использования (хотя, если VDISK достаточно большой, то файлы можно закачивать с линии). Совсем другое дело, как и было в своё время, встроить CP/M в машину, где всего лишь 64 кб и в качестве носителя возможен лишь физический дисковод.
Вскоре я изменю первый пост, упростив его. Приведу вариант трансляции самого классического варианта CP/M. И на ОРИОН, т.к некоторых не устраивает, что пример приведён для Специалиста. На ОРИОН проще, там и ОЗУ больше и п/п-ммы в ПЗУ для доступа к излишнему ОЗУ уже имеются.
Для Специалиста потому, что спрашивающего интересовал именно Специалист и мне так проще, т.к для ОРИОНА я не транслировал десяток лет, а для Специалиста странслировал лишь пару лет назад и все промежуточные исходники под рукой. А в-третьих, писать в разделе Специалиста я просто не могу, там слишком злонамеренная против меня модерация (и пока это не изменится я вынужден писать про Специалист в других разделах).
В ближайшие дни создам ещё несколько тем о трансляции CP/M для ОРИОНА, Специалиста и РК86, всё проверенное на эмуляторе EMU80, он нормально эмулирует и КНГМД реализованный на БИС ВГ93 и программный РК-КНГМД. Чтобы любой мог поставить CP/M не напрягаясь.
Lavr wrote:
Вобще говоря, если есть работающий именно Специалист_МХ (два банка памяти по 64 К), то CP/M можно поставить на него более удачно и без особых аппаратных переделок
Увод от темы. Изначально речь шла о базовом Специалисте. Естественно, в машинах, где немеряно банок ОЗУ под VDISK и есть сплошное ОЗУ в 60/62 кб не нужны доработки, чтобы поиметь CP/M с хотя-бы минимально приемлемым размером TPA.
Lavr wrote:
Первая страница с экранным ОЗУ и BIOS Специалиста притворяется терминалом и не мешает CP/M
Точно. ОРИОН и его пародия Специалист-MX удобны не только наличием большого сплошного ОЗУ, а тем, что драйвер экрана удобно размещается в банке с экраном и не отнимает ОЗУ у CP/M (а качественный драйвер для графического экрана большой - 6...12 кб).
Lavr wrote:
что из программ CP/M вы используете с пользой для себя?
Если нет задачи транслировать на 8-ми разрядке, то используется лишь файловая система, т.е читаем/запускаем чужие и пишем свои файлы (а если для CP/M уже есть нортон, то и это полезно).
Lavr wrote:
И, кстати... сделал это Александр Шевцов как раз для наших людей...
Да, он в 1994 конвертировал её для Специалиста-MX версию CP/M для ОРИОНА от МП ОРИОН-СЕРВИС (благо архитектуры очень близки). Только за несколько лет до него и для обычного Специалиста это сделали другие, причём сами.
PVV wrote:
есть желание использовать SD карту в качестве носителя и никаких дисководов
Это всем надо. Я уже несколько лет хочу поиметь исходник процедур записи/чтения физического сектора с microSD. У меня энтузиазма не хватает разобраться в её интерфейсе. Потому я заинтересованная сторона. Мне даже не нужен флэш-накопитель с FAT16/32. Мне достаточно просто читать/писать физические сектора.
Я точно также в 1999 году поступил и с винтом подключая его к ОРИОНУ. Linux-овским форматёром (т.к он позволял оперировать с физическими цилиндрами) отдал начальные цилиндры партициям MSDOS, а в конце винта оставил неиспользованные цилиндры, которые лишь программно (в CP/M-BIOS) разбил на диски CP/M по 4...8 мб и POWER-ом заполнил кодами E5 (и когда в 2000 году винт на PC накрылся, то уцелела хотя бы половина архива 8-ми разрядок на винте ОРИОНА).
Я думал, что можно создать большой нефрагментированный файл (4...8 мб) в FAT32, узнать как его адресовать и лазить туда подпрограммами 8-ми разрядки. И этот файл можно читать/писать на PC или в телефоне.
PVV wrote:
А ставить то что, cp/m, работающую с дисководом?
Кроме флоповода в рассмотрении и винчестер (и если флоповоды перестали выпускать ~25 лет назад, то винчестеры всё ещё производят и, похоже, ещё лет 10 будут выпускать).
CP/M реально не подходит для больших объёмов приводов. Она писалась в 1973 году и рассчитана на дискеты по ~150 кб. Хотя и запас по объёму диска в неё заложили солидный. В Apple-DOS сделанной позднее (1978) запас по росту объёма диска был лишь до 1 мб (максимум 4 кб на трек, 256 треков). Чем больше объём диска, тем больше тормознутость и падает размер TPA, т.к растёт Allocation Table. Реально суммарный объём всех приводов больше, чем 32 мб снижает TPA ниже границы приемлемого. И из-за отсутствия подкаталогов диски более 4...6 мб непрактичны. Кстати, все нортоны ОРИОНА с винтом успешно глюкаются, т.к не выносят число файлов (точнее экстентов) более 128.
Сейчас несущественно какая DOS. Хотя наличие CP/M позволяет использовать не только ЯВУ на 8-ми разрядке (что уже не актуально, неудобно и слишком медленно компилируется), но сразу даёт по-крайней мере нортоны (это для тех машин, где CP/M реально была). Также временами и на 8-ми разрядке нужен и текстов редактор и ассемблер и отладчик. Но это должна быть именно DOS, а не запускалка, что равнозначно магнитофонному варианту компьютера.
PVV wrote:
Что грузить, какую ОС? Тот же CP/M или МХДОС? Но их так же надо обучить работе с SD! Так что версия ОС, находящаяся в ПЗУ, и умеющая работать с SD, выглядит очень привлекательно.
Да и не для ПЗУ-шной версии, удобно как и на промышленных ЭВМ, иметь подпрограммы низкого уровня в ROM-BIOS. Так, например, в М4 для ОРИОНА-128 вместо МГ-подпрограмм включили подпрограммы чтения/записи сектора из НГМД.
Не думаю, что MXDOS лучше, чем CP/M, хотя кажется он написан по мотивам MSDOS, как и SP-DOS М.Короткина. Тогда уж и MSX-DOS 1.0/2.0 тоже можно включить в рассмотрение, хотя, кажется, на тематических форумах никто этим не занимался (чтобы мог помочь с инсталляцией).
aav8 wrote:
У меня получилось запустить CP/M из ПЗУ. Правда довольно кривовато.
Надеюсь, речь о кривоватости конкретной реализации, а не о том, что CP/M будучи помещённой в ПЗУ теряет свойства. На мой взгляд ей нет разницы откуда работать, лишь служебные ячейки д.быть в ОЗУ. Код в ПЗУ не нуждается в подкачке по Warm Boot (что экономит ОЗУ). Но есть нюанс - по Warm Boot все служебные ячейки надо обнулять.
А.Папанов wrote:
Сейчас к людям надо помягше. А на вопросы смотреть ширше...
Теоретически можно и к вопросу об использовании microSD подойти "ширше".
Если иметь только подпрограммы чтения/записи физического сектора, то для каждой DOS надо делать её версию работающую с microSD. Но ведь широко распространены DOS работающие с ВГ93. Если сделать программный или апппаратно-программный эмулятор КНГМД на ВГ93, то при аппаратно-программном варианте все программы работающие с ВГ93 будет работать без переделок.
Идея в том, чтобы доработать 8-ми рарядку так, чтобы вызывалось аппаратное прерывание по чтению/записи регистров КНГМД и процессор попадал в процедуру эмуляции ВГ93.
Если же программная эмуляция, то всё-равно не понадобится менять логику, достаточно в CP/M-BIOS и форматёрах только откорректировать места, где идёт чтение/запись в 5-ти регистров КНГМД. Так, например, команду записи в ВГ93: LD (any_reg_VG93),A заменим на CALL WR_any_reg_VG93. Кстати, это также 3 байта (хотя мне это не важно, т.к для всех нужных DOS есть исходники BIOS, а отсутствующие получаются за полчаса труда).
Работы тут не намного больше. Что большой труд эмулировать команды перемещения головки по трекам, занесения в регистры номера трека или сектора, а приняв команду на чтение сектора, затем по каждому чтению регистра данных выдавать байты - что это сложно? Это же не интерфейс дисковода, а интерфейс БИС ВГ93, тут соблюдать времянки не надо. Поэтому эмулятор КНГМД на ВГ93 можно сделать полностью внешним устройством со своим процессором, который имитирует регистры ВГ93. В подпрограммах ВГ93 нет тайм-лимита на опрос готовности данных.
Идея эмуляции ВГ93 мне нравится, попробую вскоре это программно (на уровне 8-ми разрядки). Это тоже самое, что введение в свой программный эмулятор поддержки КНГМД на ВГ93. Я когда в 1998-1999 писал свои эмуляторы РК и ОРИОНА, не стал эмулировать ВГ93, т.к счёл это ненужным (проще в DOS подпрограммы работы с ВГ93 заменить на п/п для VDISK-а из ОЗУ IBM PC). Но сейчас думаю это легко исправить, доработав мой эмулятор.
Сборку системы, из выложенного архива я сделал, но долго не мог понять, что делать с результирующим файлом CPM.RKS. Эмулятор emu его не принимал, пока я не вспомнил, что RKS бывает двух видов... поправил под второй вариант, где весь заголовок это только 4е байта, начало файла и его размер, и в emu система запустилась (соответственно, с открытием ОЗУ для рамдиска). Дальше хотел сделать, что бы был листинг сборки, PRN файлы, их удаление за ремил и включил их создание M BIOS,BIOS=BIOS.ASM, а почти во всех PRN файлах только список используемых меток и все, текста программ нет. Полный PRN файл создается только для BDOS.PRN. Отлаживаться, не видя на каком адресе нужен брейк весьма некомфортно . Но вообще сейчас, пытаюсь понять, где вставить инициализацию SD, в лоадере, A.ASM, или в BIOS.ASM? Если в итоге всю систему переводить в ПЗУ, то А файла же не будет. Плюс, инит делать только при холодном запуске или и при горячем тоже? как правильно?... То, что старые системы не расчитаны на большие, современные, объемы носителей и подводит меня к идее использовать файл образа на носителе в более современой файловой системе FAT16(а то и 32), с тем самым 'косвенным монтированием', что бы старая система о современной файловой системе ничего не знала.
в emu вг93 поддерживается, можно и там сделать конфиг, нужно лишь об адресах договориться. Но, лучше сразу переходить на SD! Еще, я с crc не понял, для SD она нужна? Есть вообще образ дискеты с программами? Что бы его сразу же в эмуляторе подключить?
PS не надо редактировать посты, лучше написать новый, иначе очень сложно понять, что изменилось и изменилось ли вообще. Если информация потеряла актуальность можно просто добавить, что информация здесь устарела и ниже есть более свежая, так будет гораздо проще все читать.
Users browsing this forum: Google [Bot] and 11 guests
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