ЭТЮДЫ

[Destr]

Заключи вызов макроса как процедуру, прибавив вначале метку а в конце RET.
Перед началом цикла опроса сделай один лишний разок CALL, только как инициализацию, не глядя на Z.
А в цикле вызывай CALL и смотри флаг Z.

Предполагается юзать именно как макрос, чтоб хранить предыдущее значение прямо в теле проги, а не делать на каждый сигнал свою ячейку отдельно где-то в памяти (ведь если сигналов будет несколько - то в теле вызываемой процедуры уже нельзя хранить предыдущее состояние)

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

Кажется домучал (были уже рабочие варианты у меня, просто эмуль подвёл - ведь тестил через ALT+F3 зажав клавишу, а эмуль не сразу опрашивает оказывается, если сделать задержку - то при зажатой кнопке изначально - передний фронт не детектится, т.е. всё как надо работает)

	MACRO FN_KEY key	;  отрицательный фронт, key=high порт/mask (#7f04="m"), Z=1 - фронт был
.prev		LD A,#FF
		CPL
		AND low key
		LD (.mask+1),A
		LD A,high key
		IN A,(#FE)
		LD (.prev+1),A
.mask		AND 0
	ENDM
	
	MACRO FP_KEY key	; положительный фронт, key=high порт/mask  (#7f04="m"), Z=1 - фронт был
.prev		LD A,#00
		AND low key
		LD (.mask+1),A
		LD A,high key
		IN A,(#FE)
		LD (.prev+1),A
		CPL
.mask		AND 0
	ENDM

Reobne, а формула клика (т.е. 0-1-0) как получается? Там уже надо видимо хранить 2 предыдущих значения, причём обновлять не каждый вызов, а ставить флаг что мол была клавиша отжатой, потом была нажатой, а теперь вот снова отжалась - тут-то и подымать флаг "клик!" ?

[Reobne]

Всё правильно!

Но у меня есть подозрение, что ты не до конца серьёзно отнёсся к теме начальной инициализации. Тебе показалось, что я предлагаю из какой-то прихоти заменить макрос на подпрограмму. Но я предлагал оставить макрос, но заключить его в подпрограмму. И не из прихоти, а для начальной инициализации.

Предположим в игре есть ГГ, который вот вот умрёт. Игрок давит на "R", но отпустить кнопку не успевает, ГГ умирает по игровой причине. Показывается анимация смерти, потом надпись: "Приготовся!". Игрок уже отпустил "R", готовится такой. А макрос твой помнит, что кнопка R, переиграть, была нажата. И как только начнётся главный игровой цикл, твой макрос увидит, что кнопку только что отпустили. И игрок потеряет вместо одной жизни сразу две жизни. Это плохо.

[Destr]

Но у меня есть подозрение, что ты не до конца серьёзно отнёсся к теме начальной инициализации.

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

[Bolt]

Сравнить два значения (например, регистр A и регистр B) и если A<=B, то получить в аккумуляторе true (ненулевое значение, желательно FFh), иначе false (00h).
Без условных переходов, только арифметикой. Это для использования в компиляторе, а условные переходы вида "jr $+n" усложнят последующую оптимизацию.

Если A<B, то флаги C=1, Z=0
Если A=B, то флаги C=0, Z=1
Если A>B, то флаги C=0, Z=0

Дошёл до такого кода:

rra
ccf
sbc a,0
rla
sbc a,a

6 байт, 23 такта (без учёта самого сравнения "cp b" или "sub a,b")
Можно ли сделать короче и/или быстрее?

[Destr]

Можно ли сделать короче и/или быстрее?

Вроде сработало

NEG		; 8т, 2b
ADD A,B		; 4т, 1b
SBC A,A		; 4т, 1b
		;=16т, 4b

СP B делать не надо, на выходе #FF или #00
(только это с беззнаковыми числами)

[Reobne]

если A<=B, то получить в аккумуляторе true

Destr, при нулевых A и B должно получаться #FF! А у тебя ноль выходит.

А так то, если известно что A никогда не 0, можно ещё чуть быстрее DEC A:CP B:SBC A,A

[Advertiser]

[Bolt]

Destr, при нулевых A и B должно получаться #FF! А у тебя ноль выходит.

А так то, если известно что A никогда не 0, можно ещё чуть быстрее DEC A:CP B:SBC A,A

Нет, оба числа могут быть любыми.

При нулевых A и B:

sub a,b ; A=00h, C=0
rra ; A=00h, C=0
ccf ; A=00h, C=1
sbc a,0 ; A=FFh
rla ; C=1
sbc a,a ; A=FFh

Вроде всё правильно. Где я ошибаюсь?

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

А, понял, не я ошибаюсь.

NEG ; A=00h
ADD A,B ; A=00h, C=0
SBC A,A ; A=00h

Но этот код натолкнул на интересную мысль...

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

Забыл указать ещё одно условие. Считаем что вычитание, которое для сравнения, уже произведено. Нужен только универсальный "хвост" для получения true/false.

[krt17]

Давно не брал я в руки шашки

			cpl
			scf
			adc	a, b
			sbc   a, a

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

Если A<B, то флаги C=1, Z=0, A=FF
Если A=B, то флаги C=0, Z=1, A=FF
Если A>B, то флаги C=0, Z=0, A=0

Так? Тогда код автора - полный бред.
Еще и условия какие-то дополнительные, тфу одним словом. Не удивительно что паскаль не работает при таком подходе.

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

Ладно не совсем бред конечно, но мнемоники желательно писать правильно.

[Bolt]

Еще и условия какие-то дополнительные, тфу одним словом. Не удивительно что паскаль не работает при таком подходе.

Кодогенератор собирает программу из отдельных блоков, принцип хорошо описал Andrew771 в журнале "Downgrade". Вычитание уже произведено, нужен именно этот блок.

Ладно не совсем бред конечно, но мнемоники желательно писать правильно.

Если речь о rra/rla, то с этими мнемониками полный бардак. Ассемблер, который я использую, их понимает, бинарник собирается, работает, и это главное

[krt17]

Неа.

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

Я сагрился на sub a, r. Нормально все, это рефлекторно.