Это название пункта в меню выбора платфомы в эмуляторе. Значит автор эмулятора включил конфиг под такое железо и ПО. И посчитал ненужным включать туда дисковод. Видимо это было давно, когда DSDOS ещё не поддерживала обычный КНГМД, а позднее Вы поленились послать автору эмулятора образы дискет в формате SPDOS.Сообщение от Denn
Насчёт смысла, - это свойственная Вам депрессия. Зачем Вы постоянно всё депресуете? Нужна, наоборот, моральная поддержка. А зачем этот сайт читают и пишут? Это такое хобби. И оно лучше, чем клеить кораблики внутри бутылок.
С чего Вы взяли, что большой объём памяти тратится на пиктограммы. Типов иконок, допустим 8. Типоразмеров иконок, для начала два: 24*32 и 16*24. Итого расход на пиктограммы всего ~1 кб. А вот на окна действительно уходит много памяти, но 2-х банок хватит. Кстати, я ориентируюсь на больше, чем 2 банки, мне нужен RAM-диск, а лишь DOS+GUI занимают 2 банки.
Не взлетит, - это непонятный жаргон. Что Вы этим утверждаете? Что будет работать неудовлетворительно или вообще не будет работать? На Apple-IIe хватило 128 кб и тормозного флопа на 140 кб. ROM-диска там вообще не было.
Чего "несмешного" в загрузке с дискеты? DOS грузится с дискеты или ROM-диска, а DOS стартует Desktop оболочку. Всё, естественно, работает из ОЗУ. Весь код для работы с графикой в банке где экран, а код DOS и TPA в другой банке. Тип DOS вообще не важен. Это может быть DOS объёмом в 12 кб или RKDOS в 4 кб и даже ORDOS объёмом в 2 кб.
Не сомневаюсь, что получится тормознуто, но вовсе не из-за графики, а из-за небайтовых шрифтов. Придётся использовать шрифты 5*9, 6*9 и 7*9, и кстати, драйверы придётся переделать, чтобы символы можно было помещать в любое место экрана, а не только в позиции знакомест. Вот тогда и понадобится Z80 на такте 4.5 МГЦ (пиксель клок 9 МГЦ, экран 448*256).
В графическом интерфейсе в окне можно выводить и список файлов, так что интерфейс Нортона можно считать окном GUI со списком. Размеры иконок масштабируются пользователем, так что нужны картинки всех размеров от 8*12 до 32*48.
Из этого вопроса и потому, что Вы считаете, что возможностей ОРИОНА для GUI не хватит, думаю что Вы не пользовались GUI на Apple-II или на Apple MAC-128 из 1984 года. У меня они есть оба в реале и я Apple GUI пользовался.
В GUI на слабых машинах применяют монохром, хотя особенности цвета Специалиста позволяют оцветить без торможения. В цветных Amiga и Atari - GUI тоже монохромный. GEM от DR для EGA тоже в основном монохромный.
Посмотрите вид графического интерфейса на Apple-IIe работающем на CPU с тактом в 1 МГЦ, ОЗУ 128 кб и экраном 560*192. Интерфейс монохромного MAC выглядит похоже (только белый и графика лучше, т.к там растр 512*342).
Скрытый текст
[свернуть]
Вы прекрасно знаете, что в DOS работающих с носителем с помощью БИС контрольные суммы есть у физических секторов. И даже в DOS, где сам процессор заменяет БИС, контрольные суммы всегда используют. А для CD и DVD даже используются исправляющие контрольные коды.Серьёзно? Если бы на Пи-Си была КС...
... ужас от Ваших доводов. Если файл открытый на запись не закрыт, то его каталоговая запись неверна и волноваться надо уже не о том, что КС не совпала, а о том, что содержимое файла не то. Но речь-то об ORDOS, где нет даже такого.
Понятно, что КС разумнее иметь у секторов, т.к это единица обмена, но речь-то о ORDOS, где нет ни секторов, ни контрольных сумм. Потому и совершенно очевидно решение исправления ситуации, - иметь КС на целый файл, тем более, что файлы маленькие. Иметь КС удобно, т.к это даёт гарантию, что файл не повреждён.
Создаётся впечатление, что Вам не важно на что и как возражать, лишь бы возражать. Я лишь предложил с пользой использовать свободные 4 байта в метке ORD-файла. Точнее предложил даже не использовать, т.к и так давно это использую, а ввести единообразие, стандартизовать. А это вызвало обструкцию и неприятие. И смехотворные доводы.
А речь шла не только о КС и дате файлов. Очевидно, что глупо было отводить на имя всего 8 символов, а для программ всего 7, оставляя в то же время 4 байта в ORDOS-метке неиспользованными. И если в самой ORDOS с этим большим неудобством смирились, то при конверсии в ORD-формат нормальных файлов из других DOS теряется расширение.
Я эту ситуация давно исправил. Двумя способами. Просто подстановкой 3-х символов CP/M-расширения в позиции 13,14 и 15. А байт с оффсетом 12, как флаг что есть продолжение имени, ставится равным 7E (символ '~'). Второй способ, расходует лишь 7 битов, оставляя 3 байта для КС и даты, - тогда 12-й байт это токен, который кодирует стандартное расширение. В тех DOS, что я использую, загрузчики понимают оба эти формата ORDOS-метки.
Кстати, в SPDOS разумно было бы ввести нормальные имена файлов, т.е, как Вы это называете - сделать "как принято в Америке", а не в ORDOS.
Ладно, проехали и забыли. Исходил из того, что Вы программируете для ОРИОНА и сделал неверные выводы. Убедился, что Вам на всё наплевать.
Согласен. Учту.
Исходил из того, что не встречал ранее людей, кто применил третий ППА. На платах ташкентского Турбо-10 МГЦ и принтер и ROM-диск обслуживает один порт F500. Зачем тогда нужен третий ППА? Он только излишне грузит шину и снижает надёжность при турбировании по схеме Турбо-200%. Гораздо разумнее на этом месте было бы поставить ВИ53. Но он и вручную удобно ставится на это место.
А какую конкретно точку зрения Denn-а Вы разделяете? Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели мерзкие американцы.
Ответить с цитированием