Электроника МК-85

[Lavr]

А всё-таки локальные метки могут иметь место?

Я помню, что в других ассемблерах есть для них обозначение - @1: @2: @3: и т.д.
А вот диапазон их действия тоже не помню, поэтому старался не применять...

Погуглил на фразу:"ассемблер локальные метки":

Будет зависеть от того, какой диалект ассемблера будет использован FASM, MASM или TASM.

- MASM автоматически различает метки, находящиеся в пределах процедуры, и считает их локальными, чтобы такая метка стала глобальной ее нужно метить так имя_метки:: также локальными считаются метки @@ их может быть в тексте программы десяток штук, переходы к таким меткам jmp @f (переход к метке @@ вперед) и jmp @b (переход к метке @@ назад).

- В TASM по умолчанию метки считаются глобальными. Локальные метки должны иметь перед именем обозначение @@. Кроме того, в начале программы следует поставить директиву LOCALS.

- В FASM локальная метка — это метка, имя которой начинается с точки. Во время генерации кода FASM автоматически добавляет к имени локальной метки имя последней объявленной «глобальной» метки. Имена локальных меток могут повторяться, если между ними есть хотя бы одна «глобальная» метка.

Сам-то кросс-ассемблер довольно древний:

Code: Select all

BK-10/11 Assembler v1.00 by AO SW Co., 1996.

Usage: ASM filename [options]
Options: -l      disable List file
         -m      disable MAP file
         -aNNNN, NNNN - link address (Def=01000)
         -k      BK-Turbo source file.

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

[Lavr]

Ок, попробую, но боюсь 1: 2: 3: он не продует...

Читай хелп к pdp11asm - продует!...

N: - Числовая метка. Область действия метки ограничивается символьными метками.
Такая метка может быть использована только в командах условного перехода B? и SOB.

vinxru такие метки поддержал, значит они не экзотика в ассемблерных программах для 1801ВМх/PDP11!

[Shaos]

vinxru такие метки поддержал, значит они не экзотика в ассемблерных программах для 1801ВМх/PDP11!

Ну видимо добивался совместимости с какими-то существующими ассемблерными текстами - зачёт ему

[Lavr]

Да ему навалили "заказов" - сделай совместимым со ВСЕМ!
Я ж читал дружественный форум... когда он работал над компилятором.
Кстати, судя по хелпам, он и делал совместимость со ВСЕМ!
Жаль только он какой-то С++ навороченный выбрал...
Так-то практически всё что надо есть, кроме разбора арифметики в строке аргумента.
Можно было бы допилить...

Кстати, в хелпах опечатка, видимо:"10b - десятичный" - всё же бинарный...

[Shaos]

Напишу тут, пока не забыл. Когда прошивка МК-85 что-то меняет на экране, то она посылает байт по одному из адресов #80...#DF для отображения 5-пиксельных планок (как на картинке на предыдущей страничке), по адресу #E0 посылается местоположение курсора (4 бита) и его вид (5й бит). Адрес #E8 тоже для чего-то используется, но туда посылается 0 ровно один раз при перезагрузке микрокомпьютера (инициализация контроллера ЖКИ?). Так вот у меня идея - если в клоне допустить использование оригинальной прошивки МК-85 (как одного из вариантов), то тогда надо ставить какой-то второй процик, который будет ловить эти обращения и отображать их на светодиодных матрицах. Вторым проциком можно поставить скажем 8085 ( раз уж это у нас типа nedoMK-85 ; ) и если у нас есть второй полноценный процик, то почему бы не наделить его возможностью запускать пользовательские программы? А пользовательские программы можно загонять через теже "порты" - к примеру пересылка байта по адресу #E1 задаёт старший байт адреса для 8085, #E2 задаёт младший байт адреса для 8085, а #E3 - байт, который пишется по заданному ранее адресу в память 8085. Далее можно скажем поддержать автоинкремент и последовательность посылок в #E4 будет заполнять память с шагом в 1 байт, сдвигая адрес введённый ранее в #E1 и #E2. Посылка байта в #E5 может скажем запускать программу по введённому ранее адресу (а пересланный байт будет в регистр A скажем писаться перед передачей управления). Ещё остаются #E6 и #E7 ещё для чего-нибудь (на самом деле вплоть до #FF ловилось в ЖКИ контроллере). Вобщем как-то так...

P.S. Если же мы заведомо расширенным ПЗУ пользуемся, то второго процыка ненадо - просто вешаем на ВМ2 прерывание по таймеру и по прерыванию вычитываем видеопамять #8000-#005F и чего-то выводим на светодиоды программно (для этого надо написать соответствующий обработчик в составе обновлённого ПЗУ). Единственное, что так вид курсора поменять нельзя - он всегда будет одинаковым, т.к. он в памяти не хранится, а формируется программно непосредственно перед засылкой в #E0...

P.P.S. Еще один плюс двухпроцессорного подхода заключается в том, что дисплей (и клавиатуру) можно проверить на хорошо известном (мне) микропроцессоре, который у меня уже запускался (nedoPC-85), а потом уже возится с неведомым ВМ2

ВМ2 будет работать на 10 МГц, а ВМ85А на 6 МГц (внутри 3 МГц) или ВМ85 на 10 МГц (внутри 5 МГц)

Надо будет прикинуть успеет ли 85й поймать копирования в область #80...#EF при стирании экрана, например:

Code: Select all

; clear screen
0A32: mov	r0,-(sp)
0A34: mov	#80,r0
0A38: inc	r0
0A3A: clrb	7F80(r0) ; <<<<
0A3E: clrb	(r0)+ ; <<<< CLEAR BYTE #80...#DF
0A40: bit	#7,r0 ; <<<<
0A44: bne	0A3A ; <<<<
0A46: cmp	r0,#E0
0A4A: bcs	0A38
0A4C: movb	#C,(r0)		;hide cursor
0A50: mov	(sp)+,r0
0A52: bisb	#1,8264		;long delay between scrollings
0A58: clrb	8269		;cursor position
0A5C: rts	pc

Скажем если этот цикл из 4х команд (помеченных <<<<) будет выполняться за 80 тактов, то при 10 МГц это будет 8 мкс, за которые успеют пройти 24 такта 3-мегагерцового ВМ85А - наверное маловато и надо просто тупо тормозить ВМ2 в случае обращения к #80...#DF, чтобы 8085 всё успел? А если на прерывание повесить? Вот примерно так:

Code: Select all

INT85:
 DI ; disable interrupts (4)
 PUSH PSW ; save A and F (12)
 PUSH HL ; save H and L (12)
 MVI H,#20 ; higher byte of address (7)
 IN 0 ; read port VADR (10)
 MOV L,A ; store address to B (4)
 IN 1 ; read port VDAT (10)
 MOV M,A ; [HL]=A (7)
 POP HL ; load H and L (10)
 POP PWS ; load A and F (10)
 EI ; enable interrupts (4)
 RET (10)

100 тактов - многовато

значит надо тормозить ВМ2, пока ВМ85 находится в прерывании (например через Serial Output управлять замыканием SYNC на AR или даже тактированием проца, как на ZX)!

[Shaos]

значит надо тормозить ВМ2, пока ВМ85 находится в прерывании (например через Serial Output управлять замыканием SYNC на AR или даже тактированием проца, как на ZX)!

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

P.S. Пётр советует через двухпортовую память процы связать

[Shaos]

Значит надо пожалуй определиться с палкой-галкой - 16V8, 20V8 или 22V10 (они все у меня имеются в разных реинкарнациях)

Для логики адресного декодера аля-PDP11 нам понадобится - входы:

A0,WTBT - для логики выборки отдельных половинок для записи
A13,A14,A15 - для выборки микросхем памяти ПЗУ/ОЗУ
DOUT,A8,A9,A10,A11,A12 - дополнительные биты адреса для определения факта записи в область #00...#FF (расширил про запас от оригинальных #80...#E0,#E8)
A3,A4,A5,A6,A7 - дополнительные биты адреса для определения факта обращения в область #100...#107 (на самом деле надо просто проверить, что все они равны 0 - можно обойтись одним входом и внешним ИЛИ)

и выходы:

_CS_ROM - выборка 16-битной микросхемы ПЗУ в области памяти #0000...#7FFF
_CS_RAM1L - выборка первой микросхемы ОЗУ (область памяти #8000...#BFFF, младшая половинка)
_CS_RAM1H - выборка второй микросхемы ОЗУ (область памяти #8000...#BFFF, старшая половинка)
_CS_RAM2L - выборка третьей микросхемы ОЗУ (область памяти #C000...#FFFF, младшая половинка)
_CS_RAM2H - выборка четвёртой микросхемы ОЗУ (область памяти #C000...#FFFF, старшая половинка)
_CS_CTRL - выборка области контрольных регистров #100...#107 (ПЗУ должно быть запрещено в этом случае)
_WR_VMEM - запись в видеопамять #00...#FF

итого 12 входов и 7 выходов - 16V8 отпадает

теперь если добавлять логику торможения ВМ2 (если ВМ85 ещё в прерывании), то надо как минимум добавить 1 вход (сигнализация, что ВМ85 в прерывании) и 1 выход (сигнал на торможение ВМ2), и возможно ещё 1 вход на синхронизацию внутреннего триггера с тактовой частотой - тогда отпадёт 20V8 и останется только 22V10...

[Shaos]

Со словом по адресу #104 будет непросто ибо оно и читается, и пишется:

Code: Select all

100   I   ;1 word, bits 8-2 - keyboard matrix columns
102   O   ;1 word, bits 3-1 - keyboard matrix rows
104   I/O ;1 word, the CPU control register,
          ;bit 3 - selects fast CPU clock when set
          ;bit 10 - stops the CPU clock when cleared
106       ;1 word, apparently not used

С другой стороны из него только 2 бита используется по сути...

P.S. Расширенные возможности МК85 (http://mk85.republika.pl/rom.html) занимают ещё несколько битов в #102:

PP7 (7й бит по адресу #102) - сигнал SDA на шине I2C (может быть как входом, так и выходом - управляется битом 1 в #104)
PP8 (8й бит по адресу #102) - сигнал SCL на шине I2C (может быть как входом, так и выходом - управляется битом 2 в #104)
PP11 (11й бит по адресу #102) - пищалка (команда BEEP в патче v27)

P.P.S. Версия патча 23 и выше поддерживает команды SAVE и LOAD для записи и чтения образов ОЗУ из 8 микросхем I2C EEPROM 24C256 (32КБ каждая) - это было бы очень зачудительно поддержать...

[Lavr]

Вот здесь гражданин также размышляет над репликой МК-85:
http://electrosch.blogspot.ru/p/85.html

[Shaos]

Вот здесь гражданин также размышляет над репликой МК-85:
http://electrosch.blogspot.ru/p/85.html

Я знаю

[Shaos]

Напишу тут, пока не забыл. Когда прошивка МК-85 что-то меняет на экране, то она посылает байт по одному из адресов #80...#DF для отображения 5-пиксельных планок (как на картинке на предыдущей страничке), по адресу #E0 посылается местоположение курсора (4 бита) и его вид (5й бит). Адрес #E8 тоже для чего-то используется, но туда посылается 0 ровно один раз при перезагрузке микрокомпьютера (инициализация контроллера ЖКИ?). Так вот у меня идея - если в клоне допустить использование оригинальной прошивки МК-85 (как одного из вариантов), то тогда надо ставить какой-то второй процик, который будет ловить эти обращения и отображать их на светодиодных матрицах. Вторым проциком можно поставить скажем 8085 ( раз уж это у нас типа nedoMK-85 ; ) и если у нас есть второй полноценный процик, то почему бы не наделить его возможностью запускать пользовательские программы? А пользовательские программы можно загонять через теже "порты" - к примеру пересылка байта по адресу #E1 задаёт старший байт адреса для 8085, #E2 задаёт младший байт адреса для 8085, а #E3 - байт, который пишется по заданному ранее адресу в память 8085. Далее можно скажем поддержать автоинкремент и последовательность посылок в #E4 будет заполнять память с шагом в 1 байт, сдвигая адрес введённый ранее в #E1 и #E2. Посылка байта в #E5 может скажем запускать программу по введённому ранее адресу (а пересланный байт будет в регистр A скажем писаться перед передачей управления). Ещё остаются #E6 и #E7 ещё для чего-нибудь (на самом деле вплоть до #FF ловилось в ЖКИ контроллере). Вобщем как-то так...

P.S. Если же мы заведомо расширенным ПЗУ пользуемся, то второго процыка ненадо - просто вешаем на ВМ2 прерывание по таймеру и по прерыванию вычитываем видеопамять #8000-#005F и чего-то выводим на светодиоды программно (для этого надо написать соответствующий обработчик в составе обновлённого ПЗУ). Единственное, что так вид курсора поменять нельзя - он всегда будет одинаковым, т.к. он в памяти не хранится, а формируется программно непосредственно перед засылкой в #E0...

P.P.S. Еще один плюс двухпроцессорного подхода заключается в том, что дисплей (и клавиатуру) можно проверить на хорошо известном (мне) микропроцессоре, который у меня уже запускался (nedoPC-85), а потом уже возится с неведомым ВМ2

ВМ2 будет работать на 10 МГц, а ВМ85А на 6 МГц (внутри 3 МГц) или ВМ85 на 10 МГц (внутри 5 МГц)

Надо будет прикинуть успеет ли 85й поймать копирования в область #80...#EF при стирании экрана, например:

Code: Select all

; clear screen
0A32: mov	r0,-(sp)
0A34: mov	#80,r0
0A38: inc	r0
0A3A: clrb	7F80(r0) ; <<<<
0A3E: clrb	(r0)+ ; <<<< CLEAR BYTE #80...#DF
0A40: bit	#7,r0 ; <<<<
0A44: bne	0A3A ; <<<<
0A46: cmp	r0,#E0
0A4A: bcs	0A38
0A4C: movb	#C,(r0)		;hide cursor
0A50: mov	(sp)+,r0
0A52: bisb	#1,8264		;long delay between scrollings
0A58: clrb	8269		;cursor position
0A5C: rts	pc

Скажем если этот цикл из 4х команд (помеченных <<<<) будет выполняться за 80 тактов, то при 10 МГц это будет 8 мкс, за которые успеют пройти 24 такта 3-мегагерцового ВМ85А - наверное маловато и надо просто тупо тормозить ВМ2 в случае обращения к #80...#DF, чтобы 8085 всё успел? А если на прерывание повесить? Вот примерно так:

Code: Select all

INT85:
 DI ; disable interrupts (4)
 PUSH PSW ; save A and F (12)
 PUSH HL ; save H and L (12)
 MVI H,#20 ; higher byte of address (7)
 IN 0 ; read port VADR (10)
 MOV L,A ; store address to B (4)
 IN 1 ; read port VDAT (10)
 MOV M,A ; [HL]=A (7)
 POP HL ; load H and L (10)
 POP PWS ; load A and F (10)
 EI ; enable interrupts (4)
 RET (10)

100 тактов - многовато

значит надо тормозить ВМ2, пока ВМ85 находится в прерывании (например через Serial Output управлять замыканием SYNC на AR или даже тактированием проца, как на ZX)!

У меня теперь есть прекрасная возможность для подсчёта реального количества тактов сымитировать стирающий экран код на реальном ВМ2 на своём стенде

viewtopic.php?f=95&t=10464&start=180

Програмку укоротим вот до такого состояния (для компиляции через pdp11asm):

Code: Select all

; clear screen

decimalnumbers

	org 0

.word	L0A34
.word	0

	org 0A34h
; 0A34:
L0A34:	mov	#80h,r0
; 0A38:
L0A38:	inc	r0
; 0A3A:
L0A3A:	clrb	07F80h(r0)
; 0A3E:
	clrb	(r0)+
; 0A40:
	bit	#7,r0
; 0A44:
	bne	L0A3A
; 0A46:
	cmp	r0,#0E0h
; 0A4A:
	bcs	L0A38
; 0A4C:
make_mk85_rom "clr.bin",32768

последняя строчка нужна лишь для того, чтобы сгенерился листинг:

Code: Select all

0003 0000                      		decimalnumbers
0005 0000                      			org 0
0007 0000 005064               		.word	L0A34
0008 0002 000000               		.word	0
0010 0004                      			org 0A34h
0012 0A34 012700 000200        		L0A34:	mov	#80h,r0
0014 0A38 005200               		L0A38:	inc	r0
0016 0A3A 105060 077600        		L0A3A:	clrb	07F80h(r0)
0018 0A3E 105020               			clrb	(r0)+
0020 0A40 032700 000007        			bit	#7,r0
0022 0A44 001372               			bne	L0A3A
0024 0A46 020027 000340        			cmp	r0,#0E0h
0026 0A4A 103766               			bcs	L0A38

по которому собственно и надо вводить слова по мере имитации прохождения программы на стенде...

P.S. с тестом пока облом - белый ВМ2 после inc r0 (который выполнился за 8 тактов CLCI) скаканул куда-то не туда, пришлось пробовать заново, поставив чёрный ВМ2 - у него вроде всё ок было до второй половины clrb 07F80h, где проц пошёл писать наружу в адрес #8001 (как и предполагалось) и соответственно стал ждать RPLY по DOUT, который у меня на стенде не заведён пока - далее всё зависло...

[Shaos]

Притянул за уши DOUT - и собственно снял все растактовки, получив очень неожиданный результат, замечательно показывающий как работает конвейер ВМ2

0A34h 012700 mov #80h,r0 <<< первая половина выполнилась за 8 тактов
0A36h 000200 <<< а вторая (вычитка аргумента 80h) ещё за 12, т.е. общее время выполнения - 20
0A38h 005200 inc r0 <<< эта команда уложилась в 8 тактов
0A3Ah 105060 clrb 07F80h(r0) <<< первая половина этой команды выполнилась за 8 тактов
0A3Ch 077600 <<< а вторая (вычитка аргумента #7F80h с дальнейшим чтением и записью по адресу #8001 ещё за 28 - всего 36
до этого места всё было понятно и логично, а вот дальше пошло месиво
0A3Eh 105020 clrb (r0)+ <<< очистка байта по адресу из R0 подразумевает чтение-запись, сама же команда вычиталась за 8 тактов
далее вместо цикла чтения-записи по R0 (где в данный момент сидит 81h), оно полезло вычитывать следующую команду!
0A40h 032700 bit #7,r0 <<< вычитка следующей команды за 8 тактов
но аргмент 7 мы далее читать НЕ ИДЁМ, а идём мы читать-писать байт по адресу 81h (ещё 18 тактов)
0A42h 000007 <<< и только после этого доходит очередь до чтения 7 с адреса 0A42h - ещё 12 тактов
0A44h 001372 bne L0A3A <<< далее происходит вычитка команды условного перехода - 8 тактов
0A46h 020027 cmp r0,#0E0h <<< и далее конвейер залез чуть вперёд и вычитал следующую команду за 8 тактов
однако её аргумент (0E0h) вычитывать не стал ибо условный переход успешно выполнился:
0A48h 000340 <<< проигнорировано в этом проходе!!!
далее хлоп и на шине адреса опять 0A3Ah

Выходит, что интересующий нас цикл проходит за 36+26+20+8+8=98 тактов CLCI, в течение которых выполнится 46 тактов 8085го - соответственно он не поспеет (т.к. ему требуется как минимум 100 тактов, чтобы забрать всю нужную инфу плюс вход в прерывание), поэтому придётся тормозить ВМ2 (через /AR) в момент выдачи на шину адреса #0080...#00FF (и при условии занятости 8085)

P.S. 8 тактов (для простых инструкций) при 10 МГц означает 1.25 миллионов операций в секунду!
А если верить слухам про возможность разгона некоторых экземпляров до 12 МГц, то и все 1.5 миллиона!!!

[Shaos]

написать свой бейсик-интерпретатор по образу и подобию, но более быстрый и более точный времени хватило, а вот свой вменяемый мануал написать - нет?

Ну так у нас плохо пишут мануалы - никому этого делать просто не охота...
Вот и облегчили себе жизнь - передрали и мануал, чего тут не понимать?
Ты же видел, я тут на форуме показывал оригинальный мануал на К580ВМ80... Стыдоба!

А что так далеко за примерами ходить? Вот тебе живой пример, как у нас "любят" писать мануалы...

Вот пара примеров, что цельно-тянутый мануал:

[Клапауций]

Купил я тут красных светодиодных матриц 5x7...

тему с интересом всю прочитал, но с этого места что-то пошло не так:
- почему матрицы, а не простые светодиоды в упаковках по 100 штук?
- почему красные, а не ультра-синие? если уж желается по ночам ловить цветных зайчиков на сетчатке.
- почему, вообще, светодиоды, а не нашефсё - ламповые неонки!?
О_О

*я один чего-то не понимаю и как лох пытаюсь сделать дисплей МК-85 на OLED или LCD графическом индикаторе как самом оптимальном варианте аппаратной реализации проекта, не выедающего глаза и в тоже время яркого цвета свечения или подсветки, например - жёлтого? О_О

[Shaos]

я один чего-то ... пытаюсь сделать дисплей МК-85 на OLED или LCD графическом индикаторе как самом оптимальном варианте аппаратной реализации проекта ...

Всё будет, но не сразу