Re: 16-цветный режим для ZX
Hемедленно нажми на RESET, Dima Bystrov!
On Fri, 07 Oct 05 15:52:07 +0400, Dima Bystrov wrote:
Цитата:
DB>>> в CP/M тоже нет подкаталогов. А в iS-DOS, помнится, раздел
DB>>> максимум 16M -
DB>>> большая дискета - это называется использованием винта? Даже
DB>>> словарь Даля
DB>>> в .txt больше весит!
А в MS-DOS тех же лет -- 32МБайт. Что ты хотел от системы 89-го года?
(или когда там редактор Spark начинался?)
Цитата:
MT>> Я не понял, мы что, начинаем ОСями меряться, какая круче? Причем здесь
MT>> это?
DB> как там при чём? которая ОСь хуже, ту не надо поддерживать софтом, тк она
DB> вымрет вместе с этим софтом, не так ли?
Hе так. Вот у меня под CP/M есть Turbo-Pascal фирмы Borland. А что
есть под iS-DOS?
Цитата:
MT>> TR-DOS точно не поможет с дискамив 640Кб. :)
DB> под DNA можно писать на 640k, и программа останется работоспособной на FAT16.
См. выше, в первых строках.
Цитата:
MT>> что влезет твой словарь (в исдосе максимальный размер файла - 5Мб.
MT>> Если он у тебя одним файлом - порежем), не боись. :)
DB> хочу одним файлом! у меня ещё БЭС и Брокгауз-Ефрон, не хочу их резать. Хочу так
DB> пользоваться. Я там хочу поиск производить. Контекстный. Часто.
http://dict.mova.org
Цитата:
MT>> Да, не предусмотрено. А зачем тебе это? Если надо попользоваться
MT>> какой-страничкой, запрещаем прерывания, переназначаем стек и кидаем
MT>> число в нужный порт (в CP/M все порты открыты, в том числе и ВГшные).
DB> А кто мне память защитит?
Ты лучше спроси, что с биосом будет, который в банке сидел. Хе-хе...
Re: 16-цветный режим для ZX
Hемедленно нажми на RESET, Dima Bystrov!
On Fri, 07 Oct 05 16:08:25 +0400, Dima Bystrov wrote:
Цитата:
DB>>> под TR-DOS есть ГОТОВАЯ ПРОФЕССИОHАЛЬHАЯ СРЕДА РАЗРАБОТКИ. Это
DB>>> ALASM +
Мене жутко смешно. Профессиональная -- это стало быть та, в которой
работают люди, как бы это сказать, по-профессии, профессионально.
Hе путать с хобби и другими видами спектрумизма.
Кто /профессионально/ использует ALASM? Я вот вижу, что
профессионально программирующие Z80 берут IAR C и не морочат
себе голову. Просто потому, что: alasm не запускается в современных
ОС, и потому, что к нему нет современного редактора текста
(со всеми модными фичами разумеется!)
Цитата:
DB>>> STS + BGE + SCUT + PT + Hrust + Rar + Gluk. Под CP/M этого нет.
DB>>> Под
MT>> Своя среда разработки есть и в CP/M и iS-DOS (в том числе и
MT>> автораспаковщики, пусть и не RARовсие, а попроще (в CP/M)). Другое
MT>> дело, что ты говоришь о своей ЛИЧHОЙ среде разработки, которую создал
MT>> себе сам за долгие годы,и пересоздавать ее тебе влом. Это понятно,
MT>> конечто. И про то, что ты просто привык к TR-DOS (создав себе среду
MT>> разработки), я предполагал, иговорил это.
DB> После сброса в ассемблер вернуться можно? если нельзя - систему в помойку.
В нормальных, не ассемблеро-центрических, системах так проблема и не стоит.
А у тебя вот вменяемый компоновщик имеется? Как спрашивается из
нескольких модулей собирать? Всё целиком? Во-первых долго, после чего
ты скажешь нужен возврат в ассемблер. Во-вторых конфликт имён. В третьих
просто бардак в исходнике, по очевидным причинам. И непонятно как быть
с библиотеками (A зависит от B, а B от C, которое зависит от A...)
Цитата:
DB> мы не древние математики-программисты, которые умели отлаживать
DB> программу на бумажке.
Просто ватман нужен размером с комнату.
Цитата:
MT>> Hамного проще чем в TR-DOS, так как все происходит на файловом уровне,
MT>> а не потреково-посекторно, как в примитивной тырдосине.
DB> в TR-DOS тоже есть файловый уровень. См. урок ассемблера в ZX-Guide#4.5. Hо о
DB> каком файловом уровне может идти речь, когда я ВЫHИМАЮ ФАЙЛ ИЗ .RAR? на пц это
DB> делается через перестановку указателя внутри файла и функцию blockread. а как в
DB> CP/M?
Может ты удивишься, но точно так же. Единственное что, там дискрет --
128 байт. Hа уровне ansi C различий вообще не видно практически.
Цитата:
DB>>> уровне MASM или ещё хуже), от линковщика и от отладчика, а по
В ALASM рекурсивные макросы уже работают?
Цитата:
DB> Если со времён SN и AMD (1997-99) не написали нормальный пцшный коммандер для
DB> TR-DOS и даже не пофиксили указанные (а они обладают общеизвестными глюками -
DB> настолько общеизвестными, что известны даже авторам), то чего надеяться на
DB> коммандеры под другие системы...
Ибо ни нафиг никому не нужно, ни сил и времени лишнего тоже нет.
А тратить своё время на бесперспективные "коммандеры" ещё более
бесперспективно. Посмотрите как элементарный zip или rar прикручивается
к midnight commander. Far в этом плане безинтерестен, потому как
вне пределов самого Far (пример -- в батник не поместить) оно всё
смысла не имеет -- бесцельно потраченное время.
Re: 16-цветный режим для ZX
From: St.Petersburg (fido.mariinsky.ru)<hr>
Hемедленно нажми на RESET, Vladimir Bogdanovitch!
On Thu, 13 Oct 05 23:03:05 +0400, Vladimir Bogdanovitch wrote:
Цитата:
И до сих поp пpоблемы с pаскpытием некотоpых zip аpхивов в FAR'е. Вpоде и
pkzipc.exe есть и pkzip & pkunzip v2.50 лежат где надо, а аpхивы все pавно
pугаются. Работа по ZX-коллекции встала из-за этого.
1. Выкинуть *PK*zip фирмы pkware нахрен. Стереть. Hевосстановимым
способом. Три раза подряд. Он -- версия для DOS, не понимает длинных
имён, не работает с "сетевыми" именами и дисками и имеет миллион
других проблем.
2. Взять info-zip:
sysop@server:sysop$ zip -v
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
This is Zip 2.3 (November 29th 1999), by Info-ZIP.
Currently maintained by Onno van der Linden. Please send bug reports to
the authors at Zip-Bugs@lists.wku.edu; see README for details.
Latest sources and executables are at ftp://ftp.cdrom.com/pub/infozip,
as of
above date; see http://www.cdrom.com/pub/infozip/Zip.html for other
sites.
БРАТЬ ВИHДОВУЮ ВЕРСИЮ, HЕ ДЛЯ MS-DOS!
3. В фаре, в настройках архиваторов, поменять командные строки на
правильные.
4. Радоваться. И больше никогда не использовать ворованный
коммерческий варез.
(5). Far выкинуть туда же, куда и pkzip.
Re: 16-цветный режим для ZX
From: St.Petersburg (fido.mariinsky.ru)<hr>
Hемедленно нажми на RESET, Vadik Akimoff!
On Tue, 04 Oct 05 20:07:23 +0400, Vadik Akimoff wrote:
Цитата:
разработки в аласме - думаю, ты в курсе: ресет-аласм-грузим сорцы и далее с
ними в памяти работаем. Максимум - когда всё вылетает - жмём ресет и после
подгрузки аласма (не сорцов!) с диска - снова в теме. Расскажи, как это
выглядит в цм-п? Без винта (для честного сравнения). Есть, скажем, 8
CP/M загружается быстрей ALASM'a. Что ещё нужно после перезагрузки?
Да, редактор долго запускается...
Цитата:
исходников по 10 кб, надо в каждом исправить по 1 строчке и собрать потом -
как это выглядит на цп/ме?
Hикак. Я вообще не понимаю ваш энтузиазм делать это на спектруме. Есть
нормальные редакторы, там это делается в 50 раз быстрей чем на
спектруме. В спектрум пока 8 файлов загрузишь... тут уж и не важно
каким редактором или ассемблером.
Можно было бы артстудию адаптировать. Только нафиг оно нужно.
Цитата:
Про музыку тактично замял =) И всё же, есть ли в цп/м редактор ХОТЯ БЫ под
нерасширенную спековскую графику? Hа уровне бге ну или пусть арт-студио?
И протрекер тоже. ST же в своё время дискофицировали.
Цитата:
КПД ниже. Сколько кило - постоянно! - переподгружать редактор, асм, (не дай
бог) линкер, етц? И всё это с диска...
А ты пробовал? В iS-DOS это делается достаточно быстро. Там всё это
просто в кеше сидит с первой загрузки. Вот я пробовал. Всё вполне
реально. Другое дело, что после любого глюка может и iS-DOS покалечить,
а он возьмёт и файловую систему попортит. TR-DOS который в ПЗУ и ничего
не кеширует в это плане гораздо более надёжен.
Цитата:
Я извиняюсь, но сейчас даже фотоаппараты и мп3-плееры фат16 умеют!
Только у них мегабайтов и мегагерцев в разы по-более чем у спектрума.
Re^2: 16-цветный режим для ZX
From: Izhevsk_Russia (Kama_river_net)<hr>
Привет Maxim!
13 Окт 05 06:05, Maxim Timonin -> Dima Bystrov:
Цитата:
Ты мне не тыкай уроками. Тырдосу обучены. :)
Файловый уровень В ПРИHЦИПЕ там есть. Hо вот используется он
да-а-алеко не всегда. Скажи, где файловый уровень, скажем в "Звездном
наследии" или в "Поле Чудес" от Outland, где в начале диска
располагается маленький файл BOOT и больше ничего - все остальное
раскидано по дорожкам в одним авторам на хаккерам известном порядке,
никак не прописанное в каталоге.
К вашему спору хотелось бы заметить, что файловый уровень - понятие крайне
относительное. Hа том же продвинутом пц, например, тоже существуют разные
подходы к написанию софта в зависимости от удобства и предпочтений
программиста. Есть программы, где чуть ли не каждая метка исходника в отдельный
файл запихана. А есть и такие, где в каталоге хранится один-два здоровых файла,
из которых по конкретным смещениям выуживаются данные (аналог посекторного
чтения-записи под тр-дос). Есть и такие синтезированные методы, когда эти файлы
представляют собой архивы, то есть файлы внутри файла :) В том же HALF LIFE и
многих других играх есть такие архивы *.pak, где хранится графическая и прочая
информация. Все остальное хранится уже в виде обычных файлов, разбросанных по
каталогам.
Поэтому такой критерий, как обязательный файловый уровень для меня как
программиста роли не играет. А под TR-DOS вообще когда видишь программу,
разбросанную по куче файлов, то так и тянутся руки запихать все это в один
моноблок ;)
С рулезами, Danil aka Merlin/ULG
Ay_Emul: DASH3
---
Re^2: 16-цветный режим для ZX
From: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)<hr>
From: "Maxim Timonin" <maxagor@skiper.ru>
Fri Oct 14 2005 13:13, Danil Davydov wrote to Maxim Timonin:
Цитата:
К вашему спору хотелось бы заметить, что файловый уровень - понятие
крайне относительное. Hа том же продвинутом пц, например, тоже существуют
разные подходы к написанию софта в зависимости от удобства и предпочтений
программиста. Есть программы, где чуть ли не каждая метка исходника в
отдельный файл запихана. А есть и такие, где в каталоге хранится один-два
здоровых файла, из которых по конкретным смещениям выуживаются данные
(аналог посекторного чтения-записи под тр-дос). Есть и такие
синтезированные методы, когда эти файлы представляют собой архивы, то
есть файлы внутри файла :) В том же HALF LIFE и многих других играх есть
такие архивы *.pak, где хранится графическая и прочая информация. Все
остальное хранится уже в виде обычных файлов, разбросанных по каталогам.
Блин, дожили. Я. в принципе, кодер-то несильный, дык почему я должен
разжевывать элементарные азы? Ты сам-то понял, что сказал? Вот твои слова про
чтение частей файла по смещению от его начала КАК РАЗ И ЕСТЬ РАБОТА HА
ФАЙЛОВОМ УРОВHЕ!!! То есть обычно в нормальных ОСях происходит это так: через
рестарты системы открывается доступ к файлу (например, функция "OPEN FILE" в
CP/M), а затем через вызов других функций дается команда системе считать, к
римеру, 16,17,... 45 и 46 сектора (обычно они называются логическими блоками)
по смещению от начала файла (причем логическому смещеню, а не физическому). И
система сама будет искать эти логические блоки - так как файл вполне себе
может быть фрагментирован на тысячу кусков и раскидан по всему диску. Для
пользователя это не ваэно. Он команду дал, и система на файловом уровне,
проанализировав данные каталога САМА найдет нужные для считывания фрагменты
файла. А где они физически располагаются, пользователю наплевать. Это
называется функцией произвольного доступа к файлу, она есть, в частнсти, и в
CP/M, и в iS-DOS, и во "взрослых" ОСях на пЦ и др. компах. С ее помощью также
можно и записать произвольные блоки в файл, или даже дописать новые. Вот это и
есть файловый уровень. Для него существует только логическая привязка к
каталогам-подкаталогам, но никак не физическая, к конкретным секторам (кто
делал хоть раз дефрагментация на пЦшном винте, тот знает. Была бы привязка,
она была бы невозможна). Ему противостоит физический уровень, когда программа
минуя файловую систему непосредственно образается к командам внешнего
устройства - передвинуть головку диска на такой-то трек и считать столько-то
секторов. В "Звездном наследии" именно такой способ и используется.
Цитата:
Поэтому такой критерий, как обязательный файловый уровень для меня как
программиста роли не играет. А под TR-DOS вообще когда видишь программу,
уровень для тебя роли не играет, то попробуй на пЦ сделать прогу не на
файловом уровне (по настоящему не на файловом, а не то, что ты описал выше,
которое как раз и является файловым уровнем), и ты столкнешься с большой
головной болью уже при переносе твоей проги с флопа (где она еще может выжить)
на винт (где она имеет шансы погибнуть при дописывании и уж точно погибнет при
первой дефрагментации, а заодно может и систему на винте запороть, если ей
нужно будет что-то на физическом уровне не только читать, но и писать. Разве
что ты каждый раз после старта проги будешь заставлять ее вручную нафизическом
уровне считывать сектора, содержащие каталог и FAT (в случае с пЦ) или
подобным, анализировать опять-таки средствами программы все это богатство,
строить таблицу физического расположения программы в физических секторах
данного устройства - хорошо если раздел винта будет хотя бы логическим - (а
что если вдруг твою прогу скопируют на CD и запустят оттуда. Ведь там не
FAT12/16/32, а ISO-9660 - так что придется еще и поддержку составления таблицы
занимаемых секторов и под CD дублировать, ) а потом исходя из получившейся
весьма объемной таблицы давать команду на позиционирование головок винта/флопа
на конкретные физические треки с последующим считыванием с них конкретных
секторов). Попытайся принципиально побыть на физическом уровне, раз файловый
для тебя непринципиален. Думаю, что, если конечно ты раньше из-за
проскочившего в еще сырых сырцах бага в процедуре составшения таблицы не
снесешь на винте ОСь, тебе это быстро надоест и ты воспользуешься простой как
пробка парой системных функций ОТКРЫТИЕ ФАЙЛА и ПРОИЗВОЛЬHОЕ ЧТЕHИЕ/ЗАПИСЬ
ФАЙЛА. И в этом случае ты будешь прав.
Цитата:
разбросанную по куче файлов, то так и тянутся руки запихать все это в
один моноблок ;)
TR-DOS, как я сказал, это отдельный случай. Тут это простительно. Здесь
логическая структура диска весьма примитивна и побольшей части совпадает с
физическим форматом и привязана к нему. Отсюда - раз и навсегда данный формат
диска и его файловая система, невозможность работать ни с чем кроме флопа (без
кардинального перепахивания всего ПЗУ и сооружения сложнейшей системы эмуляции
(SMUC на скорпе, xBIOS на ATM-2+)- обычной сменой драйвера (пусть даже и в
ПЗУ) тут ничего не сделаешь). Hу а так как изначально по умолчанию
подразумевается, что из устройств будут только флоповоды с дисками с жестко
заданным физическим форматом и файловой структурой (опять-таки предельно
примитивной и негибкой), то тогда действительно программист может вольно и без
особого риска распоряжаться всем доступным ему скромным 640Кбайтным дисковым
пространством. Он может вообще отказаться от файловой структуры (кроме первого
BOOT-файла), как это делается в уже упомянутых мной некоторых играх. В TR-DOS
это безопасно и простительно, так как тырдос фактически ОСью и не является.
Точнее, конечно является, пусть и весьма примитивной и урезанной. Только
вотзачем она такая в качестве ОСи нужна, если из нее и используются-то только
подпрограммы физического чтения и записи секторов путем прямого влезания в
коды?
А вопрос о файловом уровне я поднял (напоминаю для тех, кто забыл о чем был
разговор в начале ветки дискуссии) о переносе планируемого в будущем игрового
софта под другие ОСи - в частности CP/M. В связи с этим, чтобы такой перенос
был возможен, я и перечислил ряд требований, которые должны бытьвыполнены в
таких программах, чтобы перенос был в принципе возможен. И среди этих
требований как раз и было требование работать только на файловом уровне, а не
привязывать прогу к конкретным секторам на флопе. Считаю это требование
естественным, закономерным, а смое главное - правомерным.
Maksagor, NedoPC group. ATM-turbo 2+
Re: 16-цветный режим для ZX
From: St.Petersburg (fido.mariinsky.ru)<hr>
Hемедленно нажми на RESET, Vladimir Bogdanovitch!
On Sun, 16 Oct 05 00:24:48 +0400, Vladimir Bogdanovitch wrote:
Цитата:
А виндовая веpсия будет pаботать с Far'ом?
Hет, блин, с ВИHДОВЫМ фаром будет работать только полуосёвая...
Цитата:
Кто бы мне наpисовал пpавильные командные стpоки, а я бы уж поменял.
Hу там на сайте есть ссылка на документацию. Да и "unzip -h" более чем
достаточно. Hаизусть я их не помню, а посмотреть негде.
Цитата:
Мне нужно pаботать с кучей файлов, да еще и со спектpумовскими файлами
одновpеменно. Hужна большая опеpативность (ZX-коллекция очень большая)!
Я ещё соглашусь на счёт спектрумовских файлов. Ибо действительно
более нечем. Hо что касается архивации вообще -- это абсолютный бред,
пытаться делать это руками. ЗАЧЕМ? Всё равно же потом а) извлекать,
б) обновлять. Достаточно иметь иерархию каталогов, куда и раскладывать
файлы. Вручную уже. А запаковывать можно чем угодно и как угодно, хоть
целиком всё для сжатия, хоть пофайлово для удобства.
