Kakos_nonos
02.03.2014, 17:22
Всем доброго дня!
Хочу изложить в этой теме моё видение ДОСа для РК-совместимых компов.
Сейчас уже есть немало наработок в этой области: ORDOS, флеш-пзу, для дискет со своим форматом, но есть у этого одна проблема: каждый вариант доса работает только у автора и заточен под его оборудование. Если взять все варианты РК (РК стандарт, РК SRAM, Апогей, Микроша, Партнёт...) и перемноржить на все типы подключения хранилищ данных (Флеш(много вариантов), Дискета, SPI флеш, I2C ...), то получится огромное количество ДОСов. Как же разобраться в этой ситуации? Придумать единый стандарт и насильно всех на него пересадить - такой вариант не сойдёт. Многим приятна и родна какая-то либо машина, с ней будет неохота уходить. Как, например, мне с Апогея, хотя сейчас есть более развитые варианты, но апогей мне больше нравится.
И вот мне пришла в голову идея, с помошью которой может получиться решить проблему: Распростронять ДОС в виде исходников (возможно, и даже лучше, вместе с компилятором).
Что мы тогда получаем: Человек скачивает архив с исходниками, редактирует их под свой вариант РК, компилирует и прошивает (или загружает в память, если дос в озу хранится). Все эти действия надо свести к максимальной простоте: распростронять коды вместе с ассемблером, чтоб откомпилировать одним кликом, писать инструкцию по портированию(Открыть DOS.ASM, установить стартовый адрес после .ORG... и далее в таком ключе). Чтобы дос работал с разныминакопителями, надо сделать так: разделить исходник на два файла: первый будет содержать в себе исходники самого доса, операций над файлами, а второй - только операции работы с диском: чтение и запись сектора. В комплекте исходников должно быть несколько вариантов этого файла, для каждого типа накопителя. То есть: BDOS_I2C.ASM, BDOS_FLOPPY.ASM, BDOS_FLASH.ASM, возможно несколько вариантов одного и того же типа хранилища, для разных микросхем. Эти файлы тоже должны быть настраеваемы, в них вначале должен быть откомментированный текст, в котором должно быть написано что сделать чтоб адаптировать этот исходник к вашей модели РК: где поменять адрес ВВ55, где поменять используемые биты, и прочее.
Тогда мы получим максимальную совместимость, программы будут одинаково работать как, например на Апогее с I2C флешкой и на РК SRAM с Ромдиском на AT27XXXX !
Данный метод распространения программ широко используется, можно привести много примеров, например, линукс. Трудно найти место, куда его не портировали. Или например, CP/M. Вполне похожий принцип, количество её вариантов достаточно велико. Вот ещё один вариант, далеко ходить не надо - This Is Apogey!!!. Стоило мне выложить исходники+компилятор, как демку сразу портировали на РК и ЮТ :) Кстати, мы тоже можеи не зацикливаться на РК, а распрострониться на соседние компы: ЮТ, Специалист, Орион... Это будет сделать проще простого.
Но тут вылазят несколько проблем. Первая и основная - Не постоянный адрес ДОСа. В своей идее я подразумеваю, что дос может компилироваться под любой адрес. Это зависит как от модели компьютера, как и от желаний автора. В итоге мы получаем, что программа не будет знать где находится ДОС, и, собственно, процедуры сохранения/записи. Как я предлагаю решить данную проблему. Опять предлагаю обратиться к предкам: В Cp/M программы грузились с адрса $100, до этого распологалась системная зона, которая служила для связи прогаммы и ОС. Нечто подобное можно сделать и здесь, только предлагаю уменьшить эту область до двух байт. Эти два байта будут, собственно и адресом доса. Есть два варианта дальнейшиих размышлений. Первый, как в Мониторе - прдпрограммы располагаются с некоторым смещением от начального адреса. Т.е.: Чтение файла = Старт+3, Запись файла - Старт + 6... Второй вариант - Как в CP/M - этот адрес указывает не на адрес доса, а на адрес обрабатывающей процедуры, тогда: Чтение файла - MVI A,1:CALL DOS, Запись файла - MVI A,2:CALL DOS. А можно объеденить эти два варианта. Тогда в первых двух байтах находится адрес доса, а далше - ДОС+3 - обрабатывающая процедура (как в cp/m), дос+6 - чтение файла, и т д...
Но кто же занесёт в эту область адрес доса? - спросите вы. Тут надо взглянуть на братьев спектрумистов. У них есть похожая ситуация- за всё время существования спектрума так и не было придумано универсального способа управления в играх. И поэтому вначале каждой игры есть табличка: 1-Keyboard. 2-Kempston. 3-Sinclair. 4-Redefine. 5-Start game. Так и тут я предлагаю, чтоб программа при запуске спрашивала адрес доса, и записывала его в Первые два байта памяти. Если же пользователь не ввёл, а просто нажал энтер, значит, адрес уже там есть, использовать его. Можно ввести какой нибудь флаг, что запись там уже есть, чтоб на каждом резете не вводить число. Но всё равно, думаю, от того, что надо будет нажать 5 кнопок (4 hex числа + Enter) никто не умрёт, и много времени это не займёт.
В общем, вот так:)
Что хотел, высказал. Думаю, надо эту идею немного обсудить и можно приступать к реализации. Можно взять за основу имеющийся дос, можно написать заново. Второе, наверное, лучше, так как идея переносимости будет реализована полностью. Если никто не возмётся, напишу сам, опыт и умения есть, но только после Демопати Мультиматограф, сейчас нет времени, занят другим проектом. (Для РК. Будет интересно :))
Хочу изложить в этой теме моё видение ДОСа для РК-совместимых компов.
Сейчас уже есть немало наработок в этой области: ORDOS, флеш-пзу, для дискет со своим форматом, но есть у этого одна проблема: каждый вариант доса работает только у автора и заточен под его оборудование. Если взять все варианты РК (РК стандарт, РК SRAM, Апогей, Микроша, Партнёт...) и перемноржить на все типы подключения хранилищ данных (Флеш(много вариантов), Дискета, SPI флеш, I2C ...), то получится огромное количество ДОСов. Как же разобраться в этой ситуации? Придумать единый стандарт и насильно всех на него пересадить - такой вариант не сойдёт. Многим приятна и родна какая-то либо машина, с ней будет неохота уходить. Как, например, мне с Апогея, хотя сейчас есть более развитые варианты, но апогей мне больше нравится.
И вот мне пришла в голову идея, с помошью которой может получиться решить проблему: Распростронять ДОС в виде исходников (возможно, и даже лучше, вместе с компилятором).
Что мы тогда получаем: Человек скачивает архив с исходниками, редактирует их под свой вариант РК, компилирует и прошивает (или загружает в память, если дос в озу хранится). Все эти действия надо свести к максимальной простоте: распростронять коды вместе с ассемблером, чтоб откомпилировать одним кликом, писать инструкцию по портированию(Открыть DOS.ASM, установить стартовый адрес после .ORG... и далее в таком ключе). Чтобы дос работал с разныминакопителями, надо сделать так: разделить исходник на два файла: первый будет содержать в себе исходники самого доса, операций над файлами, а второй - только операции работы с диском: чтение и запись сектора. В комплекте исходников должно быть несколько вариантов этого файла, для каждого типа накопителя. То есть: BDOS_I2C.ASM, BDOS_FLOPPY.ASM, BDOS_FLASH.ASM, возможно несколько вариантов одного и того же типа хранилища, для разных микросхем. Эти файлы тоже должны быть настраеваемы, в них вначале должен быть откомментированный текст, в котором должно быть написано что сделать чтоб адаптировать этот исходник к вашей модели РК: где поменять адрес ВВ55, где поменять используемые биты, и прочее.
Тогда мы получим максимальную совместимость, программы будут одинаково работать как, например на Апогее с I2C флешкой и на РК SRAM с Ромдиском на AT27XXXX !
Данный метод распространения программ широко используется, можно привести много примеров, например, линукс. Трудно найти место, куда его не портировали. Или например, CP/M. Вполне похожий принцип, количество её вариантов достаточно велико. Вот ещё один вариант, далеко ходить не надо - This Is Apogey!!!. Стоило мне выложить исходники+компилятор, как демку сразу портировали на РК и ЮТ :) Кстати, мы тоже можеи не зацикливаться на РК, а распрострониться на соседние компы: ЮТ, Специалист, Орион... Это будет сделать проще простого.
Но тут вылазят несколько проблем. Первая и основная - Не постоянный адрес ДОСа. В своей идее я подразумеваю, что дос может компилироваться под любой адрес. Это зависит как от модели компьютера, как и от желаний автора. В итоге мы получаем, что программа не будет знать где находится ДОС, и, собственно, процедуры сохранения/записи. Как я предлагаю решить данную проблему. Опять предлагаю обратиться к предкам: В Cp/M программы грузились с адрса $100, до этого распологалась системная зона, которая служила для связи прогаммы и ОС. Нечто подобное можно сделать и здесь, только предлагаю уменьшить эту область до двух байт. Эти два байта будут, собственно и адресом доса. Есть два варианта дальнейшиих размышлений. Первый, как в Мониторе - прдпрограммы располагаются с некоторым смещением от начального адреса. Т.е.: Чтение файла = Старт+3, Запись файла - Старт + 6... Второй вариант - Как в CP/M - этот адрес указывает не на адрес доса, а на адрес обрабатывающей процедуры, тогда: Чтение файла - MVI A,1:CALL DOS, Запись файла - MVI A,2:CALL DOS. А можно объеденить эти два варианта. Тогда в первых двух байтах находится адрес доса, а далше - ДОС+3 - обрабатывающая процедура (как в cp/m), дос+6 - чтение файла, и т д...
Но кто же занесёт в эту область адрес доса? - спросите вы. Тут надо взглянуть на братьев спектрумистов. У них есть похожая ситуация- за всё время существования спектрума так и не было придумано универсального способа управления в играх. И поэтому вначале каждой игры есть табличка: 1-Keyboard. 2-Kempston. 3-Sinclair. 4-Redefine. 5-Start game. Так и тут я предлагаю, чтоб программа при запуске спрашивала адрес доса, и записывала его в Первые два байта памяти. Если же пользователь не ввёл, а просто нажал энтер, значит, адрес уже там есть, использовать его. Можно ввести какой нибудь флаг, что запись там уже есть, чтоб на каждом резете не вводить число. Но всё равно, думаю, от того, что надо будет нажать 5 кнопок (4 hex числа + Enter) никто не умрёт, и много времени это не займёт.
В общем, вот так:)
Что хотел, высказал. Думаю, надо эту идею немного обсудить и можно приступать к реализации. Можно взять за основу имеющийся дос, можно написать заново. Второе, наверное, лучше, так как идея переносимости будет реализована полностью. Если никто не возмётся, напишу сам, опыт и умения есть, но только после Демопати Мультиматограф, сейчас нет времени, занят другим проектом. (Для РК. Будет интересно :))