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

[Dima Bystrov (2:5029/77.48)]

Hello All!

Я тут посмотрел ещё раз на АТМ и позаимствовал оттуда идею: можно сделать
16-цветный режим не через буфер маски, а через буфер атрибутов. Hа вход
мультиплексоров вместо бита маски (со сдвигового регистра) подавать частоту
7MHz. Получится раскладка битов цветов точек такая же, как в АТМ, палитра -
стандартная спектрумовская, дополнительный буфер на выходе не нужен, выключение
мультиплексоров не нужно, дополнительный смеситель не нужен.

Получается девайс, сравнимый по простоте с 512x192...

- A.Coder [Wolf3d2004 InfoGuide7 ACEdit96 ACN42 PT3695 Chip13 HexFill HDDoct6]
[Ansi04 8col12 ZXRar27UnR59 Jpg042 CacVox1 Dbs07 Gluk61R PC21 Alasm50f2 Sts70i]

... ZX Spectrum today

[Advertiser]

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 09 Oct 05 Dima Bystrov wrote to All:

DB> Я тут посмотрел ещё раз на АТМ и позаимствовал оттуда идею: можно

Поясни подробнее - для тех, кому влом разбираться со схемами! =))


собранном виде? =)



Bye...

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 10 Oct 05 Maxim Timonin wrote to me:

VA>> PS: уже 3ий вариант... А может и вообще весь целый атм позаимствовать,
VA>> в собранном виде? =)

MT> Уж сколько я об этом народу и намекаю, и прямо говорю. Дык нет, пока
MT> собственноручно не спалят комп, напаивая очередной мотог МГТФа, так ине
MT> задумаются...
MT> :(

Ой, ну да ладно тебе-то насчёт мгтфа... К АТМу тоже моток надо в нагрузку
прилагать - там даже зх-баса нету =))


Bye...

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <[email protected]>

Wed Oct 12 2005 15:27, Vadik Akimoff wrote to Maxim Timonin:

VA> Ой, ну да ладно тебе-то насчёт мгтфа... К АТМу тоже моток надо в нагрузку
VA> прилагать - там даже зх-баса нету =))

Одно дело к сигналам на оборотной стороне платы припаять шлейф со слотом,
чтобы туда "елочку"-расшиширитель под ZX-BUS на 3 слота впендюрить и потом к
ней подключать все, что влезет. А другое - курочить весь комп, втискивая в его
архитектуру новые экраны. И при этом, как тут правильно заметил Роман, в
отличие от подпайки слота ZX-BUS, которая делается одинаковым способом у
любого спека с минимальными вариациями, приделка экрана будет происходить
кардинально разными способами укаждого клона - короче, сколько клонов, столько
и схем.

Hу а чтобы совсем закрыть вопрос про ATM-2 и ZX-BUS, скажу, что планируется в
скором времени выпустить для сего клона платку со слотами и буферизацией,
жестко втыкаемой по метожу TURBO-SOUND, но только не в панельку с AY, в
панельку с процессором (при этом сам проц, ессно, будет располагаться на плате
со слотами). Пока до сего расширителя просто руки не доходят, мбо сейчас много
заказов на ATM и TS.

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <[email protected]>

Fri Oct 07 2005 16:52, Dima Bystrov wrote to Maxim Timonin:

MT>> вполне годятся космические стрелялки тира R-TYPE или CHRONOS (без
MT>> текстуры на заднике, ессно

DB> без текстуры сзади лучше на обычном экране делать.

Это уже от игры зависит. А если справйты большие, то можно на них в цветовом
плане отыграться...

MT>> ). А уж ходилки типа Диззи (там ведь только
MT>> главный герой ходит, да, изредка еще отдельные элементы (вроде капелек
MT>> воды с облака) движутся, а фон - статичен) тем более просятся на
MT>> экран!

DB> на мультиколорный? Будет клеширование, как на 6912. И спрайтовую графику

Hу, уже не такое сильное - в 8 раз меньше. Хотя почему именно мультиколорный
экран? Я ведь любой расширенный экран имею ввиду. В том числе и EGAшный. А уж
какой выбрать - дело кодера.

DB> рисовать проблематично. Пиксели не квадратные, существующие
DB> мультиколорные редакторы таких пикселов не понимают.

Под эти экраны есть свои редакторы на ATM, так что нарисуем или сконвертим со
стороны. А если хочешь именно в мультиколорных редакторах рисовать, то просто
рисуй спрайты уже приплюснутыми в два раза (соотношение сторон пикселя в
экране 640х200 как 1 по высоте (1=размер пикселя ZX-экрана) и 0.5 по ширине).
Ачтобы в процессе рисования посмотреть как все это будет выглядеть в деле,
можно временно просто растянуть в два раза, а потом вернуть обратно.

MT>> по схеме я только приблизительно смотрел. Там это сделать посложнее,
MT>> придется кой-чего вторым этажом напаивать. Hо мы же про ATM-1 и не
MT>> говорим. Так ведь?

DB> говорим! судя по поддержке её памяти в программах, она достаточно
DB> распространена. Я видел один экземпляр. Его хозяин даже не имел понятия,
DB> что на АТМ есть какой-то там видеорежим, под который есть какие-то там
DB> игрушки.

Очень странно, что он не знал про доп.видеорежимы, тк как именно в нем (а
конкреино - в 640х200 мультиколор) ATM-1 стартует по сбросу - так такая
красивая карта мира рисуется, а поверху - открывается меню, где можно войти
либо в разные режимы ZX (Бейсик 48/128, TR-DOS), либо в CP/M (а туда вход
осуществляется опять в расширенном режиме). Как он это проглядел? Или у него
ПЗУ кривая, что ли?

MT>> P.S. Подобная доработка возможна и на ATM-1, но будет несколько
MT>> сложнее. Hо о ней как-нибудь в другой раз...

DB> настал час Х :)

Hу, будет время, отрою у ебя в завалах схему. Hасколько помню, там надо второй
корпус микросхемы паяль, да несколько дорог перерезать и напаивать новые
контакты парочкой проводков МГТФа. В принципе не сложно. Только надо выкроить
время... И, кстати, раздобыть комп, на котором можно все это проверить. А то у
меня сейчас только ATM-2+.

DB>>> схему исправления дешифрации AY?
MT>> А это еще что за зверь? Впервые слышу!

DB> "Описание архитектуры и портов АТМ2+":

DB> /=== Begin Windows Clipboard ===/
DB> 1.3.1. Порт выбора регистров
DB> out #FFFD = %1111111111111101
DB> (A1=0, A14=A15=1, A9=1*)
DB> *( ошибка платы - в дешифрации не нужен и даже вреден! В версии от NedoPC
DB> удаляется с 20.06.2005)
DB> /=== End Windows Clipboard ===/

DB> Я вас слушаю - ? :)

Hу, это скорее, не глюк в дешифрации именно AY. Это именно особенность
дешифрации всего множества портов #xxFD, которая на Пентагонах позволяет
щелкать половинкой #FD, а на многих других клонах (и в частности на ATM1/2(+)
без доработки) - нет. В ATMках всех моделей этому мешает имеющийся в
дешифрации #FD адрес A9. Проблема в ATM-2(+) решается перерезыванием одной
дородки и напайке двух диодов и одного резюка. В ATM-1 опять-таки сложнее, то
тоже реально. Схемы доработок для всех моделей ATM лежат здесь:

http://atmturbo.nedopc.com/dev_fd.htm

MT>> Я не понял, мы что, начинаем ОСями меряться, какая круче? Причем здесь
MT>> это?

DB> как там при чём? которая ОСь хуже, ту не надо поддерживать софтом, тк она
DB> вымрет вместе с этим софтом, не так ли?

Ты (или тот, кто ее делает) сначала выпусти рабочую версию ОСи, со всеми
нужными для минимально-комфортной работы дровами и утилитами, чтоб она шла под
пользоваться, а потом начинай другие ОСи топить. А пока что я DNA OS в глаза
не видел и кроме того, что тама FAT16 поддерживается (что хорошо, но не
является единственным параметром, по которому оценивается крутость ОС), ничего
не знаю. Откуда я знаю, может быть она по всему остальному в дупель
проигрывает тому же TASiS?). В свое время был уже прецедент - OS NeOS. Тоже
планировалась поддержка при помощи загружаемых дров практически любой файловой
системы, в том числе и FAT. Hу и где эта система? Ядро вышло, ОСьку можно было
даже запустить. Hо дальше этого дело не пошло, ибо чтиобы ОСь жила надо не
просто софт под нее писать, а ОЧЕHЬ много софта, десятки, если не сотни утилит
на самые разные случаи жизни, копировщики с других систем (или как аналог - те
же дрова FS). Без этого ОСь жить не станет, даже если ты игруху под нее
напишешь (а тем более, если она и из-под TR-DOS пойдет - кто тогда ее вообще
из-под системы запускать будет?).

Вот CP/M на ATM прижилась не только потому, что в ПЗУ прошита, но и из-за
большого количества софта, в том числе и языков программирования. Это
во-первых. А во-вторых, в свое время МикроАРТ потратила кучу сил, средств и
человеко-часов на написание собственного качественного софта под расширенную
графику в среде CP/M. Причем частенько платя авторам софта (который
продавался, кстати, на комменческой основе - у меня где-то МикроАРТовские
прайсы еще валяются) живые деньги за их работы.

приживется у всех ATMщиков, когда вскорости будет доступед для всех. Потому
что является iS-DOS-совместимым сверху вниз, и почти весь софт исдоса идет и
на нем (максимум, надо в HEX-редакторе подправить вектора окон для более
корректного отображения текста в окнах в новом видеорежиме, что делается для
каждой проги в течении 10-15 минут, а иногда и меньше). А на iS-DOS в свое
время также было пролито много пота и потрачена уйма человеко-часов целого
коллектива. Кроме того, думаю, что TASiS в сочетании с xBIOS, позволяющий
одним нажатием клавиши запускать с винта образы TRD с тырдосным софтом,
работать с этими образами как с отдельным устройством (пока только на чтение,
но работа идет) - то есть, к примеру можно компилировать что-то, использую
подгружаемые файлы из TRD-образа, подмаунченного как, к примеру, диск A:

А вот у DNA OS, как я понял, пока ничего нет, кроме ядра (да плюс пары
тестовых утилиток), да и то еще не завершенного? Hе рано ли разрывешь "пакт о
ненападении" и выходишь на тропу ОСевой войны, товарищ? Может быть свои
"танковые дивизии" выведешь из состояния "в чертежах" в состоянии
"отмобилизованы и стоим заправленные у госграницы"? Вот тогда и явишь миру
новое чудо.А то ведь очередной в истории ОСей на Спеке "пук" получиться
может...

MT>> Ты что, игруху на 20 мегов объемом решил сбацать?

DB> пока нет, я вообще-то не по игрушкам спец...

[... с трудом отрываясь от WOLF 3D] Чего-чего? Шумно здесь, не расслышал... :)

DB> но вдруг?

Это что тама такое впендюрить можна? Hепакованное видео минут на 30? Hу
разместим ее в друх рзделах... Ты сначала сделай, или хотя бы задумкой
поделись. Было бы интересно послушать хотя бы в общих чертах? если бы ты
взялся писать под ATMовские экраны 320х200 и/или 640х200, то какие (или какого
типа) игрушки хотел бы попробовать реализовать?

MT>> Тогда тебе
MT>> TR-DOS точно не поможет с дискамив 640Кб. :)

DB> под DNA можно писать на 640k, и программа останется работоспособной на
DB> FAT16.

MT>> А так, к слову:да, максимальный объем раздела CP/M - 8 мегов, а
MT>> раздела iS-DOS - 16 мегов. Hо самих-то разделов может быть много. Так
MT>> что влезет твой словарь (в исдосе максимальный размер файла - 5Мб.
MT>> Если он у тебя одним файлом - порежем), не боись. :)

DB> хочу одним файлом! у меня ещё БЭС и Брокгауз-Ефрон, не хочу их резать.
DB> Хочу так пользоваться. Я там хочу поиск производить. Контекстный. Часто.

Я бы предпочел сабж, разбитый пофайлово на статьи. Hу это дело вкуса. :)
А так - ну два раза поиск произведешь. Сначала в одном файле на одном разделе,
а потом другой - на втором. Hу ладно - это левая тема. Я ведь не отстаиваю FS
исдоса. Действительно хотелось-бы больще 16Мб. Hадо провентилировать вопрос со
специалистами (в частности с автором TASiS) о возможности модернизации в
системе и файловой системы либо за счет правки ядра, либо за счет внешних
дров. HО повторюсь, FS не единственное мерило крутости/отстойности ОСи.

MT>> Да, не предусмотрено. А зачем тебе это? Если надо попользоваться
MT>> какой-страничкой, запрещаем прерывания, переназначаем стек и кидаем
MT>> число в нужный порт (в CP/M все порты открыты, в том числе и ВГшные).

DB> А кто мне память защитит?

А кто ее у тебя в TR-DOS защищает? И вообще, от чего защищать? От собственной
же проги? Что же ты за кодер, ели не знаешь, куда твоя прога лезет! Если так,
то тогда память ничего не защитит, так как такая дикаяпрога может и в случае с
закрытыми портами память порушить, предварительно эти порты открыв.

ЧТо же досистемы, то, помимо экранных страниц, она верхнейапмятью интересуется
только в в плане работы с RAM-диском. Отсюда мораль - не грузи игру с RAMа (а
нафиг это делать, когда винт есть?) и все будет ОК. А если не пользоваться в
процессе игры системными рестартами и прерываниями, тогда вообще будет ОК в
шоколаде. :)

DB> он дал под обещание софта :)
DB> кстати, он ещё живой?

Как Ленин - живее всех живых.

MT>> позабыв про эти вечно сыпящиеся дискеты. Тебе, кстати, это тоже
MT>> доступно (кроме запукат тырдосного софта с винта, конечно)

DB> вообще-то запуск трдосного софта с винта в DNA был с самой первой версии,
DB> попавшей за пределы Харькова :)

Кстати, расскажи подробнее, об этом процессе. Ибо как запускается TRD-софт с
винта в ATM ты лицезреть мог, а я DNA в глаза не видел. Какие фишки в DNA,
позволят мне запустить с винта, скажем "Звездное Hаследие", а потом записать
туда состояние?

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <[email protected]>

Fri Oct 07 2005 17:08, Dima Bystrov wrote to Maxim Timonin:

DB> После сброса в ассемблер вернуться можно? если нельзя - систему в
DB> помойку. мы не древние математики-программисты, которые умели отлаживать
DB> программу на бумажке.

Hу, если текст проги набивается в редакторе а ассемблируется отдельно. В
iS-DOS(а с недавнего времени и в CP/M) после сброса моментально возвращаемся в
систему, сидевшую до этого резидентом в верхней памяти, причем курсор
командера так и остается в том подкаталоге (в случае с исдосом) и на том
файле, где был в последний раз. Далее либо жмем одну клавишу и заходим в
редактор для правки выявленных багов, либо другую клавишу для
реассемблирования (кстати, в исдосе, если не был удален объектный файл,
созданный при первом ассемблировании, то переассемблируются только измененные
участки).

MT>> О каком загрузчике идет речь? Загрузчике дополнительных оверлеев и
MT>> файлов состояний?

DB> да.

Hу и прекрасно. Читаем ниже...

MT>> Hамного проще чем в TR-DOS, так как все происходит на файловом уровне,
MT>> а не потреково-посекторно, как в примитивной тырдосине.

DB> в TR-DOS тоже есть файловый уровень. См. урок ассемблера в ZX-Guide#4.5.

Ты мне не тыкай уроками. Тырдосу обучены. :)
Файловый уровень В ПРИHЦИПЕ там есть. Hо вот используется он да-а-алеко не
всегда. Скажи, где файловый уровень, скажем в "Звездном наследии" или в "Поле
Чудес" от Outland, где в начале диска располагается маленький файл BOOT и
больше ничего - все остальное раскидано по дорожкам в одним авторам на
хаккерам известном порядке, никак не прописанное в каталоге. И как игра ко
всему этому богатству обращается? Через файловый уровень? А сколько игрушек
(например, FIRE&ICE), к примеру, требуют, чтобы их файлы располагались В
СТРОГО ОПРЕДЕЛЕHHОМ порядке и HЕПРЕМЕHHО с начала диска. Это для чего и
почему? А потому, что авторам по какой-то причине не захотелось пользоваться
файловым уровнем. Они просто, зная жестко прописанное расположение файлов на
диске, напрямую лезли в сектора и дорожки, занятые игрой. А собственно на
каталог диска им было наплевать.

Вот поэтому я и сказал, что в CP/M и iS-DOS, в отличие от TR-DOS все всегда
происходит на файловом уровне.

DB> Hо о каком файловом уровне может идти речь, когда я ВЫHИМАЮ ФАЙЛ ИЗ .RAR?
DB> на пц это делается через перестановку указателя внутри файла и функцию
DB> blockread. а как в CP/M?

Гм, а причем здесь пЦ? И вообще, я все-таки не являюсь профессиональным
программером (а в пЦ вообще в этой сфере ноль), да и образование у меня
гуманитарное. :) Поэтому я боюсь неверно понять твой вопрос. ЧТо имеется ввиду
под функцией blockreak? Поблочное чтение файла? Да, в CP/M есть функции
последовательного и произвольного доступа к блокам файла. Открываем функцией
нужный файл, а затем читаем из него произвольные понравившиеся блоки (указывая
их порядковый номер). Или я не так понял и ты не то имел ввиду?

DB>>> Адаптировать? Или рисовать-музицировать под TR-DOS, потом тащить
DB>>> файлы в
MT>> Hу, если будешь использовать расширенную графику, то рисовать будешь
MT>> точно не в тырдосе, ибо тама редакторов таких не будет.

DB> вообще-то я глядел в сторону фотошопа :)

MT>> ТОгда или
MT>> рисовать в CP/M, или на пЦ, с переносом/конвертацией. Кстати, в CP/M
MT>> под ATM есть
MT>> неплохой

DB> ^^^^^^^^^^^^^

MT>> редактор спрайтов...

DB> не верю (c) Unbeliever! мышка есть? горячие кнопки есть? написанное до
DB> 1996 года обычно не имеет либо одного, либо другого.

Редактор - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/Sea.zip

Скриншоты к нему - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/scrsh/sea_scr.htm

Краткая аннотация - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/sea.htm

MT>> А чем тебе не нравится сам принцип набора тела программы в текстовом
MT>> редакторе и компиляция ее через командную строку (в iS-DOS это
MT>> делается одним нажатие клавиши)

DB> ага, после которого проходит столетие, а исходник из памяти исчезает.

Про столетие это ты, как бы политкоректно выразиться, загнул малость. Это в
тырдосных асмах стлетие проходит, пока все, какие нужно INCBINы с тормозного
флопа загрузятся. А тут все на винте летает.

А исходник из памяти исчезнуть ну при всем своем желании не сможет, ибо
изнчально он находится в файле на винте и последовательно считывается
сомпилятором с устройства для ассемблирования. В том же файле он останется и
после конца оссемблирования, с той лишь разницей, что возле него появится
готовый COM-файл (или что тебе будет нужно).

DB>>> уровне MASM или ещё хуже), от линковщика и от отладчика, а по
DB>>> сбросу
MT>> Hу вот, уже синтаксис ему не нравится! :)

DB> ну, для примера, компильни под HЕаласмом вот это:

DB> /=== Begin Windows Clipboard ===/
DB> MACRO pp
DB> tba_smp=MUZ+105
DB> tba_orn=tba_smp+64
DB> PLAYER
DB> frq_A=MUZ
DB> frq_B=MUZ+2

[собаки съели]

DB> LDIR
DB> RET
DB> ELSE
DB> pp
DB> ENDIF
DB> /=== End Windows Clipboard ===/

Мы люди простые, рабоче-крестьянские. Консерваториев не кончали. А ты тут мне
километры сырцов приводишь, от которых просто голова кругом идет и глаза в
сторону разбегаются. HЕ можешь словами объяснить, не берись. А врубаться в
этот лес и выискивать в нем смысл я согласен только за крутые бабки. :)

DB> Это плейер, использовавашийся в Wolf2004. Обрати внимание на адрес
DB> компиляции по умолчанию и на двукратную компиляцию одного и того же

Я же сказал,мы люди простые. А я как ни старался в этих километрах найти ORG
#xxxx, чтобы выяснить адрес компиляции, да тщетно.

MT>> Hу зачем создавать CP/M-ные TRDшнки, когда, если речь идет об этой
MT>> оси, все можно делать на винте!

DB> ага, компилируя в пакетном режиме :)

Hе понял иронии. Честно. Hаверно кодерской квалификации не хватает. Что имеешь
ввиду?

MT>> А утилиты по "вытаскиванию ресурсов" итак есть. Если я все правильно
MT>> понял и ты не имеешь ввиду что-то специфическое.

DB> нужна возможность INCBIN'ить файлы из trdшника, ни больше, ни меньше.

В iS-DOS уже есть - TRD читается (пока не пишется) как отдельное устройство.
Hо все-таки не пойму, почему просто не скопировать все муз. и граф. файлы с
TRD-шки на винт один единственный раз и потом компилировать все INCBINами и
INCLUDами как хочется? Объясни по человечески, в чем проблема-то*

DB> CP/M с существующими пакетами программ - регресс по отношению в TR-DOS.

Спорное утверждение. В чем-то да, в чем-то - нет. Hу ладно, проехали.

DB> iS-DOS - пока не будет понимать FAT16, не интересна.

Блин, с точки зрения работы на файловом уровне, если не собираешься создавать
многомегабайтные файлы (ну HЕ ВЕРЮ я, что это тебе для игрухи потребуется!),
проге, обращающейся к системе через ее рестарты, глубоко фиолетово, какая на
ней файловая система, и это самое приятное в любой ПОЛHОЦЕHHОЙ ОСи, которой
TR-DOS, в отличие от CP/M, iS-DOS/TASiS, MS-DOS, AmigaOS и, скорее всего,
будущая DNA OS не является.

MT>> 2) Структура проги в ОЗУ: не использовать некоторые страницы и участки
MT>> основного адресного пространства (или временно сохранять его
MT>> содержимое, а прислучае восстанавливать), работать с вектором
MT>> прерываний и стеком аккуратней, по определенным соглашениям.

DB> можно поточнее?

Hу, за TASiS говорить не буду. Это к Корсунину. Hасчет CP/M же - ядро занимает
примерно 11Кб и сидит в третьей странице, включенной по адресу #C000. Вектор
прерываний (а в ATMовской CP/M используется IM 2) указывает примерно в конец
адресного пространства CPU (точнее не помню, если припрет посмотрю. В даное
время не важно). Обработчик тоже сидит в конце. Стек тоже там. Экраны в
страницах 5 и 1. Причем в неиспользуемых экраном байтах страниц (по 384 байта
в каждой) располагаются системные переменные и временный стек, переносимый
туда при операциях с диспетчером системой при вызове ее рестартов.

Поэтому главное не запороть ядро в странице 3 и системные переменные. А при
обращении к рестартам системы (думаю, что за всю игру это надо будет только
при работе с отгрузкой состояний и при выходе в систему), вертать вектор
прерываний и стек временно назад.

Если действительно решишься делать что-либо масштабное под ATM, подробно
разъясню все особенности конфигурации диспетчера памяти в CP/M и его
изменения. А сейчас пока смысла не вижу - итак уже все пальцы отбил, тебе
ответ печатая... :)

DB> Можешь, он там отдельным исходником. Исходники доступны (могу списать). Я
DB> уже пробовал менять драйвер в одной из старых версий.
DB> Сейчас DNA имеет такую идеологию, что драйвера компилируются в ядро.
DB> Можешь предложить ZET-9 другой вариант. Его мыло zet9_zx()mail.ru.

Я ничего не могу предлжить, пока про систему знаю только ее название и то, что
там есть FAT. Просветил бы народ. Демоверсию с TRD-шкой хоть в народ кинул бы,
скриншотики бы выслал, да хотя бы краткое описание ее структуры, идеологии и
функций, как реализованных, так и планирующихся.

DB> Игры бывают разные. Игра размером 4M должна ставиться на винт. Это

Hу и ставь эту игру на винт под CP/M или iS-DOS. FAT это хорошо, но для игры
конкретно - фиолетово. Был же вопрос: какая разница игре, под FATом или нет
она установлена?

DB> аксиома (для амижников система аксиом другая Ж)). А разговор шёл о выборе
DB> системы, которую следует подерживать при разработке игр.

А я уже в предыдущей мессаге писал, что ОСи этой еще нет. И завершение работ
над ее ядром еще не означает ее автоматического появления. Сколько прекрасных
ОСей на разных платформах не прижились, уступив место под солнцем более
простым. Это я не к тому клоню, что я якобы против DNA, а против утверждений,
что остальные ОСи должны вот так вот взять, да и уступить место новоявленной
(точнее и до этой стадии пока не дошедшей) ОСи. Лучший критерий системы -
проверка на практике. Эти ОСи рповерку прошли и выжили. ЧТо будет с DNA - не
знаю. Пусть появится, а потом посмотрим, вытеснит ли она другие ОСи. Лично я
пка сомневаюсь.

MT>> переносится на пЦ, там склеивается и
MT>> просматривается/редактируется/копируется пофайлово через FAR

DB> Скажи это Амосову, он тебя переубедит насчёт кажущейся лёгкости :)

Я лучше с HALFELFом поговорю. :)

MT>> ЗЫ: А так, конечно, давно пора написать командер (или доработать
MT>> существующие, например, ZX-Navigator или плагины к FAR), чтобы, будучи
MT>> настроенным как надо на нужные разделы, он бы открывал CP/Mные и
MT>> iS-DOSные разделы на подключенном к пЦ как SLAVE спековском винте.
MT>> Обращаюсь к народу: как вам такая идея иесть ли кому взяться? Я в
MT>> программировании под пЦ - ноль.

DB> Если со времён SN и AMD (1997-99) не написали нормальный пцшный коммандер
DB> для TR-DOS и даже не пофиксили указанные (а они обладают общеизвестными
DB> глюками - настолько общеизвестными, что известны даже авторам), то чего
DB> надеяться на коммандеры под другие системы...

Фу, какая древность. Лично я пользуюсь FARом с ZX-плагинами (последними
версиями) от HALFELFа. Работает и с образами TR-DOS, и с iS-DOS. И тебе крайне
рекомендую. А SN использую только когда надо обрезать свободное место в конце
TRD-шника по ALT+P. FAR этого не умеет (или я не знаю как).

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <[email protected]>

Thu Oct 13 2005 07:05, Maxim Timonin wrote to Dima Bystrov:

MT>>> редактор спрайтов...

DB>> не верю (c) Unbeliever! мышка есть? горячие кнопки есть? написанное до
DB>> 1996 года обычно не имеет либо одного, либо другого.

MT> Редактор - здесь:
MT> http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/Sea.zip

Забыл написать: мышки действительно нет. Hо горячие кнопки имеются.

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

10 Oct 05 23:23, Maxim Timonin wrote to Vadik Akimoff:

MT> Уж сколько я об этом народу и намекаю, и прямо говорю. Дык нет, пока
MT> собственноручно не спалят комп, напаивая очередной мотог МГТФа, так
MT> ине задумаются... :(

другой компьютер (имеющийся) не выкинет. Это первый режим, кроме стандартного,
по которому у Пентагона и АТМ будет хоть частичная совместимость - общая
графика в программах, общее распределение памяти, общие алгоритмы.

- A.Coder [Wolf3d2004 InfoGuide7 ACEdit96 ACN42 PT3695 Chip13 HexFill HDDoct6]
[Ansi04 8col12 ZXRar27UnR59 Jpg042 CacVox1 Dbs07 Gluk61R PC21 Alasm50f2 Sts70i]

... ZX Spectrum today

[Vladimir Bogdanovitch (2:5090/108.21)]

In a message of 13 Oct 05 Maxim Timonin wrote to Dima Bystrov:

MT> Фу, какая древность. Лично я пользуюсь FARом с ZX-плагинами (последними
MT> версиями) от HALFELFа. Работает и с образами TR-DOS, и с iS-DOS. И тебе
MT> крайне
MT> рекомендую. А SN использую только когда надо обрезать свободное место в
MT> конце
MT> TRD-шника по ALT+P. FAR этого не умеет (или я не знаю как).

А как в FAR'е создать чистый SCL и TRD? А то я SN для этого использую.

И до сих поp пpоблемы с pаскpытием некотоpых zip аpхивов в FAR'е. Вpоде и
pkzipc.exe есть и pkzip & pkunzip v2.50 лежат где надо, а аpхивы все pавно
pугаются. Работа по ZX-коллекции встала из-за этого.

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

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <[email protected]>

Fri Oct 14 2005 00:03, Vladimir Bogdanovitch wrote to Maxim Timonin:

VB> А как в FAR'е создать чистый SCL и TRD? А то я SN для этого использую.

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

VB> И до сих поp пpоблемы с pаскpытием некотоpых zip аpхивов в FAR'е. Вpоде
VB> и pkzipc.exe есть и pkzip & pkunzip v2.50 лежат где надо, а аpхивы все
VB> pавно pугаются. Работа по ZX-коллекции встала из-за этого.

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

Maksagor, NedoPC group. ATM-turbo 2+