==

>  Больше похоже на какие-то понты на пустом месте :)

Это было в куске защищённой от копирования проги, где-то как раз рядом с "секретным" загрузчиком.
Так что могло быть два варианта: 1) чуть-чуть обфускация; 2) автор помнил про процедуру, которая есть в сисмоне, но не имел никакого справочника процедур. Просто набрал F000LLLLLLLLL и дальше где-то нашел то, что нужно. А то, что это не окно F800..FFFF, может не заметил, а может заметил, но решил - и так сойдёт.

> Последние 4 байта в нем это именно идентификатор

Да, это именно идентификатор. В старой 140ке там просто FF FF FF FF.
Мне кажется. что про эти 4 байта фирма Ниппель вроде бы и писала документ, чтобы там сделать ID для разных новых модулей и предлагала конкретные коды (class, vendor, product id...). Но это не точно :)

Короче, хотя заставку не видно, но все более-менее работает.

Вы правы:

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

Voldemar0, спасибо огромное за помощь!!! Не знаю, сколько бы я еще искал косяк с синхробитом.

> Я имел ввиду другое, что использовали недокументированные возможности

Это было вынуждено.

Я когда читаю вот это:

то мне не кажется, что обращение к монитору по адресам $F000..$F7FF было вынужденным. Больше похоже на какие-то понты на пустом месте :) Если это была "защита" от запуска на Агат-7 или Apple ][, то монитор - сам по себе защита, у него масса входных точек на других местах.

Кстати, для девятки, похоже, разработали некую систему идентификации ПЗУ. Последние 4 байта в нем это именно идентификатор, позволяющий определить тип контроллера. ИКП-шный загрузчик для девятки эти идентификаторы использует и со старого контроллера 140 К просто загрузиться не сможет, потому что там в ПЗУ какое-то недопустимое значение лежит.

Я так понял, на первой картинке скриншот с сайта.

А загружается он с мусором в текстовом режиме потому что для заставки ИКП нужен цветной графический режим высокого разрешения, а он не реализован:

Короче, хотя заставку не видно, но все более-менее работает.

Это было вынуждено.
Допустим, для опознания контроллера дисковода можно найти какую-то уникальную сигнатуру в его ПЗУ.
А как распознать, к примеру, модули ДопОЗУ?  У них нет ПЗУшек видимых.
Можно было бы попробовать как-то попереключать режимы работы и посмотреть, что будет происходить в системе.
Но лень, много операций. Поэтому и сокращали до 1-2 характерных байт, которые, вроде бы, ни с чем больше не совпадают.

Где-то в 90-х появился документ, причем не от ЛЭМЗ (разработчика Агата), а от кооперативов, которые допмодули на агат проектировали, там предлагалась хоть какая-то унификация этого процесса (соглашения об использовании пространства ПЗУ для нужд идентификации устройств), но к тому времени агатовская тема стала уже стала сходить на нет.

>  но практически полностью отсутствует как Агат взаимодействует с контроллером.

Контроллер и есть часть агата. Или речь о взаимодействии драйвера и контроллера?

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

А ПО уже написано, и даже если кому-то захочется написать новое, для этого можно либо смотреть
примеры старых драйверов или официальную документацию - там вполне расписано как работать с железом.
По 840к ты уже нашел эти тексты, а по 140ке - .... там проще всё заного написать, очень уж многое в доках не описано
(Я бы так сказал: документация официальная на 140ку - это научно-популярная статья, а не руководство программиста).
Лучше, конечно, смотреть именно старые драйвера - там ошибок существенно меньше, чем в доках ;)
Или брать книжки по Apple][: я в своих статьях упоминал Джима Сазера - вот там всё очень подробно о взаимодействии ПО
и железа. Агатовская 140ка по логике работы практически повторяет Disk ][ от Apple ][.

> А это для какого контроллера?

140k

> Хотел уточнить, те диски, которые вы давали, они все читали из 0 дороги?

example30 имеет BRK сразу после чтения сектора 0/0.
example40 читает 0/0, затем дочитывает из трека 0 свой RWTS, что-то ищет в оборудовании, затем BRK (непосредственно перед первым вызовом своего RWTS).

example 10 и 20 без BRK.

> Есть такой диск:

А вопрос-то в чём ?
Это ИКП: только не ясно: почему он на первой картинке не цветной?
Версии для девятки цветные, версии для семёрки - ч/б.

Заргужается он у меня вот так:

А ели нажать энтер?

А если повыбирать в слепую? Да, это еще и работает:

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

"Велосипед" - это, обычно, написание своего кода, вместо уже существующего, причем свой не сильно лучше существующего. Но с агатом ситуация немного другая: на него было очень мало софта

Я имел ввиду другое, что использовали недокументированные возможности. Их использование всегда затрудняет перенос кода, да даже взять Агат-9, прикинь, решили бы добавить в схему подтяжку по данным и уже бы все развалилось.

А это для какого контроллера? Для 840 я такого не находил, я видел, что вв55 можно программировать записывая в регистр программирования 0 в 7-бит, а 3-1 биты указывают на номер бита куда можно установить или снять 1 (то что в 0 бите). Я это сделал.

Да, с этого начинал, там очень хорошо расписан секвенсер и все что происходит в самом контроллере, но практически полностью отсутствует как Агат взаимодействует с контроллером. Я нашел техническое описание на контроллер 840, примеры его программирования, но этого мало, я вот долго не мог понять, почему Агат не считывает 2 раза один и тот же байт данных. Как сбрасывается rdy. Пока случайно, где-то в примерах программирования, не увидел фразу, что при чтении из вв55 бит rdy сбрасывается сам.

Хотел уточнить, те диски, которые вы давали, они все читали из 0 дороги?

"Велосипед" - это, обычно, написание своего кода, вместо уже существующего, причем свой не сильно лучше существующего. Но с агатом ситуация немного другая: на него было очень мало софта.
Я, например, когда начинал работать с агатом, нуждался даже просто в хорошем копировщике файлов.
Был FID, но он требовал указать номер слота контроллера-источника, привод на контроллере, контроллер-приёмник, привод на контроллере и имя файла ввести вручную (там была возможность указать что-то типа "маски", но об этом нигде в интерфейсе не было сказано, я это нашел почти случайно).

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

И поскольку агаты ставились в школы, очень многие будущие агат-программисты начинали своё творчество ещё будучи школьниками. И мы агат видели как единственно возможную систему. Это же был СССР, времена дефицита, в том числе ВТ ... Есть агат и не было даже мыслей о том, что его оборудование кто-то будет как-то развивать, что надо будет думать о совместимости. Что сам написал или спаял - то и будет у тебя.

> А как в окне $F000..$F7FF вектора обрабатываются, там же BRK, старт?

А как оно может обрабатываться ? Проц вектора запрашивает в адресах FFFA..FFFF.
Так что это окно не имеет к ним отношения.

> Я стараюсь хитрые вещи обходить...

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

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

Это всё будет работать, да.
Но если вам встретится странный драйвер, который действует совсем не так (но тоже работает нормально), то знайте:
регистр в этом контроллере всего один. Он читается по любому из 16 адресов.
Но обращение на любой из 16 адресов переключает один из 8 бит управления (чётный адрес выключает, нечётный - включает бит, номер которого указывают линии A3..A1 шины адреса).

Поскольку автомат управления контроллером как раз и управляется 3 из 8 бит управления (ещё 4 идут на управление двигателем головки и ещё 1 выбирает один из двух приводов), то любое чтение или запись могут менять режим работы контроллера.
И, например, чтение датчика защиты записи обязательно, так как это тоже переключение автомата для правильного вход в режим записи.

Контроллер вообще не интересуется - успевает ЦП читать что-то там или нет: набрался байт с дискеты в регистр - ок, начался следующий байт - старый сбрасывается, набирается следующий. Кто не успел - тот опоздал.

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

Подробности про контроллеры 140 или 840:
http://agatcomp.ru/agat/Hardware/DZU.shtml
Там есть что почитать, если надоело смотреть в схему.

а потом косяки уже разработчиков софта

велосипедисты  - беда того времени.. есть такой компьютер Орион-128, так там вообще контроллеры ФДД висят на разных портах.. в разных ОС, я комп-то синтезировал, а потом смотрел на него как баран, не зная что с этим огородом дальше делать.

А как в окне $F000..$F7FF вектора обрабатываются, там же BRK, старт?
Кстати, сигналы f и onrom я сделал как в реальном Агате, те с использовантием кода оригинальных ПЗУ, то у меня тоже есть это окно, как его проверить?

Проверил, действительно по F000 и F800 одни и теже данные..

Я стараюсь хитрые вещи обходить, если это возможно, многие из них внутри наворочены до безобразия, а "наружу" выходит 3 бита и байт данных как с контроллером 840 кБ, главное понять когда и как.

Я тут подумал над wire free_slot = c200 | c400 | c500 | c600; и удалил это кусок совсем. Теперь, когда процессор читает, если нет ответа от слотов или устройств, всегда получает старший байт адреса.

T65(b) core

Как бы там не было, но пока я разбирался/писал код его железа, проникся его крутостью, это очень хороший компьютер, его наработки есть и в Орионе и в Векторе  и еще много где. На основе контрукции его блоков, с использованием других процессоров, получились бы огонь машинки. Хотя время было такое, что мы не понимали: где хорошо, а где плохо, да и не только мы, вон, на Коммодор посмотрите, его контроллер ФДД это второй Коммодор, но его любят и лилеют.

Короче, хочу доделать и выложить на гитхаб. Стараюсь не использовать особенности Альтерры, чтобы легко переносить на любые ПЛИС.

И это - не единственный сюрприз.

Вот ещё один: в реальной девятке есть два окна сисмона: $F000..$F7FF и $F800..$FFFF.
Второе - документирование, а вот первое - нет. А мне доводилось встречать софт, хоть и редко, который ссылался на процедуры сисмона именно по первому окну.

А вот почему быстропускалка (example10, example20) не заработали (а сейчас они работают?) - это уже интересный вопрос для меня, как автора их кода ;)).

С0F0 - я не помню, можно оттуда что-то читать или нет. Скорее всего нет.
Так что возвращайте всё ту же $C0.

Вот ещё заметка: порт клавиатуры описан у обеих (7 и 9) одинакого: старший бит - готовность порта, остальные биты - код.

Но в схемотехнике есть одна особенность: после очистки регистра клавиатуры (обращение на C01x) у семёрки все биты сбрасываюся в 0, а у девятки - только старший бит. Некоторые проги (редкие, по счастью) к этому небезразличны.

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

/* Кстати, а знаете что у девятки можно читать регистр управления ДК ? Не помню, говорится об этом в инструкции или нет. У семёрки - нельзя, будет просто возвращать $FF. */

А уж что будет, если воссоздавать агат заного, на плисах или ещё как-то - там ещё на три романа всплывает всякого разного.

А вот ещё интересное: в доках пишут, что обращение к C03x вызывает перемещение мембраны динамика, одна команда - в одну сторону. Но это не так: перемещение происходит в каждом такте, в котором ЦП обратился к C03x. Но в разных командах ЦП делает разное число обращений. Бывает одно, бывает два. Можно и три сделать.

Я когда первый эмулятор агата писал (который досовкий), тоже только в доки смотрел. Но когда начал только разбирать схемотехнику контроллера 140к, понял, что проще с нуля код переписать, чем что-то исправить - этот контроллер много-много более хитрый, чем описывает инструкция.

У агата довольно сложная схемотехника и подводных камней полно как для программистов так и для разработчиков железа.

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

Запиши и прибей на стену:

Это бы разместить не только тут, а на сайте, где лежат схемы к Агатам. Я объяснюсь, вот смотрю схему и не понимаю почему ответ на С08х должен содержать в старшем бите 1? У Д54 есть только 3 выхода: 0, 1 и 3 бит, откуда 7 бит в 1? Были бы подтягивающие резисторы в ШД, было бы ясно почему. Ну хорошо, может какие из микросхем имеют подтяжки? Какие есть микросхемы на шине: 555ИР22, читаем даташит - Z состояние, ИР23 - тоже самое, я обыскался эту 1. Что оказалось? Хак связанный с емкостной составляющей этого узла. Ответ узнал из вашего сообщения в теме по ремонту Агатов, как только сделал wire free_slot = c200 | c400 | c500 | c600; Агат заработал без глюков, но про С0хх там не было, от того и возвращаю 0.
Есть вопрос, что должен вернуть С0F0? тоже С0?

> по всему диапазону (кроме фдд С0В0) возвращаются 0.
> Похоже на сбой с бегущей вверх звездочкой, бипером и выводом на экран BRK по 03FD.

с040 - включение таймера, если у тебя только сисмон в памяти, то всё просто зависнет (что мы и наблюдаем).
Но вопрос не об этом, вопрос в том, что процессор получит при чтении этого порта ?

Объясняю подробно:
алгоритмы определения оборудования ожидают вполне конкретные ответы от установленных устройств.
Если ответы соответствуют известным (например, контроллер дисковода опознаётся по 0 2 4 байтам ROM загрузчика сисмоном и по 4 последним байтам - при поиске некоторыми операционками),
то считается, что устройство присутствует. Иначе - отсутствует. Но это с контроллером флопа всё легко и просто - вряд ли 3-4 байта совпадут в случае отсуствия контроллера.
Для других устройств опрос иногда делается по одному байту. Если у тебя отствутвующие устройства будут отзыватся нулями или ещё каким-то случайным образом, алгоритмы могут глючить. Они и так-то могут глючить (например, пресловутый ИКП может стать неадекватным, если не найдёт ячейку принтера, но это не всегда (известная ошибка в его коде)), а уж на нестандартной аппаратуре - тем более.

Запиши и прибей на стену:

- У агат-7 любой порт, бит порта (даже не байт!) который не отвечает на запрос, возвращает 1. Например, порт кнопки джойстика использует только старший бит, он выставляется с кнопки пульта. Другие биты этого регистра будут 1. Если с040 включает таймер - это не значит, что кто-то при этом управляет шиной данных, а значит ЦП получит оттуда 0xFF. И т.д. Это обеспечивается группой pullup-резисторов на модуле ЦП.

- У агат-9 почти то же самое, за исключением того, что там разработчики сьэкономили 8 pullup-резисторов и поэтому проц при чтении неотвечающих портов, получает последнее состояние ША (т.е. из предыдущего такта). Как правило это будет старший разряд адреса. Т.е. у тебя c040 должен читаться как 0xC0, c800 - 0xc8 и т.д. Теоретически, в зависимости от команды чтения, наверное можно получить и другие значения, но обычно к Сxxx обращаются командами косвенной адресации, так что возвращать старший байт адреса в любом случае вполне хорошо.

Это касается, кстати, и регистра управления LC : C08x. Если посмотришь схему, там возвращается только 3 или 4 младших разряда, соответственно, остальные будут возвращаться из того же байта 0xC0.

Лисин этого не будет проверять, его вообще мало что интересует кроме модулей ДопОЗУ и базового ОЗУ. А вот операционки могут вести себя внезапно.

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

по регионам C090..C0FF

по всему диапазону (кроме фдд С0В0) возвращаются 0.

Похоже на сбой с бегущей вверх звездочкой, бипером и выводом на экран BRK по 03FD.

example20.dsk, остановилось на этом:

example30.dsk, остановилось на этом:

регионы памяти:

example40.dsk:

как у тебя реализован регион C000.CFFF ?

Если я правильно понимаю, то имеется в виду, что возращается процессору в случае обращения по пустым слотам:

// free slots
wire free_slot = c200 | c400 | c500 | c600;
..
dii <= free_slot ? addr[15:8] : ...

Если слот не пустой, например Диспетчер памяти или LC, то возвращается либо подключеный банк памяти:
С110
С110 - 11
либо конфиг LC.