Значит на GATE приходят импульсы. Там кроме системного ресета ещё какой-то импульс через кондёр заведён...
Пока логгером посмотреть не могу.
Вид для печати
возвращаясь к тесту, где у меня FFFF в 01 и 05 режиме.
Я не могу понять каким образом там получается A10B (на оригинале), когда как там заносится значение FFFF в счетчик и сразу же считывается. Как?? как он успевает дотикивать до A10B??
- - - Добавлено - - -
я посмотрел по схеме. Ничего там кроме ресета не заведено. Да и стремно было бы если на ресет какие-то импульсы приходили бы.
Но при всём при этом я не понимаю как там после заноса FFFF в счетчик и считыванием в следующей комманде получается A10B... Не успеет он так быстро дотикать.
- - - Добавлено - - -
b2m,
в чем секрет такой скорости в режимах 1 и 5?
Ты смотрел схему Вектора 02го ?
D65.06 -> D66.13
KTSerg,
хм.. у меня схемы все от первой версии.
где взять 02?
p.s. нашел
- - - Добавлено - - -
у меня плохая схема 02.. числа очень плохо видны :(
- - - Добавлено - - -
Тут даже если на gate что-то тикает (в чем я сильно сомневаюсь), получить A10B сразу после записи в счетчик просто невозможно!
Я немного подправил тест i8253.
В нём первоначально сразу после записи в счётчики считывались значения, потом ожидание двух прерываний и снова считывание (вторая пара).
Я исправил, что-бы считывал сразу два раза без прерываний.
Получилось, что во всех режимах разница между первой и второй парой одинакова, но счёт в режимах 1 и 5 начинается не с записанного FFFFh а с A111h !!!
Вот попробуй, когда запустятся 1й и 5й режимы, у меня на реале такой результат:
FFF9 00
FFD5
A10B 01
A0E7
FFF9 02
FFD5
FFF4 03
FFAC
FFF9 04
FFD5
A10B 05
A0E7
FFF9 06
FFD5
FFF4 07
FFAC
KTSerg,
у меня совпадает с твоими данными за исключением 1 и 5 режимов. В 1 и 5 у меня FFFF всегда, ибо в доках сказано что счет начинается только когда GATE переходит из состояния 0 в 1. Других данных у меня нет. Я даже не знаю что можно сделать.
А ты можешь еще исследовать 1 и 5? Например, замени в tst8253 режим на 1 или 5. Посмотри какие значения будут считываться.
Тут бы b2m помог. У него в EMU тесты как на реальном железе показывают.
Но он пока молчит...
- - - Добавлено - - -
о! наткнулся на тему про ви53.
там svofski пишет:
"Еще интересный момент, который не выкопаешь ни в какой доке. После первого теста в режиме "0" счетчик продолжает считать. Дальше тест программирует его на режим "1" и загружает в него значение $FFFF. Но, поскольку сигнал GATE в Векторе всегда "1", это число не переписывается во внутренний счетчик и счет продолжается как будто бы записи не было. Самое занятное в том, что операция установки режима в "1" все же останавливает счетчик, а загрузка значения, которое в него так никогда и не попадает, продолжает счет. "
Вот, это похоже на правду :)
- - - Добавлено - - -
Получается, что если Gate=1 то при переключении режима на 1, останавливает счет, а занесение любого значения в счетчик продолжает счет со старого значения. Типа, бага..
В доках, кстати, диаграммы рисуют варианты запуска режима 1(и 5) когда GATE=0 вначале, а потом переходит в 1.
- - - Добавлено - - -
в общем, сэмулировал я этот глюк.
Но вместо A10B у меня A109. И в десятичном тесте тоже на 2 меньше.
Где-то я не задерживаю достаточно.
Попробую отыскать эти 2 такта.
Да, скорее всего это так и есть.
Я уменьшил начальные значения счётчиков с FFFF на AAAA и все считанные значения уменьшились пропорционально, похоже что в 1 и 5 режимах новые значения действительно не записываются.
Посмотрел схему от простого Вектора, там GATE = системный сброс, просто вырабатывается. На схеме 02го там ещё чего-то дополнительно накручено... пытался разобраться... утонул в развилках...
- - - Добавлено - - -
Я логгером осматривал ВИ53ю может это поможет.
Дело в том, что сигнал CS длится 2 такта CLK.
Может счёт останавливается на нём?
- - - Добавлено - - -
Верхний график это CLK.
Ниже GATE.
Потом CS, RD, WR.
Не бага, а фича :)
Мы же вроде разобрались выше, что установка режима останавливает счёт, а загрузка делителя - разрешает. Вот только загружается не сам счётчик, а регистр, откуда в режимах отличных от 1 и 5, загружается счётчик (либо сразу после загрузки делителя, либо когда он доходит до нуля). Особенность режимов 1 и 5 в том, что счётчик загружается из регистра (куда загружен делитель) по фронту gate (т.е. аппаратный строб). До этого момента он просто продолжает считать дальше, даже когда дойдёт до нуля. А срабатывание таймера, а именно заём переноса при переходе через ноль, в этих режимах на выходе никак не отражается, пока не было строба запуска.
Т.е. схематично можно изобразить канал таймера как: [регистр делителя] -> [счётчик] -> [регистр latch]
Пишем мы в регистр делителя, а читаем из регистра latch.
Вспомнил блин - "в схеме 02го к системному сбросу ещё намешано", это схема автоматического системного сброса после загрузки программы... Т.е. пока ПЗУ подключена можно ещё и программно, через порт, системный сброс организовать...
Ramiros,
а эту демку можно без FDD запустить? Как вариант с квазидиска?
- - - Добавлено - - -
это фича для всяких детекторов эмулятора.
А если с точки зрения полезности- то это бага. Счетчик в режимах 0,1,4,5 не останавливается в конце, как должно быть. Более того в режимах 1 и 5 счет возобновляется без строба GATE. То есть с точки зрения программной, использовать такой чип нельзя. Нельзя проконтроллировать был ли GATE строб, например. А так же нельзя проверить дотикал ли счетчик до 0.
Глюк на глюке...
С точки зрения полезности, режимы с аппаратным стробом вполне выполняют свою миссию: загружаем делитель, и после поступления строба на gate сигнал на выходе появится через заданное нами время. Больше от этих режимов ничего не требуется. В конце-концов, это таймер, а не счётчик. Чтение внутреннего значения счётчика - это просто фича, которая может пригодиться в некоторых случаях.
Точно нет. SkyNet пользуется квазидиском как расширением памяти и подгружает части с дискеты. Как вариант можно делать дамп памяти в эмуляторе когда загружена нужная часть, патчить запуск и заливать полученный препарат в свой эмулятор. С какими-то программами я так делал.
Буду думать на счет FDD. Слишком муторно его эмулировать из-за отсутствия стандартного ПЗУ.
svofski,
В какой момент сдвиг экрана прописывается в регистры? У меня в PDIZZY на начальной заставке экран сдвинут на пополам. Потом следующая заставка нормально. А когда игра начинается, то опять пополам экран.
- - - Добавлено - - -
фигня какая-то непонятная с этим PDIZZY.
На первой заставке и в самой игре игран сдвинут наполовину, и ничего не помогает. Пробовал прописывать сдвиг перед началом отображения непосредственно битов дисплея. Потом в момент приходя кадрового импульса. Потом в момент окончания кадрового импульса. Ничего не помогает.
- - - Добавлено - - -
Я так понял, что если я закину весь образ диска в SDRAM, то эмуляция ВГ93 сильно упростится. Можно взять модуль WD1793.v и сделать так чтобы просто читать SDRAM согласно CHS.
- - - Добавлено - - -
в PDIZZY непонятная фигня. Если нажать одну из курсорных кнопок, то изображение правильное. А при отпускании опять наполовину сдвигается.
- - - Добавлено - - -
судя по SignalTap, момент фиксации сдвига экрана должен быть в начале следующей строки после начала VSync. PDIZZY держит регистр сдвига примерно с 630 пиксела (всего 768) строки где начался VSync до примерно 320 пиксела следующей строки.
Правда, во время игры почему-то проскакивают кадры где регистр сдвига не выставляется и на экране мелькает сдвиг в этот момент.
Что ей не хватает?
- - - Добавлено - - -
нет.. я был не прав.. Я думал что FE это смещение, но оказалось что это часть опроса клавиатуры. После опроса клавиатуры выставляется 7F и держится весь кадр. После VSync прогоняется ноль по этому регистру последовательно (опрос клавы)и в конце опять 7F на весь кадр.
А ведь должно быть FF. Почему игра выставляет 7F??
- - - Добавлено - - -
разве что используется трюк с переключением выхода ВВ55 на вход и использованием резисторов подтяжки на 1.
- - - Добавлено - - -
Нет.. не используется этот трюк.. При опросе клавы режим 8A, а после - 88. Всё стандартно. При этом запись в порт 3 только при опросе клавиатуры.
Регистр сдвига просто не записывается никогда.... Что за бред?
регистр 03 он выбирает строку для сканирования клавиатуры, и в это же время задает смещение экрана (регистр двойного назначения), но т.к. опрос клавы всегда выполняется во время обратного хода луча, то безобразия с экраном не видно, а когда кадр уже рисуется лучем клавиатура уже прочитана.
Такие глюки чаще бывают, если 580ВВ55 эмулируется не полностью или с ошибками.
Ramiros,
учитывая что эмулятор у меня практически рабочий, то мне конечно же известна особенность двойного назначения этого порта.
Однако, это не объясняет почему PDIZZY не заносит смещение экрана после сканирования клавиатуры. Какие могут быть хитрости работы с регистром смещения? На ум приходит переключение порта 3 на ввод, что аналогично выводу FF в порт 3. Однако, это не так. Режим прописывается 88.
Я не понимаю как экран может быть в правильном положении если в порту торчит число 7F.
0E24 mvi a,88h
0E26 out 0
в порте 3 остается 0
ivagor,
Установка режима сбрасывает порты в FF?
Поленился смотреть даташит, цитата из
Щелкунов, Дианов "Микропроцессорные средства и системы", стр. 99
При записи нового управляющего слова все буферные регистры портов устанавливаются в 0
Так, но у меня еще добавлена задержка
https://github.com/svofski/vector06c...7eb53a74f2e1d5
почему я это сделал, хоть убей не могу вспомнить. Скорее всего это были не навороченные демки, а какая-то с виду безобидная программа, которая например слишком много времени проводила в обработчике прерывания и делала загрузку скролла в самом конце. Одна из таких зловредных программ, кстати, это Бейсик Корвет. Там как-то очень странно опрашивается клавиатура. Помню, что он долгое время у меня дергался экраном, пока я что-то не сделал. Может быть это оно и есть.
Таки да, нашелся, причем аж в 2009. На данный момент в vv и v06cc все ОК, в emu разница на 4 такта.
Имеется ввиду линия с битами, или линия бордюра?
Я пока сделал в начале отображения именно линии с битами.
Как вообще лучше называть часть экрана с битами для краткости? Экран, дисплей - это общее название включающее и бордюр...
- - - Добавлено - - -
ivagor,
я не понял что должно происходить на экране. Там говорится про какие-то скачки. У меня ничего не скачет и картинка идентична первой по вашему линку.
На emu от b2m та же самая картинка и ничего не скачет.
- - - Добавлено - - -
а... нашел кнопки управления в этом ребусе :)
у меня так же как в реале получается:
1й скачок - из 13 в 14
2й скачок - из 17 в 18
- - - Добавлено - - -
svofski,
Я видел эту конструкцию у вас. Выходило что запись происходит где-то в строке, когда уже выводятся биты. Мне показалось это странным.
- - - Добавлено - - -
svofski, b2m
наверное вопрос к вам. По поводу FDD.
Какой размер сектора используется в Векторе? Наверное, стоит уточнить: какой размер сектора используется в имиджах FDD?
Есть ли у FDD файла заголовок и где взять описание если заголовок имеется?
Я потому и не советую. Когда я делал свой Вектор, информации было очень мало, все приходилось собирать по крупицам. Не было ни тестов, ни реала, эмуляторы тогда были все только глючные. Даже схем было не найти. Поэтому у меня залипло много артефактов, результатов поиска на ощупь. Эта задержка как и та, что в прерывании, странная и может быть их вместе можно сократить одну с другой.
Хорошо бы иметь настоящий большой тест, в котором собрано все вместе. Тогда можно было бы быстро проверять, сломал чего-то, или нет. А так это минное поле.
- - - Добавлено - - -
Про флоп:
https://github.com/svofski/vector06c...ware/floppysrc
fddimage.h описывает заголовок
fddimage.c собственно
config.h определяет в частности размер сектора. Вроде бы он мог быть разным, но фактически образы fdd все 1024.
это заголовок вашей внутренней структуры, а не файла.
Судя по коду, у FDD нет заголовка, а конфигурация фиксированная:
а количество трэков вычисляется делением длины файла на длину трэка в байтах.Код:#define FDD_SECTOR_SIZE 1024U
#define FDD_NSIDES 2U
#define FDD_NSECTORS 5U
#define SECTOR_SIZE_CODE 3U // 0 = 128, 1 = 256, 2 = 512, 3 = 1024
Еще вопрос возник:
а нужно эмулировать задержки готовности позиционирования на трэк и времени поиска сектора?
Просто я планирую работать с образом, который целиком в SDRAM. Естетсвенно, задержек тут быть не может.
А вот как программы на это будут реагировать?
Еще думаю сделать чтение данных сектора в ритме как читает их прога в Векторе. То есть без потери данных если не успела.
А, ну да. Сам файл вообще просто данные сплошным потоком. Задержки вроде не должны быть важны, у дисковода они тоже не жесткие.
svofski,
сначала в файле идет side=1 а потом side=0?Код:uint32_t offset = FDD_NSIDES*fdd->cur_track + (1-fdd->cur_side);
нумерация секторов с 1?Код:offset += fdd->cur_sector - 1;
вообще расположение данных в FDD имидже получается так:
байты 0-1023
сектора 1-5
стороны 1-0 (наверное 1-2?)
Трэки 0-(сколько влезет)
правильно?
Saar, мне сейчас ответить на этот вопрос не проще, чем случайному прохожему с улицы =)
Но вроде все сходится.
задержки важны, иначе куча прог не заработает
svofski,
в wd1793.v выключена поддержка мультисекторного чтения/записи. Оно нигде в Векторе не используется?
- - - Добавлено - - -
Ramiros,
понятно.. Но я пока без задержек сделаю чтобы просто концепт отладить. Потом добавлю задержки.
- - - Добавлено - - -
нет ли каких тестов контролера дисков?
Что-нить ввиде ROM, который читает что-то посекторно и всякие биты готовности опрашивает?
Ответ про мультисекторность дать невозможно. Наверное мне не попадалось. Может быть там есть какие-то проблемы с этим связанные, может быть просто почему-то не практично.
Про тесты дисковода не слышал. Но если загрузчик долетел до конца, значит уже почти все работает. Он читает что-то посекторно и биты готовности опрашивает. Для отладки я печатал в последовательный порт.
svofski,
zagr512.hex поддерживает загрузку с FDD?
Там должно быть изображение дискеты если ВГ93 правильно работает?
- - - Добавлено - - -
svofski,
На вашем эмуляторе SkyNET демка работает?
Да.
Да.
Да.
Блин... нужна дисковая утилита, которая позволяет читать заданный сектор на диске и выводить его дамп на экран.
Вроде частично заработало, но не могу понять проблему. Даже SkyNET запускается, но до первого обращения к диску. Потм ошибки сыпятся.
У меня нет возможности выводить лог в UART. Есть возможность смотреть только в SignalTap, но его недостаточно.
А вот утилита типа какого-то редактора диска очень помогла бы. Только естественно ее загрузить смогу либо из ROM либо из EDD.
- - - Добавлено - - -
Удалось пофиксить одну из проблем. Теперь микродос из EDD не выдает ошибки при запуске. Читает каталог и запускает проги.
SkyNET всё так же выдает "отсутсвует файл TDEMO1.SN0".
Ramiros, Судя по автаре, вы - один из создателей Skynet демки? В чем там загвоздка в поиске этого файла?
- - - Добавлено - - -
вот ошибка:
Вложение 56242
T - это наверное трэк. S - сектор.
O - номер ошибки? Что такое 46 ошибка?
ST - ???
Странно что на 0 дорожке 1 сектора какая-то ошибка. Не думаю, что диск загрузился бы если бы там была ошибка...
Saar, поздравляю! Это уже очень много.
Хорошо бы иметь возможность посмотреть на тот кусок кода, который грузит TDEMO1.SN0. Скорее всего эмулятор слишком быстро выставляет бит готовности операции, а там цикл ожидания завершения написан в расчете на то, что начальное состояние "не готов".
svofski,
наверное, проще сначала ошибку МикроДОС пофиксить. Может тогда и SkyNet заработает.
Вы расшифровать текст ошибки со скрина можете?
- - - Добавлено - - -
эх... утилиту бы для чтения посекторного...