а в чем конкретно заключается помощь?
Вид для печати
а в чем конкретно заключается помощь?
Да думал, что кто-нибудь знает, как (скриптом, или как-нить ещё) можно выдернуть из idb-базы метки с комментариями. Да видимо простых путей нет - начал всё вручную перелопачивать.
Я вроде предлагал програмку для выдирания каментов из lst-файлов? Так нужна или нет?
Можно, в принципе. Если не затруднит.
Пока проистекает нудное причёсывание листинга дизассемблера, переосмысливание некоторых моментов и написания руководства я решил подбрасывать дровишек в эту "топку", чтоб не завяла тема и чтоб люди не скучали. Поэтому потихоньку буду выкладывать заметочки, которые пишу для себя при исследовании ПЗУ. Итак! Заметка намберван. "Переменные, переменные!"
Что будет, если сразу после загрузки компьютера напечатать:
PRINT ABC
Компьютер ответит:
0
Оk
Вот так вот просто, незатейливо. Это, конечно, может породить кучу проблем. Но с другой стороны, это довольно-таки удобно. Теперь наберём:
LET ABC=123
PRINT ABC
123
Ok
Очевидные вещи! Но, что здесь происходит? Что такое это ABC, и где она хранится? Разберёмся по порядку.
Переменные с точки зрения Бейсика могут быть двух видов - числовые и строковые. По адресу ENBASPRG находится системная переменная, которая указывает на конец Бейсик программы. Вот тут то и начинается область переменных. После включения компьютера эта область начинается с адреса &h4003. По адресу BGARRAY располагается системная переменная, которая хранит адрес начала области массивов (с массивами разберёмся позднее). А вот по адресу VAR_TOP находится системная переменная, которая хранит адрес конца области переменных. Таким образом, все наши переменные располагаются в области начинающейся с ENBASPRG и заканчивающейся на VAR_TOP. Под каждую переменную отводится 6 байт. Рассмотрим форматы переменных:
<Имя (2 байта)> <Данные (4 байта)>
1. Числовые переменные.
Два байта - определяют имя переменной. Формируются следующим образом. Из имени переменной берётся два первых символа и меняются местами. Таким образом для нашей переменной ABC эти два байта будут выглядеть как BA. Отсюда следует неутешительный вывод - имя переменной может состоят из скольки угодно букв, но значимыми будут только первые две! Т. е. переменные ABC и ABD для Бейсика - абсолютно одно и то-же. Исключение составляют строковые переменные (AB и AB$ - разные вещи).
Четыре байта - собственно число в формате BCDEINMEM.
2. Строковые переменные.
Два байта - также определяют имя переменной и формируются по тем же правилам, что и для числовых переменных. Единственное - после преобразований в первом байте определяющем имя переменной старший бит устанавливается в 1. Это и говорит о том, что переменная строковая!
Два байта - Длина строки. Сначала идёт младший байт, потом старший.
Два байта - адрес, по которому собственно и располагается строка. Адрес этот должен лежать в области с BGSTRAR по ENSTRAR. Строки в памяти располагаются от старших адресов к младшим. Видимо с целью какой-то там оптимизации. Соответственно, как и у длинны - младший байт адреса первый, за ним старший байт адреса.
Имея эту информацию уже довольно-таки несложно написать парсер переменных. Хранение же переменных получается довольно компактным.
Рассмотрим теперь ситуацию, когда надобно создать переменную из машинного кода и затем использовать её где-нибудь, например в печати оператором Бейсика PRINT.
Вот код, создающий новую (или работающий со старой, если есть) переменную:
Ну вот! Программа наподобие:Код:ORG 0x5000-0x26
DB 0x1F, 0xA6, 0xDE, 0xBA, 0xCC, 0x13, 0x7D, 0x74
DB 0xD0, 0xD0, 0xD0, 0xD0, 0xD0, 0xD0, 0xD0, 0xD0, 0xD0, 0xD0
DB 'tstprg'
DB 0x1F, 0xA6, 0xDE, 0xBA, 0xCC, 0x13, 0x7D, 0x74
DW START, ENDE, START
START:
lxi h, name; грузим в HL адрес имени переменной
call 0x0b1a; GETVAR
push de; тут в DE - адрес содержимого вновь созданной переменной
lxi h, numb; грузим в HL адрес нашего числа
call 0x13c6; FIN - переводим строку с числом в FACCUM
pop hl; теперь адрес содержимого нашей переменной в HL
call 0x1319; FCOPYTOMEM - копируем FACCUM в память по адресу в HL
ret
numb db "1.234E2"
db 0x0
name db "AB"
db 0x0
ENDE:
END
Выдаст следующее:Код:10 X=USR$(&H5000)
20 PRINT AB
123.4
Доброго всем дня!
Выложил очередную поправленную версию. Теперь в архиве:
- Вордовский документ (написание в самом разгаре)
- Непосредственно IDB
- Тексты MAP, LST и HTML
В данный момент идёт написание примеров. Всё будет добавляться в вордовский документ по мере написания. Также планирую внести ряд изменений в IDB, т. к. есть несколько пока нерешённых моментов. Самый болезненный из них - работа с лентой. Если всяческие примеры можно отработать на эмуляторе, то с мафоном такие фокусы не пройдут. Тут нужен вдумчивый подход и куча времени. Пока на этом всё.
это микрософт бейсик все-таки а не альтаир
я тут где-то на форуме проводил исследование родословной ...
http://zx-pk.ru/showthread.php?t=234...E5%E9%F1%E8%EA
это наследник Microsoft 8K BASIC Ver 3-2 (по крайней мере тот что SURA)
Microsoft 8K BASIC Ver 3-2 -> Micro80 -> RK86 -> SURA
Ку!
А времени то прошло! Маммая! Чуть поправил дизассемблерный листинг и вордовский документ. Но надо текста много писать. Не успеваю:(
Столкнулся с различием между эмулятором и реальным компом. Речь про порт 86h (бит d4), "ГАШ" гашение изображения. В эмуляторе EMU нулевое значение данного бита приводит к чёрному фону и чёрному растру, а в реальном компе в режиме 0 и 2 фон остаётся без изменений, а растр "зануляется", а в режиме 1 происходит срыв растра, глюк и восстановление изображения в первоначальное состояние. Полез посмотреть в принципиальную схему, так там такой лес нагородили ради этого, вместо того, чтобы "ГАШ" подать на D13.2. Там и 5 нога даже свободна. Ну, стало бы нулём зажигаться изображение, а единицей гаситься - не такая уж беда на этапе разработки.
С моей точки зрения, в эмуляторе всё намного логичнее, чем в реале: 0-нет изображения, 1-есть. Погасил экран, нарисовал картинку, зажёг экран. В реале, в режиме 0 - более-менее, погасил растр, заполнил буфер символами, зажёг растр, но в режиме 2 смешно - погасил растр и получил кучу разноцветных 8-битных полей. Применимость на практике этого - нулевая.
Интересное наблюдение. При инициализации D33 (КР580ВВ55А) записывается управляющее слово 81h (10000001b), что, если я ничего не напутал, говорит о том, что выбирается режим 0 (d6,d5=0) для всей микросхемы, для канала A - вывод, B - вывод, С (d4-d7) - вывод и С (d0-03) - ввод. В руководстве пишется, что порт 80h (A) - чтение/запись, 81h (B) - чтение, 82h - запись. Хочу понять, о чём идёт речь? Разработчики ограничивают использование портов в виде рекомендации? Вижу противоречие в настройке режима микросхемы и того, что пишется про порты.
В связи с этим вопрос - а что случится, если 81h порт не читать, а записать туда единицы и начать нажимать кнопки? Смотрю схему и рассуждаю, что если канал B будет выдавать высокий уровень напряжения, то при нажатой кнопке через один из диодов V1-V10, начнёт течь ток в аккурат в дешифратор D1 (диоды и D1 - это на плате клавиатуры). Не начнётся ли соревнование между D33 и D1 клавиатуры на предмет, кто первый расплавится? Или я не совсем верно понимаю, как работает ВВ55 и режимы чтение/запись каждого из каналов как-то ещё определяются, кроме записи управляющего слова?