Просмотр полной версии : вывод в порт
столкнулся с интересной ситуацией.
при попытке записи в нулевой порт значение отправится туда куда шла запись перед этим.
например в 48ом бейсике OUT 0,color изменит цвет бордюра.
в 128ом out 0,page ; переключит страницу.
интересно кто создаёт такой эффект: проц или обвязка ?
null_device
09.04.2024, 15:43
goodboy, а этот порт он на реальной машине, или в эмуляторе? Тут, как бы ещё неплохо было бы указать что за модель спектрума или клона.
- - - Добавлено - - -
Вроде как, при упрощённой дешифрации почти любой чётный порт детектится как #FE
сначала столкнулся с таким поведением в эмуляторах,
но сейчас специально проверил на фирме (резинка48к)
null_device
09.04.2024, 16:01
в 48ом бейсике OUT 0,color изменит цвет бордюра.
в 128ом out 0,page ; переключит страницу.
Если поведение первой команды мне хоть как-то понятно, то переключение СТРАНИЦ, через тот же самый порт в 128к режиме?
кажется разобрался.
на фирме #7FFD декодируется при условии A1 и A15 = 0 , #FE при A0=0
так что при записи в ноль все условия соблюдены.
null_device
09.04.2024, 16:33
Скорее всего, это аппаратная особенность ula.
- - - Добавлено - - -
goodboy, вспоминаю статью, вроде бы в спектрофоне, на тему упрощённой дешифрации портов фирменных машин. Это, в отечественных клонах, можно было себе позволить чуть ли не полную жёсткую дешифрацию. Учитывая любов некоторых наших проектов к укороченной записи команды обращения в порт конфигурации.
Barmaley_m
09.04.2024, 19:59
на тему упрощённой дешифрации портов фирменных машин. Это, в отечественных клонах, можно было себе позволить чуть ли не полную жёсткую дешифрацию.
Полная жесткая дешифрация дорого стоит. Это нужен дешифратор на 8 (при дешифрации только младших 8) или всех 16 бит. Я знаю только один клон - "Орель БК-08", где применялась полная жесткая дешифрация по 8 битам - там в качестве дешифратора стояла микросхема ПЗУ К556РТ4.
Я когда-то восхищался этим решением с РТ4, а теперь считаю - а зачем? ПЗУ стоит денег, его надо программировать, оно иногда ломается (ранние РТ4 были склонны к потере информации со временем). Микросхему надо разместить на плате, развести на нее все линии адреса (8 связей). Энергии немало жрет (0,45 Вт). А какая польза? Расширяемость? Так ведь расширяли по схемам, совместимым с другими клонами с неполной дешифрацией.
Если делать полную дешифрацию на логике (К555ИД3, К555ИД7, логические элементы) - то микросхем, связей между ними и финансовых затрат на все это получается еще больше. Надежность разве что выигрывает и энергопотребление.
Более того, я даже в проектах на FPGA не делаю полную дешифрацию адресов. Ресурсы у FPGA на это есть, но зачем их тратить? Логические блоки, связи между ними. Все эти ресурсы ограничены, и выгоднее их потратить на что-нибудь другое.
Полная жесткая дешифрация дорого стоит.
В общемто нет. Скажем у нас есть 16 портов. Берём дежифратор 4-16 с входами разрешения низким уровнем. 155ид3 например.
шину A0, A5-A11 цепляем на элемент 8И-НЕ
шину A1-A4 цепляем на A0-A3 дешифратора.
шину A12-A15 цепляем на элемент 4И-НЕ
Выход 8И-НЕ цепляем на вход ОЕ1 ИД3
Выход 4И-НЕ цепляем на вход ОЕ2 ИД3
Все. Получаем полный дешифратор четных адресов 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0x16, 0x18, 0x1A, 0x1C, 0x1E
Три микросхемы. Не так уж много за полную дешифрацию адреса.
Надо больше адресов? Ставим ещё один дешифратор ИД3 и вторую половинку 4И-НЕ используем... Будет 32 порта.
Внутри ULA схемотехнику можно очень упростить теоретически.
Тут скорее желание сэкономить говорит. Оно оправдано, если делать контроллер под задачу, который в принципе не предполагает дополнительных портов. Но для ПК общего пользования, который предполагает подключение произвольной периферии - экономия сомнительная.
- - - Добавлено - - -
Более того, я даже в проектах на FPGA не делаю полную дешифрацию адресов. Ресурсы у FPGA на это есть, но зачем их тратить? Логические блоки, связи между ними. Все эти ресурсы ограничены, и выгоднее их потратить на что-нибудь другое.
Всё от задачи зависит. В современных ПК, например, совсем полная дешифрация. СОвсем-совсем!:)
Barmaley_m
21.04.2024, 13:05
Три микросхемы. Не так уж много за полную дешифрацию адреса.
Ты только что доказал мою мысль. Целых три микросхемы. Которые можно было бы не ставить. Не тратить на них деньги, не размещать их на плате, не разводить связи (а разводка узла процессора на Спектрумах на двух слоях всегда была трудной задачей). Не паять их. Не тратить энергию на их питание. Они не выходят из строя. Не надо держать их запас на складе и бояться, что в один прекрасный день их снимут с производства или разберут у поставщиков, так что ты не сможешь производить и поставлять свои компьютеры. И так далее.
Особенно 155ИД3 - она же огромная. Ладно еще КР1533ИД3 - у нее корпус хотя бы узкий был.
Есть такая инженерная пословица: "Самая лучшая деталь машины - это та, которой нет". По соображениям, аналогичным приведенным выше. Чем больше опыт разработки и наблюдения за производством твоих приборов - тем больше я с этой мыслью соглашаюсь. Добавление деталей в схему, которых там могло не быть, добавляет в целом больше проблем, чем решает.
Внутри ULA схемотехнику можно очень упростить теоретически.
Там однозначно. Тогдашние БМК имели очень мало ресурсов. Что-то типа 8х8 (всего 64) базовых логических элементов. Там каждый был на счету.
Всё от задачи зависит. В современных ПК, например, совсем полная дешифрация. СОвсем-совсем!:)
Ну, сейчас ресурсов стало больше, вот их и не экономят. Кроме случаев, когда экономия себя оправдывает (типа ASIC-майнеров). Благодаря этому мне часто удается найти в какой-нибудь системе большое поле для оптимизации, "обработав" которое, получаешь результат на гораздо меньших вычислительных и схемотехнических ресурсах, чем у конкурентов. На серийной продукции это дает преимущество.
Взять еще одну простую вещь. В Спектрумах были порты ввода-вывода, доступные только на запись. Тот же порт #FE. Туда можно было записать цвет бордюра, но обратно его считать из программы было невозможно. В нынешних микроконтроллерах, SoC и IP-блоках на FPGA обычно делают "дружественные для программистов" порты, доступные на запись и на чтение. А вдруг кому-нибудь понадобится. Но, если подумать - то считывание из подобных портов нужно крайне редко, а затраты ресурсов нешуточные. Нужен дополнительный мультиплексор на 8 или более разрядов, связи к нему, и логика управления. Затраты ресурсов кристалла на реализацию двунаправленного порта в 2 и более раз выше, чем однонаправленного. Я в своих IP-блоках на FPGA не занимался подобными растратами, в результате они получались по ресурсам в разы компактнее тех, что поставляет производитель FPGA.
Еще один пример - инициализация аппаратных регистров при сбросе. Выглядит красиво на бумаге. Но для этого требуется развести к каждому регистру и триггеру сигнал сброса, и чтобы этот регистр дополнительно имел вход сброса. Но оправданы ли траты ресурсов разводки связей, если регистры можно при старте инициализировать программно?
Иногда такая оптимизация отделяла победу от поражения - когда в противном случае из-за плотности разводки не удавалось достичь нужной тактовой частоты, на которой работоспособна вся схема.
вспомнилось интро
https://youtu.be/B0EqN1jAdko?si=KNtFjZawf4E7l3Hm
тут через out (#FC),a
одновременно переключается страница/экран/цвет бордюра
Есть такая инженерная пословица: "Самая лучшая деталь машины - это та, которой нет".
Плюсую. Всегда стараюсь делать по минимуму, ибо по максимуму и дурак сделает.) Наша промышленность раньше старалась по максимуму, видать свои какие то были стимулы. Посмотришь на тот же CRT терминал, волосы дыбом. Зачем? Тут 10-ти чипов достаточно, причём обычных, а ни каких то хитрых. Нет, нужно было плату офигенных размеров городить, с офигенным кол-вом мс. Ужас! И так во всём.(
Но черезмерная экономия на портах сыграла очень нехорошую роль в Спеке.
Совсем полная дешифрация может и не нужна, но и такая куцая как на спеке - тоже тот ещё прикол... По сути просто дешифрацию портов спустили с самого процессорного блока спека на дополнительную переферию. И стандарта даже никакого не предложили.
А это уже совсем плохо.
Ребята, ну ё моё!
И стандарт был и концептуалист был, но его не стали слушать, просто выгнали (или сам ушёл) и выдали продукт, сами не понимая что это есть такое. А там настолько всё тонко, что прямо гениально.
Вот здесь я цитировал ЗАРулём (https://zx-pk.ru/threads/34979-samopalnyj-zx-riser-voprosy.html?p=1174811&viewfull=1#post1174811).
Barmaley_m
22.04.2024, 22:52
но и такая куцая как на спеке - тоже тот ещё прикол...
Ну, какая куцая? Даже если использовать по одному биту адреса на дешифрацию каждого порта - то можем реализовать 16 портов. Мало? А сколько всего портов было на Спеках, даже с развитой периферией?
1) Порт #FE
2) Порт #7FFD
3) Порты AY (2 шт.)
4) Порты ВГ93 - 5 шт.
5) Порты Centronics (Kempston-E) - 2 шт.
6) Порт Kempston Joystick
Всего 12 портов, и остается еще 4 в запасе. Кроме того, можно иметь 1 бит дешифрации на внешнее устройство, а еще 2-3 бита - на дешифрацию портов внутри этого устройства. И даже без сигнала IRQGE все проблемы решаются.
Понятно, что прошлого уже не изменишь, и все случилось как случилось. Но фактор адресов портов, по-моему, никогда сильно не мешал разработчикам тогдашней периферии. Пусть порт #FE откусывает половину всех адресов портов. Но оставшаяся-то половина остается. Ее можно использовать как хочешь, в том числе делать на ней полную дешифрацию.
И стандарта даже никакого не предложили.
Я могу предположить, почему не предложили:
1) Собирались сами разрабатывать всю периферию и рубить на ней бабло, а не отдавать этот рынок кому-то другому;
2) Не было времени продумать стандарт, который имел бы большой запас прочности на будущее. Начальство требует быстрее закончить работу. Вопрос будущего его не интересует - нужно здесь и сейчас получить хоть какой-то продукт для продажи с минимальным функционалом.
Но и так неплохой системный разъем получился. Любую периферию можно было туда цеплять, все необходимые сигналы были. Любое одно устройство. Более одного - уже проблема, но у остальных с этим было еще хуже. Какая периферия и с какой скоростью подключалась к Атари 800, например? К C64? К Амиге-500 или -600?
Lethargeek
23.04.2024, 22:48
Но и так неплохой системный разъем получился. Любую периферию можно было туда цеплять, все необходимые сигналы были. Любое одно устройство. Более одного - уже проблема, но у остальных с этим было еще хуже. Какая периферия и с какой скоростью подключалась к Атари 800, например? К C64? К Амиге-500 или -600?
ты серьёзно? уж скорее спектруму не снился ассортимент:
https://en.wikipedia.org/wiki/Commodore_64_peripherals
https://en.wikipedia.org/wiki/Atari_8-bit_computer_peripherals
https://www.computinghistory.org.uk/cgi/archive.pl?type=Peripherals&platform=Commodore%20Amiga
https://www.computinghistory.org.uk/cgi/archive.pl?type=Peripherals&platform=Commodore%2064
итд
- - - Добавлено - - -
Ну, какая куцая? Даже если использовать по одному биту адреса на дешифрацию каждого порта - то можем реализовать 16 портов. Мало? А сколько всего портов было на Спеках, даже с развитой периферией?
загляни в табличку и ужаснись: https://zx.clan.su/forum/11-46-1
лично я для юлакса своего искал долго номер, один-единственный
который ни с чем не конфликтовал бы полностью дешифруемый
так и не нашёл, пришлось смириться с меньшим из зол
Это замкнутый круг.
"Давайте сделаем максимально дёшево" - ок. Сделали. Но периферия зато подключается крайне трудно и получается дороже. На каждой периферии надо свой дешифратор. Отсутствие стандарта = конфликт адресов и так далее.
Самим производить всю периферию не реально. И даже самим при её производстве приходится на свои же грабли натыкаться.
Вот зачем в бетадиске какието "теневые порты" доступ к котором ещё и возможен лишь не иначе как через "жопу автогеном"? Чтобы программисты от недотраха не страдали?
В итоге сторонние производители плюются, сами все дёлать не могут - ресурсов нет. Перспектив развития платформы - тоже не особо...
В конце концов можно было бы сделать и неполную дешифрацию, но хотя бы отслеживать диапазоны портов. Ту же клавиатуру можно было бы разрулить тремя битами. А использовали 8. Сэкономили один дешифратор. Круто, чё...
Вот зачем в бетадиске какието "теневые порты" доступ к котором ещё и возможен лишь не иначе как через "жопу автогеном"? Чтобы программисты от недотраха не страдали?
Это своеобразная защита от случайного обращения к портам из программ, которые могут писать в порты что попало. А это может привести к порче данных на дискете...
Это своеобразная защита от случайного обращения к портам из программ, которые могут писать в порты что попало. А это может привести к порче данных на дискете...
Ок. Я не против. Пускай "защита". Но тогда сделайте вы НОРМАЛЬНОЕ API (в данном случае из нескольких команд) для доступа к произвольному порту из ПО пользователя.
Там же надо то релизовать всего то IN A,(C); ret и OUT (C),A; ret. Всё.
видно, на тот момент такой задачи перед разработчиками не стояло и необходимости никто не видел.
Несколько лет назад обсуждали 3D13/3D2F и было сказано, что даже вызовы через 3D13 не были официально прописаны. Только бейсик.
видно, на тот момент такой задачи перед разработчиками не стояло и необходимости никто не видел.
Несколько лет назад обсуждали 3D13/3D2F и было сказано, что даже вызовы через 3D13 не были официально прописаны. Только бейсик.
Ну 3D13 явно это API. все довольно красиво.
Так есть делается железо, то надо чтобы программисты могли с ним работать. И не через анус, желательно...
API, не API...
Было сказано, что на тот момент в офиц. документации Beta Disk оно не было его описано. Эти "тайные знания" были в нашей литературе описаны, а уж как до них докопались не знаю.
- - - Добавлено - - -
вот тут как раз обсуждали: https://zx-pk.ru/threads/23641-3d2f-ili-3d30/page1.html
Ок. Я не против. Пускай "защита". Но тогда сделайте вы НОРМАЛЬНОЕ API (в данном случае из нескольких команд) для доступа к произвольному порту из ПО пользователя.
Там же надо то релизовать всего то IN A,(C); ret и OUT (C),A; ret. Всё.
так есть такой api, заносишь адрес нужной инструкции IN или OUT в стек и делаешь jp в трдос окно, оттуда делается ret на инструкцию и обратно.
Там только с одним портом небольшая свистопляска требовалась, помоему системным #FF.
вспомнилось интро
https://youtu.be/B0EqN1jAdko?si=KNtFjZawf4E7l3Hm
тут через out (#FC),a
одновременно переключается страница/экран/цвет бордюра
А что за интро ?
А что за интро ?
Navy Seals от RST/Prestige
Barmaley_m
18.08.2024, 19:40
так есть такой api, заносишь адрес нужной инструкции IN или OUT в стек и делаешь jp в трдос окно, оттуда делается ret на инструкцию и обратно.
К сожалению, нет. Не было такого API. Где-то в коде TR-DOS был фрагмент OUT(C),A: RET. С его помощью решался вопрос записи в порты. Но для чтения портов свистопляска требовалась практически со всеми, а особенно - IN #1F. Считать #1F, да без побочных эффектов - это было тайное искусство. Исторически разные люди решали эту задачу по-разному, с большим или меньшим успехом.
Вот моя карта точек входа в TR-DOS V5.03 из дискового драйвера (radisk), которую я взял из публикации "Low-level disk driver" в каком-то из журналов, то ли ZX-Ревю, то ли ZX-Format, то ли уже не помню:
OUT_C_A:
PUSH HL
LD HL,2A53H
EX (SP),HL
JP 3D30H
DMA_RD: PUSH HL
LD HL,3FD5H
EX (SP),HL
JP 3D30H
DMA_WR: PUSH HL
LD HL,3FBAH
EX (SP),HL
JP 3D30H
WT_IRQ: PUSH HL
LD HL,3FE5H
EX (SP),HL
JP 3D30H
IRZ: LD HL,3F33H
PUSH HL
JP 3D30H
IN_1F: PUSH HL
PUSH BC
PUSH DE
XOR A
LD C,3FH
CALL OUT_C_A
LD A,0AH
LD C,05FH
CALL OUT_C_A
LD D,01H
CALL IRZ
CALL GET_POS
LD C,3FH
CALL OUT_C_A
LD A,B
POP DE
POP BC
POP HL
RET
И, для сравнения, их же реализация в случае "открытого" доступа к портам контроллера:
OUT_C_A:
OUT (C),A
RET
DMA_RD: LD B,4
DRD1: IN A,(0FFH)
AND 0C0H
JR NZ,DRD2
INC DE
LD A,E
OR D
JR NZ,DRD1
DJNZ DRD1
RET
DMA_WR: LD B,4
DWR1: IN A,(0FFH)
AND 0C0H
JR NZ,DWR2
INC DE
LD A,E
OR D
JR NZ,DWR1
DJNZ DWR1
RET
WT_IRQ: IN A,(0FFH)
AND 0C0H
JP Z,WT_IRQ
RET M
DRD2: INI
JP WT_IRQ
DWR3: IN A,(0FFH)
AND 0C0H
JP Z,DWR3
RET M
DWR2: OUTI
JP DWR3
IN_1F: IN A,(1FH)
RET
Что еще важно: подпрограммы DMA_RD и DMA_WR (прием и передача данных чтения и записи сектора) должны были вызываться именно те, что были в TR-DOS. Попытка реализовать тот же функционал на других функциях доступа к портам терпела неудачу: не хватало скорости процессора.
Вот весь мой драйвер дисковода81144.
так есть такой api, заносишь адрес нужной инструкции IN или OUT в стек и делаешь jp в трдос окно, оттуда делается ret на инструкцию и обратно.
Там только с одним портом небольшая свистопляска требовалась, помоему системным #FF.
Это не API, это костылеобход...
К сожалению, нет. Не было такого API. Где-то в коде TR-DOS был фрагмент OUT(C),A: RET. С его помощью решался вопрос записи в порты. Но для чтения портов свистопляска требовалась практически со всеми, а особенно - IN #1F.
да, это я уже подзабыл.
вообще странно что никто не сделал какой-то стандартный образ trdos c in a,(c):ret и out (c),a:ret, можно было сделать такой образ стандартом и использовать везде.
null_device
20.08.2024, 15:09
ZXMAK, любое изменение данных ПЗУ - потенциальный "затык" с тем ПО, которое использует фиксированные "точки входа", либо конкретные значения из него.
Barmaley_m
21.08.2024, 14:43
вообще странно что никто не сделал какой-то стандартный образ trdos c in a,(c):ret и out (c),a:ret, можно было сделать такой образ стандартом и использовать везде.
Такие образы TR-DOS появились, причем почти сразу. Уже в хакерской версии TR-DOS 5.04T (от Алексея Скоробогатова, кажется) были такие точки входа.
Но для софта это не означало, что можно пользоваться такими точками. Всегда был шанс, что у пользователя стоит фирменная TR-DOS v5.03 или даже v5.01. И что тогда? Тогда софт должен был или использовать универсальные точки входа, работающие на всех версиях; или детектировать версию и использовать подходящие для нее точки входа. Это лишь усложняло программу, без какой-либо практической пользы.
Поэтому сделать "стандартный образ" возможности на самом деле не было.
Что любопытно: TR-DOS v5.01 на практике почти нигде не встречалась. Точки входа в нее существенно отличались от v5.03. Большинство программистов не рассчитывало свой софт на работу с ней. Были такие, кто пытался детектировать версию TR-DOS (Николай Родионов в своей DCU, например) и в случае неудачи предлагал пользователю выбрать базовую версию (5.01 или 5.03). Был еще подход к детектированию базовой версии по ослабленным признакам - проверялись именно адреса точек входа. Так делал ASC в своем ASC Sound Master. Тот Спектрум, на котором работал ASC, имел именно TR-DOS v5.01. Наверное, 5.01 была у тех, кто среди первых подключал контроллер дисковода к Спектруму. Было это до начала массового распространения контроллеров в СНГ.
любое изменение данных ПЗУ - потенциальный "затык" с тем ПО, которое использует фиксированные "точки входа", либо конкретные значения из него.
насколько помню, в ходу были много разных версий. Наиболее популярная была 5.04T, также часто встречалась 5.03. Но даже с одинаковой версией были разные модификации. Стандартные процедуры были у всех одинаковые. На некоторых версиях действительно были проблемы с загрузкой некоторого софта, если правильно помню - проблемы были с официальной 5.03. Но такого софта было немного.
Был еще подход к детектированию базовой версии по ослабленным признакам - проверялись именно адреса точек входа.
да, я помню это. Детектирование версии использовалось во многих загрузчиках использующих прямое обращение к вг93... Помню даже вырезал понравившийся код инициализации процедур из какой-то демки и использовал его, даже не задумываясь на каких версиях он работает, на каких нет.
На некоторых версиях действительно были проблемы с загрузкой некоторого софта, если правильно помню - проблемы были с официальной 5.03.
Проблемы были из-за нестандартных загрузчиков в сочетании с отечественными дисководами типа 5313, на которых при остановке шпинделя головка могла сделать шаг и попасть на другую дорожку. А некоторые загрузчики этого не проверяли. На TEAC'ах, такой проблемы не было.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot