приведу к примеру MSX.Сообщение от SfS
там API в основном использовали только японские фирмы, европейцы в играх напрямую лезли сами в порты.
потому-что это быстрее.
тут приходиться выбирать стиль программирования.
правильное как правило выходит тормозным.
Barmaley_m (18.11.2023)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Вот, кстати, да. На Спеке тоже есть хороший пример - точка входа TR-DOS #3D13. Де-факто стала стандартным API TR-DOS. В конце 90х - начале 2000х начали появляться разные IDE- и SD-Card-интерфейсы. И программы, использовавшие точку #3D13, без изменений продолжали работать.
Но в середине 90х никто не думал о том, что когда-нибудь появится другое железо, которое будет доступно через #3D13. В среде спектрумистов было престижно лезть в порты контроллера дисковода напрямую. Это давало доступ к некоторым функциям контроллера: форматирование, чтение и анализ дорожек. С прямым доступом можно было читать/писать диски в формате MS-DOS и других нестандартных форматах на 800К против стандартных 640К. Прямой доступ давал улучшение производительности диска, более точный контроль над ошибками. Всякие программы форматирования и восстановления дисков (DCU, ADS, тысячи их), IS-DOS, лезли в порты напрямую. Я тоже в своих проектах так делал. Так делал и ASC в своем ASC Sound Master и других проектах. Так делали знаменитые создатели Demo - группа Code Busters, белорусские Dream Makers, Rush и др.
Но все эти проекты оказались непортируемы на более современные носители - IDE-винчестеры и SD-карты.
Да, полностью соглашусь.
Есть и противоположный пример, где все строго следовали API - CP/M. API там было весьма скудным, но достаточным. А зоопарк железа был огромным, так что соблазна лазить в порты напрямую ни у кого не возникало. Все понимали, что это сделает программу непортируемой на другие CP/M-машины. Конечно, какие-то аппаратно-зависимые проекты под CP/M где-то были. Но они не распространялись за пределы узкого круга железа. А те проекты, которые распространились повсеместно - они все строго следовали API.
Среди наследия CP/M - огромное число профессионального софта, включая редакторы, файловые утилиты, хорошие ассемблеры, дизассемблеры компоновщики, бейсики, компиляторы Фортрана, Паскаля, Си. Создатели таких проектов - Microsoft, Digital Research, Borland. Были и архиваторы, были текстовые игры, и вообще тысячи всего.
Но не было графики. Не было демок и игр, выжимающих максимум из железа. Не было стандартного доступа к памяти выше 64К (разве только как RAM-Disk).
Последний раз редактировалось Barmaley_m; 18.11.2023 в 21:04.
1 тут ты ошибаешься, в divIDE/MMC полная эмуляция давно существует.
2 стандартная функция #05,#3D13 спокойно прочитает сектор любой длины
3 проблемы с прямым доступом к портам возникли ещё в 90х (когда версию trdos 5.01 сменила 5.03)
в ранних программах (типа ADS) была проверка на версию и корректировка адресов вызова процедур
andrews (20.11.2023)
чуток дополню
в последних прошивках ПрофПЗУ скорпиона также присутствует "эмуляция" вг93 и загрузчики использующие точку входа #3d2f/#3d96 вполне себе прекрасно работают
...ну по крайней мере в большинстве случаев
SERGEY256 (19.11.2023)
Точка входа TR-DOS #3D13 не содержала всех тех функций "форматирование, чтение и анализ дорожек" и прочих. То есть налицо недостаток функционала API.
Если бы всё это было - то особо никто бы и не лазил "напрямую в регистры".
Тем более, что никакого выигрыша в скорости в данном случае это не даёт. Просто обход недостатков стандатного ПЗУ.
Собственно, любой программист - хоть игрушек, хоть системного ПО - так или иначе создаёт набор библиотек с нужным ему API.
Все эти "игровые движки" - тоже по сути готовые модули со своим API.
Сейчас создателям ПО и в голову не придёт "лезть напрямую в регистры" видяхи или звуковухи. За исключением драйверописателей.
У спектрума видеопамять была "константой". Потому в неё безбоязненно лазили напрямую. Плюс скорость. В вот если был десяток видюшек, да разных... То фиг бы там куда лазали помимо API.
на кросс-системах с колоссальными ресурсами памяти и быстродействия это вообще не проблема! Достаточно однообразно верифицировать версии софта и железа и перестать загонять юзера в нужный тебе трек. Вот эта чехарда с версиями винды и переходом на 64 бит 99% юзеров не нужна! А кому она нужна? Только тому, кто зарабатывает деньги прежде всего на железе.
- - - Добавлено - - -
ну почему же? Для коммерческого софта чем непонятней непосвященному код - тем лучше. А в России это еще и способ сохранить на годы вперед высокооплачиваемое рабочее место ( так было в телефонных компаниях, где мне доводилось работать). А регистры, если они конечно правильно задокументированы позволяют работать и непосвященным новичкам с железом компании. И ассемблер, кстати тоже является "великим уравнителем" всех программистов.
- - - Добавлено - - -
если API не были адекватно описаны на английском и не были доступны бесплатно, то учить ради этого европейцу японский конечно же не хотелось.
Последний раз редактировалось andrews; 20.11.2023 в 10:00.
оффтоп про msx
Границу на MSX по использованию BIOS / прямому обращению к портам нельзя четко провести между японскими и европейскими программистами. BIOS использовали в первые годы (причем даже тогда не все), когда для MSX писали практически только японцы. Игрушки были сравнительно простые и быстродействия хватало. Когда подключились европейцы, то они в основном портировали игры со спека, и не особо заморачивались использованием возможностей msx (спрайты, тайлы). Там в основном надо было побыстрее пересылать фрагменты изображения в видеопамять, как на спеке и мимо BIOS выходило явно быстрее. Но в то время и японцы стали все больше напрямую. А если взять например Konami, то они хотя и японцы, но не видел у них ни одной "корректной" игры, использующей только BIOS, всегда лезли в порты.[свернуть]
Вот воткнул ты новую видяху или сетевуху в комп. И? Кто там выше драйвера "в регистры" лезет?
Я не говорю про какое-то "спецоборудование". Там может быть всё что угодно. Но обычно это оборудование не меняется за время своей жизни.
То есть каждый "новичёк" будет по новой изучать и программировать все 1599 регистров сетевухи?) А зачем ?! Это во-первых коммерчески невыгодно, во-вторых просто не нужно.
Недаром, сейчас очень многие производители предоставляют библиотеки работающие со своим оборудованием.
Ну конечно же это пример из личного опыта. Купили готовую операционку реального времени для ЦАТС. В описании было про поддержку интересной компании микрухи, которую и установили на плату процессора. Запустили программу -не работает! В коде рабочей программы станции на С/C++ ковыряться не стали, а пришлось дизассемблировать драйвер операционки. Там вместо кода оказалась "заглушка". Обратились к компании -производителю операционки. Те ответили, мол, ждите полгода, будет код. Обратились в компанию производителя микрухи в Японию про описание регистров микрухи. Те послали на й. Проект приостановился, компания возмещала убытки заказчику, а из меня сделали "козла отпущения" и уволили. Так как оказывается и нанимали-то меня именно с этой целью, так как не были уверены что все пройдет гладко. Поэтому еще раз: адекватное описание регистров и ассемблер( ну и прочее до получения исполняемого кода и его загрузки(программирования) . Всё остальное уже "роскошь"
- - - Добавлено - - -
если что-то не работает как надо - придётся! Так как программист фирме стоит даже сегодня на 3 месяца от силы $10 000 даже при зп вбелую, а штрафные санкции за неработающее и не отгружаемое оборудование могут быть на порядки больше и это бьет по карману учредителей.
Последний раз редактировалось andrews; 20.11.2023 в 11:50.
Это как раз относительно нетипичный пример.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
