DSDOS для ПРК "Орион-128"

[Denn]

a какие частоты потянет?

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

[barsik]

Если я правильно понял смысл поста, речь идёт о много канальном логическом анализаторе на базе ОРИОНА, причём реализация программная, а не аппаратная. Программная реализация имеет недостатком низкую частоту дискретизации.

Конечно, такое устройство вполне может найти место в лаборатории любителя для отладки устройств на КМОП процессорах. Которые характерны тем, что сохраняют работоспособность при понижении тактовой частоты практически до 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 НСЕК), а компьютер служил лишь для управления и визуализации. Возможно, что-то подобное можно самостоятельно разработать и сейчас (например, используя ПДП).

А какие частоты потянет ?

Тут на помощь приходит арифметика. Посчитаем максимально достижимые частотные параметры программной реализации.

.
LOOP:	LD	A,(DE)		; 7
	LD	(HL),A		; 7
	INC	HL		; 4
	JR	LOOP		; 12
				; = 30 тактов

Что даёт при такте КР580 в 2.5 МГЦ минимальный период дискретизации 400 НСЕК * 30 = 12 МКСЕК, что соответствует одному периоду частоты 83.3 КГЦ. Это при 8-ми входных линиях и при аппаратной реализации останова (по аппаратному RESET или INT). Если останов на конец буфера сделать программным и ввести 16-ть анализируемых линий, то получается.

.
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 МГЦ минимальный период дискретизации 400 НСЕК * 68 = 27.2 МКСЕК, что соответствует одному периоду частоты 36.8 КГЦ.

Приведённые простейшие расчёты показывают насколько необходима замена в ОРИОНЕ КР580 на такте 2.5 МГЦ на Z80B на такте 7.5 МГЦ.

[Denn]

Если я правильно понял смысл поста, речь идёт о много канальном логическом анализаторе на базе ОРИОНА, причём реализация программная, а не аппаратная. Программная реализация имеет недостатком низкую частоту дискретизации.

Всё верно. Смысл в том, что для отладки и анализа далеко не всегда требуется работа в реальном времени. В режиме программной синхронизации в качестве клока на испытываемую схему подаётся таковой из программы, т.о. анализ производится на максимальной частоте, которую Орион может сгенерировать в программном цикле.

Конечно, такое устройство вполне может найти место в лаборатории любителя для отладки устройств на КМОП процессорах.

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

К Apple-II в начале 80-тых выпускалась такая периферийная плата, но частотные параметры её высокие. Данные накапливались в скоростном ОЗУ (70 НСЕК), а компьютер служил лишь для управления и визуализации. Возможно, что- то подобное можно самостоятельно разработать и сейчас (например, используя ПДП).

"Железная" реализация это клёво, но разрабатывать таковую сейчас смысла нет, т.к. всё равно никто не будет заморачиваться сборкой. А для работы "в стол" это слишком круто.

В данном случае вся фишка в том, что по сути ничего паять не надо: воткнул в порт нужное кол-во проводков и вот тебе готов лабораторный стенд!

- - - Добавлено - - -

Что даёт при такте КР580 в 2.5 МГЦ минимальный период дискретизации 400 НСЕК * 68 = 27.2 МКСЕК, что соответствует одному периоду частоты 36.8 КГЦ.

Ну вот и замечательно, конструкцию электронных часов с родным клоком 32768 Гц можно испытывать в реальном времени Уже профит!

- - - Добавлено - - -

Вот цикл сканирования в скоростном режиме:

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

В [BC] адрес буфера, C_OVER - старший байт адреса границы буфера


Может можно сделать ещё быстрее, например через стэк?.. Можно подумать, но выигрыш будет отнюдь не в разы, так что особого смысла и нет. Через стек это, видимо, после взятия данных из портов сразу класть в буфер по PUSH H, в таком случае запись будет обратная (стек растёт вниз), нужно менять всю логику отрисовки, а там своя оптимизация по скорости...

[HardWareMan]

Вот цикл сканирования в скоростном режиме:

LOOP:
LHLD PT_USR  / 16
MOV  A,L     / 5
STAX B       / 7
INX  B       / 5
MOV  A,H     / 5
STAX B       / 7
INX  B       / 5
MOV  A,B     / 5
CPI  C_OVER  / 7
JC   LOOP    / 10

В [BC] адрес буфера, C_OVER - старший байт адреса границы буфера

Итого на цикл: 72 такта в цикле

LOOP:
LHLD PT_USR  / 16
PUSH H       / 11
DCX  B       / 5
MOV  A,B     / 5
ORA  C       / 4
JNZ  LOOP    / 10

Итого: 51 такт на цикл. Есть смысл.

[barsik]

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

А что насчёт того, чтобы сделать из ОРИОНА осцилограф? Двухлучевой, а может быть даже и скоростной. У меня например осцилограф, хотя и достаточно скоростной, но однолучевой и даже одноканальный. А часто хочется посмотреть сразу два сигнала, чтобы узнать, как они соотносятся. В ж.РАДИО в 80-тые видел схемы внешних коммутаторов, которые, якобы, обеспечивают это.

Если применить ПДП, который тратит 4 такта на байт, то период дискретизации получится в 4*400 НСЕК=1.2 МКСЕК, что соответствует периоду частоты в 625 КГЦ. Т.е уже можно более-менее точно рассматривать сигналы частотой до 200 КГЦ. А если использовать не ОРИОН, а РК86, где, во-первых, ПДП уже есть, а во-вторых, в РК можно тактировать ПДП максимально высоким тактом, это дополнительно увеличит разрешение.

"Железную" реализацию разрабатывать сейчас смысла нет, т.к. всё равно никто не будет заморачиваться сборкой

Это да. Просто потому, что разработчиков МП-железа, которым анализатор был бы полезен, - очень мало. А вот осцилограф нужен, если его нет у любителя. Скоростной аппаратный осцилограф из ОРИОНА будет сделать разумно, если для этого будет достаточно лишь спаять платку с 10-ю микросхемами (одна из которых скоростное КМОП-ОЗУ 10-25 НСЕК). Это будет менее громоздко, чем иметь реальный осцилограф. А низкоскоростной программный осцилограф, это вообще не требует труда (достаточно изготовить высокочастотный пробник с полевиком на входе).

- - - Добавлено - - -

Со стеком лучше так:

.
LOOP:	LD	HL,(PORT_A)	; 16
	PUSH	HL		; 11
	JR	LOOP		; 12
				; = 39 тактов

Останов делается не программным, а за счёт аппаратной ловушки на запись по адресу 0000 (отчего возникает INT или RESET). Период дискретизации будет: 39*400= 15.6 МКСЕК, что соответствует периоду частоты 64 КГЦ.

[Denn]

Останов делается не программным, а за счёт аппаратной ловушки на запись по адресу 0000 (отчего возникает INT или RESET). Период дискретизации будет: 39*400= 15.6 МКСЕК, что соответствует периоду частоты 64 КГЦ.

Имхо, что 37 кГц, что 64 - одна малина. Все МПС-процессы имеют скорости от мегагерцев, так что до реал-тайма недостижимо далеко.
Актуальнее всё же синхронный режим.

[barsik]

Все МП-процессы имеют скорости от мегагерцев, так что до реал-тайма недостижимо далеко

Понятно, что отладка МП в реальном времени на программной версии анализатора невозможна. Поэтому я и указал, что это удобно только для систем, где на время отладки можно поставить очень низкочастотный такт CPU, отчего быстродействие логического анализатора перестаёт играть роль. Причём желательно, чтобы в системе ОЗУ было статическое. Естественно, если в системе динамическое ОЗУ регенерируется за счёт частых обращений к ОЗУ процессора или видеочасти, то отлаживать его на низкой скорости невозможно. Программный анализатор (осцилограф) непригоден для отладки МП-железа на динамическом ОЗУ. Так что сам ОРИОН с помощью такого анализатора не отладить. А программ реального времени практически нет (это только работа с НГМД или магнитофоном), даже для IDE-винчестера скорость обмена данными не важна.

А чего идея осцилографа Вам не интересна (это же даже проще)?

Зря Вы не хотите делать аппаратную реализацию. Хотя-бы прикиньте, во что это может "вылиться", хотя бы для осцилографа. Переключаемый генератор 20/10/5/2.5 МГЦ, банка ОЗУ 20-70 НСЕК, скоростной счётчик в 8 разрядов. 8-ми разрядный мультиплексор (коммутирует адреса ОЗУ между счётчиком и CPU), буфер шины данных и немножко логики. Кажется, ничего особо сложного.

Кстати, для программного осцилографа вовсе не нужно читать 16 линий, стек не нужен и годится скоростной линейный участок в 256 таких команд:

.
	LD	A,(DE)		; 7
	LD	(HL),A		; 7
	INC	HL		; 6
				; = 20 тактов на байт

Что даёт период дискретизации соответствующий периоду частоты 125 КГЦ. А если у Вас ОРИОН с тактом 7.5 МГЦ, то будет 375 КГЦ. Совсем неплохо. Только старт программы "захвата" надо делать аппаратно, а именно - по синхроимпульсу сбрасывать READY (или даже HOLD) для КР580.

А если накапливать отсчёты в сдвиговом регистре, то читать его надо частотой в 8 раз ниже, отчего получится период дискретизации осцилографа соответствующий частоте в 1 МГЦ. А если регистр 16-ти разрядный и использовать стек, как в примере предыдущего поста, то получится не менее 1.5 МГЦ. Заметьте, речь о программном осцилографе.

[Denn]

Стартовая версия ТТЛ-анализатора готова, линк внизу вводного поста - http://zx-pk.ru/threads/21984-dsdos-...l=1#post923604

Поддержаны обе платформы: Орион-128 (2,5 МГц) и Орион-ПРО (10 МГц).

[Denn]

a какие частоты потянет?

Намедни материализовался ответ на этот вопрос (спасибо, Stampmaker!): в самом быстром режиме на Орионе-128 (@2,5 МГц) получилось ровно 25000 измерений в секунду. На Орионе-ПРО это, видимо, будет цифра примерно в 3,5 раз больше. Как-то так.

[Denn]

Решил поразвлекаться с ЖК-индикаторами
Подключил к Ориону вот такой - https://www.chipdip.ru/product/wh1602d-ygh-ct-k
Как обычно, интересно было "открывать америку" самостоятельно, разбирался с нуля по даташиту, было весьма увлекательно.


Спаял переходник на порт пользователя (#F600-данные, #F602-управление: С0="Е", С1="RS", C2="R/W"):








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

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

Далее был некоторый секас с пониманием инженерной мысли по части алгоритма работы, подбор таймингов... в итоге всё получилось:







Код вывода символа в индикатор:

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 под различные алфавитно-цифровые ЖК-индикаторы.