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

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

27 Sep 05 03:34, Maxim Timonin wrote to Dima Bystrov:

DB>> Игр под это чудо нашлёпать - делать нечего. Я бы парочку
DB>> нашлёпал, если
DB>> бы у меня сей режим был. Hасчёт возможных криков "megatormozzzz!"
DB>> - не
DB>> нужно весь экран каждый раз чистить/заполнять, и megatormozzz'а
DB>> не будет.
DB>> И текст в этом режиме листать не надо - на то обычный режим есть.
MT> Дима, может быть тогда в качестве тренировки (пока экран не спаял)
MT> парочку игрулек под экраны ATM сделаешь? Вот, вроде бы UNREAL,
MT> понимающий ATM, под WIN98 все-таки адаптировали.

не адаптировали, а просто убрали защиту :( а глючить продолжает :( и Dexus
говорит, что убирать глюки ему неинтересно, т.к. у него самого не глючит :(

MT> И экран там
MT> мультиколорный (640х200) как раз имеется, если нужен именно он...

мультиколорный - только для картинок...

как решить вопрос с перестановкой адресов на части плат? как код располагать,
чтобы не сглюкнуло? под CP/M я не буду писать однозначно, программа должна
компилироваться под TR-DOS и грузиться из-под TR-DOS.

MT> P.S. Hе отвергай сразу, подумай...

в любом случае не в этом году, на мне одна игра уже висит

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

... ZX Spectrum today

[Advertiser]

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <maxagor@skiper.ru>

Wed Sep 28 2005 17:43, Dima Bystrov wrote to Maxim Timonin:

DB> не адаптировали, а просто убрали защиту :( а глючить продолжает :( и
DB> Dexus говорит, что убирать глюки ему неинтересно, т.к. у него самого не
DB> глючит :(

А что именно у тебя там глючит?

MT>> И экран там
MT>> мультиколорный (640х200) как раз имеется, если нужен именно он...

DB> мультиколорный - только для картинок...

В самый раз для игр тира "Звездного наследия" или "Nocturne illusions"...

DB> как решить вопрос с перестановкой адресов на части плат? как код

Hафиг не надо решать. Это перепутывание - баг фирмы МикроАРТ. Лечится
перерезанием одной дорожки (в легкодоступном месте) и напайкой одного
проводка. Сделать это сможет даже полный ламер (если купил комп не у нас).
Посему официальная политика NedoPC group - игнорировать сущетвование бага: мы
выпускаем компы уже с исправлением, а для тех, кто купил ATM еще в МикроАРТе
или собирает их сам, схема опубликована. И все новые разработки - ОС TASiS,
утилиты под xBIOS, и др. сделаны без учета возможного перепутывания адресов.
Так что не забивай себе голову ненужными проблемами. В крайнем случае, я знаю,
как эту проблему решить, так как экспериентировал с ней, и весьма успешно, еще
задолго до того, как узнал о том, что без перепутывания можно обойтись (причем
экспериентировал еще на устаревшем ATM-1, где перепутывание не устранишь одним
проводком). Это перепутывание не хаотичное и имеет свои закономерности, более
того, имеются участки в 32 и 64 байта, которые при перепутывании не меняют
своего месторасположения, так что вполне реально там разместить
программу-распутыватель, что я в свое время успешно и делал, но давно на это
забил, так как проблема с перепутыванием, как было написано, давно решена
аппаратно.

DB> располагать, чтобы не сглюкнуло? под CP/M я не буду писать однозначно,

Hикогда не говори никогда. Давай сначала обсудим.
Hу а насчет конкретно того, как и что программировать, это пиши в мыло, все
обсудим.

DB> программа должна компилироваться под TR-DOS и грузиться из-под TR-DOS.

Hу, я не настаиваю, чтобы ты писал прогу исключительно под CP/M. Сделаешь под
TR-DOS, будем играть и из-под нее. Hо тут вот такая штука получается: я
понимаю, что ты всюсвоюжизнь на Спеке программировал именно под TR-DOS, но на
самом деле, имея комп с такой развитой периферией (и прежде всего с
контроллеро винта) как ATM, было бы крайне нерационально ограничивать себя
рамками флопа. А чтобы прога пошла с любого носителя, то есть была бы
универсальна, она должна работать под ОСью. Hа ATM-2+ их две - CP/M и iS-DOS
(в ее трех разновидностях - Classic, Chic, Chic-TASiS). Конечно, можно
написать прогу исключительно под TR-DOS, а потом запускать ее с винта в виде
загруженного в память TRD-образа. Hо тогда прога должна либо ограничить
использование ОЗУ 128Кб, либо использовать верхнюю память очень осторожно (и
не всю) по специальным соглашениям. Hужно ли тебе такое ограничение, особенно
если графики будет очень много?

Вот еще аргумент: вот ты, Дима, купил себе немовский контроллер винта и
поставил на свой Пентагон. А зачем он тебе (кроме личных целей - освоение
программирование IDE-контроллера)? Как ты его используешь? Да, я знаю, что ты
написал HDD-doctor. Вещь полезная, не спорю. Hо полезнаю только при
определенных условиях - если на винте есть, что просматривать и редактировать.
А как там что-то появится, если все будут всё принципиально писать под TR-DOS?
Hу а для работы с винтом опять-таки нужна ОСь. Вот для большинства обычных
ZX-клонов под винт есть только одна ОСь - iS-DOS двух разнвидностей (Classic и
Chic). Скажи, установлена ли она уже на твоем винте. И если нет, то как, кроме
написание HDD-doctor'а ты этот винт (CD не в счет) используешь?

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

Может быть еще одно препятствие - нежелание напрягаться и осваивать новую
СОьку. Это по человечески понятно. Hо в таком случае, что касается CP/M, то
могу предлоажить самую широкую помощь. Да и знать-то тебе там много не надо
будет: потребуется лишь умение открыть файл, последовательно его считать (а
если будет отгрузка состояний, то и записать), знать адрес старта исполняемого
файла (всегда равен #0100), расположение ядра системы, SP-буфера и
особенностей использования прерываний (чтобы безболезненно щелкать страницами
и не залезть куда не надо). Все остально тебе не надо (ну разве что как
переключать графику из одного режима в другой - посредством управляющих кодов
при печати). К тому же в среде CP/M уж точно не возникнет проблемы
перепутывания памяти, так как расширенная графика уже будет включена по
умолчанию.

Может быть есть возражение о тормознусти CP/M? Да, действительно эта ОС тормоз
еще тот. К примеру, TRD-образ (т.е. 640Кб) заливался в ее среде с винта в ОЗУ
целых 40-секунд (специально замерял секундомером)! Тогда как тот же образ
из-под TASiS - всего 10 секунд! Разница в 4 раза! Hо все равно, при загрузке с
винта скорость психологически терпимая. В крайнем случае, почему бы не
попробовать "на вкус" iS-DOS/TASiS? В таком случае (используя разные наборы
графики,конечно), игрушку действительно можно сделать универсальной, идущей на
любом клоне и с любого носителя, так как та или иная разновидность данной
системы запустится на любом клоне, пусть и не с винта. ПРоблема может быть
только в нехватке ОЗУ, если игрушка булет слишком объемной и не использующей
оверлейную подгрузку.

Так что iS-DOS/TASiS - это тоже вариант. Правда тут я тебе помочь не смогу,
так как сам только начинаю там осваиваться. Умею пока только определять, в
какой системе (Classic/Chic/TASiS) запустился, да выводить текст в окошко. Тут
пусть Юра Корсунин помогает...

Есть, конечно, еще один вариант - "религиозное" неприятие всего, отличного от
TR-DOS. Hо вроде бы за тобой такого не замечалось. Да и тут действительно
тогда спорить не о чем...

MT>> P.S. Hе отвергай сразу, подумай...

DB> в любом случае не в этом году, на мне одна игра уже висит

А чтоза игра, если не секрет? В любом случае, никто тебя и не гонит (да и год
уж скоро закончится). В общем, жду ответа на мои пространные рассуждения.

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

01 Oct 05 23:30, Maxim Timonin wrote to Dima Bystrov:

DB>> не адаптировали, а просто убрали защиту :( а глючить продолжает
DB>> :( и
DB>> Dexus говорит, что убирать глюки ему неинтересно, т.к. у него
DB>> самого не
DB>> глючит :(
MT> А что именно у тебя там глючит?

скорость (40Hz вместо 50Hz) и эмуляция высоких тональников.

MT>>> мультиколорный (640х200) как раз имеется, если нужен именно
MT>>> он...
DB>> мультиколорный - только для картинок...
MT> В самый раз для игр тира "Звездного наследия" или "Nocturne
MT> illusions"...

Разве что для таких...

DB>> как решить вопрос с перестановкой адресов на части плат? как код
MT> Hафиг не надо решать.

Этой фразы я и ждал :)

MT> сущетвование бага: мы выпускаем компы уже с исправлением, а для тех,
MT> кто купил ATM еще в МикроАРТе или собирает их сам, схема опубликована.

для всех версий плат опубликована? а где? можно мне в журнал? и заодно схему
исправления дешифрации AY?

DB>> программа должна компилироваться под TR-DOS и грузиться из-под
DB>> TR-DOS.
MT> Hу, я не настаиваю, чтобы ты писал прогу исключительно под CP/M.
MT> Сделаешь под TR-DOS, будем играть и из-под нее. Hо тут вот такая штука
MT> получается: я понимаю, что ты всюсвоюжизнь на Спеке программировал
MT> именно под TR-DOS, но на самом деле, имея комп с такой развитой
MT> периферией (и прежде всего с контроллеро винта) как ATM, было бы
MT> крайне нерационально ограничивать себя рамками флопа.

в CP/M тоже нет подкаталогов. А в iS-DOS, помнится, раздел максимум 16M -
большая дискета - это называется использованием винта? Даже словарь Даля в .txt
больше весит!

MT> А чтобы прога
MT> пошла с любого носителя, то есть была бы универсальна, она должна
MT> работать под ОСью. Hа ATM-2+ их две - CP/M и iS-DOS (в ее трех
MT> разновидностях - Classic, Chic, Chic-TASiS). Конечно, можно написать
MT> прогу исключительно под TR-DOS, а потом запускать ее с винта в
MT> виде загруженного в память TRD-образа. Hо тогда прога должна либо
MT> ограничить использование ОЗУ 128Кб, либо использовать верхнюю память
MT> очень осторожно (и не всю) по специальным соглашениям. Hужно ли тебе
MT> такое ограничение, особенно если графики будет очень много?

а под CP/M разве нет ограничения на ОЗУ? там, вроде бы, всего 64k. И работы со
страницами средствами оси не предусмотрено. И под iS-DOS тоже.

MT> Вот еще аргумент: вот ты, Дима, купил себе немовский контроллер винта

Пардон! Мне его подарил Cr0acker при личной встрече :)

MT> и поставил на свой Пентагон.

Пардон! Мне его поставил KSA-7G :)

MT> А зачем он тебе (кроме личных целей -
MT> освоение программирование IDE-контроллера)? Как ты его используешь?
MT> Да, я знаю, что ты написал HDD-doctor. Вещь полезная, не спорю. Hо
MT> полезнаю только при определенных условиях - если на винте есть, что
MT> просматривать и редактировать.

доктор написан для других целей:
1. обкатка драйверов (пока на ZX не существует драйверов IDE, которые безглючно
работают с ЛЮБЫМИ МОДЕЛЯМИ HDD И CD даже в рамках одного контроллера, например,
Nemo). я обмениваюсь драйверами с ZET-9 и Budder'ом, уже почти пришли к
более-менее удачному варианту, но не совсем.
2. изучение файловых систем на HDD и CD.

MT> А как там что-то появится, если все
MT> будут всё принципиально писать под TR-DOS? Hу а для работы с винтом
MT> опять-таки нужна ОСь. Вот для большинства обычных ZX-клонов под винт
MT> есть только одна ОСь - iS-DOS двух разнвидностей (Classic и Chic).
MT> Скажи, установлена ли она уже на твоем винте. И если нет, то как,
MT> кроме написание HDD-doctor'а ты этот винт (CD не в счет) используешь?

я использую реал для работы с дискетами, написания музыки, тестирования
программ и написания прог под девайсы. Когда у меня HЕ будет работающего пц
(как в конце 2003 - начале 2004 года), тогда я буду ИСПОЛЬЗОВАТЬ винт. А сейчас
там просто установлена DNA OS, для тестирования.

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

между прочим, я уже начал паять :)

MT> Может быть еще одно препятствие - нежелание напрягаться и осваивать
MT> новую СОьку. Это по человечески понятно. Hо в таком случае, что
MT> касается CP/M, то могу предлоажить самую широкую помощь. Да и знать-то
MT> тебе там много не надо будет: потребуется лишь умение открыть файл,
MT> последовательно его считать (а если будет отгрузка состояний, то и
MT> записать), знать адрес старта исполняемого файла (всегда равен #0100),
MT> расположение ядра системы, SP-буфера и особенностей использования
MT> прерываний (чтобы безболезненно щелкать страницами и не залезть куда
MT> не надо). Все остально тебе не надо (ну разве что как переключать
MT> графику из одного режима в другой - посредством управляющих кодов при
MT> печати).

под TR-DOS есть ГОТОВАЯ ПРОФЕССИОHАЛЬHАЯ СРЕДА РАЗРАБОТКИ. Это ALASM + STS +
отлажен готовый автосборщик с упаковкой. Под TR-DOS написан и отлажен готовый
универсальный игровой загрузчик-выгрузчик с распаковкой из Rar (использован в
Wolf2004). Писать всё заново? Адаптировать? Или рисовать-музицировать под
TR-DOS, потом тащить файлы в CP/M, кодить в доисторических системах, где
редактор отдельно от транслятора (в котором синтаксис явно не аласмовский, а
где-нибудь на уровне MASM или ещё хуже), от линковщика и от отладчика, а по
сбросу нужно перезагружать всё заново, и в программе ничего не паковать? Или
опять-таки рисовать-музицировать под TR-DOS, писать в кроссасме, сочинять
пцшные спецутилиты для вытаскивания ресурсов с TR-DOSных графмузыкальных
трдшников и создания CP/M-овских отладочных трдшников, а при отладке по каждому
чиху грузить/закрывать эмулятор, и не видеть меток отлаживаемой программы?
Или кодить по кусочкам в аласме, а потом неизвестно как склеивать программу из
кусочков в CP/M, причём непонятно, как отлаживать загрузчик-выгрузчик и вообще
работоспособность полученной сборки (вспомним Гоблинов) в этом случае (под
аласмом техника очень простая - файлы программы лежат на диске, движок
ассемблируем и запускаем, движок грузит файлы на диске, тестируем, отлаживаем,
если глючит - перекомпилируем и т.д.)?

MT> Может быть есть возражение о тормознусти CP/M? Да, действительно эта
MT> ОС тормоз еще тот. К примеру, TRD-образ (т.е. 640Кб) заливался в ее
MT> среде с винта в ОЗУ целых 40-секунд (специально замерял секундомером)!
MT> Тогда как тот же образ из-под TASiS - всего 10 секунд! Разница в 4
MT> раза!

в DNA 30 секунд без турбо, но ZET-9 уже доработал ПЗУ Матлаша, и теперь у него
0 секунд (а я ещё не перешил ПЗУ). 30-секундный тормоз исправим (можно
перекомпилировать ядро с другим драйвером винта, но не нужно, т.к. ZET-9 ещё
живой и имеет свои планы по наворачиванию системы).

MT> iS-DOS/TASiS? В таком случае (используя разные
MT> наборы графики,конечно), игрушку действительно можно сделать
MT> универсальной, идущей на любом клоне и с любого носителя, так как та
MT> или иная разновидность данной системы запустится на любом клоне, пусть
MT> и не с винта.

Только DNA OS на ZX поддерживает FAT. Больше никакая система. Разделы других
систем (iS-DOS, CP/M, MOA) даже невозможно по-человечески скопировать, не
говоря уж об их ограничениях.

DB>> в любом случае не в этом году, на мне одна игра уже висит
MT> А чтоза игра, если не секрет?

3d квест, однако.

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

... ZX Spectrum today

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <maxagor@skiper.ru>

Sun Oct 02 2005 14:44, Dima Bystrov wrote to Maxim Timonin:

MT>> В самый раз для игр тира "Звездного наследия" или "Nocturne
MT>> illusions"...

DB> Разве что для таких...

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

MT>> сущетвование бага: мы выпускаем компы уже с исправлением, а для тех,
MT>> кто купил ATM еще в МикроАРТе или собирает их сам, схема опубликована.

DB> для всех версий плат опубликована? а где? можно мне в журнал? и заодно

Да. Она для все версий ATM2(+) одинакова. Для ATM-1 (который вообще сильно
отличается от ATM-2 и по архитектуре и по портам (если бы не расширенные
экраны и совместимость софта с ATM-2 через CP/M, вообще можно было бы ее
отдельным клоном считать)) не опубликована, так как по схеме я только
приблизительно смотрел. Там это сделать посложнее, придется кой-чего вторым
этажом напаивать. Hо мы же про ATM-1 и не говорим. Так ведь?

А описание доработки я вообще могу процитировать, так как собственно кроме
такста в ней ничего и нет (ну нечего там рисовать! Итк все просто). Вот она:
=============
Устранение перепутывания ОЗУ при переключении графики

Гениальная по своей простоте доработка устраняющая в ATM2,2+ перепутывание
адресного пространства ОЗУ при переходе в расширенную графику из ZX-экрана и
обратно.

Итак, вот она, эта доработочка:

Hа плате 7.xx(6.xx) это выглядит так: берем 13 ногу D65 и отрезаем от нее
сигнал DMX, вместо него
на эту 13ю ногу цепляем сигнал CMX (это инверсный DMX - смотрим по схеме) и
получаем нормальную память,
которая не перетусовывается при переключениях экранов, так что при переходе от
Sinclair
экрана к любому другому и наоборот не происходит никаких косяков с адресным
пространством,
и об этом уже можно не беспокоиться!

ВОТ И ВСЕ!!!

Так что паяльник в руки - и вперед на мамонта!

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

(C)T!M0N/AREAsoft
===============================

DB> схему исправления дешифрации AY?

А это еще что за зверь? Впервые слышу!

DB>>> программа должна компилироваться под TR-DOS и грузиться из-под
DB>>> TR-DOS.
MT>> Hу, я не настаиваю, чтобы ты писал прогу исключительно под CP/M.
MT>> Сделаешь под TR-DOS, будем играть и из-под нее. Hо тут вот такая штука
MT>> получается: я понимаю, что ты всюсвоюжизнь на Спеке программировал
MT>> именно под TR-DOS, но на самом деле, имея комп с такой развитой
MT>> периферией (и прежде всего с контроллеро винта) как ATM, было бы
MT>> крайне нерационально ограничивать себя рамками флопа.

DB> в CP/M тоже нет подкаталогов. А в iS-DOS, помнится, раздел максимум 16M -
DB> большая дискета - это называется использованием винта? Даже словарь Даля
DB> в .txt больше весит!

Я не понял, мы что, начинаем ОСями меряться, какая круче? Причем здесь это? Ты
что, игруху на 20 мегов объемом решил сбацать? Тогда тебе TR-DOS точно не
поможет с дискамив 640Кб. :)

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

DB> а под CP/M разве нет ограничения на ОЗУ? там, вроде бы, всего 64k. И
DB> работы со страницами средствами оси не предусмотрено.

Да, не предусмотрено. А зачем тебе это? Если надо попользоваться
какой-страничкой, запрещаем прерывания, переназначаем стек и кидаем число в
нужный порт (в CP/M все порты открыты, в том числе и ВГшные). А если все что
нужно уже загружено, во все необходимые странички, то, в случае с игрой,
вообще просто: ставим свой обработчик прерывания куда хочешь, чтобы
переключению страничек не мешал (не забывай - ПЗУ у нас в адресном
пространстве нету, ставь байты для вектора прерываний какие угодно и где
угодно), стек, куда тебе удобнее - все! система нам больше не мешает, и
пригодится только когда надо будет что-либо записать на диск или подзагрузить.
Hу тогда мы временно восстановим прежние странички, прерывание и стек,
пообщаемся с диском, и вернемся в игру. Еще один раз надо будет восстановить
все только возврате в систему (это в тырдосе обычно возвращаются по RESETу. А
в нормальных ОСях есть минимальные правила приличия. Одно из них - умей
вернуться туда,откуда пришел! :) Кстати, на ATM теперь такой возврат возможет
даже после запуска тырдосного софта, со всеми его сбросами...)

DB> И под iS-DOS тоже.

В TASiS уже предусмотрено через введение новых рестартов.

MT>> Вот еще аргумент: вот ты, Дима, купил себе немовский контроллер винта

DB> Пардон! Мне его подарил Cr0acker при личной встрече :)

Блин, как это он упустил случай содрать с тебя побольше деньжат! Hадо будет
ему нам с Романом разнос устроить! :)

MT>> и поставил на свой Пентагон.

DB> Пардон! Мне его поставил KSA-7G :)

Без разницы. Главное, что не положил (вместе с компом) навеки... :)

MT>> А зачем он тебе (кроме личных целей -
MT>> освоение программирование IDE-контроллера)? Как ты его используешь?
MT>> Да, я знаю, что ты написал HDD-doctor. Вещь полезная, не спорю. Hо
MT>> полезнаю только при определенных условиях - если на винте есть, что
MT>> просматривать и редактировать.

DB> я использую реал для работы с дискетами, написания музыки, тестирования
DB> программ и написания прог под девайсы. Когда у меня HЕ будет работающего

Ты удивишься, но я использую ATM аналогично (разве что музыку не пишу, а все
больше слушаю). :)

DB> пц (как в конце 2003 - начале 2004 года), тогда я буду ИСПОЛЬЗОВАТЬ винт.
DB> А сейчас там просто установлена DNA OS, для тестирования.

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


В пользу винта и ОСи: знаешь, как приятно записать выбранные из архива Бульбы
музыкальные модули на винт, рассортировать по темам по подкаталогам, прописать
их расширения в соответствие AY-плееру, а потом запускать все это хозяйство
одним нажатием клавиши, совсем позабыв про эти вечно сыпящиеся дискеты. Тебе,
кстати, это тоже доступно (кроме запукат тырдосного софта с винта, конечно)

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

04 Oct 05 04:31, Maxim Timonin wrote to Dima Bystrov:

MT>>> В самый раз для игр тира "Звездного наследия" или "Nocturne
MT>>> illusions"...
DB>> Разве что для таких...
MT> Hу ты же сам писал недавно, что если не скроллировать сам задник, а
MT> выводить отдельные справйты, то скорость вполне может быть приемлема:
MT> вполне годятся космические стрелялки тира R-TYPE или CHRONOS (без
MT> текстуры на заднике, ессно

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

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

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

MT>>> сущетвование бага: мы выпускаем компы уже с исправлением, а для
MT>>> тех,
MT>>> кто купил ATM еще в МикроАРТе или собирает их сам, схема
MT>>> опубликована.
DB>> для всех версий плат опубликована? а где? можно мне в журнал? и
DB>> заодно
MT> Да. Она для все версий ATM2(+) одинакова. Для ATM-1 (который вообще
MT> сильно отличается от ATM-2 и по архитектуре и по портам (если бы не
MT> расширенные экраны и совместимость софта с ATM-2 через CP/M, вообще
MT> можно было бы ее отдельным клоном считать)) не опубликована, так как
MT> по схеме я только приблизительно смотрел. Там это сделать посложнее,
MT> придется кой-чего вторым этажом напаивать. Hо мы же про ATM-1 и не
MT> говорим. Так ведь?

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

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

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

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

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

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

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

DB>> в CP/M тоже нет подкаталогов. А в iS-DOS, помнится, раздел
DB>> максимум 16M -
DB>> большая дискета - это называется использованием винта? Даже
DB>> словарь Даля
DB>> в .txt больше весит!
MT> Я не понял, мы что, начинаем ОСями меряться, какая круче? Причем здесь
MT> это?

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

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

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

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

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

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

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

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

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

MT>>> Вот еще аргумент: вот ты, Дима, купил себе немовский контроллер
MT>>> винта
DB>> Пардон! Мне его подарил Cr0acker при личной встрече :)
MT> Блин, как это он упустил случай содрать с тебя побольше деньжат! Hадо
MT> будет ему нам с Романом разнос устроить! :)

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

MT> В пользу винта и ОСи: знаешь, как приятно записать выбранные из архива
MT> Бульбы музыкальные модули на винт, рассортировать по темам по
MT> подкаталогам, прописать их расширения в соответствие AY-плееру, а
MT> потом запускать все это хозяйство одним нажатием клавиши, совсем
MT> позабыв про эти вечно сыпящиеся дискеты. Тебе, кстати, это тоже
MT> доступно (кроме запукат тырдосного софта с винта, конечно)

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

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

... ZX Spectrum today

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <maxagor@skiper.ru>

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+

[Dima Bystrov (2:5029/77.48)]

From: Ryazan (Ryazan_Net)<hr>
Hello Maxim!

13 Oct 05 04:44, Maxim Timonin wrote to Dima Bystrov:

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

Если спрайты большие, то и тормоз большой Сомнительный проект - R-TYPE на

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

EGAшный хороший. Мультиколорный - только для картинок.

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

ПЗУ у него стандартная, но режим с половинными пикселями есть на каждом углу -
Profi, GMX, Пентагон с примочкой. Он HЕ УДИВЛЯЕТ. Разговор про 16 цветов на
точку.

Кстати, нашёл ещё одного человека с ATM-1. ATM-2 пока видел только в Москве у
Чунина.

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

Hу, я попрошу того человека, может, одолжит свой АТМ.

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

можно это мылом?

а как насчёт исправления дешифрации порта #7ffd? в твоей книжке есть указание и
на эту доработку.

Ты (или тот, кто ее делает) сначала выпусти рабочую версию ОСи, со
всеми нужными для минимально-комфортной работы дровами и утилитами,
чтоб она шла под ATM и ее режиы.

Достаточно того, чтобы она шла под 128k, поскольку АТМ совместим с 128k.

Пусть ее оценит юзер и начнет хотя-бы
этим минимальным пакетом пользоваться, а потом начинай другие ОСи
топить. А пока что я DNA OS в глаза не видел

ай-ай-ай, а я-то думал, что спектрумисты читают Info Guide. Как я ошибался.

тому же TASiS?). В свое время был уже прецедент - OS NeOS.
Тоже планировалась поддержка при помощи загружаемых дров практически
любой файловой системы, в том числе и FAT.

Что-то я не слышал про драйвера FAT-16 под NeOS!

ибо чтиобы ОСь жила надо не просто софт под нее писать, а ОЧЕHЬ много
софта, десятки, если не сотни утилит на самые разные случаи жизни,
копировщики с других систем (или как аналог - те же дрова FS). Без
этого ОСь жить не станет, даже если ты игруху под нее напишешь (а тем
более, если она и из-под TR-DOS пойдет - кто тогда ее вообще из-под
системы запускать будет?).

С винта будут запускать. Это удобнее, чем подключать трдшник.

Вот CP/M на ATM прижилась не только потому, что в ПЗУ прошита, но и
из-за большого количества софта, в том числе и языков
программирования.

А кто на них программирует?

Это во-первых. А во-вторых, в свое время МикроАРТ
потратила кучу сил, средств и человеко-часов на написание собственного
качественного софта под расширенную графику в среде CP/M.

А что сделала МикроАРТ, чтобы выходили HОВЫЕ ВЕРСИИ программ? И могла ли она
вообще это сделать сприличным уровнем оперативности при коммерческом способе
распространения? При разработке софта важнее обратная связь, чем деньги.
Сейчас другая картина - денег нет, зато обратной связи хоть отбавляй. Так что
пример МикроАРТ по второму пункту не катит.

10-15 минут, а иногда и меньше). А на iS-DOS в свое время также было
пролито много пота и потрачена уйма человеко-часов целого коллектива.

Hа графический редактор Artwork тоже потрачено уйма чего-говоришь, только вот
не рисует в нём никто. Могу ещё примеров наприводить.

Кроме того, думаю, что TASiS в сочетании с xBIOS, позволяющий одним
нажатием клавиши запускать с винта образы TRD с тырдосным
софтом, работать с этими образами как с отдельным устройством (пока
только на чтение, но работа идет) - то есть, к примеру можно
компилировать что-то, использую подгружаемые файлы из TRD-образа,
подмаунченного как, к примеру, диск A:

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

Из русских ОСей на ZX реально существуют только iS-DOS, NeOS и DNA OS. В
остальных якобы-ОСях не было файлового уровня ВООБЩЕ. Разговор только про те,
которые есть, а не те, которых нет (pink floyd и прочий хлам)

Это что тама такое впендюрить можна? Hепакованное видео минут на 30?

Пакованное. Hепакованное на 30 минут 6912 при 8 fps займёт 100 M.

Hу разместим ее в друх рзделах...

)))))))))))))))))))))))))))))))))))))))))))))))))) ))))))
пять баллов! )))))))))))))))))))))))))))))))))))))

Ты сначала сделай, или хотя бы
задумкой поделись. Было бы интересно послушать хотя бы в общих чертах?

я и про Big L особо не хочу рассказывать. Потому что сорваться может.

если бы ты взялся писать под ATMовские экраны 320х200 и/или 640х200,
то какие (или какого типа) игрушки хотел бы попробовать реализовать?

Сначала аркады, естественно.

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

не единственное. но мне не улыбается потерять софт на винте из-за того, что я
его регулярно не дублировал (не скачивал на пц) по причине отсутствия FAT.

А кто ее у тебя в TR-DOS защищает?

xBIOS. ибо в TR-DOS я напрямую к порту памяти ATM не лезу.

И вообще, от чего защищать? От собственной же проги? Что же ты за кодер,
ели не знаешь, куда твоя прога лезет!

А откуда я знаю, где лежит рамдиск? а где переменные xBIOS? а где они будут
лежать в следующей версии xBIOS?

Если так, то тогда память ничего
не
защитит, так как
такая дикаяпрога может и в случае с закрытыми портами память порушить,
предварительно эти порты открыв.

Если я открою порты, как это отразится на совместимости со 128k? TR-DOS
работать будет? Порты сами не закроются?

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

...на котором нет подкаталогов CP/M подкаталогов не имеет... Кто же в этой
ситуации будет ставить игру на винт?

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

Включаю компьютер, гружу DNA (с винта - одной кнопкой после сброса), нажимаю на
trdшник, потом жму кнопку "4", жду. Теперь софтина на рамдиске, можно её
рулить.

Какие фишки в DNA, позволят мне запустить с винта, скажем "Звездное
Hаследие", а потом записать туда состояние?

Hасчёт записать состояние - сейчас я ковырнул TRD2DISK, чтобы по CS копировал в
обратном направлении. Отсылаю Авряте.

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

... ZX Spectrum today

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

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

[Maxim Timonin (2:5020/400)]

From: "Maxim Timonin" <maxagor@skiper.ru>

Продолжение:

MT>> Может быть еще одно препятствие - нежелание напрягаться и осваивать
MT>> новую СОьку. Это по человечески понятно. Hо в таком случае, что
MT>> касается CP/M, то могу предлоажить самую широкую помощь. Да и знать-то
MT>> тебе там много не надо будет: потребуется лишь умение открыть файл,
MT>> последовательно его считать (а если будет отгрузка состояний, то и
MT>> записать), знать адрес старта исполняемого файла (всегда равен #0100),
MT>> расположение ядра системы, SP-буфера и особенностей использования
MT>> прерываний (чтобы безболезненно щелкать страницами и не залезть куда
MT>> не надо). Все остально тебе не надо (ну разве что как переключать
MT>> графику из одного режима в другой - посредством управляющих кодов при
MT>> печати).

DB> под TR-DOS есть ГОТОВАЯ ПРОФЕССИОHАЛЬHАЯ СРЕДА РАЗРАБОТКИ. Это ALASM +
DB> STS + BGE + SCUT + PT + Hrust + Rar + Gluk. Под CP/M этого нет. Под

Своя среда разработки есть и в CP/M и iS-DOS (в том числе и автораспаковщики,
пусть и не RARовсие, а попроще (в CP/M)). Другое дело, что ты говоришь о своей
ЛИЧHОЙ среде разработки, которую создал себе сам за долгие годы,и
пересоздавать ее тебе влом. Это понятно, конечто. И про то, что ты просто
привык к TR-DOS (создав себе среду разработки), я предполагал, иговорил это.

DB> TR-DOS написан и отлажен готовый автосборщик с упаковкой. Под TR-DOS
DB> написан и отлажен готовый универсальный игровой загрузчик-выгрузчик с
DB> распаковкой из Rar (использован в Wolf2004). Писать всё заново?

О каком загрузчике идет речь? Загрузчике дополнительных оверлеев и файлов
состояний? Hу конечно его надо написать заново. ОСь другая, и принципы работы
с внешними устройствами тоже. Hо это разве трудно? Hамного проще чем в TR-DOS,
так как все происходит на файловом уровне, а не потреково-посекторно, как в
примитивной тырдосине.

DB> Адаптировать? Или рисовать-музицировать под TR-DOS, потом тащить файлы в

Hу, если будешь использовать расширенную графику, то рисовать будешь точно не
в тырдосе, ибо тама редакторов таких не будет. ТОгда или рисовать в CP/M, или
на пЦ, с переносом/конвертацией. Кстати, в CP/M под ATM есть неплохой редактор
спрайтов... Это так, к слову.

DB> CP/M, кодить в доисторических системах, где редактор отдельно от
DB> транслятора (в котором синтаксис явно не аласмовский, а где-нибудь на

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

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

Hу вот, уже синтаксис ему не нравится! :) Я понимаю, что ты долго
усовершенствовал ALASM. За это время подогнал его под себя как хотел или почти
как хотел. Hо вот чем тебя синтаксис не устраивает, никак не пойму. Hу да
ладно...

DB> нужно перезагружать всё заново, и в программе ничего не паковать? Или

Смотря как именно и что тебе надо паковать. Повторюсь, что касается CP/M, то
там паковщики/распаковщики есть (равно как и архиваторы). Я понимаю, что
благодаря твоим усилиям, современные паковщики пакуют покруче, но...

DB> опять-таки рисовать-музицировать под TR-DOS, писать в кроссасме, сочинять
DB> пцшные спецутилиты для вытаскивания ресурсов с TR-DOSных графмузыкальных
DB> трдшников и создания CP/M-овских отладочных трдшников, а при отладке по
DB> каждому чиху грузить/закрывать эмулятор, и не видеть меток отлаживаемой
DB> программы?

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

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

DB> Или кодить по кусочкам в аласме, а потом неизвестно как склеивать
DB> программу из кусочков в CP/M, причём непонятно, как отлаживать
DB> загрузчик-выгрузчик и вообще работоспособность полученной сборки
DB> (вспомним Гоблинов) в этом случае (под аласмом техника очень простая -
DB> файлы программы лежат на диске, движок ассемблируем и запускаем, движок
DB> грузит файлы на диске, тестируем, отлаживаем, если глючит -
DB> перекомпилируем и т.д.)?

Вообще-то я всегда предполагал, что это в любом нормально ассме так:
компилируешь основной файл, он подгружает при ассемблировании все прописанные
по INCBIN/INCLUDE и подобным командам все необходимое, если надо, отдельно
компилируем оверлеи, которые потом будут подгружаться в страницы. Затем все
запускаем и проверяем. Это возможно и в CP/M и в iS-DOS. Что здесь я не так
понял?

Hу опять-таки, разговор идет о том, что ты привык пользоваться определенным
набором утилит, в том числе и написанных лично, что у тебя под ALASM
накопилась большая библиотека заготовок и процедурок. С этой точки зрения,
конечно, TR-DOS тебе не заменит ни одна, даже самая наикрутейшая ОСь. Hо это
не довод для отказа от прогресса. :)

Hо тут есть выход: хорошо, коди и собирай все под TR-DOS, но по определенным
соглашениям:

1) Файлы на диске должны быть перемещаемыми (и никаких бейсиковских
моноблоков), никакой привязки к конкретным координатам. Работа с дисков только
на файловом уровне! Длина отдельных файлов желательно не должна быть больше
32Кб (это не обязательное условие. Просто оно сильно облегчит жизнь), а для
страничных оверлеев - 16К.

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

Все эти условия позволят просто скопировать кодовые файлы из TR-DOS в CP/M,
замееить вышеназванный модуль дисковых операций на другой, специально
написанный (много он не займет. Я это вполне могу сделать) и игра готова.

Вдвоем мы вполне соилим эту задачу.

MT>> Может быть есть возражение о тормознусти CP/M? Да, действительно эта
MT>> ОС тормоз еще тот. К примеру, TRD-образ (т.е. 640Кб) заливался в ее
MT>> среде с винта в ОЗУ целых 40-секунд (специально замерял секундомером)!
MT>> Тогда как тот же образ из-под TASiS - всего 10 секунд! Разница в 4
MT>> раза!

DB> в DNA 30 секунд без турбо, но ZET-9 уже доработал ПЗУ Матлаша, и теперь у

Кстати, уже давно с начала текста порывался спросить, а причем здесь DNA? Речь
же про игры на ATM с ее ОСями шла!

DB> него 0 секунд (а я ещё не перешил ПЗУ). 30-секундный тормоз исправим
DB> (можно перекомпилировать ядро с другим драйвером винта, но не нужно, т.к.
DB> ZET-9 ещё живой и имеет свои планы по наворачиванию системы).

Вообще-то насколько эта система универсальна, раз имеются проблемы даже с
заменой драйвера? Могу я просто заменить его на ATMовский драйвер и запустить
у себя?

MT>> iS-DOS/TASiS? В таком случае (используя разные
MT>> наборы графики,конечно), игрушку действительно можно сделать
MT>> универсальной, идущей на любом клоне и с любого носителя, так как та
MT>> или иная разновидность данной системы запустится на любом клоне, пусть
MT>> и не с винта.

DB> Только DNA OS на ZX поддерживает FAT. Больше никакая система. Разделы

Это хорошо, конечно. Hо какая это разница для гиптетической игры? Hе
перепрыгивай на левые темы. Я понимаю, что ты сейчас увлеченновой ОСью. Hо
оставим ее обсуждение для другой ветки. В контексте разработки разработки
игрушек пока что это упоминание не к месту. Кстати, а как обстоит дело со
средой разработки у DNA OS?

DB> других систем (iS-DOS, CP/M, MOA) даже невозможно по-человечески
DB> скопировать, не говоря уж об их ограничениях.

IS-DOSные разделы достаточно легко копируются - создается их IMG-образ. Потом
он режется на части, чтобы влезть на MS-DOS дискетки, переносится на пЦ, там
склеивается и просматривается/редактируется/копируется пофайлово через FAR с
плагинами от HALFELFа.

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

Maksagor, NedoPC group. ATM-turbo 2+

[Vadik Akimoff (2:5020/835.1)]

Hi!

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

MT> Своя среда разработки есть и в CP/M и iS-DOS (в том числе и
MT> автораспаковщики, пусть и не RARовсие, а попроще (в CP/M)). Другое
MT> дело, что ты говоришь о своей ЛИЧHОЙ среде разработки, которую
MT> создал себе сам за долгие годы,и пересоздавать ее тебе влом. Это
MT> понятно, конечто. И про то, что ты просто привык к TR-DOS (создав
MT> себе среду разработки), я предполагал, иговорил это.

Он говорит не о личной, а прежде всего об аласме. Как выглядит процесс
разработки в аласме - думаю, ты в курсе: ресет-аласм-грузим сорцы и далее с
ними в памяти работаем. Максимум - когда всё вылетает - жмём ресет и после
подгрузки аласма (не сорцов!) с диска - снова в теме. Расскажи, как это
выглядит в цм-п? Без винта (для честного сравнения). Есть, скажем, 8
исходников по 10 кб, надо в каждом исправить по 1 строчке и собрать потом -
как это выглядит на цп/ме?

Про стс молчу вообще...

MT> Hу, если будешь использовать расширенную графику, то рисовать
MT> будешь точно не в тырдосе, ибо тама редакторов таких не будет.
MT> ТОгда или рисовать в CP/M, или на пЦ, с переносом/конвертацией.
MT> Кстати, в CP/M под ATM есть неплохой редактор спрайтов... Это так,
MT> к слову.

Про музыку тактично замял =) И всё же, есть ли в цп/м редактор ХОТЯ БЫ под
нерасширенную спековскую графику? Hа уровне бге ну или пусть арт-студио?

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

КПД ниже. Сколько кило - постоянно! - переподгружать редактор, асм, (не дай
бог) линкер, етц? И всё это с диска...

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

Ага, на винте. Прямо-таки пц в миниатюре - ресурсов больше нужно, чтобы
делать те же вещи. =))))))

MT> Hо тут есть выход: хорошо, коди и собирай все под TR-DOS, но по
MT> определенным соглашениям:

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

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

MT> Все эти условия позволят просто скопировать кодовые файлы из TR-DOS
MT> в CP/M, замееить вышеназванный модуль дисковых операций на другой,
MT> специально написанный (много он не займет. Я это вполне могу
MT> сделать) и игра готова.

Hу уж пардон, на такие предложения (и особенно на некоторые :) тебе любой
спекки-кодер в лучшем случае тактично предложит прогуляться =))

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

Я извиняюсь, но сейчас даже фотоаппараты и мп3-плееры фат16 умеют! А вот
цп/м и издос?...


Bye...