Игрушка Columns для УКНЦ

[BlaireCas]

Хотелось бы, чтобы не так рано переключалась игра на быструю скорость)

Даже не предполагалось что кто-то будет реально играть
Сделал несколько больше очки переключения уровня (и соответственно скорости): 500., 1000., 1500., 2000., 3000., 4000., 6000.

[Titus]

Даже не предполагалось что кто-то будет реально играть
Сделал несколько больше очки переключения уровня (и соответственно скорости): 500., 1000., 1500., 2000., 3000., 4000., 6000.

На мой взгляд, сильно увеличивать скорость вообще не надо.
Чуть увеличил разок и все.
Люди обычно играют, чтобы расслабиться, переключиться.
А тут раз, и вдруг все быстрее пошло)

[BlaireCas]

На мой взгляд, сильно увеличивать скорость вообще не надо.

Надо будет подумать сделать там выбор навроде "Уровень вкл/выкл".

[BlaireCas]

Сунулся в первое попавшееся место. В чём преимущество такого варианта
Код:

PPSEN:	mov	#PPMSG, R0		; array address
	mov	#5, R1			; bytes to send+1 (sending from @#PP_MSG)
	br	1$
2$:	movb	(R0)+, @#176676
1$:	tstb	@#176674		; test if we are ready to send
	bpl	1$			; cycle if >= 0 (not set last bit in byte)
	sob	R1, 2$
	return

Хунта наверное не посмотрит. Но ведь... Чорт подъери:

Да уж, журнал УКНЦ 1/1995

[свернуть]

Не то чтобы я спорил с Alex_K и откуда-то взял нечто другое. Но вон в журнале тоже как-бы "а и нафиг нам tstb лишнее, проживем и без него". Даже без "первого" tstb (вдруг как-раз без первого-то можно).

Флеймово было, но я останусь верен старому коду с двумя tstb уж фиг с ним.

[Hunta]

Даже без "первого" tstb (вдруг как-раз без первого-то можно).

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

на запрос с кодом 1 надо дождаться ответа

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

[Alex_K]

Не то чтобы я спорил с Alex_K и откуда-то взял нечто другое. Но вон в журнале тоже как-бы "а и нафиг нам tstb лишнее, проживем и без него". Даже без "первого" tstb (вдруг как-раз без первого-то можно).

А вы обратили внимание, что там только две команды - передача в ОЗУ ПП (код 020) и запуск в ОЗУ ПП (код 030). Отсутствует команда выделения блока памяти в ОЗУ ПП (код 1). Здесь естественно сработает, т.к. функции 020 и 030 не меняют ваш блок параметров. А функция 1 после исполнения передаёт в ваш блок параметров результат операции.

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

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

Да уж, задержка будет ужасной. И выигрыш в задержке будет только при запуске кода по команде 030. В случае передачи команды 020 и не ожидания установки бита готовности придётся ждать его перед командой 030. Вот собственно и весь выигрыш. А так ожидание ещё может уйти на синхронизацию с запуском кода в ПП, если кодам в ЦП и ПП надо взаимодействовать между собой.

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

Ещё столовую ложку дёгтя в бочку мёда. По поводу последовательной подачи команд 020 и 030. Всё сработает и с циклом на четыре, если адрес запуска в ПП будет равен адресу загрузки. А вот если не равны, то вы в блоке параметров пропишите уже новый адрес, а в ПП ещё не успел обработаться запрос 020. Тогда загрузка в ПП начнётся уже с нового адреса.
Я писал несколько программ, которые оставались резидентами в ПП, так у меня получалось, что адрес запуска не был равен адресу загрузки. В младших адресах был резидент, а в более старших осуществлялась инициализация и уменьшение занимаемого блока памяти под объём резидента.

[BlaireCas]

Отсутствует команда выделения блока памяти в ОЗУ ПП (код 1)

Ну кто-ж его теперь знает. Это ведь бумажный журнал. Сократили, закомментировали тремя точками остальной код. Однако по таким вот журналам и учились. Я уже забыл откуда взял изначальный код с двумя tstb, откуда-то (да да тупая копипаста). Похоже не из этого журнала. В каком-то другом видимо было.

[Alex_K]

Ну кто-ж его теперь знает. Это ведь бумажный журнал. Сократили, закомментировали тремя точками остальной код. Однако по таким вот журналам и учились. Я уже забыл откуда взял изначальный код с двумя tstb, откуда-то (да да тупая копипаста). Похоже не из этого журнала. В каком-то другом видимо было.

А чего тут знать-то? Блок параметров под меткой Z имеет адрес загрузки 30000. Тем более выделяют два блока, один на загрузку, другой на запуск. Никакой экономии памяти!!!

[Titus]

Сделал несколько больше очки переключения уровня (и соответственно скорости): 500., 1000., 1500., 2000., 3000., 4000., 6000.

В новой версии у меня на эмуляторе в нижней части экрана (под игровым полем) мусор.

[Alex_K]

Я уже забыл откуда взял изначальный код с двумя tstb, откуда-то (да да тупая копипаста). Похоже не из этого журнала. В каком-то другом видимо было.

Когда я начинал программировать в ПП, у меня не было соответствующей документации "Работа с внешними устройствами". Код запуска в ПП я брал из программы ZWUK.SAV. Она там уже была со счётчиком пять, т.е. такая как надо.