По современным меркам думаю, что совсем смешные. Польза больше от режимов с программным клоком, когда Орион сам драйвит исследуемую схему.Цитата:
Сообщение от Error404
Вид для печати
По современным меркам думаю, что совсем смешные. Польза больше от режимов с программным клоком, когда Орион сам драйвит исследуемую схему.Цитата:
Сообщение от Error404
Если я правильно понял смысл поста, речь идёт о много канальном логическом анализаторе на базе ОРИОНА, причём реализация программная, а не аппаратная. Программная реализация имеет недостатком низкую частоту дискретизации.
Конечно, такое устройство вполне может найти место в лаборатории любителя для отладки устройств на КМОП процессорах. Которые характерны тем, что сохраняют работоспособность при понижении тактовой частоты практически до 0. Тогда, например, вместо поиска ошибок с помощью аппаратного пошагивателя и неудобного ручного контроля шин осцилографом, можно использовать это устройство, подав процессору такт в 10 КГЦ. Кстати, в некоторых случаях пошагиватель не помогает выявить ошибку. Например, у меня при отладке ИРИШИ тестовая программа в шаговом режиме проходила, а компьютер всё-равно не работал (так и не отладил, пришлось собрать второй экземпляр).
Кстати, знайте, что и не-КМОП процессоры могут работать на очень низкой частоте. КР580 у меня работал на такте ~200 КГЦ. А Z80 вообще нормально прогонял программы при тактировании клоком всего лишь в 2 КГЦ (!). А в справочниках написано, что минимальная частота 500 КГЦ.
Т.о, данное устройство может быть полезным при замене низкоэффективного и устаревшего КР580 в ОРИОНЕ (и РК86) на более скоростной 65C02 на такте 25 МГЦ (что эквивалентно Z80 на такте 50 МГЦ). Понятно, что получится совсем другой компьютер, естественно, с непрозрачным ОЗУ. Заметим, что такая переделка намного проще, чем разработка ЭВМ с нуля.
Для 6502 есть возможность перетранслировать некоторые программы КР580, эмулируя недостающие регистры КР580 в Zero Page. И даже команды с адресацией через 16-ти разрядные регистры, без проблем эмулируются (тут к сожалению, 6502 лучше, чем 6800). Таким образом, не так уж сложно (если надо) воспроизвести, например, ORDOS или CP/M и соответственно некоторые программы для них.
К Apple-II в начале 80-тых выпускалась такая периферийная плата, но частотные параметры её высокие. Данные накапливались в скоростном ОЗУ (70 НСЕК), а компьютер служил лишь для управления и визуализации. Возможно, что-то подобное можно самостоятельно разработать и сейчас (например, используя ПДП).
Тут на помощь приходит арифметика. Посчитаем максимально достижимые частотные параметры программной реализации.Цитата:
Сообщение от Error404
Что даёт при такте КР580 в 2.5 МГЦ минимальный период дискретизации 400 НСЕК * 30 = 12 МКСЕК, что соответствует одному периоду частоты 83.3 КГЦ. Это при 8-ми входных линиях и при аппаратной реализации останова (по аппаратному RESET или INT). Если останов на конец буфера сделать программным и ввести 16-ть анализируемых линий, то получается.Код:.
LOOP: LD A,(DE) ; 7
LD (HL),A ; 7
INC HL ; 4
JR LOOP ; 12
; = 30 тактов
Что даёт при такте КР580 в 2.5 МГЦ минимальный период дискретизации 400 НСЕК * 68 = 27.2 МКСЕК, что соответствует одному периоду частоты 36.8 КГЦ.Код:.
LOOP: LD A,(DE) ; 7
LD (HL),A ; 7
INC HL ; 4
LD A,(D8_D15) ; 13
LD (HL),A ; 7
INC HL ; 4
DEC BC ; 6
LD A,B ; 4
OR C ; 4
JR NZ,LOOP ; 12
; = 68 тактов
Приведённые простейшие расчёты показывают насколько необходима замена в ОРИОНЕ КР580 на такте 2.5 МГЦ на Z80B на такте 7.5 МГЦ.
Всё верно. Смысл в том, что для отладки и анализа далеко не всегда требуется работа в реальном времени. В режиме программной синхронизации в качестве клока на испытываемую схему подаётся таковой из программы, т.о. анализ производится на максимальной частоте, которую Орион может сгенерировать в программном цикле.Цитата:
Сообщение от barsik
В системе с процессором такой штукой ловить нечего, т.к. там требует гораздо большее кол-во входов и - главное - нужна ещё и куча выходов, плюс возможность генерировать на них сложные испытательные сигналы. В этом направлении я планирую подумать, но там уже дело пахнет редактором исптытательных сигналов...слишком масштабно для работы "в стол" /-)Цитата:
Сообщение от barsik
"Железная" реализация это клёво, но разрабатывать таковую сейчас смысла нет, т.к. всё равно никто не будет заморачиваться сборкой. А для работы "в стол" это слишком круто.Цитата:
Сообщение от barsik
В данном случае вся фишка в том, что по сути ничего паять не надо: воткнул в порт нужное кол-во проводков и вот тебе готов лабораторный стенд!
- - - Добавлено - - -
Ну вот и замечательно, конструкцию электронных часов с родным клоком 32768 Гц можно испытывать в реальном времени :) Уже профит!Цитата:
Сообщение от barsik
- - - Добавлено - - -
Вот цикл сканирования в скоростном режиме:
В [BC] адрес буфера, C_OVER - старший байт адреса границы буфераКод:LOOP:
LHLD PT_USR
MOV A,L
STAX B
INX B
MOV A,H
STAX B
INX B
MOV A,B
CPI C_OVER
JC LOOP
Может можно сделать ещё быстрее, например через стэк?.. Можно подумать, но выигрыш будет отнюдь не в разы, так что особого смысла и нет. Через стек это, видимо, после взятия данных из портов сразу класть в буфер по PUSH H, в таком случае запись будет обратная (стек растёт вниз), нужно менять всю логику отрисовки, а там своя оптимизация по скорости...
Итого на цикл: 72 такта в циклеЦитата:
Сообщение от Denn
Итого: 51 такт на цикл. Есть смысл.Код:LOOP:
LHLD PT_USR / 16
PUSH H / 11
DCX B / 5
MOV A,B / 5
ORA C / 4
JNZ LOOP / 10
Вряд-ли сейчас кто-то будет делать сложные цифровые конструкции на "рассыпухе". Теперь даже в простейшие конструкции (например, часы) часто ставят микропроцессор, что не только проще, но и улучшает качество. Для отладки простых цифровых конструкций достаточно обычного осцилографа (особенно, если он двухлучевой), а иногда даже традиционного цифрового пробника, если он достаточно грамотный (показывает не только уровни, но и наличие импульсов).
А что насчёт того, чтобы сделать из ОРИОНА осцилограф? Двухлучевой, а может быть даже и скоростной. У меня например осцилограф, хотя и достаточно скоростной, но однолучевой и даже одноканальный. А часто хочется посмотреть сразу два сигнала, чтобы узнать, как они соотносятся. В ж.РАДИО в 80-тые видел схемы внешних коммутаторов, которые, якобы, обеспечивают это.
Если применить ПДП, который тратит 4 такта на байт, то период дискретизации получится в 4*400 НСЕК=1.2 МКСЕК, что соответствует периоду частоты в 625 КГЦ. Т.е уже можно более-менее точно рассматривать сигналы частотой до 200 КГЦ. А если использовать не ОРИОН, а РК86, где, во-первых, ПДП уже есть, а во-вторых, в РК можно тактировать ПДП максимально высоким тактом, это дополнительно увеличит разрешение.
Это да. Просто потому, что разработчиков МП-железа, которым анализатор был бы полезен, - очень мало. А вот осцилограф нужен, если его нет у любителя. Скоростной аппаратный осцилограф из ОРИОНА будет сделать разумно, если для этого будет достаточно лишь спаять платку с 10-ю микросхемами (одна из которых скоростное КМОП-ОЗУ 10-25 НСЕК). Это будет менее громоздко, чем иметь реальный осцилограф. А низкоскоростной программный осцилограф, это вообще не требует труда (достаточно изготовить высокочастотный пробник с полевиком на входе).Цитата:
Сообщение от Denn
- - - Добавлено - - -
Со стеком лучше так:
Останов делается не программным, а за счёт аппаратной ловушки на запись по адресу 0000 (отчего возникает INT или RESET). Период дискретизации будет: 39*400= 15.6 МКСЕК, что соответствует периоду частоты 64 КГЦ.Код:.
LOOP: LD HL,(PORT_A) ; 16
PUSH HL ; 11
JR LOOP ; 12
; = 39 тактов
Имхо, что 37 кГц, что 64 - одна малина. Все МПС-процессы имеют скорости от мегагерцев, так что до реал-тайма недостижимо далеко.Цитата:
Сообщение от barsik
Актуальнее всё же синхронный режим.
Понятно, что отладка МП в реальном времени на программной версии анализатора невозможна. Поэтому я и указал, что это удобно только для систем, где на время отладки можно поставить очень низкочастотный такт CPU, отчего быстродействие логического анализатора перестаёт играть роль. Причём желательно, чтобы в системе ОЗУ было статическое. Естественно, если в системе динамическое ОЗУ регенерируется за счёт частых обращений к ОЗУ процессора или видеочасти, то отлаживать его на низкой скорости невозможно. Программный анализатор (осцилограф) непригоден для отладки МП-железа на динамическом ОЗУ. Так что сам ОРИОН с помощью такого анализатора не отладить. А программ реального времени практически нет (это только работа с НГМД или магнитофоном), даже для IDE-винчестера скорость обмена данными не важна.Цитата:
Сообщение от Denn
А чего идея осцилографа Вам не интересна (это же даже проще)?
Зря Вы не хотите делать аппаратную реализацию. Хотя-бы прикиньте, во что это может "вылиться", хотя бы для осцилографа. Переключаемый генератор 20/10/5/2.5 МГЦ, банка ОЗУ 20-70 НСЕК, скоростной счётчик в 8 разрядов. 8-ми разрядный мультиплексор (коммутирует адреса ОЗУ между счётчиком и CPU), буфер шины данных и немножко логики. Кажется, ничего особо сложного.
Кстати, для программного осцилографа вовсе не нужно читать 16 линий, стек не нужен и годится скоростной линейный участок в 256 таких команд:
Что даёт период дискретизации соответствующий периоду частоты 125 КГЦ. А если у Вас ОРИОН с тактом 7.5 МГЦ, то будет 375 КГЦ. Совсем неплохо. Только старт программы "захвата" надо делать аппаратно, а именно - по синхроимпульсу сбрасывать READY (или даже HOLD) для КР580.Код:.
LD A,(DE) ; 7
LD (HL),A ; 7
INC HL ; 6
; = 20 тактов на байт
А если накапливать отсчёты в сдвиговом регистре, то читать его надо частотой в 8 раз ниже, отчего получится период дискретизации осцилографа соответствующий частоте в 1 МГЦ. А если регистр 16-ти разрядный и использовать стек, как в примере предыдущего поста, то получится не менее 1.5 МГЦ. Заметьте, речь о программном осцилографе.
Стартовая версия ТТЛ-анализатора готова, линк внизу вводного поста - http://zx-pk.ru/threads/21984-dsdos-...l=1#post923604
Поддержаны обе платформы: Орион-128 (2,5 МГц) и Орион-ПРО (10 МГц).
Намедни материализовался ответ на этот вопрос (спасибо, Stampmaker!): в самом быстром режиме на Орионе-128 (@2,5 МГц) получилось ровно 25000 измерений в секунду. На Орионе-ПРО это, видимо, будет цифра примерно в 3,5 раз больше. Как-то так.Цитата:
Сообщение от Error404
Решил поразвлекаться с ЖК-индикаторами :)
Подключил к Ориону вот такой - https://www.chipdip.ru/product/wh1602d-ygh-ct-k
Как обычно, интересно было "открывать америку" самостоятельно, разбирался с нуля по даташиту, было весьма увлекательно.
Спаял переходник на порт пользователя (#F600-данные, #F602-управление: С0="Е", С1="RS", C2="R/W"):
https://pp.userapi.com/c638019/v6380...oiJaORNcwE.jpg
https://pp.userapi.com/c638019/v6380...N4mNShfL7c.jpg
https://pp.userapi.com/c638019/v6380...vMYGT0e_30.jpg
Пришлось поколдовать с преобразованием кодировки "на лету", чтобы можно было тексты писать прямо на ассме Ориона:
Код:CONV:
; I: [A]-КОД DSDOS
; O: [A]-КОД CGRAM
CPI 20H
JC ECNV
CPI '\'
JZ S_\
ANA A
RP
SUI 0B0H
JC ECNV
; ПРЕОБРАЗОВАНИЕ КОДОВ A0..FFh
LXI D,TabCNV
MOV L,A
MVI H,0
DAD D
MOV A,M
RET
S_\:
MVI A,60H; '/'
RET
ECNV:
; ОШИБОЧНЫЙ КОД
MVI A,20H
STC
RET
TabCNV:
; тАБЛИЦА ПЕРЕКОДИРОВКИ
DB 3CH,3EH,0D9H,0DAH,0C8H,0C9H,0D9H,0DAH; B0-B7
DB 0DDH,0FBH,7EH,0DFH,0F5H,0EEH,0F4H,0FFH; B8-BF
DB 0B0H,41H,0A0H,0E1H,0E0H,45H,5CH,0A1H; C0-C7
DB 58H,0A5H,0A6H,4BH,0A7H,4DH,48H,4FH; C8-CF
DB 0A8H,0B1H,50H,43H,54H,0A9H,0A3H,42H; D0-D7
DB 62H,0AEH,0AFH,0ACH,0A4H,0E2H,0ABH,0ADH; D8-DF
DB 0C6H,61H,0B2H,0E5H,0E3H,65H,0E4H,0B4H; E0-E7
DB 78H,0B8H,0B9H,0BAH,0BBH,0BCH,0BDH,6FH; E8-EF
DB 0BEH,0C7H,70H,63H,0BFH,79H,0B6H,0B3H; F0-F7
DB 0C4H,0C3H,0B7H,0C1H,0C5H,0E6H,0C0H,0C2H; F8-FF
Далее был некоторый секас с пониманием инженерной мысли по части алгоритма работы, подбор таймингов... в итоге всё получилось:
https://pp.userapi.com/c638019/v6380...lc8wy9BITo.jpg
https://pp.userapi.com/c638019/v6380...pQH3NFoHEY.jpg
https://pp.userapi.com/c638019/v6380...ODUXfKxQMk.jpg
Код вывода символа в индикатор:
Код:C_CURS:EQU 02H; ВЫВОД КУРСОРА
C_BLNK:EQU 01H; МИГАНИЕ КУРСОРА
C_tSET:EQU 1; >39МКС
C_tPWR:EQU 5; >150НС
C_tCYC:EQU 50; >1100НС
PT_DAT:EQU 0F600H; A0..A7
PT_CMD:EQU 0F602H; C0="E", C1="RS", C2="/RW"
PT_CFG:EQU 0F603H; 8Ah: Bx, CL - НА ВЫВОД
IniLCD:
; Инициализация
; НАСТРОЙКА ПОРТА
MVI A,8AH
STA PT_CFG
MVI A,3CH; 0 0 1 1 | N F 0 0
CALL WrtCMD
MVI A,3CH; 0 0 1 1 | N F 0 0
CALL WrtCMD
MVI A,0CH+C_CURS+C_BLNK; 0 0 0 0 | 1 D C B
CALL WrtCMD
; Display Clear
MVI A,01H; 0 0 0 0 | 0 0 0 1
CALL WrtCMD
; Entry Mode Set
MVI A,04H; 0 0 0 0 | 0 1 I/D S
WrtCMD:
; I: [A]-ИНСТРУКЦИЯ
STA PT_DAT
XRA A
STA PT_CMD
XRI 1
STA PT_CMD
LXI B,C_tPWR
CALL WAIT
;=XRA A
STA PT_CMD
LXI B,C_tCYC
WAIT:
DCX B
MOV A,B
ORA C
JNZ WAIT
RET
ClrLCD:
; CLS
LXI H,0
SHLD M_POS
MVI A,01H; 0 0 0 0 | 0 0 0 1
CALL WrtCMD
MVI A,02H; 0 0 0 0 | 0 0 1 -
JMP WrtCMD
PRA:
; Вывод символа
; I: [A]-КОД СИМВОЛА (КОДИРОВКА DSDOS)
PUSH H
CALL CONV
PUSH PSW
; ВЫЧИСЛЕНИЕ ПОЗИЦИИ
LHLD M_POS
MOV A,H
ANI 1
RRC
RRC
ORA L
;CALL PRH
; ЗАПИСЬ ПОЗИЦИИ В ИНДИКАТОР
ORI 80H; 1 A A A | A A A A
CALL WrtCMD
POP PSW
; ЗАПИСЬ КОДА СИМВОЛА
; I: [A]-ДАННЫЕ
STA PT_DAT
MVI A,03H; RS=1
STA PT_CMD
LXI B,C_tPWR
CALL WAIT
MVI A,02H
STA PT_CMD
LXI B,C_tCYC
CALL WAIT
; =XRA A
STA PT_CMD
; ОЖИДАНИЕ ИСПОЛНЕНИЯ (???)
LXI B,C_tCYC
CALL WAIT
; ИНКРЕМЕНТ ПОЗИЦИИ
INR L
MOV A,L
ANI 0FH
MOV L,A
JNZ EPRA
INR H
MOV A,H
ANI 1
MOV H,A
EPRA:
SHLD M_POS
POP H
RET
M_POS:DW 0; [L]=X, [H]=Y
В общем, видимо скоро будет универсальный драйвер в духе родного вывода символов в DSDOS под различные алфавитно-цифровые ЖК-индикаторы.