Тема однако...
как можно отследить (через ZX-Bus) состояние спека, когда он ждет сигнала с Tape_IN???
Чтобы например источник сигнала (CD- или MP3-Player) включался автоматически...
Может есть какой-нить порт или что-то другое...
Вид для печати
Тема однако...
как можно отследить (через ZX-Bus) состояние спека, когда он ждет сигнала с Tape_IN???
Чтобы например источник сигнала (CD- или MP3-Player) включался автоматически...
Может есть какой-нить порт или что-то другое...
Задай вопрос в "программирование" - мож подскажут идею.
Времена релюшек для пуска двигла магнитофона прошли, и тем более на плеерах врядли есть стандартный интерфейс для такого подключения, а ориентироваться на самопальный плеер нет смысла. Скорее всего это можно сделать только модификацией процедуры в бейсике и задействованием какого-то порта на вывод, но целесообразность мне непонятна.
Ну вы загнули. Если есть ZX-BUS, то можно вместо магнитофона грузить с флеш-карты через ZX-BUS.
Именно LOAD"", а точнее запуск процедуры TAPE_LOAD можно отследить по выборке команды из основного ПЗУ по адресу 1366 десятичное. Существующие импортные разработки (DivIDE и пр.) именно так и делают. В более общем случае (нестандартные загрузчики и пр,) - никак.
А нестандартный загрузчик все равно загружается стандартной процедурой. главное "виртуальную ленту" запустить, а там нехай грузится чем хочет.
Хм логично. А останавливать как будешь? Или фиг с ней?
Кстати можно еще и сделать автоматическое позиционирование на заданный файл, путем перехвата именно команды LOAD"..." и просмотра указанного имени файла.
Еще надо подумать как быть с дозагружаемыми уровнями. В этом случае надо ленту запускать, останавливать, да еще и позиционировать.
Не, так нельзя, остановки же могут быть, менюшки промежуточные, дозагрузки...
А как же эмуляторы правильно обеспечивают автостарт/автостоп нестандартных загрузчиков? Имхо явно отлавливать "IN 254" по ZX-BUS, если порт начал опрашиваться подозрительно часто и периодично - врубать мафон, перестал опрашиваться - вырубать.
Перехват LOAD"" фтопку.
Я думаю нужен еще более совершенный способ, который будет 100% совместим с любыми программами обращающими по out 254, чтобы небыло ложных срабатываний...(если не ошибаюсь) нужно отлавливать комплексно ловя несколько стандартных подобращений к процедуре еще до ее запуска....
Зачем же такие сложности? Главное - не остановить раньше времени. ;)
Если запоздали на пилоттон следующего блока, ничего страшного, потом дадим его сначала.
Хотя могут быть сильно извратные защиты с замеряемыми паузами - с ними эмуляторы справляются только в режиме "без ускорения и без автостарта/стопа", и то если tzx корректный.
А лучше напишите автору SPIN-а, он походу главный гуру и первопроходец в этой области.
Фигня какая. Навскидку даже и не вспомню, чтобы в каких-то играх с догружаемыми уровнями возникали проблемы с автостартом/стопом, на сколько бы мелких блочков ни был разит один догружаемый уровень (потому что загрузчики уровней как правило не наворачивались, вот для хитрых загрузчиков основного блока или просто целиком загружаемых игрушек изредка приходилось автостоп отключать), вручную - только на начало приходилось перематывать после GAME OVER. А tap-файлы "по определению" наименее проблемные из всех.
TAP файлы наименее проблемные только потому что они наиболее стандартные. Если грузить tap файл нестандартной процедурой, но загружающей стандартный формат, то тут как раз в эмуляторах и возникают основные грабли и с автостартом, и с остановкой виртуальной ленты.
Через стандартную точку входа то все на ура эмулируется.