У меня была подобная проблема с папками на примонтированых дисках из линукса, оказалось что папки имеют ненулевой размер, при этом папки с дисков реально пренадлежащих винде всегда имеют нулевой размер. может и тут что то подобное?

Можно ли добавить эмуляцию приставки "Эльф"? Приставка спектрум-совместимая, схема отрисована, порты расписаны, прошивки слиты (осталось ещё мои картриджи посчитывать, у меня не такой, как уже считали)? Всю инфу по приставке собрал Prusak здесь: http://zxbyte.ru/alf.htm

Сделал конфиг для Эльфа: http://bashkiria-2m.narod.ru/files/alf.rar

В статье ошибка, порт управления банками памяти не 1F, а 5F. Раскладка битов джойстика тоже другая (в обратном порядке). На фото две кнопки Fire, я пока сделал одну, как в статье, т.к. в программах анализируются только 5 бит. Со вторым джойстиком тоже не понял, судя по всему данные с него должны быть инверсными, иначе некоторые игры виснут в цикле опроса джойстика (как будто кнопка постоянно нажата).

Со сменой картриджа пока не совсем понял, по сбросу не реагирует, приходится стартовать конфиг заново. Кроме того, есть ошибка в эмуляторе, если длина файла не кратна 16Кб (учту в будущих версиях).

Есть такое пожелание: сделать эмулятор бекэндом для отладчиков. Эмулятору придется слушать некий TCP порт и в зависимости от команд в приходящих пакетах, отвечать о состоянии регистров, ставить брекпоинты (и реализовывать прочие примитивы отладчика).

Интересуют 2 формата бэкэнда (оба): один стандартный - GDBServer, и один нестандартный - для компилятора SDCC (в сущности, работает всё также по телнету, но с командами отличными от GDBServer)

Эта полезнейшая доработка в перспективе даст возможность реализовать на PC нормальные source-level отладчики - хоть для ASM, хоть для С (меня это особо интересует) из соответствующего компилятора, универсального GUI разработчика ЯВУ (их есть в природе) и эмулятора.

Ну как идея?

Да, была такая идея. Только эти source-level отладчики я пока в глаза не видел, надо бы скачать и посмотреть. Если не лень - кинь ссылки сюда.

Можно начать с компилятора SDCC. Оно на sorceforge есть в исходниках. Там имеется source-level отладчик sdcdb, заточеный под интерфейс с эмулятором ucSim (который платформу Z80 эмулирует только в версии для Линукс и не совместим по формату с GDBserver). Поэтому как мне кажется, прикрутить к sdcc штатные фронтэнды разработки/отладки (GUI), заточенные под GDBserver, не совсем тривиально. Я пока не выгуглил готовых конечных (GUI-compiler-debugger-emulator) реализаций с целевой платформой Z80.

Но работать в этом направлении всё равно надо. :)

Посмотрел я sdcdb. Мазохизм какой-то. :)
Теперь ещё придётся Emacs для винды где-то искать, может там оно лучше выглядит.

Глядя на всё на это, хочется найти нормальный редактор с подсветкой синтаксиса для винды, в котором есть поддержка отладки, и разобравшись с форматом отладочной информации sdcc, написать что-то своё. Emacs не предлагать :)

Дадад. Но как говорится, на безрыбье...
Я как прикинул что для постановки брекпоинта буду в уме строки нумеровать, так и решил - надо искать как прикрутить ГУЙ. :) И бэкенд надо орионовский, а не просто абстактный Z80.

Из простого я посматриваю в сторону ProgrammersNotepad, но пока с ним еще не все ясно - в частности насколько у него хорошо с режимом отладчика.

Мдя. Emacs я ниасилил. Не быть мне линуксоводом :)
Не смог даже запустить sdcdb.el
И потом, терпеть 150Мб ради простого текстового редактора - это уж слишком. Надо искать более компактную среду.

Насколько я понимаю, sdcdb имитирует поведение gdb. Так? То есть, если среда поддерживает gdb в качестве отладчика, то и sdcdb тоже прокатит?

Вопрос в том, насколько оно соответствует gdb. В релиз-нотах разработчики sdcdb писали, цитирую по памяти, "мы старались приблизиться к gdb". Как бы там ни было, до поддержки протокола GDBServer для общения с бэкендом их стараний не хватило.

Есть такая тема: Win+SDCC+Eclipse. HOWTO
Есть и под Винду и под Линух. Уже качаю, вроде как все готовое - надо пробовать. Опять 150Мб. :) но уже с отладчиком.

Но бэкенд платформенного отладчика на базе эмулятора все равно надо как-то делать, мне дефолтный SDCC-шный эмулятор "MCS51 only" - ниочем. А протокол нестандартный и не описан, надо лезть в исходники или смотреть чего оно в родной эмулятор передает.

http://sourceforge.net/projects/ecli...eenshots/61949

Ну, то, что он компактный - это уже хорошо. Исходники есть, если надо - допишем нужный функционал. А может и add-on-ом обойдёмся.

Посмотрю повнимательнее, что за зверь. :)

Фиг там. Интеграцию с SDCC доделали только до компиляции. Отладчик SDCDB не прицеплен, полагаю ввиду его нестандартности. Т.к. для стандартных протоколов опции интеграции отладчиков в рассмотренном плагине Eclipse просматриваются

b2m, спасибо, что добавили эмуляцию Эльфа :) Скажите, а есть ли возможность попробовать заэмулировать Байт-01 (ну и просто байт к нему впридачу?)? Инфу тоже вродь всю собрали и восстановили по фирменной БЭМЗовской документации... Инфа тута (ну и остальные подразделы).

Будет время - сделаю.

Error404, я тут плагин к Programmer's Notepad состряпал, вроде даже работает. Потестируй на досуге http://bashkiria-2m.narod.ru/files/emuide.rar.
Отладка - как везде:
Ctrl+F9 запустить make
F9 поставить точку останова
F5 запуск с точками останова
Ctrl+F5 просто запуск
F10 шаг
F11 шаг с заходом внутрь процедуры (или запуск отладки по шагам, если ещё не запущено)

Ща заценим. :) А что-то я не вижу там sdcdb.exe. Через что оно отлаживает? Что шагает по исходнику?
А где это "везде" такие кнопки? У борландов другие.

Я тут начал SDCC использовать - сплошное расстройство. :( Код не ахти как оптимизирует, компилирует долго - уснуть можно. K&R не понимает, только ANSI (а HitechC середины прошлого столетия, к примеру, понимает и тот и тот). Любительский какой-то продукт.

напиши что делать надо. А то я открываю файл, жму Run и вижу только черный экран:

Сильно не разбирался (времени особо не было).
Запускаем IDE.cmd, компилируем (Ctrl+F9 запустить make), а потом уже RUN и т.д.

Дада. Я так и делаю, однако ".ihx not found". Черный эмулятор и никакого и т.д. ЧЯДНТ?

Просто надо было открывать проект, а не файлы по отдельности. :)

Идем дальше.
Поправил файл тест.с и не могу запустить или скомпилировать - оно пытается сохраниться (какого хека, его просили сохраняться?), но не может: выдает такое или такое с непонятной закономерностью (при любом выборе не сохраняется. И не компилирует потому что не сохранено. замкнутый круг) Тут я застрелился{зачеркнуто} пошел спать.

Еще очень нужны вотчи для хотя бы переменных (но если будет с выражениями, то будет шикарно). Без вотчей отладчик теряет смысл. Калстек - это уже опционально, можно и обойтись без него.

Собственный отладчик. sdcdb.dll написана с нуля, с ней связывается эмулятор через pipe.

У мелкософтовской студии :)

Забыл сказать: надо обязательно проект открывать. Имя запускаемого файла будет по имени проекта. Сейчас make.cmd так делает, но надо бы нормальный make приделать. Ты каким пользуешься?

Хотя, запуск без проекта я тоже предусмотрел, только надо make.cmd поправить, чтобы имя скомпилированного файла совпадало с именем сишного (с точностью до расширения, конечно).

---------- Post added at 01:42 ---------- Previous post was at 01:34 ----------

Это я не знаю, это к разработчику Programmer's Notepad :)

Экий ты шустрый парень! :)
Всё будет. Только вот интерфейс к плагинам у Programmer's Notepad весьма скудный. Я даже клавиши (F5,F9...) сейчас "нелегально" перехватываю, через подставную wndproc. А уж док-панель свою с вотчами сделать - это пока нереально. Пока думаю, как можно сделать. Самое простое - в виде текста в Output, но мне не нравится.

Как оказалось - старая проблема. Не знаю какими функциями файлового IO пользуется PNotepad, но он как и твой эмулятор (об этом я писал в треде с полгода назад) не дружит с виртуальными дисками VirtualBox-а (они из-под хост системы с Линукс по cifs прокидываются в виртуалку в винду, т.е. это как бы сетевые диски). Весь архив лежал на таком диске и глючил. Как только я переместил архив на C: стало работать нормально и все сохраняется.

Пожелания: немного по точкам останова.
1. Во вложении картинка на которой видно, что в эмуляторе еще не закончил работать первый print (не все цифры выведены), а эмулятор уже провалился в точку останова второго print.
2. В точку останова в функции aaa() мне никак не удалось попасть, хотя она явно вызывается - результат ее действия выводится в теле основных print-ов.
3. А можно в какой-нибудь настроечный файл вынести настройку кнопок управления шагалкой, брикпоинтами, запуском/билдом и т.п.? А то очень непривычно. И еще - есть ли возможность ставить точки останова кликом мыши по серому полю слева от строк программы? Кнопкой ставится только в позиции курсора.

Можешь для лучшего понимания написать пару слов - каким образом в модель Ориона влетает скомпилированный бинарник? Просто я не заметил характерных этапов загрузка ДОС Ориона, ощущение такое, что она работает с образа памяти или снапшота - что и как при этом там проинициализировано? Бинарник запускается средствами CCP CP/M (ведь CCP при загрузке файла на выполнение делает некую инициализацию стека и областей 05Ch...06Сh...080h..0FFh)? Можно ли передать параметры командной строки и как?

А вообще, в целом очень приятно выглядит. Если ты допилишь до конца, это будет очень здорово, дело очень нужное. :v2_thumb: Надеюсь у многих людей появится стимул сдвинуть свои С-шные проекты с мертвой точки, т.к. дебугер это очень большое подспорье.

Пипец. SDCC не понимает ключи путей если путь закнчивается на бэкслеш. И начинает характерно глючить. По-моему любой пионер при передаче параметров через комстроку в своих программах анализирует лишние слеши (мало ли чего там пользователь напишет?). :v2_dizzy_facepalm:

1. Это особенность эмулятора. На экране видно только то, что к данному моменту времени успел отобразить "луч кинескопа".
2. Видимо, компилятор соптимизировал до:
А то и вовсе сам константу посчитал. Шагай клавишей F11, она покажет реальный код, который остался.
3. Настройки клавиш пока рановато делать, надо костяк дописать. Про мышь - посмотрю, может и можно. Но не гарантирую.

Если посмотреть на настройки команды Run, то там видно, что эмулятор вызывается с параметрами: orion.emu /d "dbgsvr:%p". То есть грузится сохранённое состояние и указано, что нужно конектиться к внешнему отладчику (параметр %p это имя проекта, фактически, путь к запускаемому файлу, эмулятор передаёт его отладчику). Состояние я сохранил после запуска программы test.com, которая состоит только из перехода jmp 100h, догадываясь, что просто запуск программы с адреса 100h может оказаться неожиданным для ДОСа. :)

После того, как эмулятор сконнектился, отладчик грузит в память эмулятора программу из .ihx, а также анализирует .cdb, после чего запускает программу с начального адреса.

Таким образом, можно сохранить состояние эмулятора для другого компьютера (например ZX Spec), подправить crt0, и можно будет отлаживать программы для Спектрума.

Параметры командной строки передать пока нельзя, можно лишь сохранить состояние эмулятора после запуска test с параметрами. Над этим потом подумаем.

А можно тогда сделать такое:
Я расставляю брикпоинты по исходному тексту, после постановки они красные. Я нажимаю make или run, выполняется компиляция, и по ее результату брекпоинты которые становятся указывающими на несуществующие в выходном файле строки (те что съел при оптимизации компилятор), выделяются другим цветом (например, белым - типа "disabled")?

Просто, шагание - не выход. Я может на тот брекпоинт после миллионного цикла попасть должен (оказывается - не должен: соптимизировано). В рунтайме оно бысто проскочило бы, а шагать я буду до морковкиного заговения.
А так я заранее буду видеть почему оно на этой точке не остановилось.

---------- Post added at 17:11 ---------- Previous post was at 16:58 ----------

Странный луч какой-то. Не все же 5 цифр показывает "срезанные до половины" (как я представлял бы себе построчную развертку), а три из пяти, но эти три - целые.

Может, тогда как-то допилить чтобы эмулятор на точке останова возвращал управление в отладчик с задержкой в 20мс (чтобы луч с гарантией дошел)? Не на каждой строке чтобы делало задержку, а только после брекпоинта перед возвращением фокуса в PNotepad. Для отладчика это не принципиально - там же человек сидит, которому для реакции что, +20мс, что -20мс это один фиг не заметно.

Да, нечто такое предполагается сделать.


Странно ты понимаешь. Луч-то быстрее оказался, чем вывод символа. Т.е. строка (вся) отобразилась лучём на момент между выводом последнего видимого и следующего невидимого.

И что должен делать процессор и остальные устройства (таймер, например) в эти 20мс?
Рассинхронизация времени различных устройств на данный момент не предусмотрена. Первое, что приходит в голову - видео сгенерирует ещё одно прерывание по кадру. И таких мелочей может оказаться очень много. Тут надо какое-то особое извещение посылать, что надо обновить экран, не трогая время внутри эмулятора.

не различных устройств, а отрисовщика экрана и всего прочего эмулятора. Это таймер и ЦПУ сложно по отдельности останавливать, а отрисовку экрана можно приостанавливать (или запускать) когда угодно - за один проход луча оно восстановит отображение на экран текущего состояния экранной памяти.

Поэтому и предложение было такое: останов на брекпоинте останавливает все треды/устройства сразу, кроме треда (или как оно у тебя организовано) экрана, который делает еще один проход луча и тоже встает. И только после этого идет возврат в дебагер. Можно просто тупо "в лоб" (без всяких дополнительных сообщений от дебагера) вызывать в эмуляторе отрисовку сразу после останова всего на паузу/брикпоинт, не выдерживая интервал между проходами луча. Вот примерно такое я имел в виду.

Впрочем, тебе как автору виднее. Но корректные принты на экран нужны - отладка при помощи принтов на экран очень часто используется, а тут она вдруг будет разъезжаться.

На этот счёт я думал сделать перехват вывода в какой-нибудь несуществующий порт, и выводить в Output прямо в IDE. Типа OutputDebugString.

Тогда проще "присесть" на вектор conout BIOS и дублировать в IDE то что туда выводится. Только как быть с conin?

b2m,
Дмитрий, в версии от 22.03.12 в эмуляции "Специалист" не загружаются "кассеты" по сбросу. Раньше всё работало. Пример файла http://www.pk-info.ru/UPLOAD/igrotek...)_original.zip

Исправлено. После того, как я добавил коррекцию среднего значения, эмулятор стал реагировать на шум (когда нет сигнала). В данном файле шум случайно выдал синхробайт. Я добавил пороговое значение шума 2%.

---------- Post added at 17:42 ---------- Previous post was at 17:40 ----------

Никак. Отладочная печать предназначена только для вывода.

как продвигается дело?

Еще очень полезно было бы в некое окно в pnotepad грабить вывод компилятора (линковщика,ассемблера), при этом строки с ошибками помечать в исходном тексте неким цветом фона. (Так делает плагин для связки Эклипса с SDCC, очень удобно).

Пока пытаюсь прилепить док-панель. Если добавить в проект плагина ATL и пару framework-ов из исходников PN, то панель создаётся и даже таскается туда-сюда. Однако, во-первых, код дублирует существующий (и недоступный через интерфейс) в PN, а во-вторых, иногда при закрытии PN по непонятной причине выскакивает исключение. При этом все dll-ки вроде как уже выгружены, и код в месте ошибки даже дизассемблер не выдаёт. Видимо, проблема в том, что окно создаётся плагином, а удаляется PN-ом.

А сейчас разве не так? У меня ошибки компилятора в Output-e как раз красным фоном и выдаёт. И даже кликнуть по ней можно. Строку он находит, а позицию в строе - нет, видимо не предусмотрено. Но там вроде можно свой анализатор состряпать, посмотри настройки Tools для make.

Наверное окну надо овнера/родителя правильного подсунуть. Чтобы они корректно закрывались. А зачем док-окно, для вотчей?

Ну, я на самом деле реально пока еще не работаю в этой среде, жду более-менее функцональную версию - хотя бы с вотчами (чтобы не переучиваться потом). Пока отлаживаюсь принтфами, тяжко. SDCC чего-то науевертил, что у меня компилированное им очень странно [не] работает на стыке с Ethernet (код произведенный HitechC из этих же исходников работает корректно).

А проект собранный из множества файлов-модулей оно будет шагать, переключаясь между окнами/закладками с разными соответствующими исходными файлами?

Не относящееся к разработке: цвета в твоем эмуляторе сделай пожалуйста поярче/почетче. Изображение как будто чуть замыленное , тяжеловато воспринимается.

Конечно, сам-же просил ;)

В тестовом проекте я специально conio.c с отладочной информацией скомпилировал, чтобы по нему шагать. Если на print-е нажать F11, то откроется conio.c. Единственное пока ограничение, все файлы должны лежать в каталоге проекта, т.к. в .cdb имя файла без пути. Позднее, можно будет сделать парсинг файла-проекта, там пути есть. А ещё, из файла-проекта можно генерить makefile, тогда можно будет нормальный make запускать. Я думаю, надо будет написать build.exe, который из проекта сгенерирует makefile и запустит make.

А в меню выбирал 1:1? Один-в-один должно быть не "замыленное".

Честно признаться, makefile никогда не пользуюсь. Т.е. готовый запустить могу, но сам писать не стану. Как-то оно там не по-людски описывается, маргиналами делано. И дело не в описании через переменные, которые через переменные, которые через переменные - этим программирующего не смутить. А в том что просто прет оттуда какой-то линуксячий маргинализм. Не знаю как описать. В-общем, генератор не помешает. Сам то по себе мake полезен, он умеет пересобирать как весь проект, так и только измененное.

Пользовался так как оно по дефолту открывается. 1:1 наверное маловато будет размером. А 2:1 есть? И все равно зеленый у тебя какой-то темно-зеленый. На черном фоне приходится вглядываться. Я помню на реале у меня (подключал в 90-х к телику 3УСЦТ) зеленый в монохроме был ярко-зеленым.

Ну как, получается?

Либо отладочная информация неправильно генерируется, либо я что-то не понимаю, но номера блоков в отладочной информации (которые нужны, чтобы восстановить иерархию блоков, чтобы показывать все переменные, а не только из текущего блока), иногда не соответствуют строке и адресу. Обычно на границах процедур. Вобщем - пока не получается.

Пинг. :)

Может с каким-нибудь упрощениями получится? Допусками-посадками?

Основная проблема сейчас: в отладочной информации никак не отражена оптимизация. Например, в результате оптимизации переменные были размещены в регистрах, и доступ к локальным переменным через IX больше стал не нужен. В итоге, стандартный пролог функции PUSH IX/LD IX,0/ADD IX,SP был выкинут, к аргументам он адресуется через SP, но в отладочной информации об этом ни байта, более того, смещения к аргументам так и остались с учётом того, что в стек кладётся IX. Но с этой мелочью я справился (проверяю наличие пролога). Гораздо хуже, что иногда, несмотря на то, что переменная находится в стеке, и в отладочной информации именно это и сказано, переменная временно располагается в регистре, т.е. при отладке по шагам показываемое значение переменной (из стека) не соответствует реальному значению, т.е. переменная как-бы не меняется, хотя на самом деле это не так. А ещё, бывает, в отладочной информации сказано, что переменная в регистре, а имя регистра не указано (пустая строка). Вот так.

---------- Post added at 14:56 ---------- Previous post was at 14:49 ----------

А ещё, такие перлы:
Здесь: ld 5 (ix), h сохранение старшего байта переменной, относящееся к строке 98, и если мы стоим на строке 99, оно ещё не выполнилось. Отладчик покажет половину старого и половину нового значения переменной :)