Т.е. глюк как бы плавающий, и нет конкретных дисков или программ, где он проявляется стабильно?
Т.е. глюк как бы плавающий, и нет конкретных дисков или программ, где он проявляется стабильно?
Во вложении -- UkncComSender.exe плюс исходник от него.
Скрестил то что было в SAV2WAV со своими тестами Стык С2, заглядывая в описание Алексея (UKNC_TAPE.doc).
Работает так:
1. Используя драйвер com0com (http://sourceforge.net/projects/com0com/) создаём и соединяем два виртуальных порта -- на один настраиваем эмулятор, во второй будем высылать SAV-файл.
2. Запускаем UkncComSender, указав два параметра -- имя COM-порта и название SAV-файла.
3. Стартуем эмулятор, выбираем загрузку из Стык С2.
Действие программы такое же как у SAV2WAV: в первый 512-байтовый блок вставляется короткий загрузчик, который догружает хвост файла и запускает его.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.
Код загрузчика пока корявый, но работает -- 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 ; Запускаем загруженную программу
Последний раз редактировалось nzeemin; 05.11.2011 в 01:53.
На вход вроде работает правильно теперь (прерывание не проверял).
На выход по прежнему неправильно: прерывание возникает в момент записи в регистр данных, а не когда регистр даннных готов принять байт.
Само прерывание происходит по непонятному вектору.
RESET по прежнему не сбрасывает бит разрешения прерываний (как минимум для 176574).
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Вектора работают правильно.
У 176574 бит 6 (100) сбрасывается по RESETу как и положено.
У 176570 не сбрасывается.
Осталась мелочь и можно будет связывать.
Момент возникновения проще вычислять в аппаратных принципах: прервание возникает сразу же как устанавливается 7 бит (200).
7 бит устанавливается как только в буфере COM порта (или того что в него отсылает) есть место для символа.
Это касается 176574/176576 всмысле, у 176570/176572 все нормально.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
При абстрактной эмуляции выставления запроса IRQ на шину Q-Bus (без отдельной эмуляции запроса вектора) я учитываю (и всем рекомендую учитывать) следующие аппаратные параметры:
Если за то время, пока прерывания в процессоре были запрещены, успело поступить несколько запросов прерываний от разных устройств, то после разрешения обработки прерываний - первым обсуживается тот запрос, который пришёл по линии BR с большим номером и от того устройства, которое расположено на этой линии BR ближе к процессору.Код:bool SetIRQ( word uVector, word uBR_Line, word uBR_LinePosition, bool bClearedByInit = true )
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)