Здравствуйте, Alekzander, Вы писали:
A>Кто бы мог подумать, что он на такое способен.
Что бы ему не быть на это способным, если псевдографику умел на экран выводить?
Здравствуйте, Alekzander, Вы писали:
M>>А что именно вызывает удивление?
A>Всё. Но, наверно, больше всего — переключение кодировок W1251/KOI8/ANSI на лету в файл-вьювере.
Здравствуйте, Alekzander, Вы писали:
A>Я слышал, что там есть какой загон со спрайтами, но деталей не знаю. Можешь просветить.
PPU может 8 спрайтов одновременно рисовать + фон который статика по сетке. Так себе возможности чтобы писать что-то буквами.
Здравствуйте, pagid_, Вы писали:
A>>Кто бы мог подумать, что он на такое способен. _>Что бы ему не быть на это способным, если псевдографику умел на экран выводить?
Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
Здравствуйте, Marty, Вы писали:
M>>>А что именно вызывает удивление? A>>Всё. Но, наверно, больше всего — переключение кодировок W1251/KOI8/ANSI на лету в файл-вьювере.
M>В переключении кодировок нет никакого космоса
При 48-то К памяти? Сделать вывод 64x24 (при этом ВСЕЙ памяти хватило бы только на 32 экрана), уместиться туда со всем кодом, поддержать конкретно во вьювере wrapping, hex mode и — вишенка на торте — кодировки на лету... Я так не напишу. И 95% программистов тоже, так что прояви немного увОжения!
Здравствуйте, Alekzander, Вы писали:
A>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал?
Ну если на асме писать, можно очень маленький .com сделать. Помнится, мне шахматы в 512байт удалось запихнуть.
Здравствуйте, Alekzander, Вы писали:
M>>В переключении кодировок нет никакого космоса
A>При 48-то К памяти? Сделать вывод 64x24 (при этом ВСЕЙ памяти хватило бы только на 32 экрана), уместиться туда со всем кодом, поддержать конкретно во вьювере wrapping, hex mode и — вишенка на торте — кодировки на лету... Я так не напишу. И 95% программистов тоже, так что прояви немного увОжения!
Я делал большинство из всего этого, кроме перекодировки. Перекодировка W1251<->CP866 (почему кстати ты про ANSI, ANSI это 1251 и есть, CP866 — OEM) — это таблица на 128 байт, еще одна для KOI8, да несколько десятков байт на процедуры конвертации.
Это легко и не ненапряжно пишется на асме Z-80, и влезет в 2-3 килобайта от силы, ну, с перекодировками и знакогенератором может 5 килобайт
И, кстати, у тебя с арифметикой что-то. В 48Кб влезет от силы 8 экранов, это если атрибуты не считать.
И да, 95% программистов это напишут, без особого напряга. Если ты под программистами подразумеваешь участников данного сайта, а не современных фронтэндеров
Здравствуйте, sambl74, Вы писали:
A>>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
S>Зачем?
Re[2]: is dos писал искарсофт который не заработав на OS
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Здравствуйте, pagid_, Вы писали:
A>>Кто бы мог подумать, что он на такое способен. _>Что бы ему не быть на это способным, если псевдографику умел на экран выводить?
Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей
Здравствуйте, Marty, Вы писали:
A>>>Кто бы мог подумать, что он на такое способен. _>>Что бы ему не быть на это способным, если псевдографику умел на экран выводить?
M>Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей
Тоже хотел спросить, почему он решил, что это псевдографика, когда знакоместо было, насколько я помню, 8x8, а на скриншоте, очевидно, 4x8. Я уж статью перечитал — нет такого: https://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes. Это похоже на какой-то хитрый трюк.
Здравствуйте, Marty, Вы писали:
A>>ZX Spectrum. Программа, правда, насколько я понял, современная, но работает под оригинальные модели 48К и 128К. Вот тут можно запустить в эмуляторе прямо из браузера: https://zxart.ee/rus/soft/tool/media-admin/commander/tr-dos-navigator/tr-dos-navigator10/ A>>Кто бы мог подумать, что он на такое способен.
M>А что именно вызывает удивление?
Всё. Но, наверно, больше всего — переключение кодировок W1251/KOI8/ANSI на лету в файл-вьювере.
Здравствуйте, Alekzander, Вы писали:
A>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
Здравствуйте, GarryIV, Вы писали:
A>>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
GIV>Тут вон люди OS для NES пишут на спрайтах https://www.youtube.com/watch?v=UTWK_bIJf1U а тут как минимум 48К памяти
"The NES contains 2 kb of onboard work RAM. A game cartridge may contain expanded RAM to increase this amount. The size of NES games varies from 8 kB (Galaxian) to 1 MB (Metal Slader Glory), but 128 to 384 kB was the most common."
The 6502 was about 3x-3.5x faster than the Z80 at the same clock speed (therefore, the Z80 was usually used with a higher clock speed). Overall, it was / is much nicer to program. The 6502 was derived from the Motorola 6800, and the Z80 was derived from the Intel 8080.
Так что, не надо сравнивать железяку, способную запускать игры размером в мегабайт и со средним размером до 384К, имеющую расширяемую память как часть программного пакета (!!!), с процессором намного мощнее и имеющим лучшую архитектуру и дополнительным специальным процессором для вывода картинки (видеоускорителем, по сути) аж на 5.37 Мгц. И Спектрум, который слепили и полюбили из того, что было.
Здравствуйте, graniar, Вы писали:
A>>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал?
G>Ну если на асме писать, можно очень маленький .com сделать. Помнится, мне шахматы в 512байт удалось запихнуть.
vc.com был 65,090 байт и он был недосягаемо прекрасен (для меня, по крайней мере). Правда, он и умел побольше. Но и 640К тогда хватало всем. 640 это не 48.
Здравствуйте, Alekzander, Вы писали:
GIV>>Тут вон люди OS для NES пишут на спрайтах https://www.youtube.com/watch?v=UTWK_bIJf1U а тут как минимум 48К памяти
A>Так что, не надо сравнивать железяку, способную запускать игры размером в мегабайт
Как тебе этот мег поможет NC нарисовать на NES? Сколько там спрайтов PPU может?
Здравствуйте, Alekzander, Вы писали:
A>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
Зачем? Был же Волков Коммандер — особенно на AT-шке разница была прям сильно заметна
Здравствуйте, Marty, Вы писали:
M>И, кстати, у тебя с арифметикой что-то. В 48Кб влезет от силы 8 экранов, это если атрибуты не считать.
(48*1024)/(24*64), считаем 1 байт на символ. Если меньше (я не в курсе, как кодируются символы в TR-DOS, 7 или 8 бит — мои родители были не настолько богаты, чтобы я с ней мог поиграться), то влезет больше. На самом деле, под буфер текста, за раз выводимого на экран, надо не 24*64, а 22*64, т.е. минус две служебные строки под хедер и футер.
Здравствуйте, GarryIV, Вы писали:
GIV>>>Тут вон люди OS для NES пишут на спрайтах https://www.youtube.com/watch?v=UTWK_bIJf1U а тут как минимум 48К памяти
A>>Так что, не надо сравнивать железяку, способную запускать игры размером в мегабайт GIV>Как тебе этот мег поможет NC нарисовать на NES? Сколько там спрайтов PPU может?
"Этот мег" — доказательство того, что там можно делать реально большие проекты. Я под NES не программировал, но зная о том, что так можно, выбрал бы её из двух зол не задумываясь.
Здравствуйте, Alekzander, Вы писали:
A>Тоже хотел спросить, почему он решил, что это псевдографика, когда знакоместо было, насколько я помню, 8x8, а на скриншоте, очевидно, 4x8. Я уж статью перечитал — нет такого: https://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes. Это похоже на какой-то хитрый трюк.
На спектруме было полно всяких шрифтов, которые были уже 8 символов. Вроде бы, где-то я видел даже и режим на 64 символа в строке — при всё тех же 256 пикселях на ширину экрана
Я даже какой-то из дипломов написал на спектруме в IS-DOS и текстовый файл вполне потом читался на обычном IBM совместимом ПК.
Здравствуйте, Alekzander, Вы писали:
A>"Этот мег" — доказательство того, что там можно делать реально большие проекты.
Неудобный вопрос про спрайты был да?
Здравствуйте, Alekzander, Вы писали:
M>>И, кстати, у тебя с арифметикой что-то. В 48Кб влезет от силы 8 экранов, это если атрибуты не считать.
A>(48*1024)/(24*64), считаем 1 байт на символ. Если меньше (я не в курсе, как кодируются символы в TR-DOS, 7 или 8 бит — мои родители были не настолько богаты, чтобы я с ней мог поиграться), то влезет больше. На самом деле, под буфер текста, за раз выводимого на экран, надо не 24*64, а 22*64, т.е. минус две служебные строки под хедер и футер.
Обычно текст экранами не считают, я вообще не понимаю, при чем тут эти подсчеты. Если говорить о TR-DOS как о файловой системе и о том, как имена файлов в ней кодируются — думаю, что 8 бит на символ. И, кстати, при семи битах на символ ты много не наэкономишь. А как храняться данные в файлах — это уже дело тех программ, которые с ними работают. Но, вообще, файлы на спектруме были нужны в основном для того, чтобы загрузить игру, и всё.
А так — 48Кб — это в общем случае — 48 тысяч символов
Зачем такие тексты на спектруме редактировать — не могу что-то представить
Здравствуйте, Alekzander, Вы писали:
G>>Ну если на асме писать, можно очень маленький .com сделать. Помнится, мне шахматы в 512байт удалось запихнуть.
A>vc.com был 65,090 байт и он был недосягаемо прекрасен (для меня, по крайней мере). Правда, он и умел побольше. Но и 640К тогда хватало всем. 640 это не 48.
Здравствуйте, sambl74, Вы писали:
A>>Тоже хотел спросить, почему он решил, что это псевдографика, когда знакоместо было, насколько я помню, 8x8, а на скриншоте, очевидно, 4x8. Я уж статью перечитал — нет такого: https://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes. Это похоже на какой-то хитрый трюк.
S>На спектруме было полно всяких шрифтов, которые были уже 8 символов. Вроде бы, где-то я видел даже и режим на 64 символа в строке — при всё тех же 256 пикселях на ширину экрана
Четыре пикселя на символ — это жестко. Но 5 было вполне распространено. В IS-DOSовской оболочке вроде так было сделано. Вроде в ассемблере GENS были узкие символы, но не помню точно, какой ширины
S>Я даже какой-то из дипломов написал на спектруме в IS-DOS и текстовый файл вполне потом читался на обычном IBM совместимом ПК.
Да, я тоже что-то под IS-DOSом делал на первых курсах, правда, у меня тогда скорпион был
Здравствуйте, GarryIV, Вы писали:
A>>"Этот мег" — доказательство того, что там можно делать реально большие проекты. GIV>Неудобный вопрос про спрайты был да?
Я слышал, что там есть какой загон со спрайтами, но деталей не знаю. Можешь просветить. А исходил я из того, что тупее атрибутного подхода "два цвета на знакоместо" всё равно ничего быть не может.
Здравствуйте, Marty, Вы писали:
A>>vc.com был 65,090 байт и он был недосягаемо прекрасен (для меня, по крайней мере). Правда, он и умел побольше. Но и 640К тогда хватало всем. 640 это не 48.
M>Побольше умел — это про что?
Речь не про ZX-Spectrum, а совершенно другой компьютер лишь "Спектрум-совместимый" с новыми
графическими режимами, более быстрым процессором, большим объёмом ОЗУ и т.д. и т.п. Примазываться
к спектруму здесь совершенно не нужно. Это не ZX-Spectrum 48k и даже не Pentagon-128 (как эталон
демомейкинга).
Здравствуйте, Marty, Вы писали:
M>Обычно текст экранами не считают, я вообще не понимаю, при чем тут эти подсчеты.
Мы говорили про файл-вьювер, и я отметил, что один только буфер под текст, отображаемый за раз на экране, занимает 1/32 ВСЕЙ памяти. Жестковатые требования к вьюверу получаются. И с другой стороны его подпирает основной модуль, в который ты выходишь по нажатию цифры 3, которому тоже нужна память. В общем, написано очень хорошо, я считаю. А про фронтендеров я даже начинать не буду, просто поверь, что на каждом лугу трава не такая зелёная, как кажется со стороны, и знать бывает надо много, и головоломки решать, и ресурсы экономить (да, экономить ресурсы).
Здравствуйте, fk0, Вы писали:
A>>https://zxart.ee/rus/soft/tool/media-admin/commander/tr-dos-navigator/tr-dos-navigator10/
fk0> Речь не про ZX-Spectrum, а совершенно другой компьютер лишь "Спектрум-совместимый" с новыми fk0>графическими режимами, более быстрым процессором, большим объёмом ОЗУ и т.д. и т.п. Примазываться fk0>к спектруму здесь совершенно не нужно. Это не ZX-Spectrum 48k и даже не Pentagon-128 (как эталон fk0>демомейкинга).
Здравствуйте, Alekzander, Вы писали:
M>>Обычно текст экранами не считают, я вообще не понимаю, при чем тут эти подсчеты.
A>Мы говорили про файл-вьювер, и я отметил, что один только буфер под текст, отображаемый за раз на экране, занимает 1/32 ВСЕЙ памяти.
И что с того?
A>Жестковатые требования к вьюверу получаются.
Чего тут жесткого?
A>И с другой стороны его подпирает основной модуль, в который ты выходишь по нажатию цифры 3, которому тоже нужна память.
Нужна. Но мало.
A>В общем, написано очень хорошо, я считаю.
Щитай на здоровие
A>А про фронтендеров я даже начинать не буду, просто поверь, что на каждом лугу трава не такая зелёная, как кажется со стороны, и знать бывает надо много, и головоломки решать, и ресурсы экономить (да, экономить ресурсы).
Здравствуйте, Alekzander, Вы писали:
A>При 48-то К памяти? Сделать вывод 64x24 (при этом ВСЕЙ памяти хватило бы только на 32 экрана), уместиться туда со всем кодом, поддержать конкретно во вьювере wrapping, hex mode и — вишенка на торте — кодировки на лету... Я так не напишу. И 95% программистов тоже, так что прояви немного увОжения!
В CP/M и MSX-DOS работал TurboPascal 1.0.
На машине было 64 Кбайта
Содержал в себе
1. Компилятор
2. Редактор текста (кода)
3. Буфер для исходного кода
4. Буфер, где хранилась рабочая программа. Он по умолчанию не делал исполняемый файл, а делал рабочую программу в ОП.
Здравствуйте, Alekzander, Вы писали:
M>>>>Побольше умел — это про что? A>>>Про F9.
M>>А что там в VC по F9 было?
A>Представления, сортировки, атрибуты, иерархия кастомных команд, сравнение каталогов, скринсейвер, менеджер памяти и даже настройка анимации диалогов.
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, fk0, Вы писали:
A>>>https://zxart.ee/rus/soft/tool/media-admin/commander/tr-dos-navigator/tr-dos-navigator10/
fk0>> Речь не про ZX-Spectrum, а совершенно другой компьютер лишь "Спектрум-совместимый" с новыми fk0>>графическими режимами, более быстрым процессором, большим объёмом ОЗУ и т.д. и т.п. Примазываться fk0>>к спектруму здесь совершенно не нужно. Это не ZX-Spectrum 48k и даже не Pentagon-128 (как эталон fk0>>демомейкинга).
A>Цитирую:
A>
A>Они обманули, или что? Я, естественно, запускал на эмуляторе.
A>Бинарник весит 14592 байт. Ещё сто байт весят два драйвера. В чём проблема?
Ах вот о чём речь. Я увидел слово NedoOS и сделал неправильные выводы (там да, полноценный текстовый режим),
а из скриншотов ничего не понятно.
Если это, то ничего лучше quick-commander'а нет (https://zxart.ee/rus/soft/tool/media-admin/commander/quick-commander/),
а он был ещё в начале 2000-х. Но сейчас это далеко не актуально. Имитировать двухпанельность нортона
никакого смысла нет. Важней другие фичи, вроде адекватного просмотрщика текстов и картинок, быстрой
прямой работы с диском (стандартный тр-дос читает по нескольку оборотов на дорожку, в пределе же нужно
~1.3 оборота на дорожку), возможности переформатировать битые сектора, оставаться резидентно в памяти
(чтоб не грузить каждый раз с диска после сброса). Не понимаю смысла писать коммандер в современное время.
Уже были conver-коммандер им. Ковалевского, real commander. Ещё Honey Commander от Микроарта (бесполезный,
но красивый). Это действительно хиты своего времени и переплюнуть их тяжело, да и бессмысленно.
Здравствуйте, Alekzander, Вы писали:
A>Ты писал в детстве свой клон Нортон Коммандера?
Не то чтобы клон Нортон Коммандера, но писал некоторое поделие с интерфейсом Нортон Коммандера и реализующее функции, которых в Нортон Коммандера не было. То есть скорее дополнение, а не замену.
A>Какого размера у тебя получился исполняемый файл и сколько памяти он кушал?
Не помню, но в модель памяти Tiny вроде как влазил.
Но я же на С++ писал и основной целью было побаловаться именно с языком.
На ассемблере конечно куда как более трудоемко, но что не сделаешь, если очень хочется. Некий господин Volkov сделал же аналог Нортона в .com формате выполнимого файла, и некоторое время его командер в специфических случаях вполне использовался.
A>Там всё не так просто, как вывод псевдографики.
А что там?
Просмотрщик текстовых файлов, так не беда. Вот если редактор есть, посложнее конечно. Но его судя по всему нет.
Здравствуйте, Marty, Вы писали:
M>Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей
То есть там все нарисовано в графике и рамочки и буковки? Ну
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>При 48-то К памяти? Сделать вывод 64x24 (при этом ВСЕЙ памяти хватило бы только на 32 экрана), уместиться туда со всем кодом, поддержать конкретно во вьювере wrapping, hex mode и — вишенка на торте — кодировки на лету... Я так не напишу. И 95% программистов тоже, так что прояви немного увОжения!
PD>В CP/M и MSX-DOS работал TurboPascal 1.0.
PD>На машине было 64 Кбайта
PD>Содержал в себе
PD>1. Компилятор PD>2. Редактор текста (кода) PD>3. Буфер для исходного кода PD>4. Буфер, где хранилась рабочая программа. Он по умолчанию не делал исполняемый файл, а делал рабочую программу в ОП.
PD>Умели тогда код писать.
Тогда нужно вспомнить и интерпретатор Майкрософт Бейсик, который влезал в 4К и оставлял место под исходный код программы.
Всё это вещи выдающиеся, штучные, а то, что некоторые их тут языком (не программирования) "пишут", так он, как известно, без костей. Была бы обычная программа, её бы ещё в 90-е написали, а не в 2007-м. И не одну.
Здравствуйте, fk0, Вы писали:
fk0> Если это, то ничего лучше quick-commander'а нет (https://zxart.ee/rus/soft/tool/media-admin/commander/quick-commander/), fk0>а он был ещё в начале 2000-х. Но сейчас это далеко не актуально. Имитировать двухпанельность нортона fk0>никакого смысла нет.
Я бы сказал, вообще писать под него софт смысла нет. Кроме как из любви к искусству, конечно (что я уважаю). А именно этот я выбрал, потому, что он как раз максимально непохож на спектрумовские программы, а похож на что-то более писишное (см. заголовок: "Угадай компьютер с трёх скриншотов").
Здравствуйте, pagid_, Вы писали:
M>>Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей _>То есть там все нарисовано в графике и рамочки и буковки? Ну
A>Всё это вещи выдающиеся, штучные, а то, что некоторые их тут языком (не программирования) "пишут", так он, как известно, без костей. Была бы обычная программа, её бы ещё в 90-е написали, а не в 2007-м. И не одну.
Я много чего понаписал для спектрума, в тч и вывод символов в пять пикселей шириной, и у меня была своя 3х-байтовая плавучка, на которой я пилил векторную графику и хотел запилить какую-нибудь игруху, но писать двухпанельный файловый менеджер для TR-DOS — дурнее идеи я не встречал
Здравствуйте, Alekzander, Вы писали:
A>Я бы сказал, вообще писать под него софт смысла нет. Кроме как из любви к искусству, конечно (что я уважаю). А именно этот я выбрал, потому, что он как раз максимально непохож на спектрумовские программы, а похож на что-то более писишное (см. заголовок: "Угадай компьютер с трёх скриншотов").
Здравствуйте, fk0, Вы писали:
fk0> Речь не про ZX-Spectrum, а совершенно другой компьютер лишь "Спектрум-совместимый" с новыми fk0>графическими режимами, более быстрым процессором, большим объёмом ОЗУ и т.д. и т.п. Примазываться fk0>к спектруму здесь совершенно не нужно. Это не ZX-Spectrum 48k и даже не Pentagon-128 (как эталон fk0>демомейкинга).
Здравствуйте, Alekzander, Вы писали:
A>Ты писал в детстве свой клон Нортон Коммандера? Какого размера у тебя получился исполняемый файл и сколько памяти он кушал? Там всё не так просто, как вывод псевдографики. Больше демо-сцену напоминает.
Для БК-11М (со 128кБ) был файловый менеджер, внешне смахивающий на Нортон. И на спектрумах тоже что-то было.
Хз где они были в актуальное время. Почему-то повылезли все под закат эпохи.
Здравствуйте, pagid_, Вы писали:
_>Что бы ему не быть на это способным, если псевдографику умел на экран выводить?
А почему слово псевдо? Там режим был один только — графический. А отдельных клонах режимов было больше конечно, но именно общепринятый режим только один.
Здравствуйте, elmal, Вы писали:
E>А почему слово псевдо? Там режим был один только — графический.
Век живи — узнаешь что-нибудь новое, и нафиг не нужное
Не знал, потому как не интересовался.
Здравствуйте, Alekzander, Вы писали:
A>Всё. Но, наверно, больше всего — переключение кодировок W1251/KOI8/ANSI на лету в файл-вьювере.
А какие собственно проблемы то? Кодировка описывается массивом из 128 байт максимум, причем уверен что можно еще как то дополнительно исхитриться.
48 килобайт оперативки это довольно много для достаточно сложного функционала.
В современных exe файлов до чета информации помимо кода программы. Туда ресурсы пихают, иногда высокого разрешения. Всякие таблицы преобразования адресов, таблицы для стыковки с библиотеками, может быть отладочная инфа, заглушка при запуске из DOS и тому подобное. Тогда программа представляла собой тупо слепок памяти как набор байтов и все. Файловая система примитивнейшая, имя файла (8 байт), байт расширение, длина, стартовый сектор. Разрешение низкое, потому шрифты и ресурсы много памяти не занимают. Пишется все на ассемблере, собственно под DOS когда были COM файлы, а не exe — там программы были тоже весьма компактные.
Так что именно клон нортона далался без проблем, я сам лично в свое время делал, хоть и не доделал но выглядело у меня похоже. Я даже папки эмулировал.
Что меня весьма впечатляет до сих пор — это всякие мультиколорные игрушки. Реально круть, я б до такого не додумался. А также 3д движки с текстурами. А потом собственно мультиколору особо уже не удивлялся, когда прочитал про то, как делали графику на ZX80 когда тупо синхронизировались с ходом луча. Но собственно это тоже далеко не рокет сайнс, во всяких семисегментных индикаторах (при подключении их в ряд минимальным количеством проводов) бывает применяют подобные приемы.
Соответственно не нужно считать разработчиков тех лет идиотами, что не могли на том железе сделать то, что является стандартом сейчас. И не следует современных считать дебилами и считать что те прошлые навыки забылись. Ничего не забыло и если требуется, оптимизируют и еще как оптимизируют и сейчас.
Здравствуйте, fk0, Вы писали:
fk0>Ещё Honey Commander от Микроарта (бесполезный, но красивый).
Совсем не бесполезный, если на машинах, для которых он писался (ATM-Turbo).
Да, он большой (100кб ОЗУ занимал), на 128кб машинах свободного ОЗУ почти не оставалось.
А вот на АТМ с 512кб оперативки (а то и 1мб, но я таких в те годы не видел) — ситуация намноооого веселее. Создаёшь РАМ-диск. И закидываешь файлы на него. Уникальная фича в 1995 году!
А ещё был режим резидента — когда по Reset'у мы вываливаемся в Хоник.
Здравствуйте, Alekzander, Вы писали:
A>Мы говорили про файл-вьювер, и я отметил, что один только буфер под текст, отображаемый за раз на экране, занимает 1/32 ВСЕЙ памяти.
А нафига плодить сущности под этот буфер? Можно без буфера. Текст сидит в памяти. Рендерить прямо в экранную область без буфера. Скроллить тоже сразу в экранной области. А буфер только под первую и последнюю строки может понадобиться для задачи скроллинга и подобного. Поиск делать прям в тексте. Дополнительно текст еще можно в принципе скомпрессировать каким простым компрессором чтоб на символ требовалось не 8 бит, а меньше, около 6 бит и практически без потери производительности.
Здравствуйте, Alekzander, Вы писали:
A>Я бы сказал, вообще писать под него софт смысла нет. Кроме как из любви к искусству, конечно (что я уважаю). А именно этот я выбрал, потому, что он как раз максимально непохож на спектрумовские программы, а похож на что-то более писишное (см. заголовок: "Угадай компьютер с трёх скриншотов").
В 90-е годы писалось до черта софта, которые были весьма похожи на писишные. В основном на просторах бывшего СССР. Текстовые редакторы были весьма приличные. Trdos navigator вообще я не застал, если что, всеж 2007 год. Да,довольно круто. Но я застал Honey commander с подобными возможностями, я его в свое время хакал чтоб он нормально работал на стандартоном 128 пентагоне. Еще был nc который выглядел примерно также, 64 символа в строке.
А вообще кстати некоторые извращались и фигачили и 80 символов в строке. Но было еле читаемо все. А 64 символа в строке вполне нормально читалось, собственно практически это стандарт был для советских компов.
И написали в свое время вообще IS-DOS. Там 48 символов в строке было и навернули весьма хорошо, аж каталоги были. С моей точки зрения зря они в операционную систему оболочку типа нортона встроили, лучше б всеж отдельно чтоб это было. А так вообще сделали практически DOS что на ПК. И языки программирования были, и командная строка, и возможность автоматизации. И самое прикольное что еще дискеты автоматически стартовали при любой команде диской, запуск был через ошибку переполнения буфера и я был крайне впечатлен в свое время.
Здравствуйте, Marty, Вы писали:
M>Четыре пикселя на символ — это жестко.
4 не жестко, читаемость и разбираемость таких символов была достаточно хорошая. Веселее было когда на символ было 3 пикселя, вот там уже выглядело по уродски и нечитаемо, плюс 80 не кратно 256.
5 пикселей по ширине на пиксель особо читаемости не прибывлял. А именно 8 при таком экране было сильно избыточно. И выглядело один черт фигово, по крайней мере шрифт по умолчанию. Хотя шрифтов было до черта нестандартных и прикольно выглящих. А 4 пикселя на символ — там собственно со шрифтами не разгуляешься и шрифт такой был скорее всего один. Но читаемый вполне.
Re: is dos писал искарсофт который не заработав на OS
Здравствуйте, elmal, Вы писали:
A>>Мы говорили про файл-вьювер, и я отметил, что один только буфер под текст, отображаемый за раз на экране, занимает 1/32 ВСЕЙ памяти. E>А нафига плодить сущности под этот буфер? Можно без буфера. Текст сидит в памяти.
Я говорил не про экранный буфер, а про буферизацию содержимого файла с диска в оперативной памяти перед выводом на экран. То, что ты называешь "текст сидит в памяти". Учитывая, что максимальный размер файла в TR-DOS был 65К, ты не можешь просто считать весь файл в память. А если ты хочешь рисовать экран текста не более, чем за одно обращение к дискете, тебе надо считывать не менее, чем по 24*64 байта, что составляет аж 1/32 всей памяти. Или точнее, 22*64, потому, что отображать надо на две строки меньше.
Здравствуйте, Alekzander, Вы писали:
A>Я говорил не про экранный буфер, а про буферизацию содержимого файла с диска в оперативной памяти перед выводом на экран. То, что ты называешь "текст сидит в памяти". Учитывая, что максимальный размер файла в TR-DOS был 65К, ты не можешь просто считать весь файл в память.
А на TRDOS никто обработкой именно больших текстов и не занимался. Текст в памяти сидел всегда. Собственно TR-DOS это вообще примитивнейшая OS которую даже OS назвать сложно. По существу это тот же интерфейс для загрузки файлов, как с магнитофона командами LOAD и SAVE плюс DELETE. И форматирование.
CP/M вроде как аналогично — OS чуть посложнее чем TR-DOS, но тоже крайне все примитивно.
В память считать весь файл можешь — если у тебя 128 кб. Что собственно и делали. Но обычно таких огромных файлов текстовых тупо не было. Обычно в таких файлах распространялась документация к софту. Были еще электронные газеты и журналы, но они собственно были не совсем стандартного формата со своим загрузчиком, там еще и музыка и какие картинки могли быть. В любом случае на дискету не влезало более 640 килобайт.
Уже не помню про IS-DOS, там вроде можно уже обрабатывать файлы больших размеров чем позволяет память. Но там наворотили ого го. Но собственно IS-DOS на 48 кб можно наверно разве что поиграться. Там сама OS в памяти жрет большую часть. На 128 машинах получше, но не на много. Вроде как нормально стало на весьма крутых машинах, где мегабайт оперативной памяти, контроллер HDD и все такое.
Здравствуйте, Alekzander, Вы писали:
A>Я говорил не про экранный буфер, а про буферизацию содержимого файла с диска в оперативной памяти перед выводом на экран. То, что ты называешь "текст сидит в памяти". Учитывая, что максимальный размер файла в TR-DOS был 65К, ты не можешь просто считать весь файл в память. А если ты хочешь рисовать экран текста не более, чем за одно обращение к дискете, тебе надо считывать не менее, чем по 24*64 байта, что составляет аж 1/32 всей памяти. Или точнее, 22*64, потому, что отображать надо на две строки меньше.
И чо такого? Пусть хоть 1/4ую составляет, какая проблема?
Половина файла влезает в память. Перечитывать надо только когда переходим через границу.
Если оптимизировать, то я хранил бы отдельно начало текста и конец текста — чтобы Home/End срабатывали мгновенно. Далее, по переходу Home/End дочитывать после/до некоторое количество текста. Когда находимся где-то на середине — не всё забиваем под данные, оставляем место под ещё одну страничку как минимум — чтобы дочитывать не тогда, когда уже прямо надо, а заранее. Тут вот не помню, можно ли было запустить асинхронно чтение с диска (с TR-DOS особо не работал), если нет — то тогда приседать особо и не надо вообще.
Здравствуйте, elmal, Вы писали:
E>Уже не помню про IS-DOS, там вроде можно уже обрабатывать файлы больших размеров чем позволяет память. Но там наворотили ого го. Но собственно IS-DOS на 48 кб можно наверно разве что поиграться. Там сама OS в памяти жрет большую часть. На 128 машинах получше, но не на много. Вроде как нормально стало на весьма крутых машинах, где мегабайт оперативной памяти, контроллер HDD и все такое.
На скорпионе с 256 Кб было нормас. Вот не помню, был ли у меня на скорпионе HDD или нет — могу путать, потому что на первой PC у меня был винт 40 метров, и за прошествием времени он у меня в памяти мог прицепится и к скорпиону. Но дисководов два было, 5.25 и 3.5, и совершенно без проблем я писал разные тексты и носил их в ВУЗ
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Alekzander, Вы писали: S>стал продавать ковровые покрытия
Да, я тоже от этого удивился. Причем про торговлю коврами я узнал гораздо раньше, чем про IS-DOS. В принципе, они могли бы взлететь, если бы сделали IS-DOS и для писюков. Система была прикольная, то, что оболочка сразу в комплекте была — это было удобно, и за счет этого в тч система предоставляла больше сервиса прикладной программе, чем MS-DOS и пр
Здравствуйте, Alekzander, Вы писали: M>>Если оптимизировать, то я хранил бы отдельно начало текста и конец текста A>Вот уж чего я бы никогда не стал делать при заданных условиях (размер памяти и ограничение на размер файла).
Ну и зря. Мотануть в начало/конец — довольно частый кейс, если будешь каждый раз подгружать данные из файла, то это отстой.
Гораздо лучше сделать что-то типа упаковки на лету — слова помещаем в словарь, и в данные вставляем 12 бит — старший бит — 0x800 — маркер, что это слово, остальные 11 бит — индекс слова в словаре. Ещё 3 бита есть закодировать самые частые символы. 0 — нет упаковки, следом идёт 8 бит символа, 1-3 — это пробел, запятая, точка — самые часто встречающиеся символы (на 46Кб текста — 7.5Кб одних пробелов, и порядка 850 точек и запятых), доп 8 бит для них не требуется. У меня на ~46 кб тексте получилось 28% сэкономить. И это я особо не думал. Если в TR-DOS файлы 65Кб макс, то, в принципе, для текстовиков можно посидеть придумать алгоритм, чтобы запаковать побыстрому всё это в память.
11 бит на слово — у меня словарь больше получился, не получается, придётся два байта на слово использовать. Но тогда у нас 7 бит останется, чтобы закодировать все хоть сколько частотные символы (на моём тексте их 32 — 5 бит). Если текст — код программы, то символов будет побольше, но, думаю, упакуются все.
Единственно, что у меня в моём алгоритме на скорую руку хэш-мап использовался, и я не учитывал расходы памяти на неё. Но, думаю, если посидеть подумать, то извернуться можно. Хоть тупым перебором. Если первым байтом хранить длину слова в словаре, то можно пропускать без сравнения слова с отличающейся длиной. Всё равно это будет достаточно быстро, и на фоне работы с дискетой несколько лишних секунд никто всё равно не заметит. Ну, и с различными кодировками надо подумать как быть, я пока накидал только для латинници.
Интересно, этот просмотрщик он только раз файл в память считывает (любой, хоть 65535 байт размером), и потом всё в памяти делает, или он таки лазает на диск? И при перекодировке — лазает на диск?
ЗЫ Убрал латинский текст, оставил только английский — чутка получше получилось
В принципе, у нас 26 букв в двух регистрах — 52 символа, 33 русских буквы — 66 всего, итого 118 букв, можно в 7 бит затолкать. Или ставить маркер — латиница/кирилица, и тогда можно затолкать в 6 бит на символ — твердый и мягкий знак заглавные можно выбросить, и кириллица влезает тоже (или выбросить обе ёЁ). Длину хранить где-то надо, можно ASCII-Z строки, а можно сначала байт длины хранить. Один бит — маркер Cyr/Lat, и 7 бит на длину слова — итого слова длиной больше 127 символов не получится хранить в словаре — хм, не беда, длинные слова можно разбить на несколько слов. Микс из Cyr/Lat тоже разбиваем на отдельные слова. Но это исключительные кейсы. 6 букв в среднем в слове по 6 бит — 36 бит, или 5 байт. Один байт сэкономили, слов в словаре больше 2 тысяч — вот тебе как с куста два килобайта освободилось.
В принципе, тут ещё можно сделать упаковку второго уровня — посчитать статистику по парам букв, и наиболее частотные пары упаковать в один байт. Ещё в словаре можно хранить строки в нижнем регистре, а при ссылке на словарь добавлять маркер строчные/Спрописной/ПРОПИСНЫЕ и при выводе на экран учитывать его (у нас два байта на слово, один бит зарезервирован как маркер слова, осталось 15, 2 бита на маркер — осталось 13 бит — это словарь из 8192 слов — вряд ли в 65Кб текста будет столько разных слов). Тогда буква в словаре будет занимать 5 бит, на 6ти буквах экономим 18 бит — два байта, на 2К слов — это уже 4 Кб свободной памяти.
В общем, можно ещё поизвращаться. И, кстати, не думаю, что в этом вьювере так запаривались
Ещё есть варик — сократить количество кода программы. Можно писать код как position independed (или транслировать с одного адреса), и отдельные большие блоки зиповать (или как-то сжимать). Например, общие утилиты всегда в памяти распакованы, а остальное — по требованию — например, перешли в режим просмотра — потёрли распакованный модуль двухпанельного файл-менеджера, и распаковали модуль просмотрщика. И обратно — вышли из просмотра, потерли код просмотрщика, и распаковали код файл-менеджера. Как долго будет зиповаться, и насколько большой код архиватора — не важно, это один раз при сборке проги делается, главное, чтобы код распаковщика был минимальным, и было много разных жирных хорошо пакующихся модулей, которые между собой не взаимодействуют. Хотя тут конечно ещё нужен буфер для распакованного кода. Но попробовать можно.
Здравствуйте, Marty, Вы писали:
M>Как долго будет зиповаться, и насколько большой код архиватора — не важно, это один раз при сборке проги делается, главное, чтобы код распаковщика был минимальным, и было много разных жирных хорошо пакующихся модулей, которые между собой не взаимодействуют. Хотя тут конечно ещё нужен буфер для распакованного кода. Но попробовать можно.
Помню был копировщик программ магнитофонных, который позволял на обычном спектруме копировать программы больше 48 килобайт — во-первых, он затирал часть экрана, во-вторых — применял сжатие, в третьих — был специальный режим, когда максимально выгружался код самого копировщика и после загрузки можно было сделать только одно действие — выгрузить текующую программу.
Здравствуйте, Marty, Вы писали:
M>Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей
Шрифт хранился в памяти — можно было напихать произвольную форму любой буквы. Делал псевдографику вполне успешно, когда рисовал свой вариант турбо-среды под впечатлением от продуктов Борланда (тогда не было IBM ещё дома)
Здравствуйте, Mr.Delphist, Вы писали:
M>>Псевдографики там как раз и не было. Был единственный графический режим, 256x192 пикселей. На псевдографику там смахивала только система цветовых атрибутов, которая один цвет фронта/бэка задавала для поля 8x8 пикселей
MD>Шрифт хранился в памяти — можно было напихать произвольную форму любой буквы. Делал псевдографику вполне успешно, когда рисовал свой вариант турбо-среды под впечатлением от продуктов Борланда (тогда не было IBM ещё дома)
Это называется графический режим. Псевдографика это о том, что графического режима нет, есть знакогенератор, которыйц используется для вывода, и всё
Здравствуйте, sambl74, Вы писали:
S>Помню был копировщик программ магнитофонных
В детстве долго не мог понять, зачем такая программа вообще нужна, когда есть двухкассетник
Вопрос, кстати, не так прост, если глубоко копнуть. Я только недавно разобрался. У Бэббиджа был стимпанковский компьютер на шестерёнках. Шестерёнка кодировала значение от 0 до 9 и имела доводчик (компенсатор недо- и переворотов), благодаря которому осуществлялась коррекция ошибок. Так вот, если бы она кодировала больше значений, то и хранила бы больше информации. По мере приближения к континууму, объём хранения данных в одной шестерёнке стремился бы к бесконечности... но при этом вероятность считывания стремилась бы к нулю. Физика, жестокая ты сука.
