Написание новых утилит никто не отменял. Например, пока еще под TASiS нет прсмотрщика JPG и GIFок. Не в смысле, что япредлагаю тебе взять и сделать их, а как пример, что есть далеко не всё.
Это что касается текущей версии TASiS ядра v5.40
А на самом деле готовится принципиально новое ядро системы v6.x, и там будет много нового, в частности "прозрачная" подмена нижнего ядра по адресу #0000 подгружаемыми библиотеками, расширение менеджмента станиц (логическая, а не физическая нумерация страниц - можно формировать "своё поле памяти" для задач - с прицелом для многозадачности, где у каждой задачи будет "своя песочница" из страниц, но номера будут для программыф пользователя одни и те же, плюс защита "чуцжих" страниц от включения и проч.), непривязанность ядра системы к каким-то одним страницам (как сейчас - к странице #00) - т.е. перемещаемость в любую страницу, поддержка на уровне системных вызовов не только 64 страницы АТМ, а вплоть до всех 256 страниц ZX-Evo, поддержка расширенной палитры от DDp и многое другое.
Что касается упомянутых библиотек, то они могут перехватывать как обычных вызовы TASiS/iS-DOS, так и иметь свои дополнительные, но не через RST #10 (на ней по прежнему висит нижнее ядро исдоса, которое теперь является лишь одних из библиотек - "базовой"), а подключаться к остальным рестартам по необходимости - #RST #00,#08,#18,#20,#28,#30,#38.
Планируется как минимум графическая библиотека - чтобы уйти от привязки к одному "физическому" экрану (ZX ка в исдосе или консольный как в TASiS - будет реализована принципиальная возможность переключаемой поддержки с любым экраном (только меняй и дорабатывай библиотеки).
Плюс остро стоит вопрос о либо расширении файловой системы свыше 16Мб (как самый минимальный вариант), вплоть до поддержки FAT16/32 (как максимум) - тоже через дополнительную библиотеку.
Проекту много лет. Продвигался очень медленно с громадными перерывами на годы (у всех свои жизненные проблемы и обстоятельства), но сейчас выходит понемного на финишную прямую, и 2025 год, надеюсь, станет годом релиза нового ядра. А вот библиотеки и обвязку надо будет писать, писать и писать. Но это обещает быть очень интересным. Но чем больше светлых голов, тем лучше.
И да - FILESHOW работает!
- - - Добавлено - - -
Выше ответили - защита от MAGIC. Поискал - в 2019 году уже здесь на форуме обсуждали сабж:
https://zx-pk.ru/threads/30499-kolle...oj-knopki.html
Ячейка была #5C00, после отработки Magic туда гарантированно записывается число #C9.
А такая защита, которая не позволяет делать отгрузку вовсе, основана на том, что обработчик Magic из ПЗУ TR-DOS бездумно и активно пользуется стеком. В частности, в начале своей работы он сохраняет туда кучу значений, а потом делает множество вложенных вызовов подпрограмм.
Таким образом, если стек размещен в ПЗУ, то первый же возврат из подпрограммы в недрах TR-DOS приведёт к возврату на неправильный адрес (т.к. стек в ПЗУ, и правильный адрес возврата не может быть туда записан при выполнении команды CALL) и сбою.
Но этот сбой можно контролируемо перехватить. А именно, как верно написал goodboy выше: размещаем стёк близко к началу экранной области. Тем самым мы сами можем пользоваться стеком в некоторой мере. Когда срабатывает Magic, то в стек записывается куча значений, и он начинает указывать на ПЗУ. А там, в конце прошивки TR-DOS, размещено много #FF. Первый же возврат из подпрограммы происходит по адресу #FFFF, туда ставим команду JR, которая попадает на адрес #FFF4, ну а туда уже размещаем код обработчика Magic, где делаем что угодно (издеваемся над пользователем).







Ответить с цитированием