Alikberov, что имеется в виду под режимом памяти?
Вид для печати
Alikberov, что имеется в виду под режимом памяти?
Вопрос напрямую касается этой темы и я бы хотел проверить собственную модель памяти пока хотя бы в рамках эмуляции.Цитата:
Сообщение от Pyk
Вложение 80410
Режим холодного старта
По сигналу Сброса триггер ТМ2 сбрасывается и дешифратор ИД7 блокируется, а ПЗУ РФ2 принудительно включается и проецируется в памяти по зеркалам 0000…07FF / 0800…0FFF / 1000…17FF / 1800…1FFF / 2000…27FF и т.д., при этом код ПЗУ вполне может функционировать при условии, что нету памяти под стек и никаких УВВ. То есть, инструкциями EI/DI генерировать звук подобным кодом:Однако, в Emu80 ничего не происходит, так как Сброс передаёт управление на адрес F800, откуда Jump'ится на 0003, где сплошные 00.Код:.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000 C3 03 00 21 20 00 16 FF 7E B7 CA 03 00 FB 3C C2
0010 0E 00 7E F3 3C C2 14 00 15 C2 08 00 23 C3 06 00
0020 7B BD DE EF F7 89 C4 E2 F1 F8 96 CB E5 F2 F9 00
Это конфигурацию нужно подправить или вообще не предусматривалось?
(Из схемы за 1986 год это следует!)
Ведь до первого чтения из 8000…FFFF дешифратор адрес заблокирован и ничего адресовать не может, а ПЗУ выбирается принудительно.
Режим 64 Кб
Хотелось бы в рамках эмулятора проверить режим памяти в 65536 байтов ОЗУ, когда код, работающий с адресов 0000…7FFF получает в 8000…FFFF дополнительное ОЗУ и имеет тем самым все 64 Кб на запись и чтение, так как ИД7 вновь отключается (подробнее - в теме).
Потому, хотелось бы в конфигурации этот режим описать.
P.S.: Спасибо!
В частности, если разместить дополнительное ПЗУ по адресам F000-F7FF, что и предусмотрено в оригинальном Мониторе, то возникает неоднозначная ситуация:Нужен некий компромисс, о котором я и говорю: В зависимости от зоны чтения инструкций по M1 переключать конфигурацию.
- Если SDOS установлен, по F000-F7FF размещаются порт КНГМД и дополнительное ПЗУ уже вне доступа
- Если SDOS отключить, запуск дополнительного ПЗУ возможен, но SDOS уже не работает
В данном случае:(Про что в чатах уже мною уже поднимались вопросы.)
- По GE000, так как счётчик команд будет находиться в интервале E000-EFFF, отображать область F000-F7FF как порты КНГМД
- По GF000, так как счётчик команд будет находиться в интервале F000-FFFF, отображать область F000-F7FF как ПЗУ
Нужны дополнительные опции конфигурации для оперативного изменения адресного пространства в зависимости от счётчика команд PC.
Pyk, когда новое обновление будет?
Полгода уже прошло.
Желательно ещё иметь следующие функции (озвученные в чате):
- Связь эмуляторов в двух окнах по магнитофонному интерфейсу (не обязательно именно через API-звука: можно просто пайпы использовать, например, галочкой в опциях)
- Возможность загрузки исходных ASM-листингов
Офигеть! Вот ведь свиньи неблагодарные! Хотя... это по нашему.(Цитата:
Сообщение от ZEman
M80, Я гдето ругался ?
грубить некому не хотел, просто я обычно так спрашиваю.
видел на nedopc и гитхабе что в последнее время прогресс какой-то идёт вот и спросил.
во какой неженка нарисовалсоЦитата:
Сообщение от M80
демонстративно высказываю свое ФИИИ
Прогресс, действительно, некоторый есть. Думаю, в марте.Цитата:
Сообщение от ZEman
Сложно и сомнительна необходимость, вряд ли сделаю, по крайней мере в ближайшее время :(Цитата:
Сообщение от Alikberov
Есть в планах, хотя и не не ближайшую версию, в любом случае - каков желаемый формат листинга?Цитата:
Сообщение от Alikberov
В смысле формат?Цитата:
Сообщение от Pyk
В основном, чтобы не было ограничений на количество псевдооператоров ORG и был оператор выбора мнемоник - INTEL или ZILOG.
Alikberov, я сначала подумал про lst-файлы для отладчика.
Предлагаешь встроить ассемблер в эмулятор?
ну асм в эмуляторе это конешно класснаЦитата:
Сообщение от Pyk
но как правило он проигрывает по функционалу нормальномуу компилятору
и таки изобретение велосипеда...
хотя очень удобно написал 3 строчки кода
запустил
остановил в дебагере
поправил/скомпилил
запустил
чисто для встроенный асм+дебагер
я все еще запускаю emuzwin
хотя тот полносью себя изжил
а так самая главное в набортном асме это вложенные DUP-ы :)
а так возьми приладь готовый новый сджасм :)
правда мнемоники и8080 он не умеет
(думаю можно будет легко добавить да еще и смержить с основным потом)
Так на канале чата я о том и говорил!:DЦитата:
Сообщение от Pyk
Уж слишком много возиться приходится в цикле Правка->Сохранение->Конвертация->Загрузка.:v2_wacko:
ну в нормальном сорцеЦитата:
Сообщение от Alikberov
правка
1клик компиляция
загрузка
хотя на некоторых машинах загрузка ущербная...
(особенно там где какието мудозвоны додумались клянчить полное имя для загрузки с ленты)
ну вот по этому и должны быть снапшоты
и компилер должен генерить снапшоты а не образы лент
на время разработки/отладки
а так набортного асма можот быть недостатошно для нормального коденга
это удобно отлаживать оттдельные процедуры
в "большых" софтах при компиляции еще вызываетсо бинарники, пакеры итд
может вместо набортного асма
просто запилить вызов внешнего компиллятора и загрузка дампа памяти в память и регистров?
но опять редактировать удобно в привычнном тебе редакторе
а не в каком то бедном окошечке набортнного асма
а если оставить только скомпилить и загрузить
то это мпрактически мало отличаетсо от вышеуказаной цепочки
Как-то у Вас слишком сложно.Цитата:
Сообщение от NEO SPECTRUMAN
Сейчас в эмуляторе три способа загрузить файл:Я всего лишь предлагаю, чтобы вместе с файлами *.RK поддерживались файлы *.ASM и грузились такими же способами. Типа, исходный ASM-файл перетащил на окно эмулятора и всё. Пусть даже по директиве I всё так же срабатывает, что будет отлично!
- Загрузка через Меню
- Загрузка через Drag'n'Drop
- Загрузка директивой I
Не нужно вообще пользоваться сторонним транслятором с ассемблера в принципе.
Эмулятор, как самодостаточная интегрированная среда - разве плохо? :-)
А для отладки - достаточно псевдооператором .BREAK в листингах расставить всех точки останова, чем искать их под клавишу F9.
Ничего не обещаю, но есть одна идея, подумаю.Цитата:
Сообщение от Alikberov
Мне эта фича кажется чужеродной в эмуляторе. Ассемблерами все пользуются разными, часто проекты состоят далеко не из одного файла, а сборку и запуск в эмуляторе можно настроить буквально по одной клавише в любой IDE... А вот inline-ассемблер в отладчике надо будет сделать.Цитата:
Сообщение от Alikberov
А вот это, как ни странно, мне кажется наиболее реальным и требующим минимальных усилий на реализацию, так как основа для этого в эмуляторе уже есть. Попробую сделать. Если не вылезут какие-то подводные камни, должно вроде бы получиться...Цитата:
Сообщение от Alikberov
- - - Добавлено - - -
Ох... Для начала сами снапшоты бы доделать... ;)Цитата:
Сообщение от NEO SPECTRUMAN
Спасибо!Цитата:
Сообщение от Pyk
Надо теперь как-то заняться написанием хотя бы крошечной демонстрации, чтобы можно было и проверить затем в новеньком эмуляторе.;)
Решается одним батником. Поправил, сохранил, запустил батник. А он уже скомпилирует, запустит эмулятор и загрузит в него исполняемых код. В качестве примера можно использовать мой вариант для Специалиста.Цитата:
Сообщение от Alikberov
а тут оказывааетсо что эмулятор не умеет грузить быстро ленту и быстрого режима нету :)Цитата:
Сообщение от CityAceE
(правда это про другой эмулятор а не про этот)
- - - Добавлено - - -
наверное ты мало представляешь себе что такое исходный ASM-файлЦитата:
Сообщение от Alikberov
А именно про этот. Emu80 так умеет. И я этой его возможностью активно пользуюсь.Цитата:
Сообщение от NEO SPECTRUMAN
Написал свой для Midnight CommanderЦитата:
Сообщение от CityAceE
Но эмулятор стабильно падает при некоторых манипуляциях.Скрытый текст
Код:shell_patterns=0
##############################################################################
+ f \.bin$
0 Translate to RKR
./bin2rkr.sh %f
+ f \.bin$
0 Translate/Execute in Emu80
./bin2rkr.sh --run %f &
Код:#!/bin/bash
function save_rkr {
local codes=$(xxd -g 1 "$1" | sed -E "s/^.{9}(.{3,48}).*$/\1/g" | sed -E "s/([0-9a-f]+)/0x\1/g" )
local dump=(${codes})
local crc86rk=0
local length=${#dump[@]}-1
printf "\x00\x00\x`printf "%02X" $((length>>8))`\x`printf "%02X" $((length&255))`" > $2
for code in ${dump[@]}
do
local data=$((code))
if [[ $length -gt 0 ]]
then
crc86rk=$((crc86rk+data*257))
else
crc86rk=$((crc86rk+data))
fi
((length-=1))
crc86rk=$((crc86rk&0xFFFF))
printf "\x`printf "%02X" $((data))`" >> $2
done
printf "\x00\x00\xE6\x`printf "%02X" $((crc86rk>>8))`\x`printf "%02X" $((crc86rk&255))`" >> $2
}
if [[ "$1" == "--run" ]]
then
temp_file=$(mktemp)
save_rkr $2 ${temp_file}
wine ~/Emu80/Emu80qt.exe --platform rk86 --run ${temp_file}
rm ${temp_file}
else
save_rkr $1 ${1//.bin/.rkr}
fi
[свернуть]
(Загружать через меню, перетаскиванием или директивой I - надёжнее: Не падает сутками!)
Хм.. Тогда тут скорее всего мы имеем дело с какой-то ошибкой, если тип загрузки влияет на стабильность эмулятора. Я в конфигурации Специалиста ни с чем подобным не сталкивался.Цитата:
Сообщение от Alikberov
А как тогда называется вот это?Цитата:
Сообщение от NEO SPECTRUMAN
Pyk, тут вот в комментариях под моим видео про ассемблер пошла речь про профилирование функций в Emu80. Нет ли в планах прикрутить к эмулятору такую вещь? Или счётчик тактов не просто так в дебагере есть, и профилирование каким-то образом уже возможно?
Цитата:
поддерживались файлы *.ASM и грузились такими же способами. Типа, исходный ASM-файл перетащил на окно эмулятора и всё.
ну называетсо то такЦитата:
Сообщение от Alikberov
но компилеров 100500 штук
у каждого свои особености записи и дополнительные директивы
даже сами команды, благодаря каким то дебилам, могут трактоваатсо по разному
сорец может инклудить все что угодно а иногда и запускать другие софты
так что под "и всё"
задачка совсем не простая и сопаставима с изобретением велосипеда
Надо бы найти проблему, раз он падает, тем более стабильно - проще будет локализовать.Цитата:
Сообщение от Alikberov
Если что, у меня есть утилита bin2tape для конвертирования бинарных файлов в rk и еще кучу форматов.Цитата:
Сообщение от Alikberov
Счетчик есть, но пока этим все и ограничивается. Не читал пока те комментарии, в каком виде хотелось бы видеть профилирование?Цитата:
Сообщение от CityAceE
Я думаю, что в любом. Лишь бы чтобы можно было хоть как-нибудь замерять количество тактов, отъедаемых участком кода или функции, чтобы не считать всё вручную.Цитата:
Сообщение от Pyk
Я тоже об этом подумал. Исходники мои - выше. Может что-то там не так?Цитата:
Сообщение от Pyk
Или просто wine под Raspberry подводит.
Подсчёт контрольной суммы под Bash'ем - отличная разминка для мозгов была!Цитата:
Сообщение от Pyk
(Привык не гуглить по качалкам, а писать сам.)
CityAceE, разово замерить количество тактов, за которое выполняется функция, не проблема и сейчас. Я так понимаю, что нужна именно статистика в том или ином виде, процент процессорного времени, которое отнимает некоторый участок кода?
Кстати, обычно я в листингах каждую строчку комментирую подсчётом тактов (по памяти или из таблиц). Можно высвечивать количество тактов (опционально) у каждой инструкции в окне отладчика?Цитата:
Сообщение от Pyk
Ещё не хватает добавления брейк-поинта не только по F9, но и введением конкретного адреса.
И функции быстрого переключения области дампа (по Ctrl+цифра запоминается до десяти адресов, по Shift+цифра - дамп переключается на нужную).
Спасибо!
Alikberov, пожелания понятны. Отладчик как раз перерабатываю, хотя и медленно дело идет. Что из этого получится учесть, пока не знаю.
Классический профайлер, насколько я понимаю, именно так и работает. Запускаем программу, она какое время работает, а потом мы смотрим сколько в процентах заняла та или иная функция от всего времени работы программы. Основная задача - выявить самые жрущие процессор процедуры и попытаться оптимизировать их.Цитата:
Сообщение от Pyk
CityAceE, ну вот и надо подумать, в каком виде это можно было бы реализовать. В классическом виде процедур здесь нет, вывести проценты по именам функций не получится... Может быть, в каком-то эмуляторе уже реализовано подобное? Основная проблема даже не в реализации, а в том, как это представить, чтобы было удобно пользоваться...
В Virtual Vector, за что Ramirosу большое спасибо. В большой программе не всегда очевидно, какие участки являются критичными по скорости, и профайлер VV в таких случаях очень помогает.Цитата:
Сообщение от Pyk
Боюсь, меня засмеют!!!Цитата:
Сообщение от Pyk
А если просто построить статистическую диаграмму/гистограмму по ячейкам памяти и обращений к ним (типа, красным - код, зелёным - чтение данных, жёлтое - запись), горизонталь - адрес, вертикаль - циклы использования?
ivagor, спасибо, посмотрю как у него сделано. Кстати, пришло в голову, что и идею "базыря" из v06x можно использовать, просто немного в другом качестве, да и Alikberov, тоже выше на подобное намекает :)
а это можно выявить и через количество чтений\записей\исполнений одного байтаЦитата:
Сообщение от CityAceE
Вот для этого у меня и сделана heatmap. Зелёное -- чтение, красное -- запись, синее -- исполнение кода.Цитата:
Сообщение от NEO SPECTRUMAN
(в bk2010)
кинь скриншот как оно выглядит утяЦитата:
Сообщение от Sandro
Посмотрел. Да, неплохая идея. Конечно, надо будет сделать эту карту как минимум кликабельной, да и вообще, подумать, как эту идею развить...Цитата:
Сообщение от Sandro