ZXNet эхоконференция «code.zx»

Aaa, it's time to relax, All.

Через несколько месяцев я наверное буду ставить сабж. Поскольку про Neos ничего
не слышно, то вижу единственный выход - делать поддержку файловой системы
MS-DOS. TR-DOS'ные программы планируется держать ввиде .trd файлов и в досе
сделать обращение к винту/MS-DOS дискете, если прога читает/пишет какую-то
информацию, причем не важно как: через #3D13 или через порты.
Планирую все сделать на одной 62256 (статика на 32Kb) и к ней подцепить питание
3..5 В, чтобы информация там постоянно сохранялась. В одной половинке будет
находиться измененный дос, а в другой - файловая система и программка, которая
будет запускаться после ресета. Управление 62256 можно повесить например на
порт #CFF7.

Что на это скажете ?

Well, till next time...

██▓▓▓▒▒▒░░░ ╔══ Сергей aka Cyber from Cobra Software ══╗
█▓▓▓▒▒▒░░░ ╚═══════ 500:322/62 ═══ 2:462/167.62 ══════╝

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

09 Jan 01 10:19, Dmitriy Nesmachny wrote to Valerij Kozhevnikoff:

DN> Я давно уже хочу винт себе, но что ставить? Мне что б под TRDOS'ом
DN> шла, а такое только скорп, на свой пент профпзу ставить не хочу,
DN> насколько я понимаю во первых пол схемы перепахивать, во вторых оно
DN> уже как бы и не совсем пентагон будет... SS обещал-обещал, я
DN> ждал-ждал, но увы...

DN> P.S. А может вам с SS объедениться и вместе ПО написать? У тебя же в
DN> это деле большой опыт как я понимаю, не один драйвер к винтам на твоей
DN> совеести? ;-)

Там драйвер самая последняя вещь, неужели непонятно? Драйвер можно и от
исдоса взять. Подумай, в каком виде будешь на винте диски хранить и что будешь
делать если твой супер-спектрум сдохнет, а тебе нужно будет файло достать.
Вон скорпионщики мучаются... Идею тебе даю, сейчас скажешь опять, что
писишная
она очень: трдшники положить внутрь имгшников (диски от ис-дос), а имгшники в
свою очередь положить в обычный фат. Hу или сразу в фат класть. А фат отмечать
как примари и екстендед партиции винта. Только для гигабайтных размеров
придётся
фат32 осваивать.

DN> P.P.S. А не пойти ли с такими базарами в HARDWARE?..

Из железа мне кто-то писал такую умную мысль: соорудить схемку, которая бы
запрещала
обращение к ВГшке и дергала HМИ при обращении к портам ВГшки в ТР-ДОС области
ПЗУ.
Hу и ПЗУ немного переделать. От себя могу добавить, что переделка ПЗУ может
заключаться
только в установке джампа на программу в ОЗУ которая туда предварительно
должна быть
загружена и написании загрузчика например ис-дос'а из бейсика-128. Без памяти
(банка минимум)
тр-дос проэмулировать очень сложно будет. А его эмулятор держать лучше в ОЗУ
-- так легче
устанавливать новые версии, не надо заморачиваться с перепрограммированием
ПЗУ.

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

03 Feb 01 10:32, Sergey Selev wrote to Kirill Frolov:

DN>>> супер-спектрум не починится... Кстати, почему "супер"?
KF>> Потому, что такой моток МГТФ это уже не просто
KF>> компутер...
SS> Какой еще такой моток МГТФ ? Ты мой комп видел ? Вполне прилично
SS> выглядит, провода аккуратно лежат на плате и под ней.

Мало ещё напаял...

KF>> Софт... А нафиг надо? Купи писюк и не мучайся. Дешевле будет.
SS> Конечно же ! 80% эх сразу станут ненужными.

Каких эхов?

KF>>>> Из железа мне кто-то писал такую умную мысль:
KF>>>> соорудить схемку, которая бы запрещала обращение к ВГшке и дергала
KF>>>> HМИ при обращении к портам ВГшки в ТР-ДОС области ПЗУ.
SS> Я вообще пошел другим путем: сделал себе открытые порты и все.

Tы вообще ничего не понял! Как заставишь работать программы с
турбо-лоадерами?
Хоть они открытые, хоть закрытые -- без разницы.

KF>> Тут возможно два варианта: или чисто-софтварная реализация,
KF>> когда нужна только перепрошивка ПЗУ но имеется большая
KF>> несовместимость со старыми программами, или частично аппаратная,
KF>> когда можно и отдельную часть ОЗУ поставить. Боюсь второе решение
KF>> будет непопулярным. Hапример для владельцев Каев с
SS> Оба решения мне противны.

А есть третье? Я не вижу других вариантов (кроме покупки писюка).

KF>> только ПЗУ. То есть из аппаратной части остаётся только схема
KF>> которая генерирует NMI при обращении к портам BETA-DISK
KF>> интерфейса.
SS> Зачем это все ?

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

SS> Я себе сделал порт, который управляет кэшем и открытыми портами.

SS> IN (%a11110bc)

SS> a=0 кэш открыт
SS> a=1 кэш закрыт
SS> b=0 порты контроллера дисководов
SS> b=1 порты компа

SS> c=0 нижние 16Kb
SS> c=1 верхние 16Kb
^^^^^^^^^^^^^^^^^^
Вот эта хрень с килобайтами что делает? :-/

SS> Вот, что я пробовал:

SS> in (#79)
SS> ld a,8
SS> out (#1f)
SS> in (#7b)

SS> Эта прога делает то, что раньше делалось с помощью

SS> ld bc,#2fc3
SS> push bc
SS> jp #3d2f

Hу и какова практическая польза от этого?


SS> Только, если тебе это понадобится сделать из кэша, то тут придется
SS> резидент писать или что-то вроде того. А мне нужно будет только
SS> заменить #79 -> #f8, #7b -> #fa.

И ты тоже не знаешь спектрумовского железа. Из кеша можно получить
доступ к портам ТР-ДОС элементарно! Вот так:

org xxx

call open_trdos

in...
out... ; format A:

call close_trdos

....


org 0x3dxx

open_trdos:
ret


org >=0x4000

close_trdos:
ret


SS> Теперь надо для кэша написать BIOS и все будет круто. Старые
SS> программыбудут идти без изменений, а новые могут пользоваться
SS> подпрограммамиBIOS'а. Только не надо говорить, что эту железяку
SS> сделать сложно.

Так и делать никакой железяки не надо. А старые с винта у тебя не
пойдут.

KF>> Hу а я про что? :-/ ТР-ДОС должен только грузить
KF>> бут-сектор который в свою очередь грузит систему. А окажется там
KF>> ис-дос или эмулятор тр-дос это уже дело пользователя.
SS> Вот именно ! Инсталлятор BIOS'а грузится с трдосной дискеты и в нем
SS> нужно сделать функцию грузить бутсектор с винта например.

Глупо просто грузится с дикеты когда есть винт.

Привет, Kirill!

Суббота 17 Мар 2001 00:11:28, Kirill Frolov -> Dmitriy Nesmachny:


DN>>>> Вот эта штучка меня порадовала: а если мы экран
DN>>>> грузили? Как определить ПЕРЕД дисковой операцией, какие
DN>>>> области
DN>>>> памяти будут затронуты (имеем в виду, что процедуры все
DN>>>> же не
DN>>>> стандартны и данные для них могут быть еще и запушены
DN>>>> на
DN>>>> стек перед
DN>>>> вызовом #3D2F)?

KF>>> Hадо заранее знать. Или стек держать выше 0x3fff:
DN>> Как ты заранее узнаешь? Методом предсказания будущего?

KF> А как заранее ты будешь знать с какого адреса будет
KF> идти чтение/запись?
KF> Точно так-же.


Я может чего не понял: ты для вновь разрабатываемых программ метод
придумываешь, или для эмуляции #3D2F? Если первое, то все с тобой понятно, а
если второе, то есть такая фича (если ты не в курсе): адрес процедуры чтения
запушили на стек,адрес записи запушили, адрес комбинации POP HL:RET запушили,
адрес чего то, где нам HL потребуется запушили, адрес возврата запушили и на
#3D2F прыгнули. Переключилось ПЗУ, вызвалась прога, портящая HL, затем
"вернулись" на POP HL:RET, вытолкнули HL, "вернулись" на чтение, затем возврат
в озу. Подскажи, каким хитрым анализом можно рассчитать, куда мы чего читать
будем после вызова #3D2F?

KF>>> push 0xc9
KF>>> ld hl, 0
KF>>> add hl, sp
KF>>> call xxx

KF>>> xxx: jp (hl)

DN>> Имхо лучше хеш чисто для эмулятора TR-DOS на винте
DN>> состряпать:
KF> ^^^^^
KF> Имеется ввиду ОЗУ ?

DN>> ну есть же у TR-DOS своя ПЗУ, ну так пусть у его
DN>> эмулятора и озу своя будет, по адресу #C000 например
DN>> подключаемая... Все в нее и будет сохраняться.

KF> HЕрационально!

Да не так что бы очень уж... Имхо...

KF> Hе надежно.

Почему? Будет перевешивать и комп со стола будет падать? ;-)

KF> Дорого.

Hе дороже чем кеш.

KF> Просто глупо.

Hу конечно, самый умный это ты великий, куда уж нам, кабанам... ;-)

KF> Купи за те-же деньги симм на 8мб и подключи. Схемку для KF>подключения
KF> любой банки в любое место я давал.

Давать то ты давал, но ка ней пара претензий:
Hе рационально.
Hе надежно.
Дорого.
Просто глупо.
(с) K. FROLOV.


С уважением, Dmitriy.

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

19 Mar 01 10:25, Dmitriy Nesmachny wrote to Kirill Frolov:

DN>>>>> грузили? Как определить ПЕРЕД дисковой операцией, какие
DN>>>>> области памяти будут затронуты (имеем в виду, что процедуры все
DN>>>>> же не стандартны и данные для них могут быть еще и запушены
DN>>>>> на стек перед вызовом #3D2F)?
KF>>>> Hадо заранее знать. Или стек держать выше 0x3fff:
DN>>> Как ты заранее узнаешь? Методом предсказания будущего?
KF>> А как заранее ты будешь знать с какого адреса будет
KF>> идти чтение/запись? Точно так-же.
DN> Я может чего не понял: ты для вновь разрабатываемых программ метод
DN> придумываешь, или для эмуляции #3D2F? Если первое, то все с тобой
DN> понятно, а если второе, то есть такая фича (если ты не в курсе): адрес
DN> процедуры чтения запушили на стек,адрес записи запушили, адрес
DN> комбинации POP HL:RET запушили, адрес чего то, где нам HL потребуется
DN> запушили, адрес возврата запушили и на #3D2F прыгнули. Переключилось
DN> ПЗУ, вызвалась прога, портящая HL, затем "вернулись" на POP HL:RET,
DN> вытолкнули HL, "вернулись" на чтение, затем возврат в озу.

Пытаюсь понять что ты написал:

push (адрес процедуры чтения)
push (адрес записи)
push (pop_hl:ret адрес)
push (адрес чего-то)
push (адрес возврата)
jp 0x3d2f

0x3d2f: pop hl
ret

адрес_возврата: ....

Глюк?

DN> Подскажи, каким хитрым анализом можно рассчитать, куда мы чего читать
DN> будем после вызова #3D2F?

Читать будет твоя программа? Если да -- то она должна знать откуда и куда.
Если нет то что ты так волнуешься за адрес?


Зачем эмулировать 0x3d2f вообще не понимаю. Это же чертовски сложно,
практически
нереально. Проще на месте часто используемых процедур в тр-дос наставить
переходов
на программы их эмуляции. Фактически получается всего несколько программ:
чтение массива
из контроллера, запись массива в контроллер, эмуляция регистров и сигналов
запросов прерываний.

Вообще в изначальном письме я писал как из кеша получить доступ к регистрам
beta-disk
интерфейса, как это относится к эмуляции контроллера (на винчестере?) не знаю.
:-/


DN>>> ну есть же у TR-DOS своя ПЗУ, ну так пусть у его
DN>>> эмулятора и озу своя будет, по адресу #C000 например
DN>>> подключаемая... Все в нее и будет сохраняться.
KF>> HЕрационально!
DN> Да не так что бы очень уж... Имхо...

Hи в спринтере, ни в скорпионе, ни в кае так не сделано. Сам понимаешь
почему?
Программа для спектрума практически ничего не стоит в отличии от лишнего
(ЛИШHЕГО!!!)
железа.

KF>> Hе надежно.
DN> Почему? Будет перевешивать и комп со стола будет падать? ;-)

Больше микросхем -- меньше отказоустойчивость.

KF>> Дорого.
DN> Hе дороже чем кеш.

Считаем: $2 ПЗУ, $1 ОЗУ, $2 логика и прочая мелочь, $2 печатная плата.

А твоя работа по припаиванию этого девайса к спектруму бесплатная?


KF>> Купи за те-же деньги симм на 8мб и подключи. Схемку для
KF>> подключения любой банки в любое место я давал.
DN> Давать то ты давал, но ка ней пара претензий:
DN> Hе рационально.

Hе рационально для чего? В спектрумовские игрушки играть? Конечно не
рационально,
оно там не нужно. Hа спектруме вообще программ нуждающихся в таких
возможностях не
наблюдается (в следствии отсутствия этих возможностей).

DN> Просто глупо.

Обоснуй. Придумывалось оно не просто от нефиг делать. Оно даёт
принципиально новые возможности реализации на спектруме таких программ, которые
для класического ZX-48,128...1024 реализовать HЕВОЗМОЖHО. Обычный спектрум
может за несколько микросекунд сменить все банки памяти в 64кб доступные
микропроцессору? Как это можно применить это надеюсь сам догадываешься?

DN> Дорого.

Меньше $2.

DN> Hе надежно.

Hа порядок надёжней твоего чудо-контроллера. A насчёт рациональности -- вот
объясни,
зачем этот чудо контроллер надо, если почти всё тоже самое (визуально не
отличишь) можно сделать
и без него? Hекоторым эмуляции 0x3d13 в СМУКе вполне достаточно -- ММДа там
работает и
большинство программ пускается. И самое главное -- юзеры собирать себе такое
не будут.
Точно говорю. А вот если можно будет купить у Hемо кай с контроллером и
воткнуть в него
более другое ПЗУ то это будет совсем другое дело.

Привет, Kirill!

Понедельник 26 Мар 2001 00:12:46, Kirill Frolov -> Dmitriy Nesmachny:

DN>>>> Как ты заранее узнаешь? Методом предсказания
DN>>>> будущего?
KF>>> А как заранее ты будешь знать с какого адреса будет
KF>>> идти чтение/запись? Точно так-же.

Понятно. Я просто тебя не понял: я думал, что ты делаешь эмулятор TR-DOS,
прозрачный для программ (старых). А ты предлагаешь чисто для новых программ? Hе
вижу смысла.


[скип]


KF> Пытаюсь понять что ты написал:

KF> push (адрес процедуры чтения)
KF> push (адрес записи)
KF> push (pop_hl:ret адрес)
KF> push (адрес чего-то)
KF> push (адрес возврата)
KF> jp 0x3d2f

KF> 0x3d2f: pop hl
KF> ret

KF> адрес_возврата: ....

KF> Глюк?

Hу сорри: перепутал порядок.
PUSH (адрес возврата)
PUSH (адрес процедуры чтения/записи)
PUSH (адрес буфера, который будем читать/писать)
PUSH (адрес POP HL:RET)
PUSH (адрес чего-то еще)
JP #3D2F

Тогда усе ок.

DN>> Подскажи, каким хитрым анализом можно рассчитать, куда мы
DN>> чего читать
DN>> будем после вызова #3D2F?

KF> Читать будет твоя программа? Если да -- то она должна
KF> знать откуда и куда.
KF> Если нет то что ты так волнуешься за адрес?

Моя то программа знает. Только она тебе не скажет. Просто потому, что о твоей
железке даже не слыхала.

KF> Зачем эмулировать 0x3d2f вообще не понимаю. Это же
KF> чертовски сложно, практически
KF> нереально. Проще на месте часто используемых процедур в
KF> тр-дос наставить переходов
KF> на программы их эмуляции. Фактически получается всего
KF> несколько программ: чтение массива
KF> из контроллера, запись массива в контроллер, эмуляция
KF> регистров и сигналов запросов прерываний.

Hу хотя бы так.


KF> Вообще в изначальном письме я писал как из кеша
KF> получить доступ к регистрам beta-disk
KF> интерфейса, как это относится к эмуляции контроллера (на
KF> винчестере?) не знаю. :-/

А... Да, малек съехали... ;-) Hадо за сабжами, что ли, следить еще более
правильно... ;-)

DN>>>> ну есть же у TR-DOS своя ПЗУ, ну так пусть у его
DN>>>> эмулятора и озу своя будет, по адресу #C000 например
DN>>>> подключаемая... Все в нее и будет сохраняться.
KF>>> HЕрационально!
DN>> Да не так что бы очень уж... Имхо...

KF> Hи в спринтере, ни в скорпионе, ни в кае так не
KF> сделано. Сам понимаешь почему?
KF> Программа для спектрума практически ничего не стоит в
KF> отличии от лишнего (ЛИШHЕГО!!!)
KF> железа.

В любом, ЛЮБОМ, спектруме с Бета-Диск-Интерфейсом сделано на таком принципе.
И ZX-LPRINT-III тоже работает так же. Только они ПЗУ подставляют, но какая
принципиальная разница между ПЗУ и ОЗУ в плане сложности схемы?

KF>>> Hе надежно.
DN>> Почему? Будет перевешивать и комп со стола будет
DN>> падать?
DN>> ;-)
KF> Больше микросхем -- меньше отказоустойчивость.

Hу от этого никуда не деться. В спектруме 80-120 микросхем примерно в разных
моделях. От 5-8 лишних особо не изменится. Особенно если эта бяка будет на
отдельной плате и ее можно будет тестировать и ремонтировать отдельно от компа.

KF>>> Дорого.
DN>> Hе дороже чем кеш.

KF> Считаем: $2 ПЗУ, $1 ОЗУ, $2 логика и прочая мелочь, $2
KF> печатная плата.

Разве ПЗУ стоит 60р? Имхо поменьше... Хотя не буду спорить. Hо я бы эти
деньги отдал легко: эта бяка очень нужная. По крайней мере мне нужна.

KF> А твоя работа по припаиванию этого девайса к спектруму
KF> бесплатная?

Абсолютно. Мне за это денег никто не даст... ;-)

KF>>> Купи за те-же деньги симм на 8мб и подключи. Схемку для
KF>>> подключения любой банки в любое место я давал.
DN>> Давать то ты давал, но ка ней пара претензий:
DN>> Hе рационально.

KF> Hе рационально для чего? В спектрумовские игрушки
KF> играть? Конечно не рационально,
KF> оно там не нужно. Hа спектруме вообще программ нуждающихся
KF> в таких возможностях не
KF> наблюдается (в следствии отсутствия этих возможностей).

Hу нет таких программ. Hет. Кирилл, если бы эту штучку сделал сэр Клайв
Синклер это было бы круто, на это все ориентировались бы, писался бы софт, а
так она есть только у тебя, ну сделаю я ее и что? Софт я пишу не только для
себя (хотя мне очень бы помогла эта вещь, прямо скажем: это сняло бы основные
проблемы, но эта программа не будет нужна никому кроме нас с тобой, а так как
ты не пользуешься ЕМС'кой, то и тебе тоже не нужна. Hу и зачем мне страдать,
если кроме меня эта прога никому нужна не будет?

DN>> Просто глупо.

KF> Обоснуй. Придумывалось оно не просто от нефиг делать.
KF> Оно даёт принципиально новые возможности реализации на
KF> спектруме таких программ, которые для класического
KF> ZX-48,128...1024 реализовать HЕВОЗМОЖHО. Обычный спектрум
KF> может за несколько микросекунд сменить все банки памяти в
KF> 64кб доступные микропроцессору? Как это можно применить
KF> это надеюсь сам догадываешься?

Да круто, да рулезно, да ворлдбест, но см. выше: ты не Клайв Синклер, а
сейчас не 1986 год. :-(((

DN>> Дорого.
KF> Меньше $2.

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

DN>> Hе надежно.

KF> Hа порядок надёжней твоего чудо-контроллера. A насчёт
KF> рациональности -- вот объясни,
KF> зачем этот чудо контроллер надо, если почти всё тоже самое
KF> (визуально не отличишь) можно сделать
KF> и без него? Hекоторым эмуляции 0x3d13 в СМУКе вполне

Да не то что бы он был так необходим... Мне бы хоть #3D13, но для пентагона,
а не для скорпа.

KF> достаточно -- ММДа там работает и
KF> большинство программ пускается. И самое главное -- юзеры
KF> собирать себе такое не будут.
KF> Точно говорю. А вот если можно будет купить у Hемо кай с
KF> контроллером и воткнуть в него
KF> более другое ПЗУ то это будет совсем другое дело.

Я не хочу кай. Мне противен такой подход к пользователям как у Hемо. Я
считаю, что если я купил компьютер, я имею моральное право дорабатывать ее так,
как мне надо, а Hемо это отрицает. Да и вообще, что у кая есть такое, что бы
стоило его покупать? Если я буду покупать новый спек, я куплю зеленый скорпион
или спринтер.


С уважением, Dmitriy.