УКНЦ загрузка через стык С2

[Titus]

Т.е. глюк как бы плавающий, и нет конкретных дисков или программ, где он проявляется стабильно?

[nzeemin]

Во вложении -- UkncComSender.exe плюс исходник от него.
Скрестил то что было в SAV2WAV со своими тестами Стык С2, заглядывая в описание Алексея (UKNC_TAPE.doc).

Работает так:
1. Используя драйвер com0com (http://sourceforge.net/projects/com0com/) создаём и соединяем два виртуальных порта -- на один настраиваем эмулятор, во второй будем высылать SAV-файл.
2. Запускаем UkncComSender, указав два параметра -- имя COM-порта и название SAV-файла.
3. Стартуем эмулятор, выбираем загрузку из Стык С2.

UkncComSender.exe COM9 vert.sav

Serial port COM9 opened.
Serial port configured.
Opening the input file vert.sav...
Reading the first block...
Waiting for byte 0100...
0x40
Sending loader...
Sending data ...............
COM port closed.

Действие программы такое же как у SAV2WAV: в первый 512-байтовый блок вставляется короткий загрузчик, который догружает хвост файла и запускает его.

Код загрузчика пока корявый, но работает -- VERT.SAV из примера у меня запустился.

000000  000240         NOP               ; Опознавательный знак
000002  000447         BR      000122    ; Запуск загрузчика

000122  012701 001000  MOV   #001000,R1  ; Адрес куда считывать остаток файла
000126  013702 000324  MOV   @#000324,R2 ; Длина остатка в словах
000132  006302         ASL   R2          ; Длина остатка в байтах
000134  105737 176570  TSTB  @#176570    ; Приемник готов ?
000140  100375         BPL   000132      ; Нет
000142  113721 176572  MOVB  @#176572,(R1)+  ; Переслать принятый байт в память
000146  077206         SOB   R2,000132   ; Продолжаем пока не прочитали всё
000150  013706 000042  MOV   @#000042,SP
000154  013707 000040  MOV   @#000040,PC ; Запускаем загруженную программу

[form]

Во вложении -- UkncComSender.exe плюс исходник от него.

А сам C2 в эмуляторе нельзя починить?
Я тут писал уже что не работает - совсем мелочи остались

[nzeemin]

Хотя может и в прошлой неправильно было - на вход я его под VTCOM проверял, а вот на выход уже (после нерабочести VTCOM) тестил через ODT, а сейчас и на вход в ODT попробовал и обнаружил, что прерывание происходит сразу независимо от бита 6 в CSR.

Во вложении -- вариант где бит учитывается, попробуйте пожалуйста.

[form]

Во вложении -- вариант где бит учитывается, попробуйте пожалуйста.

На вход вроде работает правильно теперь (прерывание не проверял).
На выход по прежнему неправильно: прерывание возникает в момент записи в регистр данных, а не когда регистр даннных готов принять байт.
Само прерывание происходит по непонятному вектору.
RESET по прежнему не сбрасывает бит разрешения прерываний (как минимум для 176574).

[nzeemin]

На вход вроде работает правильно теперь (прерывание не проверял).
На выход по прежнему неправильно: прерывание возникает в момент записи в регистр данных, а не когда регистр даннных готов принять байт.
Само прерывание происходит по непонятному вектору.
RESET по прежнему не сбрасывает бит разрешения прерываний (как минимум для 176574).

Вектор поправил, сброс поправил, про момент возникновения прерывания -- пока думаю.

[Advertiser]

[form]

Вектор поправил, сброс поправил, про момент возникновения прерывания -- пока думаю.

Вектора работают правильно.
У 176574 бит 6 (100) сбрасывается по RESETу как и положено.
У 176570 не сбрасывается.

Осталась мелочь и можно будет связывать.
Момент возникновения проще вычислять в аппаратных принципах: прервание возникает сразу же как устанавливается 7 бит (200).
7 бит устанавливается как только в буфере COM порта (или того что в него отсылает) есть место для символа.
Это касается 176574/176576 всмысле, у 176570/176572 все нормально.

[Patron]

Момент возникновения проще вычислять в аппаратных принципах: прервание возникает сразу же как устанавливается 7 бит (200).

Прерывание возникает и у устройства с разрешёнными прерываниями (установлен бит 6) при достижении готовности (установка бита 7), и у готового устройства (установлен бит 7) при разрешении прерываний (установка бита 6).

[form]

Прерывание возникает и у устройства с разрешёнными прерываниями (установлен бит 6) при достижении готовности (установка бита 7), и у готового устройства (установлен бит 7) при разрешении прерываний (установка бита 6).

Это то же самое только другими словами
Просто не упоминал разрешение так как его уже обсуждали.
Ну и про приритет (точнее "приоритет") CPU не упоминал как про очевидное

[Patron]

Ну и про приритет (точнее "приоритет") CPU не упоминал как про очевидное

При абстрактной эмуляции выставления запроса IRQ на шину Q-Bus (без отдельной эмуляции запроса вектора) я учитываю (и всем рекомендую учитывать) следующие аппаратные параметры:

bool SetIRQ( 
              word uVector, 
              word uBR_Line, 
              word uBR_LinePosition, 
              bool bClearedByInit = true
           )

Если за то время, пока прерывания в процессоре были запрещены, успело поступить несколько запросов прерываний от разных устройств, то после разрешения обработки прерываний - первым обсуживается тот запрос, который пришёл по линии BR с большим номером и от того устройства, которое расположено на этой линии BR ближе к процессору.