А что тут представлять? Простенькие конверторы проще всего писать именно на бейсике. Получается быстрее, чем на Си или ассемблере. Беру заготовку, где уже есть загрузка файла и запись результата в файл. Остаётся потратить пару минут на написание всего нескольких строк на бейсике, что и делают конверсию. И даже не требуется бейсик программу компилировать.Сообщение от Denn
Забавно. Пытаюсь представить масштабы нужды...
Фраза как раз характеризует именно Ваше отношение, не моё. Явное нежелание даже хоть что-то обсуждать.
Напрасно Вы восприняли мой пост как "наезд". Я не критиковал, а высказал личное мнение, причём всего на пару моментов, о том что реально неудобно, но что при желании поправить совсем несложно.
Я понимаю, что при программировании интереснее написать своё, чем заимствовать. Но речь о базовых вещах, здесь изобретать велосипеды незачем.
А я использую прекрасный эмулятор EMU80, где в меню выбора есть ОРИОН с DSDOS, но дисковода нет.
А вот это совсем неправильно, т.к расширение ODI используется уже более 10 лет и этот формат общепризнан и поддержан эмуляторами и утилитами, как формат CP/M Ориона и Корвета.
Обозвав так же формат дискет SPDOS, Вы ввели никому ненужную путаницу. Здесь как раз и необходимо было вводить новое расширение. Фантазии не хватило на собственное расширения для образов дискет SPDOS? Не знаю как в эмуляторе от b2m, но в EMU80 можно для каждой конфигурации задать используемый тип файлов с образами дисков.
Вообще-то диск подключённый по линии называется сетевым. Понятно, что при передаче всегда используются КС. Речь шла о ORDOS-файлах, чтобы обнаруживать дохлоту в реале.
При файлообмене без разницы какие два байта пересылать, два нуля или два байта КС. И всё как раз наоборот, - не имея готовой КС, при файлообмене КС придётся считать, что и затормозит, хотя и несущественно.
Байт паритета это упрощённый аналог КС, но однобайтовый (знаю ЭВМ в которых в МГ-подпрограммах для контроля пересылается именно байт паритета блока, а не два байта КС). Предложил я это лишь для того, чтобы уместить в 4 байта три вещи: КС, расширение ORDOS-имени и дату файла.
Речь идёт о средстве позволяющем выявлять дохлоту в архивных файлах. А не для выявления ошибок в объектных кодах прямо в процессе трансляции исходников программ в ORDOS-файл ассемблером. Причём и такой ситуации даже нет, т.к ассемблер ORDOS производный от МИКРОНА пишет не побайтово, а массивом.
Нелепый довод. Удивлён читая такое от Вас, т.к Вы знакомы с тем как программы работают с файлами. Во всех ДОС, кроме ORDOS, файл сначала открывают, а в конце работы закрывают, после чего никаких изменений с содержимым файла не происходит. Что за идиот стал бы перезаписывать КС при каждой очередной записи в файл, достаточно это сделать один раз при закрытии файла.
Но сейчас ORDOS дорабатывать поздно, т.к в реале ей никто, кроме Denn-а не пользуется. Я включил функцию подстановки КС в ORD-файл в нортоны и всё, проблема решена. Не увидел такого решения у Denn-а, и его использование лишних байтов в ORDOS-метке не совпадает с моим, потому и предложил обсудить это. Но когда сталкиваешься с таким отношением, то в другой раз не захочется что-то обсуждать.
Насчёт жизнеспособности. Имею исходники 6-ти разных DOS (совершенно разных концепций), которые используют эл.диск в качестве носителя. И все они используют для контроля целостности файлов контрольные суммы и работе программ с последовательным и произвольным доступом это нисколько не мешает.
К тому же речь шла именно о ORDOS-файлах, т.е об ORDOS, а не о какой-то иной более нормальной DOS в которой файлы имеют настолько большие размеры, что считать КС всего файла очень долго.
Я исхожу из реальной практики. В конце 80-тых пару лет пользовался платой внешнего эл.диска на РУ7-мых, для чего одним грамотным програмистом была написана RAMDOS (не путать с RAMDOS РК86 Д.Лукьянова из ж.РАДИО). Там файлы имели КС. Потому, хотя файлы иногда дохли, но дохлые файлы не плодились.
А в ORDOS дохлые файлы просто разводились. Не только из-за помех по питанию, падения утюгов на плату и проникающего гамма-излучения. При разработке ПО всегда происходят улёты. В.Воронин (Алёна) специально разработал апп.защиту квазидисков ORDOS от записи. Как только я познакомился с ORDOS, то на основе предыдущего опыта сразу же сказал, что это большая дурь не иметь КС файлов. Так что ORDOS - единственная в мире DOS, где нет КС.
Разработчики мыши для БК-010 и Корвета так не считали. Эта мышь называется "манипулятор ММ 8031". Выдаёт результат в параллельном коде (с двух реверсивных счётчиков) и подключается просто и всего через один порт ППА.Флаг Вам в руки. В свою очередь считаю мышь совершенно излишней на 8-битке
Глупости. Весь мир сделал свой выбор.
Теперь ясно, что Вы не Стивен Джобс, который увидев мышь сразу понял удобство графического интерфейса.
Речь о однозадачной ОС. Точнее даже не о ОС, а лишь об оболочке для любой ОС для управления файлами. Что-то типа Finder для MAC-128, только на 2 порядка проще. Понятно, что суть будет совсем иная. Но сначала надо получить хотя бы внешний интерфейс, а далее можно улучшать идеологию. Естественно и графика поначалу получится некрасивой, но при желании всё можно довести до шедевра.
Имея свой нортон с окнами для какой-либо DOS, берём оттуда готовые исполнительные части команд (COPY, MOVE, RENAME...) и заменяем табличный интерфейс нортона на графический. Имея готовый графический интерфейс, это сделать совсем несложно.
Кстати, графические оболочки Apple-II Desktop, MouseDesk и Quark Catalyst прекрасно работали на 8-ми разрядных Apple-IIе и Apple-IIс с тактом CPU в 1 МГЦ и ОЗУ в 128 кб. Ресурсов 8-ми разрядки достаточно, чтобы вывести на экран пиктограммы и синхронно с движением мыши двигать по экрану стрелку-указатель. Хотя горизонтальное разрешение, чтобы улучшить графику, желательно поднять до 448*256.
Не понимаю Вашего страха перед GUI. Кстати, написание GUI это самая интересная задача, что осталась в системном программировании для ОРИОНА и СПЕЦИАЛИСТА.
Какой ущерб производительности? Какая разница перемещать балку подсветки в нортоне курсорными клавишами или перемещать стрелку-указатель мышью в GUI.
Чтобы избавиться от страха написать GUI-интерфейс, подумайте о том, какие минимальные функции нужны для GUI. Тогда Вам станет ясно, что это не намного сложнее, чем написать нортон и уж точно проще, чем макро-ассемблер.
Для простейшего GUI нужны функции:
1. Открытие окна
2. Изменение размера окна
3. Перемещение окна
4. Перекладывание нижележащего окна наверх
5. Вывод пиктограммы и её перемещение мышью
6. Перемещение по экрану стрелки-указателя синхронно с движением мыши
7. По нажатию кнопки мыши проверка на попадание в заданные окна
8. Обслуживание окна выпадающего вертикального меню
Здесь относительно сложно сделать только пункт 4. Позиции 6,7,8 у меня уже есть (написал ещё в 90-тые годы). К сожалению, для Z80. БОльшая сложность нарисовать пиктограммы. Поэтому и искал Windows для ОРИОНА, что входила в дистрибутив CP/M-48K от ОРИОНСОФТ в 1993. Но так и не нашёл.
Сейчас у меня много незаконченных проектов (причём по железу), но чуть позднее, надеюсь поиметь мышь и заняться программированием GUI для СПЕЦИАЛИСТА (с ОЗУ 256 кб), хотя для КР580 программирование графики существенно усложняется.
Ответить с цитированием