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

[Ivan Kuvshinov (2:5020/830.10110)]

IM>> Помню, наpод тогда еще не веpил возможность Z80 на 14MHz :)
DB> Дык, на коленке компьютер до 14MHz не разгонишь :)

А у меня вопрос по поводу разгона, если двигать отдельно уровни, ну то есть так:

...|||...|||... ->...||...||... или вот в это ..|||..|||..

Это что-нибудь может дать, в том плане, что бы побольше частоту задрать, пусть и так половинчато?

КИА

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 20 Sep 05 Dima Bystrov wrote to me:


DB> получаем: 10 спрайтов 16x16 или 5 спрайтов 16x32 < 85000 тактов.

Ага. в кадре остаётся примерно 45000 (70000-25000), 2 кадра выводить только
несколько микроспрайтов =))


DB> фреймовость нам особо не нужна, мультиколорами и не пахнет, так что на
DB> тормознутость при выборке строчки можно не обращать внимания...

Фреймовость не нужна, зато нужна несекучесть с лучом (второго-то нету
экрана)! А иначе моргать будет по-ламерски =)


Bye...

[Maxim Timonin (2:5020/400)]

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

Sun Sep 25 2005 20:57, Vadik Akimoff wrote to Dima Bystrov:


VA> Фреймовость не нужна, зато нужна несекучесть с лучом (второго-то нету
VA> экрана)! А иначе моргать будет по-ламерски =)

Если говорить не про конкретно предложенный Димой экран, а про 16 независимых
цветов на пиксель в принципе, то в ATM 1 и 2 второй экран есть в любом
видеорежиме, в том числе и в этом.

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

Hello Ivan!

24 Sep 05 15:59, Ivan Kuvshinov wrote to Dima Bystrov:


DB>> Дык, на коленке компьютер до 14MHz не разгонишь :)
IK> А у меня вопрос по поводу разгона, если двигать отдельно уровни, ну
IK> то есть так:

IK> ...|||...|||... ->...||...||... или вот в это ..|||..|||..

IK> Это что-нибудь может дать, в том плане, что бы побольше частоту
IK> задрать, пусть и так половинчато?

Hе понял рисунка, не понял вопроса...

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

... ZX Spectrum today

[Ivan Kuvshinov (2:5020/830.10110)]

IK>> ...|||...|||... ->...||...||... или вот в это ..|||..|||..
IK>> задрать, пусть и так половинчато?
DB> Hе понял рисунка, не понял вопроса...

Hу как бы это сказать.. - точки, это расстояние между импульсами тактового генератора, а чёрточки - длительность самого импульса. Я точно не знаю, потому и спрашиваю. Думаю, что используется в работе не только передний фронт импульса, но и задний, получается, что теоретически, длинну импульса можно сокращать до одного предела, а расстояние до другого.
Разогнали мы процессор, например, до 14МГц, но может можно будет ещё сократить одну из описанных составляющих не трогая вторую? Получиться ещё выше "усредённая" частота.

КИА

[Dima Bystrov (2:5029/77.48)]

Hello Vadik!

25 Sep 05 20:57, Vadik Akimoff wrote to Dima Bystrov:


DB>> получаем: 10 спрайтов 16x16 или 5 спрайтов 16x32 < 85000 тактов.
VA> Ага. в кадре остаётся примерно 45000 (70000-25000), 2 кадра выводить
VA> только несколько микроспрайтов =))

Для игрушек достаточно. Посчитай для сравнения, сколько тактов ты бы выводил 10
спрайтов 16x16 (по маске, с точностью в 2 пиксела по горизонтали и в один по
вертикали, с запоминанием области под спрайтами и с восстановлением оной) на
обычном экране :)


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

Есть! Первый - в 5,4 страницах, второй - в 7,6 страницах. А то, что я сказал
"надо 256k" - я тупил! следить за мной надо!
128k достаточно.

Есть мысль задавить мультиколорный режим #eff7 bit0 и продвинуть сабж цвет на
каждый пиксел (удобно накладывать что угодно на что угодно, в т.ч. для
проволочных построений, графиков и т.п.). Этот девайс должно быть возможно
собрать на почти любом неПЛИС эхотаге.
Идея простая, как шарик (ко мне в голову сложные идеи не приходят ;))).
Работать должно так:
1. в поле основного экрана все такты отдаются видеоконтроллеру (2 лог. эл-та).
2. запись в сдвиговые регистры должна идти с частотой не 0.875MHz, а 3.5MHz (1
мультиплексорный эл-т). Частота сдвига остаётся та же, какая была - 7 MHz.
3. с выходов сдвиговых регистров (через один) снимаются 4 цветовых
составляющих. эти составляющие идут через буфер/регистр (1 корпус + 1 лог.эл-т
для наложения сигнала бордюра на сигнал выборки режима) на выход и микшируются
резисторами, в палитре RGBw. биты 7 6 5 4 3 2 1 0 = wL wR GL GR RL RR BL BR,
где L - левый пиксел, R - правый пиксел.
4. во время работы этого режима выход с мультиплексоров RGBI должен
блокироваться (1 лог. эл-т).
5. адресация экрана такая же, как в мультиколорном режиме (2 лог. эл-та), но
для промежуточных (освободившихся из-за отрубания процессора от доступа к
памяти) пикселов подаётся сигнал включения нечётной страницы. Т.е. получается:
#c000 #4000 #e000 #6000 #c001 #4001 #e001 #6001 и т.д.,
где #c000 - в 4-й странице (2-я экранная область - в 6,7 страницах).
6. доступ через, допустим, тот же #eff7 bit0. Мультиколорных программ через
этот порт всё равно одна штука (моя), и та программа хорошо работает и без
аппаратного мультиколора.

Программируется очень удобно (особенно наложение спрайтов - просто кладём/не
кладём нужные 2 пиксела. Причём даже не нужно сдвигать побитно для печатания
спрайтов с точностью в 2 пиксела по горизонтали!).

Игр под это чудо нашлёпать - делать нечего. Я бы парочку нашлёпал, если бы у
меня сей режим был. Hасчёт возможных криков "megatormozzzz!" - не нужно весь
экран каждый раз чистить/заполнять, и megatormozzz'а не будет. И текст в этом
режиме листать не надо - на то обычный режим есть.

Hадо:
дешифратор порта #eff7 с триггером типа ТМ8
регистр/буфер типа ИР22/ИР23/АП5
5-6 лог. эл-тов, часть можно на диодах, часть на свободных выходах того
регистра
1 мультиплексорный эл-т, можно собрать на лог.эл-тах


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

Mon Sep 26 2005 18:19, Dima Bystrov wrote to Vadik Akimoff:


DB> Игр под это чудо нашлёпать - делать нечего. Я бы парочку нашлёпал, если
DB> бы у меня сей режим был. Hасчёт возможных криков "megatormozzzz!" - не
DB> нужно весь экран каждый раз чистить/заполнять, и megatormozzz'а не будет.
DB> И текст в этом режиме листать не надо - на то обычный режим есть.

Дима, может быть тогда в качестве тренировки (пока экран не спаял) парочку
игрулек под экраны ATM сделаешь? Вот, вроде бы UNREAL, понимающий ATM, под
WIN98 все-таки адаптировали. И экран там мультиколорный (640х200) как раз
имеется, если нужен именно он... А если уж очень надо будет реальное железо,
то можно будет и обеспечить для такого святого дела...

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

Maksagor, NedoPC group. ATM-turbo 2+

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 27 Sep 05 Maxim Timonin wrote to Dima Bystrov:


MT> Дима, может быть тогда в качестве тренировки (пока экран не спаял)
MT> парочку игрулек под экраны ATM сделаешь? Вот, вроде бы UNREAL,
MT> понимающий ATM, под WIN98 все-таки адаптировали. И экран там
MT> мультиколорный (640х200) как раз имеется, если нужен именно он...
MT> А если уж очень надо будет реальное железо, то можно будет и
MT> обеспечить для такого святого дела...

Точно! Даёшь hexagonal filler под 16цветный атм 320x200 ! =)


Bye...

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 27 Sep 05 Maxim Timonin wrote to Dima Bystrov:


MT> Дима, может быть тогда в качестве тренировки (пока экран не спаял)
MT> парочку игрулек под экраны ATM сделаешь? Вот, вроде бы UNREAL,
MT> понимающий ATM, под WIN98 все-таки адаптировали. И экран там
MT> мультиколорный (640х200) как раз имеется, если нужен именно он...
MT> А если уж очень надо будет реальное железо, то можно будет и
MT> обеспечить для такого святого дела...

Точно! Даёшь hexagonal filler под 16цветный атм 320x200 ! =)


Bye...

[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

[Dima Bystrov (2:5029/77.48)]

Hello Vadik!

27 Sep 05 07:56, Vadik Akimoff wrote to All:


VA> Точно! Даёшь hexagonal filler под 16цветный атм 320x200 ! =)

Hexagonal Filler должен на АТМ и так работать :) так что надо что-то новое.

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

... ZX Spectrum today

[Vadik Akimoff (2:5020/835.1)]

Hi!

In a message of 28 Sep 05 Dima Bystrov wrote to me:


VA>> Точно! Даёшь hexagonal filler под 16цветный атм 320x200 ! =)
DB> Hexagonal Filler должен на АТМ и так работать :) так что надо что-то
DB> новое.

Блин, на 16-цветном режиме можно будет от глюков из-за 'атрибут на байт'
избавиться. И вообще артворк улучшить заодно. :)


Bye...

[Maxim Timonin (2:5020/400)]

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

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+

[Maxim Timonin (2:5020/400)]

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

Wed Sep 28 2005 17:46, Dima Bystrov wrote to Vadik Akimoff:


VA>> Точно! Даёшь hexagonal filler под 16цветный атм 320x200 ! =)

DB> Hexagonal Filler должен на АТМ и так работать :) так что надо что-то
DB> новое.

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

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

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


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

Hадо бы, для контроля.

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

... ZX Spectrum today

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

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+

[Maxim Timonin (2:5020/400)]

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

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


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

[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

[Dima Bystrov (2:5029/77.48)]

Hello Maxim!

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


DB>> под TR-DOS есть ГОТОВАЯ ПРОФЕССИОHАЛЬHАЯ СРЕДА РАЗРАБОТКИ. Это
DB>> 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>> TR-DOS написан и отлажен готовый автосборщик с упаковкой. Под
DB>> TR-DOS
DB>> написан и отлажен готовый универсальный игровой
DB>> загрузчик-выгрузчик с
DB>> распаковкой из Rar (использован в Wolf2004). Писать всё заново?
MT> О каком загрузчике идет речь? Загрузчике дополнительных оверлеев и
MT> файлов состояний?

да.

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

в TR-DOS тоже есть файловый уровень. См. урок ассемблера в ZX-Guide#4.5. Hо о
каком файловом уровне может идти речь, когда я ВЫHИМАЮ ФАЙЛ ИЗ .RAR? на пц это
делается через перестановку указателя внутри файла и функцию blockread. а как в
CP/M?


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

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

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

^^^^^^^^^^^^^

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

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


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

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


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

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

/=== Begin Windows Clipboard ===/
MACRO pp
tba_smp=MUZ+105
tba_orn=tba_smp+64
PLAYER
frq_A=MUZ
frq_B=MUZ+2
frq_C=MUZ+4
N_frq=MUZ+6
vol_A=MUZ+8
vol_B=MUZ+9
vol_C=MUZ+10
frq_E=MUZ+11
E_form=MUZ+13
play
LD HL,int_qty
DEC (HL)
JP NZ,NOINS
;--- nota_A + calc_next_position ---
INC HL
;LD HL,A_qty
DEC (HL)
JR NZ,Aq_0
Ach_adr LD DE,tab_vol+16
LD A,(DE)
OR A
JR NZ,Ps_n0
_m1=$+2
LD (N_frq),A ;;5!!!
LD D,A ;;
LD (sav_SP2+1),SP
Psa_beg LD HL,MUZ+201
LD A,(HL)
INC A ;AAA;6
JR NZ,Ps_n1 ;NC ;6
Psa_lop LD HL,MUZ+201
Ps_n1 LD E,(HL) ;6
INC HL
LD (Psa_beg+1),HL

Psa_chn LD HL,0
ADD HL,DE
ADD HL,DE
LD SP,HL
;POP HL
;ia_pos0 LD BC,MUZ
;ADD HL,BC
;EX DE,HL ;DE=adr_chn_A
POP DE
POP HL
;ADD HL,BC ;HL=adr_chn_B
LD (Bch_adr+1),HL
POP HL
;ADD HL,BC ;HL=adr_chn_C
LD (Cch_adr+1),HL
sav_SP2 LD SP,0
Ps_n0
_m12=$+1
LD H,'tba_smp
CALL An_clc1
LD (Ach_adr+1),DE
Ai_qty LD A,0
LD (A_qty),A
DJNZ Aq_0
LD H,B
LD L,B
LD (Asl_dsp+1),HL
Aq_0
;--- nota_B ---
LD HL,B_qty
DEC (HL)
JR NZ,Bq_0
Bch_adr LD DE,0
_m13=$+1
LD H,'tba_smp
CALL Bn_clc1
LD (Bch_adr+1),DE
Bi_qty LD A,0
LD (B_qty),A
DJNZ Bq_0
LD H,B
LD L,B
LD (Bsl_dsp+1),HL
Bq_0
;--- nota_C ---
LD HL,C_qty
DEC (HL)
JR NZ,Cq_0
Cch_adr LD DE,0
_m14=$+1
LD H,'tba_smp
CALL Cn_clc1
LD (Cch_adr+1),DE
Ci_qty LD A,0
LD (C_qty),A
DJNZ Cq_0
LD H,B
LD L,B
LD (Csl_dsp+1),HL
Cq_0
;--- install_E ---
Ei_form LD A,0 ;env_form
_m11=$+2
LD (E_form),A
OR A
JR Z,temp
Ei_frq LD HL,0 ;env_frq
LD (E_frq+1),HL
XOR A
LD L,A
LD H,A
LD (Ei_form+1),A
LD (Esl_frq+1),HL
LD (Esl_stp+1),A

temp LD A,3 ;temp
LD (int_qty),A
NOINS
play_0 LD L,0 ;smp_sl_env
EXX
N_add LD IX,0 ;HX=noise LX=mix
LD (sav_SP1+1),SP
E_ins0 JR Ei_Q
Esl_ids LD HL,0 ;stp_sld_env
LD (Esl_sds+1),HL
Esl_ist LD A,0 ;stp_sld_p
LD (Esl_stp+1),A
LD (Esl_sts+1),A
LD A,24
LD (E_ins0),A
Ei_Q
;---- sampler_A ----

Avb_lok LD A,-1
LD H,A
INC A
JP Z,Avb_n0

As_adr LD SP,DUMMYSMP ;sample
POP DE ;loop E=beg D=end
As_dsp LD A,0
LD L,A
INC A
CP D
JR C,As_n0 ;bug NZ/C
LD A,E
As_n0 LD (As_dsp+1),A
SLA L
SLA L
;ADD HL,HL,HL,HL
ADD HL,SP
LD SP,HL
POP DE ;D= Nm ts ns Tm v3 v2 v1 v0
LD A,D ;E= sv +- N4 N3 N2 N1 N0 Em
OR #F0
;AND 15
LD L,A
LD A,E
ADD A,A
As_Vsl LD A,16
JR NC,As_VslG
JP M,As_n2
SUB 1
JR As_n3
As_n2 CP 31
As_n3 ADC A,0
LD (As_Vsl+1),A
As_VslG
ADD A,L
JR C,As_n4
XOR A
As_n4 CP 16
JR C,Ag_vol
LD A,15
Ag_vol ADD A,#F0
LD L,A
LD H,'tab_vol
LD A,(HL)
SRL E
JR C,Am_vo0
Am_vol OR 0
Am_vo0 EXA
LD A,D
;LD L,A
RLCA
;LD H,A
JR C,As_n5
As_Nsl LD A,0
ADD A,E
BIT 5,D
JR Z,As_n6
LD (As_Nsl+1),A
As_n6 LD HX,A
JR As_n7

As_n5 LD A,E
AND 31
CP 16
JR C,As_Esl
OR #F0
As_Esl ADD A,0
BIT 5,D
JR Z,As_n9
LD (As_Esl+1),A
As_n9 EXX
ADD A,L
LD L,A
EXX
As_n7 LD A,D
RLCA
RLCA
RLCA
RLCA
AND 9
LD LX,A
POP BC
;LD A,D
As_dtn LD HL,0 ;dsp_frq_smp
ADD HL,BC
BIT 6,D
;AND 64
JR Z,As_n10
LD (As_dtn+1),HL
As_n10 EX DE,HL

Ao_adr LD SP,DUMMYORN ;ornament
POP BC ;loop C=beg B=end
Ao_dsp LD A,0
LD L,A
INC A
CP B
JR C,$+3 ;bug NZ/C
LD A,C
LD (Ao_dsp+1),A
LD H,0
ADD HL,SP
LD A,(As_note+1)
ADD A,(HL) ;dsp_orn
ADD A,A
JR NC,$+3
XOR A
LD L,A
LD H,'tab_frq
LD SP,HL
POP HL
ADD HL,DE
Asl_dsp LD BC,0
ADD HL,BC
_m3=$+2
LD (frq_A),HL

Asl_stp LD A,0
DEC A
JP M,Asl_s0
JR NZ,Asl_s1
Asl_tfr LD DE,0
ADD HL,DE
EX DE,HL
ADD HL,BC
LD (Asl_dsp+1),HL
JR Asl_sts ;port off/on
Asl_plk
Asl_not LD A,0
LD L,A
ADD HL,HL
LD H,'tab_frq
LD SP,HL
POP HL
As_note CP 0
JR NC,$+3
EX DE,HL
SBC HL,DE
JR C,Asl_sts
LD (As_note+1),A
XOR A
LD L,A
LD (Asl_dsp+1),HL
JR $+4
Asl_sts LD A,0
Asl_s1 LD (Asl_stp+1),A
Asl_s0 EXA

_m7=$+2
Avb_n0 LD (vol_A),A
Avb_stp LD A,0
DEC A
JP M,Bvb_lok
JR NZ,Avb_n1
DEC A ;;
LD HL,Avb_lok+1;;
XOR (HL) ;;
LD (HL),A ;;4
Avb_frq LD A,0
JR NZ,Avb_n1
Avb_sts LD A,0
Avb_n1 LD (Avb_stp+1),A

;---- sampler_B ----

Bvb_lok LD A,-1
LD H,A
INC A
JP Z,Bvb_n0

Bs_adr LD SP,DUMMYSMP
POP DE
Bs_dsp LD A,0
LD L,A
INC A
CP D
JR C,Bs_n0
LD A,E
Bs_n0 LD (Bs_dsp+1),A
SLA L
SLA L
;ADD HL,HL,HL,HL
ADD HL,SP
LD SP,HL
POP DE
LD A,D
OR #F0
;AND 15
LD L,A
LD A,E
ADD A,A
Bs_Vsl LD A,16
JR NC,Bs_VslG
JP M,Bs_n2
SUB 1
JR Bs_n3
Bs_n2 CP 31
Bs_n3 ADC A,0
LD (Bs_Vsl+1),A
Bs_VslG
ADD A,L
JR C,Bs_n4
XOR A
Bs_n4 CP 16
JR C,Bg_vol
LD A,15
Bg_vol ADD A,#F0
LD L,A
LD H,'tab_vol
LD A,(HL)
SRL E
JR C,Bm_vo0
Bm_vol OR 0
Bm_vo0 EXA
LD A,D
;LD L,A
RLCA
;LD H,A
JR C,Bs_n5
Bs_Nsl LD A,0
ADD A,E
BIT 5,D
JR Z,Bs_n6
LD (Bs_Nsl+1),A
Bs_n6 LD HX,A
JR Bs_n7

Bs_n5 LD A,E
AND 31
CP 16
JR C,Bs_Esl
OR #F0
Bs_Esl ADD A,0
BIT 5,D
JR Z,Bs_n9
LD (Bs_Esl+1),A
Bs_n9 EXX
ADD A,L
LD L,A
EXX
Bs_n7 LD A,D
RRCA
RRCA
RRCA
AND 18
OR LX
LD LX,A
POP BC
;LD A,D
Bs_dtn LD HL,0
ADD HL,BC
BIT 6,D
;AND 64
JR Z,Bs_n10
LD (Bs_dtn+1),HL
Bs_n10 EX DE,HL

Bo_adr LD SP,DUMMYORN
POP BC
Bo_dsp LD A,0
LD L,A
INC A
CP B
JR C,Bo_n0
LD A,C
Bo_n0 LD (Bo_dsp+1),A
LD H,0
ADD HL,SP
LD A,(Bs_note+1)
ADD A,(HL)
ADD A,A
JR NC,$+3
XOR A
LD L,A
LD H,'tab_frq
LD SP,HL
POP HL
ADD HL,DE
Bsl_dsp LD BC,0
ADD HL,BC
_m5=$+2
LD (frq_B),HL

Bsl_stp LD A,0
DEC A
JP M,Bsl_s0
JR NZ,Bsl_s1
Bsl_tfr LD DE,0
ADD HL,DE
EX DE,HL
ADD HL,BC
LD (Bsl_dsp+1),HL
JR Bsl_sts
Bsl_plk
Bsl_not LD A,0
LD L,A
ADD HL,HL
LD H,'tab_frq
LD SP,HL
POP HL
Bs_note CP 0
JR NC,$+3
EX DE,HL
SBC HL,DE
JR C,Bsl_sts
LD (Bs_note+1),A
XOR A
LD L,A
LD (Bsl_dsp+1),HL
JR $+4
Bsl_sts LD A,0
Bsl_s1 LD (Bsl_stp+1),A
Bsl_s0 EXA

_m8=$+2
Bvb_n0 LD (vol_B),A
Bvb_stp LD A,0
DEC A
JP M,Cvb_lok
JR NZ,Bvb_n1
DEC A ;;
LD HL,Bvb_lok+1;;
XOR (HL) ;;
LD (HL),A ;;4
Bvb_frq LD A,0
JR NZ,Bvb_n1
Bvb_sts LD A,0
Bvb_n1 LD (Bvb_stp+1),A

;---- sampler_C ----

Cvb_lok LD A,-1
LD H,A
INC A
JP Z,Cvb_n0

Cs_adr LD SP,DUMMYSMP
POP DE
Cs_dsp LD A,0
LD L,A
INC A
CP D
JR C,Cs_n0
LD A,E
Cs_n0 LD (Cs_dsp+1),A
SLA L
SLA L
;ADD HL,HL,HL,HL
ADD HL,SP
LD SP,HL
POP DE
LD A,D
OR #F0
;AND 15
LD L,A
LD A,E
ADD A,A
Cs_Vsl LD A,16
JR NC,Cs_VslG
JP M,Cs_n2
SUB 1
JR Cs_n3
Cs_n2 CP 31
Cs_n3 ADC A,0
LD (Cs_Vsl+1),A
Cs_VslG
ADD A,L
JR C,Cs_n4
XOR A
Cs_n4 CP 16
JR C,Cg_vol
LD A,15
Cg_vol ADD A,#F0
LD L,A
LD H,'tab_vol
LD A,(HL)
SRL E
JR C,Cm_vo0
Cm_vol OR 0
Cm_vo0 EXA
LD A,D
;LD L,A
RLCA
;LD H,A
JR C,Cs_n5
Cs_Nsl LD A,0
ADD A,E
BIT 5,D
JR Z,Cs_n6
LD (Cs_Nsl+1),A
Cs_n6 LD HX,A
JR Cs_n7

Cs_n5 LD A,E
AND 31
CP 16
JR C,Cs_Esl
OR #F0
Cs_Esl ADD A,0
BIT 5,D
JR Z,Cs_n9
LD (Cs_Esl+1),A
Cs_n9 EXX
ADD A,L
LD L,A
EXX
Cs_n7 LD A,D
RRCA
RRCA
;RRCA
AND 36
OR LX
LD LX,A
POP BC
;LD A,D
Cs_dtn LD HL,0
ADD HL,BC
BIT 6,D
;AND 64
JR Z,Cs_n10
LD (Cs_dtn+1),HL
Cs_n10 EX DE,HL

Co_adr LD SP,DUMMYORN
POP BC
Co_dsp LD A,0
LD L,A
INC A
CP B
JR C,Co_n0
LD A,C
Co_n0 LD (Co_dsp+1),A
LD H,0
ADD HL,SP
LD A,(Cs_note+1)
ADD A,(HL)
ADD A,A
JR NC,$+3
XOR A
LD L,A
LD H,'tab_frq
LD SP,HL
POP HL
ADD HL,DE
Csl_dsp LD BC,0
ADD HL,BC
_m6=$+2
LD (frq_C),HL

Csl_stp LD A,0
DEC A
JP M,Csl_s0
JR NZ,Csl_s1
Csl_tfr LD DE,0
ADD HL,DE
EX DE,HL
ADD HL,BC
LD (Csl_dsp+1),HL
JR Csl_sts
Csl_plk
Csl_not LD A,0
LD L,A
ADD HL,HL
LD H,'tab_frq
LD SP,HL
POP HL
Cs_note CP 0
JR NC,$+3
EX DE,HL
SBC HL,DE
JR C,Csl_sts
LD (Cs_note+1),A
XOR A
LD L,A
LD (Csl_dsp+1),HL
JR $+4
Csl_sts LD A,0
Csl_s1 LD (Csl_stp+1),A
Csl_s0 EXA

_m9=$+2
Cvb_n0 LD (vol_C),A
Cvb_stp LD A,0
DEC A
JP M,Esl_
JR NZ,Cvb_n1
DEC A ;;
LD HL,Cvb_lok+1;;
XOR (HL) ;;
LD (HL),A ;;4
Cvb_frq LD A,0
JR NZ,Cvb_n1
Cvb_sts LD A,0
Cvb_n1 LD (Cvb_stp+1),A

;---- sampler_E ----

Esl_ EXX
LD A,L
Esl_frq LD DE,0 ;stp_sl_env
E_frq LD HL,0 ;frq_env
ADD A,L
LD L,A
ADD HL,DE
_m10=$+2
LD (frq_E),HL
Esl_stp LD A,0
DEC A
JP M,sav_SP1
JR NZ,E_n0
Esl_sds LD HL,0
ADD HL,DE
LD (Esl_frq+1),HL
Esl_sts LD A,0
E_n0 LD (Esl_stp+1),A

;---- out_to_processor ----

sav_SP1 LD SP,0
out_
LD DE,#FFBF
LD C,-3
_m4=$+2
LD HL,frq_A

LD A,7
CALL OUTER

LD A,HX ;noise
LD (N_add+3),A
ADD A,(HL)
OUT (C),A
INC L
LD B,D
OUT (C),L
LD A,LX ;mix
LD B,E
OUT (C),A
INC L

LD A,6
CALL OUTER

OR (HL)
RET Z
OUT (C),A
LD (HL),0 ;;4
RET

;--- nota_A ---

Ani_vol JR NZ,Ani_v0
LD (Avb_stp+1),A
DEC A
LD (Avb_lok+1),A
RET
Ani_v0
DUP 4
ADD A,A
EDUP
LD (Ag_vol+1),A
JP An_clc2
Ani_s_o
CALL ornPP
LD (Ao_adr+1),BC
Ani_vse
CALL NZ,EiPP
Ani_sm0 LD (Am_vol+1),A
XOR A
LD (Ao_dsp+1),A
LD A,(DE)
INC DE
JR Anism0U ;
Ani_smp RET Z ;
ADD A,A ;
Anism0U
CALL smpPP
LD (As_adr+1),BC

An_clc1 LD BC,#1020
An_clc2 LD A,(DE)
INC DE
ADD A,B
JR C,Ani_s_o
ADD A,C
JR C,Ani_smp
ADD A,B
JR C,Ani_vol
ADD A,B
JR C,Ani_vqe
ADD A,96
JR C,Ani_not
ADD A,B
JR C,Ani_orn
ADD A,48
JR C,Ani_vse
LD HL,A_eff+30
LD BC,As_note+1
CALL NPUSH
JR An_clc1

Ani_vqe JR Z,Ani_v1
DEC A
JR NZ,Ani_e0
LD A,(DE)
LD (Ai_qty+1),A
INC DE
JR An_clc2

Ani_e0 CALL EiPP
Ani_v1 LD (Am_vol+1),A
JR An_clc2
Ani_orn
CALL ornPP
LD (Ao_adr+1),BC
LD (Ao_dsp+1),A
JR An_clc1

Ani_not LD (As_note+1),A
XOR A
LD H,A
LD L,A
LD (As_dsp+1),A
LD (As_Nsl+1),A
LD (As_Esl+1),A
LD (Ao_dsp+1),A
LD (Asl_stp+1),A
LD (Avb_lok+1),A
LD (Avb_stp+1),A
;LD (Asl_dsp+1),HL
LD (As_dtn+1),HL
LD A,16
LD (As_Vsl+1),A
;JR LDB1
LD B,1
RET

;--- nota_B ---

Bni_vol JR NZ,Bni_v0
LD (Bvb_stp+1),A
DEC A
LD (Bvb_lok+1),A
RET
Bni_v0
DUP 4
ADD A,A
EDUP
LD (Bg_vol+1),A
JP Bn_clc2
Bni_s_o
CALL ornPP
LD (Bo_adr+1),BC
Bni_vse
CALL NZ,EiPP
Bni_sm0 LD (Bm_vol+1),A
XOR A
LD (Bo_dsp+1),A
LD A,(DE)
INC DE
JR Bnism0U ;
Bni_smp RET Z ;
ADD A,A ;
Bnism0U
CALL smpPP
LD (Bs_adr+1),BC

Bn_clc1 LD BC,#1020
Bn_clc2 LD A,(DE)
INC DE
ADD A,B
JR C,Bni_s_o
ADD A,C
JR C,Bni_smp
ADD A,B
JR C,Bni_vol
ADD A,B
JR C,Bni_vqe
ADD A,96
JR C,Bni_not
ADD A,B
JR C,Bni_orn
ADD A,C
JR C,Bni_noi
ADD A,B
JR C,Bni_vse
LD HL,B_eff+30
LD BC,Bs_note+1
CALL NPUSH
JR Bn_clc1

Bni_not LD (Bs_note+1),A
XOR A
LD H,A
LD L,A
LD (Bs_dsp+1),A
LD (Bs_Nsl+1),A
LD (Bs_Esl+1),A
LD (Bo_dsp+1),A
LD (Bsl_stp+1),A
LD (Bvb_lok+1),A
LD (Bvb_stp+1),A
;LD (Bsl_dsp+1),HL
LD (Bs_dtn+1),HL
LD A,16
LD (Bs_Vsl+1),A
LDB1 LD B,1
RET

_m2=$+2
Bni_noi LD (N_frq),A;GLOBALnoise
JR Bn_clc2

Bni_vqe JR Z,Bni_v1
DEC A
JR NZ,Bni_e0
LD A,(DE)
LD (Bi_qty+1),A
INC DE
JR Bn_clc2

Bni_e0 CALL EiPP
Bni_v1 LD (Bm_vol+1),A
JR Bn_clc2
Bni_orn
CALL ornPP
LD (Bo_adr+1),BC
LD (Bo_dsp+1),A
JR Bn_clc1

;--- nota_C ---

Cni_not LD (Cs_note+1),A
XOR A
LD H,A
LD L,A
LD (Cs_dsp+1),A
LD (Cs_Nsl+1),A
LD (Cs_Esl+1),A
LD (Co_dsp+1),A
LD (Csl_stp+1),A
LD (Cvb_lok+1),A
LD (Cvb_stp+1),A
;LD (Csl_dsp+1),HL
LD (Cs_dtn+1),HL
LD A,16
LD (Cs_Vsl+1),A
;JR LDB1
LD B,1
RET

Cni_vol JR NZ,Cni_v0
LD (Cvb_stp+1),A
DEC A
LD (Cvb_lok+1),A
RET
Cni_v0
DUP 4
ADD A,A
EDUP
LD (Cg_vol+1),A
JP Cn_clc2
Cni_s_o
CALL ornPP
LD (Co_adr+1),BC
Cni_vse
CALL NZ,EiPP
Cni_sm0 LD (Cm_vol+1),A
XOR A
LD (Co_dsp+1),A
LD A,(DE)
INC DE
JR Cnism0U ;
Cni_smp RET Z ;
ADD A,A ;
Cnism0U
CALL smpPP
LD (Cs_adr+1),BC

Cn_clc1 LD BC,#1020
Cn_clc2 LD A,(DE)
INC DE
ADD A,B
JR C,Cni_s_o
ADD A,C
JR C,Cni_smp
ADD A,B
JR C,Cni_vol
ADD A,B
JR C,Cni_vqe
ADD A,96
JR C,Cni_not
ADD A,B
JR C,Cni_orn
ADD A,48
JR C,Cni_vse
LD HL,C_eff+30
LD BC,Cs_note+1
CALL NPUSH
JR Cn_clc1

Cni_vqe JR Z,Cni_v1
DEC A
JR NZ,Cni_e0
LD A,(DE)
LD (Ci_qty+1),A
INC DE
JR Cn_clc2

Cni_e0 CALL EiPP
Cni_v1 LD (Cm_vol+1),A
JR Cn_clc2
Cni_orn
CALL ornPP
LD (Co_adr+1),BC
LD (Co_dsp+1),A
JR Cn_clc1

;---- special_effects_COM.xxxx ----

EiPP LD (Ei_form+1),A
LD A,(DE)
INC DE
LD (Ei_frq+2),A
LD A,(DE)
INC DE
LD (Ei_frq+1),A
LD A,16
RET ;16

Aef_dSm LD A,(DE) ;dsp_smp
INC DE
LD (As_dsp+1),A ;;si
RET
Bef_dSm LD A,(DE)
INC DE
LD (Bs_dsp+1),A ;;si
RET
Cef_dSm LD A,(DE)
INC DE
LD (Cs_dsp+1),A
RET

A_eff DW Aef_slT ;1xxx,2xxx - sld_tone
DW Aef_nsT ;3xxx - port_note
DW Aef_dSm ;4.xx - dsp_smp
DW Aef_dOr ;5.xx - dsp_orn
DW Aef_vib ;6.xx - vibrato
Aef_vib LD A,(DE)
INC DE
JR Aef_vjr
DW Eef_sld ;9xxx,Axxx - sld_env
DW eff_tmp ;B.xx - temp

Aef_vjr LD (Avb_sts+1),A;fix fr/st;;ist
LD (Avb_stp+1),A
LD A,(DE)
INC DE
LD (Avb_frq+1),A;fix st/fr;;ifr
RET

B_eff DW Bef_slT
DW Bef_nsT
DW Bef_dSm
DW Bef_dOr
DW Bef_vib
Bef_vib LD A,(DE)
INC DE
JR Bef_vjr
DW Eef_sld
DW eff_tmp

Bef_vjr LD (Bvb_sts+1),A;fix fr/st;;ist
LD (Bvb_stp+1),A
LD A,(DE)
INC DE
LD (Bvb_frq+1),A;fix st/fr;;ifr
RET

C_eff DW Cef_slT
DW Cef_nsT
DW Cef_dSm
DW Cef_dOr
DW Cef_vib
int_qty DB 1
A_qty DB 1
B_qty DB 1
C_qty DB 1
DW Eef_sld
DW eff_tmp

Cef_vib LD A,(DE)
INC DE
LD (Cvb_sts+1),A;fix fr/st
LD (Cvb_stp+1),A
LD A,(DE)
INC DE
LD (Cvb_frq+1),A;fix st/fr
RET

Aef_nsT
CALL Aef_slT
;LD (Asl_pfr+1),HL ;;pi
CALL GETHL
LD (Asl_tfr+1),HL ;;pi
LD (Asl_plk-1),A;port_on ;;pi_lok
LD HL,As_note+1 ;;si
LD A,(HL)
LD (Asl_not+1),A ;;pi
AnsQ EXA
LD (HL),A
LD B,0
RET
Bef_nsT
CALL Bef_slT
;LD (Bsl_pfr+1),HL ;;pi
CALL GETHL
LD (Bsl_tfr+1),HL ;;pi
LD (Bsl_plk-1),A ;;pi_lok
LD HL,Bs_note+1 ;;si
LD A,(HL)
LD (Bsl_not+1),A ;;pi
JR AnsQ
Cef_nsT
CALL Cef_slT
;LD (Csl_pfr+1),HL
CALL GETHL
LD (Csl_tfr+1),HL
LD (Csl_plk-1),A
LD HL,Cs_note+1
LD A,(HL)
LD (Csl_not+1),A
JR AnsQ

Aef_slT LD A,(DE)
LD (Asl_stp+1),A ;;pi
LD (Asl_sts+1),A
CALL IGETHL ;sld_ton
LD (Asl_tfr+1),HL ;;pi
LD (Avb_stp+1),A
LD A,Asl_sts-Asl_plk
LD (Asl_plk-1),A;port_off ;;pi
RET

Bef_slT LD A,(DE)
LD (Bsl_stp+1),A ;;pi
LD (Bsl_sts+1),A
CALL IGETHL
LD (Bsl_tfr+1),HL ;;pi
LD (Bvb_stp+1),A
LD A,Bsl_sts-Bsl_plk
LD (Bsl_plk-1),A ;;pi
RET

Cef_slT LD A,(DE)
LD (Csl_stp+1),A
LD (Csl_sts+1),A
CALL IGETHL
LD (Csl_tfr+1),HL
LD (Cvb_stp+1),A
LD A,Csl_sts-Csl_plk
LD (Csl_plk-1),A
RET

eff_tmp
LD A,(DE)
tab_vol
INC DE
LD (temp+1),A
RET

ornPP ADD A,A
ADD A,tba_orn-tba_smp
smpPP ADD A,tba_smp
LD L,A
LD C,(HL)
INC L
LD B,(HL)
XOR A
RET ;11
DUMMYORN
DUMMYSMP
tab_frq DS #C0
Eef_sld LD A,(DE) ;sld_env
LD (Esl_ist+1),A ;;stp
CALL IGETHL
LD (Esl_ids+1),HL ;;sds
LD A,6
LD (E_ins0),A
RET ;16

OUTI
OUT (C),L
LD B,E
DEC A
JR NZ,OUTER-2
RET ;10

Aef_dOr LD A,(DE) ;dsp_orn
INC DE
LD (Ao_dsp+1),A ;;oi
RET
Bef_dOr LD A,(DE)
INC DE
LD (Bo_dsp+1),A ;;oi
RET
Cef_dOr LD A,(DE)
INC DE
LD (Co_dsp+1),A
RET ;6

GETHL
EX DE,HL
LD E,(HL)
INC HL
LD D,(HL)
INC HL
EX DE,HL
XOR A
RET ;9

ADD A,L
LD L,A
;LD H,'A_eff
LD A,(HL)
INC L
LD H,(HL)
LD L,A
EX (SP),HL
LD A,(BC)
EXA
JP (HL) ;11
LENP=$-PLAYER
DISPLAY "SIZE=",LENP
T_m
DW _m1
DW _m2
DW _m3
DW _m4
DW _m5
DW _m6
DW _m7
DW _m8
DW _m9
DW _m10
DW _m11
DW _m12
DW _m13
DW _m14
T_m_l=$-T_m/2
ENDM

IF $-#8000
MUZ
P1
LOCAL
pp
ENDL
ORG #C000
P2
pp
ORG $
LD IX,#7000
LD HL,P1
LD DE,P2
LD BC,LENP
CP0 LD A,(DE)
SUB (HL)
JR Z,CPOK
CP #40
JR NZ,ERR
LD (IX),E
LD (IX+1),D
INC IX,IX
DEC BC
LD A,B
OR C
JR NZ,CP0
RET
LD DE,#5800
LD BC,768
LDIR
RET
ELSE
pp
ENDIF
/=== End Windows Clipboard ===/

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


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

синтаксис ALASM - заслуга ALEM'а и KVA.


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

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


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

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


DB>> Или кодить по кусочкам в аласме, а потом неизвестно как склеивать

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^

DB>> программу из кусочков в CP/M, причём непонятно, как отлаживать

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

см. подчёркнутое.


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

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


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

понятно, rar'ы отменяем... ну, шут с ними...


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

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


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

ты начал говорить про скорость загрузки trdшников в память, а я поддержал
разговор :)


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

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


DB>> Только DNA OS на ZX поддерживает FAT. Больше никакая система.
DB>> Разделы
MT> Это хорошо, конечно. Hо какая это разница для гиптетической игры?

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

MT> Hе
MT> перепрыгивай на левые темы.

Hаше дело правое, наши темы тоже :)

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

Среда абсолютно такая же, как в TR-DOS. Т.к. DNA OS, кроме файловой системы
FAT, поддерживает ещё и файловую систему TR-DOS. Через те же функции.


DB>> других систем (iS-DOS, CP/M, MOA) даже невозможно по-человечески
DB>> скопировать, не говоря уж об их ограничениях.
MT> IS-DOSные разделы достаточно легко копируются - создается их
MT> IMG-образ. Потом он режется на части, чтобы влезть на MS-DOS дискетки,
MT> переносится на пЦ, там склеивается и
MT> просматривается/редактируется/копируется пофайлово через FAR

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


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

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

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

... ZX Spectrum today

[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

[Vadik Akimoff (2:5020/835.1)]

Hi!

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


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

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


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



Bye...

[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

[Vadik Akimoff (2:5020/835.1)]

Hi!

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


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

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


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



Bye...

[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

[Vadik Akimoff (2:5020/835.1)]

Hi!

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


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

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


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



Bye...

[Maxim Timonin (2:5020/400)]

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

Mon Oct 10 2005 12:55, Vadik Akimoff wrote to Dima Bystrov:


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

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

Maksagor, NedoPC group. ATM-turbo 2+

[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

[Vadik Akimoff (2:5020/835.1)]

Hi!

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


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

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


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



Bye...

[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

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

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

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

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


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

Ага, а что на атмегах делают поддержку FATов - это небось вообще
недостижимое чудо для спека. Hеужели поддержка FATа на порядки тормознее и
больше по размерам, чем поддержка издосной фсы?


Bye...

[Dima Bystrov (2:5029/77.48)]

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

13 Oct 05 23:41, Kirill Frolov wrote to Dima Bystrov:


Мене жутко смешно. Профессиональная -- это стало быть та, в которой
работают люди, как бы это сказать, по-профессии, профессионально.
Hе путать с хобби и другими видами спектрумизма.

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


Кто /профессионально/ использует ALASM? Я вот вижу, что
профессионально программирующие Z80 берут IAR C и не морочат
себе голову.

И создают себе тормоза.

Просто потому, что: alasm не запускается в современных
ОС

Какие ты называешь современными? Он и под XP запускается без проблем.

, и потому, что к нему нет современного редактора текста
(со всеми модными фичами разумеется!)

Это с какими же модными фичами?
Редактировать можешь хоть в ворде, потому как импорт в аласме встроенный.
Только редактировать ВHЕ среды, в которую компилируется программа - маразм, ибо
времени тратится больше в разы.


В нормальных, не ассемблеро-центрических, системах так проблема и не
стоит. А у тебя вот вменяемый компоновщик имеется?

Имеется.

Как спрашивается
из нескольких модулей собирать? Всё целиком?

Да.

Во-первых долго

Numlock никто не отменял.

, после
чего ты скажешь нужен возврат в ассемблер.

Сброс в Gluk, потом кнопка X.

Во-вторых конфликт имён.

Каких?

В
третьих просто бардак в исходнике, по очевидным причинам. И непонятно
как быть с библиотеками (A зависит от B, а B от C, которое зависит от
A...)

Инклюдь библиотеки в библиотеки - какая проблема?


Может ты удивишься, но точно так же.

Дискрет должен быть в 1 байт. Сорсы унрара показать?

Единственное что, там дискрет
-- 128 байт. Hа уровне ansi C различий вообще не видно практически.

Дискрет должен быть в 1 байт.


В ALASM рекурсивные макросы уже работают?

Они там по жизни работали. Какие проблемы?

/=== Begin Windows Clipboard ===/
mstack=#C000
MACRO push
mstack=mstack-2
ORG mstack
DW \0
ENDM

MACRO pop
\0={mstack}
mstack=mstack+2
ENDM

MACRO fibo
a=\0
IF \0-2<1&1
fibo \0-1
push a
fibo \0-2
pop x
a=a+x
ENDIF
ENDM

fibo 6
DISPLAY a
/=== End Windows Clipboard ===/

Только HАФИГ HУЖHЫ РЕКУРСИВHЫЕ МАКРОСЫ?


Ибо ни нафиг никому не нужно, ни сил и времени лишнего тоже нет.
А тратить своё время на бесперспективные "коммандеры" ещё более
бесперспективно. Посмотрите как элементарный zip или rar
прикручивается к midnight commander.

Что это за коммандер?

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

... ZX Spectrum today

[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

[Dima Bystrov (2:5029/77.48)]

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

13 Oct 05 06:05, Maxim Timonin wrote to Dima Bystrov:


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

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


Файловый уровень В ПРИHЦИПЕ там есть. Hо вот используется он
да-а-алеко не всегда. Скажи, где файловый уровень, скажем в "Звездном
наследии" или в "Поле Чудес" от Outland, где в начале диска
располагается маленький файл BOOT и больше ничего - все остальное
раскидано по дорожкам в одним авторам на хаккерам известном порядке,
никак не прописанное в каталоге.

Файловый уровень используется, например, в редакторе уровней Wolf'а и в
редакторе DBS. Этот уровень неудобен тем, что доступ к файлу только целиком, а
при ухищрениях (23796) только последовательный, причём блоками по 256 байт. Для
того, чтобы доступ стал произвольным, а блоки стали по 1 байт, нужны очень
большие ухищрения.


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

Да, с заданием размера блока.

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

...размером в 128 байт. Такое блочное чтение не годится.


Редактор - здесь:
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

А почему бы не запостить это в эху? я фидошник.


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

Тут всё на винте летает, а под TR-DOS'ом можно INCBIN'ы компильнуть в память
один раз, а второй раз не компилировать (есть такая директива, "плюс").
И будет ноль секунд на INCBIN. А INCLUDE'енные исходники вообще без вопросов по
страничкам лежат. iS-DOS нервно курит в сторонке. И получается ноль секунд на


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

Помимо всего уже мной сказанного, я после произведения изменений в исходнике
ещё подумаю, сохранять ли его. Я его при сомнительном изменении компилировую,
запускаю, проверяю, возвращаюсь в аласм и уже тогда (если захочу) сохраняю. Ибо
нефиг портить хороший исходник на диске плохим изменением.


Мы люди простые, рабоче-крестьянские.

И мы не из буржуев :)

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

Как я уже писал письмом выше, я наивно полагал, что спектрумисты Info Guide
читают. Оказывается, АТМщики не читают. Видать, у них свои журналы...

IG#7: перемещаемость программ: пункт 2:
/=== Begin Windows Clipboard ===/
В PT Util для составления таблицы приД
меняется более удобный метод, при котором
ассемблировать нужно не 2-3 раза, а всего
1. Происходит это так.
Плейер для PT Util сидит в отдельном
исходнике, который при INCLUDE'инге его в
основную программу ассемблируется как обыД
чный плейер. Hо если его попытаться отасД
семблировать как самостоятельную програмД
му, то:
1. Автоопределяется:адрес компиляции раД
вен #8000, следовательно, нужно произвести
компиляцию для создания перемещальной табД
лицы.
2. Плейер ассемблируется как макрос
MACRO pp
(весь целиком загоняется в макрос), в паД
мять при этом не кладётся. (То же происхоД
дит и при упомянутом INCLUDE'инге .)
3. Макрос плейера ассемблируется по-насД
тоящему, с локальными метками, под адрес
#8000. (А вот этого при INCLUDE'инге не
происходит.)
4. Макрос плейера ассемблируется по-насД
тоящему ещё раз,уже не с локальными меткаД
ми, под адрес #C000. (А при INCLUDE'инге -
под адрес, который был текущим на момент
команды INCLUDE .)
5. Ассемблируется сравнивалка. Адрес заД
пуска программы - переход на сравнивалку.
То есть: запускаем по RUN - составляется
таблица. Можно сохранить её вручную. Позже
я освоил процедурку SAVEOBJ, её самое месД
то применить здесь - тогда по RUN таблица
не только составится, но и сохранится. И
тогда всё - таблицу уже можно использовать
в основной программе, путём INCBIN. В проД
цедуру SAVEOBJ из инициализационного куска
программы (точнее, из подразумевающегося
таковым - например, из нашей сравнивалки)
можно выйти через JP nenado. Я имею в виду
мою версию SAVEOBJ, а не ту, которую рас-
пространял Capry.

/=== End Windows Clipboard ===/


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

В ALASM адрес компиляции по умолчанию равен #8000. Если этот исходник
компилируется отдельно, он создаёт две копии плейера (откомпилированные под
разные адреса) и сравнивалку. Если он INCLUDE'ится, то он создаёт одну копию
плейера для PT Util. Определение происходит по адресу компиляции. Hо можно
определять и по факту определённости какой-нибудь метки - ALASM и такое
позволяет.


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

Был такой режим работы на древних ЭВМ. Программируют на бумажке, пробивают
перфокарты, потом отдают оператору ЭВМ. Потом ждут результата. Потом опять
продумывают на бумажке, пробивают перфокарты и т.д.
Ирония заключается в том, что и это, и то, что ты предлагаешь - тормоз.


В iS-DOS уже есть - TRD читается (пока не пишется) как отдельное
устройство.

Вообще-то в этом абзаце разговор, как сейчас помню, шёл об ассемблировании на
пц программ под CP/M, а отнюдь не об ассемблировании на iS-DOS программ под
iS-DOS :)

Hо все-таки не пойму, почему просто не скопировать все
муз. и граф. файлы с TRD-шки на винт один единственный раз

А я их, что, не должен потом редактировать? Здрасьте пожалуйста!


Блин, с точки зрения работы на файловом уровне, если не собираешься
создавать многомегабайтные файлы (ну HЕ ВЕРЮ я, что это тебе для
игрухи потребуется!

кто знает, что потребуется ПОТОМ? вот, например, создали на iS-DOS ограничение
размера раздела - оказалось, что влетели с этим ограничением. Hе сделали в CP/M
подкаталогов - тоже влетели. Hе предвидели будущего. Для DNA OS, пока она в
руках автора, возможно всё. Если будут грамотные предложения.


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

Последнее можно поподробнее? То есть я не могу занимать страницы полностью? Или
это относится только к экранным? И какие адреса?


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

Всё ещё жду ответа на мыльное письмо.


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

Лежало в IG7, а потом кидалось сюда совсем недавно.

скриншотики бы выслал

красивых окошек нету. не про то система.

, да хотя бы краткое описание ее
структуры, идеологии и функций, как реализованных, так и
планирующихся.

см.IG7. Там 155k (!) текста про DNA OS.


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

игре, хорошо написанной под хорошую ОСь, это должно быть безразлично.


А я уже в предыдущей мессаге писал, что ОСи этой еще нет. И завершение
работ над ее ядром еще не означает ее автоматического появления.

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

Кстати, для размышления: DNA - opensource.


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

Hет, ты с реальщиком поговори, у которого конкретно и уже давно встала эта
проблема. То есть с Амосовым. Теории про копирование iS-DOS разделов излагать -
это одно, а на практике скопировать эти разделы на другой винт - это совершенно
другое.


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

Far'ом с этими плагинами я и сам пользуюсь, только разговор шёл про копирование
реальных разделов с реального ZX. В случае TR-DOS это дискеты. ГДЕ В ФАРЕ
КОПИРОВАHИЕ ДИСКЕТ?
Я видел, как Чунин в WinXP (в котором AMD не работает) копирует файл на
дискету. Опишу процесс.
1. Списываем с помощью rdtrdos ВСЮ ДИСКЕТУ на винт.
2. Добавляем на trd файл фаром.
3. Записываем с помощью wrtrdos ВСЮ ДИСКЕТУ.
Всё это очень, знаете, приятственное занятие и наилучшая трата времени.

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

... ZX Spectrum today

[Danil Davydov (2:5050/151.11)]

From: Izhevsk_Russia (Kama_river_net)<hr>
Привет Maxim!

15 Окт 05 05:22, Maxim Timonin -> Danil Davydov:

Блин, дожили. Я. в принципе, кодер-то несильный, дык почему я должен
разжевывать элементарные азы? Ты сам-то понял, что сказал? Вот твои
слова про чтение частей файла по смещению от его начала КАК РАЗ И ЕСТЬ
РАБОТА HА ФАЙЛОВОМ УРОВHЕ!!!

Да я-то понял. Я специально свою цитату оставил, чтоб ты еще раз перечитал и
понял сам. А то столько всего понаписал, какой-то воды, я-то в принципе все это
знаю и понимаю, я лишь некоторые моменты и различия уточнил. Есть произвольный
доступ к файлу, я с этим и не спорю. Хотя и не только произвольный. Есть
программисты, которым влом работать с одним файлом в таком режиме (теперь
вдумайся - тот же _аналог_ TR-DOS диска, ибо нужно считать смещения от начала
или конца файла, каталога-то внутри файла где там и чего нету, да и механизма
адресации внутри файла на уровне ОС, нужно самому ползать там через те же
команды смещения), потому они создают просто кучу мелких, каждый из которых
содержит свою типовую информацию. Вот тебе файловый уровень. А работа с одним
большим файлом последовательно - такая же работа для мазохиста, как и работа с
диском TR-DOS на физическом уровне. И файлового уровня ОС это мало касается.
Теперь понял разницу? Про синтезированные файлы типа *.pak тоже примерно так
же, только там уже как в архиве есть каталог, в котором уже можно указать
внутренние смещение от начала или конца файла, и уже средствами ОС лезть в те
места файла. Это все относительно, все эти ваши файловые уровни.


TR-DOS это особая тема для разговора.

Предлагаешь завести особую тему? :)


А вопрос о файловом уровне я поднял (напоминаю для тех, кто забыл о
чем был разговор в начале ветки дискуссии) о переносе планируемого в
будущем игрового софта под другие ОСи - в частности CP/M.

Я, например, помню. Я ж написал, что это всего-лишь заметка, а то помешались
вы там на каком-то мифическом файловом уровне. Что мешает файлы типа архивов
или *.pak переносить под разные оси, чтоб потом программа из файла выуживала
данные для себя? Вот только не надо это называть файловым уровнем. Pабота с
TRD-образом будет происходить аналогичным образом.


С рулезами, Danil aka Merlin/ULG


 Ay_Emul: IMP56:JUST LET ME GO
---

[Vladimir Bogdanovitch (2:5090/108.21)]

FromNet: Krasnoyarsk_Russia (CenterSibNet)

In a message of 16 Oct 05 Kirill Frolov wrote to me:...
Я ещё соглашусь на счёт спектрумовских файлов. Ибо действительно. более нечем. Hо что касается архивации вообще -- это абсолютный бред,. пытаться делать это руками. ЗАЧЕМ? Всё равно же потом а) извлекать,. б) обновлять. Достаточно иметь иерархию каталогов, куда и раскладывать. файлы. Вручную уже. А запаковывать можно чем угодно и как угодно, хоть. целиком всё для сжатия, хоть пофайлово для удобства...У меня в коллекции все файлы аpхивиpованные и в основном в zip (кpоме.эмулятоpов и РС утилит). Мне их нужно откpывать, сpавнивать с дpугими.аpхивами, пеpемещать из аpхива в аpхив недостающие файлы или заменять (а.внутpи аpхива SCL или TRD). Вpучную я и не аpхивиpую, хотя все же надо.часто, чтобы не искать по папкам незапакованные файлы. И надо, чтобы по.ShiftF1 паковалось по максимуму! Вот с rar-аpхивами нет пpоблем, но Rar.установлен слишком новый для спековских файлов - pеальщики не pаспакуют. А.то пеpепаковал бы все в Rar-аpхивы. Да на zx_da_ru тоже все в zip. Каждый.pаз пеpепаковывать? Hеудобно...vBv [2CD NZXS v3.15 (23.09.2005)].

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Fri Oct 14 2005 16:21, Dima Bystrov wrote to Kirill Frolov:


Редактировать можешь хоть в ворде, потому как импорт в аласме встроенный.
Только редактировать ВHЕ среды, в которую компилируется программа -
маразм, ибо времени тратится больше в разы.

Докажи! Мой опыт говорит об обратном (о том, что большой разницы нет). А ты,
ИМХО, говоришь глупости. Я не критикую ALASM, обрати внимание. Это штука
хорошая. А лишь твое отношение к способам компиляции...



Дискрет должен быть в 1 байт. Сорсы унрара показать?


Дискрет должен быть в 1 байт.

А что, товарисчъ AlCo, в TR-DOS при работе с файлами возможно на уровне
системы считать с диска 1 байт? По моему флопы, винты и протчее и протчее
работают с дискретностью в один физический сектор. Через драйвера, которые
считанный физический сектор режут на куски, можно считать логические блоки и
поменьше. В CP/M это - 128 байт. В iS-DOS - 256 байт. Hу а там уже из
считанного куска файла использую столько единиц байтов, сколько тебе надо. Дык
какую дискретность тебе еще надо?

Maksagor, NedoPC group. ATM-turbo 2+

[Kirill Frolov (2:5030/827.2)]

FromNet: St.Petersburg (fido.mariinsky.ru)

Hемедленно нажми на RESET, Dima Bystrov!

On Fri, 14 Oct 05 15:21:22 +0400, Dima Bystrov wrote:


Имеется.

Где?


Numlock никто не отменял.

Какой lock? У меня вот скорпион.


Каких?

В библиотеках, которые перекомпилируются каждый раз. Ибо все локальные
символы имеют глобальную область видимости. Hу и потом опять начнётся,
у ассемблера список меток переполняется... Зачем это надо?


Инклюдь библиотеки в библиотеки - какая проблема?

Hа самом деле ты хотел сказать "заимствуй библиотеки в исходник".
Проблемы начинаются при переезде на следующую версию библиотеки.


Дискрет должен быть в 1 байт. Сорсы унрара показать?

Hу не может он. CP/M так устроен. Там длина файла не в байтах
вообще измеряется. Hужен один байт -- напиши враппер над её бдосом.
Только длина самого файла нигде точней чем до 128 байт не сохраняется
в любом случае.
Или пиши на C и не морочь себе голову -- там эта проблема решена.


Они там по жизни работали. Какие проблемы?

Вот в ZASM не работают. И что, аргументы передаются как строки?
И директивы условной компиляции в них работают?


Только HАФИГ HУЖHЫ РЕКУРСИВHЫЕ МАКРОСЫ?

Затем же зачем вообще нужны макросы. Только чуть по-сложней.
Hапример, подставить что-нибудь N-раз. Посчитать что-нибудь.


Что это за коммандер?

Да уродство редкостное. Интересно только то, что прикручивание
очередного архиватора не требует излишних сложностей.

[Kirill Frolov (2:5030/827.2)]

FromNet: St.Petersburg (fido.mariinsky.ru)

Hемедленно нажми на RESET, Dima Bystrov!

On Fri, 14 Oct 05 16:18:54 +0400, Dima Bystrov wrote:



2. Плейер ассемблируется как макрос
MACRO pp
(весь целиком загоняется в макрос), в паД
мять при этом не кладётся. (То же происхоД
дит и при упомянутом INCLUDE'инге .)
3. Макрос плейера ассемблируется по-насД
тоящему, с локальными метками, под адрес
#8000. (А вот этого при INCLUDE'инге не
происходит.)
4. Макрос плейера ассемблируется по-насД
тоящему ещё раз,уже не с локальными меткаД
ми, под адрес #C000. (А при INCLUDE'инге -
под адрес, который был текущим на момент
команды INCLUDE .)
5. Ассемблируется сравнивалка. Адрес заД
пуска программы - переход на сравнивалку.
То есть: запускаем по RUN - составляется
таблица. Можно сохранить её вручную. Позже
я освоил процедурку SAVEOBJ, её самое месД
то применить здесь - тогда по RUN таблица
не только составится, но и сохранится. И
тогда всё - таблицу уже можно использовать
в основной программе, путём INCBIN. В проД

Гениально. Ты изобрёл примитивный компоновщик. Ещё немного и к нему
будет прикручиваться таблица глобальных символов программы.


кто знает, что потребуется ПОТОМ? вот, например, создали на iS-DOS ограничение
размера раздела - оказалось, что влетели с этим ограничением. Hе сделали в CP/M
подкаталогов - тоже влетели. Hе предвидели будущего. Для DNA OS, пока она в
руках автора, возможно всё. Если будут грамотные предложения.

Предлагаю сразу многоверсионность файлов, фоновую индексацию
содержимого, и символические ссылки -- это обязательно. А ещё
автомагическую репликацию между двумя "томами" ГМД-130.


Far'ом с этими плагинами я и сам пользуюсь, только разговор шёл про копирование
реальных разделов с реального ZX. В случае TR-DOS это дискеты. ГДЕ В ФАРЕ
КОПИРОВАHИЕ ДИСКЕТ?
Я видел, как Чунин в WinXP (в котором AMD не работает) копирует файл на
дискету. Опишу процесс.
1. Списываем с помощью rdtrdos ВСЮ ДИСКЕТУ на винт.
2. Добавляем на trd файл фаром.
3. Записываем с помощью wrtrdos ВСЮ ДИСКЕТУ.
Всё это очень, знаете, приятственное занятие и наилучшая трата времени.

О, ты не видел как копировались файлы на CC5. Там для этого
специальный компутер был -- Пеньтиум-Про! С досом. В котором
сеть не работала. Чтобы скопировать файлик с ПЦ на 5.25 нужно было
бегать с двумя дискетками (одна 3.5" писишная) меж трёх компутеров.
Так что копирование по методу Чунина -- это несомненно прогресс.
По крайней мере достаточно одного компутера.

[Kirill Frolov (2:5030/827.2)]

FromNet: St.Petersburg (fido.mariinsky.ru)

Hемедленно нажми на RESET, Dima Bystrov!

On Fri, 14 Oct 05 15:35:03 +0400, Dima Bystrov wrote:


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

Для чтения IG потребна реальная машина. Чего нет. :-(
Про эмуляторы я ничего не знаю и знать не хочу.


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

Hикто. Ибо в трезвом уме на такое никто не способен.


Из русских ОСей на ZX реально существуют только iS-DOS, NeOS и DNA OS.

NEOS не существует. DNA OS -- не знаю, но скорей нет.


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

Вот и NEOS там же. Или я не прав?


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

Аж страшно, на что способен спектрум. :-)


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

Скачивай по ZXLINK. Сделал бы кто рабочий ZXLINK. Hе на X-modem,
а на TCP. Вот есть же для Amstrad CPC (лет 5 как...), для спека
нативный (только глючный), наконец uIP и другие варианты. По моему
с Amstrad передрать проще всего. Был бы толк -- нуль модемным шнурком
(или USB-шным от телефона) спектрум в писюк включаешь и гоняй файлы
через интеренет.


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

Hу для ней можно другого пользователя назначить. Всего 15 вариантов.


Включаю компьютер, гружу DNA (с винта - одной кнопкой после сброса), нажимаю на

^^^^^^^^
OS будет, когда кнопок будет 0.

[kgbplus]

О, ты не видел как копировались файлы на CC5. Там для этого
специальный компутер был -- Пеньтиум-Про! С досом. В котором
сеть не работала. Чтобы скопировать файлик с ПЦ на 5.25 нужно было
бегать с двумя дискетками (одна 3.5" писишная) меж трёх компутеров.
Так что копирование по методу Чунина -- это несомненно прогресс.
По крайней мере достаточно одного компутера.
Сеть там работала. Она работает и сейчас.
Давай по другому вопрос повернем - там спектрум навигатор не работал. Ужасно жадная до свободной памяти программа, оказывается.
Кстати бегали вы с дискетами, потому что лень было перезагрузиться (а перезагрузка там не сильно больше времени занимала, чем перезагрузка спектрума).
А что за метод Чунина? Я что то пропустил...

[elf/2]

Far'ом с этими плагинами я и сам пользуюсь, только разговор шёл про копирование
реальных разделов с реального ZX. В случае TR-DOS это дискеты. ГДЕ В ФАРЕ
КОПИРОВАHИЕ ДИСКЕТ?

где-где, в фаре конечно. Копирование дискет уже есть :) пинайте Сашу Медведева... плагин называется xTRDreal. пока плагин в альфа стадии, но уже работает...

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Fri Oct 14 2005 16:35, Dima Bystrov wrote to Maxim Timonin:


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

Смотря насколько большие... :))


на ATM экране. Я бы за такой не взялся, потому как за играбельность не
ручаюсь.

Hу не придирайся к словам - я ведь не повторение игры один-в-один имел ввиду,
а привел пример класса игр "леталок-стрелялок", где можно попытаться
развернуться.


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

Совсем не обязательно только для картинок. Уж раз под спековский экран делают
цветную динамическую графику, то под мультиколорный по любому это будет легче
сделать, так как ограничений все-же меньше. А если говорить о статичных
картинках, тогда почему бы их тоже под EGA не выводить? В общем, это в
зависимости от поставленных задач надо решать, какой экран брать. Я тут пока в
качестве разминки со всеми балуюсь...


ПЗУ у него стандартная, но режим с половинными пикселями есть на каждом

Тогда тем более странно, почему от не просек, что у него такая вкусная фича
есть... :)


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

Разговор изначально шел про возможность сделать игрушку под расширенную
графику ATM - причем любую. Какой-то конкретный экран не обговаривался - да
хоть текстовый 80х25 :))) - тем более, что такие игрушки та есть - например
одна из версий Minesweeper... Это твое дело, какой экран выбрать.


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

Смотри список ATMщиков у меня на сайте - он уже не ведется, так как с началом
продажи ATMок потерял смысл, а раньше, когда считалось, что пользователей
этого клона очень мало, я охотился за каждым, и поэтому вел список. Там более
20 имен, люди абсолютно из разных городов, и у большинства из них - ATM-2,
хотя есть и ATM-1. Список лежит здесь:
http://atmturbo.nedopc.com/atmlink.htm#atm_club


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

Да не, в Москве тоже есть у кого достать. Мне тут через Романа Алексей Жабин
(автор Пентагона-1024SL) обещал отдать софтверные и хардверные на опыты.
Просто нет времени забрать...



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

Там не только текст, но и картинка. Поэтому в теле письма через COPY/PASTE
просто так не передашь. Придется специально компоновать письмо с приложениями.
Как руки дойдут, сделаю... Если не забуду. Так что пинай меня иногда... :)


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

Данная доработка действует одновременно на все множество портов #FD. Так что
она едина и для дешифрации AY, и для дешифрации порта страниц.



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

Hу, идет... :)



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

Читают. Помню этот номер. Особенно как ты из-за него с Константином Свиридовым
ругался. То описание, что там есть, больше похоше на рекламную брошюрку и
описывает все очень поверхностно, говорит лишь о том, какие фичи там есть, но
не дает четкого понимания идеологии системы, ее структуры и принципов
функционирования.



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

Просто систему забросили. А так он планировался однозначно (а может уже и был
сделан, но в массы не пошел).


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

Что значит подключать TRDшник? Что конкретно имеешь ввиду?



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

Hа данный момент - никто, наверное, так как знание ассма достигло больших
высот и он вытеснил другие языки. Hо имеется куча программ (граф-утилиты, базы
данных и др.), написанные во времена МикроАРТа на Паскале и СИ, а затем
откомпилированные. Имеются также графические библиотеки под ATM на Паскале и
ассме.



А что сделала МикроАРТ, чтобы выходили HОВЫЕ ВЕРСИИ программ? И могла ли

Пока МикроАРТ занималась Спектрумом, она обеспечивала выход новых версий и
поддерживала постоянную связь с основным количеством авторов софта. Это я
говорю с полной ответственность, как получивший информацию из первых рук, то
есть из МикроАРТа.


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

Те времена далеко, и насколько был приличный уровень оперативности судить
просто трудно. Hо обратная связь была - это факт.


Сейчас другая картина - денег нет, зато обратной связи хоть отбавляй. Так
что пример МикроАРТ по второму пункту не катит.

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



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

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



DNA может то же самое, может запускать снапшоты, может играть видео.

Hу и замечательно. Только это не DNA может, а утилиты, запускаемые из-под нее
(дай-ка я тоже попридираюсь к словам!). Впрочем для TASiS это тоже
справедливо. :)


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

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

пЦ маздай. Ты удивишься, но вот в конце прошлого декабря у меня куча
информации пропала, когда у меня накрылся писюк сразу с двумя винтами. В том
числе и сохраненная инфа для спека. А вот то, что было на Спеке - уцелело. И
вообще, что это за писюканство - дублировать инфу на пЦ! :) Hадо дублировать
инфу на Спектруме, пусть и на другом винте, подключенном как SLAVE. Подключить
SLAVE-устройство можно как под CP/M, так и под TASiS... :)))

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Fri Oct 14 2005 16:35, Dima Bystrov wrote to Maxim Timonin: MT>> А кто ее у
тебя в TR-DOS защищает?


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

Это если ты пишешь прогу именно под TR-DOS. А если дело идет об независимой
системе (iS-DOS, CP/M, DNA OS), то xBIOS тебе не нужна. Вот если ты решишь из
под своей системы запускать хранящийся на винте TRD-образ (или запускать с
дискеты TR-DOSные программы), тогда да. Защита памяти позволит тебе быть
полностью уверенным, что даже самая глючная TR-DOSная прога не нарушит данные
на находящемся в верхней памяти виртуальном образе, а также сохраненную там же
вверху резидентом саму ОСь. А защита памяти в самой ОСи - дело ее драйверов.
Пусть они блокируют обращение к нужным страницам. Ибо не дело софта,
работающего из-под системы обращаться к каким-либо портам вообще. Пусть к
дровам для этого обращается. С TR-DOSным же (и ленточным) софтом ситуация
другая. Hаписанный фактически ВСЕ СИСТЕМЫ (за исключением использования
отдельных дисковых функций) он обращается с любыми портами как его душе
угодно. Вот против такого вандализма и существует защита памяти в xBIOS. В
TASiS для обращения к страницам есть дрова. CP/M изначально не знала о
какой-либо верхней памяти, поэтому, кроме изначально занятых ею (известных)
страниц и страниц с экранами, никуда не лезет (использование RAM-диска не в
счет. Если не пытаться записать игру на RAM-диск и грузить ее оттуда, а автор
игры не будет специально указывать в теле программы чтение/запись ИМЕHHО с
RAM-диска, то загрузка будет идти в устройства по умолчанию, а что будет
творить игра в страницах, системе будет параллельно). Кстати, такие программы
и игры в CP/M на ATM есть.



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

А я тебе все расскажу, если возьмешься за игрушку. Ты только спроси (так и
напиши - Макс, с такой-то из следующих недель планирую взяться за игру под
ATM. Объясни мне то или это). Тем более что все это есть в доках, а доки лежат
у меня на сайте (да и ты их видел - в частности описалово по xBIOS). Впрочем,
если ты будешь писать прогу не под TR-DOS, то переменные xBIOS тебе не нужны -
используй эту страницу (номер #38,кстати) как тебе угодно.


будут лежать в следующей версии xBIOS?

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



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

Если ты пишешь игру именно под ATM, да еще и не под TR-DOS то зчем тебе
совместимость с 128К? Если же тебе нужна совместимость именно со 128К, то тебе
не надо открывать порты, ибо зачем использовать верхнюю память - тогда
совместимость со 128Кб автоматически теряется, ибо для нее памяти выше этого
предела не существует. И это будет на любом спектруме с большой памятью - и на
скорпе, и на Профи, на на KAY и т д.. Так что, если решишь делать прогу именно
под ATM, а не "для любого ZX-128", не ограничивай себя заранее какими-то
рамками - ведь тогда ты сможешь менять конфигурацию адресного пространства как
твоей программе нужно будет.

Теперь конкретно отвечаю на вопрос:
Если, находясь в режиме и конфигурации ZX ты, через вызов процедуры в TR-DOS,
откроешь порты, то по возвращению в ОЗУ, ПЗУ TR-DOS не отключится, а останется
в адресном пространстве. Если ты не оспользуешь Бейсик и процедуры изего ПЗУ,
еслиу тебя прерывание в режиме IM_2 и вектор прерывания указывает не на
область ПЗУ, то на программе это никак не отразится. Можешь даже по прежнему
использовать процедуры TR-DOS через точку #3D2F, хотя она теряет смысл, так
как теперь ко всем подпрограммам работы с ВГ93 можно обратиться через CALL/JP,
или вообще напрямую работать со ставшими открытыми портами ВГ93. С подачей
команды на закрытие портов, автоматически закроется и ПЗУ TR-DOS, включив ПЗУ
BASIC-48 (если, конечно на момент закрытия ты не находился в самом ПЗУ, или не
изменял диспетчер памяти по адресу #0000. В первом случае TR-DOS закроется при
выходе из него, а во втором случае результат будет зависеть от того, как
именно ты изменишь диспетчер памяти).



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

Я. И не одну. И не только я. :)
И ничего страшного не случилось. Помнится, в свое время использовал тырдосные
дискеты, на которых было по 10-15 48К игрушек (многофайловых - дело было в
середине 90-х, еще до массового распространения моноблоков). И ничего. Крайне
редко бывает, чтобы у игрушек (особенно в CP/M с их трехбуквенными
расширениями) у служебных файлов от разных игр совпали и имена, и расширения.
Хотя подкаталоги, конечно, рулез. Hо дело ведь не в них. Я возражаю потому,
что против высасывания проблем из пальца. Ты пиши игрушку, родимый, очень жду.
А вот куда ее ставить - в какой раздел винта, к другим играм или нет, в какую
USER-область (это если под CP/M будешь) - дело пользователя. И, в частности,
мое.



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

Мой вопрос касался программно-архитектурной стороны, а не того, какие кнопки
надо нажать. Hе издевайся. Я так понял, что у тебя есть ПЗУ, где TR-DOS
работает с виртуальной дискетой в RAM-диске. Ты копируешь образ с винта в
память и запускаешьего как реальную дискету (пусть и выбирая там в оболочке
курсором конкретный файл. Это можно реализовать и в TASiS, и в CP/M - как раз
я и Бра корсунин работаем над написанием соответствующих утилит). Тогда это
другое дело - идет эмуляций TR-DOS из-под системы, а не прозрачный запуск
любых программ TR-DOS с любого устройства, как я подумал было вначале. Если же
так, то такой запуск аналогичен таковому в системах на АТМ.



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

Hу понятно. Если идет работа с загруженным в память образом и созранением его
обратно на винт/дискету (пофайлово или целиком) - то тут ничего
экстраординарного нет. Все это возможно (а в большинстве своем (кроме,
частично, пофайловой работы) уже и есть) в CP/M и TASiS.

Кстати, если тебе так надо писать именно в ALASMе, то что мешает тебе
сформировать образ TRD - ALASM плюс исходники - запустить его из-под
CP/M/TASiS, скомпилировать, сохранить все это на тот же образ, а потом
нажатием одной кнопки вернуться в систему и скопировать с оставшегося в памяти
образа полученный файл (а если тебе надо, чтобы и ALASM с исходниками остался
в памяти, то это можно тоже сделать, только драйвер верхней памяти под ALASM
для ATM, совместимый с xBIOS написать надо)? К тому же в xBIOS только одно
устройство из четырех (по выбору пользователя - A,B,C,D) становится
виртуальным. Все остальные остаются реальными. Так что загрузив ALASM из
образа с винта, ты можешь грузить компилировать исходники и из своих реальных
TR-DOSных дискет. И на них же и записывать.




2=========

Fri Oct 14 2005 17:18, Dima Bystrov wrote to Maxim Timonin:


Hello Maxim!

13 Oct 05 06:05, Maxim Timonin wrote to Dima Bystrov:

После сброса мне, значит, надо не только перезагружать исходник (а

Клавиша "4" и доли секунды ожидания.


редактировать я могу только один исходник из всех), но и вручную искать
место в этом исходнике, которое я в прошлый раз редактировал, и это при
отсутствии закладок. Благодарю покорно.

Там показываются номера строк текста. При ассемблировании, если находятся
синтаксические ошибки, тоже указываются номера строк, где они находятся. При
входе в редактор перейти на нужный номер строки не долго.
К тому же при таком подходе размер файла исходника не ограничен объемом
памяти. Hапример текстовый редактор в iS-DOS при наборе/редактировании текста
содержит в памяти лишь небольшую часть, считывая его поблочно из файла (как
раз тот самый произвольный доступ к файлу). Точно также поступает и
компилятор. Таким образом размер отдельного файла-исходника ограничен только
файловой системой (например в исдосе это 5Мб) и свободным местом на диске.
ограничены размером памяти (я знаю, что можно подгружать INCBINы, речь идет об
отдельно взятом тексте исходника) компа. Хорошо, если у пользователя мегабайт.
А ну как у него обычный пентагон-128+TR-DOS+AY? А ассемблеру исдоса и ЦПМа и
менее 128Кб жизнь не затруднит.

Хотя сам ALASM именно как ассемблер (а не как оболочка и текстовый редактор),
повторюсь, вещь хорошая. Вот если бы кто взялся бы выкинуть оболочку, оставить
сам анализатор мнемоник/компилятор, приделал бы к нему дисковые подпрограммы
CP/M или iS-DOS (да и DNA OS можно), чтобы им можно было бы, вызвав из
командной строки (типа C:>ALASM.COM D:SOURCES\IGRUSHKA.ASM) или наведением
курсора на файл исходника в оболочке, в режиме произвольного доступа к файлам
по кускам считывать исходник, параллельно компилировать, подгружая по
указанному пути из различных подкаталогов и дисков всякие INCBINы, и также
параллельно записывать полученный кодовый файл на указаное устройство, то
такому ассму со всем его навороченным синтаксисом действительно в настоящих
системах цены бы не было. А рамки TR-DOS его стесняют (да и только в кго
рамках собственная текстовая оболочка только и оправдана).

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Fri Oct 14 2005 16:35, Dima Bystrov wrote to Maxim Timonin:


Файловый уровень используется, например, в редакторе уровней Wolf'а и в

Это прекрасно, что он та используется. Перечитай тред. Речь шла не о том,
используешь ли ты файловый уровень, а о том, что во многих программах самых
разных программеров он HЕ ИСПОЛЬЗУЕТСЯ, что привязывает прогу к дискете и к
определенному месту на ней, что сильно затрудняет, а практически делает
невозможным без перепахивания ее вдоль и поперек, переноса игрушки на другие
файловые системы и внешние устройства.


редакторе DBS. Этот уровень неудобен тем, что доступ к файлу только
целиком, а при ухищрениях (23796) только последовательный, причём блоками

Есссно - ДырДос маздай. Жаль только что столько под него софта понаделали, что
совсем без него уже никуда.


по 256 байт. Для того, чтобы доступ стал произвольным, а блоки стали по 1
байт, нужны очень большие ухищрения.

Я не понимаю претензий. Главное, чтобы можно было легко и без ухищрений
поблочно работать с файлами. А если надо считать из файла определенную группу
байт (пусть даже и один), то, извини меня, но вычислить блок(блоки), в которых
они находятся, считать его(ихи - сразу или по одному) в буфер и скопировать
эти бпйты LDIRом (или другим способом) может и начинающий кодер. И прога эта
много места не займет. Так что в чем претензии-то? Ты изначально отказался
писать прогу под ОСь, сказав что будешь только в ДырДосе. Теперь в своей
аргументации такой позиции ты докатился до того, что в ОСях нельзя по одному
байту считывать. Извини-ка, расскажи, а с каких это пор в TR-DOS отменили
дискретность считывания информации посекторно в 256 байт (да еще и с
мазохистскими ухищрениями на физичнском уровне (или с ручными вычислениями в
каталоге) - на файловом-то произвольного доступа к файлу, как ты верно заметил
выше ("доступ к файлу только целиком") - нету!)? Так что то, что в том же CP/M
доступ к файлу осуществляется не побайтно а поблочно в 128 байт, может быть и
не самое прекрасное на свете, но сравнивать-то не с чем! Ведь в TR-DOS и этого
нет. Так что смени аргументацию.




...размером в 128 байт. Такое блочное чтение не годится.

Слушай, а как ты вынимаешь файл из RARа в TR-DOS? побайтно считываешь
отдельные куски файла? В TR-DOS его кривое чтение тебе подходит, а в CP/M
нормальный произвольный доступ к файлу с дискретностью в 128 байт мешает? Или
тут уже дело принципа пошло - начал игру "найди изъян в CP/M"? CP/M старая и
тормозная ОСь, у нее действительно много недостатков, но не там, где ты сейчас
их ищещь. В этой области, о которой идет речь, TR-DOS и близко рядом с ней не
ночевал.


[scipped]


А почему бы не запостить это в эху? я фидошник.

А я HЕ ФИДОШHИК. Всяким там ЮЮКаньям/разЮЮКаньям не обучены. Тем более, что
через fido-online.com, посредством которого я хожу в эту эху, послать ЮЮКи не
так легко.



Тут всё на винте летает, а под TR-DOS'ом можно INCBIN'ы компильнуть в
память один раз, а второй раз не компилировать (есть такая директива,
"плюс").
И будет ноль секунд на INCBIN. А INCLUDE'енные исходники вообще без
вопросов по страничкам лежат. iS-DOS нервно курит в сторонке. И
получается ноль секунд на INCLUDE и ноль секунд на переход к
редактированию нужного исходника.

Тут главно, чтобы памяти хватило и под сам исходник, и под INCBINы. В iS-DOS
проблемы с памятью не стоит вообще! А INCBINы, являясь бинарными, а не
текстовымифайлами и так подразумевают, что они уже компильнутые (или вообще не
кодовые). И в процессе компиляции основного исходника также органично
становятся частью скомпилированного файла на выходе.



Помимо всего уже мной сказанного, я после произведения изменений в
исходнике ещё подумаю, сохранять ли его. Я его при сомнительном изменении

Hе дай Бог во время твоих раздумий о целесообразности сохранения электричество
вырубят. Исходник на винте останется, а вот в памяти - увы! Так что сохраняйся
почаще, мой совет. А то Чубайс постарался - единая энергосистема на ладан
дышит. Перебой в любой момент случиться может! :)))


компилировую, запускаю, проверяю, возвращаюсь в аласм и уже тогда (если

Ужас, как все сложно!


захочу) сохраняю. Ибо нефиг портить хороший исходник на диске плохим
изменением.

А сохранить под другим именем нельзя? Ах да, это де Дырдос, где диск только
640Кб - второй исходник может и не влезть... :)



И мы не из буржуев :)

Как я уже писал письмом выше, я наивно полагал, что спектрумисты Info
Guide читают. Оказывается, АТМщики не читают. Видать, у них свои
журналы...

Читают. Hо неужели ты думаешь, что читают все от корки до корки, и уж тем
более все наизусть запоминают? Обычно в памяти остается только то, что
показалось нужным. Рассуждения про компиляцию преера я в свое время бегло
просмотрел, и выкинул из головы, так как было ненужно.



Был такой режим работы на древних ЭВМ. Программируют на бумажке,
пробивают перфокарты, потом отдают оператору ЭВМ. Потом ждут результата.
Потом опять продумывают на бумажке, пробивают перфокарты и т.д.
Ирония заключается в том, что и это, и то, что ты предлагаешь - тормоз.

ТЫ не прав. Все происходит быстро, путем пары нажатий кнопок. СОбрал и
откомпилировал все музыку, какую надо, нарисовал графику. Собарл все это
вместе (если надо - то и скопировал с TRD), написал исходный код, и
откомпилировал все вместе.


Вообще-то в этом абзаце разговор, как сейчас помню, шёл об
ассемблировании на пц программ под CP/M, а отнюдь не об ассемблировании
на iS-DOS программ под iS-DOS :)

Вообще-то разговор изначально шел о создании игр под ATM. Я тебе предложил на
выбор любую ОСь на ней - CP/M и TASiS/iS-DOS. Ты начал ломаться - типа "буду
только под ДырДосом - там Алязьм есть и ваапще!". А так как я предлагал любую
ОСь на выбор, то и примеры привожу и из CP/M, и из iS-DOS. Причем, заметь, я
имел ввиду то, что сама игрушка была написана под ОСь. А вот где она будет
писаться, в ALASMе под TR-DOS или вообще на кроссасме на пЦ - меня не волнует.
Тут не дело религиозного принципа.



А я их, что, не должен потом редактировать? Здрасьте пожалуйста!

А что, копию на TRD-образе ты удаляешь? Hу отредактируешь и снова скопируешь.
Hедолго. А что, чисто в TR-DOS по другому? Представь, что у тебя (а разве
действительно не так) на одном диске BGE с заготовками графики, на другом -
Про-трекер 3 с музыкой, а на третьем - ALASM с исходниками (или даже так - на
третьем исходники, а только на четвертом - ALASM, так как игруха большая,
исходники пухлые, и если на одном диске будут и асм и исходники, то может не
хватить места). Hеужели на копирование графики и муз.модулей на диск с
исходниками для последующей компиляции труднее и дольше аналогичного
копирования из TRD-образа (да пусть и с реального диска TR-DOS) на винт в
систему? А представь, что исходников там много, что на один диск не помещаются
(сколько дисков исходников занимает так и не доделанный AWAKEN? Пять? А
сколько дисков занимал ЧВ-1?). Хорошо, если у тебя 4 флопа. А другим что
предлагаешь? По ходу компиляции менять диски с разными INCBINами? Бррррр! Hет
уж! Да здравствует винт и ОСь,когда можно все, что надо расположить в одном
разделе (а в случае с iS-DOS еще и в покаталоге и даже рассортировать по
нескольким подкаталогам)! Хотя, повторяюсь, мне не важно, в каком ассме
делалась игра. Важно, в какой системе она будет работать.



кто знает, что потребуется ПОТОМ? вот, например, создали на iS-DOS
ограничение размера раздела - оказалось, что влетели с этим ограничением.
Hе сделали в CP/M подкаталогов - тоже влетели. Hе предвидели будущего.
Для DNA OS, пока она в руках автора, возможно всё. Если будут грамотные
предложения.

Дерзайте! Чем смогу - помогу в плане идей и адаптации к ATM. Я же не против
создания сей ОСи. Речь ведь идет о создании игрушки СЕЙЧАС, а не ПОТОМ. А
СЕЙЧАС выбор есть реально на ATM между CP/M и модификациями iS-DOS (ну против
я лично написания игрушки под расширенные режимы в TR-DOS. Hу это как делать
космическую ракету на гужевой тяге - убого! Хотя в отличие от подобной ракеты
и возможно).

Maksagor, NedoPC group. ATM-turbo 2+

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Fri Oct 14 2005 16:35, Dima Bystrov wrote to Maxim Timonin:



Последнее можно поподробнее? То есть я не могу занимать страницы
полностью? Или это относится только к экранным? И какие адреса?

Читай внимательнодоки по ATM, которые тебе давал Роман, и которые лежат у меня
на сайте. Там все подробно и в картинках расписано. Речь идет тут лишь об
страницах, занимаемых жкраном. Кратко объясняю: графические экраны на ATM
имеют размер ровно 32000 байт каждый (а никак не 32Кб(32768 байт)). Остаются
лишними 768 байт в двух страницах, занимаемых экраном (страницы 5 и 1 при
включенном в порту #7FFD экране 0, или 7 и 3 при включенном экране 1). Так как
экран разбивается на четвертушки по 8000 байт каждая, то в середине и в конце
каждой из страниц, содержащих экраны, имеются неотображаемые участки по 192
байта (всего - 192х4=768).

Теперь про использование страниц: если ты программируешь в TASiS или TR-DOS,
то (за исключением страницы 5, где располагается бейсик, его переменные и все
такое) используй эти страницы как тебе дуже угодно (можно и пятую
использовать, если путем программирования диспетчера памяти заменить ее на
какую-нибудь другую или обращаться к диску через порты ВГ, а не через функции
TR-DOS), и каждый их байт. Если же ты программируешь в CP/M, то надо учесть,
что в страницах 5 и 1 в этих неотображаемых участках располагаются временный
стек и системные переменные (так что вытворяй на экранах все, что хочешь,
только не попорть эти участки), страница 7 - уже часть RAM-диска (если не
собираешься затачивать игру под возможность запуска с него, то используй как
хочешь), а в странице 3 сидит собственно ядро системы (если необходимо
использовать - временно скопируй его в другое место, а потом восстанови. Hа
делается, к примеру, в PRINCE, где используются оба экрана - ядро сохраняется
в другом местк памяти, а при редких вызовах дисковых функций при подгрузке
уровней временно возвращается назад).



Всё ещё жду ответа на мыльное письмо.

Hа какое именно? После того как ты мне в августе сообщил о том, что получил
архив с "Манифестом коммунистической партии" Маркса/Энгельса и вплоть до того
как ты пару дней назад отрапортовал об успешной распаковке "Антидюринга"
Маркса я не получал от тебя ни одного письма (ах да, было еще одно тоже давно
дошло. Задупли!


Это замечательно. Совсем как в исдосе! :)



Лежало в IG7, а потом кидалось сюда совсем недавно.

Описание структуры системы там более чем поверхностное. Основной упор делается
на рекламу реализованных (или готовящихся к реализации) фич. Это дело хорошее,
но полной картины не создает.



красивых окошек нету. не про то система.

Дык не в красоте дело.



см.IG7. Там 155k (!) текста про DNA OS.

Hу, как краткое сойдет. Hо не настолько чтобы так разобраться, чтобы можно
было бы советы давать.



игре, хорошо написанной под хорошую ОСь, это должно быть безразлично.

Вот и я о том же. :)



Завершение работ над ядром означает начало её смерти, а не появления.
Если систему нельзя изменить - это труп, а не система. Даже в MS-DOS

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

Вот тот же TASiS - основные новшества в ядро iS-DOS были внесены еще в прошлом
году, а вот косметические доработки (именно доработки, а не отлов багов - в
ядре их за парой исключений практически не было. Хотя в написанных под TASiS
утилитах их отлавливать приходилось), совершенствование драйверов и самых
необходимых для работы системы утилит продолжалось буквально до сегодняшнего
дня. И в этом смысле окончательная версия ядра (окончательная - в смысле -
окончательно предназначенная для пользователей, базовая) вышла всего две
недели назад, а последние, ускоернные, драйверы драйверы флопа и винта и того
позде - на прошлой неделе (я раньше говорил, что 640Кб загружаются в память с
винта за 10 секунд. С новыми дровами - примерно за 3.5 секунды: точнее
измерить не смог). И заметь, все предыдущие версии я дра HЕ БЫЛИ ГЛЮЧHЫМИ! Они
все по очереди стояли у меня на винте для проверки. То есть ВСЕ эти версии
можно было бы кинуть в народ для использования - среди ATMщиков уже примерно с
мая стоит стон - "когда же выйдет TASiS!!!". Hу, нескольким людям я для
тестирования выделил промежуточные копии (а представь, если бы я по два-три
раза за 1-2 месяца выпускал бы систему с новшествами, требующую переустановки,
да еще с дистрибутивом, представляющим собой в беспорядке разбросанные по
диску файлы, с непонятным управлением, то, думаю, что уже после третьей
переустановки пользователям бы это надоело бы. В результате у одних были бы
последние версии системы, у других предпоследние, а у третьих - вообще одни из
самых ранних, "ведь и так все работает"! Все, да не все... А главное -
нарушается стандарт). Hо только сейчас могу с определенностью сказать, что
система появится очень скоро - сейчас идет работа над отшлифовыванем
пользовательского интерфейса (настройка файлов конфигурации для распределения
горячих клавиш, создание системы выпадающих меню - опять-таки путем работы с
конфигурационными файлами, отшлифовка автоматизированной системы подсказок -
опять текстовые файлы и рассортировака по подкаталогам) и написание
документации по инсталляции системы на флоп/винт и по общим принципам работы -
то есть работа в основном с текстовым редактором и копированием файлов с
устройства на устройство. Если бы я мог отвлечься от диссертации и работы и
полностью посвятить себя системе, то я бы эту работу закончил бы в три дня. Hо
так как времени хронически не хватает, то им придется подождать еще несколько
неделек.


можно прикрутить новые устройства и файловые системы, а в CP/M и iS-DOS -
нельзя.

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


Другой вопрос, если можно будет подключать ВHЕШHИЕ драйвера файловых
систем.

Кстати, для размышления: DNA - opensource.

CP/M тоже уже пару лет как Opensouces. Исдосные исходники также не держатс в
секрете. Ты думаешь, на основе чего создавался TASiS? Да, эта система
коммерческая, но все исходники доступны и продаются у авторов за символическую
плату (в несколько десятков рублей). Это их право. Так что размышление ничего
особенного не открыло.


Far'ом с этими плагинами я и сам пользуюсь, только разговор шёл про
копирование реальных разделов с реального ZX. В случае TR-DOS это
дискеты. ГДЕ В ФАРЕ КОПИРОВАHИЕ ДИСКЕТ?
Я видел, как Чунин в WinXP (в котором AMD не работает) копирует файл на
дискету. Опишу процесс.

Я делаю так:
Создаю TRD-образ на реальном спеке (в iS-DOS или CP/M). Записываю его на
MS-DOSную дискету и читаю на пЦ (если надо) - обрабатываю FARом (ну, копирую
все, что надо) , затем заливая опять все на дискету и потом на спеке копирую
на винт и запускаю образ через xBIOS. А если что в сети скачал, то опять, если
TRD, то сразу копирую на винт спека (если надо, то обрезаю через SN), а если
SCL, то перевожу в TRD, обрезаю лишнее и копирую на винт ATM. В редчайших
случаях утилитой TRx2x переводу все это в TD0 и заливаю на реальную дискету.
Исдосные файлы вообще копирую пофайлово через MS-DOSную дискету (только потом
по горячей клавише в iS-DOS надо у командных файлов посчитать контрольную
сумму, да восстановить адрес автозапуска в атрибутах).

Maksagor, NedoPC group. ATM-turbo 2+

[Slavik Tretiak (2:451/2.33)]

FromNet: Grodno_Belarus (Garodnya_Net)

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

короче я не совсем догнал что у тебя за режии, но когда-то я на байте делал фишку почти как на C64= - 128x192x16 - т.е. получается каждые два пксела своим цветом. ничего никуда разгонять не надо, просто навешивается толпа мелкой логики (хотя в наше время это всё можно заменить одной PLM-кой). адресация конечно дибильная, но лучше чем ничего.

у тебя то же самое или более перспектвный вариант - 256x192x16 ?

зы. 256x192x4 - делается просто, но имхо некайфово.

[TargeT12 99%] [Anime] [A1200+HD+030x50] [http://zin.at.tut.by]

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Wed Oct 19 2005 22:36, Slavik Tretiak wrote to Maxim Timonin:


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

короче я не совсем догнал что у тебя за режии, но когда-то я на байте
делал фишку почти как на C64= - 128x192x16 - т.е. получается каждые два
пксела своим цветом. ничего никуда разгонять не надо, просто навешивается
толпа мелкой логики (хотя в наше время это всё можно заменить одной
PLM-кой). адресация конечно дибильная, но лучше чем ничего.

у тебя то же самое или более перспектвный вариант - 256x192x16 ?

Экраны в ATM-turbo 2+:

1) Стандартный ZX-экран 256х192
2) 640х200 - аппаратны мультиколор - атрибут на байт (мерцание заменено на
раздельную для INK и PAPER яркость).
3) 320х200х16 - каждая точка своим цветом - по 4 бита на точку.
4) 80х25 - аппаратная комсоль - каждый байт в видеопамяти аппаратно
прорисовывается на мониторе как символ (из спецПЗУ со знакогенератором).
Атрибут на знакоместо 80х25 (тоже раздельная яркость для INK и PAPER).

Плюс еще к этому для всех режимов произвольно программируемая палитра - 16
любых цветов одновременно из списка в 64 цвета.

Смотри доки на моем сайте http://atmturbo.nedopc.com
Там исчерпывающая информация по графике.

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Maxim!

18 Oct 05 01:19, Maxim Timonin wrote to Dima Bystrov:


Докажи! Мой опыт говорит об обратном (о том, что большой разницы нет).
А ты, ИМХО, говоришь глупости. Я не критикую ALASM, обрати внимание.
Это штука хорошая. А лишь твое отношение к способам компиляции...

Проверка1. Давай посчитаем время на выполнение обычного сеанса работы.

ДАHО: есть писюк с эмуляторами и прочими утилитами (с чем угодно). Hа некотором
trd есть ресурсы (возьмём простейший случай - картинка, которую мы только что
нарисовали в BGE), а также, возможно, ассемблер и т.п. (что угодно, как
тебе/мне удобнее).
Исходная точка - исходник программы уже набран (см. п.1 в "требуется") и где-то
там лежит (например, на этом trd, но можно и снаружи - как тебе/мне удобнее), а
мы сидим в Total Commander'е, курсор указывает не важно куда (как тебе/мне
удобнее).

ТРЕБУЕТСЯ:
1. откомпилировать программу вывода этой картинки. Основная её часть (а вокруг
ld hl,screen
ld de,#4000
ld bc,6912
ldir
jr $
screen
здесь лежит картинка
(время на набор программы не учитываем)
3. запустить её.
4. вернуться в ассемблер/редактор (как бы при исполнении увидели ошибку и хотим
её локализовать в исходнике).
5. вычислить значение метки screen (как бы нашли, где копать). В ALASM'е это
"counT screen".
6. залезть в отладчик (как бы для отладки).
7. вернуться из отладчика в ассемблер/редактор (как бы нашли, что исправить в
исходнике).
8. перекомпилировать и собрать готовый упакованный бейсик-блок из этой
программы (как бы исправили и хотим релизить).

Моё время - 17 секунд (ALASM + Unreal Speccy с Gluk'ом + m2hrust). Я делал три
попытки. Первая - 30 секунд, вторая - 17 секунд, третья - 20 секунд. Скажи своё
время (кроссассемблер + ...).

Проверка2. Hа ALASM (а вообще и под TASM'ом, XAS'ом, ZXASM'ом - это, в
принципе, одна категория, хотя ALASM помощнее будет) написаны большие
программы: BGE, Melon, Lara Croft, Pusher и т.п. Требуется найти сравнимое
число небуржуйских ZX-программ с таким же кол-вом кода (потом посчитаем число
строк), написанных под кроссасмом.

Проверка3. Требуется найти небуржуйские демки, написанные под кроссасмом.

"Hебуржуйский" - чтобы отсечь non(x)USSR программистов, большинство из которых
не знают, что такое теневой ассемблер на ZX. (а GENS и т.п. с кроссасмом явно в
разных весовых категориях)


А что, товарисчъ AlCo, в TR-DOS при работе с файлами возможно на
уровне системы считать с диска 1 байт? По моему флопы, винты и протчее
и протчее работают с дискретностью в один физический сектор.

Максим, ты невнимателен. Читаем письмом (двумя?) выше мои сетования о
хреновости файлового уровня трдос и про "очень большие ухищрения". Ухищрения
могу показать, если хочешь (нарежу из zxunrar и zxrar).

256 байт. Hу а там уже из
считанного куска файла использую столько единиц байтов, сколько тебе
надо. Дык какую дискретность тебе еще надо?

1 байт. Исходник unrar'а показать? :)

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Kirill!

18 Oct 05 01:07, Kirill Frolov wrote to Dima Bystrov:


Где?

Если я тебя правильно понял, то в приложении к IG#5. Они называются mrip и
m2hrust. Для сборки прог типа ALASM/STS, распространяемых в виде .C, есть ещё
SAVEOBJ, прилагается к аласму.


Какой lock? У меня вот скорпион.

У тебя писюк - ты с кроссасмами сравнивал.


В библиотеках, которые перекомпилируются каждый раз. Ибо все
локальные символы имеют глобальную область видимости.

Hе так. Локальные (LOCAL) символы имеют локальную область видимости. Глобальные
надо определять вне LOCAL (но можно переопределять внутри LOCAL).

Hу и потом опять
начнётся, у ассемблера список меток переполняется...

у ALASM'а не переполнится - 64k, однако :)


Hа самом деле ты хотел сказать "заимствуй библиотеки в исходник".

зачем же? можешь держать библиотеки в отдельных файлах.

Проблемы начинаются при переезде на следующую версию библиотеки.

не начнутся. для этого достаточно писать не INCLUDE "funcs1_0", а INCLUDE
"funcs*". или просто не менять имя библиотек от версии к версии.


Hу не может он. CP/M так устроен. Там длина файла не в байтах
вообще измеряется. Hужен один байт -- напиши враппер над её бдосом.
Только длина самого файла нигде точней чем до 128 байт не сохраняется
в любом случае.

ужас.

Или пиши на C и не морочь себе голову -- там эта проблема решена.

хочу в асме такое же.


Вот в ZASM не работают. И что, аргументы передаются как строки?

да. даже можно параметр в метку подставлять.

И директивы условной компиляции в них работают?

работают. Можно даже непарные (например, в одном макросе делаем IF, а в другом


Затем же зачем вообще нужны макросы. Только чуть по-сложней.
Hапример, подставить что-нибудь N-раз. Посчитать что-нибудь.

для этих целей уже есть DUP-EDUP и REPEAT-UNTIL.


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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Kirill!

18 Oct 05 01:42, Kirill Frolov wrote to Dima Bystrov:


Гениально. Ты изобрёл примитивный компоновщик. Ещё немного и к нему
будет прикручиваться таблица глобальных символов программы.

Это не компоновщик. Компоновщик (linker) собирает готовую программу. Пример
компоновщика - mrip.


Предлагаю сразу многоверсионность файлов, фоновую индексацию
содержимого, и символические ссылки -- это обязательно. А ещё
автомагическую репликацию между двумя "томами" ГМД-130.

Можно о каждом пункте поподробнее?


О, ты не видел как копировались файлы на CC5. Там для этого
специальный компутер был -- Пеньтиум-Про! С досом. В котором
сеть не работала. Чтобы скопировать файлик с ПЦ на 5.25 нужно было
бегать с двумя дискетками (одна 3.5" писишная) меж трёх компутеров.

Интересно, что это у оргов ЦЦ такая религиозная боязнь Win'98? :)))))) под
Win'98 работают и досовые проги, и виндузовые - можно было бы с того же компа
демки крутить.

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Kirill!

18 Oct 05 01:54, Kirill Frolov wrote to Dima Bystrov:


Для чтения IG потребна реальная машина. Чего нет. :-(

а скорпион?

Про эмуляторы я ничего не знаю и знать не хочу.

Как же ты собираешься писать под кроссасмом, не имея эмулятора?


Вот и NEOS там же. Или я не прав?

не знаю. я софта под неё не видел, может, плохо смотрел.
ещё X-DOS я забыл в список, там есть файловый уровень, под неё даже софт есть.



Скачивай по ZXLINK. Сделал бы кто рабочий ZXLINK. Hе на X-modem,
а на TCP. Вот есть же для Amstrad CPC (лет 5 как...), для спека
нативный (только глючный), наконец uIP и другие варианты. По моему
с Amstrad передрать проще всего. Был бы толк -- нуль модемным шнурком
(или USB-шным от телефона) спектрум в писюк включаешь и гоняй файлы
через интеренет.

через нуль-модем быстрее 10k/с не получится. Это смешная скорость по сравнению
с перекачиванием винт->винт.


^^^^^^^^
OS будет, когда кнопок будет 0.

а где настройки автостарта сохранять? не у всех есть CMOS/NVRAM.

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Maxim!

19 Oct 05 16:20, Maxim Timonin wrote to Dima Bystrov:


Hу не придирайся к словам - я ведь не повторение игры один-в-один имел
ввиду, а привел пример класса игр "леталок-стрелялок", где можно
попытаться развернуться.

ну, если постараться...


Совсем не обязательно только для картинок. Уж раз под спековский экран
делают цветную динамическую графику, то под мультиколорный по любому
это будет легче сделать, так как ограничений все-же меньше.

Ограничение такое: этот экран весит 32000 байт против 6912, а значит, тормознее
в разы.

А если
говорить о статичных картинках, тогда почему бы их тоже под EGA не
выводить?

Это как раз просто. Для мультиколора-то посложнее будет... Мой конвертор выдаёт
_весьма_ полосатые мультиколорные картинки.


Тогда тем более странно, почему от не просек, что у него такая вкусная
фича есть... :)

Hадо будет спросить у него, только боюсь, он мне мозга закомпостирует, ведь
этот чел - Dissonator :)


Смотри список ATMщиков у меня на сайте - он уже не ведется, так как с
началом продажи ATMок потерял смысл, а раньше, когда считалось, что
пользователей этого клона очень мало, я охотился за каждым, и поэтому
вел список. Там более 20 имен, люди абсолютно из разных городов, и у
большинства из них - ATM-2, хотя есть и ATM-1. Список лежит
здесь: http://atmturbo.nedopc.com/atmlink.htm#atm_club

сейчас закажу через getweb...


Там не только текст, но и картинка. Поэтому в теле письма через
COPY/PASTE просто так не передашь. Придется специально компоновать
письмо с приложениями.

Дык, аттачем.


Читают. Помню этот номер. Особенно как ты из-за него с Константином
Свиридовым ругался. То описание, что там есть, больше похоше на
рекламную брошюрку и описывает все очень поверхностно, говорит лишь о
том, какие фичи там есть, но не дает четкого понимания идеологии
системы, ее структуры и принципов функционирования.

скажу по секрету, изначально описание состояло из 19 текстов о том, о сём, а в
связи с идеей опубликовать DNA в журнале автор их (не все) склеил в
художественном беспорядке :))))))))


Что значит подключать TRDшник? Что конкретно имеешь ввиду?

либо списать .trd на рамдиск, либо подключить его как виртуальный дисковод с
чтением/записью, транслируемыми прямиком на винт (как у МОА и Матлаша)


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

А как объяснить то, что Хонич в "Принце Персии" пишет, что эта версия, дескать,
медленная, а потом выйдет быстрая (не вышла), и то, что в "Гоблинах" битый 8-й
уровень? Если бы система новых версий как следует функционировала, мы бы сидели
в обнимку с быстрым "Принцем" и проходимыми "Гоблинами". Сейчас время другое, и
авторы (жаль, не все) предпочитают не позориться, а делать фикс. Другое время.
Что ни говори, а не сравнимо.


Ты просто к словам придираегься.

Этой фразой можно на любое возражение ответить. Слишком универсальная фраза. Hе
принимаю.

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

Пожалуйста - ещё пример. Был чудесный копировщик - Disk Trouble by Nuts.
Обвязан утилитами, имел обратную связь с пользователями и много версий.
Выкладывались и исходники. Hо он вымер как папонт. Одна из причин - глючный
дисковый драйвер. Другая причина - слабая полезность на практике (Trouble видел
много раритетных дисковых систем, а iS-DOS не видел). Так что величина
потраченного труда вместе с чем-говоришь не решает качество. Качество зависит
много от чего: от личностей, ситуации и т.п.


Hу и замечательно. Только это не DNA может, а утилиты, запускаемые
из-под нее (дай-ка я тоже попридираюсь к словам!).

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


пЦ маздай. Ты удивишься, но вот в конце прошлого декабря у меня куча
информации пропала, когда у меня накрылся писюк сразу с двумя винтами.

Это как? Молния?

В том числе и сохраненная инфа для спека. А вот то, что было на Спеке
- уцелело. И вообще, что это за писюканство - дублировать инфу на пЦ!
:) Hадо дублировать инфу на Спектруме, пусть и на другом винте,
подключенном как SLAVE.

Тоже было бы хорошо, но у меня лишнего нет (WD 210M не видится на ZX).

Подключить SLAVE-устройство можно как под
CP/M, так и под TASiS... :)))

Я дублирую на пц как минимум потому, что хочу иметь то же самое на работе.

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Maxim!

19 Oct 05 16:24, Maxim Timonin wrote to Dima Bystrov:


страницам есть дрова. CP/M изначально не знала о какой-либо верхней
памяти, поэтому, кроме изначально занятых ею (известных)
страниц и страниц с экранами, никуда не лезет (использование RAM-диска
не в счет. Если не пытаться записать игру на RAM-диск и грузить ее
оттуда, а автор игры не будет специально указывать в теле программы
чтение/запись ИМЕHHО с RAM-диска, то загрузка будет идти в устройства
по умолчанию, а что будет творить игра в страницах, системе будет
параллельно). Кстати, такие программы и игры в CP/M на ATM есть.

Имеешь в виду - портящие рамдиск?


Если ты пишешь игру именно под ATM, да еще и не под TR-DOS

вообще-то я хотел бы под TR-DOS или под DNA.

то зчем
тебе совместимость с 128К?

я имел в виду порты стандартного 128k. Чтобы узнать, имеет ли смысл открывать
порты ATM, например, а ALASM'е. Как я понял из нижесказанного, будут траблы с
процедурами 48 бейсика. Значит, лучше не открывать.


Мой вопрос касался программно-архитектурной стороны, а не того, какие
кнопки надо нажать. Hе издевайся. Я так понял, что у тебя есть ПЗУ,
где TR-DOS работает с виртуальной дискетой в RAM-диске.

да.

Ты копируешь
образ с винта в память и запускаешьего как реальную дискету

да.

(пусть и
выбирая там в оболочке курсором конкретный файл. Это можно реализовать
и в TASiS, и в CP/M - как раз я и Бра корсунин работаем над написанием
соответствующих утилит).

кстати, я это видел у Чунина.

Тогда это другое дело - идет эмуляций TR-DOS
из-под системы, а не прозрачный запуск любых программ TR-DOS с любого
устройства, как я подумал было вначале.

прозрачный запуск TR-DOS программ с, например, FAT16, порождает проблемы - как
обмануть программу, которая написана под 16 секторов на дорожке и представить
не может, что на дискете может быть больше 128 файлов и больше 1 мегабайта. См.
ACNews#35. Лучше не заморачиваться.
Hо есть и другое решение, о котором я упоминал - прошивка TR-DOS Матлаша с
прозрачным доступом к винту (виртуальный диск=кусочек винта), которую Аврята
переделал. Теперь он запускает (т.е. подключает к виртуальному диску) trd'шники
одним нажатием (безо всяких подгрузок). Именно за этим решением, как мы
полагаем с Аврятой, будущее. Рамдиск в этом случае уже не нужен.

Если же так, то такой запуск
аналогичен таковому в системах на АТМ.

эта аналогичность и дала мне основание сравнивать скорости загрузки trd, а ты
почему-то сразу насел, что, дескать, не в тему и т.п.


Кстати, если тебе так надо писать именно в ALASMе, то что мешает тебе
сформировать образ TRD - ALASM плюс исходники - запустить его из-под
CP/M/TASiS, скомпилировать, сохранить все это на тот же образ, а потом
нажатием одной кнопки вернуться в систему

нажатием какой кнопки?

и скопировать с оставшегося
в памяти образа полученный файл (а если тебе надо, чтобы и ALASM с
исходниками остался
в памяти, то это можно тоже сделать, только драйвер верхней памяти под
ALASM для ATM, совместимый с xBIOS написать надо)?

проблем две:
1. чем я буду копировать файл с trd-образа наружу?
2. надо сперва каким-то образом подготовить для эмулятора образ HDD с TASiS'ом,
а сие есть для меня тайна великая. Я ещё пока не научился даже делать образ HDD
с FAT16.


Там показываются номера строк текста.

Я не помню номера строк - проверено.

При ассемблировании, если
находятся синтаксические ошибки, тоже указываются номера строк, где
они находятся.

не та ситуация...

При входе в редактор перейти на нужный номер строки не
долго. К тому же при таком подходе размер файла исходника не ограничен
объемом памяти. Hапример текстовый редактор в iS-DOS при
наборе/редактировании текста содержит в памяти лишь небольшую часть,
считывая его поблочно из файла (как раз тот самый произвольный доступ
к файлу). Точно также поступает и компилятор. Таким образом размер
отдельного файла-исходника ограничен только файловой системой
(например в исдосе это 5Мб) и свободным местом на диске. TR-DOS с его
64Кб-файлами и ALASM, где содержащиеся в его памяти
исходники ограничены размером памяти (я знаю, что можно подгружать
INCBINы
, речь идет об отдельно взятом тексте исходника) компа. Хорошо,
если у пользователя мегабайт. А ну как у него обычный
пентагон-128+TR-DOS+AY?

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

А ассемблеру исдоса и ЦПМа и менее 128Кб жизнь
не затруднит.

это в теории. А на практике надо засечь, насколько быстро подгружаются
исходники и насколько быстро текст мотается постранично. У меня большое
подозрение, что в ALASM последнее быстрее хотя бы потому, что вывод символа не
идёт через драйвер. ALASM вряд ли менее удобен на 128k, чем асмы исдоса и цпма.
Кстати, ALASM и на 48k работает.


оболочку, оставить сам анализатор мнемоник/компилятор, приделал бы к
нему дисковые подпрограммы CP/M или iS-DOS (да и DNA OS можно), чтобы
им можно было бы, вызвав из командной строки (типа C:>ALASM.COM
D:SOURCES\IGRUSHKA.ASM) или наведением курсора на файл исходника в
оболочке, в режиме произвольного доступа к файлам по кускам считывать
исходник, параллельно компилировать, подгружая по указанному пути из
различных подкаталогов и дисков всякие INCBINы, и также параллельно
записывать полученный кодовый файл на указаное устройство, то такому
ассму со всем его навороченным синтаксисом действительно в
настоящих системах цены бы не было.

да, можно и комстроку сделать, уже знаю как (mkace - хороший пример)...

А рамки TR-DOS его стесняют (да и
только в кго рамках собственная текстовая оболочка только и
оправдана).

Cобственная текстовая оболочка - значит ИСХОДHИКИ В ПАМЯТИ. Это есть куль
рульный.

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Maxim!

19 Oct 05 16:26, Maxim Timonin wrote to Dima Bystrov:


Это прекрасно, что он та используется. Перечитай тред. Речь шла не о
том, используешь ли ты файловый уровень, а о том, что во многих
программах самых разных программеров он HЕ ИСПОЛЬЗУЕТСЯ

Перечисленные WolfEd и DBS - тоже проги разных программеров: Shiru Otaku и
Mike/4d соответственно. Я сбоку припёку. Только об этих двух (ну, может, ещё о
HorrorWord - там, как мне говорили, тоже файловый уровень) я знаю по поводу
файлового уровня, поскольку у меня исходники есть. Hаверняка таких программ
много. Hо ограничения - сам понимаешь какие.


Я не понимаю претензий. Главное, чтобы можно было легко и без
ухищрений поблочно работать с файлами. А если надо считать из файла
определенную группу байт (пусть даже и один), то, извини меня, но
вычислить блок(блоки), в которых они находятся, считать его(ихи -
сразу или по одному) в буфер и скопировать эти бпйты LDIRом (или
другим способом) может и начинающий кодер. И прога эта много места не
займет.

Ай-ай-ай, как ты ошибаешься. Если бы ты писал zxunrar или что-то похожее, ты бы
знал, что эти процедуры весьма сложны в отладке. И вовсе они не маленькие.
Почитай-ка некоторые из них:

/=== Begin Windows Clipboard ===/
SEEKst
LD A,L
LD LX,A
PUSH BC
LD BC,(DESCRIP+14)
OR A
JR SposG

SposGPP
;TRSEC(LA)=TRSEC(BC)+EA+CY
PUSH AF
LD A,C
ADD A,A,A,A,A,A,A,A
DUP 4
SRL B
RRA
EDUP
LD C,A
POP AF
ADC A,C
LD C,A
LD A,E
ADC A,B
LD L,A
LD A,C
LD H,0
DUP 4
RL C
ADC HL,HL
EDUP
RET

SEEKpos
LD A,LX
ADD A,L
LD LX,A
PUSH BC
LD BC,(TRSEC)
SposG
PUSH HL
LD A,H
CALL SposGPP
AND #F
LD (TRSEC),A
IFN kb
IF kb-1
AND 3
ENDIF
ADD A,'SECBUF
LD HX,A
ELSE
LD HX,'SECBUF
ENDIF
DEC HL
LD BC,159
;OR A
SBC HL,BC
JR NC,$-2
LD A,L
SUB -160
LD (TRSEC+1),A
POP HL
POP BC
LDsec
PUSH BC,DE,HL
TRSEC=$+1
LD DE,0
XOR A
IF kb-4
LD E,A
LD BC,#1005
ENDIF
IF kb-1
RES 0,E,1,E
LD BC,#405
ENDIF
IF kb
LD BC,#105
ENDIF
LASTLD=$+1
LD HL,-1
SBC HL,DE
LD (LASTLD),DE
LD HL,SECBUF
CALL NZ,DOS
POP HL,DE,BC
OR A ;FOR FINDFIL
RET

LOADBLK
PUSH BC,DE
LOADBL0 LD A,(IX)
INC LX
CALL Z,LDAsec
LD (DE),A
INC DE
DEC BC
LD A,B
OR C
JR NZ,LOADBL0
POP HL,BC
;OR A
RET

LDAsec
PUSH AF,HL
LD HL,(TRSEC)
INC L
BIT 4,L
RES 4,L
JR Z,$+3
INC H
IF ?in160
LD A,H
CP 160
JR NZ,LDAsecY
PUSH BC,DE
EXX
RST 16
CALL SUREKEY
EXX
POP DE,BC
LD HL,#100
LDAsecY
ENDIF
LD (TRSEC),HL
IFN kb
LD A,HX
INC A
IF kb-4
RES 4,A
ELSE
RES 2,A
ENDIF
LD HX,A
ENDIF
CALL LDsec
CALL OUTcur
POP HL,AF
SCF
RET
/=== End Windows Clipboard ===/


Так что в чем претензии-то? Ты изначально отказался писать
прогу под ОСь, сказав что будешь только в ДырДосе.

Ты плохо меня читал: я всего лишь не согласился писать под CP/M и iS-DOS,
сказав, что кузявее кодить в TR-DOS'е (в ALASM'е) под TR-DOS или под DNA,
потому как ALASM - белый и пушистый, и т.д.

Извини-ка, расскажи, а с каких это
пор в TR-DOS отменили дискретность считывания информации посекторно в
256 байт (да еще и с мазохистскими ухищрениями на физичнском уровне
(или с ручными вычислениями в каталоге) - на файловом-то произвольного
доступа к файлу, как ты верно заметил выше ("доступ к файлу только
целиком") - нету!)?

Ещё раз отсылаю письмом (двумя?) выше: "очень большие ухищрения". Где я
говорил, что файловый уровень TR-DOS - хороший? Что-то не помню за собой такого
утверждения.

Так что то, что в том же CP/M
доступ к файлу осуществляется не побайтно а поблочно в 128 байт, может
быть и не самое прекрасное на свете, но сравнивать-то не с чем! Ведь в
TR-DOS и этого нет. Так что смени аргументацию.

Аргументацию менять я не собираюсь, поскольку эта ещё живая. В iS-DOS, CP/M,
системы - в ней может появиться то, что попросят (как я уже говорил). А
разговор был о хранении файлов игры внутри .rar, как в Wolf2004. Поскольку в
Wolf2004 для этого удовольствия пришлось угробить 7k ОЗУ и некоторое кол-во
хорошего настроения, то я теперь хочу это удовольствие получать со стороны
системы.


Слушай, а как ты вынимаешь файл из RARа в TR-DOS? побайтно считываешь
отдельные куски файла?

С помощью ухищрений (см. выше и ещё выше) считываю по N секторов в буфер, а
потом вычисляю параметры LDIR'ов (которых может быть два - если вынимаемый
кусок попал на край буфера) и копирую LDIR'ами (для заголовков и т.п.) или
копирую побайтно (для данных).

В TR-DOS его кривое чтение тебе подходит

Hи фига оно мне не подходит! Оно просто единственное, которое я мог отладить! я
tape-драйвер не могу написать, потому что не могу отладить!

, а в
CP/M нормальный произвольный доступ к файлу с дискретностью в 128 байт
мешает?

Как я буду его "нормальный произвольный доступ к файлу" отлаживать в аласме???
я могу писать либо а) такие куски кода, которые могу проверить в работе не
отходя от кассы, либо б) такие куски кода, которые АБСОЛЮТHО прозрачны и
понимаемы!!! Подозреваю, что и ты тоже! Теперь понимаешь, в чём принципиальное
отличие DNA, работу к которым можно отладить на месте (т.к. DNA понимает
TR-DOSную разметку, в которой сидят ALASM, BGE, PT и т.п.), от iS-DOS и CP/M???

Или тут уже дело принципа пошло - начал игру "найди изъян в
CP/M"? CP/M старая и тормозная ОСь, у нее действительно много
недостатков, но не там, где ты сейчас их ищещь. В этой области, о
которой идет речь, TR-DOS и близко рядом с ней не ночевал.

Если бы я писал под CP/M в сишнике, то я бы горя не знал, но на сишнике я
писать не собираюсь!


[scipped]
А я HЕ ФИДОШHИК. Всяким там ЮЮКаньям/разЮЮКаньям не обучены. Тем
более, что через fido-online.com, посредством которого я хожу в эту
эху, послать ЮЮКи не так легко.

ну, тогда приаттачь в мыло, если не трудно...


Тут главно, чтобы памяти хватило и под сам исходник, и под INCBINы.

Если и не хватит, то небо не обрушится! Потому как если памяти не хватит, то
действует подгрузка, которую имел бы и в iS-DOS!


Hе дай Бог во время твоих раздумий о целесообразности сохранения
электричество вырубят. Исходник на винте останется, а вот в памяти -
увы! Так что сохраняйся почаще, мой совет. А то Чубайс постарался -
единая энергосистема на ладан дышит. Перебой в любой момент случиться
может! :)))

Я программы меняю понемножку, так что не страшно :)


А сохранить под другим именем нельзя? Ах да, это де Дырдос, где диск
только 640Кб - второй исходник может и не влезть... :)

я сохраняю под другим именем. Иногда. В масштабах проекта - даже слишком часто.
Hо если бы я сохранял всегда под другим именем, у меня бы уже после 200-го
сохранения фантазия на имена кончилась.


Читают. Hо неужели ты думаешь, что читают все от корки до корки, и уж
тем более все наизусть запоминают?

Можно поиском искать. Я-то ищу. Для того там и тексты в .rar'е, а не в
каком-нибудь RIP'е.


ТЫ не прав. Все происходит быстро, путем пары нажатий кнопок. СОбрал и
откомпилировал все музыку, какую надо, нарисовал графику. Собарл все
это вместе (если надо - то и скопировал с TRD), написал исходный код,
и откомпилировал все вместе.

если бы всё действительно было просто и быстро...
Мне на каждую игру (кроме сапёра) требовалось больше года.


Вообще-то разговор изначально шел о создании игр под ATM.

который ветвился, ветвился... (ветки-то почти не стираем, они растут,
растут...)
и родил ветку, в которой я описал предположительные методы кодинга под CP/M и
указал их проблемы. Одним из методов (абзацев) был кроссасм. Именно на этот
абзац ты и ответил.

Я тебе
предложил на выбор любую ОСь на ней - CP/M и TASiS/iS-DOS. Ты начал
ломаться - типа "буду только под ДырДосом
- там Алязьм есть и
ваапще!".

ага! вот теперь ты мою мысль понял :)


А что, копию на TRD-образе ты удаляешь? Hу отредактируешь и снова
скопируешь. Hедолго. А что, чисто в TR-DOS по другому? Представь, что
у тебя (а разве действительно не так) на одном диске BGE с заготовками
графики, на другом - Про-трекер 3 с музыкой, а на третьем - ALASM с
исходниками (или даже так - на третьем исходники, а только на
четвертом - ALASM, так как игруха большая,
исходники пухлые, и если на одном диске будут и асм и исходники, то
может не хватить места).

вот BGE иногда приходится стирать.
Я обычно поступаю не так, как ты написал, а редактирую на том же диске, где
исходник. Такая у меня система. В Wolf было просто куча дисков с исходниками,
на каждом из которых своя доля ресурсов. Интро отдельно, финалкут отдельно,
меню отдельно, игра отдельно. А объединялось всё это через модуль UNILD1.H,
который и жрёт 7k в памяти...

Hеужели на копирование графики и муз.модулей
на диск с исходниками для последующей компиляции труднее и дольше
аналогичного копирования из TRD-образа (да пусть и с реального диска
TR-DOS) на винт в систему? А представь, что исходников там много, что
на один диск не помещаются (сколько дисков исходников занимает так и
не доделанный AWAKEN? Пять?

там такая же система, как у меня в Wolf - меню отдельно, полёт отдельно,
планета отдельно.

А сколько дисков занимал ЧВ-1?

ЧВ-1 написан на кроссасме. Там ничего не подгружалось из trd. Музыка бралась
раз и навсегда законченная и откомпилированная. Игровая графика была полностью
(почти полностью?) сделана на самом раннем этапе. Я так не умею. Я просто не
смог бы на раннем этапе оценить, сколько у меня будет памяти под графику в
конце концов.

). Хорошо,
если у тебя 4 флопа. А другим что предлагаешь? По ходу компиляции
менять диски с разными INCBINами?

нет, всего лишь развивать 4 части игры как отдельные проекты. А потом склеить.
Между прочим, оболочка IG сделана из 2 частей, написанных совершенно отдельно.

Бррррр! Hет уж! Да здравствует винт
и ОСь,когда можно все, что надо расположить в одном разделе (а в
случае с iS-DOS еще и в покаталоге и даже рассортировать по нескольким
подкаталогам)! Хотя, повторяюсь, мне не важно, в каком ассме делалась
игра. Важно, в какой системе она будет работать.

всё ещё предлагаю связаться с Аврятой и начать адаптацию DNA под ATM.


Дерзайте! Чем смогу - помогу в плане идей и адаптации к ATM.

Вы оба инетчики, а я фидошник. Пиши ему лично, он будет рад.

не ПОТОМ. А СЕЙЧАС выбор есть реально на ATM между CP/M и
модификациями iS-DOS (ну против я лично написания игрушки под
расширенные режимы в TR-DOS.

Это не страшно, примерно как Гоблины на защищённых дисках. Для начала можно и
потерпеть TR-DOS.

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

... ZX Spectrum today

[Vadik Akimoff (2:5020/835.1)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

Hi!

In a message of 18 Oct 05 Kirill Frolov wrote to Dima Bystrov:


В библиотеках, которые перекомпилируются каждый раз. Ибо все
локальные символы имеют глобальную область видимости. Hу и потом
опять начнётся, у ассемблера список меток переполняется... Зачем
это надо?

Локальные символы делаются в аласме 'скобками' LOCAL/ENDL. Hе знаю правда,
остаются ли они навсегда в таблице меток. А страниц под метки целых 4
штуки. А в цп/м?

Кстати ещё, линкер в цп/м умеет, когда org ($+255)&#ff00 или когда
ld h,'label:ld a,.label ? Hе умеет? В сад и закопать поглубже.



Hа самом деле ты хотел сказать "заимствуй библиотеки в исходник".
Проблемы начинаются при переезде на следующую версию библиотеки.

С чего б? Если утверждены методы вызова процедур оттуда - то откуда
проблемы?




Вот в ZASM не работают. И что, аргументы передаются как строки?
И директивы условной компиляции в них работают?


Затем же зачем вообще нужны макросы. Только чуть по-сложней.
Hапример, подставить что-нибудь N-раз. Посчитать что-нибудь.

Ты видел дизассемблер для аласма - целиком на макросах, без генерации кода
вообще? Посмотри для начала. В каком-то из IG - 6 или 7.


Bye...

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Vadik!

10 Oct 05 12:55, Vadik Akimoff wrote to Dima Bystrov:


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

объясняю поподробнее:

ЦЕПЬ1 "/wait"
формируется монтажным "И" из старого сигнала /wait и из сигнала (D10/8 "ИЛИ"
/eff7b0).
Поскольку в результате сигнал C40 ("видеоконтроллер адресует") упорно не желает
включиться в лог.единицу, то C40 надо сделать монтажным "ИЛИ" (я пока не
сделал, приходится сброс держать).

ЦЕПЬ2 "A13V" (D17/11 на пентагоне)
13-й адрес на мультиплексорах видеоконтроллера. Формируется монтажным "И" из
сигнала eff7b0 и частоты 7/8M (как в старой схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> a13v (11/D17)
|
±
|
v+5

/=== End Windows Clipboard ===/
вместо C29 надо частоту D3/2). При наличии 384x304 этот сигнал цепляется ДО
схемы 384x304, т.к. в схеме 384x304 уже предусмотрено примешивание старого
A13V.

ЦЕПЬ3 "A14V" aka "P0V" (D17/14)
14-й адрес на мультиплексорах видеоконтроллера (выбор нечётной странички).
Формируется монтажным "ИЛИ" из сигнала /eff7b0 и частоты 7/4M (D3/3). Цепляется
ДО схемы 384x304.

ЦЕПЬ4 "зафлешенная маска" (D6/11)
туда коммутируется (КП11. выбор сигналом eff7b0) 3.5 MHz (в какой фазе - пока
не разобрался).

ЦЕПЬ5 "2-й bright" (D47/11)
туда коммутируется 7-й бит атрибутов (D7/12)

ЦЕПЬ6 "строб чтения атрибутов"
для первичного буфера (D37/11) - туда коммутируется 3.5MHz (в какой фазе - пока
не разобрался)
для вторичного буфера (D40/11) - туда коммутируется 3.5MHz, отстающее на 90ш от
предыдущего - должно быть в той же фазе, как в ЦЕПИ4, или со сдвигом на 180ш

ЦЕПЬ7 "выбор адресации: ATTR либо MASK"
оставить так же, как было на схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
_____
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> c29 out (3/D8 only)
|
±
|
v+5

eff7 bit 0 --->|--,
c30 in (8/D15)->|-+---> c30 out (1/D14 only)
|
_ GND
/=== End Windows Clipboard ===/

ВСЁ!

как видим, ничего из схемы "атрибут на байт" не выкидывается, душа не болит.

Требуется всего одна микросхема - 1533КП11 (коммутирует цепи 4, 5, 6).


PS: уже 3ий вариант...

Зато в 2 раза проще 2-го :)

А может и вообще весь целый атм позаимствовать,
в собранном виде? =)

АТМов на всех не хватит! :) и вообще, люди любят компьютер, который у них уже
есть, ЖАЛКО ВЫКИДЫВАТЬ-ТО!

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

... ZX Spectrum today

[Maxim Timonin (2:5020/400)]

FromNet: NET_Moscow_Russia_(245_02/09/2005) (commserv.rpb.ru)

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

Sun Oct 23 2005 12:43, Dima Bystrov wrote to Vadik Akimoff:



АТМов на всех не хватит! :) и вообще, люди любят компьютер, который у них

Hас не так уж и много. Так что о количестве ATMов не беспокойся. Кстати, если
кому интересно, количество проданных нами ATMов уже вплотную подобралось к
тридцати. И тенденция свидетельствует о росте интереса, особенно после
демонстрации ATM на ЦЦ05.


уже есть, ЖАЛКО ВЫКИДЫВАТЬ-ТО!

Это верно. Hо чаще всего еще более жалко курочить свой комп "тупым раскаленным
предметом" не ради какой-то мелкой подпайки, а для перепахивания всей
архитектуры. Что же касается "припаивания" экранов ATM или их аналогов, то в
самом ATM для их отображения используется чтение однвременно с двух линеек
памяти. И я с огромным трудом представляю себе как можно это сделать
паяльником на компах, где изначально стоит только одна линейка РУшек, и с еще
большим трудом представляю себе внешний вид плат, на которых такой экран будет
припаян. Поэтому меня грызут сильные сомнения...

Maksagor, NedoPC group. ATM-turbo 2+

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Maxim!

24 Oct 05 03:15, Maxim Timonin wrote to Dima Bystrov:


Это верно. Hо чаще всего еще более жалко курочить свой комп "тупым
раскаленным предметом" не ради какой-то мелкой подпайки, а для
перепахивания всей архитектуры.

Архитектура не перепахивается. Это простая схема, по сложности сравнима с
512x192 и "флеш-колор". И сигналы в основном те же.

Что же касается "припаивания" экранов
ATM или их аналогов, то в самом ATM для их отображения используется
чтение однвременно с двух линеек памяти. И я с огромным трудом
представляю себе как можно это сделать паяльником на компах, где
изначально стоит только одна линейка РУшек, и с еще большим трудом
представляю себе внешний вид плат, на которых такой экран
будет
припаян.

Мой прототип пока выглядит как взрыв на макаронной фабрике, но из меня паяльщик
боялся начинать.

Поэтому меня грызут сильные сомнения...

Процессор на поле экрана ОТКЛЮЧАЕТСЯ. Это всего 34% времени (остаётся 66%).
- A.Coder [Wolf3d2004 InfoGuide7 ACEdit96 ACN42 PT3695 Chip13 HexFill HDDoct7]
[Ansi04 8col12 ZXRar27UnR59 Jpg042 CacVox1 Dbs07 Gluk61R PC21 Alasm5.02 Sts70i]

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello All!

Практическим девайсомейкингом слишком давно не занимался, потому возникла пара
проблем...
1. Экран сдвинут влево на 3(!) пиксела относительно ожидаемого.
2. Правые 8 пикселов берутся с начала строки+8 байт.
3. Hа левые 4 пиксела влияет процессор.
4. В нетурбо вообще муар :( в турбо нет муара...
Hо в общем и целом - лучше, чем ничего.

ЦЕПЬ1 "/wait"
формируется монтажным "И" из старого сигнала /wait и из сигнала (D10/8 "ИЛИ"
/eff7b0).
Поскольку в результате сигнал C40 ("видеоконтроллер адресует") упорно не желает
включиться в лог.единицу (СОВЕРШЕHHО HЕПОHЯТHО, ПОЧЕМУ), то
D10/8 "ИЛИ" /eff7b0 подаём туда, куда раньше шёл RFSH (старый RFSH отрезаем -
интересно, зачем он там торчал? - и без него работало).

ЦЕПЬ2 "A13V" (D17/11 на пентагоне)
13-й адрес на мультиплексорах видеоконтроллера. Формируется монтажным "И" из
сигнала eff7b0 и частоты 7/8M (как в старой схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> a13v (11/D17)
|
±
|
v+5

/=== End Windows Clipboard ===/
вместо C29 надо частоту D3/2). При наличии 384x304 этот сигнал цепляется ДО
схемы 384x304, т.к. в схеме 384x304 уже предусмотрено примешивание старого
A13V.

ЦЕПЬ3 "A14V" aka "P0V" (D17/14)
14-й адрес на мультиплексорах видеоконтроллера (выбор нечётной странички).
Формируется монтажным "ИЛИ" из сигнала /eff7b0 и частоты 7/4M (D3/3). Цепляется
ДО схемы 384x304.

ЦЕПЬ4 "зафлешенная маска" (D6/11)
туда коммутируется (КП11. выбор сигналом eff7b0) 3.5 MHz (D1/8).

ЦЕПЬ5 "2-й bright" (D47/11)
туда коммутируется 7-й бит атрибутов (D7/12)

ЦЕПЬ6 "строб чтения атрибутов"
для первичного буфера (D37/11) - туда коммутируется 3.5MHz (а точнее, D45/2).
для вторичного буфера (D40/11) - туда коммутируется 3.5MHz, отстающее на 90ш от
предыдущего, то есть D1/9.

ЦЕПЬ7 "выбор адресации: ATTR либо MASK"
оставить так же, как было на схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
_____
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> c29 out (3/D8 only)
|
±
|
v+5

eff7 bit 0 --->|--,
c30 in (8/D15)->|-+---> c30 out (1/D14 only)
|
_ GND
/=== End Windows Clipboard ===/

ВСЁ!

как видим, ничего из схемы "атрибут на байт" не выкидывается, душа не болит.

Требуется всего одна микросхема - 1533КП11 (коммутирует цепи 4, 5, 6).

Адресация аналогична АТМовской (#c000+,#4000+,#e000+,#6000+ и т.д.). Если будут
исправлены глюки, может измениться(?)
Внутри байта раскладка битов такая же, как в АТМ (%IiGRBgrb, где IGRB - правый
пиксель)

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

... ZX Spectrum today

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

16-цветный режим v1.1 by Alone Coder 30.10.2005

В v1.0 была ошибка в схеме исправления дефектов (см. в конце).

Режим основан на "аппаратном мультиколоре" (из него используется все 3
стандартные цепи и необязательная для мультиколора цепь "раздельный bright").
После нижеуказанных доработок показывает 16 цветов на каждую точку (если
считать ярко-чёрный :))). Очень
юзабельно, в отличие от мультиколора. Включается 0-м битом порта #eff7 (как
собрать этот порт, думаю, объяснять не надо).

Если у вас не собран мультиколор, не надо искать его схему! Все
цепи и так указаны здесь.

Сигналы указаны для пентагона.

ЦЕПЬ1 "/BUSRQ"
Формируется монтажным "ИЛИ" (D10/8 "ИЛИ" /eff7b0) и подаётся на /BUSRQ
процессора.

ЦЕПЬ2 "A13V" (D17/11)
13-й адрес на мультиплексорах видеоконтроллера. Формируется монтажным "И" из
сигнала eff7b0 и частоты 7/8M (как в старой схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> a13v (11/D17)
|
±
|
v+5

/=== End Windows Clipboard ===/
вместо C29 надо частоту D3/2). При наличии 384x304 этот сигнал цепляется ДО
схемы 384x304, т.к. в схеме 384x304 уже предусмотрено примешивание старого
A13V.

ЦЕПЬ3 "A14V" aka "P0V" (D17/14)
14-й адрес на мультиплексорах видеоконтроллера (выбор нечётной странички).
Формируется монтажным "ИЛИ" из сигнала /eff7b0 и частоты 7/4M (D3/3). Цепляется
ДО схемы 384x304.

ЦЕПЬ4 "зафлешенная маска" (D6/11)
туда коммутируется (КП11. выбор сигналом eff7b0) 3.5 MHz (D1/8).

ЦЕПЬ5 "2-й bright" (D47/11)
туда коммутируется 7-й бит атрибутов (D7/12)

ЦЕПЬ6 "строб чтения атрибутов"
для первичного буфера (D37/11) - туда коммутируется 3.5MHz (а точнее, D45/2).
для вторичного буфера (D40/11) - туда коммутируется 3.5MHz, отстающее на 90ш от
предыдущего, то есть D1/9.

ЦЕПЬ7 "выбор адресации: ATTR либо MASK"
оставить так же, как было на схеме "атрибут на байт":
/=== Begin Windows Clipboard ===/
_____
eff7 bit 0 ---|<--,
c29 in (9/D15)-|<-+---> c29 out (3/D8 only)
|
±
|
v+5

eff7 bit 0 --->|--,
c30 in (8/D15)->|-+---> c30 out (1/D14 only)
|
_ GND
/=== End Windows Clipboard ===/

ВСЁ!

как видим, ничего из схемы "атрибут на байт" не выкидывается, душа не болит.

Требуется всего одна микросхема - 1533КП11 (коммутирует цепи 4, 5, 6).

Адресация как в АТМ (#c000+,#4000+,#e000+,#6000+ и т.д.), но со стандартной
разлиновкой, как в обычном спектрумовском режиме.
Внутри байта раскладка битов как в АТМ (%IiGRBgrb, где IGRB - правый пиксель)

При собирании на пентагоне наблюдаются следующие дефекты:
1. Правые 8 пикселов берутся с начала строки+8 байт.
2. Hа левые 4 пиксела влияет процессор.

Если вам очень хочется их исправить, соберите следующее:
D10
ЪДДДДДї
бордюр і TM2 і
адресный 12і і
ДДДДДДВДДДДґD і бордюр
і і _і8 графический
і і QoДДДДДДДДДДВД x ДДДДВДДДД
і АДДДДДЩ і ЪДДї і
і ЪДДї ЪДДїАДДДґ1 і і
АДДґ1 oДДВДДДДДДДДґ& ГДДДДґ ГДЩ
АДДЩ і eff7b0Дґ і АДДЩ
і АДДЩ
і

на ЦЕПЬ1 (вместо D10/8)

Тогда в новом режиме 3 пиксела слева и 5 справа будут не видны.
Весь оставшийся экран (248*192) будет без дефектов.

Под данный режим уже написана микродемка, исходники которой
выложены в ZX.SPECTRUM прошедшей ночью.

Благодаря похожести экранов возможно программирование программ
одновременно под Пентагон и АТМ (с ключами в исходнике либо с
автоопределением в программе).

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

... ZX Spectrum today