Re: 16-цветный режим для ZX

[Kirill Frolov (2:5030/827.2)]

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> А кто мне память защитит?

Ты лучше спроси, что с биосом будет, который в банке сидел. Хе-хе...

[Kirill Frolov (2:5030/827.2)]

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 (пример -- в батник не поместить) оно всё
смысла не имеет -- бесцельно потраченное время.

[elf/2]

Жми F11, откроется менюшка, где выбери опцию "Creatr TR-DOS image". А там уже
в открывшемся окошке выберешь что именно тебе надо - TRD, SCL или FDI.

только не забудь поставить плагин xCreate

С этой проблемой не знаком, так как в FARе с ZIPами просто не приходилось
работать. Всегда архивы по привычке распаковывал через винду WINRAR'ом... Так
что тут помочь не смогу.

я тоже никогда с такой проблемой не сталкивался, но можешь попробовать поменять MultiArc на 7-zip (ну или использовать их совместно)

[Kirill Frolov (2:5030/827.2)]

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 [email protected]; 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.

[Kirill Frolov (2:5030/827.2)]

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 умеют!

Только у них мегабайтов и мегагерцев в разы по-более чем у спектрума.

[Danil Davydov (2:5050/151.11)]

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
---

[Advertiser]

[Maxim Timonin (2:5020/400)]

From: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)<hr>
From: "Maxim Timonin" <[email protected]>

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+

[Vladimir Bogdanovitch (2:5090/108.21)]

From: Krasnoyarsk_Russia (CenterSibNet)<hr>
In a message of 14 Oct 05 Kirill Frolov wrote to me:

2. Взять info-zip:

БРАТЬ ВИHДОВУЮ ВЕРСИЮ, HЕ ДЛЯ MS-DOS!

3. В фаре, в настройках архиваторов, поменять командные строки на
правильные.

А виндовая веpсия будет pаботать с Far'ом? Кто бы мне наpисовал пpавильные
командные стpоки, а я бы уж поменял.

(5). Far выкинуть туда же, куда и pkzip.

Мне нужно pаботать с кучей файлов, да еще и со спектpумовскими файлами
одновpеменно. Hужна большая опеpативность (ZX-коллекция очень большая)!
Меня устpаивал стаpый Far и стаpые zip'ы, но все это баpахло не хочет
pаботать но новом ПЦ, вот после апгpейда и мучаюсь до сих поp. Вpемени
очень мало pазбиpаться во всем этом. Хочется те кpохи, что имеются
использовать для ZX-коллекции, а не получается. Коpоче - у меня установлен
Far v1.70b5 и мне нужно, чтобы в нем ноpмально pаботалось с zip аpхивами!

vBv [2CD NZXS v3.15 (23.09.2005)]

[Kirill Frolov (2:5030/827.2)]

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о что касается архивации вообще -- это абсолютный бред,
пытаться делать это руками. ЗАЧЕМ? Всё равно же потом а) извлекать,
б) обновлять. Достаточно иметь иерархию каталогов, куда и раскладывать
файлы. Вручную уже. А запаковывать можно чем угодно и как угодно, хоть
целиком всё для сжатия, хоть пофайлово для удобства.

[Vadik Akimoff (2:5020/835.1)]

From: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)<hr>
Hi!

In a message of 14 Oct 05 Kirill Frolov wrote to me:

Hикак. Я вообще не понимаю ваш энтузиазм делать это на
спектруме. Есть нормальные редакторы, там это делается в 50 раз
быстрей чем на спектруме. В спектрум пока 8 файлов загрузишь...
тут уж и не важно каким редактором или ассемблером.

Гы, последнее время я кодю в аласме, лёжа на диване с ноутом на коленях =))

Мог бы делать это в MED'е, например, и asl'ом собирать, но только вот потом
постоянно трамбовать в снапшот и пихать в эмуль - меня совершенно не
улыбает.


Bye...